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

On 10/31/2012 07:08 PM, Daniel Mack wrote:

On 30.10.2012 11:50, Afzal Mohammed wrote:

quoted

Hi Daniel,

On Monday 29 October 2012 10:52 PM, Daniel Mack wrote:

quoted

On 29.10.2012 16:09, Rob Herring wrote:

quoted

quoted

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

quoted

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?

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.

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 had tried to find an example in PPC dts files, but didn't. This
example is what you should follow.

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?

For whatever parts of a CS are programmable, make sure they are in the
DT or you can calculate them from the DT data.

Rob