On Tue, Nov 13, 2018 at 08:58:15PM +0000, Peter Rosin wrote:
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...
The only setup I'm aware with the TDA19988 is one which uses the internal FRO - I don't believe with the TDA19988 that there's any possibility of other clocking methods for the CEC part.
The TDA19988 makes some reference to an external 12MHz clock as a possibility, but the pinning information makes no mention of which pins may receive a 12MHz clock, or be a 12MHz oscillator. The block diagram immediately below the reference to this external 12MHz clock only shows the FRO and no external clock reference. So the documentation seems to be inconsistent.
That said, here's some information for setting it up for an external crystal:
- read-modify-write REG_CEC_CLK masking the register value with 0xe6 (there's no information about what the bits in this register do.) - avoid calling tda998x_cec_calibration()
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).
It does look that way - snd_soc_get_dai_name() does this:
switch (args->args_count) { case 0: id = 0; /* same as dai_drv[0] */ break; case 1: id = args->args[0]; break; default: /* not supported */ break; }
so a value of '2' for #sound-dai-cells would result in the default path being taken. I suspect it's a typo.