Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1469449 > unrolled thread
| Started by | Mirza Krak <mirza.krak@gmail.com> |
|---|---|
| First post | 2016-08-24 15:40 +0200 |
| Last post | 2016-08-24 22:00 +0200 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH v2 0/6] Add support for Tegra GMI bus controller Mirza Krak <mirza.krak@gmail.com> - 2016-08-24 15:40 +0200
[PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller Mirza Krak <mirza.krak@gmail.com> - 2016-08-24 15:40 +0200
Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller Jon Hunter <jonathanh@nvidia.com> - 2016-08-24 18:00 +0200
Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller Mirza Krak <mirza.krak@gmail.com> - 2016-08-24 22:00 +0200
| From | Mirza Krak <mirza.krak@gmail.com> |
|---|---|
| Date | 2016-08-24 15:40 +0200 |
| Subject | [PATCH v2 0/6] Add support for Tegra GMI bus controller |
| Message-ID | <s9Gzo-2Q5-5@gated-at.bofh.it> |
From: Mirza Krak <mirza.krak@gmail.com> Hi. This is a follow up to my previous RFC to add support for Tegra GMI bus controller. I have tested this series on a Tegra30 using a Colibri T30 SOM on a custom carrier board which has multiple CAN controllers (SJA1000) connected to the GMI bus. I have rebased on top of latest tegra/for-next in V2. Also see individual patches for changes in V2. See below links for previous discussions. Comments on RFC: https://marc.info/?l=linux-clk&m=146893557629903&w=2 https://marc.info/?l=linux-tegra&m=146893541829801&w=2 https://marc.info/?l=linux-tegra&m=146893542429814&w=2 Comments on V1: https://marc.info/?l=linux-arm-kernel&m=147051551821122&w=2 https://marc.info/?l=linux-arm-kernel&m=147051553121150&w=2 https://marc.info/?l=linux-arm-kernel&m=147194856600627&w=2 https://marc.info/?l=linux-arm-kernel&m=147072742432211&w=2 Mirza Krak (6): clk: tegra: add TEGRA20_CLK_NOR to init table clk: tegra: add TEGRA30_CLK_NOR to init table dt/bindings: Add bindings for Tegra GMI controller ARM: tegra: Add Tegra30 GMI support ARM: tegra: Add Tegra20 GMI support bus: Add support for Tegra Generic Memory Interface .../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132 ++++++++++++ arch/arm/boot/dts/tegra20.dtsi | 13 ++ arch/arm/boot/dts/tegra30.dtsi | 12 ++ drivers/bus/Kconfig | 8 + drivers/bus/Makefile | 1 + drivers/bus/tegra-gmi.c | 231 +++++++++++++++++++++ drivers/clk/tegra/clk-tegra20.c | 1 + drivers/clk/tegra/clk-tegra30.c | 1 + 8 files changed, 399 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt create mode 100644 drivers/bus/tegra-gmi.c -- 2.1.4
[toc] | [next] | [standalone]
| From | Mirza Krak <mirza.krak@gmail.com> |
|---|---|
| Date | 2016-08-24 15:40 +0200 |
| Subject | [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller |
| Message-ID | <s9Gzo-2Q5-21@gated-at.bofh.it> |
| In reply to | #1469449 |
From: Mirza Krak <mirza.krak@gmail.com>
Document the devicetree bindings for the Generic Memory Interface (GMI)
bus driver found on Tegra SOCs.
Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
---
Changes in v2:
- Updated examples and some information based on comments from Jon Hunter.
.../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132 +++++++++++++++++++++
1 file changed, 132 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..8c1e15f
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
@@ -0,0 +1,132 @@
+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. Should be 1.
+ - #size-cells: The number of cells used to represent the size of an address
+ range in the GMI address space. Should be 1.
+ - ranges: Must be set up to reflect the memory layout with three integer values
+ for each chip-select line in use (only one entry is supported, see below
+ comments):
+ <cs-number> <physical address of mapping> <size>
+
+Note that the GMI controller does not have any internal chip-select address
+decoding, because of that chip-selects either need to be managed via software
+or by employing external chip-select decoding logic.
+
+If external chip-select logic is used to support multiple devices it is assumed
+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. In this case only one
+child device is supported which represents the active chip-select line, see
+examples for more insight.
+
+Required child cs node properties:
+ - reg: First entry should contain the active chip-select number
+
+Optional child cs node 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
+
+ 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-15, default is 4
+ - 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. We wrap the
+controllers with a simple-bus node since they are all connected to the same
+chip-select (CS4), in this example external address decoding is provided:
+
+gmi@70090000 {
+ compatible = "nvidia,tegra20-gmi";
+ reg = <0x70009000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&tegra_car TEGRA20_CLK_NOR>;
+ clock-names = "gmi";
+ resets = <&tegra_car 42>;
+ reset-names = "gmi";
+ ranges = <4 0x48000000 0x7ffffff>;
+
+ status = "disabled";
+
+ bus@4 {
+ compatible = "simple-bus";
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 4 0x40100>;
+
+ nvidia,snor-mux-mode;
+ nvidia,snor-adv-inv;
+
+ can@0 {
+ reg = <0 0x100>;
+ ...
+ };
+
+ can@40000 {
+ reg = <0x40000 0x100>;
+ ...
+ };
+ };
+};
+
+Example with one SJA1000 CAN controller connected to the GMI bus
+on CS4:
+
+gmi@70090000 {
+ compatible = "nvidia,tegra20-gmi";
+ reg = <0x70009000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&tegra_car TEGRA20_CLK_NOR>;
+ clock-names = "gmi";
+ resets = <&tegra_car 42>;
+ reset-names = "gmi";
+ ranges = <4 0x48000000 0x7ffffff>;
+
+ status = "disabled";
+
+ can@4 {
+ reg = <4 0x100>;
+ ...
+ nvidia,snor-mux-mode;
+ nvidia,snor-adv-inv;
+ };
+};
--
2.1.4
[toc] | [prev] | [next] | [standalone]
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Date | 2016-08-24 18:00 +0200 |
| Subject | Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller |
| Message-ID | <s9IKR-4jv-21@gated-at.bofh.it> |
| In reply to | #1469454 |
On 24/08/16 14:37, Mirza Krak wrote:
> From: Mirza Krak <mirza.krak@gmail.com>
>
> Document the devicetree bindings for the Generic Memory Interface (GMI)
> bus driver found on Tegra SOCs.
>
> Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
> ---
> Changes in v2:
> - Updated examples and some information based on comments from Jon Hunter.
>
> .../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132 +++++++++++++++++++++
> 1 file changed, 132 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..8c1e15f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
> @@ -0,0 +1,132 @@
> +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. Should be 1.
> + - #size-cells: The number of cells used to represent the size of an address
> + range in the GMI address space. Should be 1.
> + - ranges: Must be set up to reflect the memory layout with three integer values
> + for each chip-select line in use (only one entry is supported, see below
> + comments):
> + <cs-number> <physical address of mapping> <size>
> +
> +Note that the GMI controller does not have any internal chip-select address
> +decoding, because of that chip-selects either need to be managed via software
> +or by employing external chip-select decoding logic.
> +
> +If external chip-select logic is used to support multiple devices it is assumed
> +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. In this case only one
> +child device is supported which represents the active chip-select line, see
> +examples for more insight.
> +
> +Required child cs node properties:
> + - reg: First entry should contain the active chip-select number
> +
> +Optional child cs node 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
> +
> + 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-15, default is 4
> + - 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. We wrap the
> +controllers with a simple-bus node since they are all connected to the same
> +chip-select (CS4), in this example external address decoding is provided:
> +
> +gmi@70090000 {
> + compatible = "nvidia,tegra20-gmi";
> + reg = <0x70009000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + clocks = <&tegra_car TEGRA20_CLK_NOR>;
> + clock-names = "gmi";
> + resets = <&tegra_car 42>;
> + reset-names = "gmi";
> + ranges = <4 0x48000000 0x7ffffff>;
> +
> + status = "disabled";
> +
> + bus@4 {
> + compatible = "simple-bus";
> + reg = <4>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 4 0x40100>;
Does this work? I tried to add an example like this and I got ...
Warning (reg_format): "reg" property in /gmi@70009000/bus@4 has invalid
length (4 bytes) (#address-cells == 1, #size-cells == 1)
I am wondering if we should just following the arm,pl172 example and
have ...
cs4 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
nvidia,snor-cs = <4>;
nvidia,snor-mux-mode;
nvidia,snor-adv-inv;
can@0 {
reg = <0 0x100>;
...
};
...
};
Cheers
Jon
--
nvpublic
[toc] | [prev] | [next] | [standalone]
| From | Mirza Krak <mirza.krak@gmail.com> |
|---|---|
| Date | 2016-08-24 22:00 +0200 |
| Subject | Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller |
| Message-ID | <s9Mv7-6UZ-23@gated-at.bofh.it> |
| In reply to | #1469558 |
2016-08-24 17:56 GMT+02:00 Jon Hunter <jonathanh@nvidia.com>:
+
>> +Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap the
>> +controllers with a simple-bus node since they are all connected to the same
>> +chip-select (CS4), in this example external address decoding is provided:
>> +
>> +gmi@70090000 {
>> + compatible = "nvidia,tegra20-gmi";
>> + reg = <0x70009000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + clocks = <&tegra_car TEGRA20_CLK_NOR>;
>> + clock-names = "gmi";
>> + resets = <&tegra_car 42>;
>> + reset-names = "gmi";
>> + ranges = <4 0x48000000 0x7ffffff>;
>> +
>> + status = "disabled";
>> +
>> + bus@4 {
>> + compatible = "simple-bus";
>> + reg = <4>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0 4 0x40100>;
>
> Does this work? I tried to add an example like this and I got ...
>
> Warning (reg_format): "reg" property in /gmi@70009000/bus@4 has invalid
> length (4 bytes) (#address-cells == 1, #size-cells == 1)
Shoot, to get rid of the warning it should be
reg = <4 0 >;
But it works either way.
>
> I am wondering if we should just following the arm,pl172 example and
> have ...
>
> cs4 {
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> nvidia,snor-cs = <4>;
> nvidia,snor-mux-mode;
> nvidia,snor-adv-inv;
>
> can@0 {
> reg = <0 0x100>;
> ...
> };
>
> ...
> };
>
That means to go back to V1 really (almost :)). Which I do not mind.
Will give it a test run.
But I am a little hesitant if will be any better/cleaner. In your example above:
can@0 {
reg = <0 0x100>;
...
};
Would this really translate correctly? In the pl172 example they have
multiple ranges and address with "flash@0,0" which a range defined in
parent node. "can@0" does not have valid match in parent node in our
example. So I probably need add some more logic for it to properly
translate.
I have an idea which is following:
gmi@70090000 {
status = "okay";
#address-cells = <2>;
#size-cells = <1>;
ranges = <4 0 0x48000000 0x00040000>;
cs4 {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges;
nvidia,snor-cs = <4>;
nvidia,snor-mux-mode;
nvidia,snor-adv-inv;
can@0 {
compatible = "nxp,sja1000";
reg = <4 0 0x100>;
...
};
can@40000 {
compatible = "nxp,sja1000";
reg = <4 0x40000 0x100>;
...
};
};
};
Do not know if above will work at all (not able to test at current
location), anyway I will play around with it some more and get back to
you.
Best Regards
Mirza
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web