From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jagan Teki Date: Sat, 15 Dec 2018 20:12:53 +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> <2ab9c416-2d37-84a3-f7a3-83723763039c@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 7:29 PM Jagan Teki wrote: > > On Fri, Dec 14, 2018 at 10:12 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. > > > > > > > > > > > > But if we do that, could we please have a config option so that I can > > > > somehow ensure only 4 byte opcoses are used that don't change some > > > state > > > > in the chip? > > > > > > > > > > I am afraid BAR support would be the default as Jagan suggests not to > > > change existing behavior. You would have to disable SPI_FLASH_BAR to use > > > 4 Byte addressing opcodes. > > > > > > > > > Honestly, I don't like the idea of making BAR the default. Why can't we > > > go the Linux way and enable BAR (maybe then as default) for boards that > > > need it only? > > > > > > > Jagan, would that be acceptable? > > Better way to have some controller flag to check we go with 3-byte or > 4-byte addressing if flash > 16MiB. anyway let me give some time, will > come back for the better to way to go this. ofcourse CONFIG would > require if BAR handling code occupy more foot-print, but we have to > enable based some controller indication. another approach can be do some sanity transfer if the flash > 16MiB with 4-byte addressing failure can lead to enable BAR.