Representation of external memory-mapped devices in DT (gpmc)

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).

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 at 50000000 {
		compatible = "ti,gpmc";
		ti,hwmods = "gpmc";
		reg = <0x50000000 0x2000>;
		interrupt-parent = <&intc>;
		interrupts = <100>;
		#address-cells = <1>;
		#size-cells = <0>;

		nand at 0 {

			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 at 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

Quoted 7 lines · Daniel Mack

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.

Quoted 3 lines

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.

Quoted 13 lines

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 at 50000000 {
		compatible = "ti,gpmc";
		ti,hwmods = "gpmc";
		reg = <0x50000000 0x2000>;
		interrupt-parent = <&intc>;
		interrupts = <100>;
		#address-cells = <1>;
		#size-cells = <0>;

Quoted 1 line

		nand at 0 {

You may want a CS0 node with nand as a child node of that.

Quoted 12 lines · Rob Herring

Quoted 10 lines · Daniel Mack

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).

Quoted 4 lines

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.

In this case, the controller is @0x50000000 while the external device is mapped to address 0x0.

Quoted 13 lines

Quoted 13 lines

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 at 50000000 {
		compatible = "ti,gpmc";
		ti,hwmods = "gpmc";
		reg = <0x50000000 0x2000>;
		interrupt-parent = <&intc>;
		interrupts = <100>;
		#address-cells = <1>;
		#size-cells = <0>;

Quoted 3 lines

Quoted 1 line

		nand at 0 {

You may want a CS0 node with nand as a child node of that.

Hmm, I don't see what that would buy us. The question is which way is feasible for storing both the memory region and the cs number in the device tree. The CS number should certainly go to the child node, no?

IOW, would it be a good idea to have something like the following layout?

	gpmc: gpmc at 50000000 {
		compatible = "ti,gpmc";
		ti,hwmods = "gpmc";
		reg = <0x50000000 0x2000>;

		/* cs-reg stores the setup of the controller's
		   memory map */

			/* offset	size */
		cs-reg = <0x0		0x1000000
			  ....		.....
			  ....		.....>;

		nand: child at 0 {
			/* timings */
			/* peripheral specifics */
		};
	};

I would actually much prefer that approach.

Afzal, because because that way, we can leave the code as-is for now and add the "cs-reg" property once the code is switched to dynamic handling. What do you think?

Thanks,
Daniel

Quoted 18 lines · Daniel Mack

Quoted 16 lines · Rob Herring

Quoted 10 lines · Daniel Mack

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.

Quoted 2 lines

In this case, the controller is @0x50000000 while the external device is mapped to address 0x0.

Okay, so it's not fixed or some sub-range of the memory map.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

The binding will use one top-level node to describe the GPMC

Quoted 1 line

Quoted 1 line

Quoted 1 line

itself and register the actual devices as sub-nodes to it. The NAND

Quoted 1 line

Quoted 1 line

Quoted 1 line

is the only one that is currently supported. This is how it currently

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

    gpmc: gpmc at 50000000 {
            compatible = "ti,gpmc";
            ti,hwmods = "gpmc";
            reg = <0x50000000 0x2000>;
            interrupt-parent = <&intc>;
            interrupts = <100>;
            #address-cells = <1>;
            #size-cells = <0>;

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

            nand at 0 {

You may want a CS0 node with nand as a child node of that.

Hmm, I don't see what that would buy us. The question is which way is feasible for storing both the memory region and the cs number in the device tree. The CS number should certainly go to the child node, no?

I was thinking of if you had per CS properties you needed to setup each CS. So something like this (using non-zero address to show the translation better):

gpmc {
        compatible = "ti,gpmc", "simple-bus";
        ti,hwmods = "gpmc";
        reg = <0x50000000 0x2000>;

        CS0 {
                // map 1MB @ gpmc offset 0 to host address 0x10000000
                ranges = <0x10000000 0x0 <0x100000>;

                // other gpmc specific per CS properties.
                nand {
                        reg = <0x0 0x100000>;
                }
        };

The core code will look at parents' ranges properties to translate the local offset of 0 into host address of 0x10000000 Then the nand node's reg address will get translated to 0x10000000.

The gpmc code can then use the ranges properties to setup the mapping of each chip select to the host address. You don't need a new property to describe the cs mapping.

Rob

Quoted 2 lines

IOW, would it be a good idea to have something like the following

Quoted 22 lines

      gpmc: gpmc at 50000000 {
              compatible = "ti,gpmc";
              ti,hwmods = "gpmc";
              reg = <0x50000000 0x2000>;

              /* cs-reg stores the setup of the controller's
                 memory map */

                      /* offset       size */
              cs-reg = <0x0           0x1000000
                        ....          .....
                        ....          .....>;

              nand: child at 0 {
                      /* timings */
                      /* peripheral specifics */
              };
      };

I would actually much prefer that approach.

Quoted 8 lines

Afzal, because because that way, we can leave the code as-is for now and add the "cs-reg" property once the code is switched to dynamic handling. What do you think?

Thanks,
Daniel

Quoted 1 line · Rob Herring

You may want a CS0 node with nand as a child node of that.

Hmm, I don't see what that would buy us. The question is which way is feasible for storing both the memory region and the cs number in the device tree. The CS number should certainly go to the child node, no?

IOW, would it be a good idea to have something like the following layout?

	gpmc: gpmc at 50000000 {
		compatible = "ti,gpmc";
		ti,hwmods = "gpmc";
		reg =<0x50000000 0x2000>;

		/* cs-reg stores the setup of the controller's
		   memory map */

			/* offset	size */
		cs-reg =<0x0		0x1000000
			  ....		.....
			  ....		.....>;

		nand: child at 0 {
			/* timings */
			/* peripheral specifics */
		};
	};

I would actually much prefer that approach.

Afzal, because because that way, we can leave the code as-is for now and add the "cs-reg" property once the code is switched to dynamic handling. What do you think?

Hi Daniel,

Quoted 29 lines · Daniel Mack

Quoted 1 line · Rob Herring

You may want a CS0 node with nand as a child node of that.

Hmm, I don't see what that would buy us. The question is which way is feasible for storing both the memory region and the cs number in the device tree. The CS number should certainly go to the child node, no?

IOW, would it be a good idea to have something like the following layout?

	gpmc: gpmc at 50000000 {
		compatible = "ti,gpmc";
		ti,hwmods = "gpmc";
		reg =<0x50000000 0x2000>;

		/* cs-reg stores the setup of the controller's
		   memory map */

			/* offset	size */
		cs-reg =<0x0		0x1000000
			  ....		.....
			  ....		.....>;

		nand: child at 0 {
			/* timings */
			/* peripheral specifics */
		};
	};

Quoted 5 lines

I would actually much prefer that approach.

Afzal, because because that way, we can leave the code as-is for now and add the "cs-reg" property once the code is switched to dynamic handling. What do you think?

I don't know what to say, don't have a good grasp on DT to give right suggestion.

It seems offset field may not be necessary. memory for connected peripherals is not fixed, only CS is fixed (as CS pin is hard-wired). Physical memory can be anywhere between 0-512MB (with alignment constraints depending on size, refer GPMC_CONFIG7 register), even though right now memory region for peripheral seems to be fixed (for boards supported in mainline it will be what bootloader configures), it is possible to have it in a different region for those peripherals.

Quoted 41 lines · Afzal Mohammed

Hi Daniel,

Quoted 29 lines · Daniel Mack

Quoted 1 line · Rob Herring

You may want a CS0 node with nand as a child node of that.

Hmm, I don't see what that would buy us. The question is which way is feasible for storing both the memory region and the cs number in the device tree. The CS number should certainly go to the child node, no?

IOW, would it be a good idea to have something like the following layout?

	gpmc: gpmc at 50000000 {
		compatible = "ti,gpmc";
		ti,hwmods = "gpmc";
		reg =<0x50000000 0x2000>;

		/* cs-reg stores the setup of the controller's
		   memory map */

			/* offset	size */
		cs-reg =<0x0		0x1000000
			  ....		.....
			  ....		.....>;

		nand: child at 0 {
			/* timings */
			/* peripheral specifics */
		};
	};

Quoted 5 lines

I would actually much prefer that approach.

Afzal, because because that way, we can leave the code as-is for now and add the "cs-reg" property once the code is switched to dynamic handling. What do you think?

I don't know what to say, don't have a good grasp on DT to give right suggestion.

Quoted 8 lines

It seems offset field may not be necessary. memory for connected peripherals is not fixed, only CS is fixed (as CS pin is hard-wired). Physical memory can be anywhere between 0-512MB (with alignment constraints depending on size, refer GPMC_CONFIG7 register), even though right now memory region for peripheral seems to be fixed (for boards supported in mainline it will be what bootloader configures), it is possible to have it in a different region for those peripherals.

The question is whether this is transparent to the client driver at the end. If the driver needs to know about the address of the external memory (that's the case for the smsx911x for example), that value should be in the device tree.

Actually, there's an example here that matches our case quite well:

http://devicetree.org/Device_Tree_Usage#Ranges_.28Address_Translation.29

I think the important part is to get the bindings straight so we don't have to change them anymore later on; we don't really need to parse the values from the generic driver and set up the mappings accrodingly - that can be added easily later on. For a first shot, we can just write default values to the DT that are computed anyway, right?