Linux-Renesas-SoC Archive on lore.kernel.org
 help / color / Atom feed
From: Chris Brandt <Chris.Brandt@renesas.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	Mason Yang <masonccyang@mxic.com.tw>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Subject: RE: [PATCH 6/6] dt-bindings: spi: Document Renesas SPIBSC bindings
Date: Wed, 4 Dec 2019 13:31:18 +0000
Message-ID: <TY1PR01MB1562322613FC52617312F14E8A5D0@TY1PR01MB1562.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <CAMuHMdUn3h1VjYkARTFBqMij5aYg2mJSVErwceHc0NATBo+_hw@mail.gmail.com>

Hi Geert,

> To avoid future problems, you probably do want to specify spi-tx-bus-width =
> <4> and spi-rx-bus-width = <4> in DTS now.

I didn't do that because if the MTD layer then thinks I 'want' to do 4-bit access, then that introduces a new problem the solve.
The MTD layer might start sending down QUAD READ commands to the external SPI and then the SPI Flash will start sending back data on all 4 lines, but the controller is only configured for 1-bit transfers.

I honestly don't know when/why the MTD layer decides on switch from 1-bit to 4-bit mode, so while the board hardware is wired for 4-bit (as the DT would document), we are not ready to be doing 4-bit just yet.
I just want to try and get the driver in at first....then we can make it do fancy stuff later.

If someone can tell me that even if "spi-rx-bus-width = <4>" is put I the board DTS, the spi will still only do 1-bit transfers until the application specially enables 4-bit mode, then I'm fine with add bus-width=<4> in the DTS.

Unless....I did not understand you meaning....

Did you mean put 'spi-rx-bus-width = <4>' in the .dtsi????  (then I can override it back to <1>  that in the board .dts)???



> > Basically, it's like the 'role switch' in the USB OTG drivers.
> 
> If you want to do that, both configurations should be described in DT, and we
> need a way to specify what's being used.
> I guess if the direct mapped mode is used, you always want to boot the kernel
> using that mode, and only switch to SPI mode temporarily after boot?  So that
> could be handled by manually unbinding the driver from physmap-flash, and
> forcing a bind to spibsc, all from sysfs.

Yes, I agree. That is what I would suggest to someone. (I suggest unbind/bind for a lot of situations that people ask me what to do).

> (Which cuts the branch the kernel is sitting on in the case of XIP...)
XIP is a special case all in it's own.....which is why we uses a completely special driver for R/W in XIP mode...which is out of scope from mainline.
The case I'm talking above would probably before an R-Car or RZ/G use case. But, since no one has stated a use case like that, it's very low on the priority list.


> > So my suggestion is to forget about trying to 'support' direct mode in
> > this driver at the moment. If you're using this HW for something like
> > XIP, then don't enable this driver at all (which is what we have been
> > doing).
> 
> Still, the direct-mapped mode should be described in DT, when used.
> arch/arm/boot/dts/r7s72100-gr-peach.dts does describe the FLASH, but fails to
> describe the exact topology (flash is a child of spibsc, and thus relies on
> the spibsc module clock being turned on).

I can agree with that....and we go back to my first idea: If you are 'using' the SPIBSC for anything (XIP or SPI mode) then you describe that in DT. And when the driver probes, if it does not see a 'spi-nor' partition, it does not register a spi-controller, but it does keep the clock (power) on the entire time (until removed).

For GR-PEACH, we would just have to go back and put the qspi@18000000 (which is currently at the root) node under a spibsc node.

Of course also if we do all this, we could drop all the patches for enabling 'critical clocks' that were needed to cover the XIP cases.


> BTW, when using spibsc in direct-mapped mode: if you turn of and on again the
> module clock, does the spibsc need reprogramming?

Nope. Everything will stay the same (just like all the other peripherals). The only thing you 'might' want to do is flush the read cache (especially if you disconnected it because you were going to go out and re-write some of the flash in SPI mode).

Chris


  reply index

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03  3:45 [PATCH 0/6] spi: Add Renesas SPIBSC controller Chris Brandt
2019-12-03  3:45 ` [PATCH 1/6] clk: renesas: mstp: Add critical clock from device tree support Chris Brandt
2019-12-03 18:32   ` Geert Uytterhoeven
2019-12-03 18:46     ` Chris Brandt
2019-12-03 18:51       ` Geert Uytterhoeven
2019-12-03  3:45 ` [PATCH 2/6] ARM: dts: r7s72100: Add SPIBSC clocks Chris Brandt
2019-12-03 18:42   ` Geert Uytterhoeven
2019-12-03 18:57     ` Chris Brandt
2019-12-03 19:12       ` Geert Uytterhoeven
2019-12-04  8:38         ` Lee Jones
2019-12-04  9:03           ` Geert Uytterhoeven
2019-12-04  9:47             ` Lee Jones
2019-12-04 11:00               ` Chris Brandt
2019-12-03  3:45 ` [PATCH 3/6] clk: renesas: r7s9210: Add SPIBSC clock Chris Brandt
2019-12-03 18:49   ` Geert Uytterhoeven
2019-12-03 19:09     ` Chris Brandt
2019-12-03 20:40       ` Geert Uytterhoeven
2019-12-04  3:09         ` Chris Brandt
2019-12-03  3:45 ` [PATCH 4/6] spi: Add SPIBSC driver Chris Brandt
2019-12-03 14:19   ` Mark Brown
2019-12-03 15:00     ` Chris Brandt
2019-12-03 18:29     ` Geert Uytterhoeven
2019-12-04 11:25       ` Mark Brown
2019-12-04 12:14         ` Geert Uytterhoeven
2019-12-04 15:51     ` Chris Brandt
2019-12-04 16:49       ` Mark Brown
2019-12-03 18:28   ` Geert Uytterhoeven
2019-12-04 11:18     ` Mark Brown
2019-12-04 22:12     ` Chris Brandt
2019-12-03  3:45 ` [PATCH 5/6] ARM: dts: r7s9210: Add SPIBSC Device support Chris Brandt
2019-12-03 18:59   ` Geert Uytterhoeven
2019-12-03 22:38     ` Chris Brandt
2019-12-04  7:57       ` Geert Uytterhoeven
2019-12-04 11:04         ` Chris Brandt
2019-12-03  3:45 ` [PATCH 6/6] dt-bindings: spi: Document Renesas SPIBSC bindings Chris Brandt
2019-12-03  9:14   ` Sergei Shtylyov
2019-12-03 13:27     ` Chris Brandt
2019-12-03 16:04       ` Sergei Shtylyov
2019-12-03 16:35         ` Chris Brandt
2019-12-03 18:57   ` Geert Uytterhoeven
2019-12-03 20:39     ` Geert Uytterhoeven
2019-12-04  2:54       ` Chris Brandt
2019-12-04  8:56         ` Geert Uytterhoeven
2019-12-04 13:31           ` Chris Brandt [this message]
2019-12-05 15:48             ` Geert Uytterhoeven
2019-12-05 16:00               ` Chris Brandt
2019-12-04  8:40       ` Geert Uytterhoeven
2019-12-03 22:33     ` Chris Brandt
2019-12-04  8:43       ` Geert Uytterhoeven
2019-12-04 11:19         ` Chris Brandt

Reply instructions:

You may reply publically 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=TY1PR01MB1562322613FC52617312F14E8A5D0@TY1PR01MB1562.jpnprd01.prod.outlook.com \
    --to=chris.brandt@renesas.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=masonccyang@mxic.com.tw \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=sergei.shtylyov@cogentembedded.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

Linux-Renesas-SoC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-renesas-soc/0 linux-renesas-soc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-renesas-soc linux-renesas-soc/ https://lore.kernel.org/linux-renesas-soc \
		linux-renesas-soc@vger.kernel.org
	public-inbox-index linux-renesas-soc

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-renesas-soc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git