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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 21 Sep 2015 10:19:18 -0500
Rob Herring <robh@xxxxxxxxxx> wrote:

> On 09/18/2015 06:06 AM, Jyri Sarha wrote:
> > From: Jean-Francois Moine <moinejf@xxxxxxx>
> > 
> > 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@xxxxxxx>
> > Signed-off-by: Jyri Sarha <jsarha@xxxxxx>
> > ---
	[snip]
> > diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> > index e9e4bce..35f6a80 100644
> > --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> > +++ b/Documentation/devicetree/bindings/drm/i2c/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"  
> 
> Why do you need this if there is no other choice? The port number should
> define which one is video.

There is no specific port number.
One of the ports is video and two other ones are audio.

> > +
> > +	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>.  
> 
> I'm failing to decode how this value works. In any case, I would keep
> this as a vendor specific property rather than abusing reg.

This has been explained in
https://lkml.org/lkml/2014/1/20/86

> > +
> > +    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)  
> 
> reg is 32-bits.

This port has only 8 significant bits as explained in
https://lkml.org/lkml/2015/1/7/362

> > +
> > +[1] Documentation/devicetree/bindings/graph.txt
> >  
> >  Example:
> >  
> > @@ -26,4 +55,26 @@ Example:
> >  		interrupts = <27 2>;		/* falling edge */
> >  		pinctrl-0 = <&pmx_camera>;
> >  		pinctrl-names = "default";
> > +
> > +		port@230145 {
> > +			port-type = "rgb";
> > +			reg = <0x230145>;
> > +			hdmi_0: endpoint {
> > +				remote-endpoint = <&lcd0_0>;
> > +			};
> > +		};
> > +		port@3 {			/* AP1 = I2S */  
> 
> Is 3 significant? What happened to 0-2?

The value after @ is the 'reg' value (= value of the port register).

> > +			port-type = "i2s";
> > +			reg = <0x03>;
> > +			tda998x_i2s: endpoint {
> > +				remote-endpoint = <&audio1_i2s>;
> > +			};
> > +		};

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux