On 21/07/16 21:10, Mirza Krak wrote:

2016-07-21 11:56 GMT+02:00 Jon Hunter [off-list ref]:

quoted

quoted

+
+The NOR controller supports a number of memory types, including synchronous NOR,
+asynchronous NOR, and other flash memories with similar interfaces, such as
+MuxOneNAND. One could also connect high speed devices like FPGAs, DSPs,
+CAN chips, Wi-Fi chips etc.

Nit-pick ... the Tegra documentation refers to this controller as the
GMI (general memory interface) or SNOR (sync-NOR) controller because it
is not just limited to NOR as you mentioned. I see references to GMI in
the Tegra pinctrl driver and so may be we should use this name.

ACK.

quoted

quoted

+Required properties:
+
+ - compatible: should be "nvidia,tegra20-nor", "nvidia,tegra30-nor"

I see at least one difference at the register level between Tegra20 and
Tegra30 and so I think this should be something like ...

 - compatible : Should contain one of the following:
        For Tegra20 must contain "nvidia,tegra20-gmi".
        For Tegra30 must contain "nvidia,tegra30-gmi".

ACK. Just curious, which register was it? I only checked that they
have the same count of registers.

Register counts are the same, but the SNOR_CONFIG_0 is not identical. I
believe only Tegra30 defines bit 14.

quoted

quoted

+ - nvidia,config: This property represents the SNOR_CONFIG_0 register.

There is also a SNOR_MIO_CONFIG for the MIO address space and so I think
that this should be nvidia,snor-config to be explicit. It might be nice
to also add a "nvidia,mio-config" while you are at it as well, however,
that could always be done later. If you do, then the
"nvidia,snor-config" becomes optional depending on whether you are using
the SNOR or MIO address space.

ACK the nvidia,snor-config part, will though wait for further comments
regarding what to do with the config registers, break-out or keep it
is a one property / register.

Regarding mio-config, not sure about if I would like to include that
part in this stage. If you feel strongly about this we can do it. If
it only comes to down to replicate the same configurations that we do
for SNOR to MIO then I do not see much of a problem, but would like
SNOR to be accepted and would not like the MIO part to halt this. But
then again this up to you guys.

quoted

quoted

+
+Note that the NOR controller does not have any internal chip-select address
+decoding and if you want to access multiple devices external chip-select
+decoding must be provided.

Although it is true, you do have the MIO address space and so you could
support two devices via the SNOR address space and MIO address space
(assuming that the MIO can be used for the 2nd device).

This is true. If we include MIO support above could be added to the bindings.

quoted

Furthermore, if you do have external logic to support multiple devices
this would assume that the devices use the same timing and so are
probably the same type. It also assumes both can fit in the 256MB
address range. May be worth mentioning.

ACK.

quoted

The GMI does have 8 chip selects and I believe the purpose of these is
to allow you to address more than the 256MB range. However, I believe to
do this it require software intervention to change the current CS that
is in use.

Yes that is true. One has to modify the SNOR_CONFIG register to choose
a different CS pin.

quoted

I wonder if it is worth mentioning that the chip-select specified in the
"nvidia,config" prop should match that in the "ranges" prop unless you
have some external decoding logic to provide an external chip-select.
Which raises a question, what does the chip-select in the ranges
actually represent? I am not sure if there is a common practice here for
device tree when boards have external logic to provide additional
chip-selects. I am sure this is quite common.

I do not understand why CS pin setting in nvidia,config need to match
the "ranges" prop? Other then maybe cosmetics.

Yes it would be cosmetic. That said, I even wonder if CS needs to be
exposed at all given that they all map to the same CPU address space.
Couldn't your binding for the CAN devices be as follows?

nor@70009000 {
	...

	can@48000000 {
		...
	};

	can@48040000 {
		...
	};
};

Problem is if you did have devices on different chip-selects then how
would these be handled? They could not point to the same physical
address. I am not sure if there is a way to do that in DT?

Cheers
Jon

-- 
nvpublic