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

[Russell King - ARM Linux]

On Thu, Feb 18, 2016 at 04:18:23PM +0100, Jean-Francois Moine wrote:
> On Thu, 18 Feb 2016 08:35:30 -0600
> Rob Herring <robh at kernel.org> wrote:
> 
> > On Wed, Feb 17, 2016 at 04:49:05PM +0200, Jyri Sarha wrote:
> > > From: Jean-Francois Moine <moinejf at free.fr>
> > > 
> > > Two kinds of ports may be declared in a DT graph of ports: video and audio.
> > > This patch accepts the port value from a video port as an alternative
> > > to the video-ports property.
> > > It also accepts audio ports in the case the transmitter is not used as
> > > a slave encoder.
> > > The new file include/sound/tda998x.h prepares to the definition of
> > > a tda998x CODEC.
> > > 
> > > Signed-off-by: Jean-Francois Moine <moinejf at free.fr>
> > > Signed-off-by: Jyri Sarha <jsarha at ti.com>
> > > ---
> > >  .../devicetree/bindings/display/bridge/tda998x.txt | 51 ++++++++++++
> > >  drivers/gpu/drm/i2c/tda998x_drv.c                  | 90 +++++++++++++++++++---
> > >  include/sound/tda998x.h                            |  8 ++
> > >  3 files changed, 140 insertions(+), 9 deletions(-)
> > >  create mode 100644 include/sound/tda998x.h
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
> > > index e9e4bce..35f6a80 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt
> > > +++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
> > > @@ -16,6 +16,35 @@ Optional properties:
> > >  
> > >    - video-ports: 24 bits value which defines how the video controller
> > >  	output is wired to the TDA998x input - default: <0x230145>
> > > +	This property is not used when ports are defined.
> > > +
> > > +Optional nodes:
> > > +
> > > +  - port: up to three ports.
> > > +	The ports are defined according to [1].
> > > +
> > > +    Video port.
> > > +	There may be only one video port.
> > > +	This one must contain the following property:
> > > +
> > > +	- port-type: must be "rgb"
> > 
> > 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.
> > 
> > > +	and may contain the optional property:
> > > +
> > > +	- reg: 24 bits value which defines how the video controller
> > > +		output is wired to the TDA998x input (video pins)
> > > +		When absent, the default value is <0x230145>.
> > 
> > This is not really how reg is intended to be used. Can you explain how 
> > this value is determined?
> > 
> > > +    Audio ports.
> > > +	There may be one or two audio ports.
> > > +	These ones must contain the following properties:
> > > +
> > > +	- port-type: must be "i2s" or "spdif"
> > > +
> > > +	- reg: 8 bits value which defines how the audio controller
> > > +		output is wired to the TDA998x input (audio pins)
> > 
> > Same here.
> 
> Hi Rob,
> 
> These audio/video port definitions were discussed in the thread
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-August/095836.html
> but, you are right, and as you already said in the thread 
> https://lists.freedesktop.org/archives/dri-devel/2015-September/090544.html
> 'reg' should not be used here.

However, ePAPR requires that a node name with @n also have a reg property
with the same n value.  See ePAPR 2.2.1.1.  This statement in it seems
to be particularly clear on this subject:

"The unit-address must match the first address specified in the reg
property of the node. If the node has no reg property, the @ and
unit-address must be omitted and the node-name alone differentiates
the node from other nodes at the same level in the tree."

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