On 13/12/18 8:31 AM, Tom Rini wrote:
On Thu, Dec 13, 2018 at 04:51:56AM +0530, Jagan Teki wrote:
On Thu, Dec 13, 2018 at 4:26 AM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 13, 2018 at 02:01:15AM +0530, Jagan Teki wrote:
On Wed, Dec 12, 2018 at 11:10 PM Vignesh R vigneshr@ti.com wrote:
Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space. Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that. So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.
Signed-off-by: Vignesh R vigneshr@ti.com
drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++ include/linux/mtd/cfi.h | 32 + include/linux/mtd/spi-nor.h | 421 +++++
Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.
- no __UBOOT ifdef
What? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync.
Several areas, but not spi-flash or spi. ie what I'm maintaining from long. I'm always looking for persistent code to be IN. May be it can't be syn-cable but we can work it more maintainable in u-boot way like other opensource project. Well this is my experience with the U-Boot project development so-far, I never ever hold any features but if u-boot need the same features, better to add then like new code.
I think that for flash related SPI we should follow the lead of the rest of MTD/NAND and adapt the kernel code.
I have no hard preference, although I prefer MTD conventions wrt __UBOOT__ and file names as this code resides under drivers/mtd/.