History log of /openbmc/linux/drivers/spi/spi-atmel.c (Results 1 – 25 of 944)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.6.67, v6.6.66, v6.6.65, v6.6.64, v6.6.63, v6.6.62, v6.6.61, v6.6.60, v6.6.59, v6.6.58, v6.6.57, v6.6.56, v6.6.55, v6.6.54, v6.6.53, v6.6.52, v6.6.51, v6.6.50, v6.6.49, v6.6.48, v6.6.47, v6.6.46, v6.6.45, v6.6.44, v6.6.43, v6.6.42, v6.6.41, v6.6.40, v6.6.39, v6.6.38, v6.6.37, v6.6.36, v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23
# 3e7759b9 10-Feb-2024 Andrew Jeffery <andrew@codeconstruct.com.au>

Merge tag 'v6.6.9' into dev-6.6

This is the 6.6.9 stable release


Revision tags: v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5
# dbf0c97f 04-Dec-2023 Louis Chauvet <louis.chauvet@bootlin.com>

spi: atmel: Fix clock issue when using devices with different polarities

commit fc70d643a2f6678cbe0f5c86433c1aeb4d613fcc upstream.

The current Atmel SPI controller driver (v2) behaves incorrectly w

spi: atmel: Fix clock issue when using devices with different polarities

commit fc70d643a2f6678cbe0f5c86433c1aeb4d613fcc upstream.

The current Atmel SPI controller driver (v2) behaves incorrectly when
using two SPI devices with different clock polarities and GPIO CS.

When switching from one device to another, the controller driver first
enables the CS and then applies whatever configuration suits the targeted
device (typically, the polarities). The side effect of such order is the
apparition of a spurious clock edge after enabling the CS when the clock
polarity needs to be inverted wrt. the previous configuration of the
controller.

This parasitic clock edge is problematic when the SPI device uses that edge
for internal processing, which is perfectly legitimate given that its CS
was asserted. Indeed, devices such as HVS8080 driven by driver gpio-sr in
the kernel are shift registers and will process this first clock edge to
perform a first register shift. In this case, the first bit gets lost and
the whole data block that will later be read by the kernel is all shifted
by one.

Current behavior:
The actual switching of the clock polarity only occurs after the CS
when the controller sends the first message:

CLK ------------\ /-\ /-\
| | | | | . . .
\---/ \-/ \
CS -----\
|
\------------------

^ ^ ^
| | |
| | Actual clock of the message sent
| |
| Change of clock polarity, which occurs with the first
| write to the bus. This edge occurs when the CS is
| already asserted, and can be interpreted as
| the first clock edge by the receiver.
|
GPIO CS toggle

This issue is specific to this controller because while the SPI core
performs the operations in the right order, the controller however does
not. In practice, the controller only applies the clock configuration right
before the first transmission.

So this is not a problem when using the controller's dedicated CS, as the
controller does things correctly, but it becomes a problem when you need to
change the clock polarity and use an external GPIO for the CS.

One possible approach to solve this problem is to send a dummy message
before actually activating the CS, so that the controller applies the clock
polarity beforehand.

New behavior:

CLK ------\ /-\ /-\ /-\ /-\
| | | ... | | | | ... | |
\------/ \- -/ \------/ \- -/ \------

CS -\/-----------------------\
|| |
\/ \---------------------
^ ^ ^ ^ ^
| | | | |
| | | | Expected clock cycles when
| | | | sending the message
| | | |
| | | Actual GPIO CS activation, occurs inside
| | | the driver
| | |
| | Dummy message, to trigger clock polarity
| | reconfiguration. This message is not received and
| | processed by the device because CS is low.
| |
| Change of clock polarity, forced by the dummy message. This
| time, the edge is not detected by the receiver.
|
This small spike in CS activation is due to the fact that the
spi-core activates the CS gpio before calling the driver's
set_cs callback, which deactivates this gpio again until the
clock polarity is correct.

To avoid having to systematically send a dummy packet, the driver keeps
track of the clock's current polarity. In this way, it only sends the dummy
packet when necessary, ensuring that the clock will have the correct
polarity when the CS is toggled.

There could be two hardware problems with this patch:
1- Maybe the small CS activation peak can confuse SPI devices
2- If on a design, a single wire is used to select two devices depending
on its state, the dummy message may disturb them.

Fixes: 5ee36c989831 ("spi: atmel_spi update chipselect handling")
Cc: <stable@vger.kernel.org>
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Link: https://msgid.link/r/20231204154903.11607-1-louis.chauvet@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


# 4b74558a 05-Dec-2023 Miquel Raynal <miquel.raynal@bootlin.com>

spi: atmel: Prevent spi transfers from being killed

commit 890188d2d7e4ac6c131ba166ca116cb315e752ee upstream.

Upstream commit e0205d6203c2 ("spi: atmel: Prevent false timeouts on
long transfers") h

spi: atmel: Prevent spi transfers from being killed

commit 890188d2d7e4ac6c131ba166ca116cb315e752ee upstream.

Upstream commit e0205d6203c2 ("spi: atmel: Prevent false timeouts on
long transfers") has tried to mitigate the problem of getting spi
transfers canceled because they were lasting too long. On slow buses,
transfers in the MiB range can take more than one second and thus a
calculation was added to progressively increment the timeout value. In
order to not be too problematic from a user point of view (waiting dozen
of seconds or even minutes), the wait call was turned interruptible.

Turning the wait interruptible was a mistake as what we really wanted to
do was to be able to kill a transfer. Any signal interrupting our
transfer would not be suitable at all so a second attempt was made at
turning the wait killable instead.

Link: https://lore.kernel.org/linux-spi/20231127095842.389631-1-miquel.raynal@bootlin.com/

All being well, it was reported that JFFS2 was showing a splat when
interrupting a transfer. After some more debate about whether JFFS2
should be fixed and how, it was also pointed out that the whole
consistency of the filesystem in case of parallel I/O would be
compromised. Changing JFFS2 behavior would in theory be possible but
nobody has the energy and time and knowledge to do this now, so better
prevent spi transfers to be interrupted by the user.

Partially revert the blamed commit to no longer use the interruptible
nor the killable variant of wait_for_completion().

Fixes: e0205d6203c2 ("spi: atmel: Prevent false timeouts on long transfers")
Cc: <stable@vger.kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Ronald Wahl <ronald.wahl@raritan.com>
Link: https://lore.kernel.org/r/20231205083102.16946-1-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


Revision tags: v6.6.4, v6.6.3
# 662ae991 27-Nov-2023 Miquel Raynal <miquel.raynal@bootlin.com>

spi: atmel: Do not cancel a transfer upon any signal

commit 1ca2761a7734928ffe0678f88789266cf3d05362 upstream.

The intended move from wait_for_completion_*() to
wait_for_completion_interruptible_*(

spi: atmel: Do not cancel a transfer upon any signal

commit 1ca2761a7734928ffe0678f88789266cf3d05362 upstream.

The intended move from wait_for_completion_*() to
wait_for_completion_interruptible_*() was to allow (very) long spi memory
transfers to be stopped upon user request instead of freezing the
machine forever as the timeout value could now be significantly bigger.

However, depending on the user logic, applications can receive many
signals for their own "internal" purpose and have nothing to do with the
requested kernel operations, hence interrupting spi transfers upon any
signal is probably not a wise choice. Instead, let's switch to
wait_for_completion_killable_*() to only catch the "important"
signals. This was likely the intended behavior anyway.

Fixes: e0205d6203c2 ("spi: atmel: Prevent false timeouts on long transfers")
Cc: stable@vger.kernel.org
Reported-by: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20231127095842.389631-1-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


Revision tags: v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3
# c900529f 12-Sep-2023 Thomas Zimmermann <tzimmermann@suse.de>

Merge drm/drm-fixes into drm-misc-fixes

Forwarding to v6.6-rc1.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>


Revision tags: v6.5.2, v6.1.51, v6.5.1
# 1ac731c5 30-Aug-2023 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge branch 'next' into for-linus

Prepare input updates for 6.6 merge window.


Revision tags: v6.1.50
# 3b6bf5b1 29-Aug-2023 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'spi-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

Pull spi updates from Mark Brown:
"There's been quite a lot of generic activity here, but more
administrative tha

Merge tag 'spi-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

Pull spi updates from Mark Brown:
"There's been quite a lot of generic activity here, but more
administrative than featuers. We also have a bunch of new drivers,
including one that's part of a MFD so we pulled in the core parts of
that:

- Lots of work from both Yang Yingliang and Andy Shevchenko on moving
to host/device/controller based terminology for devices.

- QuadSPI SPI support for Allwinner sun6i.

- New device support Cirrus Logic CS43L43, Longsoon, Qualcomm GENI
QuPv3 and StarFive JH7110 QSPI"

* tag 'spi-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (151 commits)
spi: at91-usart: Use PTR_ERR_OR_ZERO() to simplify code
spi: spi-sn-f-ospi: switch to use modern name
spi: sifive: switch to use modern name
spi: sh: switch to use modern name
spi: sh-sci: switch to use modern name
spi: sh-msiof: switch to use modern name
spi: sh-hspi: switch to use modern name
spi: sc18is602: switch to use modern name
spi: s3c64xx: switch to use modern name
spi: rzv2m-csi: switch to use devm_spi_alloc_host()
spi: rspi: switch to use spi_alloc_host()
spi: rockchip: switch to use modern name
spi: rockchip-sfc: switch to use modern name
spi: realtek-rtl: switch to use devm_spi_alloc_host()
spi: rb4xx: switch to use modern name
spi: qup: switch to use modern name
spi: spi-qcom-qspi: switch to use modern name
spi: pxa2xx: switch to use modern name
spi: ppc4xx: switch to use modern name
spi: spl022: switch to use modern name
...

show more ...


Revision tags: v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44
# 2612e3bb 07-Aug-2023 Rodrigo Vivi <rodrigo.vivi@intel.com>

Merge drm/drm-next into drm-intel-next

Catching-up with drm-next and drm-intel-gt-next.
It will unblock a code refactor around the platform
definitions (names vs acronyms).

Signed-off-by: Rodrigo V

Merge drm/drm-next into drm-intel-next

Catching-up with drm-next and drm-intel-gt-next.
It will unblock a code refactor around the platform
definitions (names vs acronyms).

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

show more ...


# 9f771739 07-Aug-2023 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Merge drm/drm-next into drm-intel-gt-next

Need to pull in b3e4aae612ec ("drm/i915/hdcp: Modify hdcp_gsc_message msg sending mechanism") as
a dependency for https://patchwork.freedesktop.org/series/1

Merge drm/drm-next into drm-intel-gt-next

Need to pull in b3e4aae612ec ("drm/i915/hdcp: Modify hdcp_gsc_message msg sending mechanism") as
a dependency for https://patchwork.freedesktop.org/series/121735/

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

show more ...


Revision tags: v6.1.43, v6.1.42, v6.1.41
# 61b73694 24-Jul-2023 Thomas Zimmermann <tzimmermann@suse.de>

Merge drm/drm-next into drm-misc-next

Backmerging to get v6.5-rc2.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>


Revision tags: v6.1.40, v6.1.39
# 50501936 17-Jul-2023 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge tag 'v6.4' into next

Sync up with mainline to bring in updates to shared infrastructure.


# 0791faeb 17-Jul-2023 Mark Brown <broonie@kernel.org>

ASoC: Merge v6.5-rc2

Get a similar baseline to my other branches, and fixes for people using
the branch.


# 64a7b0e0 12-Jul-2023 Mark Brown <broonie@kernel.org>

spi: Header and core clean up and refactoring

Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

Various cleanups and refactorings of the SPI header and core parts
united in a s

spi: Header and core clean up and refactoring

Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

Various cleanups and refactorings of the SPI header and core parts
united in a single series. It also touches drivers under SPI subsystem
folder on the pure renaming purposes of some constants.

No functional change intended.

show more ...


# 82238d2c 10-Jul-2023 Andy Shevchenko <andriy.shevchenko@linux.intel.com>

spi: Rename SPI_MASTER_GPIO_SS to SPI_CONTROLLER_GPIO_SS

Rename SPI_MASTER_GPIO_SS to SPI_CONTROLLER_GPIO_SS and
convert the users to SPI_CONTROLLER_GPIO_SS to follow
the new naming shema.

Signed-o

spi: Rename SPI_MASTER_GPIO_SS to SPI_CONTROLLER_GPIO_SS

Rename SPI_MASTER_GPIO_SS to SPI_CONTROLLER_GPIO_SS and
convert the users to SPI_CONTROLLER_GPIO_SS to follow
the new naming shema.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230710154932.68377-14-andriy.shevchenko@linux.intel.com
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 90366cd6 10-Jul-2023 Andy Shevchenko <andriy.shevchenko@linux.intel.com>

spi: Get rid of old SPI_MASTER_MUST_TX & SPI_MASTER_MUST_RX

Convert the users from SPI_MASTER_MUST_TX and/or SPI_MASTER_MUST_RX
to SPI_CONTROLLER_MUST_TX and/or SPI_CONTROLLER_MUST_RX respectively
a

spi: Get rid of old SPI_MASTER_MUST_TX & SPI_MASTER_MUST_RX

Convert the users from SPI_MASTER_MUST_TX and/or SPI_MASTER_MUST_RX
to SPI_CONTROLLER_MUST_TX and/or SPI_CONTROLLER_MUST_RX respectively
and kill the not used anymore definitions.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230710154932.68377-13-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 2f98e686 11-Jul-2023 Maxime Ripard <mripard@kernel.org>

Merge v6.5-rc1 into drm-misc-fixes

Boris needs 6.5-rc1 in drm-misc-fixes to prevent a conflict.

Signed-off-by: Maxime Ripard <mripard@kernel.org>


# 616a733c 05-Jul-2023 Yangtao Li <frank.li@vivo.com>

spi: atmel: Use devm_platform_get_and_ioremap_resource()

Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
wha

spi: atmel: Use devm_platform_get_and_ioremap_resource()

Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.

Signed-off-by: Yangtao Li <frank.li@vivo.com>
Link: https://lore.kernel.org/r/20230706032727.9180-1-frank.li@vivo.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


Revision tags: v6.1.38, v6.1.37
# 44f10dbe 30-Jun-2023 Andrew Morton <akpm@linux-foundation.org>

Merge branch 'master' into mm-hotfixes-stable


# 84fccbba 28-Jun-2023 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'spi-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

Pull spi updates from Mark Brown:
"One small core feature this time around but mostly driver improvements
and add

Merge tag 'spi-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

Pull spi updates from Mark Brown:
"One small core feature this time around but mostly driver improvements
and additions for SPI:

- Add support for controlling the idle state of MOSI, some systems
can support this and depending on the system integration may need
it to avoid glitching in some situations

- Support for polling mode in the S3C64xx driver and DMA on the
Qualcomm QSPI driver

- Support for several Allwinner SoCs, AMD Pensando Elba, Intel Mount
Evans, Renesas RZ/V2M, and ST STM32H7"

* tag 'spi-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (66 commits)
spi: dt-bindings: atmel,at91rm9200-spi: fix broken sam9x7 compatible
spi: dt-bindings: atmel,at91rm9200-spi: add sam9x7 compatible
spi: Add support for Renesas CSI
spi: dt-bindings: Add bindings for RZ/V2M CSI
spi: sun6i: Use the new helper to derive the xfer timeout value
spi: atmel: Prevent false timeouts on long transfers
spi: dt-bindings: stm32: do not disable spi-slave property for stm32f4-f7
spi: Create a helper to derive adaptive timeouts
spi: spi-geni-qcom: correctly handle -EPROBE_DEFER from dma_request_chan()
spi: stm32: disable spi-slave property for stm32f4-f7
spi: stm32: introduction of stm32h7 SPI device mode support
spi: stm32: use dmaengine_terminate_{a}sync instead of _all
spi: stm32: renaming of spi_master into spi_controller
spi: dw: Remove misleading comment for Mount Evans SoC
spi: dt-bindings: snps,dw-apb-ssi: Add compatible for Intel Mount Evans SoC
spi: dw: Add compatible for Intel Mount Evans SoC
spi: s3c64xx: Use dev_err_probe()
spi: s3c64xx: Use the managed spi master allocation function
spi: spl022: Probe defer is no error
spi: spi-imx: fix mixing of native and gpio chipselects for imx51/imx53/imx6 variants
...

show more ...


Revision tags: v6.1.36, v6.4
# a77541ca 22-Jun-2023 Mark Brown <broonie@kernel.org>

spi: Helper for deriving timeout values

Merge series from Miquel Raynal <miquel.raynal@bootlin.com>:

I recently came across an issue with the Atmel spi controller driver
which would stop my transfe

spi: Helper for deriving timeout values

Merge series from Miquel Raynal <miquel.raynal@bootlin.com>:

I recently came across an issue with the Atmel spi controller driver
which would stop my transfers after a too small timeout when performing
big transfers (reading a 4MiB flash in one transfer). My initial idea
was to derive a the maximum amount of time a transfer would take
depending on its size and use that as value to avoid erroring-out when
not relevant. Mark wanted to go further by creating a core helper doing
that, based on the heuristics from the sun6i driver.

Here is a small series of 3 patches doing exactly that.

show more ...


# e0205d62 22-Jun-2023 Miquel Raynal <miquel.raynal@bootlin.com>

spi: atmel: Prevent false timeouts on long transfers

A slow SPI bus clocks at ~20MHz, which means it would transfer about
2500 bytes per second with a single data line. Big transfers, like when
deal

spi: atmel: Prevent false timeouts on long transfers

A slow SPI bus clocks at ~20MHz, which means it would transfer about
2500 bytes per second with a single data line. Big transfers, like when
dealing with flashes can easily reach a few MiB. The current DMA timeout
is set to 1 second, which means any working transfer of about 4MiB will
always be cancelled.

With the above derivations, on a slow bus, we can assume every byte will
take at most 0.4ms. Said otherwise, we could add 4ms to the 1-second
timeout delay every 10kiB. On a 4MiB transfer, it would bring the
timeout delay up to 2.6s which still seems rather acceptable for a
timeout.

The consequence of this is that long transfers might be allowed, which
hence requires the need to interrupt the transfer if wanted by the
user. We can hence switch to the _interruptible variant of
wait_for_completion. This leads to a little bit more handling to also
handle the interrupted case but looks really acceptable overall.

While at it, we drop the useless, noisy and redundant WARN_ON() call.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Ryan Wanner <ryan.wanner@microchip.com>
Link: https://lore.kernel.org/r/Message-Id: <20230622090634.3411468-3-miquel.raynal@bootlin.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


Revision tags: v6.1.35
# db6da59c 15-Jun-2023 Thomas Zimmermann <tzimmermann@suse.de>

Merge drm/drm-next into drm-misc-next-fixes

Backmerging to sync drm-misc-next-fixes with drm-misc-next.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>


Revision tags: v6.1.34
# 03c60192 12-Jun-2023 Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

Merge branch 'drm-next' of git://anongit.freedesktop.org/drm/drm into msm-next-lumag-base

Merge the drm-next tree to pick up the DRM DSC helpers (merged via
drm-intel-next tree). MSM DSC v1.2 patche

Merge branch 'drm-next' of git://anongit.freedesktop.org/drm/drm into msm-next-lumag-base

Merge the drm-next tree to pick up the DRM DSC helpers (merged via
drm-intel-next tree). MSM DSC v1.2 patches depend on these helpers.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

show more ...


Revision tags: v6.1.33
# 5c680050 06-Jun-2023 Miquel Raynal <miquel.raynal@bootlin.com>

Merge tag 'v6.4-rc4' into wpan-next/staging

Linux 6.4-rc4


# 9ff17e6b 05-Jun-2023 Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Merge drm/drm-next into drm-intel-gt-next

For conflict avoidance we need the following commit:

c9a9f18d3ad8 drm/i915/huc: use const struct bus_type pointers

Signed-off-by: Tvrtko Ursulin <tvrtko

Merge drm/drm-next into drm-intel-gt-next

For conflict avoidance we need the following commit:

c9a9f18d3ad8 drm/i915/huc: use const struct bus_type pointers

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

show more ...


12345678910>>...38