Am 25.09.2014 um 10:03 schrieb Peter Ujfalusi:
> On 09/24/2014 10:24 PM, Grazvydas Ignotas wrote:
>>> 18 controls. For speakers, headset, microphone, vibramotor.
>>>
>>
>> On a mixer that shows mux switches I get a lot mere, they don't even fit
>> 2 fullhd worth of screen with. Although I'll admit I haven't tried it on
>> 3.17 yet, it's what I had on 3.8.
>
> Yes, you seams to have kernel with AESS/ABE code with the firmware for AESS.
>
>> And this (+plus the 'plop' problem) effectively means that you'll need a
>> binary blob to have any kind of working audio on Pyra, which sucks.
After studying one of the documents we got for the TWL6040 it appears
that it should be possible to remove the plop&click (in a system without AESS/ABE)
by subtracting some calibration offset that each chip provides and using
a specific initialization sequence of DAC and amplifier.
Most likely we need something similar in any system so it is not necessarily
something specific to the TWL6040.
>>
>> I know I sound like a broken record, but I don't like this twl6030
>> solution at all: binary blob, high complexity and difficulty to use even
>> basic features, driver dependencies on frameworks that we may have no
>> permission to use (if I understood Peter correctly).
>
> Well, I should not say that, but I tend to agree. The audio solution with
> twl6040 is comlex. It can deliver pretty neat features, but it has it's cost.
IMHO only software cost... Hardware cost is lower wiht TWL6040 than with
solutions like OpenPandora (ca. 30 external components instead of 1).
Anyways, if we want non-complex solutions without dependencies we
shouldn't build a Pyra at all and stay far away from Linux :)
But this answers only half of the question Notaz has raised:
What about the binary blobs and driver dependencies without permission to use?
>
>>> On the other hand - if we want to use the ABE I think we are
>>> forced to use the TWL6040 since I am not aware of any other
>>> compatible codec.
>>
>> Maybe 256fs clock that's coming from twl4030 on pandora could be
>> generated by some dedicated chip. There still seems to be a external
>> clock input pin on OMAP5 called abe_clks that looks similar to
>> mcbsp_clks in use on OMAP3 pandora. According to OMAP5 TRM, MCBSP1 can
>> be clocked by it.
>
> I know products using OMAP4 with other codec(s) than twl6040 (and AESS is not
> used by them either).
> AFAIK we did some counting in the past regarding to available audio
> connections and you might not have enough to satisfy your needs w/o twl6040.
> OMAP5 has:
> 1 x McPDM
> 1 x DMIC (up to 6 mic)
> 3 x McBSP,
> 1 x McASP (4 x serializers, no AFIFO - means it is prone to under/over run)
If I did get the pinmux subtleties right it is even worse: you can't have 1xMcASP
and 3xMcBSP in parallel. At most 3 out of 4.
The EVM assigns:
McPDM: TWL6040
McBSP1: BT
McBSP2: FM
McBSP3: expansion connector (i.e. for external modem)
>
> If you can live with the 3 x McBSP, then you can select whatever codec you
> want, it should work with it.
That is the issue. We need:
1x for codec (speakers/headset)
1x for 3G/4G modem
1x for digital BT headset
1x for digital FM radio
which one should we leave out?
We can easily serve all of them if the codec for the speakers is the TWL6040.
>
> The McASP is a bit tricky since I do not even have means to test it, but with
> a quick look at the registers, I think the davinci-mcasp driver should be able
> to handle it just fine - in a same way as DRA7, but w/o the FIFO support.
For me this looks more complex and risky than copying the circuits of the EVM
and taking the existing software. But I am mostly a hardware guy :)
>
>> Of course it's risky to try to use something no other board uses, but we
>> did the same with pandora and it worked out in the end..
Well, we should draw decisions based on goals and knowledge, not on lucky
experiences :)
@Notaz:
What I don't understand is that on one hand you complain about the complexitiy
of an existing and apparently working solution. But on the other
hand you want to take the risks of a solution that no other board uses. If
it doesn't work immediately, we might come up with 10 times complexity
to make it work. And might even have to come back to the TWL6040.
BR,
Nikolaus