On 10/29/2012 09:39 AM, Daniel Mack wrote:
> Hi,
>
> we're currently working on a DT binding for the GPMC bus that is found
> on SoCs by TI. The implementation is based on CS lines and an 8, 16 or
> 32 bit parallel interface. That IP is quite flexible, and it can for
> example be used for physmap flash, external peripherals or even NAND.
>
> Depending on which CS is used to control the device, different memory
> regions are reserved, and there's code to calculate the location and
> size of them, given a CS number (see arch/arm/mach-omap2/gpmc.c).
I don't know the details of the h/w, but I would think the DT core code
should be able work out the addresses. This can be done using ranges
property which defines the mapping of a child bus into the parent bus
addresses.
> The binding will use one top-level node to describe the GPMC controller
> itself and register the actual devices as sub-nodes to it. The NAND type
> is the only one that is currently supported. This is how it currently looks:
>
> gpmc: gpmc@50000000 {
> compatible = "ti,gpmc";
> ti,hwmods = "gpmc";
> reg = <0x50000000 0x2000>;
> interrupt-parent = <&intc>;
> interrupts = <100>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> nand@0 {
You may want a CS0 node with nand as a child node of that.
Rob
> reg = <0>; /* CS0 */
> nand-bus-width = <16>;
> nand-ecc-mode = "soft";
>
> gpmc,sync-clk = <0>;
> gpmc,cs-on = <0>;
> gpmc,cs-rd-off = <44>;
> gpmc,cs-wr-off = <44>;
> gpmc,adv-on = <6>;
> gpmc,adv-rd-off = <34>;
> gpmc,adv-wr-off = <44>;
> gpmc,we-off = <40>;
> gpmc,oe-off = <54>;
> gpmc,access = <64>;
> gpmc,rd-cycle = <82>;
> gpmc,wr-cycle = <82>;
> gpmc,wr-access = <40>;
> gpmc,wr-data-mux-bus = <0>;
>
> #address-cells = <1>;
> #size-cells = <1>;
>
> partition@0 {
> label = "1st";
> reg = <0x0 0x20000>;
> };
> /* more partitions ... */
> };
> };
>
> The question is where the resource location and sizes should be
> described so that the code that does the magic run-time calculations can
> be removed eventually. I would clearly prefer not to have them in the
> child, as the only thing these nodes really care about is the chip
> select index the hardware is wired to.
>
> Should the "reg" property in the parent be augmented to hold such details?
>
> Once we got that sorted out, I'll do a re-spin of the series and copy
> devicetree-discuss on the patch that adds the bindings.
>
>
> Thanks,
> Daniel
>
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
