On Mon, Jul 25, 2016 at 02:09:18PM +0100, Jon Hunter wrote:

On 25/07/16 13:10, Thierry Reding wrote:

quoted

* PGP Signed by an unknown key

On Thu, Jul 21, 2016 at 10:10:49PM +0200, Mirza Krak wrote:

quoted

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.

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.

What's the difference between SNOR and MIO? Sorry if I'm being dense but
a quick look around the internet didn't yield anything related. I'd be
happy to read up if somebody can provide a link.

I am not sure where this term MIO comes from (may be an NVIDIA term),
but from looking at the MIO_CONFIG register, it looks like a basic
16/32-bit interface with configurable read/write strobe timing. Does not
support bursting or address/data multiplexing that the SNOR interface
does. So may be it is used for interfacing to external devices such as
FIFOs, UARTs, I2C expanders, etc.

Yes, looks like some sort of parallel interface to connect external
devices and make them act like MMIO. Perhaps MIO is supposed to be
"memory I/O". I've found some vague references to MIO == multi-I/O,
but that was always related to serial flash (essentially something
like QSPI).

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160725/ce37864a/attachment.sig>