On Sat, Dec 15, 2018 at 7:29 PM Jagan Teki jagan@amarulasolutions.com wrote:
On Fri, Dec 14, 2018 at 10:12 PM Vignesh R vigneshr@ti.com wrote:
> 2) For BAR support, lets place it as it is and support viaspi-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.