mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Mirza Krak <mirza.krak@gmail.com>, <swarren@wwwdotorg.org>,
	<thierry.reding@gmail.com>
Cc: <gnurou@gmail.com>, <linux@armlinux.org.uk>,
	<pdeschrijver@nvidia.com>, <pgaikwad@nvidia.com>,
	<mturquette@baylibre.com>, <sboyd@codeaurora.org>,
	<robh+dt@kernel.org>, <mark.rutland@arm.com>,
	<devicetree@vger.kernel.org>, <linux-tegra@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-clk@vger.kernel.org>
Subject: Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller
Date: Wed, 24 Aug 2016 16:56:45 +0100	[thread overview]
Message-ID: <de2fb909-829e-6c04-4f6a-442cbb9171c9@nvidia.com> (raw)
In-Reply-To: <1472045838-22628-4-git-send-email-mirza.krak@gmail.com>


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

  reply	other threads:[~2016-08-24 15:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-24 13:37 [PATCH v2 0/6] Add support for Tegra GMI bus controller Mirza Krak
2016-08-24 13:37 ` [PATCH v2 1/6] clk: tegra: add TEGRA20_CLK_NOR to init table Mirza Krak
2016-08-24 13:37 ` [PATCH v2 2/6] clk: tegra: add TEGRA30_CLK_NOR " Mirza Krak
2016-08-24 13:37 ` [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller Mirza Krak
2016-08-24 15:56   ` Jon Hunter [this message]
2016-08-24 19:54     ` Mirza Krak
2016-08-26  4:53       ` Mirza Krak
2016-08-26  7:25         ` Jon Hunter
2016-08-29  7:38           ` Mirza Krak
2016-08-30 17:06       ` Rob Herring
2016-08-31 11:22         ` Mirza Krak
2016-09-06 10:32           ` Jon Hunter
2016-09-19  7:21             ` Mirza Krak
2016-09-30  8:02               ` Jon Hunter
2016-09-06 10:35           ` Jon Hunter
2016-08-30 15:02   ` Marcel Ziswiler
2016-08-31  9:24     ` Mirza Krak
2016-08-24 13:37 ` [PATCH v2 4/6] ARM: tegra: Add Tegra30 GMI support Mirza Krak
2016-08-24 13:37 ` [PATCH v2 5/6] ARM: tegra: Add Tegra20 " Mirza Krak
2016-08-24 13:37 ` [PATCH v2 6/6] bus: Add support for Tegra Generic Memory Interface Mirza Krak
2016-08-26  8:21   ` Jon Hunter
2016-08-30 15:01 ` [PATCH v2 0/6] Add support for Tegra GMI bus controller Marcel Ziswiler
2016-08-31  9:23   ` Mirza Krak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=de2fb909-829e-6c04-4f6a-442cbb9171c9@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gnurou@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=mirza.krak@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=pdeschrijver@nvidia.com \
    --cc=pgaikwad@nvidia.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®