From: thierry.reding@gmail•com (Thierry Reding)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC 3/6] dt/bindings: Add bindings for Tegra20/30 NOR bus driver
Date: Mon, 25 Jul 2016 15:39:22 +0200 [thread overview]
Message-ID: <20160725133922.GK21170@ulmo.ba.sec> (raw)
In-Reply-To: <CALw8SCU6vWeDyoy+t53k2+tmnrZd+ieBV88Vc6FSL9x3FzSm5g@mail.gmail.com>
On Mon, Jul 25, 2016 at 03:30:34PM +0200, Mirza Krak wrote:
> 2016-07-25 13:59 GMT+02:00 Thierry Reding <thierry.reding@gmail•com>:
> > On Thu, Jul 21, 2016 at 10:56:44AM +0100, Jon Hunter wrote:
> >>
> >
> >> > +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?
> >
> >> 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?
> >
> > 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.
> >
> > Thierry
>
> From my experience (maybe not as long as yours :)) but these kind of
> things would be handled by the controller. At least with previous SOCs
> that I have used, PXA270, PXA300 and i.MX SOCs.
>
> That it has an address range per chip-select PIN and timing registers
> per chip-select. And thus eliminating a need for a infrastructure or
> framework.
Okay, so the controllers have a translation table that needs to be
programmed and which maps address ranges to chip-selects. That's a nifty
feature, but I think it's also fairly specialized. In such a setup there
doesn't need to be a concept of chip-selects in software because it's
all transparently handled by the controller. Effectively the only time a
chip-select is needed is during the initial programming of the
controller when the translation table is set up.
>From a software point of view the devices are then addressed by memory
address alone, so they aren't on a "manually switched" bus using chip-
selects.
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/e85f0eda/attachment.sig>
next prev parent reply other threads:[~2016-07-25 13:39 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 13:36 [RFC 0/6] Add support for Tegra20/30 NOR bus controller Mirza Krak
2016-07-19 13:36 ` [RFC 1/6] clk: tegra: add TEGRA20_CLK_NOR to init table Mirza Krak
2016-07-25 11:17 ` Thierry Reding
2016-07-25 12:28 ` Mirza Krak
2016-07-25 13:23 ` Thierry Reding
2016-07-19 13:36 ` [RFC 2/6] clk: tegra: add TEGRA30_CLK_NOR " Mirza Krak
2016-07-19 13:36 ` [RFC 3/6] dt/bindings: Add bindings for Tegra20/30 NOR bus driver Mirza Krak
2016-07-20 12:44 ` Rob Herring
2016-07-20 19:28 ` Mirza Krak
2016-07-21 10:26 ` Jon Hunter
2016-07-25 11:36 ` Thierry Reding
2016-07-25 13:20 ` Mirza Krak
2016-07-25 13:27 ` Thierry Reding
2016-07-25 13:33 ` Mirza Krak
2016-07-21 9:56 ` Jon Hunter
2016-07-21 20:10 ` Mirza Krak
2016-07-22 9:32 ` Jon Hunter
2016-07-22 19:07 ` Mirza Krak
2016-07-25 8:14 ` Jon Hunter
2016-07-25 12:10 ` Thierry Reding
2016-07-25 13:09 ` Jon Hunter
2016-07-25 13:32 ` Thierry Reding
2016-07-25 11:59 ` Thierry Reding
2016-07-25 13:30 ` Mirza Krak
2016-07-25 13:39 ` Thierry Reding [this message]
2016-07-25 13:50 ` Mirza Krak
2016-07-25 13:36 ` Jon Hunter
2016-07-25 13:49 ` Thierry Reding
2016-07-25 11:30 ` Thierry Reding
2016-07-25 13:16 ` Mirza Krak
2016-07-25 14:15 ` Thierry Reding
2016-07-25 14:38 ` Mirza Krak
2016-07-25 15:01 ` Jon Hunter
2016-07-25 15:34 ` Thierry Reding
2016-07-25 19:59 ` Mirza Krak
2016-07-26 8:32 ` Thierry Reding
2016-07-28 9:29 ` Mirza Krak
2016-07-19 13:36 ` [RFC 4/6] ARM: tegra: Add Tegra30 NOR support Mirza Krak
2016-07-19 13:36 ` [RFC 5/6] ARM: tegra: Add Tegra20 " Mirza Krak
2016-07-19 13:36 ` [RFC 6/6] bus: Add support for Tegra NOR controller Mirza Krak
2016-07-21 10:15 ` Jon Hunter
2016-07-21 20:42 ` Mirza Krak
2016-07-22 9:38 ` Jon Hunter
2016-07-22 19:18 ` Mirza Krak
2016-07-25 8:19 ` Jon Hunter
2016-07-25 10:57 ` Thierry Reding
2016-07-21 15:12 ` Jon Hunter
2016-07-21 21:41 ` Mirza Krak
2016-07-25 11:14 ` Thierry Reding
2016-07-25 12:17 ` Mirza Krak
2016-07-25 13:41 ` Thierry Reding
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=20160725133922.GK21170@ulmo.ba.sec \
--to=thierry.reding@gmail$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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