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.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
