[alsa-devel] [PATCH RFC v5 4/8] drm/i2c: tda998x: Add support of a DT graph of ports

[Russell King - ARM Linux]

On Thu, Feb 25, 2016 at 03:42:50PM +0200, Jyri Sarha wrote:
> On 02/18/16 16:35, Rob Herring wrote:
> >This should be implied from the port unit address. In other words,
> >port at 0 is defined to be the rgb port. Now, if this is one of several
> >modes for the video port, then that is a different story.
> >
> 
> Do you suggest that also the audio i2s and s/p-dif port-types should be
> coded in the port unit addresses? Something like: port at 0 is always rgb,
> port at 1 is i2s, and port at 2 is spdif?

For the audio inputs, the port address corresponds to the input pin.
TDA998x devices can have multiple streams routed to the pins, and can
select between them.

For example, there may be four I2S data pins and one I2S clock pin.
When using stereo, you can select which of the four I2S data pins
carries the audio data.

When using SPDIF, there may be two SPDIF inputs, and you can select
which SPDIF input is used.

So, "reg" may not be an address in terms of a CPU visible address, but
it's an address as far as selecting the appropriate input - and it
fits in with the requirements of ePAPR, which are that if you have
a unit-address (which is required to distinguish different port nodes)
then you must have a matching "reg" property.

I don't particularly like the video node using the RGB routing register
value either for the reg property, but I've kept quiet because I have
nothing to offer there: again, this comes down to ePAPR requirements
and the need to specify multiple "port { }" nodes.  You can't have two
"port { }" nodes without using a unit-address, and we'd need to chose
a unit-address for it which doesn't conflict with the audio ports...
so there's a kind of logic to using the RGB routing value, which will
never conflict.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.