Skip to content

RFC ARM: kirkwood: cleanup DT conversion

Thomas Petazzoni linux-arm-kernel 2 versions New

Get series with b4
b4 am 20130128200332.2770093e@skate

Versions newest first · linked by author and title

  1. v2 RFC Latest posting 2/20 of 8 patches 0 repliesNew
  2. v2 RFC posting 1/20 of 8 patches 0 repliesSuperseded

Patches in v2 posting 2/2 No applies recorded yet

None of the 8 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.

Read the v2 thread

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

Dear Ezequiel Garcia,

Quoted 21 lines · Ezequiel Garcia

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>;
        };
};
Quoted 8 lines

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

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

Read the cover letter in its thread