From: Vignesh R <vigneshr@ti.com> To: Boris Brezillon <boris.brezillon@bootlin.com> Cc: Marek Vasut <marek.vasut@gmail.com>, Rob Herring <robh+dt@kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Yogesh Gaur <yogeshnarayan.gaur@nxp.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>, Brian Norris <computersforpeace@gmail.com>, Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>, Tudor Ambarus <tudor.ambarus@microchip.com> Subject: Re: [PATCH 0/3] spi-nor: Add Octal SPI support Date: Mon, 8 Oct 2018 21:06:02 +0530 [thread overview] Message-ID: <e4af1014-2008-440c-a017-bb8e7e960d3b@ti.com> (raw) In-Reply-To: <20181004131732.4c9e2ae9@bbrezillon> 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@ti.com> 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! >> 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. >> >> 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. -- Regards Vignesh
WARNING: multiple messages have this Message-ID (diff)
From: vigneshr@ti.com (Vignesh R) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 0/3] spi-nor: Add Octal SPI support Date: Mon, 8 Oct 2018 21:06:02 +0530 [thread overview] Message-ID: <e4af1014-2008-440c-a017-bb8e7e960d3b@ti.com> (raw) In-Reply-To: <20181004131732.4c9e2ae9@bbrezillon> 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@ti.com> 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! >> 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. >> >> 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. -- Regards Vignesh
next prev parent reply other threads:[~2018-10-08 15:35 UTC|newest] Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-03 16:56 [PATCH 0/3] spi-nor: Add Octal SPI support Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-03 16:56 ` [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-04 6:51 ` Yogesh Narayan Gaur 2018-10-04 6:51 ` Yogesh Narayan Gaur 2018-10-04 7:39 ` Boris Brezillon 2018-10-04 7:39 ` Boris Brezillon 2018-10-04 8:47 ` Yogesh Narayan Gaur 2018-10-04 8:47 ` Yogesh Narayan Gaur 2018-10-04 9:10 ` Boris Brezillon 2018-10-04 9:10 ` Boris Brezillon 2018-10-04 9:10 ` Boris Brezillon 2018-10-04 10:38 ` Vignesh R 2018-10-04 10:38 ` Vignesh R 2018-10-04 10:38 ` Vignesh R 2018-10-04 9:45 ` Boris Brezillon 2018-10-04 9:45 ` Boris Brezillon 2018-10-04 9:45 ` Boris Brezillon 2018-10-04 11:12 ` Vignesh R 2018-10-04 11:12 ` Vignesh R 2018-10-04 11:12 ` Vignesh R 2018-10-04 11:27 ` Boris Brezillon 2018-10-04 11:27 ` Boris Brezillon 2018-10-04 11:27 ` Boris Brezillon 2018-10-03 16:56 ` [PATCH 2/3] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-15 19:11 ` Rob Herring 2018-10-15 19:11 ` Rob Herring 2018-10-15 19:11 ` Rob Herring 2018-10-03 16:56 ` [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-12-10 8:45 ` Boris Brezillon 2018-12-10 8:45 ` Boris Brezillon 2018-12-10 8:45 ` Boris Brezillon 2018-12-10 11:19 ` Vignesh R 2018-12-10 11:19 ` Vignesh R 2018-12-10 11:19 ` Vignesh R 2018-12-10 11:28 ` Boris Brezillon 2018-12-10 11:28 ` Boris Brezillon 2018-12-10 11:28 ` Boris Brezillon 2018-10-03 19:20 ` [PATCH 0/3] spi-nor: Add Octal SPI support Boris Brezillon 2018-10-03 19:20 ` Boris Brezillon 2018-10-04 10:35 ` Vignesh R 2018-10-04 10:35 ` Vignesh R 2018-10-04 10:35 ` Vignesh R 2018-10-04 11:17 ` Boris Brezillon 2018-10-04 11:17 ` Boris Brezillon 2018-10-04 11:17 ` Boris Brezillon 2018-10-08 15:36 ` Vignesh R [this message] 2018-10-08 15:36 ` Vignesh R 2018-10-12 8:52 ` Boris Brezillon 2018-10-12 8:52 ` Boris Brezillon 2018-12-09 8:47 ` Vignesh R 2018-12-09 8:47 ` Vignesh R 2018-12-09 8:47 ` Vignesh R 2018-12-10 8:45 ` Boris Brezillon 2018-12-10 8:45 ` Boris Brezillon 2018-12-10 8:45 ` Boris Brezillon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=e4af1014-2008-440c-a017-bb8e7e960d3b@ti.com \ --to=vigneshr@ti.com \ --cc=boris.brezillon@bootlin.com \ --cc=computersforpeace@gmail.com \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=marek.vasut@gmail.com \ --cc=robh+dt@kernel.org \ --cc=tudor.ambarus@microchip.com \ --cc=yogeshnarayan.gaur@nxp.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.