Sound and the TDA998x binding

Sound and the TDA998x binding

[Peter Rosin]

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?

Pointers on how to obtain a copy of said "full" data sheet would
be appreciated.

The chip I have is TDA19988, if that is of any consequence...

Cheers,
Peter

[1] Documentation/devicetree/bindings/display/bridge/tda998x.txt
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Sound and the TDA998x binding

[Russell King - ARM Linux]

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.
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.

-- 
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Sound and the TDA998x binding

[Peter Rosin]

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?

> 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...

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?

Cheers,
Peter
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Sound and the TDA998x binding

[Russell King - ARM Linux]

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.

> > 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.

-- 
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Sound and the TDA998x binding

[Russell King - ARM Linux]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel