Re: [PATCH 11/11] soc: ti: k3-socinfo: Add entry for AM64 SoC family
On 10/1/20 12:12 PM, Peter Ujfalusi wrote:
> Hi Grygorii,
>
> On 30/09/2020 16.56, Grygorii Strashko wrote:
>>
>>
>> On 28/09/2020 11:34, Peter Ujfalusi wrote:
>>> It's JTAG PARTNO is 0xBB38.
>>>
>>> Signed-off-by: Peter Ujfalusi
>>> ---
>>> drivers/soc/ti/k3-socinfo.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c
>>> index bbbc2d2b7091..a14ec68846dd 100644
>>> --- a/drivers/soc/ti/k3-socinfo.c
>>> +++ b/drivers/soc/ti/k3-socinfo.c
>>> @@ -40,6 +40,7 @@ static const struct k3_soc_id {
>>> { 0xBB5A, "AM65X" },
>>> { 0xBB64, "J721E" },
>>> { 0xBB6D, "J7200" },
>>> + { 0xBB38, "AM64" }
>>
>> Shouldn't it be AM64X
>
> Good point, I'll fix this up and then the DMA series.
>
> While here, what do you think: should we keep the DMA compatibles as I
> have them in v1 (am64-dmss-bcdma and am64-dmss-pktdma):
> https://lore.kernel.org/lkml/20200930091412.8020-10-peter.ujfal...@ti.com/
> https://lore.kernel.org/lkml/20200930091412.8020-11-peter.ujfal...@ti.com/
>
> or change them to am64x-dmss-* ?
>
> I'll ask Rob on the binding doc patches as well.
As long as differences within the family are discoverable by some other
means, wild chars may be okay. See one of Rob's earlier responses:
https://linuxlists.cc/l/1/linux-kernel/t/3311057/(patch_1_2)_dt-bindings:_ptp:_add_binding_doc_for_idt_clockmatrix_based_ptp_clock
Regards
Vignesh
Re: [RESEND PATCH 1/2] mtd: spi-nor: do not touch TB bit without SPI_NOR_HAS_TB
On 9/30/20 6:37 PM, Ivan Mikhaylov wrote: > On Wed, 2020-09-30 at 15:06 +0530, Vignesh Raghavendra wrote: >> >> On 9/21/20 4:54 PM, Ivan Mikhaylov wrote: >>> Some chips like macronix don't have TB(Top/Bottom protection) >>> bit in the status register. Do not write tb_mask inside status >>> register, unless SPI_NOR_HAS_TB is present for the chip. >>> >> >> Not entirely accurate.. Macronix chips have TB bit in config register >> and is OTP and hence should not be touched ideally... >> >> You still need to "read" that bit to determine actual scheme (Top vs >> Bottom). This is needs to be done before 2/2 enables SPI_NOR_HAS_LOCK >> flag for macronix flashes. > > Vignesh, that's the point about this commit to generalize this part about TB > bit > plus there is already exist SPI_NOR_HAS_TB flag which representing state of TB > existence. I didn't add any support for macronix's TB bit, that's true but > that's enough to make macronix chips able to use lock mechanism with default > 'use_top' or any other chips which doesn't have TB bit. Right, but 2/2 "enables" locking mechanism for Macronix flashes. Therefore its necessary to take TB bit into account so that implementation is correct. What if OTP bit is set as "use_bottom"? Although this is non default, we need to take care of this case for correctness. > >> I guess macronix does not support SR_SRWD right? This needs special >> treatment as well. > > It does support SR_SRWD as well. No need any special treatment here. > I did not find it in one Macronix datasheet at least: https://www.macronix.com/Lists/Datasheet/Attachments/7902/MX25L25673G,%203V,%20256Mb,%20v1.6.pdf Are you sure all Macronix flashes support SRWD? > Thanks. >
Re: [PATCH v3] mtd: spi-nor: keep lock bits if they are non-volatile
On 3/27/20 9:29 PM, Michael Walle wrote:
> Traditionally, linux unlocks the whole flash because there are legacy
> devices which has the write protections bits set by default at startup.
> If you actually want to use the flash protection bits, eg. because there
> is a read-only part for a bootloader, this automatic unlocking is
> harmful. If there is no hardware write protection in place (usually
> called WP#), a startup of the kernel just discards this protection.
>
[...]
> Further, the commit 3e0930f109e76 ("mtd: spi-nor: Rework the disabling of
> block write protection") expanded the unlock_all() feature to ANY flash
> which supports locking.
>
Appreciate the detail commit log.
> Signed-off-by: Michael Walle
> ---
> changes since v2:
> - add Kconfig option to be able to retain legacy behaviour
> - rebased the patch due to the spi-nor rewrite
> - dropped the Fixes: tag, it doens't make sense after the spi-nor rewrite
> - mention commit 3e0930f109e76 which further modified the unlock
>behaviour.
>
> changes since v1:
> - completely rewrote patch, the first version used a device tree flag
>
> drivers/mtd/spi-nor/Kconfig | 35 +
> drivers/mtd/spi-nor/atmel.c | 24 +---
> drivers/mtd/spi-nor/core.c | 44 -
> drivers/mtd/spi-nor/core.h | 6 +
> drivers/mtd/spi-nor/esmt.c | 6 ++---
> drivers/mtd/spi-nor/intel.c | 6 ++---
> drivers/mtd/spi-nor/sst.c | 21 +-
> include/linux/mtd/spi-nor.h | 6 +
> 8 files changed, 114 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 6e816eafb312..647de17c81e2 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -24,6 +24,41 @@ config MTD_SPI_NOR_USE_4K_SECTORS
> Please note that some tools/drivers/filesystems may not work with
> 4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
>
> +choice
> + prompt "Write protection at boot"
> + default MTD_SPI_NOR_WP_DISABLE
These choice control how BP0-X bits are manipulated on boot. Hence, to
be consistent should use Block Protection (BP) terminology throughout.
This would also be inline with most flash datasheets which also use term BP
> +
> +config MTD_SPI_NOR_WP_DISABLE
> + bool "Disable WP on any flashes (legacy behaviour)"
> + help
> + This option disables the write protection on any SPI flashes at
> + boot-up.
> +
> + Don't use this if you intent to use the write protection of your
> + SPI flash. This is only to keep backwards compatibility.
> +
> +config MTD_SPI_NOR_WP_DISABLE_ON_VOLATILE
> + bool "Disable WP on flashes w/ volatile protection bits"
> + help
> + Some SPI flashes have volatile block protection bits, ie. after a
> + power-up or a reset the flash is write protected by default.
> +
> + This option disables the write protection for these kind of flashes
> + while keeping it enabled for any other SPI flashes which have
> + non-volatile block protection bits.
> +
> + If you are unsure, select this option.
> +
> +config MTD_SPI_NOR_WP_KEEP
> + bool "Keep write protection as is"
> + help
> + If you select this option the write protection of any SPI flashes
> + will not be changed. If your flash is write protected or will be
> + automatically write protected after power-up you have to manually
> + unlock it before you are able to write to it.
> +
> +endchoice
> +
> source "drivers/mtd/spi-nor/controllers/Kconfig"
>
> endif # MTD_SPI_NOR
[...]
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 6f2f6b27173f..9a33c023717f 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -26,6 +26,7 @@ enum spi_nor_option_flags {
> SNOR_F_HAS_SR_TB_BIT6 = BIT(11),
> SNOR_F_HAS_4BIT_BP = BIT(12),
> SNOR_F_HAS_SR_BP3_BIT6 = BIT(13),
> + SNOR_F_NEED_UNPROTECT = BIT(14),
> };
>
> struct spi_nor_read_command {
> @@ -311,6 +312,11 @@ struct flash_info {
>* BP3 is bit 6 of status register.
>* Must be used with SPI_NOR_4BIT_BP.
>*/
> +#define SPI_NOR_UNPROTECTBIT(19) /*
> + * Flash is write-protected after
> + * power-up and needs a global
> + * unprotect.
> + */
>
It would be better to name the flag to indicate BP bits are volatile or
powers up locked instead of SPI_NOR_UNPROTECT. This makes it easier to
understand what this flag means wrt flash HW feature. Maybe:
SPI_NOR_LOCKED_ON_POWER_UP or SPI_NOR_BP_IS_VOLATILE
Reset looks fine to me
[...]
Regards
Vignesh
Re: [RESEND PATCH 2/2] mtd: spi-nor: enable lock interface for macronix chips
Hi,
On 9/21/20 4:54 PM, Ivan Mikhaylov wrote:
> Add locks for whole macronix chip series with BP0-2 and BP0-3 bits.
>
> Tested with mx25l51245g(BP0-3).
Since you have only tested on flash that have 4bit BP, please don't
modify flashes that have 3bit BP. Lets be conservative and enable only
things that have been tested else we may end up with broken feature from
day 1.
Regards
Vignesh
>
> Signed-off-by: Ivan Mikhaylov
> ---
> drivers/mtd/spi-nor/macronix.c | 75 ++
> 1 file changed, 50 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
> index 96735d83c77c..80de43eb05d6 100644
> --- a/drivers/mtd/spi-nor/macronix.c
> +++ b/drivers/mtd/spi-nor/macronix.c
> @@ -37,53 +37,78 @@ static const struct flash_info macronix_parts[] = {
> /* Macronix */
> { "mx25l512e", INFO(0xc22010, 0, 64 * 1024, 1, SECT_4K) },
> { "mx25l2005a", INFO(0xc22012, 0, 64 * 1024, 4, SECT_4K) },
> - { "mx25l4005a", INFO(0xc22013, 0, 64 * 1024, 8, SECT_4K) },
> - { "mx25l8005", INFO(0xc22014, 0, 64 * 1024, 16, 0) },
> - { "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32, SECT_4K) },
> - { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, SECT_4K) },
> - { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64, SECT_4K) },
> - { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, SECT_4K) },
> - { "mx25u2033e", INFO(0xc22532, 0, 64 * 1024, 4, SECT_4K) },
> + { "mx25l4005a", INFO(0xc22013, 0, 64 * 1024, 8,
> + SECT_4K | SPI_NOR_HAS_LOCK) },
> + { "mx25l8005", INFO(0xc22014, 0, 64 * 1024, 16,
> + SPI_NOR_HAS_LOCK) },
> + { "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25u2033e", INFO(0xc22532, 0, 64 * 1024, 4,
> + SECT_4K | SPI_NOR_HAS_LOCK) },
> { "mx25u3235f", INFO(0xc22536, 0, 64 * 1024, 64,
> SECT_4K | SPI_NOR_DUAL_READ |
> - SPI_NOR_QUAD_READ) },
> - { "mx25u4035", INFO(0xc22533, 0, 64 * 1024, 8, SECT_4K) },
> - { "mx25u8035", INFO(0xc22534, 0, 64 * 1024, 16, SECT_4K) },
> - { "mx25u6435f", INFO(0xc22537, 0, 64 * 1024, 128, SECT_4K) },
> - { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
> - { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
> + SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK |
> + SPI_NOR_4BIT_BP) },
> + { "mx25u4035", INFO(0xc22533, 0, 64 * 1024, 8,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25u8035", INFO(0xc22534, 0, 64 * 1024, 16,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25u6435f", INFO(0xc22537, 0, 64 * 1024, 128,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256,
> + SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256,
> + SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> { "mx25r3235f", INFO(0xc22816, 0, 64 * 1024, 64,
> SECT_4K | SPI_NOR_DUAL_READ |
> - SPI_NOR_QUAD_READ) },
> + SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK |
> + SPI_NOR_4BIT_BP) },
> { "mx25u12835f", INFO(0xc22538, 0, 64 * 1024, 256,
> SECT_4K | SPI_NOR_DUAL_READ |
> - SPI_NOR_QUAD_READ) },
> + SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK |
> + SPI_NOR_4BIT_BP) },
> { "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512,
> - SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
> + SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> + SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP)
> .fixups = _fixups },
> { "mx25u25635f", INFO(0xc22539, 0, 64 * 1024, 512,
> - SECT_4K | SPI_NOR_4B_OPCODES) },
> + SECT_4K | SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK |
> + SPI_NOR_4BIT_BP) },
> { "mx25u51245g", INFO(0xc2253a, 0, 64 * 1024, 1024,
> SECT_4K | SPI_NOR_DUAL_READ |
> - SPI_NOR_QUAD_READ
Re: [RESEND PATCH 1/2] mtd: spi-nor: do not touch TB bit without SPI_NOR_HAS_TB
On 9/21/20 4:54 PM, Ivan Mikhaylov wrote: > Some chips like macronix don't have TB(Top/Bottom protection) > bit in the status register. Do not write tb_mask inside status > register, unless SPI_NOR_HAS_TB is present for the chip. > Not entirely accurate.. Macronix chips have TB bit in config register and is OTP and hence should not be touched ideally... You still need to "read" that bit to determine actual scheme (Top vs Bottom). This is needs to be done before 2/2 enables SPI_NOR_HAS_LOCK flag for macronix flashes. > Signed-off-by: Ivan Mikhaylov > --- > drivers/mtd/spi-nor/core.c | 22 -- > 1 file changed, 16 insertions(+), 6 deletions(-) > > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c > index 0369d98b2d12..f9853dd566dc 100644 > --- a/drivers/mtd/spi-nor/core.c > +++ b/drivers/mtd/spi-nor/core.c > @@ -1735,13 +1735,18 @@ static int spi_nor_sr_lock(struct spi_nor *nor, > loff_t ofs, uint64_t len) > return -EINVAL; > } > > - status_new = (status_old & ~mask & ~tb_mask) | val; > + if (nor->flags & SNOR_F_HAS_SR_TB) > + status_new = (status_old & ~mask & ~tb_mask) | val; > + else > + status_new = (status_old & ~mask) | val; > > /* Disallow further writes if WP pin is asserted */ > status_new |= SR_SRWD; > I guess macronix does not support SR_SRWD right? This needs special treatment as well. So either, macronix.c should implements its own locking ops or convert this function in to more generic library so that its suitable to be called from macronix.c file while hiding vendor specific stuff in that driver, Regards Vignesh
Re: [PATCH] mtd: spi-nor: Prefer asynchronous probe
On Wed, 2 Sep 2020 16:00:40 -0700, Douglas Anderson wrote: > On my system the spi_nor_probe() took ~6 ms at bootup. That's not a > lot, but every little bit adds up to a slow bootup. While we can get > this out of the boot path by making it a module, there are times where > it is convenient (or even required) for this to be builtin the kernel. > Let's set that we prefer async probe so that we don't block other > drivers from probing while we are probing. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-nor/next, thanks! [1/1] mtd: spi-nor: Prefer asynchronous probe https://git.kernel.org/mtd/c/03edda0e1e -- Regards Vignesh
Re: [RESEND PATCH v4] mtd: spi-nor: winbond: Add support for w25q64jwm
On Mon, 28 Sep 2020 14:06:31 +0800, Ikjoon Jang wrote:
> Add support Winbond w25q{64,128,256}jwm which are identical to existing
> w25q32jwm except for their sizes.
>
> This was tested with w25q64jwm, basic erase/write/readback and
> lock/unlock both lower/upper blocks were okay.
>
> Signed-off-by: i...@chromium.org
> Signed-off-by: Xingyu Wu
> Signed-off-by: ST Lin
> Tested-by: Nicolas Boichat
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
spi-nor/next, thanks!
[1/1] mtd: spi-nor: winbond: Add support for w25q64jwm
https://git.kernel.org/mtd/c/6eedfd858f
--
Regards
Vignesh
Re: [PATCH] mtd: spi-nor: macronix: Add SECT_4K to mx25l12805d
On Tue, 15 Sep 2020 12:06:23 +0200, Robert Marko wrote: > According to the mx25l12805d datasheet it supports using 4K or 64K sectors. > So lets add the SECT_4K to enable 4K sector usage. > > Datasheet: > https://www.mxic.com.tw/Lists/Datasheet/Attachments/7321/MX25L12805D,%203V,%20128Mb,%20v1.2.pdf Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-nor/next, thanks! [1/1] mtd: spi-nor: macronix: Add SECT_4K to mx25l12805d https://git.kernel.org/mtd/c/02892d4053 -- Regards Vignesh
Re: [PATCH v2 0/4] mtd: hyperbus: hbmc-am654: Add DMA support
On Thu, 24 Sep 2020 13:42:10 +0530, Vignesh Raghavendra wrote: > This series add DMA support for reading data from HyperBus memory > devices for TI's AM654/J721e SoCs > > With DMA there is ~5x improvement in read througput. > > v2: > Fix DMAengine APIs usage issues pointed out by Peter. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git cfi/next, thanks! [1/4] mtd: hyperbus: Provide per device private pointer https://git.kernel.org/mtd/c/714fb2fbe7 [2/4] mtd: hyperbus: hbmc-am654: Fix direct mapping setup flash access https://git.kernel.org/mtd/c/aca31ce968 [3/4] mtd: hyperbus: hbmc-am654: Drop pm_runtime* calls from probe https://git.kernel.org/mtd/c/992df3bb35 [4/4] mtd: hyperbus: hbmc-am654: Add DMA support for reads https://git.kernel.org/mtd/c/00c9cf49a6 -- Regards Vignesh
Re: [PATCH v10 05/17] mtd: spi-nor: add support for DTR protocol
On 9/29/20 9:12 PM, tudor.amba...@microchip.com wrote: > Hi, Pratyush, > > I'm replying to v10 so that we continue the discussion, but this applies to > v13 as well. > > On 7/21/20 2:29 PM, Pratyush Yadav wrote: > @@ -2368,12 +2517,16 @@ spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor, u32 *hwcaps) struct spi_nor_flash_parameter *params = nor->params; unsigned int cap; - /* DTR modes are not supported yet, mask them all. */ - *hwcaps &= ~SNOR_HWCAPS_DTR; - /* X-X-X modes are not supported yet, mask them all. */ *hwcaps &= ~SNOR_HWCAPS_X_X_X; + /* +* If the reset line is broken, we do not want to enter a stateful +* mode. +*/ + if (nor->flags & SNOR_F_BROKEN_RESET) + *hwcaps &= ~(SNOR_HWCAPS_X_X_X | SNOR_HWCAPS_X_X_X_DTR); >>> >>> A dedicated reset line is not enough for flashes that keep their state >>> in non-volatile bits. Since we can't protect from unexpected crashes in >>> the non volatile state case, we should enter these modes only with an >>> explicit request, i.e. an optional DT property: "update-nonvolatile-state", >>> or something similar. >> >> I wrote this patch with the assumption that we won't be supporting> >> non-volatile configuration as of now. In the previous discussions we > > I think we have to take care of the stateful flashes now, otherwise we'll risk > to end up with users that let their flashes in a mode from which they can't > recover. > I made some small RFC patches in reply to your v13, let me know what you > think. > >> came to the conclusion that it is not easy to detect the flash if it >> boots in any mode other than 1S-1S-1S [0]. So if we update non-volatile >> state, the flash would be useless after a reboot because we won't be >> able to detect it in 8D mode. It doesn't matter if the reset line is >> connected or not because it will reset the flash to the non-volatile >> state, and we can't detect it from the non-volatile state. > > correct, so a reset line for stateful modes doesn't help and the comment from > the > code should be updated. s/stateful/stateless Entering an IO mode even using volatile bits (which gets cleared on SW or HW reset) creates a "state" that SW needs to keep track of which is why "stateful" term is used. I think that's what is implied here AFAIU, Boris's original RFC[1] introducing X-X-X mode also used "stateful mode" term in the same context . >> >>> For the volatile state case, we can parse the SFDP SCCR map, save if we >>> can enter stateful modes in a volatile way, and if yes allow the entering. >> >> If we are not support volatile configurations, the reset line is enough >> to take care of unexpected resets, no? I don't see any need to parse > > the reset line is excellent for the stateless flashes, it guarantees that the > volatile bits will return to their default state. Disabling the clock, waiting > for a period and re-enabling it again should do the trick too, but probably > a dedicated reset line is safer. > I don't think disable-wait-enable sequence of clock input to flash will trigger a reset... You have to take down the power and thus force flash to go through power-down/power-up sequence or use HW or SW reset sequences [1] https://patchwork.ozlabs.org/project/linux-mtd/cover/20181012084825.23697-1-boris.brezil...@bootlin.com/ Regards Vignesh
Re: [RFC PATCH 2/3] mtd: spi-nor: Introduce MTD_SPI_NOR_ALLOW_STATEFUL_MODES
On 9/29/20 3:29 PM, Tudor Ambarus wrote: > Some users may teach their bootloaders to discover and recover a > flash even when left in a statefull mode (a X-X-X I/O mode that is > configured via a non-volatile bit). > > Provide a way for those users to enter in stateful modes. A reset > or a crash will leave the flash in full I/O mode and if the bootloader > does not know how to recover, the SPI NOR boot will be broken. > > Flashes that will enable stateful modes will be accepted only if a > hook to recover from the stateful mode is provided in the kernel. > With this, even if a user will break its SPI NOR boot, it'll be able > to recover the flash at the kernel level (on those systems that have > at least another boot media). Both the Kconfig and the acceptance > restriction are needed, so that we don't end up completely hopeless > and look at a flash for which there is no software to discover and > recover the flash. Even if we can recover the flash from a stateful > mode in kernel, entering the stateful mode is still dangerous if one's > bootloader can't handle it. We need a way to pass the responsibility > to the user and let him decide conciously about the risks of allowing > stateful modes. > Recovering from non-volatile (NV) stateful mode would mean unsetting some NV bit. Doing this for every boot would mean NV bit will wear out quite quickly which is a concern. And sometimes NV Octal Enable bits are OTP only (Some Macronix flashes). NV bits are not to be fiddled with too often. One would set stateful mode in NV way only if entire system is capable of handling this somehow. But, IMHO, since SPI NOR core currently does not support flashes that boot in Quad or Octal mode at the moment, SPI NOR core should not bother providing a hook for manipulating NV IO mode settings. So my recommendation is to not support writing to non volatile IO modes bits unless absolutely necessary. Regards Vignesh > Signed-off-by: Tudor Ambarus > --- > drivers/mtd/spi-nor/Kconfig | 10 ++ > drivers/mtd/spi-nor/core.c | 2 ++ > 2 files changed, 12 insertions(+) > > diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig > index ffc4b380f2b1..ab62457559b2 100644 > --- a/drivers/mtd/spi-nor/Kconfig > +++ b/drivers/mtd/spi-nor/Kconfig > @@ -24,6 +24,16 @@ config MTD_SPI_NOR_USE_4K_SECTORS > Please note that some tools/drivers/filesystems may not work with > 4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum). > > +config MTD_SPI_NOR_ALLOW_STATEFUL_MODES > + bool "Allow stateful modes (DANGEROUS)" > + help > + Allow the flash to enter in full I/O mode via a non-volatile bit. > + A reset or a crash will leave the flash in the full I/O mode and if > + the bootloader does not know how to recover, the SPI NOR boot will be > + broken. > + > + Say N, unless you absolutely know what you are doing. > + > source "drivers/mtd/spi-nor/controllers/Kconfig" > > endif # MTD_SPI_NOR > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c > index c149b318e2e8..e89c3ea9a736 100644 > --- a/drivers/mtd/spi-nor/core.c > +++ b/drivers/mtd/spi-nor/core.c > @@ -3089,8 +3089,10 @@ static int spi_nor_octal_dtr_enable(struct spi_nor > *nor, bool enable) > nor->write_proto == SNOR_PROTO_8_8_8_DTR)) > return 0; > > +#ifndef CONFIG_MTD_SPI_NOR_ALLOW_STATEFUL_MODES > if (!(nor->flags & SNOR_F_IO_MODE_EN_VOLATILE)) > return 0; > +#endif > > ret = nor->params->octal_dtr_enable(nor, enable); > if (ret) >
Re: [RFC PATCH 1/3] mtd: spi-nor: Introduce SNOR_F_IO_MODE_EN_VOLATILE
On 9/29/20 3:29 PM, Tudor Ambarus wrote:
> We don't want to enter a stateful mode, where a X-X-X I/O mode
> is entered by setting a non-volatile bit, because in case of a
> reset or a crash, once in the non-volatile mode, we may not be able
> to recover in bootloaders and we may break the SPI NOR boot.
>
> Forbid by default the I/O modes that are set via a non-volatile bit.
>
> SPI_NOR_IO_MODE_EN_VOLATILE should be set just for the flashes that
> don't define the optional SFDP SCCR Map, so that we don't pollute the
> flash info flags.
>
I would make this SPI_NOR_IO_MODE_EN_NON_VOLATILE. Because flashes with
volatile bits to change IO modes are more common than non volatile ones
and above change makes its easier to spot such quirky flashes.
> Signed-off-by: Tudor Ambarus
> ---
> drivers/mtd/spi-nor/core.c | 6 ++
> drivers/mtd/spi-nor/core.h | 6 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 34edfcf33172..c149b318e2e8 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3089,6 +3089,9 @@ static int spi_nor_octal_dtr_enable(struct spi_nor
> *nor, bool enable)
> nor->write_proto == SNOR_PROTO_8_8_8_DTR))
> return 0;
>
> + if (!(nor->flags & SNOR_F_IO_MODE_EN_VOLATILE))
> + return 0;
> +
> ret = nor->params->octal_dtr_enable(nor, enable);
> if (ret)
> return ret;
> @@ -3474,6 +3477,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> if (info->flags & SPI_NOR_4B_OPCODES)
> nor->flags |= SNOR_F_4B_OPCODES;
>
> + if (info->flags & SPI_NOR_IO_MODE_EN_VOLATILE)
> + nor->flags |= SNOR_F_IO_MODE_EN_VOLATILE;
> +
> ret = spi_nor_set_addr_width(nor);
> if (ret)
> return ret;
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 10dc03506f93..c2755c82f978 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -27,6 +27,7 @@ enum spi_nor_option_flags {
> SNOR_F_HAS_4BIT_BP = BIT(12),
> SNOR_F_HAS_SR_BP3_BIT6 = BIT(13),
> SNOR_F_SOFT_RESET = BIT(14),
> + SNOR_F_IO_MODE_EN_VOLATILE = BIT(15),
> };
>
> struct spi_nor_read_command {
> @@ -323,6 +324,11 @@ struct flash_info {
>*/
> #define SPI_NOR_OCTAL_DTR_READ BIT(19) /* Flash supports octal DTR
> Read. */
> #define SPI_NOR_OCTAL_DTR_PP BIT(20) /* Flash supports Octal DTR Page
> Program */
> +#define SPI_NOR_IO_MODE_EN_VOLATILE BIT(21) /*
> + * Flash enables the best
> + * available I/O mode via a
> + * volatile bit.
> + */
>
> /* Part specific fixup hooks. */
> const struct spi_nor_fixups *fixups;
>
Re: [PATCH] mtd: spi-nor: macronix: Add SECT_4K to mx25l12805d
Hi,
On 9/15/20 3:36 PM, Robert Marko wrote:
> According to the mx25l12805d datasheet it supports using 4K or 64K sectors.
> So lets add the SECT_4K to enable 4K sector usage.
>
> Datasheet:
> https://www.mxic.com.tw/Lists/Datasheet/Attachments/7321/MX25L12805D,%203V,%20128Mb,%20v1.2.pdf
Have you tested this feature on a real HW?
>
> Signed-off-by: Robert Marko
> Cc: Luka Perkov
> ---
> drivers/mtd/spi-nor/macronix.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
> index f97f3d127575..9203abaac229 100644
> --- a/drivers/mtd/spi-nor/macronix.c
> +++ b/drivers/mtd/spi-nor/macronix.c
> @@ -50,7 +50,7 @@ static const struct flash_info macronix_parts[] = {
> { "mx25u4035", INFO(0xc22533, 0, 64 * 1024, 8, SECT_4K) },
> { "mx25u8035", INFO(0xc22534, 0, 64 * 1024, 16, SECT_4K) },
> { "mx25u6435f", INFO(0xc22537, 0, 64 * 1024, 128, SECT_4K) },
> - { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
> + { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, SECT_4K) },
> { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
> { "mx25r1635f", INFO(0xc22815, 0, 64 * 1024, 32,
> SECT_4K | SPI_NOR_DUAL_READ |
>
Regards
Vignesh
Re: [PATCH] mtd: spi-nor: controllers: intel-spi: Add support for command line partitions
On 4/17/20 9:37 PM, Mika Westerberg wrote: > On Fri, Apr 17, 2020 at 08:26:11AM -0700, Ronald G. Minnich wrote: >> On Intel platforms, the usable SPI area is located several >> MiB in from the start, to leave room for descriptors and >> the Management Engine binary. Further, not all the remaining >> space can be used, as the last 16 MiB contains firmware. >> >> To make the SPI usable for mtdblock and other devices, >> it is necessary to enable command line partitions so the >> middle usable region can be specified. >> >> Add a part_probes array which includes only "cmdelineparts", >> and change to mtd_device_parse_register to use this part_probes. >> >> Signed-off-by: Ronald G. Minnich > > Reviewed-by: Mika Westerberg > scripts/checkpatch.pl --strict complains: CHECK: Alignment should match open parenthesis #46: FILE: drivers/mtd/spi-nor/controllers/intel-spi.c:956: + ret = mtd_device_parse_register(>nor.mtd, part_probes, + NULL, , 1); WARNING: Missing Signed-off-by: line by nominal patch author '"Ronald G. Minnich" ' Regards Vignesh
Re: [PATCH v2 0/2] Add support for MMC/SD on j7200-evm
On 9/24/20 4:56 PM, Faiz Abbas wrote: > The following patches add dt support for MMC/SD on TI's j7200-evm. > > Currently, eMMC support upto HS200 speed and SD card supports upto high > speed speed mode. > > v2: > Fixed node names to use mmc@* format > Fixed reg address format to align with others in the file > > Faiz Abbas (2): > arm64: dts: ti: k3-j7200-main: Add support for MMC/SD controller nodes > arm64: dts: ti: k3-j7200-common-proc-board: Add support for eMMC and > SD card > > .../dts/ti/k3-j7200-common-proc-board.dts | 28 ++ > arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 37 +++ > 2 files changed, 65 insertions(+) > For the series: Tested-by: Vignesh Raghavendra [1.678263] mmc0: Command Queue Engine enabled [1.682727] mmc0: new HS200 MMC card at address 0001 [1.688193] mmcblk0: mmc0:0001 S0J56X 14.8 GiB [1.692971] mmcblk0boot0: mmc0:0001 S0J56X partition 1 31.5 MiB [1.699138] mmcblk0boot1: mmc0:0001 S0J56X partition 2 31.5 MiB [1.705268] mmcblk0rpmb: mmc0:0001 S0J56X partition 3 4.00 MiB, ch ardev (240:0) [1.789527] mmc1: new high speed SDHC card at address [1.795621] mmcblk1: mmc1: SC16G 14.8 GiB [1.810074] mmcblk1: p1 p2 SD hot plug works fine too.. Full log: https://pastebin.ubuntu.com/p/5hcCQDjhtW/
Re: [PATCH v4 0/6] arm64: dts: ti: Add USB support for J7200 EVM
On 9/21/20 8:09 PM, Roger Quadros wrote: > Hi Tero/Nishanth, > > This series adds USB2.0 support for the J7200 EVM. [...] > Kishon Vijay Abraham I (1): > arm64: dts: ti: k3-j7200-common-proc-board: Configure the SERDES lane > function > > Roger Quadros (5): > dt-bindings: ti-serdes-mux: Add defines for J7200 SoC > arm64: dts: ti: k3-j7200-main: Add SERDES lane control mux > arm64: dts: ti: k3-j7200-main.dtsi: Add USB to SERDES lane MUX > arm64: dts: ti: k3-j7200-main: Add USB controller > arm64: dts: ti: k3-j7200-common-proc-board: Add USB support > > .../dts/ti/k3-j7200-common-proc-board.dts | 28 ++ > arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 51 +++ > include/dt-bindings/mux/ti-serdes.h | 22 > 3 files changed, 101 insertions(+) > For the series: Reviewed-by: Vignesh Raghavendra
[PATCH v2 4/4] mtd: hyperbus: hbmc-am654: Add DMA support for reads
AM654 HyperBus controller provides MMIO interface to read data from
flash. So add DMA memcpy support for reading data over MMIO interface.
This provides 5x improvement in throughput and reduces CPU usage as
well.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Peter Ujfalusi
---
drivers/mtd/hyperbus/hbmc-am654.c | 126 +-
1 file changed, 125 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/hyperbus/hbmc-am654.c
b/drivers/mtd/hyperbus/hbmc-am654.c
index b6a2400fcaa9..a3439b791eeb 100644
--- a/drivers/mtd/hyperbus/hbmc-am654.c
+++ b/drivers/mtd/hyperbus/hbmc-am654.c
@@ -3,6 +3,10 @@
// Copyright (C) 2019 Texas Instruments Incorporated - https://www.ti.com/
// Author: Vignesh Raghavendra
+#include
+#include
+#include
+#include
#include
#include
#include
@@ -13,10 +17,18 @@
#include
#include
#include
+#include
#include
#define AM654_HBMC_CALIB_COUNT 25
+struct am654_hbmc_device_priv {
+ struct completion rx_dma_complete;
+ phys_addr_t device_base;
+ struct hyperbus_ctlr *ctlr;
+ struct dma_chan *rx_chan;
+};
+
struct am654_hbmc_priv {
struct hyperbus_ctlr ctlr;
struct hyperbus_device hbdev;
@@ -51,13 +63,103 @@ static int am654_hbmc_calibrate(struct hyperbus_device
*hbdev)
return ret;
}
+static void am654_hbmc_dma_callback(void *param)
+{
+ struct am654_hbmc_device_priv *priv = param;
+
+ complete(>rx_dma_complete);
+}
+
+static int am654_hbmc_dma_read(struct am654_hbmc_device_priv *priv, void *to,
+ unsigned long from, ssize_t len)
+
+{
+ enum dma_ctrl_flags flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
+ struct dma_chan *rx_chan = priv->rx_chan;
+ struct dma_async_tx_descriptor *tx;
+ dma_addr_t dma_dst, dma_src;
+ dma_cookie_t cookie;
+ int ret;
+
+ if (!priv->rx_chan || !virt_addr_valid(to) || object_is_on_stack(to))
+ return -EINVAL;
+
+ dma_dst = dma_map_single(rx_chan->device->dev, to, len,
DMA_FROM_DEVICE);
+ if (dma_mapping_error(rx_chan->device->dev, dma_dst)) {
+ dev_dbg(priv->ctlr->dev, "DMA mapping failed\n");
+ return -EIO;
+ }
+
+ dma_src = priv->device_base + from;
+ tx = dmaengine_prep_dma_memcpy(rx_chan, dma_dst, dma_src, len, flags);
+ if (!tx) {
+ dev_err(priv->ctlr->dev, "device_prep_dma_memcpy error\n");
+ ret = -EIO;
+ goto unmap_dma;
+ }
+
+ reinit_completion(>rx_dma_complete);
+ tx->callback = am654_hbmc_dma_callback;
+ tx->callback_param = priv;
+ cookie = dmaengine_submit(tx);
+
+ ret = dma_submit_error(cookie);
+ if (ret) {
+ dev_err(priv->ctlr->dev, "dma_submit_error %d\n", cookie);
+ goto unmap_dma;
+ }
+
+ dma_async_issue_pending(rx_chan);
+ if (!wait_for_completion_timeout(>rx_dma_complete,
msecs_to_jiffies(len + 1000))) {
+ dmaengine_terminate_sync(rx_chan);
+ dev_err(priv->ctlr->dev, "DMA wait_for_completion_timeout\n");
+ ret = -ETIMEDOUT;
+ }
+
+unmap_dma:
+ dma_unmap_single(rx_chan->device->dev, dma_dst, len, DMA_FROM_DEVICE);
+ return ret;
+}
+
+static void am654_hbmc_read(struct hyperbus_device *hbdev, void *to,
+ unsigned long from, ssize_t len)
+{
+ struct am654_hbmc_device_priv *priv = hbdev->priv;
+
+ if (len < SZ_1K || am654_hbmc_dma_read(priv, to, from, len))
+ memcpy_fromio(to, hbdev->map.virt + from, len);
+}
+
static const struct hyperbus_ops am654_hbmc_ops = {
.calibrate = am654_hbmc_calibrate,
+ .copy_from = am654_hbmc_read,
};
+static int am654_hbmc_request_mmap_dma(struct am654_hbmc_device_priv *priv)
+{
+ struct dma_chan *rx_chan;
+ dma_cap_mask_t mask;
+
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_MEMCPY, mask);
+
+ rx_chan = dma_request_chan_by_mask();
+ if (IS_ERR(rx_chan)) {
+ if (PTR_ERR(rx_chan) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_dbg(priv->ctlr->dev, "No DMA channel available\n");
+ return 0;
+ }
+ priv->rx_chan = rx_chan;
+ init_completion(>rx_dma_complete);
+
+ return 0;
+}
+
static int am654_hbmc_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
+ struct am654_hbmc_device_priv *dev_priv;
struct device *dev = >dev;
struct am654_hbmc_priv *priv;
struct resource res;
@@ -96,13 +198,31 @@ static int am654_hbmc_probe(struct platform_device *pdev)
priv->ctlr.dev = dev;
priv->ctlr.ops = _hbmc_ops;
priv->hbdev.ctlr = >ctlr;
+
+
[PATCH v2 0/4] mtd: hyperbus: hbmc-am654: Add DMA support
This series add DMA support for reading data from HyperBus memory devices for TI's AM654/J721e SoCs With DMA there is ~5x improvement in read througput. v2: Fix DMAengine APIs usage issues pointed out by Peter. Vignesh Raghavendra (4): mtd: hyperbus: Provide per device private pointer mtd: hyperbus: hbmc-am654: Fix direct mapping setup flash access mtd: hyperbus: hbmc-am654: Drop pm_runtime* calls from probe mtd: hyperbus: hbmc-am654: Add DMA support for reads drivers/mtd/hyperbus/hbmc-am654.c | 144 ++ include/linux/mtd/hyperbus.h | 2 + 2 files changed, 130 insertions(+), 16 deletions(-) -- 2.28.0
[PATCH v2 3/4] mtd: hyperbus: hbmc-am654: Drop pm_runtime* calls from probe
Recent genpd changes for K3 platform ensure device is ON before driver
probe is called. Therefore, drop redundant pm_runtime_* calls from
driver to simplify the code.
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/hyperbus/hbmc-am654.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/mtd/hyperbus/hbmc-am654.c
b/drivers/mtd/hyperbus/hbmc-am654.c
index 1e70ecfffa39..b6a2400fcaa9 100644
--- a/drivers/mtd/hyperbus/hbmc-am654.c
+++ b/drivers/mtd/hyperbus/hbmc-am654.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#define AM654_HBMC_CALIB_COUNT 25
@@ -89,13 +88,6 @@ static int am654_hbmc_probe(struct platform_device *pdev)
priv->mux_ctrl = control;
}
- pm_runtime_enable(dev);
- ret = pm_runtime_get_sync(dev);
- if (ret < 0) {
- pm_runtime_put_noidle(dev);
- goto disable_pm;
- }
-
priv->hbdev.map.size = resource_size();
priv->hbdev.map.virt = devm_ioremap_resource(dev, );
if (IS_ERR(priv->hbdev.map.virt))
@@ -107,13 +99,11 @@ static int am654_hbmc_probe(struct platform_device *pdev)
ret = hyperbus_register_device(>hbdev);
if (ret) {
dev_err(dev, "failed to register controller\n");
- pm_runtime_put_sync(>dev);
- goto disable_pm;
+ goto disable_mux;
}
return 0;
-disable_pm:
- pm_runtime_disable(dev);
+disable_mux:
if (priv->mux_ctrl)
mux_control_deselect(priv->mux_ctrl);
return ret;
@@ -127,8 +117,6 @@ static int am654_hbmc_remove(struct platform_device *pdev)
ret = hyperbus_unregister_device(>hbdev);
if (priv->mux_ctrl)
mux_control_deselect(priv->mux_ctrl);
- pm_runtime_put_sync(>dev);
- pm_runtime_disable(>dev);
return ret;
}
--
2.28.0
[PATCH v2 2/4] mtd: hyperbus: hbmc-am654: Fix direct mapping setup flash access
Setting up of direct mapping should be done with flash node's IO
address space and not with controller's IO region.
Fixes: b6fe8bc67d2d3 ("mtd: hyperbus: move direct mapping setup to AM654 HBMC
driver")
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/hyperbus/hbmc-am654.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/hyperbus/hbmc-am654.c
b/drivers/mtd/hyperbus/hbmc-am654.c
index e0e33f6bf513..1e70ecfffa39 100644
--- a/drivers/mtd/hyperbus/hbmc-am654.c
+++ b/drivers/mtd/hyperbus/hbmc-am654.c
@@ -70,7 +70,8 @@ static int am654_hbmc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, priv);
- ret = of_address_to_resource(np, 0, );
+ priv->hbdev.np = of_get_next_child(np, NULL);
+ ret = of_address_to_resource(priv->hbdev.np, 0, );
if (ret)
return ret;
@@ -103,7 +104,6 @@ static int am654_hbmc_probe(struct platform_device *pdev)
priv->ctlr.dev = dev;
priv->ctlr.ops = _hbmc_ops;
priv->hbdev.ctlr = >ctlr;
- priv->hbdev.np = of_get_next_child(dev->of_node, NULL);
ret = hyperbus_register_device(>hbdev);
if (ret) {
dev_err(dev, "failed to register controller\n");
--
2.28.0
[PATCH v2 1/4] mtd: hyperbus: Provide per device private pointer
Provide per device private pointer that can be used by controller
drivers to store device specific private data.
Signed-off-by: Vignesh Raghavendra
---
include/linux/mtd/hyperbus.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/mtd/hyperbus.h b/include/linux/mtd/hyperbus.h
index 2129f7d3b6eb..d8cb1aec826d 100644
--- a/include/linux/mtd/hyperbus.h
+++ b/include/linux/mtd/hyperbus.h
@@ -20,6 +20,7 @@ enum hyperbus_memtype {
* @mtd: pointer to MTD struct
* @ctlr: pointer to HyperBus controller struct
* @memtype: type of memory device: HyperFlash or HyperRAM
+ * @priv: pointer to controller specific per device private data
*/
struct hyperbus_device {
@@ -28,6 +29,7 @@ struct hyperbus_device {
struct mtd_info *mtd;
struct hyperbus_ctlr *ctlr;
enum hyperbus_memtype memtype;
+ void *priv;
};
/**
--
2.28.0
[PATCH v2 2/2] arm64: dts: ti: k3-j7200-som-p0: Add HyperFlash node
J7200 SoM has a HyperFlash connected to HyperBus memory controller. But
HyperBus is muxed with OSPI, therefore keep HyperBus node disabled.
Bootloader will detect the mux and enable the node as required.
Signed-off-by: Vignesh Raghavendra
---
arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 36 +
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
index f7e271c442a0..6a98ba499bc2 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
@@ -27,3 +27,39 @@ secure_ddr: optee@9e80 {
};
};
};
+
+_pmx0 {
+ mcu_fss0_hpb0_pins_default: mcu-fss0-hpb0-pins-default {
+ pinctrl-single,pins = <
+ J721E_WKUP_IOPAD(0x0, PIN_OUTPUT, 1) /* (B6)
MCU_OSPI0_CLK.MCU_HYPERBUS0_CK */
+ J721E_WKUP_IOPAD(0x4, PIN_OUTPUT, 1) /* (C8)
MCU_OSPI0_LBCLKO.MCU_HYPERBUS0_CKn */
+ J721E_WKUP_IOPAD(0x2c, PIN_OUTPUT, 1) /* (D6)
MCU_OSPI0_CSn0.MCU_HYPERBUS0_CSn0 */
+ J721E_WKUP_IOPAD(0x30, PIN_OUTPUT, 1) /* (D7)
MCU_OSPI0_CSn1.MCU_HYPERBUS0_RESETn */
+ J721E_WKUP_IOPAD(0x8, PIN_INPUT, 1) /* (B7)
MCU_OSPI0_DQS.MCU_HYPERBUS0_RWDS */
+ J721E_WKUP_IOPAD(0xc, PIN_INPUT, 1) /* (D8)
MCU_OSPI0_D0.MCU_HYPERBUS0_DQ0 */
+ J721E_WKUP_IOPAD(0x10, PIN_INPUT, 1) /* (C7)
MCU_OSPI0_D1.MCU_HYPERBUS0_DQ1 */
+ J721E_WKUP_IOPAD(0x14, PIN_INPUT, 1) /* (C5)
MCU_OSPI0_D2.MCU_HYPERBUS0_DQ2 */
+ J721E_WKUP_IOPAD(0x18, PIN_INPUT, 1) /* (A5)
MCU_OSPI0_D3.MCU_HYPERBUS0_DQ3 */
+ J721E_WKUP_IOPAD(0x1c, PIN_INPUT, 1) /* (A6)
MCU_OSPI0_D4.MCU_HYPERBUS0_DQ4 */
+ J721E_WKUP_IOPAD(0x20, PIN_INPUT, 1) /* (B8)
MCU_OSPI0_D5.MCU_HYPERBUS0_DQ5 */
+ J721E_WKUP_IOPAD(0x24, PIN_INPUT, 1) /* (A8)
MCU_OSPI0_D6.MCU_HYPERBUS0_DQ6 */
+ J721E_WKUP_IOPAD(0x28, PIN_INPUT, 1) /* (A7)
MCU_OSPI0_D7.MCU_HYPERBUS0_DQ7 */
+ >;
+ };
+};
+
+ {
+ /* OSPI and HBMC are muxed inside FSS, Bootloader will enable
+* appropriate node based on board detection
+*/
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <_fss0_hpb0_pins_default>;
+ ranges = <0x00 0x00 0x05 0x 0x400>, /* 64MB Flash on CS0 */
+<0x01 0x00 0x05 0x0400 0x80>; /* 8MB RAM on CS1 */
+
+ flash@0,0 {
+ compatible = "cypress,hyperflash", "cfi-flash";
+ reg = <0x00 0x00 0x400>;
+ };
+};
--
2.28.0
[PATCH v2 1/2] arm64: dts: ti: k3-j7200-mcu-wakeup: Add HyperBus node
J7200 has a Flash SubSystem that has one OSPI and one HyperBus.. Add
DT nodes for HyperBus controller for now.
Signed-off-by: Vignesh Raghavendra
---
.../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
index a43385d8feca..ab22b02c0da5 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -125,4 +125,31 @@ wkup_i2c0: i2c@4212 {
clocks = <_clks 197 1>;
power-domains = <_pds 197 TI_SCI_PD_SHARED>;
};
+
+ fss: syscon@4700 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x00 0x4700 0x00 0x100>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ hbmc_mux: hbmc-mux {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x4 0x2>; /* HBMC select */
+ };
+
+ hbmc: hyperbus@47034000 {
+ compatible = "ti,am654-hbmc";
+ reg = <0x00 0x47034000 0x00 0x100>,
+ <0x05 0x 0x01 0x000>;
+ power-domains = <_pds 102 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 102 0>;
+ assigned-clocks = <_clks 102 5>;
+ assigned-clock-rates = <3>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ mux-controls = <_mux 0>;
+ };
+ };
};
--
2.28.0
[PATCH v2 0/2] arm64: dts: ti: k3-j7200: Add HyperFlash related nodes
This series adds HyperBus and HyperFlash nodes for TI's J7200 SoC v2: Rebase on latest ti-k3-next + I2C series Align reg address format with this file's convention Vignesh Raghavendra (2): arm64: dts: ti: k3-j7200-mcu-wakeup: Add HyperBus node arm64: dts: ti: k3-j7200-som-p0: Add HyperFlash node .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 27 ++ arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 36 +++ 2 files changed, 63 insertions(+) -- 2.28.0
[PATCH v2 0/2] J7200: Add I2C support
Add I2C and I2C IO expanders nodes for J7200 v2: Align reg address format with that of file's (s/0x0/0x00) Vignesh Raghavendra (2): arm64: dts: ti: j7200: Add I2C nodes arm64: dts: ti: k3-j7200-common-proc-board: Add I2C IO expanders .../dts/ti/k3-j7200-common-proc-board.dts | 49 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 77 +++ .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 33 3 files changed, 159 insertions(+) -- 2.28.0
[PATCH v2 2/2] arm64: dts: ti: k3-j7200-common-proc-board: Add I2C IO expanders
Add DT nodes for I2C GPIO expanders on main_i2c0 and main_i2c1 and
also add the pinmux corresponding to these I2C instances.
Signed-off-by: Vignesh Raghavendra
---
.../dts/ti/k3-j7200-common-proc-board.dts | 49 +++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index e27069317c4e..26ad2e46009e 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -14,6 +14,22 @@ chosen {
};
};
+_pmx0 {
+ main_i2c0_pins_default: main-i2c0-pins-default {
+ pinctrl-single,pins = <
+ J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL
*/
+ J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA
*/
+ >;
+ };
+
+ main_i2c1_pins_default: main-i2c1-pins-default {
+ pinctrl-single,pins = <
+ J721E_IOPAD(0xdc, PIN_INPUT_PULLUP, 3) /* (U3)
ECAP0_IN_APWM_OUT.I2C1_SCL */
+ J721E_IOPAD(0xe0, PIN_INPUT_PULLUP, 3) /* (T3)
EXT_REFCLK1.I2C1_SDA */
+ >;
+ };
+};
+
_uart0 {
/* Wakeup UART is used by System firmware */
status = "disabled";
@@ -62,3 +78,36 @@ _uart9 {
/* UART not brought out */
status = "disabled";
};
+
+_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0_pins_default>;
+ clock-frequency = <40>;
+
+ exp1: gpio@20 {
+ compatible = "ti,tca6416";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ exp2: gpio@22 {
+ compatible = "ti,tca6424";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+_i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c1_pins_default>;
+ clock-frequency = <40>;
+
+ exp4: gpio@20 {
+ compatible = "ti,tca6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
--
2.28.0
[PATCH v2 1/2] arm64: dts: ti: j7200: Add I2C nodes
J7200 has 7 I2Cs in main domain, 2 I2Cs in MCU and 1 in wakeup domain.
Add DT nodes for the same.
Signed-off-by: Vignesh Raghavendra
---
arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 77 +++
.../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 33
2 files changed, 110 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index 3df49577b06a..f44f0b83d12a 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -233,4 +233,81 @@ main_uart9: serial@289 {
clocks = <_clks 286 2>;
clock-names = "fclk";
};
+
+ main_i2c0: i2c@200 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x200 0x00 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 187 1>;
+ power-domains = <_pds 187 TI_SCI_PD_SHARED>;
+ };
+
+ main_i2c1: i2c@201 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x201 0x00 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 188 1>;
+ power-domains = <_pds 188 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ main_i2c2: i2c@202 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x202 0x00 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 189 1>;
+ power-domains = <_pds 189 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ main_i2c3: i2c@203 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x203 0x00 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 190 1>;
+ power-domains = <_pds 190 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ main_i2c4: i2c@204 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x204 0x00 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 191 1>;
+ power-domains = <_pds 191 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ main_i2c5: i2c@205 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x205 0x00 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 192 1>;
+ power-domains = <_pds 192 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ main_i2c6: i2c@206 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x206 0x00 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 193 1>;
+ power-domains = <_pds 193 TI_SCI_PD_EXCLUSIVE>;
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
index ec2745e0768e..a43385d8feca 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -92,4 +92,37 @@ wkup_gpio_intr: interrupt-controller2 {
ti,sci-dev-id = <137>;
ti,interrupt-ranges = <16 960 16>;
};
+
+ mcu_i2c0: i2c@40b0 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x40b0 0x00 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 194 1>;
+ power-domains = <_pds 194 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ mcu_i2c1: i2c@40b1 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x00
[GIT PULL] mtd: Fixes for v5.9-rc6
Hello Linus, Please pull the MTD changes for v5.9-rc6. I am sending this on behalf of MTD maintainers group this time around. Miquel/Richard, Could you please ACK the PR? Regards Vignesh The following changes since commit 856deb866d16e29bd65952e0289066f6078af773: Linux 5.9-rc5 (2020-09-13 16:06:00 -0700) are available in the Git repository at: g...@gitolite.kernel.org:pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/fixes-for-5.9-rc6 for you to fetch changes up to 1afc0c89f6a155c54c76d65ffcf72cd1232daf3a: Revert "mtd: spi-nor: Add capability to disable flash quad mode" (2020-09-14 20:58:27 +0530) MTD/SPI NOR fixes: Revert patches that caused non volatile Quad Enable bit to be cleared for certain SPI NOR flashes during module remove or during shutdown, thus breaking backward compatibility. Yicong Yang (2): Revert "mtd: spi-nor: Disable the flash quad mode in spi_nor_restore()" Revert "mtd: spi-nor: Add capability to disable flash quad mode" drivers/mtd/spi-nor/core.c | 57 -- drivers/mtd/spi-nor/core.h | 10 +- 2 files changed, 24 insertions(+), 43 deletions(-)
[PATCH 3/4] mtd: hyperbus: hbmc-am654: Drop pm_runtime* calls from probe
Recent genpd changes for K3 platform ensure device is ON before driver
probe is called. Therefore, drop redundant pm_runtime_* calls from
driver to simplify the code.
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/hyperbus/hbmc-am654.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/mtd/hyperbus/hbmc-am654.c
b/drivers/mtd/hyperbus/hbmc-am654.c
index 1e70ecfffa39..b6a2400fcaa9 100644
--- a/drivers/mtd/hyperbus/hbmc-am654.c
+++ b/drivers/mtd/hyperbus/hbmc-am654.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#define AM654_HBMC_CALIB_COUNT 25
@@ -89,13 +88,6 @@ static int am654_hbmc_probe(struct platform_device *pdev)
priv->mux_ctrl = control;
}
- pm_runtime_enable(dev);
- ret = pm_runtime_get_sync(dev);
- if (ret < 0) {
- pm_runtime_put_noidle(dev);
- goto disable_pm;
- }
-
priv->hbdev.map.size = resource_size();
priv->hbdev.map.virt = devm_ioremap_resource(dev, );
if (IS_ERR(priv->hbdev.map.virt))
@@ -107,13 +99,11 @@ static int am654_hbmc_probe(struct platform_device *pdev)
ret = hyperbus_register_device(>hbdev);
if (ret) {
dev_err(dev, "failed to register controller\n");
- pm_runtime_put_sync(>dev);
- goto disable_pm;
+ goto disable_mux;
}
return 0;
-disable_pm:
- pm_runtime_disable(dev);
+disable_mux:
if (priv->mux_ctrl)
mux_control_deselect(priv->mux_ctrl);
return ret;
@@ -127,8 +117,6 @@ static int am654_hbmc_remove(struct platform_device *pdev)
ret = hyperbus_unregister_device(>hbdev);
if (priv->mux_ctrl)
mux_control_deselect(priv->mux_ctrl);
- pm_runtime_put_sync(>dev);
- pm_runtime_disable(>dev);
return ret;
}
--
2.28.0
[PATCH 2/4] mtd: hyperbus: hbmc-am654: Fix direct mapping setup flash access
Setting up of direct mapping should be done with flash node's IO
address space and not with controller's IO region.
Fixes: b6fe8bc67d2d3 ("mtd: hyperbus: move direct mapping setup to AM654 HBMC
driver")
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/hyperbus/hbmc-am654.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/hyperbus/hbmc-am654.c
b/drivers/mtd/hyperbus/hbmc-am654.c
index e0e33f6bf513..1e70ecfffa39 100644
--- a/drivers/mtd/hyperbus/hbmc-am654.c
+++ b/drivers/mtd/hyperbus/hbmc-am654.c
@@ -70,7 +70,8 @@ static int am654_hbmc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, priv);
- ret = of_address_to_resource(np, 0, );
+ priv->hbdev.np = of_get_next_child(np, NULL);
+ ret = of_address_to_resource(priv->hbdev.np, 0, );
if (ret)
return ret;
@@ -103,7 +104,6 @@ static int am654_hbmc_probe(struct platform_device *pdev)
priv->ctlr.dev = dev;
priv->ctlr.ops = _hbmc_ops;
priv->hbdev.ctlr = >ctlr;
- priv->hbdev.np = of_get_next_child(dev->of_node, NULL);
ret = hyperbus_register_device(>hbdev);
if (ret) {
dev_err(dev, "failed to register controller\n");
--
2.28.0
[PATCH 4/4] mtd: hyperbus: hbmc-am654: Add DMA support for reads
AM654 HyperBus controller provides MMIO interface to read data from
flash. So add DMA memcpy support for reading data over MMIO interface.
This provides 5x improvement in throughput and reduces CPU usage as
well.
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/hyperbus/hbmc-am654.c | 130 +-
1 file changed, 129 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/hyperbus/hbmc-am654.c
b/drivers/mtd/hyperbus/hbmc-am654.c
index b6a2400fcaa9..b6ab55560089 100644
--- a/drivers/mtd/hyperbus/hbmc-am654.c
+++ b/drivers/mtd/hyperbus/hbmc-am654.c
@@ -3,6 +3,10 @@
// Copyright (C) 2019 Texas Instruments Incorporated - https://www.ti.com/
// Author: Vignesh Raghavendra
+#include
+#include
+#include
+#include
#include
#include
#include
@@ -13,10 +17,18 @@
#include
#include
#include
+#include
#include
#define AM654_HBMC_CALIB_COUNT 25
+struct am654_hbmc_device_priv {
+ struct completion rx_dma_complete;
+ phys_addr_t device_base;
+ struct hyperbus_ctlr *ctlr;
+ struct dma_chan *rx_chan;
+};
+
struct am654_hbmc_priv {
struct hyperbus_ctlr ctlr;
struct hyperbus_device hbdev;
@@ -51,13 +63,107 @@ static int am654_hbmc_calibrate(struct hyperbus_device
*hbdev)
return ret;
}
+static void am654_hbmc_dma_callback(void *param)
+{
+ struct am654_hbmc_device_priv *priv = param;
+
+ complete(>rx_dma_complete);
+}
+
+static int am654_hbmc_dma_read(struct am654_hbmc_device_priv *priv, void *to,
+ unsigned long from, ssize_t len)
+
+{
+ enum dma_ctrl_flags flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
+ struct dma_chan *rx_chan = priv->rx_chan;
+ struct dma_async_tx_descriptor *tx;
+ dma_addr_t dma_dst, dma_src;
+ dma_cookie_t cookie;
+ int ret;
+
+ if (!priv->rx_chan || !virt_addr_valid(to) || object_is_on_stack(to))
+ return -EINVAL;
+
+ dma_dst = dma_map_single(rx_chan->device->dev, to, len,
DMA_FROM_DEVICE);
+ if (dma_mapping_error(rx_chan->device->dev, dma_dst)) {
+ dev_dbg(priv->ctlr->dev, "DMA mapping failed\n");
+ return -EIO;
+ }
+
+ dma_src = priv->device_base + from;
+ tx = dmaengine_prep_dma_memcpy(rx_chan, dma_dst, dma_src, len, flags);
+ if (!tx) {
+ dev_err(priv->ctlr->dev, "device_prep_dma_memcpy error\n");
+ ret = -EIO;
+ goto unmap_dma;
+ }
+
+ reinit_completion(>rx_dma_complete);
+ tx->callback = am654_hbmc_dma_callback;
+ tx->callback_param = priv;
+ cookie = tx->tx_submit(tx);
+
+ ret = dma_submit_error(cookie);
+ if (ret) {
+ dev_err(priv->ctlr->dev, "dma_submit_error %d\n", cookie);
+ ret = -EIO;
+ goto unmap_dma;
+ }
+
+ dma_async_issue_pending(rx_chan);
+ ret = wait_for_completion_timeout(>rx_dma_complete,
+ msecs_to_jiffies(len + 1000));
+ if (ret <= 0) {
+ dmaengine_terminate_sync(rx_chan);
+ dev_err(priv->ctlr->dev, "DMA wait_for_completion_timeout\n");
+ ret = -ETIMEDOUT;
+ goto unmap_dma;
+ }
+ ret = 0;
+
+unmap_dma:
+ dma_unmap_single(rx_chan->device->dev, dma_dst, len, DMA_FROM_DEVICE);
+ return ret;
+}
+
+static void am654_hbmc_read(struct hyperbus_device *hbdev, void *to,
+ unsigned long from, ssize_t len)
+{
+ struct am654_hbmc_device_priv *priv = hbdev->priv;
+
+ if (len < SZ_1K || am654_hbmc_dma_read(priv, to, from, len))
+ memcpy_fromio(to, hbdev->map.virt + from, len);
+}
+
static const struct hyperbus_ops am654_hbmc_ops = {
.calibrate = am654_hbmc_calibrate,
+ .copy_from = am654_hbmc_read,
};
+static int am654_hbmc_request_mmap_dma(struct am654_hbmc_device_priv *priv)
+{
+ struct dma_chan *rx_chan;
+ dma_cap_mask_t mask;
+
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_MEMCPY, mask);
+
+ rx_chan = dma_request_chan_by_mask();
+ if (IS_ERR(rx_chan)) {
+ if (PTR_ERR(rx_chan) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ return 0;
+ }
+ priv->rx_chan = rx_chan;
+ init_completion(>rx_dma_complete);
+
+ return 0;
+}
+
static int am654_hbmc_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
+ struct am654_hbmc_device_priv *dev_priv;
struct device *dev = >dev;
struct am654_hbmc_priv *priv;
struct resource res;
@@ -96,13 +202,31 @@ static int am654_hbmc_probe(struct platform_device *pdev)
priv->ctlr.dev = dev;
priv->ctlr.ops = _hbmc_ops;
priv->hbd
[PATCH 0/4] mtd: hyperbus: hbmc-am654: Add DMA support
This series add DMA support for reading data from HyperBus memory devices for TI's AM654/J721e SoCs With DMA there is ~5x improvement in read througput. Vignesh Raghavendra (4): mtd: hyperbus: Provide per device private pointer mtd: hyperbus: hbmc-am654: Fix direct mapping setup flash access mtd: hyperbus: hbmc-am654: Drop pm_runtime* calls from probe mtd: hyperbus: hbmc-am654: Add DMA support for reads drivers/mtd/hyperbus/hbmc-am654.c | 148 ++ include/linux/mtd/hyperbus.h | 2 + 2 files changed, 134 insertions(+), 16 deletions(-) -- 2.28.0
[PATCH 1/4] mtd: hyperbus: Provide per device private pointer
Provide per device private pointer that can be used by controller
drivers to store device specific private data.
Signed-off-by: Vignesh Raghavendra
---
include/linux/mtd/hyperbus.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/mtd/hyperbus.h b/include/linux/mtd/hyperbus.h
index 2129f7d3b6eb..d8cb1aec826d 100644
--- a/include/linux/mtd/hyperbus.h
+++ b/include/linux/mtd/hyperbus.h
@@ -20,6 +20,7 @@ enum hyperbus_memtype {
* @mtd: pointer to MTD struct
* @ctlr: pointer to HyperBus controller struct
* @memtype: type of memory device: HyperFlash or HyperRAM
+ * @priv: pointer to controller specific per device private data
*/
struct hyperbus_device {
@@ -28,6 +29,7 @@ struct hyperbus_device {
struct mtd_info *mtd;
struct hyperbus_ctlr *ctlr;
enum hyperbus_memtype memtype;
+ void *priv;
};
/**
--
2.28.0
Re: [PATCH v12 00/14] mtd: spi-nor: add xSPI Octal DTR support
On 9/15/20 1:17 PM, Pratyush Yadav wrote:
> On 15/09/20 12:16PM, Vignesh Raghavendra wrote:
>>
>>
>> On 9/3/20 10:42 PM, Pratyush Yadav wrote:
>>> Hi,
>>>
>>> This series adds support for Octal DTR flashes in the SPI NOR framework,
>>> and then adds hooks for the Cypress Semper and Micron Xcella flashes to
>>> allow running them in Octal DTR mode. This series assumes that the flash
>>> is handed to the kernel in Legacy SPI mode.
>>>
>>> Tested on TI J721E EVM with 1-bit ECC on the Cypress flash.
>>>
>> [...]
>>
>> Please fix checkpatch issues on patch 1, 3, 4 and 5
>
> I ran checkpatch on my patches based on top of next-20200914 just now. I
> only see issues with patches 3 and 4. Patches 1 and 5 report no issues.
> What problems do you see on patches 1 and 5?
>
Please run with --strict argument to checkpatch. You can see the issues
at: https://pastebin.ubuntu.com/p/5pPWcGNsmp/
> As for patches 3 and 4, the error I see is "ENOTSUPP is not a SUSV4
> error code, prefer EOPNOTSUPP". I left it in intentionally. There a
> couple other functions in SPI NOR that use ENOTSUPP instead of
> EOPNOTSUPP so I followed the local convention.
>
This is a recent addition to checkpatch: 6b9ea5ff5abd ("checkpatch: warn
about uses of ENOTSUPP").
> If you insist, I can add a preparatory patch that first changes those
> uses of ENOTSUPP to EOPNOTSUPP and then update patches 3 and 4 to do the
> same. Let me know.
>
Changing existing usage of ENOTSUPP to EOPNOTSUPP is a separate exercise
and patches are welcome. But any new addition of ENOTSUPP would need to
be avoided.
Regards
Vignesh
Re: [PATCH v12 00/14] mtd: spi-nor: add xSPI Octal DTR support
On 9/3/20 10:42 PM, Pratyush Yadav wrote:
> Hi,
>
> This series adds support for Octal DTR flashes in the SPI NOR framework,
> and then adds hooks for the Cypress Semper and Micron Xcella flashes to
> allow running them in Octal DTR mode. This series assumes that the flash
> is handed to the kernel in Legacy SPI mode.
>
> Tested on TI J721E EVM with 1-bit ECC on the Cypress flash.
>
[...]
Please fix checkpatch issues on patch 1, 3, 4 and 5
Otherwise patches look good to me...
>
> Pratyush Yadav (14):
> mtd: spi-nor: core: add spi_nor_{read,write}_reg() helpers
> mtd: spi-nor: core: add spi_nor_controller_ops_erase helper
> mtd: spi-nor: add support for DTR protocol
> mtd: spi-nor: sfdp: get command opcode extension type from BFPT
> mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
> mtd: spi-nor: core: use dummy cycle and address width info from SFDP
> mtd: spi-nor: core: do 2 byte reads for SR and FSR in DTR mode
> mtd: spi-nor: core: enable octal DTR mode when possible
> mtd: spi-nor: sfdp: detect Soft Reset sequence support from BFPT
> mtd: spi-nor: core: perform a Soft Reset on shutdown
> mtd: spi-nor: core: disable Octal DTR mode on suspend.
> mtd: spi-nor: core: expose spi_nor_default_setup() in core.h
> mtd: spi-nor: spansion: add support for Cypress Semper flash
> mtd: spi-nor: micron-st: allow using MT35XU512ABA in Octal DTR mode
>
> drivers/mtd/spi-nor/core.c | 462
> drivers/mtd/spi-nor/core.h | 23 ++
> drivers/mtd/spi-nor/micron-st.c | 102 ++-
> drivers/mtd/spi-nor/sfdp.c | 122 -
> drivers/mtd/spi-nor/sfdp.h | 8 +
> drivers/mtd/spi-nor/spansion.c | 166
> include/linux/mtd/spi-nor.h | 53 +++-
> 7 files changed, 813 insertions(+), 123 deletions(-)
Re: [PATCH 1/3] mtd: spi-nor: sst: fix write support for SST_WRITE marked devices
On 9/11/20 8:17 PM, Marco Felsch wrote:
> The sst write support for devices using the special SST_WRITE routine
> is broken since commit commit df5c21002cf4 ("mtd: spi-nor: use spi-mem
> dirmap API") because the spi_nor_create_write_dirmap() function checks
> SPINOR_OP_AAI_WP and sst_write_second. These checks are not valid during
> probe. The check seems also to be broken since the "op->addr.nbytes = 0"
> causes the devm_spi_mem_dirmap_create() function to return
> PTR_ERR(-EINVAL) and the probe() function will fail.
>
> It seems that the commit only copy'n'pasted the existing logic. Use the
> correct SST_WRITE flag and return 0 to fix both issues.
>
> Fixes: df5c21002cf4 ("mtd: spi-nor: use spi-mem dirmap API")
> Signed-off-by: Marco Felsch
> ---
> drivers/mtd/spi-nor/core.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 65eff4ce6ab1..31869ac245a8 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3289,15 +3289,21 @@ static int spi_nor_create_write_dirmap(struct spi_nor
> *nor)
> };
> struct spi_mem_op *op = _tmpl;
>
> + /*
> + * Most SST SPI-NOR's have a special write routine.which should so
s/SPI-NOR/SPI NOR.
> + * dirmap.wdesc is not supported for these.
Or How about more readable version:
"Most SST flashes have special sequence for writing data to the flash
and therefore cannot support writes through direct mapping APIs."
> + */
> + if (nor->info->flags & SST_WRITE) {
> + nor->dirmap.wdesc = NULL;
nor->dirmap.wdesc is known to be NULL at this point. So no need to set
to NULL again.
> + return 0;
> + }
> +
> /* get transfer protocols. */
> op->cmd.buswidth = spi_nor_get_protocol_inst_nbits(nor->write_proto);
> op->addr.buswidth = spi_nor_get_protocol_addr_nbits(nor->write_proto);
> op->dummy.buswidth = op->addr.buswidth;
> op->data.buswidth = spi_nor_get_protocol_data_nbits(nor->write_proto);
>
> - if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second)
> - op->addr.nbytes = 0;
> -
> nor->dirmap.wdesc = devm_spi_mem_dirmap_create(nor->dev, nor->spimem,
> );
> return PTR_ERR_OR_ZERO(nor->dirmap.wdesc);
>
Re: [PATCH] Platform integrity information in sysfs
Hi, On 9/3/20 9:48 PM, Daniel Gutson wrote: > This patch exports information about the platform integrity > firmware configuration in the sysfs filesystem. > In this initial patch, I include some configuration attributes > for the system SPI chip. > Please avoid first-person singular pronouns instead use imperative mood. > This initial version exports the BIOS Write Enable (bioswe), > BIOS Lock Enable (ble), and the SMM BIOS Write Protect (SMM_BWP) > fields of the BIOS Control register. The idea is to keep adding more > flags, not only from the BC but also from other registers in following > versions. > > The goal is that the attributes are avilable to fwupd when SecureBoot > is turned on. > s/avilable/available > The patch provides a new misc driver, as proposed in the previous patch, > that provides a registration function for HW Driver devices to register > class_attributes. > In this case, the intel SPI flash chip (intel-spi) registers three s/intel SPI/Intel SPI > class_attributes corresponding to the fields mentioned above. > > This version of the patch provides a new API supporting regular > device attributes rather than custom attributes, and also avoids > a race condition when exporting the driver sysfs dir and the > attributes files inside it. > Also, this patch renames 'platform lockdown' by 'platform integrity'. Changes wrt to previous versions should not be part of commit message but instead should be below tearline (b/w "---" and diffstat below) > > Signed-off-by: Daniel Gutson > --- Changes wrt previous versions go here... > .../ABI/stable/sysfs-class-platform-integrity | 23 + > MAINTAINERS | 7 ++ > drivers/misc/Kconfig | 11 +++ > drivers/misc/Makefile | 1 + > drivers/misc/platform-integrity.c | 61 + > drivers/mtd/spi-nor/controllers/Kconfig | 1 + > .../mtd/spi-nor/controllers/intel-spi-pci.c | 64 - > .../spi-nor/controllers/intel-spi-platform.c | 2 +- > drivers/mtd/spi-nor/controllers/intel-spi.c | 89 ++- > drivers/mtd/spi-nor/controllers/intel-spi.h | 5 +- > include/linux/platform-integrity.h| 20 + > 11 files changed, 278 insertions(+), 6 deletions(-) > create mode 100644 Documentation/ABI/stable/sysfs-class-platform-integrity > create mode 100644 drivers/misc/platform-integrity.c > create mode 100644 include/linux/platform-integrity.h > You forgot to cc linux-mtd lists and hence patch did not show up in my queue.. MTD Patches are managed via patchoworks and if linux-mtd is not cc'd then they will most likely be ignored. Please use scripts/get_maintainer.pl to get list of maintainters and mailing lists to cc. Also, this patch needs to be split into at least two patches: one introducing platform-integrity module and another adding suuport for intel-spi driver to use the same. Also, I see there are multiple iterations of the patch posted but are not versioned. Please use appropriate version number in $subject. Please read Documentation/process/submitting-patches.rst for more details. > diff --git a/Documentation/ABI/stable/sysfs-class-platform-integrity > b/Documentation/ABI/stable/sysfs-class-platform-integrity > new file mode 100644 > index ..b31ec051ca48 > --- /dev/null > +++ b/Documentation/ABI/stable/sysfs-class-platform-integrity > @@ -0,0 +1,23 @@ > +What:/sys/class/platform-integrity/intel-spi/bioswe > +Date:September 2020 > +KernelVersion: 5.9.1 5.9 merge window is closed. This won't make it to 5.9... Maybe 5.10 > +Contact: Daniel Gutson > +Description: If the system firmware set BIOS Write Enable. > + 0: writes disabled, 1: writes enabled. > +Users: https://github.com/fwupd/fwupd > + > +What:/sys/class/platform-integrity/intel-spi/ble Naming seems inconsistent... Previous entry was bioswe (BIOS write enable) but this one is called ble (BIOS latch enable). Maybe rename previous one as bwe to be consistent with other entries? > +Date:September 2020 > +KernelVersion: 5.9.1 > +Contact: Daniel Gutson > +Description: If the system firmware set BIOS Lock Enable. > + 0: SMM lock disabled, 1: SMM lock enabled. > +Users: https://github.com/fwupd/fwupd > + > +What:/sys/class/platform-integrity/intel-spi/smm_bwp > +Date:September 2020 > +KernelVersion: 5.9.1 > +Contact: Daniel Gutson > +Description: If the system firmware set SMM BIOS Write Protect. > + 0: writes disabled unless in SMM, 1: writes enabled. Is SMM a standard abbreviation in Intel world? If not you may want to expand what it means in Description. > +Users: https://github.com/fwupd/fwupd > diff --git a/MAINTAINERS b/MAINTAINERS > index e4647c84c987..771eaf715427 100644 > --- a/MAINTAINERS > +++
Re: [PATCH V2 4/8] arm64: dts: ti: k3-am65*: Use generic clock for syscon clock names
On 9/3/20 6:30 PM, Nishanth Menon wrote:
> serdes and ehrpwm_tbclk nodes should be using clock@ naming for nodes
> following standard conventions of device tree (section 2.2.2 Generic
> Names recommendation in [1]).
>
> [1] https://github.com/devicetree-org/devicetree-specification/tree/v0.3
>
> Suggested-by: Suman Anna
> Signed-off-by: Nishanth Menon
> Reviewed-by: Lokesh Vutla
> Acked-by: Suman Anna
> ---
> Change:
> v2: added ehrpwm_tbclk based on review comments.
> v1: https://lore.kernel.org/linux-arm-kernel/20200901223059.14801-3...@ti.com/
>
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> index a2fc508e59a6..63a1299cb0b2 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> @@ -327,12 +327,12 @@
> reg = <0x0210 0x4>;
> };
>
> - serdes0_clk: serdes_clk@4080 {
> + serdes0_clk: clock@4080 {
> compatible = "syscon";
> reg = <0x4080 0x4>;
> };
>
> - serdes1_clk: serdes_clk@4090 {
> + serdes1_clk: clock@4090 {
> compatible = "syscon";
> reg = <0x4090 0x4>;
> };
> @@ -349,7 +349,7 @@
> reg = <0x041e0 0x14>;
> };
>
> - ehrpwm_tbclk: syscon@4140 {
> + ehrpwm_tbclk: clock@4140 {
> compatible = "ti,am654-ehrpwm-tbclk", "syscon";
> reg = <0x4140 0x18>;
> #clock-cells = <1>;
>
Acked-by: Vignesh Raghavendra
Re: [PATCH V2 7/8] arm64: dts: ti: k3-am65-wakeup: Use generic temperature-sensor for node name
On 9/3/20 6:30 PM, Nishanth Menon wrote:
> Use temperature-sensor@ naming for nodes following standard conventions of
> device
> tree (section 2.2.2 Generic Names recommendation in [1]).
>
> [1] https://github.com/devicetree-org/devicetree-specification/tree/v0.3
>
> Suggested-by: Suman Anna
> Suggested-by: Vignesh Raghavendra
> Signed-off-by: Nishanth Menon
> Reviewed-by: Lokesh Vutla
> Reviewed-by: Suman Anna
Acked-by: Vignesh Raghavendra
> ---
> Changes:
> v2: None (picked acks/reviews)
> v1: https://lore.kernel.org/linux-arm-kernel/20200901223059.14801-6...@ti.com/
>
> arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
> b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
> index bb498be2f0a4..ed42f13e7663 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
> @@ -95,7 +95,7 @@
> clock-names = "gpio";
> };
>
> - wkup_vtm0: thermal@4205 {
> + wkup_vtm0: temperature-sensor@4205 {
> compatible = "ti,am654-vtm";
> reg = <0x4205 0x25c>;
> power-domains = <_pds 80 TI_SCI_PD_EXCLUSIVE>;
>
Re: [PATCH 6/7] arm64: dts: ti: k3-*: Use generic adc for node names
Hi Nishanth,
On 9/2/20 11:48 PM, Nishanth Menon wrote:
> On 11:51-20200902, Suman Anna wrote:
>> On 9/1/20 5:30 PM, Nishanth Menon wrote:
>>> Use adc@ naming for nodes following standard conventions of device
>>> tree (section 2.2.2 Generic Names recommendation in [1]).
>>>
>>> [1] https://github.com/devicetree-org/devicetree-specification/tree/v0.3
>>>
>>> Suggested-by: Suman Anna
>>> Signed-off-by: Nishanth Menon
>>> ---
>>> arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 4 ++--
>>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 4 ++--
>>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>>> b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>>> index 51ca4b4d4c21..6dfec68ac865 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>>> +++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>>> @@ -80,7 +80,7 @@
>>> #size-cells = <0>;
>>> };
>>>
>>> - tscadc0: tscadc@4020 {
>>> + tscadc0: adc@4020 {
>>
>> OK with these changes, since these seem to be only have the adc child nodes.
>> This node is essentially a parent node for touchscreen and adc child nodes.
>> The
>> driver is currently looking for "tsc" on touchscreen child nodes, but none of
>> the K3 SoCs have them atm.
>>
>
>
> Vignesh: are you ok with this, care to comment?
>
On K3 SoCs, ADC IP is reuse from AM335x but just lacks resistive
touchscreen interfaces. So, existing AM335x ADC driver is being reused
for K3 devices as well. Unfortunately, ADC driver cannot be used as
standalone and is dependent on MFD parent to be present...
Above node represents the MFD parent and ADC itself is the child node
(see arch/arm64/boot/dts/ti/k3-am654-base-board.dts). So, I recommend
that we keep this node's name as tscadc in order to avoid having same
name for parent and child node which will be quite confusing.
Regards
Vignesh
[PATCH v2] spi: spi-cadence-quadspi: Fix mapping of buffers for DMA reads
Buffers need to mapped to DMA channel's device pointer instead of SPI
controller's device pointer as its system DMA that actually does data
transfer.
Data inconsistencies have been reported when reading from flash
without this fix.
Fixes: ffa639e069fb ("mtd: spi-nor: cadence-quadspi: Add DMA support for direct
mode reads")
Signed-off-by: Vignesh Raghavendra
Tested-by: Jan Kiszka
---
v2:
Update the Fixes tag and add collect tested-by
drivers/spi/spi-cadence-quadspi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index 508b219eabf8..c6795c684b16 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -907,14 +907,16 @@ static int cqspi_direct_read_execute(struct
cqspi_flash_pdata *f_pdata,
struct dma_async_tx_descriptor *tx;
dma_cookie_t cookie;
dma_addr_t dma_dst;
+ struct device *ddev;
if (!cqspi->rx_chan || !virt_addr_valid(buf)) {
memcpy_fromio(buf, cqspi->ahb_base + from, len);
return 0;
}
- dma_dst = dma_map_single(dev, buf, len, DMA_FROM_DEVICE);
- if (dma_mapping_error(dev, dma_dst)) {
+ ddev = cqspi->rx_chan->device->dev;
+ dma_dst = dma_map_single(ddev, buf, len, DMA_FROM_DEVICE);
+ if (dma_mapping_error(ddev, dma_dst)) {
dev_err(dev, "dma mapping failed\n");
return -ENOMEM;
}
@@ -948,7 +950,7 @@ static int cqspi_direct_read_execute(struct
cqspi_flash_pdata *f_pdata,
}
err_unmap:
- dma_unmap_single(dev, dma_dst, len, DMA_FROM_DEVICE);
+ dma_unmap_single(ddev, dma_dst, len, DMA_FROM_DEVICE);
return ret;
}
--
2.28.0
Re: [PATCH] spi: spi-cadence-quadspi: Fix mapping of buffers for DMA reads
On 8/28/20 1:56 PM, Jan Kiszka wrote:
> On 28.08.20 09:47, Vignesh Raghavendra wrote:
>> Buffers need to mapped to DMA channel's device pointer instead of SPI
>> controller's device pointer as its system DMA that actually does data
>> transfer.
>> Data inconsistencies have been reported when reading from flash
>> without this fix.
>>
>> Fixes: 31fb632b5d43c ("spi: Move cadence-quadspi driver to drivers/spi/")
>
> This looks wrong, ...
>
>> Signed-off-by: Vignesh Raghavendra
>> ---
>>
>> This issue was present in the original driver under SPI NOR framework as
>> well.
>> But only got exposed as driver started handling probe deferral for DMA
>> channel
>> request and thus uses DMA almost always unlike before.
>
> ...you rather want 935da5e5100f57d843cac4781b21f1c235059aa0 then.
>
Actually, the offending code is actually from
commit ffa639e069fb ("mtd: spi-nor: cadence-quadspi: Add DMA support for direct
mode reads)
which adds dma_{un}map_single() calls.
Will send v2 with Fixes tag updated to point to above commit
> Other than that:
>
> Tested-by: Jan Kiszka
Thanks!
Regards
Vignesh
>
> Thanks!
> Jan
>
>>
>> drivers/spi/spi-cadence-quadspi.c | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/spi/spi-cadence-quadspi.c
>> b/drivers/spi/spi-cadence-quadspi.c
>> index 508b219eabf8..c6795c684b16 100644
>> --- a/drivers/spi/spi-cadence-quadspi.c
>> +++ b/drivers/spi/spi-cadence-quadspi.c
>> @@ -907,14 +907,16 @@ static int cqspi_direct_read_execute(struct
>> cqspi_flash_pdata *f_pdata,
>> struct dma_async_tx_descriptor *tx;
>> dma_cookie_t cookie;
>> dma_addr_t dma_dst;
>> +struct device *ddev;
>>
>> if (!cqspi->rx_chan || !virt_addr_valid(buf)) {
>> memcpy_fromio(buf, cqspi->ahb_base + from, len);
>> return 0;
>> }
>>
>> -dma_dst = dma_map_single(dev, buf, len, DMA_FROM_DEVICE);
>> -if (dma_mapping_error(dev, dma_dst)) {
>> +ddev = cqspi->rx_chan->device->dev;
>> +dma_dst = dma_map_single(ddev, buf, len, DMA_FROM_DEVICE);
>> +if (dma_mapping_error(ddev, dma_dst)) {
>> dev_err(dev, "dma mapping failed\n");
>> return -ENOMEM;
>> }
>> @@ -948,7 +950,7 @@ static int cqspi_direct_read_execute(struct
>> cqspi_flash_pdata *f_pdata,
>> }
>>
>> err_unmap:
>> -dma_unmap_single(dev, dma_dst, len, DMA_FROM_DEVICE);
>> +dma_unmap_single(ddev, dma_dst, len, DMA_FROM_DEVICE);
>>
>> return ret;
>> }
>>
>
[PATCH] spi: spi-cadence-quadspi: Fix mapping of buffers for DMA reads
Buffers need to mapped to DMA channel's device pointer instead of SPI
controller's device pointer as its system DMA that actually does data
transfer.
Data inconsistencies have been reported when reading from flash
without this fix.
Fixes: 31fb632b5d43c ("spi: Move cadence-quadspi driver to drivers/spi/")
Signed-off-by: Vignesh Raghavendra
---
This issue was present in the original driver under SPI NOR framework as well.
But only got exposed as driver started handling probe deferral for DMA channel
request and thus uses DMA almost always unlike before.
drivers/spi/spi-cadence-quadspi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index 508b219eabf8..c6795c684b16 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -907,14 +907,16 @@ static int cqspi_direct_read_execute(struct
cqspi_flash_pdata *f_pdata,
struct dma_async_tx_descriptor *tx;
dma_cookie_t cookie;
dma_addr_t dma_dst;
+ struct device *ddev;
if (!cqspi->rx_chan || !virt_addr_valid(buf)) {
memcpy_fromio(buf, cqspi->ahb_base + from, len);
return 0;
}
- dma_dst = dma_map_single(dev, buf, len, DMA_FROM_DEVICE);
- if (dma_mapping_error(dev, dma_dst)) {
+ ddev = cqspi->rx_chan->device->dev;
+ dma_dst = dma_map_single(ddev, buf, len, DMA_FROM_DEVICE);
+ if (dma_mapping_error(ddev, dma_dst)) {
dev_err(dev, "dma mapping failed\n");
return -ENOMEM;
}
@@ -948,7 +950,7 @@ static int cqspi_direct_read_execute(struct
cqspi_flash_pdata *f_pdata,
}
err_unmap:
- dma_unmap_single(dev, dma_dst, len, DMA_FROM_DEVICE);
+ dma_unmap_single(ddev, dma_dst, len, DMA_FROM_DEVICE);
return ret;
}
--
2.28.0
Re: [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel
On 8/26/20 7:01 PM, Jan Kiszka wrote:
> On 26.08.20 14:18, Vignesh Raghavendra wrote:
>> On 8/26/20 3:42 PM, Jan Kiszka wrote:
>>> On 24.08.20 19:20, Jan Kiszka wrote:
>>>> On 24.08.20 14:49, Jan Kiszka wrote:
>>>>> On 24.08.20 13:45, Vignesh Raghavendra wrote:
>>>>>>
[...]
>> Also, there seems to be DMA mapping related issue, that was always present
>> in
>> older driver as well. Could you see if diff [2] fixes the issue?
>>
>> [2] Use DMA device for mapping:
>>
>> ---><8---
>>
>>
>> diff --git a/drivers/spi/spi-cadence-quadspi.c
>> b/drivers/spi/spi-cadence-quadspi.c
>> index b9739ae919340..a546aa4598758 100644
>> --- a/drivers/spi/spi-cadence-quadspi.c
>> +++ b/drivers/spi/spi-cadence-quadspi.c
>> @@ -901,6 +901,7 @@ static int cqspi_direct_read_execute(struct
>> cqspi_flash_pdata *f_pdata,
>> {
>> struct cqspi_st *cqspi = f_pdata->cqspi;
>> struct device *dev = >pdev->dev;
>> + struct device *ddev = cqspi->rx_chan->device->dev;
>> enum dma_ctrl_flags flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
>> dma_addr_t dma_src = (dma_addr_t)cqspi->mmap_phys_base + from;
>> int ret = 0;
>> @@ -917,8 +918,8 @@ static int cqspi_direct_read_execute(struct
>> cqspi_flash_pdata *f_pdata,
>> return 0;
>> }
>>
>> - dma_dst = dma_map_single(dev, buf, len, DMA_FROM_DEVICE);
>> - if (dma_mapping_error(dev, dma_dst)) {
>> + dma_dst = dma_map_single(ddev, buf, len, DMA_FROM_DEVICE);
>> + if (dma_mapping_error(ddev, dma_dst)) {
>> dev_err(dev, "dma mapping failed\n");
>> return -ENOMEM;
>> }
>> @@ -952,7 +953,7 @@ static int cqspi_direct_read_execute(struct
>> cqspi_flash_pdata *f_pdata,
>> }
>>
>> err_unmap:
>> - dma_unmap_single(dev, dma_dst, len, DMA_FROM_DEVICE);
>> + dma_unmap_single(ddev, dma_dst, len, DMA_FROM_DEVICE);
>>
>> return ret;
>> }
>>
>
> That seems to help! Wasn't able to reproduce the issue with this applied
> so far.
>
OK, great... I will post this patch soon once I finish a bit more
testing... Thanks!
Regards
Vignesh
Re: [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel
On 8/26/20 3:42 PM, Jan Kiszka wrote:
> On 24.08.20 19:20, Jan Kiszka wrote:
>> On 24.08.20 14:49, Jan Kiszka wrote:
>>> 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
>>>>>> Reviewed-by: Tudor Ambarus
>>>>>> ---
>>>> [...]
>>>>>>
>>>>>> 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 * 0x1)
>>>>>out.write(mtd.read(0x1))
>>>>> 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.
>>
>> Done so now, could reproduce.
>
> ..."could *not* reproduce" there. Sorry if that caused confusion.
>
Oh, thanks! I was wondering why I cannot see this issue on AM654 EVM at my
end...
>>
>> But the OSPIs are definitely different. EVM reports
>>
>> spi-nor spi0.0: mt35xu512aba (65536 Kbytes)
>>
>> with 4K erase size. Our our board, we have
>>
>> spi-nor spi7.0: w25q128 (16384 Kbytes)
>>
>> with 64K erase size.
>>
>> Here is some extract of the hex-diffs between out.bin and out2.bin (the
>> latter being the good one):
>>
>> --- /dev/fd/63 2020-08-24 17:16:58.776409282 +
>> +++ /dev/fd/62 2020-08-24 17:16:58.776409282 +
>> @@ -6,18 +6,18 @@
>> 0050 0f 30 0d 06 03 55 04 07 0c 06 44 61 6c 6c 61 73
>> |.0...UDallas|
>> 0060 31 27 30 25 06 03 55 04 0a 0c 1e 54 65 78 61 73
>> |1'0%..UTexas|
>> 0070 20 49 6e 73 74 72 75 6d 65 6e 74 73 20 49 6e 63 | Instruments
>> Inc|
>> -0080 84 8b 96 2c 0c 12 18 03 01 05 05 04 01 02 00 00
>> |...,|
>> -0090 07 06 44 45 20 01 0d 14 2a 01 00 32 05 24 30 48 |..DE
>> ...*..2.$0H|
>> -00a0 60 6c 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04
>> |`l0.|
>> -00b0 01 00 00 0f ac 02 0c 00 2d 1a 6f 18 17
[PATCH] spi: spi-cadence-quadspi: Populate get_name() interface
Implement get_name() interface of spi_controller_mem_ops so as to avoid
changing of mtd->name due to driver being moved over to spi-mem
framework from SPI NOR. This avoids breaking of MTD cmdline args being
passed by bootloaders which maybe using old driver name.
Fixes: 31fb632b5d43c ("spi: Move cadence-quadspi driver to drivers/spi/")
Reported-by: Jan Kiszka
Suggested-by: Boris Brezillon
Signed-off-by: Vignesh Raghavendra
---
drivers/spi/spi-cadence-quadspi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index 1c1a9d17eec0d..508b219eabf80 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1128,8 +1128,17 @@ static int cqspi_request_mmap_dma(struct cqspi_st *cqspi)
return 0;
}
+static const char *cqspi_get_name(struct spi_mem *mem)
+{
+ struct cqspi_st *cqspi = spi_master_get_devdata(mem->spi->master);
+ struct device *dev = >pdev->dev;
+
+ return devm_kasprintf(dev, GFP_KERNEL, "%s.%d", dev_name(dev),
mem->spi->chip_select);
+}
+
static const struct spi_controller_mem_ops cqspi_mem_ops = {
.exec_op = cqspi_exec_mem_op,
+ .get_name = cqspi_get_name,
};
static int cqspi_setup_flash(struct cqspi_st *cqspi)
--
2.28.0
Re: [RESEND PATCH v3 7/8] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
Hi Jan,
On 8/24/20 11:25 AM, Jan Kiszka wrote:
[...]
>> +MODULE_AUTHOR("Vignesh Raghavendra ");
>>
> On the AM65x, this changes mtd->name (thus mtd-id for
> parser/cmdlinepart) from 4704.spi.0 to spi7.0. The besides having to
> deal with both names now, "spi7" sounds like it could easily change
> again if someone plugs or unplugs some other SPI device. Is this intended?
>
You could use DT aliases to make sure OSPI0 is always at given bus num
(say spi7):
aliases {
spi7 =
};
Regards
Vignesh
Re: [RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel
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
>> Reviewed-by: Tudor Ambarus
>> ---
[...]
>>
>> 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 * 0x1)
>out.write(mtd.read(0x1))
> 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?
Does this fail even on AM654 EVM? Could you share full script for me to
test locally?
What is the flash on the board?
>
> with open("out2.bin", "wb") as out:
> with open("/dev/mtd0", "rb") as mtd:
> out.write(mtd.read(0x2))
>
> (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
>
[PATCH 1/2] arm64: dts: ti: k3-j7200: Add HyperBus node
J7200 has a Flash SubSystem that has one OSPI and one HyperBus.. Add
DT nodes for HyperBus controller for now.
Signed-off-by: Vignesh Raghavendra
---
.../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 27 +++
arch/arm64/boot/dts/ti/k3-j7200.dtsi | 8 --
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
index 94a797bbcdaf0..106c774dc224a 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -114,4 +114,31 @@ wkup_i2c0: i2c@4212 {
clocks = <_clks 197 1>;
power-domains = <_pds 197 TI_SCI_PD_SHARED>;
};
+
+ fss: system-controller@4700 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x0 0x4700 0x0 0x100>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ hbmc_mux: hbmc-mux {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x4 0x2>; /* HBMC select */
+ };
+
+ hbmc: hyperbus@47034000 {
+ compatible = "ti,am654-hbmc";
+ reg = <0x0 0x47034000 0x0 0x100>,
+ <0x5 0x 0x1 0x000>;
+ power-domains = <_pds 102 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 102 0>;
+ assigned-clocks = <_clks 102 5>;
+ assigned-clock-rates = <3>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ mux-controls = <_mux 0>;
+ };
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-j7200.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200.dtsi
index aadf707f25f5c..ba27f6641137e 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200.dtsi
@@ -139,7 +139,9 @@ cbass_main: bus@10 {
<0x00 0x4510 0x00 0x4510 0x00 0x00c24000>,
<0x00 0x4600 0x00 0x4600 0x00 0x0020>,
<0x00 0x4700 0x00 0x4700 0x00 0x00068400>,
-<0x00 0x5000 0x00 0x5000 0x00 0x1000>;
+<0x00 0x5000 0x00 0x5000 0x00 0x1000>,
+<0x05 0x 0x05 0x 0x01 0x>,
+<0x07 0x 0x07 0x 0x01 0x>;
cbass_mcu_wakeup: bus@2838 {
compatible = "simple-bus";
@@ -155,7 +157,9 @@ cbass_mcu_wakeup: bus@2838 {
<0x00 0x4510 0x00 0x4510 0x00
0x00c24000>, /* MMRs, remaining NAVSS */
<0x00 0x4600 0x00 0x4600 0x00
0x0020>, /* CPSW */
<0x00 0x4700 0x00 0x4700 0x00
0x00068400>, /* OSPI register space */
-<0x00 0x5000 0x00 0x5000 0x00
0x1000>; /* FSS OSPI0/1 data region 0 */
+<0x00 0x5000 0x00 0x5000 0x00
0x1000>, /* FSS OSPI0/1 data region 0 */
+<0x05 0x 0x05 0x 0x01
0x>, /* FSS OSPI0 data region 3 */
+<0x07 0x 0x07 0x 0x01
0x>; /* FSS OSPI1 data region 3 */
};
};
};
--
2.28.0
[PATCH 0/2] arm64: dts: ti: k3-j7200: Add HyperFlash related nodes
This series adds HyperBus and HyperFlash nodes for TI's J7200 SoC Based on top of https://lore.kernel.org/linux-arm-kernel/20200723084628.19241-1-lokeshvu...@ti.com/ And earlier I2C DT patches: https://lore.kernel.org/linux-arm-kernel/20200730192600.1872-1-vigne...@ti.com/ Vignesh Raghavendra (2): arm64: dts: ti: k3-j7200: Add HyperBus node arm64: dts: ti: k3-j7200-som-p0: Add HyperFlash node .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 27 ++ arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 36 +++ arch/arm64/boot/dts/ti/k3-j7200.dtsi | 8 +++-- 3 files changed, 69 insertions(+), 2 deletions(-) -- 2.28.0
[PATCH 2/2] arm64: dts: ti: k3-j7200-som-p0: Add HyperFlash node
J7200 SoM has a HyperFlash connected to HyperBus memory controller. But
HyperBus is muxed with OSPI, therefore keep HyperBus node disabled.
Bootloader will detect the mux and enable the node as required.
Signed-off-by: Vignesh Raghavendra
---
arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 36 +
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
index 22fc50bd5c4c4..0984977f381ad 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
@@ -27,3 +27,39 @@ secure_ddr: optee@9e80 {
};
};
};
+
+_pmx0 {
+ mcu_fss0_hpb0_pins_default: mcu-fss0-hpb0-pins-default {
+ pinctrl-single,pins = <
+ J721E_WKUP_IOPAD(0x0, PIN_OUTPUT, 1) /* (B6)
MCU_OSPI0_CLK.MCU_HYPERBUS0_CK */
+ J721E_WKUP_IOPAD(0x4, PIN_OUTPUT, 1) /* (C8)
MCU_OSPI0_LBCLKO.MCU_HYPERBUS0_CKn */
+ J721E_WKUP_IOPAD(0x2c, PIN_OUTPUT, 1) /* (D6)
MCU_OSPI0_CSn0.MCU_HYPERBUS0_CSn0 */
+ J721E_WKUP_IOPAD(0x30, PIN_OUTPUT, 1) /* (D7)
MCU_OSPI0_CSn1.MCU_HYPERBUS0_RESETn */
+ J721E_WKUP_IOPAD(0x8, PIN_INPUT, 1) /* (B7)
MCU_OSPI0_DQS.MCU_HYPERBUS0_RWDS */
+ J721E_WKUP_IOPAD(0xc, PIN_INPUT, 1) /* (D8)
MCU_OSPI0_D0.MCU_HYPERBUS0_DQ0 */
+ J721E_WKUP_IOPAD(0x10, PIN_INPUT, 1) /* (C7)
MCU_OSPI0_D1.MCU_HYPERBUS0_DQ1 */
+ J721E_WKUP_IOPAD(0x14, PIN_INPUT, 1) /* (C5)
MCU_OSPI0_D2.MCU_HYPERBUS0_DQ2 */
+ J721E_WKUP_IOPAD(0x18, PIN_INPUT, 1) /* (A5)
MCU_OSPI0_D3.MCU_HYPERBUS0_DQ3 */
+ J721E_WKUP_IOPAD(0x1c, PIN_INPUT, 1) /* (A6)
MCU_OSPI0_D4.MCU_HYPERBUS0_DQ4 */
+ J721E_WKUP_IOPAD(0x20, PIN_INPUT, 1) /* (B8)
MCU_OSPI0_D5.MCU_HYPERBUS0_DQ5 */
+ J721E_WKUP_IOPAD(0x24, PIN_INPUT, 1) /* (A8)
MCU_OSPI0_D6.MCU_HYPERBUS0_DQ6 */
+ J721E_WKUP_IOPAD(0x28, PIN_INPUT, 1) /* (A7)
MCU_OSPI0_D7.MCU_HYPERBUS0_DQ7 */
+ >;
+ };
+};
+
+ {
+ /* OSPI and HBMC are muxed inside FSS, Bootloader will enable
+* appropriate node based on board detection
+*/
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <_fss0_hpb0_pins_default>;
+ ranges = <0x0 0x0 0x5 0x 0x400>, /* 64MB Flash on CS0 */
+<0x1 0x0 0x5 0x0400 0x80>; /* 8MB RAM on CS1 */
+
+ flash@0,0 {
+ compatible = "cypress,hyperflash", "cfi-flash";
+ reg = <0x0 0x0 0x400>;
+ };
+};
--
2.28.0
[PATCH 0/2] J7200: Add I2C support
Add I2C and I2C IO expanders nodes for J7200 Based on top of https://lore.kernel.org/linux-arm-kernel/20200723084628.19241-1-lokeshvu...@ti.com/ Vignesh Raghavendra (2): arm64: dts: ti: j7200: Add I2C nodes arm64: dts: ti: k3-j7200-common-proc-board: Add I2C IO expanders .../dts/ti/k3-j7200-common-proc-board.dts | 49 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 77 +++ .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 33 3 files changed, 159 insertions(+) -- 2.28.0
[PATCH 2/2] arm64: dts: ti: k3-j7200-common-proc-board: Add I2C IO expanders
Add DT nodes for I2C GPIO expanders on main_i2c0 and main_i2c1 and
also add the pinmux corresponding to these I2C instances.
Signed-off-by: Vignesh Raghavendra
---
.../dts/ti/k3-j7200-common-proc-board.dts | 49 +++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index e27069317c4e5..26ad2e46009e3 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -14,6 +14,22 @@ chosen {
};
};
+_pmx0 {
+ main_i2c0_pins_default: main-i2c0-pins-default {
+ pinctrl-single,pins = <
+ J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL
*/
+ J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA
*/
+ >;
+ };
+
+ main_i2c1_pins_default: main-i2c1-pins-default {
+ pinctrl-single,pins = <
+ J721E_IOPAD(0xdc, PIN_INPUT_PULLUP, 3) /* (U3)
ECAP0_IN_APWM_OUT.I2C1_SCL */
+ J721E_IOPAD(0xe0, PIN_INPUT_PULLUP, 3) /* (T3)
EXT_REFCLK1.I2C1_SDA */
+ >;
+ };
+};
+
_uart0 {
/* Wakeup UART is used by System firmware */
status = "disabled";
@@ -62,3 +78,36 @@ _uart9 {
/* UART not brought out */
status = "disabled";
};
+
+_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0_pins_default>;
+ clock-frequency = <40>;
+
+ exp1: gpio@20 {
+ compatible = "ti,tca6416";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ exp2: gpio@22 {
+ compatible = "ti,tca6424";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+_i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c1_pins_default>;
+ clock-frequency = <40>;
+
+ exp4: gpio@20 {
+ compatible = "ti,tca6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
--
2.28.0
[PATCH 1/2] arm64: dts: ti: j7200: Add I2C nodes
J7200 has 7 I2Cs main domain, 2 I2Cs in MCU and one in wakeup domain.
Add DT nodes of the same.
Signed-off-by: Vignesh Raghavendra
---
arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 77 +++
.../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 33
2 files changed, 110 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index 70c8f7e941fbf..0a87fa3ea5f0c 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -196,4 +196,81 @@ main_uart9: serial@289 {
clocks = <_clks 286 2>;
clock-names = "fclk";
};
+
+ main_i2c0: i2c@200 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x200 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 187 1>;
+ power-domains = <_pds 187 TI_SCI_PD_SHARED>;
+ };
+
+ main_i2c1: i2c@201 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x201 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 188 1>;
+ power-domains = <_pds 188 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ main_i2c2: i2c@202 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x202 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 189 1>;
+ power-domains = <_pds 189 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ main_i2c3: i2c@203 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x203 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 190 1>;
+ power-domains = <_pds 190 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ main_i2c4: i2c@204 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x204 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 191 1>;
+ power-domains = <_pds 191 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ main_i2c5: i2c@205 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x205 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 192 1>;
+ power-domains = <_pds 192 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ main_i2c6: i2c@206 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x206 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 193 1>;
+ power-domains = <_pds 193 TI_SCI_PD_EXCLUSIVE>;
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
index 670e4c7cd9fed..94a797bbcdaf0 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -81,4 +81,37 @@ mcu_uart0: serial@40a0 {
clocks = <_clks 149 2>;
clock-names = "fclk";
};
+
+ mcu_i2c0: i2c@40b0 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x40b0 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 194 1>;
+ power-domains = <_pds 194 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ mcu_i2c1: i2c@40b1 {
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x40b1 0x0 0x100>;
+
Re: [PATCH v3 8/8] spi: Move cadence-quadspi driver to drivers/spi/
On 01/06/20 12:30 pm, tudor.amba...@microchip.com wrote:
> Hi, Mark,
>
> On Monday, June 1, 2020 8:47:25 AM EEST Vignesh Raghavendra wrote:
>> From: Ramuthevar Vadivel Murugan
>>
>>
>> Now that cadence-quadspi has been converted to use spi-mem framework,
>> move it under drivers/spi/
>>
>> Update license header to match SPI subsystem style
>>
>> Signed-off-by: Ramuthevar Vadivel Murugan
>> Signed-off-by: Vignesh
>> Raghavendra
>> ---
>> drivers/mtd/spi-nor/controllers/Kconfig| 11 ---
>> drivers/mtd/spi-nor/controllers/Makefile | 1 -
>> drivers/spi/Kconfig| 11 +++
>> drivers/spi/Makefile | 1 +
>> .../spi-cadence-quadspi.c} | 14 +++---
>> 5 files changed, 19 insertions(+), 19 deletions(-)
>> rename drivers/{mtd/spi-nor/controllers/cadence-quadspi.c =>
>> spi/spi-cadence-quadspi.c} (99%)
>
> If this patch set looks good to you, would you take it through the SPI tree?
> If so, I would need an immutable tag, so I can merge back in spi-nor/next in
> order to fix a small conflict that will appear in drivers/mtd/spi-nor/
> controllers/Kconfig. Vignesh would have to respin this patch on top of v5.7-
> rc1. With this addressed:
>
> Reviewed-by: Tudor Ambarus
>
I have resent v3 on top of v5.7-rc1 (also applies cleanly on spi tree's
for-next branch):
https://lore.kernel.org/linux-spi/20200601070444.16923-1-vigne...@ti.com/T/#t
[RESEND PATCH v3 8/8] spi: Move cadence-quadspi driver to drivers/spi/
From: Ramuthevar Vadivel Murugan
Now that cadence-quadspi has been converted to use spi-mem framework,
move it under drivers/spi/
Update license header to match SPI subsystem style
Signed-off-by: Ramuthevar Vadivel Murugan
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
drivers/mtd/spi-nor/controllers/Kconfig| 11 ---
drivers/mtd/spi-nor/controllers/Makefile | 1 -
drivers/spi/Kconfig| 11 +++
drivers/spi/Makefile | 1 +
.../spi-cadence-quadspi.c} | 14 +++---
5 files changed, 19 insertions(+), 19 deletions(-)
rename drivers/{mtd/spi-nor/controllers/cadence-quadspi.c =>
spi/spi-cadence-quadspi.c} (99%)
diff --git a/drivers/mtd/spi-nor/controllers/Kconfig
b/drivers/mtd/spi-nor/controllers/Kconfig
index 10b86660b8214..95fcd4b435be5 100644
--- a/drivers/mtd/spi-nor/controllers/Kconfig
+++ b/drivers/mtd/spi-nor/controllers/Kconfig
@@ -9,17 +9,6 @@ config SPI_ASPEED_SMC
and support for the SPI flash memory controller (SPI) for
the host firmware. The implementation only supports SPI NOR.
-config SPI_CADENCE_QUADSPI
- tristate "Cadence Quad SPI controller"
- depends on OF && (ARM || ARM64 || COMPILE_TEST)
- help
- Enable support for the Cadence Quad SPI Flash controller.
-
- Cadence QSPI is a specialized controller for connecting an SPI
- Flash over 1/2/4-bit wide bus. Enable this option if you have a
- device with a Cadence QSPI controller and want to access the
- Flash as an MTD device.
-
config SPI_HISI_SFC
tristate "Hisilicon FMC SPI-NOR Flash Controller(SFC)"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/mtd/spi-nor/controllers/Makefile
b/drivers/mtd/spi-nor/controllers/Makefile
index 46e6fbe586e34..e7abba491d983 100644
--- a/drivers/mtd/spi-nor/controllers/Makefile
+++ b/drivers/mtd/spi-nor/controllers/Makefile
@@ -1,6 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o
-obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o
obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o
obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o
obj-$(CONFIG_SPI_INTEL_SPI)+= intel-spi.o
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 741b9140992a8..a4f65d956fa0a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -200,6 +200,17 @@ config SPI_CADENCE
This selects the Cadence SPI controller master driver
used by Xilinx Zynq and ZynqMP.
+config SPI_CADENCE_QUADSPI
+ tristate "Cadence Quad SPI controller"
+ depends on OF && (ARM || ARM64 || COMPILE_TEST)
+ help
+ Enable support for the Cadence Quad SPI Flash controller.
+
+ Cadence QSPI is a specialized controller for connecting an SPI
+ Flash over 1/2/4-bit wide bus. Enable this option if you have a
+ device with a Cadence QSPI controller and want to access the
+ Flash as an MTD device.
+
config SPI_CLPS711X
tristate "CLPS711X host SPI controller"
depends on ARCH_CLPS711X || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 28f601327f8c7..c02caeeb99b85 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_SPI_BCM_QSPI)+= spi-iproc-qspi.o
spi-brcmstb-qspi.o spi-bcm-qspi.
obj-$(CONFIG_SPI_BITBANG) += spi-bitbang.o
obj-$(CONFIG_SPI_BUTTERFLY)+= spi-butterfly.o
obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o
+obj-$(CONFIG_SPI_CADENCE_QUADSPI) += spi-cadence-quadspi.o
obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o
obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o
obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
similarity index 99%
rename from drivers/mtd/spi-nor/controllers/cadence-quadspi.c
rename to drivers/spi/spi-cadence-quadspi.c
index c12a1c0191b92..1c1a9d17eec0d 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1,11 +1,11 @@
// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Driver for Cadence QSPI Controller
- *
- * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
- * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
- * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
- */
+//
+// Driver for Cadence QSPI Controller
+//
+// Copyright Altera Corporation (C) 2012-2014. All rights reserved.
+// Copyright Intel Corporation (C) 2019-2020. All rights reserved.
+// Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
+
#include
#include
#include
--
2.26.2
[RESEND PATCH v3 7/8] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
From: Ramuthevar Vadivel Murugan
Move cadence-quadspi driver to use spi-mem framework. This is required
to make the driver support for SPI NAND flashes in future.
Driver is feature compliant with existing SPI NOR version.
Signed-off-by: Ramuthevar Vadivel Murugan
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
.../mtd/spi-nor/controllers/cadence-quadspi.c | 476 +++---
1 file changed, 191 insertions(+), 285 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 6b1cbad25e3f6..c12a1c0191b92 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -3,6 +3,8 @@
* Driver for Cadence QSPI Controller
*
* Copyright Altera Corporation (C) 2012-2014. All rights reserved.
+ * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
*/
#include
#include
@@ -17,9 +19,6 @@
#include
#include
#include
-#include
-#include
-#include
#include
#include
#include
@@ -27,6 +26,7 @@
#include
#include
#include
+#include
#include
#define CQSPI_NAME "cadence-qspi"
@@ -36,16 +36,12 @@
#define CQSPI_NEEDS_WR_DELAY BIT(0)
#define CQSPI_DISABLE_DAC_MODE BIT(1)
-/* Capabilities mask */
-#define CQSPI_BASE_HWCAPS_MASK \
- (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
- SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
- SNOR_HWCAPS_PP)
+/* Capabilities */
+#define CQSPI_SUPPORTS_OCTAL BIT(0)
struct cqspi_st;
struct cqspi_flash_pdata {
- struct spi_nor nor;
struct cqspi_st *cqspi;
u32 clk_rate;
u32 read_delay;
@@ -57,8 +53,6 @@ struct cqspi_flash_pdata {
u8 addr_width;
u8 data_width;
u8 cs;
- boolregistered;
- booluse_direct_mode;
};
struct cqspi_st {
@@ -71,7 +65,6 @@ struct cqspi_st {
void __iomem*ahb_base;
resource_size_t ahb_size;
struct completion transfer_complete;
- struct mutexbus_mutex;
struct dma_chan *rx_chan;
struct completion rx_dma_complete;
@@ -85,6 +78,7 @@ struct cqspi_st {
boolrclk_en;
u32 trigger_address;
u32 wr_delay;
+ booluse_direct_mode;
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
@@ -283,9 +277,8 @@ static irqreturn_t cqspi_irq_handler(int this_irq, void
*dev)
return IRQ_HANDLED;
}
-static unsigned int cqspi_calc_rdreg(struct spi_nor *nor)
+static unsigned int cqspi_calc_rdreg(struct cqspi_flash_pdata *f_pdata)
{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
u32 rdreg = 0;
rdreg |= f_pdata->inst_width << CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB;
@@ -352,19 +345,21 @@ static int cqspi_exec_flash_cmd(struct cqspi_st *cqspi,
unsigned int reg)
return cqspi_wait_idle(cqspi);
}
-static int cqspi_command_read(struct spi_nor *nor, u8 opcode,
- u8 *rxbuf, size_t n_rx)
+static int cqspi_command_read(struct cqspi_flash_pdata *f_pdata,
+ const struct spi_mem_op *op)
{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqspi_st *cqspi = f_pdata->cqspi;
void __iomem *reg_base = cqspi->iobase;
+ u8 *rxbuf = op->data.buf.in;
+ u8 opcode = op->cmd.opcode;
+ size_t n_rx = op->data.nbytes;
unsigned int rdreg;
unsigned int reg;
size_t read_len;
int status;
if (!n_rx || n_rx > CQSPI_STIG_DATA_LEN_MAX || !rxbuf) {
- dev_err(nor->dev,
+ dev_err(>pdev->dev,
"Invalid input argument, len %zu rxbuf 0x%p\n",
n_rx, rxbuf);
return -EINVAL;
@@ -372,7 +367,7 @@ static int cqspi_command_read(struct spi_nor *nor, u8
opcode,
reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB;
- rdreg = cqspi_calc_rdreg(nor);
+ rdreg = cqspi_calc_rdreg(f_pdata);
writel(rdreg, reg_base + CQSPI_REG_RD_INSTR);
reg |= (0x1 << CQSPI_REG_CMDCTRL_RD_EN_LSB);
@@ -401,25 +396,36 @@ static int cqspi_command_read(struct spi_nor *nor, u8
opcode,
return 0;
}
-static int cqspi_command_write(struct spi_nor *nor, const u8 opcode,
- const u8 *txbuf, size_t n_tx)
+static int cqspi_command_write(struct cqspi_flash_pdata *f_pdata,
+ const struct spi_mem_op *op)
{
- struct cqspi_flash_pdata *f_pdata = nor-&g
[RESEND PATCH v3 3/8] mtd: spi-nor: cadence-quadspi: Don't initialize rx_dma_complete on failure
If driver fails to acquire DMA channel then don't initialize
rx_dma_complete struct as it won't be used.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 8a9e17f79d8d9..379e22c11c87f 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1180,6 +1180,7 @@ static void cqspi_request_mmap_dma(struct cqspi_st *cqspi)
if (IS_ERR(cqspi->rx_chan)) {
dev_err(>pdev->dev, "No Rx DMA available\n");
cqspi->rx_chan = NULL;
+ return;
}
init_completion(>rx_dma_complete);
}
--
2.26.2
[RESEND PATCH v3 2/8] mtd: spi-nor: cadence-quadspi: Provide a way to disable DAC mode
Currently direct access mode is used on platforms that have AHB window
(memory mapped window) larger than flash size. This feature is limited
to TI platforms as non TI platforms have < 1MB of AHB window.
Therefore introduce a driver quirk to disable DAC mode and set it for
non TI compatibles. This is in preparation to move to spi-mem framework
where flash geometry cannot be known.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 9b8554d44fac8..8a9e17f79d8d9 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -34,6 +34,7 @@
/* Quirks */
#define CQSPI_NEEDS_WR_DELAY BIT(0)
+#define CQSPI_DISABLE_DAC_MODE BIT(1)
/* Capabilities mask */
#define CQSPI_BASE_HWCAPS_MASK \
@@ -1261,7 +1262,8 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi,
struct device_node *np)
f_pdata->registered = true;
- if (mtd->size <= cqspi->ahb_size) {
+ if (mtd->size <= cqspi->ahb_size &&
+ !(ddata->quirks & CQSPI_DISABLE_DAC_MODE)) {
f_pdata->use_direct_mode = true;
dev_dbg(nor->dev, "using direct mode for %s\n",
mtd->name);
@@ -1457,6 +1459,7 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
static const struct cqspi_driver_platdata cdns_qspi = {
.hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+ .quirks = CQSPI_DISABLE_DAC_MODE,
};
static const struct cqspi_driver_platdata k2g_qspi = {
--
2.26.2
[RESEND PATCH v3 6/8] mtd: spi-nor: cadence-quadspi: Drop redundant WREN in erase path
Drop redundant WREN command in cqspi_erase() as SPI NOR core takes care of sending WREN command before sending erase command. Signed-off-by: Vignesh Raghavendra Reviewed-by: Tudor Ambarus --- drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c index 0570ebca135a9..6b1cbad25e3f6 100644 --- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c +++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c @@ -1016,11 +1016,6 @@ static int cqspi_erase(struct spi_nor *nor, loff_t offs) if (ret) return ret; - /* Send write enable, then erase commands. */ - ret = nor->controller_ops->write_reg(nor, SPINOR_OP_WREN, NULL, 0); - if (ret) - return ret; - /* Set up command buffer. */ ret = cqspi_command_write_addr(nor, nor->erase_opcode, offs); if (ret) -- 2.26.2
[RESEND PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel
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
Reviewed-by: Tudor Ambarus
---
.../mtd/spi-nor/controllers/cadence-quadspi.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 608ca657ff7f5..0570ebca135a9 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1169,7 +1169,7 @@ static void cqspi_controller_init(struct cqspi_st *cqspi)
cqspi_controller_enable(cqspi, 1);
}
-static void cqspi_request_mmap_dma(struct cqspi_st *cqspi)
+static int cqspi_request_mmap_dma(struct cqspi_st *cqspi)
{
dma_cap_mask_t mask;
@@ -1178,11 +1178,16 @@ static void cqspi_request_mmap_dma(struct cqspi_st
*cqspi)
cqspi->rx_chan = dma_request_chan_by_mask();
if (IS_ERR(cqspi->rx_chan)) {
- dev_err(>pdev->dev, "No Rx DMA available\n");
+ int ret = PTR_ERR(cqspi->rx_chan);
+
+ if (ret != -EPROBE_DEFER)
+ dev_err(>pdev->dev, "No Rx DMA available\n");
cqspi->rx_chan = NULL;
- return;
+ return ret;
}
init_completion(>rx_dma_complete);
+
+ return 0;
}
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;
+ }
}
}
--
2.26.2
[RESEND PATCH v3 0/8] mtd: spi-nor: Move cadence-qaudspi to spi-mem framework
This series is a subset of "[PATCH v12 0/4] spi: cadence-quadspi: Add
support for the Cadence QSPI controller" by Ramuthevar,Vadivel MuruganX
that intended to move
cadence-quadspi driver to spi-mem framework
Those patches were trying to accomplish too many things in a single set
of patches and need to split into smaller patches. This is reduced
version of above series.
Changes that are intended to make migration easy are split into separate
patches. Patches 1 to 3 drop features that cannot be supported under
spi-mem at the moment (backward compatibility is maintained).
Patch 4-5 are trivial cleanups. Patch 6 does the actual conversion to
spi-mem and patch 7 moves the driver to drivers/spi folder.
I have tested both INDAC mode (used by non TI platforms like Altera
SoCFPGA) and DAC mode (used by TI platforms) on TI EVMs.
Patches to move move bindings over to
"Documentation/devicetree/bindings/spi/" directory and also conversion
of bindig doc to YAML will be posted separately. Support for Intel
platform would follow that.
Resend v3:
Rebased onto v5.7-c1
v3:
Split handling of probe deferral into separate patch (out of 5/6)
Split dropping of redundant WREN to separate patch (out of 5/6)
Fix a possible memleak due to lack of spi_master_put()
Parse all SPI slave nodes in cqspi_setup_flash()
Address misc comments from Tudor on v2
Rebase onto latest spi-nor/next
v2:
Rework patch 1/6 to keep "cdns,is-decoded-cs" property supported.
Ramuthevar Vadivel Murugan (2):
mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
spi: Move cadence-quadspi driver to drivers/spi/
Vignesh Raghavendra (6):
mtd: spi-nor: cadence-quadspi: Make driver independent of flash
geometry
mtd: spi-nor: cadence-quadspi: Provide a way to disable DAC mode
mtd: spi-nor: cadence-quadspi: Don't initialize rx_dma_complete on
failure
mtd: spi-nor: cadence-quadspi: Fix error path on failure to acquire
reset lines
mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting
DMA channel
mtd: spi-nor: cadence-quadspi: Drop redundant WREN in erase path
drivers/mtd/spi-nor/controllers/Kconfig | 11 -
drivers/mtd/spi-nor/controllers/Makefile | 1 -
drivers/spi/Kconfig | 11 +
drivers/spi/Makefile | 1 +
.../spi-cadence-quadspi.c}| 541 +++---
5 files changed, 222 insertions(+), 343 deletions(-)
rename drivers/{mtd/spi-nor/controllers/cadence-quadspi.c =>
spi/spi-cadence-quadspi.c} (74%)
--
2.26.2
[RESEND PATCH v3 4/8] mtd: spi-nor: cadence-quadspi: Fix error path on failure to acquire reset lines
Make sure to undo the prior changes done by the driver when exiting due
to failure to acquire reset lines.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 379e22c11c87f..608ca657ff7f5 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1359,13 +1359,13 @@ static int cqspi_probe(struct platform_device *pdev)
rstc = devm_reset_control_get_optional_exclusive(dev, "qspi");
if (IS_ERR(rstc)) {
dev_err(dev, "Cannot get QSPI reset.\n");
- return PTR_ERR(rstc);
+ goto probe_reset_failed;
}
rstc_ocp = devm_reset_control_get_optional_exclusive(dev, "qspi-ocp");
if (IS_ERR(rstc_ocp)) {
dev_err(dev, "Cannot get QSPI OCP reset.\n");
- return PTR_ERR(rstc_ocp);
+ goto probe_reset_failed;
}
reset_control_assert(rstc);
@@ -1384,7 +1384,7 @@ static int cqspi_probe(struct platform_device *pdev)
pdev->name, cqspi);
if (ret) {
dev_err(dev, "Cannot request IRQ.\n");
- goto probe_irq_failed;
+ goto probe_reset_failed;
}
cqspi_wait_idle(cqspi);
@@ -1401,7 +1401,7 @@ static int cqspi_probe(struct platform_device *pdev)
return ret;
probe_setup_failed:
cqspi_controller_enable(cqspi, 0);
-probe_irq_failed:
+probe_reset_failed:
clk_disable_unprepare(cqspi->clk);
probe_clk_failed:
pm_runtime_put_sync(dev);
--
2.26.2
[RESEND PATCH v3 1/8] mtd: spi-nor: cadence-quadspi: Make driver independent of flash geometry
Drop configuration of Flash size, erase size and page size
configuration. Flash size is needed only if using AHB decoder (BIT 23 of
CONFIG_REG) which is not used by the driver.
Erase size and page size are needed if IP is configured to send WREN
automatically. But since SPI NOR layer takes care of sending WREN, there
is no need to configure these fields either.
Therefore drop these in preparation to move the driver to spi-mem
framework where flash geometry is not visible to controller driver.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
.../mtd/spi-nor/controllers/cadence-quadspi.c | 36 +--
1 file changed, 1 insertion(+), 35 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 494dcab4b..9b8554d44fac8 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -77,9 +77,6 @@ struct cqspi_st {
dma_addr_t mmap_phys_base;
int current_cs;
- int current_page_size;
- int current_erase_size;
- int current_addr_width;
unsigned long master_ref_clk_hz;
boolis_decoded_cs;
u32 fifo_depth;
@@ -736,32 +733,6 @@ static void cqspi_chipselect(struct spi_nor *nor)
writel(reg, reg_base + CQSPI_REG_CONFIG);
}
-static void cqspi_configure_cs_and_sizes(struct spi_nor *nor)
-{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
- struct cqspi_st *cqspi = f_pdata->cqspi;
- void __iomem *iobase = cqspi->iobase;
- unsigned int reg;
-
- /* configure page size and block size. */
- reg = readl(iobase + CQSPI_REG_SIZE);
- reg &= ~(CQSPI_REG_SIZE_PAGE_MASK << CQSPI_REG_SIZE_PAGE_LSB);
- reg &= ~(CQSPI_REG_SIZE_BLOCK_MASK << CQSPI_REG_SIZE_BLOCK_LSB);
- reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
- reg |= (nor->page_size << CQSPI_REG_SIZE_PAGE_LSB);
- reg |= (ilog2(nor->mtd.erasesize) << CQSPI_REG_SIZE_BLOCK_LSB);
- reg |= (nor->addr_width - 1);
- writel(reg, iobase + CQSPI_REG_SIZE);
-
- /* configure the chip select */
- cqspi_chipselect(nor);
-
- /* Store the new configuration of the controller */
- cqspi->current_page_size = nor->page_size;
- cqspi->current_erase_size = nor->mtd.erasesize;
- cqspi->current_addr_width = nor->addr_width;
-}
-
static unsigned int calculate_ticks_for_ns(const unsigned int ref_clk_hz,
const unsigned int ns_val)
{
@@ -867,18 +838,13 @@ static void cqspi_configure(struct spi_nor *nor)
int switch_cs = (cqspi->current_cs != f_pdata->cs);
int switch_ck = (cqspi->sclk != sclk);
- if ((cqspi->current_page_size != nor->page_size) ||
- (cqspi->current_erase_size != nor->mtd.erasesize) ||
- (cqspi->current_addr_width != nor->addr_width))
- switch_cs = 1;
-
if (switch_cs || switch_ck)
cqspi_controller_enable(cqspi, 0);
/* Switch chip select. */
if (switch_cs) {
cqspi->current_cs = f_pdata->cs;
- cqspi_configure_cs_and_sizes(nor);
+ cqspi_chipselect(nor);
}
/* Setup baudrate divisor and delays */
--
2.26.2
[PATCH v3 6/8] mtd: spi-nor: cadence-quadspi: Drop redundant WREN in erase path
Drop redundant WREN command in cqspi_erase() as SPI NOR core takes care of sending WREN command before sending erase command. Signed-off-by: Vignesh Raghavendra --- drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c index 0570ebca135a..6b1cbad25e3f 100644 --- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c +++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c @@ -1016,11 +1016,6 @@ static int cqspi_erase(struct spi_nor *nor, loff_t offs) if (ret) return ret; - /* Send write enable, then erase commands. */ - ret = nor->controller_ops->write_reg(nor, SPINOR_OP_WREN, NULL, 0); - if (ret) - return ret; - /* Set up command buffer. */ ret = cqspi_command_write_addr(nor, nor->erase_opcode, offs); if (ret) -- 2.26.2
[PATCH v3 7/8] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
From: Ramuthevar Vadivel Murugan
Move cadence-quadspi driver to use spi-mem framework. This is required
to make the driver support for SPI NAND flashes in future.
Driver is feature compliant with existing SPI NOR version.
Signed-off-by: Ramuthevar Vadivel Murugan
Signed-off-by: Vignesh Raghavendra
---
.../mtd/spi-nor/controllers/cadence-quadspi.c | 476 +++---
1 file changed, 191 insertions(+), 285 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 6b1cbad25e3f..c12a1c0191b9 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -3,6 +3,8 @@
* Driver for Cadence QSPI Controller
*
* Copyright Altera Corporation (C) 2012-2014. All rights reserved.
+ * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
*/
#include
#include
@@ -17,9 +19,6 @@
#include
#include
#include
-#include
-#include
-#include
#include
#include
#include
@@ -27,6 +26,7 @@
#include
#include
#include
+#include
#include
#define CQSPI_NAME "cadence-qspi"
@@ -36,16 +36,12 @@
#define CQSPI_NEEDS_WR_DELAY BIT(0)
#define CQSPI_DISABLE_DAC_MODE BIT(1)
-/* Capabilities mask */
-#define CQSPI_BASE_HWCAPS_MASK \
- (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
- SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
- SNOR_HWCAPS_PP)
+/* Capabilities */
+#define CQSPI_SUPPORTS_OCTAL BIT(0)
struct cqspi_st;
struct cqspi_flash_pdata {
- struct spi_nor nor;
struct cqspi_st *cqspi;
u32 clk_rate;
u32 read_delay;
@@ -57,8 +53,6 @@ struct cqspi_flash_pdata {
u8 addr_width;
u8 data_width;
u8 cs;
- boolregistered;
- booluse_direct_mode;
};
struct cqspi_st {
@@ -71,7 +65,6 @@ struct cqspi_st {
void __iomem*ahb_base;
resource_size_t ahb_size;
struct completion transfer_complete;
- struct mutexbus_mutex;
struct dma_chan *rx_chan;
struct completion rx_dma_complete;
@@ -85,6 +78,7 @@ struct cqspi_st {
boolrclk_en;
u32 trigger_address;
u32 wr_delay;
+ booluse_direct_mode;
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
@@ -283,9 +277,8 @@ static irqreturn_t cqspi_irq_handler(int this_irq, void
*dev)
return IRQ_HANDLED;
}
-static unsigned int cqspi_calc_rdreg(struct spi_nor *nor)
+static unsigned int cqspi_calc_rdreg(struct cqspi_flash_pdata *f_pdata)
{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
u32 rdreg = 0;
rdreg |= f_pdata->inst_width << CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB;
@@ -352,19 +345,21 @@ static int cqspi_exec_flash_cmd(struct cqspi_st *cqspi,
unsigned int reg)
return cqspi_wait_idle(cqspi);
}
-static int cqspi_command_read(struct spi_nor *nor, u8 opcode,
- u8 *rxbuf, size_t n_rx)
+static int cqspi_command_read(struct cqspi_flash_pdata *f_pdata,
+ const struct spi_mem_op *op)
{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqspi_st *cqspi = f_pdata->cqspi;
void __iomem *reg_base = cqspi->iobase;
+ u8 *rxbuf = op->data.buf.in;
+ u8 opcode = op->cmd.opcode;
+ size_t n_rx = op->data.nbytes;
unsigned int rdreg;
unsigned int reg;
size_t read_len;
int status;
if (!n_rx || n_rx > CQSPI_STIG_DATA_LEN_MAX || !rxbuf) {
- dev_err(nor->dev,
+ dev_err(>pdev->dev,
"Invalid input argument, len %zu rxbuf 0x%p\n",
n_rx, rxbuf);
return -EINVAL;
@@ -372,7 +367,7 @@ static int cqspi_command_read(struct spi_nor *nor, u8
opcode,
reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB;
- rdreg = cqspi_calc_rdreg(nor);
+ rdreg = cqspi_calc_rdreg(f_pdata);
writel(rdreg, reg_base + CQSPI_REG_RD_INSTR);
reg |= (0x1 << CQSPI_REG_CMDCTRL_RD_EN_LSB);
@@ -401,25 +396,36 @@ static int cqspi_command_read(struct spi_nor *nor, u8
opcode,
return 0;
}
-static int cqspi_command_write(struct spi_nor *nor, const u8 opcode,
- const u8 *txbuf, size_t n_tx)
+static int cqspi_command_write(struct cqspi_flash_pdata *f_pdata,
+ const struct spi_mem_op *op)
{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqs
[PATCH v3 2/8] mtd: spi-nor: cadence-quadspi: Provide a way to disable DAC mode
Currently direct access mode is used on platforms that have AHB window
(memory mapped window) larger than flash size. This feature is limited
to TI platforms as non TI platforms have < 1MB of AHB window.
Therefore introduce a driver quirk to disable DAC mode and set it for
non TI compatibles. This is in preparation to move to spi-mem framework
where flash geometry cannot be known.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 9b8554d44fac..8a9e17f79d8d 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -34,6 +34,7 @@
/* Quirks */
#define CQSPI_NEEDS_WR_DELAY BIT(0)
+#define CQSPI_DISABLE_DAC_MODE BIT(1)
/* Capabilities mask */
#define CQSPI_BASE_HWCAPS_MASK \
@@ -1261,7 +1262,8 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi,
struct device_node *np)
f_pdata->registered = true;
- if (mtd->size <= cqspi->ahb_size) {
+ if (mtd->size <= cqspi->ahb_size &&
+ !(ddata->quirks & CQSPI_DISABLE_DAC_MODE)) {
f_pdata->use_direct_mode = true;
dev_dbg(nor->dev, "using direct mode for %s\n",
mtd->name);
@@ -1457,6 +1459,7 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
static const struct cqspi_driver_platdata cdns_qspi = {
.hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+ .quirks = CQSPI_DISABLE_DAC_MODE,
};
static const struct cqspi_driver_platdata k2g_qspi = {
--
2.26.2
[PATCH v3 1/8] mtd: spi-nor: cadence-quadspi: Make driver independent of flash geometry
Drop configuration of Flash size, erase size and page size
configuration. Flash size is needed only if using AHB decoder (BIT 23 of
CONFIG_REG) which is not used by the driver.
Erase size and page size are needed if IP is configured to send WREN
automatically. But since SPI NOR layer takes care of sending WREN, there
is no need to configure these fields either.
Therefore drop these in preparation to move the driver to spi-mem
framework where flash geometry is not visible to controller driver.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
.../mtd/spi-nor/controllers/cadence-quadspi.c | 36 +--
1 file changed, 1 insertion(+), 35 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 494dcab4..9b8554d44fac 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -77,9 +77,6 @@ struct cqspi_st {
dma_addr_t mmap_phys_base;
int current_cs;
- int current_page_size;
- int current_erase_size;
- int current_addr_width;
unsigned long master_ref_clk_hz;
boolis_decoded_cs;
u32 fifo_depth;
@@ -736,32 +733,6 @@ static void cqspi_chipselect(struct spi_nor *nor)
writel(reg, reg_base + CQSPI_REG_CONFIG);
}
-static void cqspi_configure_cs_and_sizes(struct spi_nor *nor)
-{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
- struct cqspi_st *cqspi = f_pdata->cqspi;
- void __iomem *iobase = cqspi->iobase;
- unsigned int reg;
-
- /* configure page size and block size. */
- reg = readl(iobase + CQSPI_REG_SIZE);
- reg &= ~(CQSPI_REG_SIZE_PAGE_MASK << CQSPI_REG_SIZE_PAGE_LSB);
- reg &= ~(CQSPI_REG_SIZE_BLOCK_MASK << CQSPI_REG_SIZE_BLOCK_LSB);
- reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
- reg |= (nor->page_size << CQSPI_REG_SIZE_PAGE_LSB);
- reg |= (ilog2(nor->mtd.erasesize) << CQSPI_REG_SIZE_BLOCK_LSB);
- reg |= (nor->addr_width - 1);
- writel(reg, iobase + CQSPI_REG_SIZE);
-
- /* configure the chip select */
- cqspi_chipselect(nor);
-
- /* Store the new configuration of the controller */
- cqspi->current_page_size = nor->page_size;
- cqspi->current_erase_size = nor->mtd.erasesize;
- cqspi->current_addr_width = nor->addr_width;
-}
-
static unsigned int calculate_ticks_for_ns(const unsigned int ref_clk_hz,
const unsigned int ns_val)
{
@@ -867,18 +838,13 @@ static void cqspi_configure(struct spi_nor *nor)
int switch_cs = (cqspi->current_cs != f_pdata->cs);
int switch_ck = (cqspi->sclk != sclk);
- if ((cqspi->current_page_size != nor->page_size) ||
- (cqspi->current_erase_size != nor->mtd.erasesize) ||
- (cqspi->current_addr_width != nor->addr_width))
- switch_cs = 1;
-
if (switch_cs || switch_ck)
cqspi_controller_enable(cqspi, 0);
/* Switch chip select. */
if (switch_cs) {
cqspi->current_cs = f_pdata->cs;
- cqspi_configure_cs_and_sizes(nor);
+ cqspi_chipselect(nor);
}
/* Setup baudrate divisor and delays */
--
2.26.2
[PATCH v3 4/8] mtd: spi-nor: cadence-quadspi: Fix error path on failure to acquire reset lines
Make sure to undo the prior changes done by the driver when exiting due
to failure to acquire reset lines.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 379e22c11c87..608ca657ff7f 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1359,13 +1359,13 @@ static int cqspi_probe(struct platform_device *pdev)
rstc = devm_reset_control_get_optional_exclusive(dev, "qspi");
if (IS_ERR(rstc)) {
dev_err(dev, "Cannot get QSPI reset.\n");
- return PTR_ERR(rstc);
+ goto probe_reset_failed;
}
rstc_ocp = devm_reset_control_get_optional_exclusive(dev, "qspi-ocp");
if (IS_ERR(rstc_ocp)) {
dev_err(dev, "Cannot get QSPI OCP reset.\n");
- return PTR_ERR(rstc_ocp);
+ goto probe_reset_failed;
}
reset_control_assert(rstc);
@@ -1384,7 +1384,7 @@ static int cqspi_probe(struct platform_device *pdev)
pdev->name, cqspi);
if (ret) {
dev_err(dev, "Cannot request IRQ.\n");
- goto probe_irq_failed;
+ goto probe_reset_failed;
}
cqspi_wait_idle(cqspi);
@@ -1401,7 +1401,7 @@ static int cqspi_probe(struct platform_device *pdev)
return ret;
probe_setup_failed:
cqspi_controller_enable(cqspi, 0);
-probe_irq_failed:
+probe_reset_failed:
clk_disable_unprepare(cqspi->clk);
probe_clk_failed:
pm_runtime_put_sync(dev);
--
2.26.2
[PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel
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
---
.../mtd/spi-nor/controllers/cadence-quadspi.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 608ca657ff7f..0570ebca135a 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1169,7 +1169,7 @@ static void cqspi_controller_init(struct cqspi_st *cqspi)
cqspi_controller_enable(cqspi, 1);
}
-static void cqspi_request_mmap_dma(struct cqspi_st *cqspi)
+static int cqspi_request_mmap_dma(struct cqspi_st *cqspi)
{
dma_cap_mask_t mask;
@@ -1178,11 +1178,16 @@ static void cqspi_request_mmap_dma(struct cqspi_st
*cqspi)
cqspi->rx_chan = dma_request_chan_by_mask();
if (IS_ERR(cqspi->rx_chan)) {
- dev_err(>pdev->dev, "No Rx DMA available\n");
+ int ret = PTR_ERR(cqspi->rx_chan);
+
+ if (ret != -EPROBE_DEFER)
+ dev_err(>pdev->dev, "No Rx DMA available\n");
cqspi->rx_chan = NULL;
- return;
+ return ret;
}
init_completion(>rx_dma_complete);
+
+ return 0;
}
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;
+ }
}
}
--
2.26.2
[PATCH v3 8/8] spi: Move cadence-quadspi driver to drivers/spi/
From: Ramuthevar Vadivel Murugan
Now that cadence-quadspi has been converted to use spi-mem framework,
move it under drivers/spi/
Update license header to match SPI subsystem style
Signed-off-by: Ramuthevar Vadivel Murugan
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi-nor/controllers/Kconfig| 11 ---
drivers/mtd/spi-nor/controllers/Makefile | 1 -
drivers/spi/Kconfig| 11 +++
drivers/spi/Makefile | 1 +
.../spi-cadence-quadspi.c} | 14 +++---
5 files changed, 19 insertions(+), 19 deletions(-)
rename drivers/{mtd/spi-nor/controllers/cadence-quadspi.c =>
spi/spi-cadence-quadspi.c} (99%)
diff --git a/drivers/mtd/spi-nor/controllers/Kconfig
b/drivers/mtd/spi-nor/controllers/Kconfig
index d89a5ea9446a..5c0e0ec2e6d1 100644
--- a/drivers/mtd/spi-nor/controllers/Kconfig
+++ b/drivers/mtd/spi-nor/controllers/Kconfig
@@ -9,17 +9,6 @@ config SPI_ASPEED_SMC
and support for the SPI flash memory controller (SPI) for
the host firmware. The implementation only supports SPI NOR.
-config SPI_CADENCE_QUADSPI
- tristate "Cadence Quad SPI controller"
- depends on OF && (ARM || ARM64 || COMPILE_TEST)
- help
- Enable support for the Cadence Quad SPI Flash controller.
-
- Cadence QSPI is a specialized controller for connecting an SPI
- Flash over 1/2/4-bit wide bus. Enable this option if you have a
- device with a Cadence QSPI controller and want to access the
- Flash as an MTD device.
-
config SPI_HISI_SFC
tristate "Hisilicon FMC SPI NOR Flash Controller(SFC)"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/mtd/spi-nor/controllers/Makefile
b/drivers/mtd/spi-nor/controllers/Makefile
index 46e6fbe586e3..e7abba491d98 100644
--- a/drivers/mtd/spi-nor/controllers/Makefile
+++ b/drivers/mtd/spi-nor/controllers/Makefile
@@ -1,6 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o
-obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o
obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o
obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o
obj-$(CONFIG_SPI_INTEL_SPI)+= intel-spi.o
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 099d6a75a371..2de8098b26c1 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -200,6 +200,17 @@ config SPI_CADENCE
This selects the Cadence SPI controller master driver
used by Xilinx Zynq and ZynqMP.
+config SPI_CADENCE_QUADSPI
+ tristate "Cadence Quad SPI controller"
+ depends on OF && (ARM || ARM64 || COMPILE_TEST)
+ help
+ Enable support for the Cadence Quad SPI Flash controller.
+
+ Cadence QSPI is a specialized controller for connecting an SPI
+ Flash over 1/2/4-bit wide bus. Enable this option if you have a
+ device with a Cadence QSPI controller and want to access the
+ Flash as an MTD device.
+
config SPI_CLPS711X
tristate "CLPS711X host SPI controller"
depends on ARCH_CLPS711X || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 889368f4ad53..f03834d1d312 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_SPI_BCM_QSPI)+= spi-iproc-qspi.o
spi-brcmstb-qspi.o spi-bcm-qspi.
obj-$(CONFIG_SPI_BITBANG) += spi-bitbang.o
obj-$(CONFIG_SPI_BUTTERFLY)+= spi-butterfly.o
obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o
+obj-$(CONFIG_SPI_CADENCE_QUADSPI) += spi-cadence-quadspi.o
obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o
obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o
obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
similarity index 99%
rename from drivers/mtd/spi-nor/controllers/cadence-quadspi.c
rename to drivers/spi/spi-cadence-quadspi.c
index c12a1c0191b9..1c1a9d17eec0 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1,11 +1,11 @@
// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Driver for Cadence QSPI Controller
- *
- * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
- * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
- * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
- */
+//
+// Driver for Cadence QSPI Controller
+//
+// Copyright Altera Corporation (C) 2012-2014. All rights reserved.
+// Copyright Intel Corporation (C) 2019-2020. All rights reserved.
+// Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
+
#include
#include
#include
--
2.26.2
[PATCH v3 3/8] mtd: spi-nor: cadence-quadspi: Don't initialize rx_dma_complete on failure
If driver fails to acquire DMA channel then don't initialize
rx_dma_complete struct as it won't be used.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 8a9e17f79d8d..379e22c11c87 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1180,6 +1180,7 @@ static void cqspi_request_mmap_dma(struct cqspi_st *cqspi)
if (IS_ERR(cqspi->rx_chan)) {
dev_err(>pdev->dev, "No Rx DMA available\n");
cqspi->rx_chan = NULL;
+ return;
}
init_completion(>rx_dma_complete);
}
--
2.26.2
[PATCH v3 0/8] mtd: spi-nor: Move cadence-qaudspi to spi-mem framework
This series is a subset of "[PATCH v12 0/4] spi: cadence-quadspi: Add
support for the Cadence QSPI controller" by Ramuthevar,Vadivel MuruganX
that intended to move
cadence-quadspi driver to spi-mem framework
Those patches were trying to accomplish too many things in a single set
of patches and need to split into smaller patches. This is reduced
version of above series.
Changes that are intended to make migration easy are split into separate
patches. Patches 1 to 3 drop features that cannot be supported under
spi-mem at the moment (backward compatibility is maintained).
Patch 4-5 are trivial cleanups. Patch 6 does the actual conversion to
spi-mem and patch 7 moves the driver to drivers/spi folder.
I have tested both INDAC mode (used by non TI platforms like Altera
SoCFPGA) and DAC mode (used by TI platforms) on TI EVMs.
Patches to move move bindings over to
"Documentation/devicetree/bindings/spi/" directory and also conversion
of bindig doc to YAML will be posted separately. Support for Intel
platform would follow that.
v3:
Split handling of probe deferral into separate patch (out of 5/6)
Split dropping of redundant WREN to separate patch (out of 5/6)
Fix a possible memleak due to lack of spi_master_put()
Parse all SPI slave nodes in cqspi_setup_flash()
Address misc comments from Tudor on v2
Rebase onto latest spi-nor/next
v2:
Rework patch 1/6 to keep "cdns,is-decoded-cs" property supported.
Ramuthevar Vadivel Murugan (2):
mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
spi: Move cadence-quadspi driver to drivers/spi/
Vignesh Raghavendra (6):
mtd: spi-nor: cadence-quadspi: Make driver independent of flash
geometry
mtd: spi-nor: cadence-quadspi: Provide a way to disable DAC mode
mtd: spi-nor: cadence-quadspi: Don't initialize rx_dma_complete on
failure
mtd: spi-nor: cadence-quadspi: Fix error path on failure to acquire
reset lines
mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting
DMA channel
mtd: spi-nor: cadence-quadspi: Drop redundant WREN in erase path
drivers/mtd/spi-nor/controllers/Kconfig | 11 -
drivers/mtd/spi-nor/controllers/Makefile | 1 -
drivers/spi/Kconfig | 11 +
drivers/spi/Makefile | 1 +
.../spi-cadence-quadspi.c}| 541 +++---
5 files changed, 222 insertions(+), 343 deletions(-)
rename drivers/{mtd/spi-nor/controllers/cadence-quadspi.c =>
spi/spi-cadence-quadspi.c} (74%)
--
2.26.2
Re: [PATCH v2 5/6] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
On 30/05/20 7:20 pm, tudor.amba...@microchip.com wrote:
> Hi, Vignesh,
>
> On Tuesday, May 26, 2020 12:36:03 PM EEST Vignesh Raghavendra wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> From: Ramuthevar Vadivel Murugan
>>
>>
>> Move cadence-quadspi driver to use spi-mem framework. This is required
>> to make the driver support for SPI NAND flashes in future.
>>
>> Driver is feature compliant with existing SPI NOR version.
>>
>> Signed-off-by: Ramuthevar Vadivel Murugan
>> Signed-off-by: Vignesh
>> Raghavendra
>> ---
>> .../mtd/spi-nor/controllers/cadence-quadspi.c | 469 +++---
>> 1 file changed, 183 insertions(+), 286 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
>> b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c index
>> 608ca657ff7f..c1df4b221889 100644
>> --- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
>> +++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
>> @@ -3,6 +3,8 @@
>> * Driver for Cadence QSPI Controller
>> *
>> * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
>> + * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
>> + * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
>> */
>> #include
>> #include
>> @@ -17,9 +19,6 @@
>> #include
>> #include
>> #include
>> -#include
>> -#include
>> -#include
>> #include
>> #include
>> #include
>> @@ -27,6 +26,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #define CQSPI_NAME "cadence-qspi"
>> @@ -36,16 +36,12 @@
>> #define CQSPI_NEEDS_WR_DELAY BIT(0)
>> #define CQSPI_DISABLE_DAC_MODE BIT(1)
>>
>> -/* Capabilities mask */
>> -#define CQSPI_BASE_HWCAPS_MASK \
>> - (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
>> - SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
>> - SNOR_HWCAPS_PP)
>> +/* Capabilities */
>> +#define CQSPI_SUPPORTS_OCTAL BIT(0)
>>
>> struct cqspi_st;
>>
>> struct cqspi_flash_pdata {
>> - struct spi_nor nor;
>> struct cqspi_st *cqspi;
>> u32 clk_rate;
>> u32 read_delay;
>> @@ -58,7 +54,6 @@ struct cqspi_flash_pdata {
>> u8 data_width;
>> u8 cs;
>> boolregistered;
>
> you can drop this, as it is no longer used
>
>> - booluse_direct_mode;
>> };
>>
>> struct cqspi_st {
>> @@ -71,7 +66,6 @@ struct cqspi_st {
>> void __iomem*ahb_base;
>> resource_size_t ahb_size;
>> struct completion transfer_complete;
>> - struct mutexbus_mutex;
>>
>> struct dma_chan *rx_chan;
>> struct completion rx_dma_complete;
>> @@ -85,6 +79,7 @@ struct cqspi_st {
>> boolrclk_en;
>> u32 trigger_address;
>> u32 wr_delay;
>> + booluse_dac_mode;
>
> is use_dac_mode better than use_direct_mode? If you prefer "dac", maybe you
> can rename this variable in 2/6
I will just keep "use_direct_mode" as is to minimize churn
>
>> struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
>> };
>>
>> @@ -283,9 +278,8 @@ static irqreturn_t cqspi_irq_handler(int this_irq, void
>> *dev) return IRQ_HANDLED;
>> }
>>
>> -static unsigned int cqspi_calc_rdreg(struct spi_nor *nor)
>> +static unsigned int cqspi_calc_rdreg(struct cqspi_flash_pdata *f_pdata)
>> {
>> - struct cqspi_flash_pdata *f_pdata = nor->priv;
>> u32 rdreg = 0;
>>
>> rdreg |= f_pdata->inst_width << CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB;
>> @@ -352,19 +346,21 @@ static int cqspi_exec_flash_cmd(struct cqspi_st
>> *cqspi, unsigned int reg) return cqspi_wait_idle(cqspi);
>> }
>>
>> -static int cqspi_command_read(struct spi_nor *nor, u8 opcode,
>> - u8 *rxbuf, size_t n_rx)
>> +static int cqspi_command_read(struct cqspi_flash_pdata *f_pdata,
>> + const struct spi_mem_op *op)
>> {
>> - struct cqs
Re: [PATCH RESEND v2] mtd: physmap: Add Baikal-T1 physically mapped ROMs support
On 28/05/20 4:12 pm, Serge Semin wrote:
[...]
>>> +
>>> +static map_word __xipram bt1_rom_dummy_read(struct map_info *map,
>>> + unsigned long ofs)
>>> +{
>>> + map_word ret;
>>> +
>>> + ret.x[0] = 0xFF;
>>> +
>>> + return ret;
>>> +}
>> Why define dummy_io for "baikal,bt1-boot-rom"? I don't see any use of
>> adding a driver that always reads 0xFFs
> This is supposed to be temporary solution for the baikal,bt1-boot-rom ROM.
> The Boot ROM mirror might reflect either an embedded firmware or the SPI flash
> directly mapped into the memory. In former case there is no problem, we can
> freely read from the Boot ROM region. But in the later case the mirrored
> region
> (memory mapped SPI flash) is not always accessible. If normal Boot SPI
> controller is enabled, then the SPI flash mapping isn't accessible (any
> attempt
> will cause a bus-error). In order to fix this we'd need a mutual exclusive
> lock,
> which would disable the SPI controller while the mirrored memory mapped SPI
> flash
> region needs to be accessed. Such mechanism isn't currently implemented, but
> it
> will in be in the framework of my patch created for the SPI subsystem.
>
> My idea was to just provide a dummy callback for now and replace it with
> normal
> IO-methods with mutual exclusive lock-unlocks when the corresponding SPI
> driver
> is accepted.
>
Yes I understand, but I don't see any advantage for end user by
providing dummy calls... So please don't add the callbacks until they
implement proper functionality
Re: [PATCH 2/2] mtd: spi-nor: intel-spi: fix forced writable option
On 18/05/20 11:29 pm, Daniel Walker wrote: > This option currently doesn't work as expected. If the BIOS has this > flash as read-only there is no way to change this thru the driver. > There is a parameter which allows the flash to become writable with the > "writable" option to the module, but it does nothing if the BIOS has it > set to read-only. > > I would expect this option would make the flash writable regardless of > the BIOS settings. This patch changes this option so the BIOS setting > doesn't stop the writable option from enabling read write on the flash. > I am confused you say "If the BIOS has this flash as read-only there is no way to change this thru the driver", so is it possible to override BIOS setting? If yes, where is the code in the driver? What happens if BIOS is set to allow writes but writeable is set to 0? Also please send patch series as thread (2/2 in reply to 1/2). You can use tool like git send-email > Original patch by Jinhua Wu > > Cc: Jinhua Wu > Cc: xe-linux-exter...@cisco.com > Signed-off-by: Daniel Walker > --- > drivers/mtd/spi-nor/controllers/intel-spi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/controllers/intel-spi.c > b/drivers/mtd/spi-nor/controllers/intel-spi.c > index e5a3d51a2e4d..68a5877bfc0b 100644 > --- a/drivers/mtd/spi-nor/controllers/intel-spi.c > +++ b/drivers/mtd/spi-nor/controllers/intel-spi.c > @@ -954,7 +954,7 @@ struct intel_spi *intel_spi_probe(struct device *dev, > intel_spi_fill_partition(ispi, ); > > /* Prevent writes if not explicitly enabled */ > - if (!ispi->writeable || !writeable) > + if (!ispi->writeable && !writeable) > ispi->nor.mtd.flags &= ~MTD_WRITEABLE; > > ret = mtd_device_register(>nor.mtd, , 1); >
Re: [PATCH 1/2] mtd: spi-nor: create/Export parameter softwareseq for intel-spi driver to user
+Mika Westerberg original author of the driver
On 18/05/20 11:29 pm, Daniel Walker wrote:
> From: Bobby Liu
>
> How to use:
> append softwareseq=1 while probe the driver.
> example:
> modprobe intel-spi writeable=1 softwareseq=1
> it will let driver use software sequence to write register for opt=EN4B
> by default it's 0 if not specified, driver will do usual HW cycle
>
Could some one from Intel please review this patch?
Regards
Vignesh
> Why this parameter is posted to user:
> Intel PCH provides two groups of registers for SPI flash operation,
> Hard Sequence registers and Software Sequence registers,
> corresponding to intel_spi_hw_cycle() and intel_spi_sw_cycle()
> respectively in driver code. But HW sequence register won't send EN4B
> opcode to SPI flash. BIOS code use SW register to send EN4B.
>
> On some Cisco routers, two 32M SPI flashes, which require 4-byte address mode
> enabled,
> are physically connected to an FPGA, one flash is active and one is inactive.
> When we do BIOS upgrade, we need switch to the inactive one,
> but unfortunately, this one is still 3-byte address mode as default,
> after we do real-time switch, we need reload SPI driver to send EN4B code to
> enable 4-byte address mode.
>
> Refering to our BIOS code, Software sequence register is processed
> while sending EN4B opcode. So here we use sw_cycle in driver for EN4B as well.
>
> Why I don't just easily use software sequence for all:
> 1.It will impact all flash operation, include flash W/R, high risk
> 2.The only SPI type I can use is INTEL_SPI_BXT according to datasheet,
> this will require using hw seq.
> I tried to specify other SPI type, it couldn't work with Intel PCH.
> If I force SW seq for all, during boot up, sw_cycle fails to read
> vendor ID.
>
> In conclusion, I only use SW cycle for EN4B opcode to minimize impact.
> It won't impact other users as well.
>
> Why the default flash can work at 4-byte address mode:
> BIOS sets 4-byte address mode for the current active SPI flash with SW seq
> registers.
> So we don't need append softwareseq=1 for normal boot up script,
> it will only be used in BIOS upgrade script.
>
> Cc: xe-linux-exter...@cisco.com
> Signed-off-by: Bobby Liu
> [ danielwa: edited the commit message a little. ]
> Signed-off-by: Daniel Walker
> ---
> drivers/mtd/spi-nor/controllers/intel-spi.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/controllers/intel-spi.c
> b/drivers/mtd/spi-nor/controllers/intel-spi.c
> index 61d2a0ad2131..e5a3d51a2e4d 100644
> --- a/drivers/mtd/spi-nor/controllers/intel-spi.c
> +++ b/drivers/mtd/spi-nor/controllers/intel-spi.c
> @@ -163,6 +163,10 @@ static bool writeable;
> module_param(writeable, bool, 0);
> MODULE_PARM_DESC(writeable, "Enable write access to SPI flash chip
> (default=0)");
>
> +static bool softwareseq;
> +module_param(softwareseq, bool, 0);
> +MODULE_PARM_DESC(softwareseq, "Use software sequence for register write
> (default=0)");
> +
> static void intel_spi_dump_regs(struct intel_spi *ispi)
> {
> u32 value;
> @@ -619,6 +623,18 @@ static int intel_spi_write_reg(struct spi_nor *nor, u8
> opcode, const u8 *buf,
> if (ret)
> return ret;
>
> + /*
> + * Intel Skylake will not send EN4B to SPI flash if we use HW sequence
> + * Here export one interface "softwareseq" to OS,
> + * let driver user decide if use SW sequence or not
> + */
> + if (opcode == SPINOR_OP_EN4B && softwareseq) {
> + dev_info(ispi->dev,
> + "Write register opcode is SPINOR_OP_EN4B, do SW cycle\n");
> + return intel_spi_sw_cycle(ispi, opcode, len,
> + OPTYPE_WRITE_NO_ADDR);
> + }
> +
> if (ispi->swseq_reg)
> return intel_spi_sw_cycle(ispi, opcode, len,
> OPTYPE_WRITE_NO_ADDR);
>
Re: [PATCH v1 1/1] drivers: mtd: spi-nor: update read capabilities for w25q64 and s25fl064k
Hi,
On 21/05/20 10:56 am, Rayagonda Kokatanur wrote:
> Both w25q64 and s25fl064k nor flash support QUAD and DUAL read
> command, hence update the same in flash_info table.
>
I am guessing both modes were tested on some platform?
Could you add that info here?
> Signed-off-by: Rayagonda Kokatanur
> ---
> drivers/mtd/spi-nor/spansion.c | 3 ++-
> drivers/mtd/spi-nor/winbond.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
> index 6756202ace4b..c91bbb8d9cd6 100644
> --- a/drivers/mtd/spi-nor/spansion.c
> +++ b/drivers/mtd/spi-nor/spansion.c
> @@ -52,7 +52,8 @@ static const struct flash_info spansion_parts[] = {
>SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "s25fl016k", INFO(0xef4015, 0, 64 * 1024, 32,
>SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> - { "s25fl064k", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
> + { "s25fl064k", INFO(0xef4017, 0, 64 * 1024, 128,
> + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "s25fl116k", INFO(0x014015, 0, 64 * 1024, 32,
>SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "s25fl132k", INFO(0x014016, 0, 64 * 1024, 64, SECT_4K) },
> diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
> index 17deabad57e1..2028cab3eff9 100644
> --- a/drivers/mtd/spi-nor/winbond.c
> +++ b/drivers/mtd/spi-nor/winbond.c
> @@ -39,7 +39,8 @@ static const struct flash_info winbond_parts[] = {
> SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
> { "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
> - { "w25q64", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
> + { "w25q64", INFO(0xef4017, 0, 64 * 1024, 128,
> + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "w25q64dw", INFO(0xef6017, 0, 64 * 1024, 128,
> SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
>
Regards
Vignesh
Re: [PATCH RESEND v2] mtd: physmap: Add Baikal-T1 physically mapped ROMs support
Hi,
On 27/05/20 4:28 am, Serge Semin wrote:
> Baikal-T1 Boot Controller provides an access to a RO storages, which are
> physically mapped into the MMIO space. In particularly there are the
> Internal ROM embedded into the SoC with a pre-installed firmware,
> externally attached SPI flash (also accessed in the read-only mode) and a
> memory region, which mirrors one of them in accordance with the currently
> enabled system boot mode (also called Boot ROM).
>
> This commit adds the ROMs support to the physmap driver of the MTD kernel
> subsystem. Currently the driver only supports the Internal ROM, since
> physically mapped SPI flash is utilized by the Baikal-T1 System Boot
> Controller driver so won't be available over mtd-rom interface and
> the Boot ROM mirror mapping has dependency on the SPI flash mapping
> switcher available within the SPI flash registers space. The real access
> to the Boot ROM memory will be added in future.
>
> Note we had to create a dedicated code for the ROMs since read from the
> corresponding memory regions must be done via the dword-aligned addresses.
> In addition the driver in future states will have to take into account
> that the Boot ROM might mirror the SPI flash region so before accessing it
> the SPI flash direct mapping must be enabled by means of a dedicated flag
> in the Baikal-T1 System SPI register flag.
>
> Signed-off-by: Serge Semin
> Cc: Alexey Malahov
> Cc: Maxim Kaurkin
> Cc: Pavel Parkhomenko
> Cc: Ramil Zaripov
> Cc: Ekaterina Skachko
> Cc: Vadim Vlasov
> Cc: Alexey Kolotnikov
> Cc: Thomas Bogendoerfer
> Cc: Arnd Bergmann
> Cc: Lee Jones
> Cc: linux-m...@vger.kernel.org
>
> ---
>
> Miquel, Richard, Vignesh, the merge window is upon us, please review/merge
> in/whatever this patch.
>
> This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
> base-commit: 0e698dfa2822 ("Linux 5.7-rc4")
> tag: v5.7-rc4
>
> New vendor prefix will be added in the framework of the next patchset:
> https://lkml.org/lkml/2020/5/6/1047
Sorry, driver patch and dt bindings have to be proposed together...
Driver cannot be accepted ahead of DT bindings been reviewed.
>
> Note since the next patchset is no longer relevant (as a result of a
> discussion with @Lee and @Miquel)
> https://lkml.org/lkml/2020/3/6/421
> and Boot ROM mtd is currently unsupported I can freely submit this patch,
> while in former case I had to wait for the patchset merged.
>
[...]
> +static void __xipram bt1_rom_map_copy_from(struct map_info *map,
> +void *to, unsigned long from,
> +ssize_t len)
> +{
> + void __iomem *src = map->virt + from;
> + ssize_t shift, chunk;
> + u32 data;
> +
> + if (len <= 0 || from >= map->size)
> + return;
> +
> + /* Make sure we don't go over the map limit. */
> + len = min_t(ssize_t, map->size - from, len);
> +
> + /*
> + * Since requested data size can be pretty big we have to implement
> + * the copy procedure as optimal as possible. That's why it's split
> + * up into the next three stages: unaligned head, aligned body,
> + * unaligned tail.
> + */
> + shift = (ssize_t)src & 0x3;
> + if (shift) {
> + chunk = min_t(ssize_t, 4 - shift, len);
> + data = readl_relaxed(src - shift);
> + memcpy(to, + shift, chunk);
> + src += chunk;
> + to += chunk;
> + len -= chunk;
> + }
> +
> + while (len >= 4) {
> + data = readl_relaxed(src);
> + memcpy(to, , 4);
> + src += 4;
> + to += 4;
> + len -= 4;
> + }
> +
> + if (len) {
> + data = readl_relaxed(src);
> + memcpy(to, , len);
> + }
> +}
> +
> +static map_word __xipram bt1_rom_dummy_read(struct map_info *map,
> + unsigned long ofs)
> +{
> + map_word ret;
> +
> + ret.x[0] = 0xFF;
> +
> + return ret;
> +}
Why define dummy_io for "baikal,bt1-boot-rom"? I don't see any use of
adding a driver that always reads 0xFFs
> +
> +/*
> + * Currently Baikal-T1 SoC internal ROM is only supported. Boot ROM region is
> + * dummy-data filled for now since in case of the system booted up from an
> + * external SPI flash the ROM will mirror the Baikal-T1 System Boot SPI
> direct
> + * mapping memory region. That region can be only accessed when transparent
> + * mode is enabled, which we unable to do here because this feature is
> provided
> + * by the SPI controller config space occupied by the corresponding driver.
> + * In future we'll export the mode setting method from the Baikal-T1 System
> + * Boot SPI Controller driver to also have the Boot ROM supported here.
> + */
> +static const struct of_device_id bt1_rom_of_match[] = {
> + {
> + .compatible = "baikal,bt1-int-rom",
> + .data = _rom_normal_io
> + },
Re: [PATCH v2 6/6] spi: Move cadence-quadspi driver to drivers/spi/
Hi,
On 28/05/20 2:28 am, kbuild test robot wrote:
> Hi Vignesh,
>
[...]
>
> In file included from include/linux/err.h:5,
> from include/linux/clk.h:12,
> from drivers/spi/spi-cadence-quadspi.c:9:
> include/linux/scatterlist.h: In function 'sg_set_buf':
> arch/xtensa/include/asm/page.h:193:9: warning: comparison of unsigned
> expression >= 0 is always true [-Wtype-limits]
> 193 | ((pfn) >= ARCH_PFN_OFFSET && ((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
> | ^~
> include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
> 78 | # define unlikely(x) __builtin_expect(!!(x), 0)
> | ^
> include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON'
> 143 | BUG_ON(!virt_addr_valid(buf));
> | ^~
> arch/xtensa/include/asm/page.h:201:32: note: in expansion of macro 'pfn_valid'
> 201 | #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
> |^
> include/linux/scatterlist.h:143:10: note: in expansion of macro
> 'virt_addr_valid'
> 143 | BUG_ON(!virt_addr_valid(buf));
> | ^~~
> In file included from ./arch/xtensa/include/generated/asm/bug.h:1,
> from include/linux/bug.h:5,
> from include/linux/thread_info.h:12,
> from arch/xtensa/include/asm/current.h:18,
> from include/linux/mutex.h:14,
> from include/linux/notifier.h:14,
> from include/linux/clk.h:14,
> from drivers/spi/spi-cadence-quadspi.c:9:
> include/linux/dma-mapping.h: In function 'dma_map_resource':
> arch/xtensa/include/asm/page.h:193:9: warning: comparison of unsigned
> expression >= 0 is always true [-Wtype-limits]
> 193 | ((pfn) >= ARCH_PFN_OFFSET && ((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
> | ^~
> include/asm-generic/bug.h:139:27: note: in definition of macro 'WARN_ON_ONCE'
> 139 | int __ret_warn_once = !!(condition);|
> ^
> include/linux/dma-mapping.h:352:19: note: in expansion of macro 'pfn_valid'
> 352 | if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
> | ^
> In file included from include/linux/shm.h:6,
> from include/linux/sched.h:16,
> from include/linux/ratelimit.h:6,
> from include/linux/dev_printk.h:16,
> from include/linux/device.h:15,
> from include/linux/dma-mapping.h:7,
> from drivers/spi/spi-cadence-quadspi.c:12:
> drivers/spi/spi-cadence-quadspi.c: In function 'cqspi_direct_read_execute':
> arch/xtensa/include/asm/page.h:193:9: warning: comparison of unsigned
> expression >= 0 is always true [-Wtype-limits]
> 193 | ((pfn) >= ARCH_PFN_OFFSET && ((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
> | ^~
> arch/xtensa/include/asm/page.h:201:32: note: in expansion of macro 'pfn_valid'
> 201 | #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
> |^
>>> drivers/spi/spi-cadence-quadspi.c:911:26: note: in expansion of macro
>>> 'virt_addr_valid'
> 911 | if (!cqspi->rx_chan || !virt_addr_valid(buf)) {
> | ^~~
Thanks for the report! But it seems with ARCH=xtensa and config that was
attached, I see above warning for every file in the kernel that uses
virt_addr_valid(), So, the fix for this warning is really in xtensa arch
code and therefore should not block this series from being merged.
Regards
Vignesh
Re: [PATCH] scsi: ufs: Fix runtime PM imbalance on error
Hi,
On 22/05/20 10:23 am, Dinghao Liu wrote:
> When devm_clk_get() returns an error code, a pairing
> runtime PM usage counter decrement is needed to keep
> the counter balanced.
>
> Signed-off-by: Dinghao Liu
> ---
Thanks for the patch! But this fix is incomplete, I have posted
a more comprehensive fix at [1].. Please take a look!
[1]
https://lore.kernel.org/linux-scsi/20200526100340.15032-1-vigne...@ti.com/T/#u
> drivers/scsi/ufs/ti-j721e-ufs.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/ufs/ti-j721e-ufs.c b/drivers/scsi/ufs/ti-j721e-ufs.c
> index 5216d228cdd9..f3f212f6f9a9 100644
> --- a/drivers/scsi/ufs/ti-j721e-ufs.c
> +++ b/drivers/scsi/ufs/ti-j721e-ufs.c
> @@ -39,6 +39,7 @@ static int ti_j721e_ufs_probe(struct platform_device *pdev)
> clk = devm_clk_get(dev, NULL);
> if (IS_ERR(clk)) {
> dev_err(dev, "Cannot claim MPHY clock.\n");
> + pm_runtime_put_sync(dev);
> return PTR_ERR(clk);
> }
> clk_rate = clk_get_rate(clk);
>
Regards
Vignesh
[PATCH] scsi: ufs: ti-j721e-ufs: Fix unwinding of pm_runtime changes
Fix unwinding of pm_runtime changes when bailing out of driver probe due
to a failure and also on removal of driver.
Fixes: 6979e56cec97 ("scsi: ufs: Add driver for TI wrapper for Cadence UFS IP")
Reported-by: Dinghao Liu
Signed-off-by: Vignesh Raghavendra
---
drivers/scsi/ufs/ti-j721e-ufs.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ufs/ti-j721e-ufs.c b/drivers/scsi/ufs/ti-j721e-ufs.c
index 5216d228cdd9..46bb905b4d6a 100644
--- a/drivers/scsi/ufs/ti-j721e-ufs.c
+++ b/drivers/scsi/ufs/ti-j721e-ufs.c
@@ -32,14 +32,14 @@ static int ti_j721e_ufs_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(dev);
if (ret < 0) {
pm_runtime_put_noidle(dev);
- return ret;
+ goto disable_pm;
}
/* Select MPHY refclk frequency */
clk = devm_clk_get(dev, NULL);
if (IS_ERR(clk)) {
dev_err(dev, "Cannot claim MPHY clock.\n");
- return PTR_ERR(clk);
+ goto clk_err;
}
clk_rate = clk_get_rate(clk);
if (clk_rate == 2600)
@@ -54,16 +54,23 @@ static int ti_j721e_ufs_probe(struct platform_device *pdev)
dev);
if (ret) {
dev_err(dev, "failed to populate child nodes %d\n", ret);
- pm_runtime_put_sync(dev);
+ goto clk_err;
}
return ret;
+
+clk_err:
+ pm_runtime_put_sync(dev);
+disable_pm:
+ pm_runtime_disable(dev);
+ return ret;
}
static int ti_j721e_ufs_remove(struct platform_device *pdev)
{
of_platform_depopulate(>dev);
pm_runtime_put_sync(>dev);
+ pm_runtime_disable(>dev);
return 0;
}
--
2.26.2
[PATCH v2 5/6] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
From: Ramuthevar Vadivel Murugan
Move cadence-quadspi driver to use spi-mem framework. This is required
to make the driver support for SPI NAND flashes in future.
Driver is feature compliant with existing SPI NOR version.
Signed-off-by: Ramuthevar Vadivel Murugan
Signed-off-by: Vignesh Raghavendra
---
.../mtd/spi-nor/controllers/cadence-quadspi.c | 469 +++---
1 file changed, 183 insertions(+), 286 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 608ca657ff7f..c1df4b221889 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -3,6 +3,8 @@
* Driver for Cadence QSPI Controller
*
* Copyright Altera Corporation (C) 2012-2014. All rights reserved.
+ * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
*/
#include
#include
@@ -17,9 +19,6 @@
#include
#include
#include
-#include
-#include
-#include
#include
#include
#include
@@ -27,6 +26,7 @@
#include
#include
#include
+#include
#include
#define CQSPI_NAME "cadence-qspi"
@@ -36,16 +36,12 @@
#define CQSPI_NEEDS_WR_DELAY BIT(0)
#define CQSPI_DISABLE_DAC_MODE BIT(1)
-/* Capabilities mask */
-#define CQSPI_BASE_HWCAPS_MASK \
- (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
- SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
- SNOR_HWCAPS_PP)
+/* Capabilities */
+#define CQSPI_SUPPORTS_OCTAL BIT(0)
struct cqspi_st;
struct cqspi_flash_pdata {
- struct spi_nor nor;
struct cqspi_st *cqspi;
u32 clk_rate;
u32 read_delay;
@@ -58,7 +54,6 @@ struct cqspi_flash_pdata {
u8 data_width;
u8 cs;
boolregistered;
- booluse_direct_mode;
};
struct cqspi_st {
@@ -71,7 +66,6 @@ struct cqspi_st {
void __iomem*ahb_base;
resource_size_t ahb_size;
struct completion transfer_complete;
- struct mutexbus_mutex;
struct dma_chan *rx_chan;
struct completion rx_dma_complete;
@@ -85,6 +79,7 @@ struct cqspi_st {
boolrclk_en;
u32 trigger_address;
u32 wr_delay;
+ booluse_dac_mode;
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
@@ -283,9 +278,8 @@ static irqreturn_t cqspi_irq_handler(int this_irq, void
*dev)
return IRQ_HANDLED;
}
-static unsigned int cqspi_calc_rdreg(struct spi_nor *nor)
+static unsigned int cqspi_calc_rdreg(struct cqspi_flash_pdata *f_pdata)
{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
u32 rdreg = 0;
rdreg |= f_pdata->inst_width << CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB;
@@ -352,19 +346,21 @@ static int cqspi_exec_flash_cmd(struct cqspi_st *cqspi,
unsigned int reg)
return cqspi_wait_idle(cqspi);
}
-static int cqspi_command_read(struct spi_nor *nor, u8 opcode,
- u8 *rxbuf, size_t n_rx)
+static int cqspi_command_read(struct cqspi_flash_pdata *f_pdata,
+ const struct spi_mem_op *op)
{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqspi_st *cqspi = f_pdata->cqspi;
void __iomem *reg_base = cqspi->iobase;
+ u8 *rxbuf = op->data.buf.in;
+ u8 opcode = op->cmd.opcode;
+ size_t n_rx = op->data.nbytes;
unsigned int rdreg;
unsigned int reg;
size_t read_len;
int status;
if (!n_rx || n_rx > CQSPI_STIG_DATA_LEN_MAX || !rxbuf) {
- dev_err(nor->dev,
+ dev_err(>pdev->dev,
"Invalid input argument, len %zu rxbuf 0x%p\n",
n_rx, rxbuf);
return -EINVAL;
@@ -372,7 +368,7 @@ static int cqspi_command_read(struct spi_nor *nor, u8
opcode,
reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB;
- rdreg = cqspi_calc_rdreg(nor);
+ rdreg = cqspi_calc_rdreg(f_pdata);
writel(rdreg, reg_base + CQSPI_REG_RD_INSTR);
reg |= (0x1 << CQSPI_REG_CMDCTRL_RD_EN_LSB);
@@ -401,25 +397,35 @@ static int cqspi_command_read(struct spi_nor *nor, u8
opcode,
return 0;
}
-static int cqspi_command_write(struct spi_nor *nor, const u8 opcode,
- const u8 *txbuf, size_t n_tx)
+static int cqspi_command_write(struct cqspi_flash_pdata *f_pdata,
+ const struct spi_mem_op *op)
{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqspi_st *cqspi = f_pdata->cqspi;
[PATCH v2 6/6] spi: Move cadence-quadspi driver to drivers/spi/
From: Ramuthevar Vadivel Murugan
Now that cadence-quadspi has been converted to use spi-mem framework,
move it under drivers/spi/
Update license header to match SPI subsystem style
Signed-off-by: Ramuthevar Vadivel Murugan
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi-nor/controllers/Kconfig| 11 ---
drivers/mtd/spi-nor/controllers/Makefile | 1 -
drivers/spi/Kconfig| 11 +++
drivers/spi/Makefile | 1 +
.../spi-cadence-quadspi.c} | 14 +++---
5 files changed, 19 insertions(+), 19 deletions(-)
rename drivers/{mtd/spi-nor/controllers/cadence-quadspi.c =>
spi/spi-cadence-quadspi.c} (99%)
diff --git a/drivers/mtd/spi-nor/controllers/Kconfig
b/drivers/mtd/spi-nor/controllers/Kconfig
index 10b86660b821..95fcd4b435be 100644
--- a/drivers/mtd/spi-nor/controllers/Kconfig
+++ b/drivers/mtd/spi-nor/controllers/Kconfig
@@ -9,17 +9,6 @@ config SPI_ASPEED_SMC
and support for the SPI flash memory controller (SPI) for
the host firmware. The implementation only supports SPI NOR.
-config SPI_CADENCE_QUADSPI
- tristate "Cadence Quad SPI controller"
- depends on OF && (ARM || ARM64 || COMPILE_TEST)
- help
- Enable support for the Cadence Quad SPI Flash controller.
-
- Cadence QSPI is a specialized controller for connecting an SPI
- Flash over 1/2/4-bit wide bus. Enable this option if you have a
- device with a Cadence QSPI controller and want to access the
- Flash as an MTD device.
-
config SPI_HISI_SFC
tristate "Hisilicon FMC SPI-NOR Flash Controller(SFC)"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/mtd/spi-nor/controllers/Makefile
b/drivers/mtd/spi-nor/controllers/Makefile
index 46e6fbe586e3..e7abba491d98 100644
--- a/drivers/mtd/spi-nor/controllers/Makefile
+++ b/drivers/mtd/spi-nor/controllers/Makefile
@@ -1,6 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o
-obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o
obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o
obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o
obj-$(CONFIG_SPI_INTEL_SPI)+= intel-spi.o
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 099d6a75a371..2de8098b26c1 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -200,6 +200,17 @@ config SPI_CADENCE
This selects the Cadence SPI controller master driver
used by Xilinx Zynq and ZynqMP.
+config SPI_CADENCE_QUADSPI
+ tristate "Cadence Quad SPI controller"
+ depends on OF && (ARM || ARM64 || COMPILE_TEST)
+ help
+ Enable support for the Cadence Quad SPI Flash controller.
+
+ Cadence QSPI is a specialized controller for connecting an SPI
+ Flash over 1/2/4-bit wide bus. Enable this option if you have a
+ device with a Cadence QSPI controller and want to access the
+ Flash as an MTD device.
+
config SPI_CLPS711X
tristate "CLPS711X host SPI controller"
depends on ARCH_CLPS711X || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 889368f4ad53..f03834d1d312 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_SPI_BCM_QSPI)+= spi-iproc-qspi.o
spi-brcmstb-qspi.o spi-bcm-qspi.
obj-$(CONFIG_SPI_BITBANG) += spi-bitbang.o
obj-$(CONFIG_SPI_BUTTERFLY)+= spi-butterfly.o
obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o
+obj-$(CONFIG_SPI_CADENCE_QUADSPI) += spi-cadence-quadspi.o
obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o
obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o
obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
similarity index 99%
rename from drivers/mtd/spi-nor/controllers/cadence-quadspi.c
rename to drivers/spi/spi-cadence-quadspi.c
index c1df4b221889..8e8937ec5b1b 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1,11 +1,11 @@
// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Driver for Cadence QSPI Controller
- *
- * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
- * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
- * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
- */
+//
+// Driver for Cadence QSPI Controller
+//
+// Copyright Altera Corporation (C) 2012-2014. All rights reserved.
+// Copyright Intel Corporation (C) 2019-2020. All rights reserved.
+// Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
+
#include
#include
#include
--
2.26.2
[PATCH v2 0/6] mtd: spi-nor: Move cadence-qaudspi to spi-mem framework
mtd: spi-nor: Move cadence-qaudspi to spi-mem framework
This series is a subset of "[PATCH v12 0/4] spi: cadence-quadspi: Add
support for the Cadence QSPI controller" by Ramuthevar,Vadivel MuruganX
that intended to move
cadence-quadspi driver to spi-mem framework
Those patches were trying to accomplish too many things in a single set
of patches and need to split into smaller patches. This is reduced
version of above series.
Changes that are intended to make migration easy are split into separate
patches. Patches 1 to 3 drop features that cannot be supported under
spi-mem at the moment (backward compatibility is maintained).
Patch 4-5 are trivial cleanups. Patch 6 does the actual conversion to
spi-mem and patch 7 moves the driver to drivers/spi folder.
I have tested both INDAC mode (used by non TI platforms like Altera
SoCFPGA) and DAC mode (used by TI platforms) on TI EVMs.
Patches to move move bindings over to
"Documentation/devicetree/bindings/spi/" directory and also conversion
of bindig doc to YAML will be posted separately. Support for Intel
platform would follow that.
v2:
Rework patch 1/6 to keep "cdns,is-decoded-cs" property supported.
Ramuthevar Vadivel Murugan (2):
mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
spi: Move cadence-quadspi driver to drivers/spi/
Vignesh Raghavendra (4):
mtd: spi-nor: cadence-quadspi: Make driver independent of flash
geometry
mtd: spi-nor: cadence-quadspi: Provide a way to disable DAC mode
mtd: spi-nor: cadence-quadspi: Don't initialize rx_dma_complete on
failure
mtd: spi-nor: cadence-quadspi: Fix error path on failure to acquire
reset lines
drivers/mtd/spi-nor/controllers/Kconfig | 11 -
drivers/mtd/spi-nor/controllers/Makefile | 1 -
drivers/spi/Kconfig | 11 +
drivers/spi/Makefile | 1 +
.../spi-cadence-quadspi.c}| 521 +++---
5 files changed, 206 insertions(+), 339 deletions(-)
rename drivers/{mtd/spi-nor/controllers/cadence-quadspi.c =>
spi/spi-cadence-quadspi.c} (74%)
--
2.26.2
[PATCH v2 2/6] mtd: spi-nor: cadence-quadspi: Provide a way to disable DAC mode
Currently direct access mode is used on platforms that have AHB window
(memory mapped window) larger than flash size. This feature is limited
to TI platforms as non TI platforms have < 1MB of AHB window.
Therefore introduce a driver quirk to disable DAC mode and set it for
non TI compatibles. This is in preparation to move to spi-mem framework
where flash geometry cannot be known.
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 9b8554d44fac..8a9e17f79d8d 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -34,6 +34,7 @@
/* Quirks */
#define CQSPI_NEEDS_WR_DELAY BIT(0)
+#define CQSPI_DISABLE_DAC_MODE BIT(1)
/* Capabilities mask */
#define CQSPI_BASE_HWCAPS_MASK \
@@ -1261,7 +1262,8 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi,
struct device_node *np)
f_pdata->registered = true;
- if (mtd->size <= cqspi->ahb_size) {
+ if (mtd->size <= cqspi->ahb_size &&
+ !(ddata->quirks & CQSPI_DISABLE_DAC_MODE)) {
f_pdata->use_direct_mode = true;
dev_dbg(nor->dev, "using direct mode for %s\n",
mtd->name);
@@ -1457,6 +1459,7 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
static const struct cqspi_driver_platdata cdns_qspi = {
.hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+ .quirks = CQSPI_DISABLE_DAC_MODE,
};
static const struct cqspi_driver_platdata k2g_qspi = {
--
2.26.2
[PATCH v2 3/6] mtd: spi-nor: cadence-quadspi: Don't initialize rx_dma_complete on failure
If driver fails to acquire DMA channel then don't initialize
rx_dma_complete struct as it won't be used.
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 8a9e17f79d8d..379e22c11c87 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1180,6 +1180,7 @@ static void cqspi_request_mmap_dma(struct cqspi_st *cqspi)
if (IS_ERR(cqspi->rx_chan)) {
dev_err(>pdev->dev, "No Rx DMA available\n");
cqspi->rx_chan = NULL;
+ return;
}
init_completion(>rx_dma_complete);
}
--
2.26.2
[PATCH v2 1/6] mtd: spi-nor: cadence-quadspi: Make driver independent of flash geometry
Drop configuration of Flash size, erase size and page size
configuration. Flash size is needed only if using AHB decoder (BIT 23 of
CONFIG_REG) which is not used by the driver.
Erase size and page size are needed if IP is configured to send WREN
automatically. But since SPI NOR layer takes care of sending WREN, there
is no need to configure these fields either.
Therefore drop these in preparation to move the driver to spi-mem
framework where flash geometry is not visible to controller driver.
Signed-off-by: Vignesh Raghavendra
---
.../mtd/spi-nor/controllers/cadence-quadspi.c | 36 +--
1 file changed, 1 insertion(+), 35 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 494dcab4..9b8554d44fac 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -77,9 +77,6 @@ struct cqspi_st {
dma_addr_t mmap_phys_base;
int current_cs;
- int current_page_size;
- int current_erase_size;
- int current_addr_width;
unsigned long master_ref_clk_hz;
boolis_decoded_cs;
u32 fifo_depth;
@@ -736,32 +733,6 @@ static void cqspi_chipselect(struct spi_nor *nor)
writel(reg, reg_base + CQSPI_REG_CONFIG);
}
-static void cqspi_configure_cs_and_sizes(struct spi_nor *nor)
-{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
- struct cqspi_st *cqspi = f_pdata->cqspi;
- void __iomem *iobase = cqspi->iobase;
- unsigned int reg;
-
- /* configure page size and block size. */
- reg = readl(iobase + CQSPI_REG_SIZE);
- reg &= ~(CQSPI_REG_SIZE_PAGE_MASK << CQSPI_REG_SIZE_PAGE_LSB);
- reg &= ~(CQSPI_REG_SIZE_BLOCK_MASK << CQSPI_REG_SIZE_BLOCK_LSB);
- reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
- reg |= (nor->page_size << CQSPI_REG_SIZE_PAGE_LSB);
- reg |= (ilog2(nor->mtd.erasesize) << CQSPI_REG_SIZE_BLOCK_LSB);
- reg |= (nor->addr_width - 1);
- writel(reg, iobase + CQSPI_REG_SIZE);
-
- /* configure the chip select */
- cqspi_chipselect(nor);
-
- /* Store the new configuration of the controller */
- cqspi->current_page_size = nor->page_size;
- cqspi->current_erase_size = nor->mtd.erasesize;
- cqspi->current_addr_width = nor->addr_width;
-}
-
static unsigned int calculate_ticks_for_ns(const unsigned int ref_clk_hz,
const unsigned int ns_val)
{
@@ -867,18 +838,13 @@ static void cqspi_configure(struct spi_nor *nor)
int switch_cs = (cqspi->current_cs != f_pdata->cs);
int switch_ck = (cqspi->sclk != sclk);
- if ((cqspi->current_page_size != nor->page_size) ||
- (cqspi->current_erase_size != nor->mtd.erasesize) ||
- (cqspi->current_addr_width != nor->addr_width))
- switch_cs = 1;
-
if (switch_cs || switch_ck)
cqspi_controller_enable(cqspi, 0);
/* Switch chip select. */
if (switch_cs) {
cqspi->current_cs = f_pdata->cs;
- cqspi_configure_cs_and_sizes(nor);
+ cqspi_chipselect(nor);
}
/* Setup baudrate divisor and delays */
--
2.26.2
[PATCH v2 4/6] mtd: spi-nor: cadence-quadspi: Fix error path on failure to acquire reset lines
Make sure to undo the prior changes done by the driver when exiting due
to failure to acquire reset lines.
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 379e22c11c87..608ca657ff7f 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1359,13 +1359,13 @@ static int cqspi_probe(struct platform_device *pdev)
rstc = devm_reset_control_get_optional_exclusive(dev, "qspi");
if (IS_ERR(rstc)) {
dev_err(dev, "Cannot get QSPI reset.\n");
- return PTR_ERR(rstc);
+ goto probe_reset_failed;
}
rstc_ocp = devm_reset_control_get_optional_exclusive(dev, "qspi-ocp");
if (IS_ERR(rstc_ocp)) {
dev_err(dev, "Cannot get QSPI OCP reset.\n");
- return PTR_ERR(rstc_ocp);
+ goto probe_reset_failed;
}
reset_control_assert(rstc);
@@ -1384,7 +1384,7 @@ static int cqspi_probe(struct platform_device *pdev)
pdev->name, cqspi);
if (ret) {
dev_err(dev, "Cannot request IRQ.\n");
- goto probe_irq_failed;
+ goto probe_reset_failed;
}
cqspi_wait_idle(cqspi);
@@ -1401,7 +1401,7 @@ static int cqspi_probe(struct platform_device *pdev)
return ret;
probe_setup_failed:
cqspi_controller_enable(cqspi, 0);
-probe_irq_failed:
+probe_reset_failed:
clk_disable_unprepare(cqspi->clk);
probe_clk_failed:
pm_runtime_put_sync(dev);
--
2.26.2
Re: [PATCH 1/6] mtd: spi-nor: cadence-quadspi: Drop cdns,is-decoded-cs property
On 09/05/20 12:24 am, Vignesh Raghavendra wrote:
> Cadence QSPI provides a way to automatically decode CS based on the
> offset accessed within memory map window. This feature cannot be
> supported in spi-mem framework as controller driver would not have
> access to flash geometry. Therefore drop this feature in preparation to
> moving to spi-mem.
>
> Note that, this feature never worked in the driver (Direct/Indirect mode
> accesses did not take into account size of flash on other CSs) and there
> are no users of this feature in kernel. Therefore dropping this should
> not cause a regression
>
I realized cdns,is-decoded-cs property does not depend on
cqspi_configure_cs_and_sizes() and can still be supported w/o knowing
flash geometry... Will respin..
Regards
Vignesh
> Signed-off-by: Vignesh Raghavendra
> ---
> .../mtd/spi-nor/controllers/cadence-quadspi.c | 59 +++
> 1 file changed, 9 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> index 494dcab4..fa54f85e16d7 100644
> --- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> @@ -77,11 +77,7 @@ struct cqspi_st {
> dma_addr_t mmap_phys_base;
>
> int current_cs;
> - int current_page_size;
> - int current_erase_size;
> - int current_addr_width;
> unsigned long master_ref_clk_hz;
> - bool is_decoded_cs;
> u32 fifo_depth;
> u32 fifo_width;
> bool rclk_en;
> @@ -715,19 +711,15 @@ static void cqspi_chipselect(struct spi_nor *nor)
> unsigned int reg;
>
> reg = readl(reg_base + CQSPI_REG_CONFIG);
> - if (cqspi->is_decoded_cs) {
> - reg |= CQSPI_REG_CONFIG_DECODE_MASK;
> - } else {
> - reg &= ~CQSPI_REG_CONFIG_DECODE_MASK;
> + reg &= ~CQSPI_REG_CONFIG_DECODE_MASK;
>
> - /* Convert CS if without decoder.
> - * CS0 to 4b'1110
> - * CS1 to 4b'1101
> - * CS2 to 4b'1011
> - * CS3 to 4b'0111
> - */
> - chip_select = 0xF & ~(1 << chip_select);
> - }
> + /* Convert CS if without decoder.
> + * CS0 to 4b'1110
> + * CS1 to 4b'1101
> + * CS2 to 4b'1011
> + * CS3 to 4b'0111
> + */
> + chip_select = 0xF & ~(1 << chip_select);
>
> reg &= ~(CQSPI_REG_CONFIG_CHIPSELECT_MASK
> << CQSPI_REG_CONFIG_CHIPSELECT_LSB);
> @@ -736,32 +728,6 @@ static void cqspi_chipselect(struct spi_nor *nor)
> writel(reg, reg_base + CQSPI_REG_CONFIG);
> }
>
> -static void cqspi_configure_cs_and_sizes(struct spi_nor *nor)
> -{
> - struct cqspi_flash_pdata *f_pdata = nor->priv;
> - struct cqspi_st *cqspi = f_pdata->cqspi;
> - void __iomem *iobase = cqspi->iobase;
> - unsigned int reg;
> -
> - /* configure page size and block size. */
> - reg = readl(iobase + CQSPI_REG_SIZE);
> - reg &= ~(CQSPI_REG_SIZE_PAGE_MASK << CQSPI_REG_SIZE_PAGE_LSB);
> - reg &= ~(CQSPI_REG_SIZE_BLOCK_MASK << CQSPI_REG_SIZE_BLOCK_LSB);
> - reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
> - reg |= (nor->page_size << CQSPI_REG_SIZE_PAGE_LSB);
> - reg |= (ilog2(nor->mtd.erasesize) << CQSPI_REG_SIZE_BLOCK_LSB);
> - reg |= (nor->addr_width - 1);
> - writel(reg, iobase + CQSPI_REG_SIZE);
> -
> - /* configure the chip select */
> - cqspi_chipselect(nor);
> -
> - /* Store the new configuration of the controller */
> - cqspi->current_page_size = nor->page_size;
> - cqspi->current_erase_size = nor->mtd.erasesize;
> - cqspi->current_addr_width = nor->addr_width;
> -}
> -
> static unsigned int calculate_ticks_for_ns(const unsigned int ref_clk_hz,
> const unsigned int ns_val)
> {
> @@ -867,18 +833,13 @@ static void cqspi_configure(struct spi_nor *nor)
> int switch_cs = (cqspi->current_cs != f_pdata->cs);
> int switch_ck = (cqspi->sclk != sclk);
>
> - if ((cqspi->current_page_size != nor->page_size) ||
> - (cqspi->current_erase_size != nor->mtd.erasesize) ||
> - (cqspi->current_addr_width != nor->addr_width))
> - switch_cs = 1;
> -
> if (switch_cs || switch_ck)
> cqspi_controller_ena
Re: [PATCH] mtd: Replace zero-length array with flexible-array
On Thu, 7 May 2020 14:00:33 -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
cfi/next, thanks!
Regards
--
Vignesh
Re: [PATCH 4/5] dt-bindings: ufs: ti: Add missing 'additionalProperties: false'
On 13/05/20 2:15 am, Rob Herring wrote: > The ti,j721e-ufs schema is missing an 'additionalProperties: false'. Add > that and and the missing assigned-clock properties. > > Cc: Vignesh Raghavendra > Signed-off-by: Rob Herring > --- Acked-by: Vignesh Raghavendra Regards Vignesh > Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml | 8 > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml > b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml > index b503b1a918a5..4d13e6bc1c50 100644 > --- a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml > +++ b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml > @@ -25,6 +25,12 @@ properties: >power-domains: > maxItems: 1 > > + assigned-clocks: > +maxItems: 1 > + > + assigned-clock-parents: > +maxItems: 1 > + >"#address-cells": > const: 2 > > @@ -47,6 +53,8 @@ patternProperties: >Documentation/devicetree/bindings/ufs/cdns,ufshc.txt for binding >documentation of child node > > +additionalProperties: false > + > examples: >- | > #include >
Re: [PATCH 3/5] dt-bindings: ufs: ti: Fix address properties handling
On 13/05/20 2:15 am, Rob Herring wrote:
> The ti,j721e-ufs schema and example have a couple of problems related to
> address properties. First, the default #size-cells and #address-cells
> are 1 for examples, so they need to be overriden with a bus node.
> Second, address translation for the child ufs node is broken because
> 'ranges', '#address-cells', and '#size-cells' are missing from the
> schema.
>
> Cc: Vignesh Raghavendra
> Signed-off-by: Rob Herring
> ---
Acked-by: Vignesh Raghavendra
Regards
Vignesh
> Please ack, dependency for patch 5.
>
> .../devicetree/bindings/ufs/ti,j721e-ufs.yaml | 57 ---
> 1 file changed, 36 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml
> b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml
> index c8a2a92074df..b503b1a918a5 100644
> --- a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml
> +++ b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml
> @@ -25,6 +25,14 @@ properties:
>power-domains:
> maxItems: 1
>
> + "#address-cells":
> +const: 2
> +
> + "#size-cells":
> +const: 2
> +
> + ranges: true
> +
> required:
>- compatible
>- reg
> @@ -44,25 +52,32 @@ examples:
> #include
> #include
>
> -ufs_wrapper: ufs-wrapper@4e8 {
> - compatible = "ti,j721e-ufs";
> - reg = <0x0 0x4e8 0x0 0x100>;
> - power-domains = <_pds 277>;
> - clocks = <_clks 277 1>;
> - assigned-clocks = <_clks 277 1>;
> - assigned-clock-parents = <_clks 277 4>;
> - #address-cells = <2>;
> - #size-cells = <2>;
> -
> - ufs@4e84000 {
> - compatible = "cdns,ufshc-m31-16nm", "jedec,ufs-2.0";
> - reg = <0x0 0x4e84000 0x0 0x1>;
> - interrupts = ;
> - freq-table-hz = <1920 1920>;
> - power-domains = <_pds 277>;
> - clocks = <_clks 277 1>;
> - assigned-clocks = <_clks 277 1>;
> - assigned-clock-parents = <_clks 277 4>;
> - clock-names = "core_clk";
> - };
> +bus {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +
> +ufs-wrapper@4e8 {
> +compatible = "ti,j721e-ufs";
> +reg = <0x0 0x4e8 0x0 0x100>;
> +power-domains = <_pds 277>;
> +clocks = <_clks 277 1>;
> +assigned-clocks = <_clks 277 1>;
> +assigned-clock-parents = <_clks 277 4>;
> +
> +ranges = <0x0 0x0 0x0 0x4e8 0x0 0x14000>;
> +#address-cells = <2>;
> +#size-cells = <2>;
> +
> +ufs@4000 {
> +compatible = "cdns,ufshc-m31-16nm", "jedec,ufs-2.0";
> +reg = <0x0 0x4000 0x0 0x1>;
> +interrupts = ;
> +freq-table-hz = <1920 1920>;
> +power-domains = <_pds 277>;
> +clocks = <_clks 277 1>;
> +assigned-clocks = <_clks 277 1>;
> +assigned-clock-parents = <_clks 277 4>;
> +clock-names = "core_clk";
> +};
> +};
> };
>
Re: [PATCH v4 00/16] mtd: spi-nor: add xSPI Octal DTR support
On 12/05/20 11:46 am, tudor.amba...@microchip.com wrote: > Hi, Boris, Pratyush, > > I stripped case 2/, we'll not treat it for now. > > On Monday, May 11, 2020 12:27:12 PM EEST Boris Brezillon wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >> content is safe >> >> On Mon, 11 May 2020 09:00:35 + >> >> wrote: >>> Hi, Pratyush, Boris, >>> >>> On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote: This series adds support for octal DTR flashes in the spi-nor framework, >>> >>> I'm still learning about this, but I can give you my 2 cents as of now, to >>> open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous >>> because the flash may not recover from unexpected resets. Entering one of >>> these modes can be: >>> 1/ volatile selectable, the device return to the 1-1-1 protocol after the >>> next power-on. I guess this is conditioned by the optional RESET pin, but >>> I'll have to check. Also the flash can return to the 1-1-1 mode using the >>> software reset or through writing to its Configuration Register, without >>> power-on or power- off. >> >> My understanding is that there's no standard software reset procedure >> that guarantees no conflict with existing 1S commands, so even the >> software reset approach doesn't work here. >> > > The software reset procedure can't protect you from unexpected resets, but > the > hardware with its optional reset pin can. Pratyush to confirm. > > cut > >> >>> Not recovering from unexpected resets is unacceptable. One should always >>> prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with >>> the presence of the optional RESET pin. >> >> Totally agree with you on that one, but we know what happens in >> practice... > > What I proposed is to condition the entering in the state-full modes with the > presence of the optional RESET pin. We would introduce an optional device > tree > property for the RESET pin. If hardware doesn't implement the optional RESET# > signal, then we will not enter in the state-full modes. > Are you asking for dedicated SW controllable reset line or just an indication from DT that OSPI reset line is connected to board level soft/hard reset lines? Mandating SW controllable RESET line is bit of a stretch IMO... Board design may not allow wasting dedicated pin due to lack of GPIOs perhaps.. For eg.: TI EVM has OSPI reset line connected to board level reset out. This ensures any soft/warm/hard CPU reset will trigger OSPI Flash reset, but there is no SW control that allows OSPI flash alone to be reset. Isn't such a reset mechanism sufficient? Regards Vignesh
Re: [PATCH v4 00/16] mtd: spi-nor: add xSPI Octal DTR support
On 11/05/20 2:30 pm, tudor.amba...@microchip.com wrote: > Hi, Pratyush, Boris, > > On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote: >> This series adds support for octal DTR flashes in the spi-nor framework, > > I'm still learning about this, but I can give you my 2 cents as of now, to > open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous > because the flash may not recover from unexpected resets. Unfortunately, xSPI compliant flashes need to support 1S-1S-1S and 8D-8D-8D (or 4S-4D-4D) mode only. So we have to start supporting state-full modes > Entering one of these modes can be: > 1/ volatile selectable, the device return to the 1-1-1 protocol after the > next > power-on. I guess this is conditioned by the optional RESET pin, but I'll > have > to check. Also the flash can return to the 1-1-1 mode using the software > reset > or through writing to its Configuration Register, without power-on or power- > off. Right, I guess switching to octal mode be made conditional based upon SNOR_F_BROKEN_RESET? > 2/ non-volatile selectable in which RESET# and software reset are useless, > the > flash defaults to the mode selected in the non volatile Configuration > Register > bits. The only way to get back to 1-1-1 is to write to the Configuration > Register. > In addition to reset issue, supporting flash that boot up in Octal DDR mode (due to non-volatile setting) is still pretty difficult. Commands like Read ID and READ SFDP (that are used for flash discovery at runtime) follow different protocols across different vendors in Octal DDR mode. So its almost impossible to support such flashes w/o a hint about device type from DT (or somewhere else). I would really stick to option 1 for now until someone makes a compelling case to support option 2. > Not recovering from unexpected resets is unacceptable. One should always > prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with > the > presence of the optional RESET pin. > > For the unfortunate flashes that support just option 2/, we should not enter > these modes on our own, just by discovering the capabilities from the SFDP > tables or by the flags in the flash_info struct. The best we can do for them > is to move the responsibility to the user. Maybe to add a Kconfig option that > is disabled by default with which we condition the entering in 2-2-2, 4-4-4 > or > 8-8-8 modes. Once entered in one of these modes, if an unexpected reset > comes, > you most likely are doomed, because early stage bootloaders may not work in > these modes and you'll not be able to boot the board. Assuming that one uses > other environment to boot the board, we should at least make sure that the > flash works in linux after an unexpected reset. We should try to determine in > which mode we are at init, so maybe an extension of the default_init hook is > needed. But all this looks like a BIG compromise, I'm not yet sure if we > should adress 2/. Thoughts? > Agree, lets not worry about option 2 for now... Regards Vignesh
[PATCH 6/6] spi: Move cadence-quadspi driver to drivers/spi/
From: Ramuthevar Vadivel Murugan
Now that cadence-quadspi has been converted to use spi-mem framework,
move it under drivers/spi/
Update license header to match SPI subsystem style
Signed-off-by: Ramuthevar Vadivel Murugan
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi-nor/controllers/Kconfig| 11 ---
drivers/mtd/spi-nor/controllers/Makefile | 1 -
drivers/spi/Kconfig| 11 +++
drivers/spi/Makefile | 1 +
.../spi-cadence-quadspi.c} | 14 +++---
5 files changed, 19 insertions(+), 19 deletions(-)
rename drivers/{mtd/spi-nor/controllers/cadence-quadspi.c =>
spi/spi-cadence-quadspi.c} (99%)
diff --git a/drivers/mtd/spi-nor/controllers/Kconfig
b/drivers/mtd/spi-nor/controllers/Kconfig
index 10b86660b821..95fcd4b435be 100644
--- a/drivers/mtd/spi-nor/controllers/Kconfig
+++ b/drivers/mtd/spi-nor/controllers/Kconfig
@@ -9,17 +9,6 @@ config SPI_ASPEED_SMC
and support for the SPI flash memory controller (SPI) for
the host firmware. The implementation only supports SPI NOR.
-config SPI_CADENCE_QUADSPI
- tristate "Cadence Quad SPI controller"
- depends on OF && (ARM || ARM64 || COMPILE_TEST)
- help
- Enable support for the Cadence Quad SPI Flash controller.
-
- Cadence QSPI is a specialized controller for connecting an SPI
- Flash over 1/2/4-bit wide bus. Enable this option if you have a
- device with a Cadence QSPI controller and want to access the
- Flash as an MTD device.
-
config SPI_HISI_SFC
tristate "Hisilicon FMC SPI-NOR Flash Controller(SFC)"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/mtd/spi-nor/controllers/Makefile
b/drivers/mtd/spi-nor/controllers/Makefile
index 46e6fbe586e3..e7abba491d98 100644
--- a/drivers/mtd/spi-nor/controllers/Makefile
+++ b/drivers/mtd/spi-nor/controllers/Makefile
@@ -1,6 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o
-obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o
obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o
obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o
obj-$(CONFIG_SPI_INTEL_SPI)+= intel-spi.o
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 17e7e4afc0fc..15f308571163 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -200,6 +200,17 @@ config SPI_CADENCE
This selects the Cadence SPI controller master driver
used by Xilinx Zynq and ZynqMP.
+config SPI_CADENCE_QUADSPI
+ tristate "Cadence Quad SPI controller"
+ depends on OF && (ARM || ARM64 || COMPILE_TEST)
+ help
+ Enable support for the Cadence Quad SPI Flash controller.
+
+ Cadence QSPI is a specialized controller for connecting an SPI
+ Flash over 1/2/4-bit wide bus. Enable this option if you have a
+ device with a Cadence QSPI controller and want to access the
+ Flash as an MTD device.
+
config SPI_CLPS711X
tristate "CLPS711X host SPI controller"
depends on ARCH_CLPS711X || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 889368f4ad53..f03834d1d312 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_SPI_BCM_QSPI)+= spi-iproc-qspi.o
spi-brcmstb-qspi.o spi-bcm-qspi.
obj-$(CONFIG_SPI_BITBANG) += spi-bitbang.o
obj-$(CONFIG_SPI_BUTTERFLY)+= spi-butterfly.o
obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o
+obj-$(CONFIG_SPI_CADENCE_QUADSPI) += spi-cadence-quadspi.o
obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o
obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o
obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
similarity index 99%
rename from drivers/mtd/spi-nor/controllers/cadence-quadspi.c
rename to drivers/spi/spi-cadence-quadspi.c
index d788692efc55..de009e44f2aa 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1,11 +1,11 @@
// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Driver for Cadence QSPI Controller
- *
- * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
- * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
- * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
- */
+//
+// Driver for Cadence QSPI Controller
+//
+// Copyright Altera Corporation (C) 2012-2014. All rights reserved.
+// Copyright Intel Corporation (C) 2019-2020. All rights reserved.
+// Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
+
#include
#include
#include
--
2.26.2
[PATCH 3/6] mtd: spi-nor: cadence-quadspi: Don't initialize rx_dma_complete on failure
If driver fails to acquire DMA channel then don't initialize
rx_dma_complete struct as it won't be used.
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 4d2e732b85b1..6feb94a38dff 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1173,6 +1173,7 @@ static void cqspi_request_mmap_dma(struct cqspi_st *cqspi)
if (IS_ERR(cqspi->rx_chan)) {
dev_err(>pdev->dev, "No Rx DMA available\n");
cqspi->rx_chan = NULL;
+ return;
}
init_completion(>rx_dma_complete);
}
--
2.26.2
[PATCH 1/6] mtd: spi-nor: cadence-quadspi: Drop cdns,is-decoded-cs property
Cadence QSPI provides a way to automatically decode CS based on the
offset accessed within memory map window. This feature cannot be
supported in spi-mem framework as controller driver would not have
access to flash geometry. Therefore drop this feature in preparation to
moving to spi-mem.
Note that, this feature never worked in the driver (Direct/Indirect mode
accesses did not take into account size of flash on other CSs) and there
are no users of this feature in kernel. Therefore dropping this should
not cause a regression
Signed-off-by: Vignesh Raghavendra
---
.../mtd/spi-nor/controllers/cadence-quadspi.c | 59 +++
1 file changed, 9 insertions(+), 50 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 494dcab4..fa54f85e16d7 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -77,11 +77,7 @@ struct cqspi_st {
dma_addr_t mmap_phys_base;
int current_cs;
- int current_page_size;
- int current_erase_size;
- int current_addr_width;
unsigned long master_ref_clk_hz;
- boolis_decoded_cs;
u32 fifo_depth;
u32 fifo_width;
boolrclk_en;
@@ -715,19 +711,15 @@ static void cqspi_chipselect(struct spi_nor *nor)
unsigned int reg;
reg = readl(reg_base + CQSPI_REG_CONFIG);
- if (cqspi->is_decoded_cs) {
- reg |= CQSPI_REG_CONFIG_DECODE_MASK;
- } else {
- reg &= ~CQSPI_REG_CONFIG_DECODE_MASK;
+ reg &= ~CQSPI_REG_CONFIG_DECODE_MASK;
- /* Convert CS if without decoder.
-* CS0 to 4b'1110
-* CS1 to 4b'1101
-* CS2 to 4b'1011
-* CS3 to 4b'0111
-*/
- chip_select = 0xF & ~(1 << chip_select);
- }
+ /* Convert CS if without decoder.
+* CS0 to 4b'1110
+* CS1 to 4b'1101
+* CS2 to 4b'1011
+* CS3 to 4b'0111
+*/
+ chip_select = 0xF & ~(1 << chip_select);
reg &= ~(CQSPI_REG_CONFIG_CHIPSELECT_MASK
<< CQSPI_REG_CONFIG_CHIPSELECT_LSB);
@@ -736,32 +728,6 @@ static void cqspi_chipselect(struct spi_nor *nor)
writel(reg, reg_base + CQSPI_REG_CONFIG);
}
-static void cqspi_configure_cs_and_sizes(struct spi_nor *nor)
-{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
- struct cqspi_st *cqspi = f_pdata->cqspi;
- void __iomem *iobase = cqspi->iobase;
- unsigned int reg;
-
- /* configure page size and block size. */
- reg = readl(iobase + CQSPI_REG_SIZE);
- reg &= ~(CQSPI_REG_SIZE_PAGE_MASK << CQSPI_REG_SIZE_PAGE_LSB);
- reg &= ~(CQSPI_REG_SIZE_BLOCK_MASK << CQSPI_REG_SIZE_BLOCK_LSB);
- reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
- reg |= (nor->page_size << CQSPI_REG_SIZE_PAGE_LSB);
- reg |= (ilog2(nor->mtd.erasesize) << CQSPI_REG_SIZE_BLOCK_LSB);
- reg |= (nor->addr_width - 1);
- writel(reg, iobase + CQSPI_REG_SIZE);
-
- /* configure the chip select */
- cqspi_chipselect(nor);
-
- /* Store the new configuration of the controller */
- cqspi->current_page_size = nor->page_size;
- cqspi->current_erase_size = nor->mtd.erasesize;
- cqspi->current_addr_width = nor->addr_width;
-}
-
static unsigned int calculate_ticks_for_ns(const unsigned int ref_clk_hz,
const unsigned int ns_val)
{
@@ -867,18 +833,13 @@ static void cqspi_configure(struct spi_nor *nor)
int switch_cs = (cqspi->current_cs != f_pdata->cs);
int switch_ck = (cqspi->sclk != sclk);
- if ((cqspi->current_page_size != nor->page_size) ||
- (cqspi->current_erase_size != nor->mtd.erasesize) ||
- (cqspi->current_addr_width != nor->addr_width))
- switch_cs = 1;
-
if (switch_cs || switch_ck)
cqspi_controller_enable(cqspi, 0);
/* Switch chip select. */
if (switch_cs) {
cqspi->current_cs = f_pdata->cs;
- cqspi_configure_cs_and_sizes(nor);
+ cqspi_chipselect(nor);
}
/* Setup baudrate divisor and delays */
@@ -1145,8 +1106,6 @@ static int cqspi_of_get_pdata(struct platform_device
*pdev)
struct device_node *np = pdev->dev.of_node;
struct cqspi_st *cqspi = platform_get_drvdata(pdev);
- cqspi->is_decoded_cs = of_property_read_bool(np, "cdns,is-decoded-cs");
-
if (of_property_read_u32(np, "cdns,fifo-depth", >fifo_depth)) {
dev_err(>dev, "couldn't determine fifo-depth\n");
return -ENXIO;
--
2.26.2
[PATCH 0/6] mtd: spi-nor: Move cadence-qaudspi to spi-mem framework
This series is a subset of "[PATCH v12 0/4] spi: cadence-quadspi: Add
support for the Cadence QSPI controller" by Ramuthevar,Vadivel MuruganX
that intended to move
cadence-quadspi driver to spi-mem framework
Those patches were trying to accomplish too many things in a single set
of patches and need to split into smaller patches. This is reduced
version of above series.
Changes that are intended to make migration easy are split into separate
patches. Patches 1 to 3 drop features that cannot be supported under
spi-mem at the moment (backward compatibility is maintained).
Patch 4-5 are trivial cleanups. Patch 6 does the actual conversion to
spi-mem and patch 7 moves the driver to drivers/spi folder.
I have tested both INDAC mode (used by non TI platforms like Altera
SoCFPGA) and DAC mode (used by TI platforms) on TI EVMs.
Patches to move move bindings over to
"Documentation/devicetree/bindings/spi/" directory and also conversion
of bindig doc to YAML will be posted separately. Support for Intel
platform would follow that.
Changes since v12
- Drop intel platform related changes
- Drop DT bindings movement to YAML
- Split patch moving driver to spi-mem framework framework into
multiple patches as suggested by Tudor.
v12:
https://patchwork.ozlabs.org/project/linux-mtd/list/?series=163343=%2A=both
Vadivel,
I have maintained the additional changes needed on top of this series
for Intel platform that were part of your v12 series here (needs cleanup):
https://github.com/r-vignesh/linux.git branch: cqspi-mig
Please use above branch to test the same.
Ramuthevar Vadivel Murugan (2):
mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
spi: Move cadence-quadspi driver to drivers/spi/
Vignesh Raghavendra (4):
mtd: spi-nor: cadence-quadspi: Drop cdns,is-decoded-cs property
mtd: spi-nor: cadence-quadspi: Provide a way to disable DAC mode
mtd: spi-nor: cadence-quadspi: Don't initialize rx_dma_complete on
failure
mtd: spi-nor: cadence-quadspi: Fix error path on failure to acquire
reset lines
drivers/mtd/spi-nor/controllers/Kconfig | 11 -
drivers/mtd/spi-nor/controllers/Makefile | 1 -
drivers/spi/Kconfig | 11 +
drivers/spi/Makefile | 1 +
.../spi-cadence-quadspi.c}| 546 +++---
5 files changed, 215 insertions(+), 355 deletions(-)
rename drivers/{mtd/spi-nor/controllers/cadence-quadspi.c =>
spi/spi-cadence-quadspi.c} (73%)
--
2.26.2
[PATCH 4/6] mtd: spi-nor: cadence-quadspi: Fix error path on failure to acquire reset lines
Make sure to undo the prior changes done by the driver when exiting due
to failure to acquire reset lines.
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 6feb94a38dff..51ed644f58c5 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1352,13 +1352,13 @@ static int cqspi_probe(struct platform_device *pdev)
rstc = devm_reset_control_get_optional_exclusive(dev, "qspi");
if (IS_ERR(rstc)) {
dev_err(dev, "Cannot get QSPI reset.\n");
- return PTR_ERR(rstc);
+ goto probe_reset_failed;
}
rstc_ocp = devm_reset_control_get_optional_exclusive(dev, "qspi-ocp");
if (IS_ERR(rstc_ocp)) {
dev_err(dev, "Cannot get QSPI OCP reset.\n");
- return PTR_ERR(rstc_ocp);
+ goto probe_reset_failed;
}
reset_control_assert(rstc);
@@ -1377,7 +1377,7 @@ static int cqspi_probe(struct platform_device *pdev)
pdev->name, cqspi);
if (ret) {
dev_err(dev, "Cannot request IRQ.\n");
- goto probe_irq_failed;
+ goto probe_reset_failed;
}
cqspi_wait_idle(cqspi);
@@ -1394,7 +1394,7 @@ static int cqspi_probe(struct platform_device *pdev)
return ret;
probe_setup_failed:
cqspi_controller_enable(cqspi, 0);
-probe_irq_failed:
+probe_reset_failed:
clk_disable_unprepare(cqspi->clk);
probe_clk_failed:
pm_runtime_put_sync(dev);
--
2.26.2
