Re: [PATCH V8 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
From: Marek Vasut <hidden>
Date: 2016-02-06 07:42:38
On Thursday, February 04, 2016 at 06:30:27 PM, R, Vignesh wrote:
On 2/4/2016 4:55 PM, Marek Vasut wrote:quoted
On Thursday, February 04, 2016 at 08:38:47 AM, Vignesh R wrote:quoted
On 02/02/2016 02:43 AM, Marek Vasut wrote:quoted
On Monday, February 01, 2016 at 10:03:35 PM, Brian Norris wrote:quoted
On Wed, Jan 13, 2016 at 03:39:17AM +0100, Marek Vasut wrote:quoted
On Wednesday, January 13, 2016 at 03:26:08 AM, Rob Herring wrote:quoted
On Mon, Jan 11, 2016 at 05:34:45AM +0100, Marek Vasut wrote:[...]quoted
quoted
quoted
All these SoCs should be capable of tweaking the block to fit their needs by just the DT properties. I believe they differ only in the FIFO depth and sometimes someone is greedy and uses 4:16 CS multiplexer, which is an external passive component, but that's all. Would we need soc-specific compatible strings if this is the case?It's nice when most things can be supported with a small set of DT properties, as you've done. But IUIC, I think it's usually good practice to define and use SoC-specific (or maybe SoC family) compatible strings in the docs and DTS files, in addition to the generic one, in case there are future quirks that need to be handled. Note that you don't actually have to use these in the driver yet, but it's good to have a definition. So you can, today, have: foo@xxxx { compatible = "ti,baz-12345", "cdns,qspi-nor"; ... }; And we have the option to pick up "ti,baz-12345" in the Linux driver *if needed.*The support for TI SoC that has this IP is not in upstream yet. I will add TI-specific compatible later. It will be: foo@xxxx { compatible = "ti,k2g-qspi", "cdns,qspi-nor"; ... };Do you expect any specifics which cannot be handled by the current bindings btw?quoted
In my socfpga case, the compatible strings will be probably:Yeah, there is delay(of few ns) required between writing to INDIRECTWR_START bit and actually writing data to flash(i.e writesl() call). This is specific to TI K2G SoC and needs to be tied to the new binding.
Can't you somehow poll the hardware to check whether or not it's ready instead of adding some random delay ? Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html