On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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. > No need to manually create platform devices from the devicetree. > Thanks a lot for your feedback, I'll go back and think more about this and try to solve this using a different approach that won't require changing the platform device info structure and reusing the generic SMSC LAN DT binding. > Sascha > Best regards, Javier -- 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
