Update recent parallel memory support code to move to log_debug instead
of debug as per logging in U-Boot documentation
Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@amd.com>
Link: https://lore.kernel.org/r/20250107145110.2855213-1-ibai.erkiaga-elorza@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The mxc_get_clock function is around for compatibility with older
drivers that are not clock aware. In this case asking for the clk for
MXC_CSPI_CLK does not take into account there are multiple SPI busses on
modern IMX SoC's and it will return the clock for the first bus which
may not be used or configured.
In the case you are not using the first bus you will not get the proper
clock. Fix this by obtaining the clock rate from the bus clock.
This resolves an invalid SPI clock frequency configuration for SPI2 on a
board where SPI1 is not used.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
The correct spelling is R-Car, including the dash, update the usage.
Kconfig strings and comment changes only, no functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
As the flash reset is handled in spi nor core, removing the
flash reset functionality. As the configuration like tristate
and hysterisis need to be enabled by the cdo. Handle the flash
reset only for mini u-boot case.
Rename the "cadence_qspi_versal_flash_reset" to generic name
"cadence_qspi_flash_reset" as this can be used by other platforms
as well.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20241108063537.13180-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Moving the hw_reset function from the controller driver to
the NOR framework has caused the OSPI reset not to be triggered
in the Cadence driver's probe function. As a result, reading the
flash ID during SPI calibration is incorrect, and the
CQSPI_REG_RD_DATA_CAPTURE is set with an invalid value.This makes
it unable to read the flash ID properly.
To solve this problem, it's suggested to skip SPI calibration and
instead retrieve the read_delay directly from the device tree.
Skipping SPI calibration doesn't bring harm since there's no need
for the flash golden values stored during SPI calibration.
Instead, they are now read during the spi_nor_read_id call in the
NOR framework.
Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20241114062045.17581-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The 5d40b3d384 ("mtd: spi-nor: Add parallel and stacked memories support")
adds new SPI bus flags, but also introduces a completely new set of
SPI bus flags in another location. The existing flags field is type
u8, while the new separate flags are BIT(8) and higher. Use of those
new flags triggers integer overflow.
Drop the newly introduced flags which were never used anywhere in the
code. Move the one remaining flag which was used in the correct place
and change it from BIT(8) to BIT(6) so it fits the u8 flags.
Fixes: 5d40b3d384 ("mtd: spi-nor: Add parallel and stacked memories support")
Addresses-Coverity-ID: 510804 Extra high-order bits
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
The SPI_ADVANCE description does not explain what the switch does.
It does not have anything to do with any advanced functionality, it
only gates off support for stacked and parallel SPI NORs. Rename the
Kconfig symbol, update description, and move it right next to Xilinx
hardware as it seems to be specific to this hardware. Make sure the
symbol is also protected by if DM_SPI in Kconfig.
Fixes: 5d40b3d384 ("mtd: spi-nor: Add parallel and stacked memories support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.
Update the comment in bootstage to refer to this symbol, instead of
SPL_
Signed-off-by: Simon Glass <sjg@chromium.org>
John Watts <contact@jookia.org> says:
I'm doing some SPI work so I tried to compile all the drivers on my
sunxi board to try and avoid some regressions. This failed, so here are
some fixes for this.
Link: https://lore.kernel.org/r/20240427-spikconfig-v1-0-8a54772522f4@jookia.org
Signed-off-by: Tom Rini <trini@konsulko.com>
These dependencies are required for building the drivers and create
compile errors if not enabled.
Signed-off-by: John Watts <contact@jookia.org>
[trini: Add ARCH_MVEBU to KIRKWOOD_SPI]
Signed-off-by: Tom Rini <trini@konsulko.com>
Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com> says:
This series adds support for Xilinx qspi parallel and
stacked memeories.
In parallel mode, the current implementation assumes that a maximum
of two flashes are connected. The QSPI controller splits the data
evenly between both the flashes so, both the flashes that are connected
in parallel mode should be identical.
During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in
nor->flags.
In stacked mode the current implementation assumes that a maximum of two
flashes are connected and both the flashes are of same make but can differ
in sizes. So, except the sizes all other flash parameters of both the flashes
are identical.
Spi-nor will pass on the appropriate flash select flag to low level driver,
and it will select pass all the data to that particular flash.
Write operation in parallel mode are performed in page size * 2 chunks as
each write operation results in writing both the flashes. For doubling the
address space each operation is performed at addr/2 flash offset, where addr
is the address specified by the user.
Similarly for read and erase operations it will read from both flashes, so
size and offset are divided by 2 and send to flash.
Add support for parallel memories in zynq_qspi.c driver. In case of
parallel memories STRIPE bit is set and sent to the qspi ip, which will
send data bits to both the flashes in parallel. However for few commands
we should not use stripe, instead send same data to both the flashes.
Those commands are exclueded by using zynqmp_qspi_update_stripe().
Also update copyright info for this file.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Add support for parallel memories in zynqmp_gqspi.c driver. In case of
parallel memories STRIPE bit is set and sent to the qspi ip, which will
send data bits to both the flashes in parallel. However for few commands
we should not use stripe, instead send same data to both the flashes.
Those commands are exclueded by using zynqmp_qspi_update_stripe().
Also update copyright info for this file.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Read chipselect properties from DT which are populated using 'reg'
property and save it in plat->cs[] array for later use.
Also read multi chipselect capability which is used for
parallel-memories and return errors if they are passed on using DT but
driver is not capable of handling it.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
In parallel mode, the current implementation assumes that a maximum of
two flashes are connected. The QSPI controller splits the data evenly
between both the flashes so, both the flashes that are connected in
parallel mode should be identical.
During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in
nor->flags.
In stacked mode the current implementation assumes that a maximum of two
flashes are connected and both the flashes are of same make but can
differ in sizes. So, except the sizes all other flash parameters of both
the flashes are identical
Spi-nor will pass on the appropriate flash select flag to low level
driver, and it will select pass all the data to that particular flash.
Write operation in parallel mode are performed in page size * 2 chunks as
each write operation results in writing both the flashes. For doubling
the address space each operation is performed at addr/2 flash offset,
where addr is the address specified by the user.
Similarly for read and erase operations it will read from both flashes,
so size and offset are divided by 2 and send to flash.
Adding the config option SPI_ADVANCE for non SPL code.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
A write to the TX buffer is performed before entering the loop to "avoid
clock starvation". This sometimes results in subsequent writes in
davinci_spi_xfer_data() to occur while the TXFULL bit is asserted,
leading to write failures.
Remove the preload of the TX buffer.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Add device tree compatible string "renesas,rcar-gen4-rpc-if" to
the driver to match on upstream RPC DT node in R-Car Gen4 DTs.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Make sure RPC PHY timing registers are configured before performing
bus access. These registers might have been left unconfigured or may
have been configured by a prior stage bootloader and leaving them
unconfigured or misconfigured would interfere with U-Boot operation.
Set PHYOFFSET1 DDRTMG field to 3 which enables DDR timing adjustment
when SPIDRE or DRDRE = 0 and set PHYOFFSET2 OCTTMG field to 4 which
makes the interface operate in Serial flash or HyperFlash mode.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Make sure DRDRENR register is configured before performing external
address space read. This register might have been configured by a
prior stage bootloader and leaving it unconfigured would interfere
with U-Boot operation. Since U-Boot RPC SPI driver does not support
DDR data transfer mode yet, set this register unconditionally to 0.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Instead of writing DRDMCR with 0 first and then overwriting DRDMCR again
in case any dummy bytes have to be sent out, write DRDMCR in every case
with the amount of dummy bytes that have to be sent out. In case no dummy
bytes have to be sent out, the value written into DRDMCR is zero, so no
dummy bytes are sent out. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Instead of writing DREAR with 0 first and then overwriting DREAR again
in case of 4 byte addressing mode, write DREAR in every case once with
the correct content right away. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Some boards don't have chipselect lines for leds so cs-gpios is not
specified in the dts leading to probing error. Fix it by making
behavior similar to the one in Linux, parse num-chipselects and
if it is zero, ignore cs-gpios.
Signed-off-by: Michael Polyntsov <michael.polyntsov@iopsys.eu>
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
The patch fix a missprint introduced in commit 2e9fe73a88 ("spi: soft_spi:
Support the recommended soft spi properties").
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
If the maximum frequency is requested, we still fall into the CDR2
handling. But there the minimal divider is 2. For the sun6i and sun8i we
can do better with the CDR1 setting where the minimal divider is 1:
SPI_CLK = MOD_CLK / 2 ^ cdr with cdr = 0
Thus, handle the div = 1 case specially.
While at it, correct the comment above the calculation.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
The CDR2 divider calculation always yield a frequency greater than the
requested one. Use DIV_ROUND_UP() to keep the frequency equal or below
the requested one. This way, we can also drop the "if div > 0" check
because we know for a fact that div cannot be zero.
FWIW, this aligns the CDR2 calculation with the linux driver.
Suggested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Michal Simek <michal.simek@amd.com>
The driver is trying to read the "spi-max-frequency" property of the
*controller* driver node. There is no such property. The
"spi-max-frequency" property belongs to the SPI devices on the bus.
Right now, the driver will always fall back to the default value of 1MHz
and thus flash reads are very slow with just about 215kb/s.
In fact, the SPI uclass will already take care of everything and we just
have to clamp the frequency to the values the driver/hardware supports.
Thus, drop the whole max_hz handling.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Upstream kernel linux use a different compatible mediatek,spi-ipm.
Add support for this compatible and add handling for the additional
clock similar to how it's done by the upstream driver and handling for
all the property enabled by default.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Remove <common.h> from this driver directory and when needed
add missing include files directly.
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Add spi nor flash controller driver for cv1800b SoC
Signed-off-by: Kongyang Liu <seashell11234455@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Set the speed requested through mpc8xx_spi_set_speed() instead
of hardcoding a fixed speed.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
On CPM, the RISC core is a lot more efficiant when doing transfers
in 16-bits chunks than in 8-bits chunks, but unfortunately the
words need to be byte swapped.
So, for large tranfers with an even size, allocate a temporary
buffer and byte-swap data before and after transfer.
This change allows setting higher speed for transfer. For instance
on an MPC 8xx (CPM1 comms RISC processor), the documentation tells
that transfer in byte mode at 1 kbit/s uses 0.200% of CPM load
at 25 MHz while a word transfer at the same speed uses 0.032%
of CPM load. This means the speed can be 6 times higher in
word mode for the same CPM load.
For small transfers, the load reduction is not worth the CPU load
required to allocate the temporary buffer, so do it only when data
size is over 64 bytes.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Perform multiple transfer of size MAX_BUFFER when the data to be
transferred is longer than MAX_BUFFER.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
SDMA configuration register needs to be set up only once and doesn't
belong to drivers. Also, the value to be used is different on mpc885.
So do the init in cpu_init_f() with 0x40 for mpc885 and 0x1 for others.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
