From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jagan Teki Date: Tue, 18 Dec 2018 18:02:42 +0530 Subject: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework In-Reply-To: References: <20181212173228.12281-1-vigneshr@ti.com> <1cd66c4d-d37b-e48b-0a6a-6037e1d255f8@ti.com> 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 Sat, Dec 15, 2018 at 9:13 PM Vignesh R wrote: > > >>> 2) For BAR support, lets place it as it is and support via spi-nor > >> > >> Problem is, it not desirable to use BAR as default because its not > >> stateless and does not work with all flash parts. OTOH, it seems like 4 > >> byte addressing (stateless dedicated opcode or with enter/exit 4 byte > >> mode) seems to be standard. > >> Also, Linux doesn't support BAR and haven't seen any request for BAR > >> support. Why support additional feature and burden of maintaining when > >> it may not be needed. > >> > >> But if you insist, I just have to add BAR support back. > > > > It's not about insistence, ie how we support since from long and > > u-boot bootloader project does in general. bootloader can be some > > certain boot difference functionalities unlike Linux, it's better not > > to compare u-boot with Linux in all cases. > > > > Example we have SPI_TX_BYTE which usually not supported in Linux. > > Since it's ich controller specific and it require for bootloader to do > > byte tx on that specific controller, so we supported. Same for the > > case with the BAR, this specific controller(or supported boards) has > > been in U-Boot since from long and they do upstream well. So we need > > to support BAR in any case or we can find any alternative to work the > > same functionalities. (we tried before but ended-up adding BAR) > > > How about this instead? > > Lets use 4 byte addressing opcodes as default for >16MB flashes. > But if CONFIG_SPI_FLASH_BAR is enabled then, spi-nor layer will use BAR > registers for >16MB access instead of 4 byte addressing. Yes, this can be normal approach. but what I'm trying to initiate here is if we have a generic kind of sanity check transfer for > 16MB flashes, then we can notify the controllers enable BAR to support > 16MiB. This way we can reduce the ifdefs on code, and if we handle BAR in better way to minimize the code eventually we even drop the CONFIG option. > I will remove SPI_FLASH_BAR from defconfigs from all boards expect those > controllers that really cannot handle 4 byte addressing. From a quick > glance it looks following controllers support only 3 byte addresses: > stm32_qspi.c > ich.c > fsl_qspi.c > renesas_rpc_spi.c > mtk_qspi.c I'm not sure whether all these support 4-byte addressing or not? since we don't have 4-byte on spi-flash they do use BAR for accessing > 16MiB, zynq_qspi is the key taker for this initially. > > So, except for boards with above controllers, I will remove > SPI_FLASH_BAR for all other boards. If there is a regression, then such > boards can go back to enabling CONFIG_SPI_FLASH_BAR. I think we can go the BAR code in flash as you mentioned with CONFIG option, and don't remove any CONFIG items from board configs then we can add sanity check patch on top of spi-nor changes and give warning to boards which never need BAR(ask them to drop CONFIG_BAR). This way transition look promising to move BAR to 4-byte addressing. > > AFAIU, above controller HWs(except ich perhaps) can support 4 byte > addressing but would need to move to spi-mem. Even if we move to spi-mem, but BAR need to handle it flash side. isn't it?