From: "Jin, Le" <le.jin@siemens.com> To: "Kiszka, Jan" <jan.kiszka@siemens.com>, Vignesh Raghavendra <vigneshr@ti.com>, Tudor Ambarus <tudor.ambarus@microchip.com>, Mark Brown <broonie@kernel.org> Cc: Boris Brezillon <bbrezillon@kernel.org>, Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>, "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>, "simon.k.r.goldschmidt@gmail.com" <simon.k.r.goldschmidt@gmail.com>, "dinguyen@kernel.org" <dinguyen@kernel.org>, "marex@denx.de" <marex@denx.de> Subject: RE: [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel Date: Tue, 25 Aug 2020 03:12:20 +0000 [thread overview] Message-ID: <84209e7d08e24362bdf7ccbab1c46e60@siemens.com> (raw) In-Reply-To: <dbba9f0c-4621-2d58-8fb8-4cbe788558f9@siemens.com> Hello Jan, The flash on our board is Winbond W25Q128JV. Best Regards, Le Jin -----Original Message----- From: Kiszka, Jan (CT RDA IOT SES-DE) <jan.kiszka@siemens.com> Sent: Monday, August 24, 2020 8:49 PM To: Vignesh Raghavendra <vigneshr@ti.com>; Tudor Ambarus <tudor.ambarus@microchip.com>; Mark Brown <broonie@kernel.org>; Jin, Le (RC-CN DI FA R&D SW) <le.jin@siemens.com> Cc: Boris Brezillon <bbrezillon@kernel.org>; Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>; linux-mtd@lists.infradead.org; linux-kernel@vger.kernel.org; linux-spi@vger.kernel.org; simon.k.r.goldschmidt@gmail.com; dinguyen@kernel.org; marex@denx.de Subject: Re: [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel On 24.08.20 13:45, Vignesh Raghavendra wrote: > > > On 8/22/20 11:35 PM, Jan Kiszka wrote: >> On 01.06.20 09:04, Vignesh Raghavendra wrote: >>> dma_request_chan_by_mask() can throw EPROBE_DEFER if DMA provider is >>> not yet probed. Currently driver just falls back to using PIO mode >>> (which is less efficient) in this case. Instead return probe >>> deferral error as is so that driver will be re probed once DMA >>> provider is available. >>> >>> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> >>> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> >>> --- > [...] >>> >>> static const struct spi_nor_controller_ops cqspi_controller_ops = { >>> @@ -1269,8 +1274,11 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) >>> dev_dbg(nor->dev, "using direct mode for %s\n", >>> mtd->name); >>> >>> - if (!cqspi->rx_chan) >>> - cqspi_request_mmap_dma(cqspi); >>> + if (!cqspi->rx_chan) { >>> + ret = cqspi_request_mmap_dma(cqspi); >>> + if (ret == -EPROBE_DEFER) >>> + goto err; >>> + } >>> } >>> } >>> >>> >> >> This seem to break reading the SPI flash on our IOT2050 [1] (didn't >> test the eval board yet). >> >> Without that commit, read happens via PIO, and that works. With the >> commit, the pattern >> >> with open("out.bin", "wb") as out: >> pos = 0 >> while pos < 2: >> with open("/dev/mtd0", "rb") as mtd: >> mtd.seek(pos * 0x10000) >> out.write(mtd.read(0x10000)) >> pos += 1 >> >> gives the wrong result for the second block while > > Interesting... Could you please explain wrong result? Is the data move > around or completely garbage? It looks like some stripes contain data from other parts of the flash or kernel RAM. It's not just garbage, there are readable strings included. > > Does this fail even on AM654 EVM? Could you share full script for me > to test locally? The scripts are complete (python). Just binary-diff the outputs. I'll try on the EVM later. > > What is the flash on the board? Le, could you answer that more precisely than I could? Thanks, Jan > >> >> with open("out2.bin", "wb") as out: >> with open("/dev/mtd0", "rb") as mtd: >> out.write(mtd.read(0x20000)) >> >> (or "mtd_debug read") is fine. >> >> What could be the reason? Our DTBs and k3-am654-base-board.dtb had >> some deviations /wrt the ospi node, but aligning ours to the base >> board made no difference. >> >> Jan >> >> [1] https://github.com/siemens/linux/commits/jan/iot2050 >> -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
WARNING: multiple messages have this Message-ID (diff)
From: "Jin, Le" <le.jin@siemens.com> To: "Kiszka, Jan" <jan.kiszka@siemens.com>, Vignesh Raghavendra <vigneshr@ti.com>, Tudor Ambarus <tudor.ambarus@microchip.com>, Mark Brown <broonie@kernel.org> Cc: "marex@denx.de" <marex@denx.de>, Boris Brezillon <bbrezillon@kernel.org>, "dinguyen@kernel.org" <dinguyen@kernel.org>, "simon.k.r.goldschmidt@gmail.com" <simon.k.r.goldschmidt@gmail.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>, Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>, "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org> Subject: RE: [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel Date: Tue, 25 Aug 2020 03:12:20 +0000 [thread overview] Message-ID: <84209e7d08e24362bdf7ccbab1c46e60@siemens.com> (raw) In-Reply-To: <dbba9f0c-4621-2d58-8fb8-4cbe788558f9@siemens.com> Hello Jan, The flash on our board is Winbond W25Q128JV. Best Regards, Le Jin -----Original Message----- From: Kiszka, Jan (CT RDA IOT SES-DE) <jan.kiszka@siemens.com> Sent: Monday, August 24, 2020 8:49 PM To: Vignesh Raghavendra <vigneshr@ti.com>; Tudor Ambarus <tudor.ambarus@microchip.com>; Mark Brown <broonie@kernel.org>; Jin, Le (RC-CN DI FA R&D SW) <le.jin@siemens.com> Cc: Boris Brezillon <bbrezillon@kernel.org>; Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>; linux-mtd@lists.infradead.org; linux-kernel@vger.kernel.org; linux-spi@vger.kernel.org; simon.k.r.goldschmidt@gmail.com; dinguyen@kernel.org; marex@denx.de Subject: Re: [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel On 24.08.20 13:45, Vignesh Raghavendra wrote: > > > On 8/22/20 11:35 PM, Jan Kiszka wrote: >> On 01.06.20 09:04, Vignesh Raghavendra wrote: >>> dma_request_chan_by_mask() can throw EPROBE_DEFER if DMA provider is >>> not yet probed. Currently driver just falls back to using PIO mode >>> (which is less efficient) in this case. Instead return probe >>> deferral error as is so that driver will be re probed once DMA >>> provider is available. >>> >>> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> >>> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> >>> --- > [...] >>> >>> static const struct spi_nor_controller_ops cqspi_controller_ops = { >>> @@ -1269,8 +1274,11 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) >>> dev_dbg(nor->dev, "using direct mode for %s\n", >>> mtd->name); >>> >>> - if (!cqspi->rx_chan) >>> - cqspi_request_mmap_dma(cqspi); >>> + if (!cqspi->rx_chan) { >>> + ret = cqspi_request_mmap_dma(cqspi); >>> + if (ret == -EPROBE_DEFER) >>> + goto err; >>> + } >>> } >>> } >>> >>> >> >> This seem to break reading the SPI flash on our IOT2050 [1] (didn't >> test the eval board yet). >> >> Without that commit, read happens via PIO, and that works. With the >> commit, the pattern >> >> with open("out.bin", "wb") as out: >> pos = 0 >> while pos < 2: >> with open("/dev/mtd0", "rb") as mtd: >> mtd.seek(pos * 0x10000) >> out.write(mtd.read(0x10000)) >> pos += 1 >> >> gives the wrong result for the second block while > > Interesting... Could you please explain wrong result? Is the data move > around or completely garbage? It looks like some stripes contain data from other parts of the flash or kernel RAM. It's not just garbage, there are readable strings included. > > Does this fail even on AM654 EVM? Could you share full script for me > to test locally? The scripts are complete (python). Just binary-diff the outputs. I'll try on the EVM later. > > What is the flash on the board? Le, could you answer that more precisely than I could? Thanks, Jan > >> >> with open("out2.bin", "wb") as out: >> with open("/dev/mtd0", "rb") as mtd: >> out.write(mtd.read(0x20000)) >> >> (or "mtd_debug read") is fine. >> >> What could be the reason? Our DTBs and k3-am654-base-board.dtb had >> some deviations /wrt the ospi node, but aligning ours to the base >> board made no difference. >> >> Jan >> >> [1] https://github.com/siemens/linux/commits/jan/iot2050 >> -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-08-25 3:18 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-01 7:04 [RESEND PATCH v3 0/8] mtd: spi-nor: Move cadence-qaudspi to spi-mem framework Vignesh Raghavendra 2020-06-01 7:04 ` Vignesh Raghavendra 2020-06-01 7:04 ` [RESEND PATCH v3 1/8] mtd: spi-nor: cadence-quadspi: Make driver independent of flash geometry Vignesh Raghavendra 2020-06-01 7:04 ` Vignesh Raghavendra 2020-06-01 7:04 ` [RESEND PATCH v3 2/8] mtd: spi-nor: cadence-quadspi: Provide a way to disable DAC mode Vignesh Raghavendra 2020-06-01 7:04 ` Vignesh Raghavendra 2020-06-01 7:04 ` [RESEND PATCH v3 3/8] mtd: spi-nor: cadence-quadspi: Don't initialize rx_dma_complete on failure Vignesh Raghavendra 2020-06-01 7:04 ` Vignesh Raghavendra 2020-06-01 7:04 ` [RESEND PATCH v3 4/8] mtd: spi-nor: cadence-quadspi: Fix error path on failure to acquire reset lines Vignesh Raghavendra 2020-06-01 7:04 ` Vignesh Raghavendra 2020-06-01 7:04 ` [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel Vignesh Raghavendra 2020-06-01 7:04 ` Vignesh Raghavendra 2020-08-22 18:05 ` Jan Kiszka 2020-08-22 18:05 ` Jan Kiszka 2020-08-24 11:45 ` Vignesh Raghavendra 2020-08-24 11:45 ` Vignesh Raghavendra 2020-08-24 12:49 ` Jan Kiszka 2020-08-24 12:49 ` Jan Kiszka 2020-08-24 17:20 ` Jan Kiszka 2020-08-24 17:20 ` Jan Kiszka 2020-08-26 10:12 ` Jan Kiszka 2020-08-26 10:12 ` Jan Kiszka 2020-08-26 12:18 ` Vignesh Raghavendra 2020-08-26 12:18 ` Vignesh Raghavendra 2020-08-26 13:31 ` Jan Kiszka 2020-08-26 13:31 ` Jan Kiszka 2020-08-27 7:04 ` Vignesh Raghavendra 2020-08-27 7:04 ` Vignesh Raghavendra 2020-08-25 3:12 ` Jin, Le [this message] 2020-08-25 3:12 ` Jin, Le 2020-06-01 7:04 ` [RESEND PATCH v3 6/8] mtd: spi-nor: cadence-quadspi: Drop redundant WREN in erase path Vignesh Raghavendra 2020-06-01 7:04 ` Vignesh Raghavendra 2020-06-01 7:04 ` [RESEND PATCH v3 7/8] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework Vignesh Raghavendra 2020-06-01 7:04 ` Vignesh Raghavendra 2020-08-24 5:55 ` Jan Kiszka 2020-08-24 5:55 ` Jan Kiszka 2020-08-24 11:44 ` Vignesh Raghavendra 2020-08-24 11:44 ` Vignesh Raghavendra 2020-08-24 12:04 ` Boris Brezillon 2020-08-24 12:04 ` Boris Brezillon 2020-08-24 13:52 ` Jan Kiszka 2020-08-24 13:52 ` Jan Kiszka 2020-08-24 12:06 ` Jan Kiszka 2020-08-24 12:06 ` Jan Kiszka 2020-06-01 7:04 ` [RESEND PATCH v3 8/8] spi: Move cadence-quadspi driver to drivers/spi/ Vignesh Raghavendra 2020-06-01 7:04 ` Vignesh Raghavendra 2020-06-19 10:57 ` [RESEND PATCH v3 0/8] mtd: spi-nor: Move cadence-qaudspi to spi-mem framework Mark Brown 2020-06-19 10:57 ` Mark Brown 2020-06-19 11:47 ` Tudor.Ambarus 2020-06-19 11:47 ` Tudor.Ambarus 2020-06-19 15:17 ` Mark Brown 2020-06-19 15:17 ` Mark Brown 2020-06-26 9:25 ` Tudor.Ambarus 2020-06-26 9:25 ` Tudor.Ambarus 2020-06-19 13:28 ` Mark Brown 2020-06-19 13:28 ` Mark Brown
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=84209e7d08e24362bdf7ccbab1c46e60@siemens.com \ --to=le.jin@siemens.com \ --cc=bbrezillon@kernel.org \ --cc=broonie@kernel.org \ --cc=dinguyen@kernel.org \ --cc=jan.kiszka@siemens.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=linux-spi@vger.kernel.org \ --cc=marex@denx.de \ --cc=simon.k.r.goldschmidt@gmail.com \ --cc=tudor.ambarus@microchip.com \ --cc=vadivel.muruganx.ramuthevar@linux.intel.com \ --cc=vigneshr@ti.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.