Sound and the TDA998x binding

[Peter Rosin]

On 2018-11-13 20:09, Russell King - ARM Linux wrote:
> On Tue, Nov 13, 2018 at 06:12:37PM +0000, Peter Rosin wrote:
>> On 2018-11-13 18:24, Russell King - ARM Linux wrote:
>>> On Tue, Nov 13, 2018 at 01:28:40PM +0000, Peter Rosin wrote:
>>>> Hi!
>>>>
>>>> I'm wondering about some programming details regarding the TDA998x
>>>> driver...
>>>>
>>>> The bindings documentation [1] state that one should fill in the
>>>> desired register content of the AP_ENA register. However, I cannot
>>>> find any details anywhere about how one determines what is desired.
>>>> When I look for data sheets on the Internet, all I find is a "short"
>>>> data sheet, which is far from enlightening. There are hints about
>>>> a "full" data sheet in the chapter on legal information of the
>>>> "short" data sheet. Is the "full" data sheet protected by an NDA
>>>> or something? That's the only reason I can find for it not being
>>>> available...
>>>>
>>>> Maybe someone with such a "full" data sheet at hand can enlighten
>>>> me on the workings of this AP_ENA register so that I know what it is
>>>> that I need to fill in? Since it is so difficult to find this info,
>>>> maybe it should be added to the binding?
>>>
>>> There's various public documents for the TDA998x chips, some of which
>>> do contain the register programming information - although we don't
>>> have definitive information for every variant that the driver supports.
>>
>> I have looked, and not found anything. Do you have any pointer? For what
>> chip(s) in the family are there register information?
> 
> TDA9983B is the main one, but as I say, it doesn't document several
> registers found in the TDA19988 - we have no definitive register
> descriptions for this chip.

That's something at least. I was hoping for some info on how to set things
up for external 12MHz for the CEC chip, but it looks like I'm out of luck.
I guess I'll have to experiment in order to maybe get that working...

>>> Even so, that doesn't give us documentation for this register, so we
>>> have to resort to code received from other sources.
>>>
>>> The AP_ENA register "audio port enable" is one bit per AP signal, from
>>> the AP0 pin being bit 0, up to the AP7 pin being bit 7.
>>
>> Thanks! However, in the "short" sheet for the TDA19988 that I have, there
>> is this table:
>>
>> AP0                  WS (word select)
>> AP1   S/PDIF input   I2S-bus channel 0
>> AP2   S/PDIF input   I2S-bus channel 1
>> AP3                  I2S-bus channel 2
>> AP4                  I2S-bus channel 3
>> ACLK                 SCK (I2S-bus clock)
>>
>> AP5 through AP7 are nowhere to be found...
> 
> Right, so only bits 0 to 4 are meaningful.
> 
>> Should I assume that ACLK is an alias for AP5, and that the register
>> content should be 0x23 for I2S on channel 0? Or is ACLK not part of
>> the AP_ENA register at all, so that 0x03 is more likely to be correct?
> 
> I believe 0x03 as per the example binding in the tda998x document.
> The example given is from Jean's work for the Dove Cubox which
> uses a TDA19988, which has both I2S and S/PDIF wired to the
> TDA19988 - I2S data on AP1, S/PDIF data on AP2.

Ok, thanks!

Next question. The example in the tda998x binding has a line

		#sound-dai-cells = <2>;

with no further explanation. I think this is a bug, and that it should
be <1>, but that's just a hunch (I haven't dug into the code). I base
my hunch on the fact that the Cubox Audio example in the simple-card
binding [1] has a couple of lines like this

		sound-dai = <&tda998x 1>;

i.e. with only one cell. One cell is also what I would expect, given
how you can define more than one audio connection in the tda998x
node and that 2 cells seems over the top for what is needed. However,
arch/arm/boot/dts/am335x-boneblack-common.dtsi has #sound-dai-cells = <0>,
and that's the only upstream mention of audio and tda998x in a real
device tree context. So there is apparently some confusion.

Maybe #sound-dai-cells = <0> works if the tda998x node only defines
one audio input?

Cheers,
Peter

[1] Documentation/devicetree/bindings/sound/simple-card.txt