On 09/08/16 09:40, Mirza Krak wrote:

2016-08-08 16:44 GMT+02:00 Jon Hunter [off-list ref]:

quoted

On 06/08/16 20:40, Mirza Krak wrote:

quoted

From: Mirza Krak <redacted>

Document the devicetree bindings for the Generic Memory Interface (GMI)
bus driver found on Tegra SOCs.

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

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

@@ -0,0 +1,99 @@
+Device tree bindings for NVIDIA Tegra Generic Memory Interface bus
+
+The Generic Memory Interface bus enables memory transfers between internal and
+external memory. Can be used to attach various high speed devices such as
+synchronous/asynchronous NOR, FPGA, UARTS and more.
+
+The actual devices are instantiated from the child nodes of a GMI node.
+
+Required properties:
+  - compatible : Should contain one of the following:
+        For Tegra20 must contain "nvidia,tegra20-gmi".
+        For Tegra30 must contain "nvidia,tegra30-gmi".
+ - reg: Should contain GMI controller registers location and length.
+ - clocks: Must contain an entry for each entry in clock-names.
+ - clock-names: Must include the following entries: "gmi"
+ - resets : Must contain an entry for each entry in reset-names.
+ - reset-names : Must include the following entries: "gmi"
+ - #address-cells: The number of cells used to represent physical base
+   addresses in the GMI address space.
+ - #size-cells: The number of cells used to represent the size of an address
+   range in the GMI address space.
+ - ranges: Mapping of the GMI address space to the CPU address space.
+
+Note that the GMI 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. Furthermore, if you do have external logic to

The above is not 100% accurate. I would say that because there is no
chip-select address decoding, chip-selects either need to be managed via
software or by employing external chip-select decoding logic.

ACK, will update with the possibility of managing CS in software.

quoted

quoted

+support multiple devices this would assume that the devices use the same
+timing and so are probably the same type. It also assumes that they can fit in
+the 256MB address range.

Again this is only true for the case where you have external chip-select
decoding logic, but would not be the case if software were to manage the
chip-selects.

ACK

quoted

quoted

+
+Optional properties:
+
+ - nvidia,snor-data-width-32bit: Use 32bit data-bus, default is 16bit.
+ - nvidia,snor-mux-mode: Enable address/data MUX mode.
+ - nvidia,snor-rdy-active-before-data: Assert RDY signal one cycle before data.
+   If omitted it will be asserted with data.
+ - nvidia,snor-rdy-inv: RDY signal is active high
+ - nvidia,snor-adv-inv: ADV signal is active high
+ - nvidia,snor-oe-inv: WE/OE signal is active high
+ - nvidia,snor-cs-inv: CS signal is active high
+ - nvidia,snor-cs-select: CS output pin configuration. Default is CS0

Nit ... I think "nvidia,snor-cs" is sufficient for the name. But I am
not sure if we even need this. See below.

quoted

+     <0> : CS0
+     <1> : CS1
+     <2> : CS2
+     <3> : CS3
+     <4> : CS4
+     <5> : CS5
+     <6> : CS6
+     <7> : CS7
+
+  Note that there is some special handling for the timing values.
+  From Tegra TRM:
+  Programming 0 means 1 clock cycle: actual cycle = programmed cycle + 1
+
+ - nvidia,snor-muxed-width: Number of cycles MUX address/data asserted on the
+   bus. Valid values are 0-15, default is 1
+ - nvidia,snor-hold-width: Number of cycles CE stays asserted after the
+   de-assertion of WR_N (in case of SLAVE/MASTER Request) or OE_N
+   (in case of MASTER Request). Valid values are 0-15, default is 1
+ - nvidia,snor-adv-width: Number of cycles during which ADV stays asserted.
+   Valid values are 0-15, default is 1.
+ - nvidia,snor-ce-width: Number of cycles before CE is asserted.
+   Valid values are 0-255, default is 4

ce-width only occupies a 4-bit field and so the max is 15.

ACK.

quoted

quoted

+ - nvidia,snor-we-width: Number of cycles during which WE stays asserted.
+   Valid values are 0-15, default is 1
+ - nvidia,snor-oe-width: Number of cycles during which OE stays asserted.
+   Valid values are 0-255, default is 1
+ - nvidia,snor-wait-width: Number of cycles before READY is asserted.
+   Valid values are 0-255, default is 3
+
+Example with two SJA1000 CAN controllers connected to the GMI bus:
+
+  gmi@70090000 {
+    #address-cells = <1>;
+    #size-cells = <1>;

I think 0 for size makes sense. I know that caused you problems before,
but I am wondering if ...

quoted

+    ranges;

... ranges is needed here? If we do have it, I am wondering if it should
be a single entry for the chip-select that is being used. For now we
could only support a ranges with one entry.

        #address-cells = <1>;
        #size-cells = <1>;
        ranges = <4 0x48000000 0x00040000>;

I prefer if we have "ranges" with one single entry, and warn if user enters
multiple for now, like we discussed earlier. Should have really done it in
this series.

I think I do as well.

quoted

quoted

+    nvidia,snor-mux-mode;
+    nvidia,snor-adv-inv;
+    nvidia,snor-cs-select = <4>;

I would have expected these under bus@X node as they are specific to the
GMI CS.

Yes, that is true.

quoted

I would also expect that the actual chip-select number is encoded in the
reg property.

quoted

+
+    bus@0,0 {

bus@4

ACK.

quoted

No mention of this bus node in the above documentation.

I was hesitant documenting it since I am not sure if we really need it
in a generic case? It does make sense in my
specific case. But what would it look like if we could maintain CS in software.

Do you then have a bus node per CS? I am guessing not. Is it enough to
document it in my "example brief"?

I see what you mean. May be it is fine to document with the examples
below how child devices should be populated. You should also state that
currently the GMI only supports one child device currently for the
chip-select that is being used.

Cheers
Jon

-- 
nvpublic