spi: cadence_qspi: Select flash subnode at runtime
Currently spi driver gets flash parameter from first subnode.
Few boards have more than one flash with different parameters
and selection of flash is done by on board switch settings.
In such case, uboot needs to be recompiled with updated
device tree to align with board switch settings.
This patch allows to select flash node at runtime.
Boards those are supporting multiple flashes
needs to implement cadence_qspi_get_subnode function and return correct
flash node.
Cc: Apurva Nandan <a-nandan@ti.com> Signed-off-by: Udit Kumar <u-kumar1@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
mtd: spi-nor: Add MT25U01G part number for SPI NOR Flash
MT25QU01 OPN with 4B OPCODE support is currently not supported in
source code and the driver reuses the definition for "n25q00a"
which has the same silicon ID but is a slower part.
Adding mt25u01g definition to the source code to support a faster
read response for MT25QU01 QSPI NOR Flash device.
Signed-off-by: Jit Loon Lim <jit.loon.lim@intel.com>
[jagan: fix the id position and commit head] Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
William Zhang [Sat, 12 Aug 2023 02:03:19 +0000 (19:03 -0700)]
spi: bcm63xx-hsspi: Fix compiler warning
When build for arm64 target, comipler reports the following warning:
drivers/spi/bcm63xx_hsspi.c: In function ‘bcm63xx_hsspi_xfer_dummy_cs’:
include/linux/kernel.h:184:17: warning: comparison of distinct pointer
types lacks a cast
184 | (void) (&_min1 == &_min2); \
| ^~
drivers/spi/bcm63xx_hsspi.c:298:22: note: in expansion of macro ‘min’
298 | size_t curr_step = min(step_size, data_bytes);
This change fix this warning by casting the data_bytes to size_t.
Chanho Park [Sun, 3 Dec 2023 08:30:40 +0000 (17:30 +0900)]
watchdog: Correct watchdog timeout print message
The wdt_start function takes timeout_ms as a parameter and starts the
watchdog with this value. However, when you output the message, it shows
the default timeout value for the watchdog device.
So this patch fixes that part to output the correct timeout value.
Before -->
StarFive # wdt start 3000
WDT: Started watchdog@13070000 without servicing (60s timeout)
After -->
StarFive # wdt start 3000
WDT: Started watchdog@13070000 without servicing (3s timeout)
Fixes: c2fd0ca1a822 ("watchdog: Integrate watchdog triggering into the cyclic framework") Signed-off-by: Chanho Park <chanho61.park@samsung.com> Reviewed-by: Stefan Roese <sr@denx.de>
Cong Dang [Mon, 19 Jun 2023 22:41:50 +0000 (00:41 +0200)]
ARM: dts: renesas: Disable RPC driver on R8A779G0 V4H White Hawk board
As requirement of CR side, QSPI Flash usage via RPC driver shall
be disabled and leaving the control of this module to CR side.
Perform DT modification to disable the RPC SPI.
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Cong Dang <cong.dang.xn@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: Do not modify defconfig, modify the DT instead, this way
the RPC SPI can be enabled without recompiling the U-Boot
itself. Update commit message accordingly.]
Use the phandle reference to &rpc node in arch/arm/dts/r8a779g0.dtsi
and remove properties which are already in arch/arm/dts/r8a779g0.dtsi.
No functional change and no resulting DT change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Compiling with CONFIG_USB_XHCI_PCI and CONFIG_PCI=n results in
usb/host/xhci-pci.c:48:(.text.xhci_pci_probe+0x44):
undefined reference to `dm_pci_write_config32
Add the missing Kconfig dependency.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Marek Vasut <marex@denx.de>
Hector Martin [Sun, 29 Oct 2023 07:23:30 +0000 (16:23 +0900)]
usb: storage: Use the correct CBW lengths
USB UFI uses fixed 12-byte commands (as does RBC, which is not
supported), but SCSI does not have this limitation. Use the correct
command block lengths depending on the subclass.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Marek Vasut <marex@denx.de>
Hector Martin [Sun, 29 Oct 2023 06:37:43 +0000 (15:37 +0900)]
usb: xhci: Do not panic on event timeouts
Now that we always check the return value, just return NULL on timeouts.
We can still log the error since this is a problem, but it's not reason
to panic.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Marek Vasut <marex@denx.de>
Hector Martin [Sun, 29 Oct 2023 06:37:41 +0000 (15:37 +0900)]
usb: xhci: Recover from halted bulk endpoints
There is currently no codepath to recover from this case. In principle
we could require that the upper layer do this explicitly, but let's just
do it in xHCI when the next bulk transfer is started, since that
reasonably implies whatever caused the problem has been dealt with.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Marek Vasut <marex@denx.de>
Hector Martin [Sun, 29 Oct 2023 06:37:40 +0000 (15:37 +0900)]
usb: xhci: Allow context state errors when halting an endpoint
There is a race where an endpoint may halt by itself while we are trying
to halt it, which results in a context state error. See xHCI 4.6.9 which
mentions this case.
This also avoids BUGging when we attempt to stop an endpoint which was
already stopped to begin with, which is probably a bug elsewhere but
not a good reason to crash.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Marek Vasut <marex@denx.de>
Hector Martin [Sun, 29 Oct 2023 06:37:39 +0000 (15:37 +0900)]
usb: xhci: Better error handling in abort_td()
If the xHC has a problem with our STOP ENDPOINT command, it is likely to
return a completion directly instead of first a transfer event for the
in-progress transfer. Handle that more gracefully.
We still BUG() on the error code, but at least we don't end up timing
out on the event and ending up with unexpected event errors.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Marek Vasut <marex@denx.de>
Hector Martin [Sun, 29 Oct 2023 06:37:38 +0000 (15:37 +0900)]
usb: xhci: Guard all calls to xhci_wait_for_event
xhci_wait_for_event returns NULL on timeout, so the caller always has to
check for that. This addresses immediate explosions in this part
of the code when timeouts happen, but not the root cause for the
timeout.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Marek Vasut <marex@denx.de>
Sam Protsenko [Thu, 9 Nov 2023 20:13:13 +0000 (14:13 -0600)]
configs: Remove unneeded SYS_CONFIG_NAME from a*y17lte defconfigs
As correct default SYS_CONFIG_NAME value is now set in
board/samsung/axy17lte/Kconfig (in commit "board: samsung: Fix
SYS_CONFIG_NAME configs in axy17lte Kconfig"), the SYS_CONFIG_NAME
option can be safely removed from all a*y17lte defconfigs. That removal
doesn't change resulting .config files.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Thu, 9 Nov 2023 20:13:12 +0000 (14:13 -0600)]
board: samsung: Fix SYS_CONFIG_NAME configs in axy17lte Kconfig
There is a couple of issues related to SYS_CONFIG_NAME config in
axy17lte Kconfig.
1. The global SYS_CONFIG_NAME in axy17lte Kconfig overrides
SYS_CONFIG_NAME for all boards specified after this line in
arch/arm/mach-exynos/Kconfig:
source "board/samsung/axy17lte/Kconfig"
Right now it's the last 'source' line there, so the issue is not
reproducible. But once some board is moved or added after this line
the next build error will happen:
GEN include/autoconf.mk.dep
In file included from ./include/common.h:16:
include/config.h:3:10: fatal error: configs/exynos78x0-common.h.h:
No such file or directory
3 | #include <configs/exynos78x0-common.h.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
That's happening because axy17lte Kconfig defines SYS_CONFIG_NAME
option in global namespace (not guarded with any "if TARGET_..."), so
it basically rewrites the correct SYS_CONFIG_NAME defined in the
hypothetical boards which might appear after axy17lte in mach-exynos
Kconfig.
2. Another side of the issue is that SYS_CONFIG_NAME is defined
incorrectly in axy17lte Kconfig:
The .h extension should not have been specified there. It's leading
to a build error, as the generated include file has a double '.h'
extension.
3. Each target in axy17lte/Kconfig defines its own SYS_CONFIG_NAME. But
all of those in fact incorrect, as corresponding
include/configs/<CONFIG_SYS_CONFIG_NAME>.h header files don't exist.
4. The global SYS_CONFIG_NAME pretty much repeats the help description
from arch/Kconfig and doc/README.kconfig.
Corresponding defconfig files (a*y17lte_defconfig) fix above issues by
overriding SYS_CONFIG_NAME and correctly setting it to
"exynos78x0-common".
Fix all mentioned issues by removing the incorrect global
SYS_CONFIG_NAME and instead specifying it (correctly) in SYS_CONFIG_NAME
options for each target instead.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Fixes: 3e2095e960b4 ("board: samsung: add support for Galaxy A series of 2017 (a5y17lte)") Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Tue, 7 Nov 2023 20:13:49 +0000 (14:13 -0600)]
serial: s5p: Use dev_read_addr_ptr() to get base address
As the address read from device tree is being cast to a pointer, it's
better to use dev_read_addr_ptr() API for getting that address. The more
detailed explanation can be found in commit a12a73b66476 ("drivers: use
dev_read_addr_ptr when cast to pointer").
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Tue, 7 Nov 2023 19:06:01 +0000 (13:06 -0600)]
serial: s5p: Improve coding style
Just some minor style fixes. No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Tue, 7 Nov 2023 19:06:00 +0000 (13:06 -0600)]
serial: s5p: Use named constants for register values
Get rid of magic numbers in s5p_serial_init() when writing to UART
registers. While at it, use BIT() macro for existing constants when
appropriate.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Tue, 7 Nov 2023 19:05:59 +0000 (13:05 -0600)]
serial: s5p: Use livetree API to get "id" property
Use dev_read_u8_default() instead of fdtdec_get_int() to read the "id"
property from device tree, as suggested in [1]. dev_* API is already
used in this driver, so there is no reason to stick to fdtdec_* API.
This also fixes checkpatch warning:
WARNING: Use the livetree API (dev_read_...)
[1] doc/develop/driver-model/livetree.rst
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Tue, 7 Nov 2023 19:05:58 +0000 (13:05 -0600)]
serial: s5p: Remove common.h inclusion
It's not really needed here anymore. Remove it, as common.h is going
away at some point.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Simon Holesch [Mon, 20 Nov 2023 00:08:34 +0000 (01:08 +0100)]
usb: ci: Fix gadget reinit
The ChipIdea device controller wasn't properly cleaned up when disabled.
So enabling it again left it in a broken state. The problem occurred for
example when the host unbinds the driver and binds it again.
During the first setup, when the out request is queued, the endpoint is
primed (`epprime`). If the endpoint is then disabled, it stayed primed
with the initial buffer. So after the endpoint is re-enabled, the device
controller and device driver were out of sync: the new out request was
in the driver queue head, yet not submitted, but the "complete" function
was still called, since the endpoint was primed with the old buffer.
With the fastboot function this error led to the (rather confusing)
error message "buffer overflow".
Fixed by clearing the primed buffers with the `epflush` (`ENDPTFLUSH`)
register.
Signed-off-by: Simon Holesch <simon@holesch.de> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/20231120002024.32865-1-simon@holesch.de Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
efi_loader: Increase default variable store size to 128K
In commit 9fd3f881c6ed ("efi_loader: Increase default variable store size to 64KiB")
Alper has a detailed explanation of why the size needs to be bumped to at
least 64K. However enabling Secure boot, writing db, KEK, PK etc keys
will further increase the size so bump it to 128K.
It's worth noting that when U-Boot stores the EFI variables in an RPMB the
available storage is defined statically in StandAloneMM at build time.
The U-Boot code is detecting the available true size on the fly during
writes. When StandAloneMM is present this size defines the reserved
memory U-Boot can use to copy any runtime variables, before booting an
OS.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Jonathan Corbet [Wed, 4 Jan 2023 17:47:39 +0000 (10:47 -0700)]
docs: Fix the docs build with Sphinx 6.0
Sphinx 6.0 removed the execfile_() function, which we use as part of the
configuration process. They *did* warn us... Just open-code the
functionality as is done in Sphinx itself.
Tested (using SPHINX_CONF, since this code is only executed with an
alternative config file) on various Sphinx versions from 2.5 through 6.0.
Reported-by: Martin Liška <mliska@suse.cz> Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Rebased for U-Boot Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
When running 'mkimage -l' is called for a valid StarFive file an error
message "Error: invalid marker bytes" is written by the Renesas SPKG
driver.
mkimage -l may be invoked without specifying an image type. In this case
mkimage iterates over all image type drivers to find the one that matches.
None of the non-matching drivers should write an error message.
Fix the Renesas SPKG driver.
Fixes: afdfcb11f97c ("tools: spkgimage: add Renesas SPKG format") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
scsi: set dma direction to NONE for TEST UNIT READY
SCSI device scan code was executing TEST UNIT READY command without
explicitly setting dma direction in struct scsi_cmd to NONE, so command
was passed to driver with dma direction set to DMA_FROM_DEVICE,
inherited from older usage.
With WDC SDINDDH6-64G ufs device, that caused TEST UNIT READY to
return error.
Fix that, by explicitly setting dma direction to NONE for
TEST UNIT READY, and restoring it back DMA_FROM_DEVICE for the
following READ CAPACITY.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Reviewed-by: Marek Vasut <marex@denx.de>
Chris Packham [Fri, 27 Oct 2023 00:23:54 +0000 (13:23 +1300)]
Revert "arm64: Use FEAT_HAFDBS to track dirty pages when available"
This reverts commit 6cdf6b7a340db4ddd008516181de7e08e3f8c213. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Chris Packham [Fri, 27 Oct 2023 00:23:53 +0000 (13:23 +1300)]
Revert "arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present"
This reverts commit 836b8d4b205d2175b57cb9ef271e638b0c116e89. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Chris Packham [Fri, 27 Oct 2023 00:23:52 +0000 (13:23 +1300)]
Revert "armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present"
This reverts commit c1da6fdb5c239b432440721772d993e63cfdeb20. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Marcel Ziswiler [Thu, 26 Oct 2023 07:32:20 +0000 (09:32 +0200)]
imx: spl_imx_romapi: fix emmc fast boot mode case
This fixes a regression in the eMMC fast boot mode case where the buffer
was missing 464 bytes.
The code figures out how many bytes must at least be fetched to honor
the current read, rounds that up to the ss->pagesize [which is a no-op
in the USB download case because that has ->pagesize==1], fetches that
many bytes, but then recorded the original upper bound as the new end of
the valid data. However, this did not take into account the rounding up
to the ss->pagesize. Fix this by recording the actual bytes downloaded.
Fixes: 4b4472438f5a ("imx: spl_imx_romapi: avoid tricky use of spl_load_simple_fit() to get full FIT size") Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Fabio Estevam <festevam@gmail.com>
John Keeping [Tue, 14 Nov 2023 11:30:17 +0000 (11:30 +0000)]
spl: fix TPL_SYS_MALLOC_F description
This config option enables the malloc() pool in TPL not the SPL. Fix
the description to accurately reflect this.
Fixes: fd8497dae54 (spl: Create proper symbols for enabling the malloc() pool) Signed-off-by: John Keeping <jkeeping@inmusicbrands.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Andre Przywara [Tue, 7 Nov 2023 16:09:00 +0000 (16:09 +0000)]
virtio: rng: gracefully handle 0 byte returns
According to the virtio v1.x "entropy device" specification, a virtio-rng
device is supposed to always return at least one byte of entropy.
However the virtio v0.9 spec does not mention such a requirement.
The Arm Fixed Virtual Platform (FVP) implementation of virtio-rng always
returns 8 bytes less of entropy than requested. If 8 bytes or less are
requested, it will return 0 bytes.
This behaviour makes U-Boot's virtio_rng_read() implementation go into an
endless loop, hanging the system.
Work around this problem by always requesting 8 bytes more than needed,
but only if a previous call to virtqueue_get_buf() returned 0 bytes.
This should never trigger on a v1.x spec compliant implementation, but
fixes the hang on the Arm FVP.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reported-by: Peter Hoyes <peter.hoyes@arm.com>
Simon Glass [Thu, 16 Nov 2023 01:35:23 +0000 (18:35 -0700)]
bootstd: Avoid freeing a non-allocated buffer
EFI applications can be very large and thus used to cause boot failures
when malloc() space was exhausted.
A recent changed fixed this by using the kernel_addr_r environment var
as the address of the buffer. However, it still frees the buffer when
the bootflow is discarded.
Fix this by introducing a flag to indicate whether the buffer was
allocated, or not.
Note that kernel_addr_r is not the last word here. It might be better
to use lmb to place images. But there is a lot of refactoring to do
before we can remove the environment variables. The distro scripts rely
on them so it is safe for bootstd to do so too.
Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file Signed-off-by: Simon Glass <sjg@chromium.org>
Reported by: Simon Glass <sjg@chromium.org>
Reported by: Shantur Rathore <i@shantur.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Shantur Rathore <i@shantur.com>
Simon Glass [Tue, 7 Nov 2023 09:17:40 +0000 (10:17 +0100)]
bootstage: Correct exhasuted typo
Correct this typo in the warning message shown when no more bootstage
records can be added.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Sat, 4 Nov 2023 19:57:33 +0000 (15:57 -0400)]
sandbox: Close file after mmaping it
After opening pathname, we must close ifd once we are done with it.
Fixes: b9274095c2c ("sandbox: Add a way to map a file into memory") Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
CONFIG_DM_WARN has a text indicating that these messages should only
provided when debugging. This implies that the setting must be default no.
We should still create debug messages.
Reported-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Sat, 4 Nov 2023 16:25:24 +0000 (10:25 -0600)]
patman: Correct Python 3.6 behaviour
The importlib_resources import is not actually used. Fix this so that
patman can run on Python 3.6 to some extent, once
'pip3 install importlib-resources' has been run.
Simon Glass [Mon, 2 Oct 2023 01:14:37 +0000 (19:14 -0600)]
bootstd: Refactor mmc prep to allow a different scan
Adjust scan_mmc4_bootdev() and related function so that the caller can
do its own 'bootflow scan' command. This allows it to change the flags
if needed.
Simon Glass [Mon, 2 Oct 2023 01:14:36 +0000 (19:14 -0600)]
efi: Correct handling of frame buffer
The efi_gop driver uses private fields from the video uclass to obtain a
pointer to the frame buffer. Use the platform data instead.
Check the VIDEO_COPY setting to determine which frame buffer to use. Once
the next stage is running (and making use of U-Boot's EFI boot services)
U-Boot does not handle copying from priv->fb to the hardware framebuffer,
so we must allow EFI to write directly to the hardware framebuffer.
We could provide a function to read this, but it seems better to just
document how it works. The original change ignored an explicit comment
in the video.h file ("Things that are private to the uclass: don't use
these in the driver") which is why this was missed when the VIDEO_COPY
feature was added.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 8f661a5b662 ("efi_loader: gop: Expose fb when 32bpp") Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Sam Protsenko [Tue, 7 Nov 2023 21:22:00 +0000 (15:22 -0600)]
clk: exynos: Add header guard for clk-pll.h
The clk-pll.h is going to be included in multiple files soon. Add
missing header guard to prevent possible build errors in future.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Fixes: 166097e87753 ("clk: exynos: add clock driver for Exynos7420 Soc") Reviewed-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
clk_get_by_index() returns negative number on error. Assigning it to
unsigned int makes the subsequent "ret < 0" check always false, leading
in turn to possible unhandled errors. Change 'ret' variable type to
signed int so the code checks and handles clk_get_by_index() return code
properly.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Fixes: cf75cdf96ef2 ("serial: s5p: use clock api to get clock rate") Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Mon, 30 Oct 2023 16:55:02 +0000 (11:55 -0500)]
exynos: Avoid duplicate reset_cpu with SYSRESET enabled
The sysreset uclass unconditionally provides a definition of the
reset_cpu() function. So does the exynos soc code. Fix the build with
SYSRESET enabled by omitting the function from the soc code in that
case. The code still needs to be kept around for use in SPL.
This commit was inspired by commit 6e19dc84c14b ("sunxi: Avoid duplicate
reset_cpu with SYSRESET enabled").
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Fri, 20 Oct 2023 21:46:33 +0000 (16:46 -0500)]
watchdog: s5p_wdt: Include missing CPU header
s5p watchdog driver calls samsung_get_base_watchdog() function, but its
prototype is not included. That might lead to build warnings like this:
drivers/watchdog/s5p_wdt.c: In function 'wdt_stop':
drivers/watchdog/s5p_wdt.c:16:26:
warning: implicit declaration of function
'samsung_get_base_watchdog' [-Wimplicit-function-declaration]
16 | (struct s5p_watchdog *)samsung_get_base_watchdog();
| ^~~~~~~~~~~~~~~~~~~~~~~~~
Include asm/arch/cpu.h to fix that issue.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Fri, 20 Oct 2023 21:46:32 +0000 (16:46 -0500)]
arm: exynos: Include missing CPU header in gpio.h
arch/arm/include/asm/arch/gpio.h relies on definitions from cpu.h.
Include it explicitly in gpio.h. Otherwise next build error may occur:
In file included from ./arch/arm/include/asm/gpio.h:7,
from include/cros_ec.h:14,
from board/samsung/common/board.c:8:
./arch/arm/include/asm/arch/gpio.h:1357:4:
error: 'EXYNOS4_GPIO_PART1_BASE' undeclared here
(not in a function); did you mean 'EXYNOS4_GPIO_MAX_PORT'?
1357 | { EXYNOS4_GPIO_PART1_BASE, EXYNOS4_GPIO_MAX_PORT_PART_1 },
| ^~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Marek Vasut [Sun, 5 Nov 2023 22:42:45 +0000 (23:42 +0100)]
mmc: renesas-sdhi: Disable clock after tuning reset when possible
Currently the renesas_sdhi_reset_tuning() unconditionally leaves SDHI
clock enabled after the tuning reset. This is not always necessary.
After the driver performed tuning reset at the end of probe function,
or in the unlikely case that tuning failed during regular operation,
the SDHI clock can be disabled after the tuning reset. The following
set_ios call would reconfigure the clock as needed.
In case of regular set_ios call which requires a tuning reset, keep
the clock enabled or disabled according to the mmc->clk_disable state.
With this in place, the controllers which have not been accessed via
block subsystem after boot are left in quiescent state. However, if an
MMC device is used e.g. for environment storage, that controller would
be accessed during the environment load and left active, including its
clock which would still be generated. This is due to the design of the
MMC subsystem, which does not deinit a controller after it was started
once, the controller is only deinited in case of mmc rescan, or before
OS boot.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com> Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Thuan Nguyen Hong <thuan.nguyen-hong@banvien.com.vn>
Tom Rini [Sun, 12 Nov 2023 21:36:22 +0000 (16:36 -0500)]
Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi
To quote Andre:
The first few patches are some easy refactorings and fixes, most of them
actually don't change the generated binaries at all. Then there is a
defconfig for a new board, for which we just gained the .dts file from
the last kernel DT sync.
On top there is support for a new PMIC (AXP313), and LPDDR4 support for
the Allwinner H616 SoC, both of which are needed to support new devices
that appeared lately, especially cheap TV boxes.
While those are technically new features, they don't affect existing
boards, for instance the LPDDR4 support code is guarded by a new DRAM
type Kconfig variable. So the risk for regressions is very slim.
Gitlab CI passed, and I booted that briefly on some boards, including an
H616 and an H618 one (with LPDDR4).
The H616 SoC family has support for several types of DRAM: DDR3,
LPDDR3, DDR4 and LPDDR4.
At the moment, the driver only supports DDR3 and LPDDR3 memory.
Let's extend the driver to support the LPDDR4 memory. This type
of memory widely used in device with T507(-H) SoC and new orangepi
zero3 with H618.
The compatibility with T507 is not yet complete, because there
is difference in the phy_init array.
The LPDDR4-2133 timings correspond to DRAM Rayson RS1G32LO4D2BDS-53BT
found on the NOR SPI from the Orangepi Zero 3 4GB.
Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com> Tested-by: Piotr Oniszczuk <piotr.oniszczuk@gmail.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Andre Przywara <andre.przywara@arm.com>
The original H616 DDR3 ODT configuration code wrote board specific values
into a sequence of paired registers.
For LPDDR3 support we needed to special-case one group of registers,
because for that DRAM type we need to write 0 into the lower register of
each pair. That already made the code less readable.
LPDDR4 support will make things even messier, so let's refactor that
code now: We allow to write different values into the lower and upper
half of each pair. The masking is moved into a macro, and use in each
write statement.
The effect is not as obvious yet, as we don't need the full flexibility at
the moment, but the motivation will become clearer with LPDDR4 support.
Andre Przywara [Sun, 30 Jul 2023 00:11:01 +0000 (01:11 +0100)]
power: pmic: sunxi: add AXP313 SPL driver
On boards using the AXP313 PMIC, the DRAM rail is often not setup
correctly at reset time, so we have to program the PMIC very early in
the SPL, before running the DRAM initialisation.
Add a simple AXP313 PMIC driver that knows about DCDC2(CPU) and
DCDC3(DRAM), so that we can bump up the voltage before the DRAM init.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Samuel Holland [Tue, 31 Oct 2023 04:57:40 +0000 (23:57 -0500)]
pinctrl: sunxi: Avoid using .bss for SPL
sunxi platforms put .bss in DRAM, so .bss is not available in SPL before
DRAM controller initialization. Therefore, this buffer must be placed in
the .data section.
Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Samuel Holland [Tue, 31 Oct 2023 05:22:35 +0000 (00:22 -0500)]
sunxi: mmc: Move header to the driver directory
The MMC controller driver is (and ought to be) the only user of these
register definitions. Put them in a header next to the driver to remove
the dependency on a specific ARM platform's headers.
Due to the sunxi_mmc_init() prototype, the file was not renamed. None of
the register definitions were changed.
Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Tom Rini [Mon, 17 Jul 2023 19:29:20 +0000 (15:29 -0400)]
arm: sunxi: Correct warning in board_fit_config_name_match
When building this with clang, we get a warning about having excess
parenthesis here, or that we're incorrectly using "==" when we want "=".
Correct these by using the common size macro.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
[Andre: Use SZ_512M as per Simon's suggestion] Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Sun, 27 Jun 2021 00:13:09 +0000 (01:13 +0100)]
sunxi: board: simplify early PMIC setup conditions
So far we have a convoluted #ifdef mesh that guards the early AXP PMIC
setup in board.c. That combination of &&, || and negations is very hard
to read, maintain and especially to extend.
Fortunately we have those same conditions already modelled in the
Kconfig file, so they are actually redundant. On top of that the real
reason we have those preprocessor guards in the first place is about the
symbols that are *conditionally* defined: without #ifdefs the build
would break because of them being undefined for many boards.
To simplify this, just change the guards to actually look at the symbols
needed, so CONFIG_AXP_xxx_VOLT instead of CONFIG_AXPyyy_POWER.
This drastically improves the readability of this code, and makes adding
PMIC support a pure Kconfig matter.
Doing this revealed one bug in Kconfig: there is no axp_set_dcdc4() for
the AXP818, even though CONFIG_AXP_DCDC4_VOLT includes that PMIC.
Since the AXP818 wasn't included when calling axp_set_dcdc4() in board.c,
this wasn't an issue, but becomes one now, so also remove the AXP818 from
the DCDC4 Kconfig symbol.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Milan P. Stanić [Sat, 4 Nov 2023 14:38:15 +0000 (15:38 +0100)]
doc: build: fix wrongly written targests instead of targets
Signed-off-by: Milan P. Stanić <mps@arvanta.net> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>