[RFC V2 PATCH 0/8] ARM: kirkwood: cleanup DT conversion

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Mon Jan 28 14:03:32 EST 2013


Dear Ezequiel Garcia,

On Mon, 28 Jan 2013 15:41:12 -0300, Ezequiel Garcia wrote:

> Note that in Jason's proposal, it's possible to instantiate a bus'
> child device, configure its address window and then call the
> corresponding driver using a regular of_node.
> 
> For instance,
> 
> // MBUS Decoder window for NAND
> nand at f4000000 {
>         #address-cells = <1>;
>         #size-cells = <1>;
>         compatible = "simple-bus", "marvell,orion-mbus";
>         mbus-target = <0x01 0x2f>;
>         ranges = <0 0xf4000000 0x10000>;
> 
>         nand at 0 {
>                 // ...
>                compatible = "marvell,orion-nand";
>                reg = <0x0 0x400>;
>         };
> };
> 
> In this example, we can configure the window using both mbus-target
> and ranges properties and then use the child node to instantiate an
> "orion-nand" device.
> 
> I understand your point regarding PCIe flexibility needs.
> So I wonder, in your proposed scheme,
> who should call this "address decoding window" driver
> in order to still be able to instantiate child devices easily?

I am not sure to exactly understand what you mean here. You would have
a DT node for the NAND, and another one for the NOR. Each of them use a
different compatible string (such as the "marvell,orion-nand" you've
mentioned). Those correspond to platform_drivers, like all other
devices described in the DT, nothing different. In their ->probe()
function, those driver call some mvebu_setup_addr_decoding_window()
function, which is part of an API provided by the address mapping
driver.

The address at which we configure the various address decoding windows
is an operating system specific decision, it is not a description of
the hardware. Therefore, it shouldn't be encoded in the DT, because the
DT describes the hardware, not the Linux-specific decisions on how the
hardware should be used.

Of course, for things like the internal registers decoding windows, we
can't really make the DT unaware of that, because it is so fundamental
to even having the platform booting. But for all other windows, it is
an operating system decision, and not a hardware description.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com



More information about the linux-arm-kernel mailing list