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

[Javier Martinez Canillas]

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.

> 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