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