2016-07-25 15:39 GMT+02:00 Thierry Reding [off-list ref]:

On Mon, Jul 25, 2016 at 03:30:34PM +0200, Mirza Krak wrote:

quoted

2016-07-25 13:59 GMT+02:00 Thierry Reding [off-list ref]:

quoted

On Thu, Jul 21, 2016 at 10:56:44AM +0100, Jon Hunter wrote:

quoted

quoted

quoted

+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?

quoted

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.

Yes, and in some cases you can not "program" the map as it is fixed in hardware.