From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vignesh R Date: Thu, 13 Dec 2018 17:14:05 +0530 Subject: [U-Boot] [PATCH 05/16] mtd: spi: Port SPI NOR framework from Linux In-Reply-To: <20181213030122.GV8702@bill-the-cat> References: <20181212173228.12281-1-vigneshr@ti.com> <20181212173228.12281-6-vigneshr@ti.com> <20181212225625.GF8702@bill-the-cat> <20181213030122.GV8702@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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 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 >>>>> --- >>>>> 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/. -- Regards Vignesh