Synchronize R8A774E1 RZ/G2H clock tables with Linux 6.5.3,
commit 238589d0f7b421aae18c5704dc931595019fa6c7 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Synchronize R8A774C0 RZ/G2E clock tables with Linux 6.5.3,
commit 238589d0f7b421aae18c5704dc931595019fa6c7 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Synchronize R8A774B1 RZ/G2N clock tables with Linux 6.5.3,
commit 238589d0f7b421aae18c5704dc931595019fa6c7 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Synchronize R8A774A1 RZ/G2M clock tables with Linux 6.5.3,
commit 238589d0f7b421aae18c5704dc931595019fa6c7 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Synchronize R-Car R8A779G0 V4H clock tables with Linux 6.5.3,
commit 238589d0f7b421aae18c5704dc931595019fa6c7 .
The PLL2_VAR is not implemented yet and PLL2 is still configured
as regular PLL2 only.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Synchronize R-Car R8A77960 M3-W and R8A77961 M3-W+ clock tables with Linux 6.5.3,
commit 238589d0f7b421aae18c5704dc931595019fa6c7 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Synchronize R-Car R8A7791 M2-W and R8A7793 M2-N clock tables with Linux 6.5.3,
commit 238589d0f7b421aae18c5704dc931595019fa6c7 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Synchronize R-Car R8A77960 M3-W and R8A77961 M3-W+ PFC tables with Linux 6.5.3,
commit 238589d0f7b421aae18c5704dc931595019fa6c7 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Synchronize R-Car R8A7791 M2-W and R8A7793 M2-N PFC tables with Linux 6.5.3,
commit 238589d0f7b421aae18c5704dc931595019fa6c7 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Currently, the Renesas pin control driver supports pins that can switch
their I/O voltage levels between either 1.8V and 3.3V, or between 2.5V
and 3.3V. However, some SoCs have pins that can switch between 1.8V and
2.5V.
Add support for this by replacing the separate SH_PFC_PIN_CFG_IO_VOLTAGE
capability and voltage level flags by a 2-bit field, to cover three
possible I/O voltage switching options.
Ported from Linux kernel commit by Geert Uytterhoeven:
b88e733ac517 ("pinctrl: renesas: Add support for 1.8V/2.5V I/O voltage levels")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Rename pfc-r7s72100.c to pfc-rza1.c to match the file name with Linux.
Rename the Kconfig symbol to match.
No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Rename pfc-r8a7795.c to pfc-r8a77951.c to match the file name with Linux
and to indicate the PFC driver does not support R8A77950 H3 ES1.* .
No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Arrays are not cleared entirely because ARRAY_SIZE
returns the number of elements in an array, not the size
in bytes.
This commit fixes the calls to memset by providing the
array size in bytes instead of the number of elements
in the array.
Signed-off-by: Francois Berder <fberder@outlook.fr>
Adapt behaviour to Linux kernel driver.
The return value of gpio_request_by_name_nodev() was not checked before,
and thus in case 'rb-gpios' was missing in DT, rb.type was set to
ATMEL_NAND_GPIO_RB nevertheless, leading to output like this for
example (on sam9x60-curiosity with the line removed from dts):
NAND: Could not find valid ONFI parameter page; aborting
device found, Manufacturer ID: 0xc2, Chip ID: 0xdc
Macronix NAND 512MiB 3,3V 8-bit
512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 64
atmel-nand-controller nand-controller: NAND scan failed: -22
Failed to probe nand driver (err = -22)
Failed to initialize NAND controller. (error -22)
0 MiB
Note: not having that gpio assigned in dts is possible, the driver does
not override nand_chip->dev_ready() then and a generic solution is used.
Fixes: 6a8dfd57220d ("nand: atmel: Add DM based NAND driver")
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Reviewed-by: Eugen Hristev <eugen.hristev@collabora.com>
Acked-by: Michael Trimarchi <michael@amarulasolutions.com>
dm tree enhancement
adjust meaning of bootph-pre-ram/sram
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmUPQXURHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreY1TAf+LeDzKKMhJmyo5ImQWlKPdFt9UGlWqthL
PBngUWV7GdQ5Kn+dLmKmySAmnQC4XNid565nJt8okmMfpHYUBhOnrnJmrXTZdDPJ
lYrpEAR7fTyTTTwjSVFcIXJ56bIT07AUX6jQATh383+Plm0U15tRBMguNsrTy1wL
EmJBVdeT0BZkpSkJyqAIkVuwjOYP+KSuVCectL5LRIpKtjOA+HmMGmELUirjuL00
uN2h/uucuSGFnjCmKW4l9sYrxxYgd/zN2Y8SOJwBebKyHxSgyvNdbjZxeG5o3gSS
ruUSEx4DHYVIRHeDBAnwB4wLdCOqfC2dy0ACReTg0Li+iSQN9qYtEg==
=Sl3P
-----END PGP SIGNATURE-----
Merge tag 'dm-next-23sep23' of https://source.denx.de/u-boot/custodians/u-boot-dm into next
buildman file-keeping and build-progress improvements
dm tree enhancement
adjust meaning of bootph-pre-ram/sram
This old patch was marked as deferred. Bring it back to life, to continue
towards the removal of common.h
Move this out of the common header and include it only where needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
The output from "dm tree" or "dm uclass" is a bit annoying
if the number of devices available on the system is huge.
(This is especially true on sandbox when I debug some DM code.)
With this patch, we can specify the uclass name or the device
name that we are interested in in order to limit the output.
For instance,
=> dm uclass usb
uclass 121: usb
0 usb@1 @ 0bcff8b0, seq 1
uclass 124: usb
=> dm tree usb:usb@1
Class Index Probed Driver Name
-----------------------------------------------------------
usb 0 [ ] usb_sandbox usb@1
usb_hub 0 [ ] usb_hub `-- hub
usb_emul 0 [ ] usb_sandbox_hub `-- hub-emul
usb_emul 1 [ ] usb_sandbox_flash |-- flash-stick@0
usb_emul 2 [ ] usb_sandbox_flash |-- flash-stick@1
usb_emul 3 [ ] usb_sandbox_flash |-- flash-stick@2
usb_emul 4 [ ] usb_sandbox_keyb `-- keyb@3
If you want forward-matching against a uclass or udevice name,
you can specify "-e" option.
=> dm uclass -e usb
uclass 15: usb_emul
0 hub-emul @ 0bcffb00, seq 0
1 flash-stick@0 @ 0bcffc30, seq 1
2 flash-stick@1 @ 0bcffdc0, seq 2
3 flash-stick@2 @ 0bcfff50, seq 3
4 keyb@3 @ 0bd000e0, seq 4
uclass 64: usb_mass_storage
uclass 121: usb
0 usb@1 @ 0bcff8b0, seq 1
uclass 122: usb_dev_generic
uclass 123: usb_hub
0 hub @ 0bcff9b0, seq 0
uclass 124: usb
=> dm tree -e usb
Class Index Probed Driver Name
-----------------------------------------------------------
usb 0 [ ] usb_sandbox usb@1
usb_hub 0 [ ] usb_hub `-- hub
usb_emul 0 [ ] usb_sandbox_hub `-- hub-emul
usb_emul 1 [ ] usb_sandbox_flash |-- flash-stick@0
usb_emul 2 [ ] usb_sandbox_flash |-- flash-stick@1
usb_emul 3 [ ] usb_sandbox_flash |-- flash-stick@2
usb_emul 4 [ ] usb_sandbox_keyb `-- keyb@3
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Nodes with bootph-pre-sram/ram props are bound in multiple phases:
1. At TPL (bootph-pre-sram) or SPL (bootph-pre-ram) phase
2. At U-Boot proper pre-relocation phase
3. At U-Boot proper normal phase
However the binding and U-Boot Driver Model documentation indicate that
only nodes marked with bootph-all or bootph-some-ram should be bound in
the U-Boot proper pre-relocation phase.
Change ofnode_pre_reloc to report a node with bootph-pre-ram/sram prop
with a pre-reloc status only after U-Boot proper pre-relocation phase.
Also update the ofnode_pre_reloc documentation to closer reflect the
binding and driver model documentation.
This changes behavior of what nodes are bound in the U-Boot proper
pre-relocation phase. Change to bootph-all or add bootph-some-ram prop
to restore prior behavior.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Simon Glass <sjg@chromium.org>
Errors were handled only if an I2C transfer timed out
and received a NACK which is very unlikely. This commit
changes the condition such that errors are handled if
an I2C transfer times out or received a NACK.
Signed-off-by: Francois Berder <fberder@outlook.fr>
Reviewed-by: Heiko Schocher <hs@denx.de>
The NETSEC GMAC occasionally falls into a weird state where
MAC_REG_DESC_SOFT_RST has never been cleared and shows errors like the
below when networking commands are issued:
=> ping 192.168.1.1
ethernet@522d0000 Waiting for PHY auto negotiation to complete... done
netsec_wait_while_busy: timeout
Using ethernet@522d0000 device
ARP Retry count exceeded; starting again
ping failed; host 192.168.1.1 is not alive
It happens on not only 'ping' but also 'dhcp', 'tftp' and so on.
Luckily, restarting the NETSEC GMAC and trying again seems to fix the
problematic state. So first ensure that we haven't entered the state by
checking MAC_REG_DESC_SOFT_RST to be cleared; otherwise, restarting
NETSEC/PHY and trying again would work as a workaround.
Signed-off-by: Ryosuke Saito <ryosuke.saito@linaro.org>
Tested-by: Masahisa Kojima <masahisa.kojima@linaro.org>
When 'usb stop' is run, doing 'bootflow scan' does not run the USB hunter
again so does not see any devices. Fix this by telling bootstd about the
state of USB.
Signed-off-by: Simon Glass <sjg@chromium.org>
At least on modern machines the write-back mechanism for the frame buffer
is quite slow when scrolling, since it must read the entire frame buffer
and write it back.
Enable the VIDEO_COPY feature to resolve this problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
If coreboot does not set up sysinfo for the UART, SPL currently hangs.
Use the DBG2 technique there as well. This allows coreboot64 to boot from
coreboot even if the console info is missing from sysinfo
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This driver is not actually built since a Kconfig was never created for
it.
Add a Kconfig (which is already implied by COREBOOT) and update the
implementation to avoid using unnecessary memory. Drop the #ifdef at the
top since we can rely on Kconfig to get that right.
To enable it (in addition to serial and video), use:
setenv stdout serial,vidconsole,cbmem
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[Modified the comment about overflow a little bit]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Cache related issues are seen with small sized data reads.
Due to this, proper data is not read. Also some times sf probe
fails randomly. To workaround this issue, invalidate dcache after read DMA
is triggered.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230915031759.28889-3-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Before DMA read, ideally cache should be invalidated, so that data from
memory will be updated to cache after DMA is completed. But
flush_dcache_range is being used which is incorrect. Change
flush_dcache_range to invalidate_dcache_range.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230915031759.28889-2-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
