[PATCH RFC 1/7] platform: add a device node

[Sascha Hauer]

On Mon, Feb 11, 2013 at 11:33:19AM +0100, Javier Martinez Canillas wrote:
> On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> > On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
> >> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
> >> <linux at arm.linux.org.uk> wrote:
> >> > On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
> >> >> I knew this would be controversial and that's why I didn't mean it to be a patch
> >> >> but a RFC :)
> >> >>
> >> >> The problem basically is that you have to associate the platform device with its
> >> >> corresponding DT device node because it can be used in the driver probe function.
> >> >
> >> > When DT is being used, doesn't DT create the platform devices for you,
> >> > with the device node already set correctly?
> >> >
> >>
> >> Well they usually do but not always just like usually you have a
> >> platform_device in your board code and call platform_device_register().
> >>
> >> But in some configurations you can't just define the platform_device
> >> required resources (I/O memory, IRQ, etc) as static platform data.
> >> In some cases you need a level of indirection.
> >>
> >> In this particular case a SMSC ethernet chip is connected to an
> >> OMAP3 processor through its General-Purpose Memory Controller.
> >>
> >> You can't just define the I/O memory used by the device since you first
> >> need to request that address to the GPMC. The same happens with the
> >> IRQ line since a OMAP GPIO pin is used so you have to first configure
> >> the GPIO line as input.
> >
> > For the gpio interrupt you can use, example taken from omap4-var-som.dts:
> >
> >         interrupt-parent = <&gpio6>;
> >         interrupts = <11>; /* gpio line 171 */
> >
> > Other architectures allow to specify the edge/level hi/low active
> > parameters from the devicetree aswell. The gpio direction should be
> > handled by the gpio driver as necessary, at least that's what done on
> > other architectures.
> >
> > If the SMSC hangs on the GPMC then the SMSC should be a child node of
> > the GPMC. The GPMC would then act as a bus driver and configure the
> > chipselects and timings for its children automatically, maybe based
> > on timing information from the devicetree. I've never tried this before,
> > but I think that's the way things should be.
> >
> 
> Hi Sasha,
> 
> The SMSC is already a child node of the GPMC in the device tree but instead
> using the generic SMSC binding I added a GPMC-specific SMSC binding.
> 
> Since the SMSC binding doesn't have a chip select property and it expects
> the I/O memory address to be explicitly defined in the reg property while
> the GPMC needs to request this memory according to the chip select used.

So you probably have this:

	gpmc {
		compatible = "ti,gpmc", "simple-bus";
		ranges;

		smsc911x {
			compatible = "smsc,91x";
		}
	}

If you remove the simple-bus property the gpmc devices would not be
probed. If then you add a driver which matches "ti,gpmc" you can
configure the chip selects in its probe callback. After this you
can call of_platform_populate() starting from the gpmc device node
to instantiate the gpmc child devices.

Please somebody interrupt me if I'm talking total rubbish here. I never
tried this and only assume it should work like this.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |