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
