On Mon, Jul 25, 2016 at 02:09:18PM +0100, Jon Hunter wrote: > > On 25/07/16 13:10, Thierry Reding wrote: > > * PGP Signed by an unknown key > > > > On Thu, Jul 21, 2016 at 10:10:49PM +0200, Mirza Krak wrote: > >> 2016-07-21 11:56 GMT+02:00 Jon Hunter <jonathanh@xxxxxxxxxx>: > >>>> + > >>>> +The NOR controller supports a number of memory types, including synchronous NOR, > >>>> +asynchronous NOR, and other flash memories with similar interfaces, such as > >>>> +MuxOneNAND. One could also connect high speed devices like FPGAs, DSPs, > >>>> +CAN chips, Wi-Fi chips etc. > >>> > >>> Nit-pick ... the Tegra documentation refers to this controller as the > >>> GMI (general memory interface) or SNOR (sync-NOR) controller because it > >>> is not just limited to NOR as you mentioned. I see references to GMI in > >>> the Tegra pinctrl driver and so may be we should use this name. > >> > >> ACK. > >> > >> > >>>> +Required properties: > >>>> + > >>>> + - compatible: should be "nvidia,tegra20-nor", "nvidia,tegra30-nor" > >>> > >>> I see at least one difference at the register level between Tegra20 and > >>> Tegra30 and so I think this should be something like ... > >>> > >>> - compatible : Should contain one of the following: > >>> For Tegra20 must contain "nvidia,tegra20-gmi". > >>> For Tegra30 must contain "nvidia,tegra30-gmi". > >> > >> ACK. Just curious, which register was it? I only checked that they > >> have the same count of registers. > >> > >>>> + - nvidia,config: This property represents the SNOR_CONFIG_0 register. > >>> > >>> There is also a SNOR_MIO_CONFIG for the MIO address space and so I think > >>> that this should be nvidia,snor-config to be explicit. It might be nice > >>> to also add a "nvidia,mio-config" while you are at it as well, however, > >>> that could always be done later. If you do, then the > >>> "nvidia,snor-config" becomes optional depending on whether you are using > >>> the SNOR or MIO address space. > >> > >> ACK the nvidia,snor-config part, will though wait for further comments > >> regarding what to do with the config registers, break-out or keep it > >> is a one property / register. > >> > >> Regarding mio-config, not sure about if I would like to include that > >> part in this stage. If you feel strongly about this we can do it. If > >> it only comes to down to replicate the same configurations that we do > >> for SNOR to MIO then I do not see much of a problem, but would like > >> SNOR to be accepted and would not like the MIO part to halt this. But > >> then again this up to you guys. > > > > What's the difference between SNOR and MIO? Sorry if I'm being dense but > > a quick look around the internet didn't yield anything related. I'd be > > happy to read up if somebody can provide a link. > > I am not sure where this term MIO comes from (may be an NVIDIA term), > but from looking at the MIO_CONFIG register, it looks like a basic > 16/32-bit interface with configurable read/write strobe timing. Does not > support bursting or address/data multiplexing that the SNOR interface > does. So may be it is used for interfacing to external devices such as > FIFOs, UARTs, I2C expanders, etc. Yes, looks like some sort of parallel interface to connect external devices and make them act like MMIO. Perhaps MIO is supposed to be "memory I/O". I've found some vague references to MIO == multi-I/O, but that was always related to serial flash (essentially something like QSPI). Thierry
Attachment:
signature.asc
Description: PGP signature
