Re: [RFC 3/6] dt/bindings: Add bindings for Tegra20/30 NOR bus driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




2016-07-25 13:59 GMT+02:00 Thierry Reding <thierry.reding@xxxxxxxxx>:
> 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.


Best regards,
Mirza
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux