Hi Vignesh, On Mon, 8 Oct 2018 21:06:02 +0530 Vignesh R <vigneshr@xxxxxx> wrote: > Hi Boris, > > Sorry I missed this mail. > > On Thursday 04 October 2018 04:47 PM, Boris Brezillon wrote: > > On Thu, 4 Oct 2018 16:05:36 +0530 > > Vignesh R <vigneshr@xxxxxx> wrote: > > > >>>> > >>>> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > >>>> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > >>> > >>> On a slightly different topic, do you plan to convert the Cadence > >>> driver to spi-mem? And if you don't, is it because you don't have time > >>> or because some features are missing in spi-mem (I remember you > >>> mentioned a few things back when you were reviewing the spi-mem series)? > >>> > >> > >> I do not have plans to convert cadence QSPI driver to spi-mem yet, > >> mainly due to lack of time. Also, not sure if original author Marek and > >> other altera people are okay with that. > >> > >> I see couple of issues in the way of conversion: > >> 1. I would wait to know what direction would direct mapping APIs[1] go > >> before starting spi-mem conversion for Cadence QSPI driver. Else, we > >> have may to re write again if direct mapping APIs are merged. > > > > I'd suggest reviewing the proposal I posted so that you can influence > > the design of this new API ;-). > > > > I did take a look and proposal seems fine. Will try to prototype and > test cadence QSPI driver with these. Thanks for the patches! That's great news! Let me know how it goes, and don't hesitate to ask if you have any questions. > > > >> 2. New Cadence OSPI IP has an integrated PHY to support high throughput > >> OSPI flashes operating up 200MHz in Octal DDR mode. In order to work > >> with such flashes, PHY DLLs need to be calibrated. Highly simplified > >> calibration sequence is as below(See [2] for actual sequence): > >> -Read flash ID at low speed and store it. > >> -Enable PHY and set DLLs to a defined initial value > >> -Increment RX DLL value > >> -Read flash ID and check for correctness of data read > >> -repeat above two steps until a band of passing values is obtained for > >> RX DLL where flash ID is correctly read. > >> -DLL needs to set to middle of the passing band. > > > > Is the Read ID operation hardcoded or do you just use it as a way to > > trigger predictable transfers on the IO bus? > > > > Just a way to trigger predictable data reads. Good. > > >> > >> I am trying to figure out how to fit this into the spi-mem framework as > >> controller would to need to store READ ID opcode and expected JEDEC ID > >> before starting calibration sequence. > > > > I think this should be split in 2: > > > > - the SPI NOR framework passing the operation to use to do the > > calibration (here a READ ID) > > - the SPI controller framework replaying the same operation with > > different DLL configs until it finds the best match > > > > So, it would basically be added as a new hook: > > > > int (*calibrate)(struct spi_mem *mem, > > const struct spi_mem_op *tmpl); > > > > and a new function provided by the spi-mem API > > > > int spi_mem_calibrate(struct spi_mem *mem, > > const struct spi_mem_op *tmpl); > > > > and calibration outcome would be somehow attached to the spi_mem > > object. > > > > This way we stay memory agnostic but still provide the necessary blocks > > at the spi-mem level to do such callibrations. > > > > Would that work? > > > > That would work and hopefully is not intrusive to spi-mem framework. > Okay. Don't hesitate to post a proposal along those lines and I'll try to review it. Thanks, Boris
