[PATCH v2 0/2] Improve drm_of_component_probe() and move rockchip to use it

Jean-Francois Moine moinejf at free.fr
Thu Dec 24 00:15:28 PST 2015


On Wed, 23 Dec 2015 18:59:48 +0000
Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:

> > > Have a look at my v2 where I've introduced two compare functions and also
> > > modified the Rockchip compare_port() to use port->parent in the comparison. I
> > > guess that should solve your problem.
> > 
> > Keeping the port instead of the parent asks for more code, but,
> > especially, it also asks for changes in the component drivers because,
> > at bind time, in 'data', they get a port instead of the device.
> 
> Sorry, this doesn't make sense.  You have far too many sub-clauses
> which mean nothing at all.  Please rephrase.

Well, two topics:

- adding a second 'of_compare' function complexifies the code
  and people may wonder why such a function is needed and what
  they have to put inside.

- usually, the component drivers just do a component_add() of the device
  at probe time.
  Now, as the bind() function of the components of the first level
  returns the port in 'data', some work has to be done for retrieving
  the device.
  This can (should?) be done in the bind() function.
  In drm/imx/ipuv3-crtc.c, this is done by a hack, changing the device
  node reference before calling component_add()!

I looked at the imx-drm and the associated DTs, and I think that,
without the v2 patch and keeping the port parent as the component
(previous mail), the code could be simplified adding an intermediate
device node in the DT.

For example, in imx6qdl.dtsi:

	ipu1: ipu at 02400000 {
		...
		ports at 2 {			/* di<x> device */
			ipu1_di0: port {
				...
				ipu1_di0_hdmi: endpoint at 1 {
					remote-endpoint = <&hdmi_mux_0>;
				};
				...
			};
		};
	}

In the code, the ipu driver searches the 'ports' and adds them as components.
After binding, the devices are the 'ports'.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



More information about the linux-arm-kernel mailing list