On Thu, 20 Feb 2020 08:46:23 +0100 Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> wrote: > On Wed, 19 Feb 2020 23:13:36 +0300 > Sergei Shtylyov <sergei.shtylyov@xxxxxxxxxxxxxxxxxx> wrote: > > > > One way would be to extend spi_mem_op to support above template along > > > with a new field to distinguish SPI NOR vs HyperFlash protocol. HyperBus > > > core can then register a spi_device and use spi-mem ops to talk to > > > controller driver. > > > > We have discussed this idea with Mark Brown, the SPI maintainer, and > > he wasn't terribly impressed (I've invited him to #mtd -- his nick is > > broonie and mine is headless, I'm also adding him to CC:). > > > > > So, I suggest making Renesas RPC-IF backend a full fledged spi-mem > > > driver (instead of driver/memory) and use extended spi_mem_op to support > > > HyperFlash. > > > > I don't think cramming support for the different flash busses into > > the SPI drivers is a good idea... > > That's what I thought at first (SPI and Hyperflash seemed different > enough to not merge them), then I had a look at Vignesh's HyperFlash > presentation [1], and there's one aspect that made me reconsider this > PoV. Slide 25 (xSPI compliant HyperFlash): having devices bouncing from > one driver to another depending on the mode they operate in is likely to > be painful to handle. Not to mention that Octo+DTR is similar to > HyperBus from an HW PoV (at the PHY level, they both have CS, CLK, > DQS/RWDS, DQ/IO[0:7] signals, only the protocol differs). This doc [2] also shows the similarities between HyperBus and Octal+DTR-SPI. > > [1]https://elinux.org/images/3/38/HBMC-v1.pdf [2]https://www.st.com/content/ccc/resource/technical/document/application_note/group0/91/dd/af/52/e1/d3/48/8e/DM00407776/files/DM00407776.pdf/jcr:content/translations/en.DM00407776.pdf ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/