On Mon, Jul 25, 2016 at 02:36:35PM +0100, Jon Hunter wrote:

On 25/07/16 12:59, Thierry Reding wrote:

quoted

* PGP Signed by an unknown key

On Thu, Jul 21, 2016 at 10:56:44AM +0100, Jon Hunter wrote:

quoted

On 19/07/16 14:36, Mirza Krak wrote:

quoted

From: Mirza Krak <redacted>

Document the devicetree bindings for NOR bus driver found on Tegra20 and
Tegra30 SOCs

Signed-off-by: Mirza Krak <redacted>
---
 .../devicetree/bindings/bus/nvidia,tegra20-nor.txt | 73 ++++++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/nvidia,tegra20-nor.txt

diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra20-nor.txt b/Documentation/devicetree/bindings/bus/nvidia,tegra20-nor.txt
new file mode 100644
index 0000000..9ee4a66
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/nvidia,tegra20-nor.txt

@@ -0,0 +1,73 @@
+Device tree bindings for NVIDIA Tegra20/30 NOR Bus
+
+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.

quoted

+
+The actual devices are instantiated from the child nodes of a NOR node.
+
+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".

quoted

+ - reg: Should contain NOR controller registers location and length.
+ - clocks: Must contain one entry, for the module clock.
+   See ../clocks/clock-bindings.txt for details.
+ - resets : Must contain an entry for each entry in reset-names.
+   See ../reset/reset.txt for details.
+ - reset-names : Must include the following entries:
+  - nor
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells:	Must be set to 1 to allow CS address passing
+ - ranges: Must be set up to reflect the memory layout with four integer
+ 		values for each chip-select line in use.
+ - 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.

Thierry, Stephen, do prefer all the fields on the config registers are
broken out? There are quite a few but I am not sure what we typically
recommend here?

As I said elsewhere, I prefer breaking the fields out into separate
properties because that makes it a lot easier to write the DT. Rather
than having to go and manually assemble 32-bit values for this register
and the timing registers, it must be a lot easier to look at datasheets
and copy the values into the corresponding DT properties.

That's what I thought :-)

quoted

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

Now I'm even more confused. If the GMI controller itself can't select a
chip, what is the SNOR_SEL field in the SNOR_CONFIG_0 register for? Does
that not select a specific chip?

So the GMI has 8 chip-selects and these can be used by either the SNOR
interface for MIO interface. As you mentioned the chip-select used for
the SNOR interface is configured by the field SNOR_SEL in the
SNOR_CONFIG and similarly the chip-select for the MIO interface is
configured by the MIO_SEL field in the MIO_CONFIG register.

Looking at the Tegra20 TRM, the SNOR interface is mapped to the address
range 0xd0000000-0xdfffffff and the MIO interface is mapped to the
address range 0xe0000000-0xefffffff. If chip-select 0 is used for SNOR
and chip-select 1 is used for MIO, you can support two devices at the
same time and they will be accessible via different address ranges.
Whether you can use the MIO interface for the 2nd device is another
question.

If you want to support two 256MB NOR devices on the SNOR interface, then
you would need to reconfigure the SNOR_CONFIG each time you swap between
the two devices.

quoted

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.

Similarly if you switch between different devices, wouldn't you have to
reprogram the timing registers if they are different?

Yes.

Okay, good. I'm relieved that I wasn't completely mistaken about how
this kind of hardware works. =)

quoted

The way I remember this kind of interface to work (it's been a long time
since I used one) is that in order to operate on a chip you need to
acquire the bus first. Typically that would be an API exposed by the bus
driver or some framework that the bus driver registers with. That API
arbitrates between multiple devices on the bus and makes sure that the
proper chip select is asserted and timing is programmed when you're
granted access. A driver that has acquired the bus can then perform what
operations they need and release the bus when done.

SPI uses a mechanism like this, for example.

That would make sense. However, I am not sure how that would work with
the client drivers, such as the CAN driver Mirza is using, that wishes
to read/write directly to the SNOR address space. I am guessing that SPI
works like I2C and buffers up the requests and performs them in sequence.

Yes, you would of course have to guard accesses by the drivers with
calls to an API that acquire and release the bus. Not that it's very
nice, but in the absence of automatic address to CS translation that
really is the only way to solve it (explicit chip-select).

It doesn't seem like we currently have infrastructure for it, but we
would need something like that to solve this in the general case.

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/81966d43/attachment.sig>