linux.git/include/linux/spi, branch v6.14 Linux kernel source tree spi: spi-mem: Estimate the time taken by operations 2025-01-10T15:20:04+00:00 Miquel Raynal miquel.raynal@bootlin.com 2025-01-10T14:45:22+00:00 226d6cb3cb799aae46d0dd19a521133997d9db11 In the SPI-NAND layer, we currently make list of operation variants from the fastest one to the slowest and there is a bit of logic in the core to go over them and pick the first one that is supported by the controller, ie. the fastest one among the supported ops. This kind of logic only works if all operations run at the same frequency, but as soon as we introduce per operation max frequencies it is not longer as obvious which operation will be faster, especially since it also depends on the PCB/controller frequency limitation. One way to make this choice more clever is to go over all the variants and for each of them derive an indicator which will help derive the theoretical best. In this case, we derive a theoretical duration for the entire operation and we take the smallest one. Add a helper that parses the spi-mem operation and returns this value. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20250110-winbond-6-11-rc1-quad-support-v3-20-7ab4bd56cf6e@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org> 
In the SPI-NAND layer, we currently make list of operation variants from
the fastest one to the slowest and there is a bit of logic in the core
to go over them and pick the first one that is supported by the
controller, ie. the fastest one among the supported ops.

This kind of logic only works if all operations run at the same
frequency, but as soon as we introduce per operation max frequencies it
is not longer as obvious which operation will be faster, especially
since it also depends on the PCB/controller frequency limitation.

One way to make this choice more clever is to go over all the
variants and for each of them derive an indicator which will help derive
the theoretical best. In this case, we derive a theoretical duration for
the entire operation and we take the smallest one.

Add a helper that parses the spi-mem operation and returns this value.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20250110-winbond-6-11-rc1-quad-support-v3-20-7ab4bd56cf6e@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
spi: spi-mem: Create macros for DTR operation 2025-01-09T20:16:39+00:00 Miquel Raynal miquel.raynal@bootlin.com 2024-12-24T17:06:04+00:00 f0006897a96c736623ddeb9b68c3880eb5cdebe7 We do have macros for defining command, address, dummy and data cycles. We also have a .dtr flag that implies sampling the bus on both edges, but there are currently no macros enabling it. We might make use of such macros, so let's create: - SPI_MEM_DTR_OP_CMD - SPI_MEM_DTR_OP_ADDR - SPI_MEM_DTR_OP_DUMMY - SPI_MEM_DTR_OP_DATA_OUT - SPI_MEM_DTR_OP_DATA_OUT Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-19-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org> 
We do have macros for defining command, address, dummy and data
cycles. We also have a .dtr flag that implies sampling the bus on both
edges, but there are currently no macros enabling it. We might make use
of such macros, so let's create:
- SPI_MEM_DTR_OP_CMD
- SPI_MEM_DTR_OP_ADDR
- SPI_MEM_DTR_OP_DUMMY
- SPI_MEM_DTR_OP_DATA_OUT
- SPI_MEM_DTR_OP_DATA_OUT

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-19-ad218dbc406f@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
spi: spi-mem: Reorder spi-mem macro assignments 2025-01-09T20:16:39+00:00 Miquel Raynal miquel.raynal@bootlin.com 2024-12-24T17:06:03+00:00 d1f85873d2d62d6980e68d21d3a21f20b0664cc3 Follow the order in which all the `struct spi_mem_op` members are defined. This is purely aesthetics, there is no functional change. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-18-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Follow the order in which all the `struct spi_mem_op` members are
defined.

This is purely aesthetics, there is no functional change.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-18-ad218dbc406f@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
spi: spi-mem: Add a new controller capability 2025-01-09T20:16:23+00:00 Miquel Raynal miquel.raynal@bootlin.com 2024-12-24T17:05:47+00:00 1248c9b8d54120950fda10fbeb98fb8932b4d45c There are spi devices with multiple frequency limitations depending on the invoked command. We probably do not want to afford running at the lowest supported frequency all the time, so if we want to get the most of our hardware, we need to allow per-operation frequency limitations. Among all the SPI memory controllers, I believe all are capable of changing the spi frequency on the fly. Some of the drivers do not make any frequency setup though. And some others will derive a per chip prescaler value which will be used forever. Actually changing the frequency on the fly is something new in Linux, so we need to carefully flag the drivers which do and do not support it. A controller capability is created for that, and the presence for this capability will always be checked before accepting such pattern. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-2-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org> 
There are spi devices with multiple frequency limitations depending on
the invoked command. We probably do not want to afford running at the
lowest supported frequency all the time, so if we want to get the most
of our hardware, we need to allow per-operation frequency limitations.

Among all the SPI memory controllers, I believe all are capable of
changing the spi frequency on the fly. Some of the drivers do not make
any frequency setup though. And some others will derive a per chip
prescaler value which will be used forever.

Actually changing the frequency on the fly is something new in Linux, so
we need to carefully flag the drivers which do and do not support it. A
controller capability is created for that, and the presence for this
capability will always be checked before accepting such pattern.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-2-ad218dbc406f@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
spi: spi-mem: Extend spi-mem operations with a per-operation maximum frequency 2025-01-09T20:16:23+00:00 Miquel Raynal miquel.raynal@bootlin.com 2024-12-24T17:05:46+00:00 0fefeade90e74bc8f40ab0e460f483565c492e28 In the spi subsystem, the bus frequency is derived as follows: - the controller may expose a minimum and maximum operating frequency - the hardware description, through the spi peripheral properties, advise what is the maximum acceptable frequency from a device/wiring point of view. Transfers must be observed at a frequency which fits both (so in practice, the lowest maximum). Actually, this second point mixes two information and already takes the lowest frequency among: - what the spi device is capable of (what is written in the component datasheet) - what the wiring allows (electromagnetic sensibility, crossovers, terminations, antenna effect, etc). This logic works until spi devices are no longer capable of sustaining their highest frequency regardless of the operation. Spi memories are typically subject to such variation. Some devices are capable of spitting their internally stored data (essentially in read mode) at a very fast rate, typically up to 166MHz on Winbond SPI-NAND chips, using "fast" commands. However, some of the low-end operations, such as regular page read-from-cache commands, are more limited and can only be executed at 54MHz at most. This is currently a problem in the SPI-NAND subsystem. Another situation, even if not yet supported, will be with DTR commands, when the data is latched on both edges of the clock. The same chips as mentioned previously are in this case limited to 80MHz. Yet another example might be continuous reads, which, under certain circumstances, can also run at most at 104 or 120MHz. As a matter of fact, the "one frequency per chip" policy is outdated and more fine grain configuration is needed: we need to allow per-operation frequency limitations. So far, all datasheets I encountered advertise a maximum default frequency, which need to be lowered for certain specific operations. So based on the current infrastructure, we can still expect firmware (device trees in general) to continued advertising the same maximum speed which is a mix between the PCB limitations and the chip maximum capability, and expect per-operation lower frequencies when this is relevant. Add a `struct spi_mem_op` member to carry this information. Not providing this field explicitly from upper layers means that there is no further constraint and the default spi device maximum speed will be carried instead. The SPI_MEM_OP() macro is also expanded with an optional frequency argument, because virtually all operations can be subject to such a limitation, and this will allow for a smooth and discrete transition. For controller drivers which do not implement the spi-mem interface, the per-transfer speed is also set acordingly to a lower (than the maximum default) speed when relevant. Acked-by: Pratyush Yadav <pratyush@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-1-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org> 
In the spi subsystem, the bus frequency is derived as follows:
- the controller may expose a minimum and maximum operating frequency
- the hardware description, through the spi peripheral properties,
  advise what is the maximum acceptable frequency from a device/wiring
  point of view.
Transfers must be observed at a frequency which fits both (so in
practice, the lowest maximum).

Actually, this second point mixes two information and already takes the
lowest frequency among:
- what the spi device is capable of (what is written in the component
  datasheet)
- what the wiring allows (electromagnetic sensibility, crossovers,
  terminations, antenna effect, etc).

This logic works until spi devices are no longer capable of sustaining
their highest frequency regardless of the operation. Spi memories are
typically subject to such variation. Some devices are capable of
spitting their internally stored data (essentially in read mode) at a
very fast rate, typically up to 166MHz on Winbond SPI-NAND chips, using
"fast" commands. However, some of the low-end operations, such as
regular page read-from-cache commands, are more limited and can only be
executed at 54MHz at most. This is currently a problem in the SPI-NAND
subsystem. Another situation, even if not yet supported, will be with
DTR commands, when the data is latched on both edges of the clock. The
same chips as mentioned previously are in this case limited to
80MHz. Yet another example might be continuous reads, which, under
certain circumstances, can also run at most at 104 or 120MHz.

As a matter of fact, the "one frequency per chip" policy is outdated and
more fine grain configuration is needed: we need to allow per-operation
frequency limitations. So far, all datasheets I encountered advertise a
maximum default frequency, which need to be lowered for certain specific
operations. So based on the current infrastructure, we can still expect
firmware (device trees in general) to continued advertising the same
maximum speed which is a mix between the PCB limitations and the chip
maximum capability, and expect per-operation lower frequencies when this
is relevant.

Add a `struct spi_mem_op` member to carry this information. Not
providing this field explicitly from upper layers means that there is no
further constraint and the default spi device maximum speed will be
carried instead. The SPI_MEM_OP() macro is also expanded with an
optional frequency argument, because virtually all operations can be
subject to such a limitation, and this will allow for a smooth and
discrete transition.

For controller drivers which do not implement the spi-mem interface, the
per-transfer speed is also set acordingly to a lower (than the maximum
default) speed when relevant.

Acked-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-1-ad218dbc406f@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge tag 'mtd/for-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux 2024-11-23T01:06:59+00:00 Linus Torvalds torvalds@linux-foundation.org 2024-11-23T01:06:59+00:00 d0c9a21c8e0b2d7c55a2174f47bd0ea1d7302de6 Pull MTD updates from Miquel Raynal: "MTD device changes: - switch platform_driver back to remove() - misc fixes SPI-NAND changes: - a load of fixes to Winbond manufacturer driver - structure constification Raw NAND changes: - improve the power management of the GPMI driver - Davinci driver clean-ups - fix leak in the Atmel driver - fix some typos in the core SPI NOR changes: - Introduce byte swap support for 8D-8D-8D mode and a user for it: macronix. SPI NOR flashes may swap the bytes on a 16-bit boundary when configured in Octal DTR mode. For such cases the byte order is propagated through SPI MEM to the SPI controllers so that the controllers swap the bytes back at runtime. This avoids breaking the boot sequence because of the endianness problems that appear when the bootloaders use 1-1-1 and the kernel uses 8D-8D-8D with byte swap support. Along with the SPI MEM byte swap support we queue a patch for the SPI MXIC controller that swaps the bytes back at runtime" * tag 'mtd/for-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (25 commits) mtd: spi-nor: core: replace dummy buswidth from addr to data mtd: spi-nor: winbond: add "w/ and w/o SFDP" comment mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in RD_ANY_REG_OP mtd: Switch back to struct platform_driver::remove() mtd: cfi_cmdset_0002: remove redundant assignment to variable ret mtd: spinand: Constify struct nand_ecc_engine_ops MAINTAINERS: add mailing list for GPMI NAND driver mtd: spinand: winbond: Sort the devices mtd: spinand: winbond: Ignore the last ID characters mtd: spinand: winbond: Fix 512GW, 01GW, 01JW and 02JW ECC information mtd: spinand: winbond: Fix 512GW and 02JW OOB layout mtd: nand: raw: gpmi: improve power management handling mtd: nand: raw: gpmi: switch to SYSTEM_SLEEP_PM_OPS mtd: rawnand: davinci: use generic device property helpers mtd: rawnand: davinci: break the line correctly mtd: rawnand: davinci: order headers alphabetically mtd: rawnand: atmel: Fix possible memory leak mtd: rawnand: Correct multiple typos in comments mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE mtd: spi-nor: add support for Macronix Octal flash ... 
Pull MTD updates from Miquel Raynal:
 "MTD device changes:
   - switch platform_driver back to remove()
   - misc fixes

  SPI-NAND changes:
   - a load of fixes to Winbond manufacturer driver
   - structure constification

  Raw NAND changes:
   - improve the power management of the GPMI driver
   - Davinci driver clean-ups
   - fix leak in the Atmel driver
   - fix some typos in the core

  SPI NOR changes:
   - Introduce byte swap support for 8D-8D-8D mode and a user for it:
     macronix.

     SPI NOR flashes may swap the bytes on a 16-bit boundary when
     configured in Octal DTR mode. For such cases the byte order is
     propagated through SPI MEM to the SPI controllers so that the
     controllers swap the bytes back at runtime. This avoids breaking
     the boot sequence because of the endianness problems that appear
     when the bootloaders use 1-1-1 and the kernel uses 8D-8D-8D with
     byte swap support. Along with the SPI MEM byte swap support we
     queue a patch for the SPI MXIC controller that swaps the bytes back
     at runtime"

* tag 'mtd/for-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (25 commits)
  mtd: spi-nor: core: replace dummy buswidth from addr to data
  mtd: spi-nor: winbond: add "w/ and w/o SFDP" comment
  mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in RD_ANY_REG_OP
  mtd: Switch back to struct platform_driver::remove()
  mtd: cfi_cmdset_0002: remove redundant assignment to variable ret
  mtd: spinand: Constify struct nand_ecc_engine_ops
  MAINTAINERS: add mailing list for GPMI NAND driver
  mtd: spinand: winbond: Sort the devices
  mtd: spinand: winbond: Ignore the last ID characters
  mtd: spinand: winbond: Fix 512GW, 01GW, 01JW and 02JW ECC information
  mtd: spinand: winbond: Fix 512GW and 02JW OOB layout
  mtd: nand: raw: gpmi: improve power management handling
  mtd: nand: raw: gpmi: switch to SYSTEM_SLEEP_PM_OPS
  mtd: rawnand: davinci: use generic device property helpers
  mtd: rawnand: davinci: break the line correctly
  mtd: rawnand: davinci: order headers alphabetically
  mtd: rawnand: atmel: Fix possible memory leak
  mtd: rawnand: Correct multiple typos in comments
  mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE
  mtd: spi-nor: add support for Macronix Octal flash
  ...
spi: spi-mem: Allow specifying the byte order in Octal DTR mode 2024-10-02T06:44:56+00:00 Tudor Ambarus tudor.ambarus@linaro.org 2024-09-26T14:19:52+00:00 030ace430afcf847f537227afceb22dfe8fb8fc8 There are NOR flashes (Macronix) that swap the bytes on a 16-bit boundary when configured in Octal DTR mode. The byte order of 16-bit words is swapped when read or written in Octal Double Transfer Rate (DTR) mode compared to Single Transfer Rate (STR) modes. If one writes D0 D1 D2 D3 bytes using 1-1-1 mode, and uses 8D-8D-8D SPI mode for reading, it will read back D1 D0 D3 D2. Swapping the bytes may introduce some endianness problems. It can affect the boot sequence if the entire boot sequence is not handled in either 8D-8D-8D mode or 1-1-1 mode. Therefore, it is necessary to swap the bytes back to ensure the same byte order as in STR modes. Fortunately there are controllers that could swap the bytes back at runtime, addressing the flash's endianness requirements. Provide a way for the upper layers to specify the byte order in Octal DTR mode. Merge Tudor's patch and add modifications for suiting newer version of Linux kernel. Suggested-by: Michael Walle <mwalle@kernel.org> Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw> Signed-off-by: AlvinZhou <alvinzhou@mxic.com.tw> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240926141956.2386374-3-alvinzhou.tw@gmail.com Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> 
There are NOR flashes (Macronix) that swap the bytes on a 16-bit
boundary when configured in Octal DTR mode. The byte order of
16-bit words is swapped when read or written in Octal Double
Transfer Rate (DTR) mode compared to Single Transfer Rate (STR)
modes. If one writes D0 D1 D2 D3 bytes using 1-1-1 mode, and uses
8D-8D-8D SPI mode for reading, it will read back D1 D0 D3 D2.
Swapping the bytes may introduce some endianness problems. It can
affect the boot sequence if the entire boot sequence is not handled
in either 8D-8D-8D mode or 1-1-1 mode. Therefore, it is necessary
to swap the bytes back to ensure the same byte order as in STR modes.
Fortunately there are controllers that could swap the bytes back at
runtime, addressing the flash's endianness requirements. Provide a
way for the upper layers to specify the byte order in Octal DTR mode.

Merge Tudor's patch and add modifications for suiting newer version
of Linux kernel.

Suggested-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Signed-off-by: AlvinZhou <alvinzhou@mxic.com.tw>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20240926141956.2386374-3-alvinzhou.tw@gmail.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
spi: remove {devm_}spi_alloc_master/slave() 2024-09-29T23:12:07+00:00 Yang Yingliang yangyingliang@huawei.com 2024-09-02T12:59:47+00:00 0809a9ccac4a2ffdfd1561bb551aec6099775545 All the {devm_}spi_alloc_master/slave() have been replaced, so they can be removed and replaced in doc and comment. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://patch.msgid.link/20240902125947.1368-8-yangyingliang@huaweicloud.com Signed-off-by: Mark Brown <broonie@kernel.org> 
All the {devm_}spi_alloc_master/slave() have been replaced,
so they can be removed and replaced in doc and comment.

No functional changed.

Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://patch.msgid.link/20240902125947.1368-8-yangyingliang@huaweicloud.com
Signed-off-by: Mark Brown <broonie@kernel.org>
spi: remove spi_controller_is_slave() and spi_slave_abort() 2024-09-10T11:41:42+00:00 Yang Yingliang yangyingliang@huawei.com 2024-09-10T02:26:17+00:00 740c1c84bfa3d8c63bd3b01fb570e7452f51fbd8 spi_controller_is_slave() and spi_slave_abort() are all replaced, so they can be removed. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://patch.msgid.link/20240910022618.1397-8-yangyingliang@huaweicloud.com Signed-off-by: Mark Brown <broonie@kernel.org> 
spi_controller_is_slave() and spi_slave_abort() are all replaced,
so they can be removed.

No functional changed.

Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://patch.msgid.link/20240910022618.1397-8-yangyingliang@huaweicloud.com
Signed-off-by: Mark Brown <broonie@kernel.org>
spi: Add dummy definitions for ACPI lookup functions 2024-08-02T20:53:04+00:00 Mark Brown broonie@kernel.org 2024-08-02T20:53:04+00:00 d196c714a54c03c81e7b5dc972814f597bfb1fac Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>: Provide empty versions of acpi_spi_count_resources(), acpi_spi_device_alloc() and acpi_spi_find_controller_by_adev() if the real functions are not being built. This commit fixes two problems with the original definitions: 1) There wasn't an empty version of these functions 2) The #if only depended on CONFIG_ACPI. But the functions are implemented in the core spi.c so CONFIG_SPI_MASTER must also be enabled for the real functions to exist. 
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:

Provide empty versions of acpi_spi_count_resources(),
acpi_spi_device_alloc() and acpi_spi_find_controller_by_adev()
if the real functions are not being built.

This commit fixes two problems with the original definitions:

1) There wasn't an empty version of these functions
2) The #if only depended on CONFIG_ACPI. But the functions are implemented
   in the core spi.c so CONFIG_SPI_MASTER must also be enabled for the real
   functions to exist.