This target is used for Allwinner's sun20i series of RISC-V SoCs,
starting with the Allwinner D1 and D1s.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Implement the .get_function operation, so the gpio command can report
the current function. Since the GPIOF_FUNC (versus GPIOF_UNUSED) mux
values vary among the PMICs, report all non-GPIO mux values as UNKNOWN.
Signed-off-by: Samuel Holland <samuel@sholland.org>
There are three major variants of the AXP PMIC GPIO functionality (plus
PMICs with no GPIOs at all). Except for GPIO3 on the AXP209, which uses
a different register layout, it is straightforward to support all three
variants with a single driver. Do this, and in the process remove the
GPIO-related definitions from the PMIC-specific headers, and therefore
the dependency on AXP_PMIC_BUS.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that the PMIC driver implements the DM_PMIC uclass, those functions
can be used instead of the platform-specific "pmic_bus" functions.
Since the driver still uses the single set of register definitions from
axpXXX.h (as selected by AXPxxx_POWER), it still depends on one of those
choices, and therefore also AXP_PMIC_BUS.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that the PMIC has a DM driver and binds device tree subnodes, the
GPIO device can be bound that way, instead of from inside board code.
Since the driver still uses the single set of register definitions from
axpXXX.h (as selected by AXPxxx_POWER), it does not differentiate among
the supported compatibles.
Signed-off-by: Samuel Holland <samuel@sholland.org>
This is less confusing than half of the driver using "axp_gpio" and the
other half using "gpio_axp".
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that the sunxi_gpio driver handles pull-up/down via the driver
model, we can switch to DM_GPIO for these pins with no loss in
functionality. Since the driver now gets its pin configuration from
the device tree, we can remove the Kconfig symbols.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that this functionality is modeled using the device tree and
regulator uclass, the named GPIO is not referenced anywhere. Remove
it, along with the rest of the support for AXP virtual GPIOs.
Series-to: Andre Przywara <andre.przywara@arm.com>
Series-to: Jagan Teki <jagan@amarulasolutions.com>
Series-cc: Chen-Yu Tsai <wens@csie.org>
Series-cc: Hans de Goede <hdegoede@redhat.com>
Series-cc: Icenowy Zheng <icenowy@aosc.xyz>
Series-cc: Maxime Ripard <mripard@kernel.org>
Series-cc: Adam Sampson <ats@offog.org>
Series-cc: Stefan Roese <sr@denx.de>
Series-cc: u-boot@lists.denx.de
Cover-letter:
sunxi: Control USB VBUS supplies via DT regulators
This series converts sunxi boards from controlling VBUS suppllies using
GPIO name strings in Kconfig to using regulator devices probed via the
devicetree. ARCH_SUNXI already implies DM_REGULATOR_FIXED, so the only
new driver needed is for the AXP PMIC drivevbus regulator. This is part
2 of 3 for removing the PHY driver's GPIO Kconfig options. Part 1 was
here[1]. Part 3 will finish converting the VBUS/ID detection GPIOs; it
requires adding some missing DT properties to a couple of boards, so it
will have to wait for at least the next DT sync from Linux.
I tried to verify (by inspection) every board affected by this change,
but there is some possibility that this could break some boards. See the
commit message for patch 3. I have CCed some relevant board maintaners;
please test this patch series if you have the opportunity.
[1]: https://lore.kernel.org/u-boot/20230122234623.1636-1-samuel@sholland.org/
END
Signed-off-by: Samuel Holland <samuel@sholland.org>
The device tree binding for the PHY provides VBUS supplies as regulator
references. Now that all boards have the appropriate regulator uclass
drivers enabled, the PHY driver can switch to using them. This replaces
direct GPIO usage, which in some cases needed a special DM-incompatible
"virtual" GPIO from the PMIC.
The following boards provided a value for CONFIG_USB0_VBUS_PIN, but are
missing the "usb0_vbus-supply" property in their device tree. None of
them have the MUSB controller enabled in host or OTG mode, so they
should see no impact:
- Ainol_AW1_defconfig / sun7i-a20-ainol-aw1
- Ampe_A76_defconfig / sun5i-a13-ampe-a76
- CHIP_pro_defconfig / sun5i-gr8-chip-pro
- Cubieboard4_defconfig / sun9i-a80-cubieboard4
- Merrii_A80_Optimus_defconfig / sun9i-a80-optimus
- Sunchip_CX-A99_defconfig / sun9i-a80-cx-a99
- Yones_Toptech_BD1078_defconfig / sun7i-a20-yones-toptech-bd1078
- Yones_Toptech_BS1078_V2_defconfig /
sun6i-a31s-yones-toptech-bs1078-v2
- iNet_3F_defconfig / sun4i-a10-inet-3f
- iNet_3W_defconfig / sun4i-a10-inet-3w
- iNet_86VS_defconfig / sun5i-a13-inet-86vs
- iNet_D978_rev2_defconfig / sun8i-a33-inet-d978-rev2
- icnova-a20-swac_defconfig / sun7i-a20-icnova-swac
- sun8i_a23_evb_defconfig / sun8i-a23-evb
Similarly, the following boards set CONFIG_USB1_VBUS_PIN, but do not
have "usb1_vbus-supply" in their device tree. Neither of them have USB
enabled at all, so again there should be no impact:
- Cubieboard4_defconfig / sun9i-a80-cubieboard4 (also for USB3)
- sun8i_a23_evb_defconfig / sun8i-a23-evb
The following boards use a different pin for USB1 VBUS between their
defconfig and their device tree. Depending on which is correct, they
may be broken:
- Linksprite_pcDuino3_Nano_defconfig (PH11) /
sun7i-a20-pcduino3-nano (PD2)
- icnova-a20-swac_defconfig (PG10) / sun7i-a20-icnova-swac (PH6)
Finally, this board has conflicting pins given for its USB2 VBUS:
- Lamobo_R1_defconfig (PH3) / sun7i-a20-lamobo-r1 (PH12)
Signed-off-by: Samuel Holland <samuel@sholland.org>
AXP PMICs have a pin which can either report the USB VBUS state, or
driving a regulator that supplies USB VBUS. Add a regulator driver for
controlling this pin. The selection between input and output is done via
the x-powers,drive-vbus-en pin on the PMIC (parent) node.
Signed-off-by: Samuel Holland <samuel@sholland.org>
DM_GPIO is always enable in U-Boot proper for ARCH_SUNXI, and this
driver is never enabled in SPL, so the condition is always true.
Series-to: sunxi
Signed-off-by: Samuel Holland <samuel@sholland.org>
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.
Series-to: sunxi
Signed-off-by: Samuel Holland <samuel@sholland.org>
commit 95168d77d391 ("sunxi: add Allwinner R528/T113 SoC support") added
the new entry out of order.
Signed-off-by: Samuel Holland <samuel@sholland.org>
If the UART bus or baud clock has a gate, it must be enabled before the
UART can be used.
Series-to: Tom Rini <trini@konsulko.com>
Series-cc: Stefan Roese <sr@denx.de>
Series-cc: Simon Glass <sjg@chromium.org>
Series-cc: u-boot@lists.denx.de
Series-prefix: RESEND
Series-version: 3
Series-changes: 2
- Only enable the first clock, as using the clk_get_bulk() API pushes
a board (phycore-rk3288) over its SPL size limit.
Series-changes: 3
- Switch back to the original patch, now that the phycore-rk3288 build
is fixed by enabling LTO.
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Samuel Holland <samuel@sholland.org>
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.
Series-to: sunxi
Signed-off-by: Samuel Holland <samuel@sholland.org>
CONFIG_ARCH_SUNXI will not be enabled for RISC-V SoCs using this driver.
Use the symbol for the driver itself instead.
Series-to: sunxi
Signed-off-by: Samuel Holland <samuel@sholland.org>
We tried to enable USB_EHCI_GENERIC and USB_OHCI_GENERIC by default.
This did not work because those symbols depend on USB_EHCI_HCD and
USB_OHCI_HCD, which were not enabled. Fix this by implying all four.
Signed-off-by: Samuel Holland <samuel@sholland.org>
reg must contain enough cells for the entire next address/size pair
after skipping `index` pairs. The previous code allows an out-of-bounds
read when na + ns > 1.
Series-to: Simon Glass <sjg@chromium.org>
Fixes: 69b41388ba45 ("dm: core: Add a new api to get indexed device address")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Calculate the maximum length of the buffer when writing
across the page boundary. If the buffer length (len)
exceeds the page boundary (pagesize), split it. Use this
length instead of comparing the length with the pagesize,
because if the write start address (offset) is not at the
beginning of a page and the page_offset + len is greater
than the page boundary (pagesize), the write operation
would overflow the current page and the behaviour can be
undefined (e.g. at24).
Signed-off-by: Alex Michel <alex.michel@wiedemann-group.com>
Similar change was done by commit b4c2c151b14b ("Kconfig: Remove all
default n/no options") and again sync is required.
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com> # tegra
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Angelo Dureghello <angelo@kernel-space.org>
To avoid thermal burn out, program thermal shutdown
value in VTM (Voltage and Thermal Manager) IP.
Part of Linux kernel driver (drivers/thermal/k3_j72xx_bandgap.c)
is ported from kernel 6.6-rc1, which sets thermal shutdown values.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Neha Francis <n-francis@ti.com>
In current vexpress_config_probe code, it sets the uclass private data
directly. This will cause one compilation error:
drivers/misc/vexpress_config.c:114:27: error: lvalue required as left operand of assignment
114 | dev_get_uclass_priv(dev) = priv;
| ^
In this patch we set the uclass private data through struct member
.priv_auto, and this compilation error disappears.
Signed-off-by: Wei Chen <wei.chen@arm.com>
Signed-off-by: Qi Feng <qi.feng@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEgWII69YpahbL5iK5gS8AYozs+qIFAmU7j50ACgkQgS8AYozs
+qIh8w/+O4UjT0sG1NLwmyV7U1Ypk+EyYaE6wmSWzpsJLfH/YvtObBJOYRuXxRVh
J9lkgCsw8Ct1ZNCrp8iVO+Dz1DtV8+QvTecrUHZqcOhTYDaqxXnlvEH2/EUhgo5T
9a/ZaDtOP1mKz754C4G6G363+iRCvbcqDECeKg9VYxfWCo1cINOmqyQCqlGxFT+h
PKiB5VzUpN/K/yiie+Hr42/+6XaykAUjUvEWeyKOsRmYY4lNiK22vG/puE42bFTh
catXwTE2a7x+yzPKkdhR0UGvDUlIKET2kF6mi+pYN2h/cSUxWTzbP/OxcU9yJOnm
qJiRZ+Woez1I7ul6ln4ci2kiWc3CTYFXfctwrBJPuJ/EO+2EEb3oHqG2S3Fc9VBZ
N17flHW7XZHEQbNexlUhk9cRpCwRuSA5OJXwW+IZIuydgNeo3xF0iYvipbjkEGgW
BBkt8PH+ivTLjEz6Gcmquvo1fHGJLHRIPg7DNb0phGHviuC0zlDJ7N5DZk0CpkiT
36siV9xK4X6qvWkOTa6Ldw60e4tN9nv3VG30uXtPHi3XdOkKfNkyIuqO/5BkkQPt
6yEc9IYXYoWNKDVUGme5+xszZp1sSvqltajG9VVNupt958dFyOSgS5aNa6B4UsWX
3XfndP1/s2bezUHoQx5zjraapKVrqBFLkGeTlCDUD+mEgP440G8=
=gvDs
-----END PGP SIGNATURE-----
Merge tag 'tpm-next-27102023' of https://source.denx.de/u-boot/custodians/u-boot-tpm
bootX measurements and measurement API moved to u-boot core:
Up to now, U-Boot could perform measurements and EventLog creation as
described by the TCG spec when booting via EFI.
The EFI code was residing in lib/efi_loader/efi_tcg2.c and contained
both EFI specific code + the API needed to access the TPM, extend PCRs
and create an EventLog. The non-EFI part proved modular enough and
moving it around to the TPM subsystem was straightforward.
With that in place we can have a common API for measuring binaries
regardless of the boot command, EFI or boot(m|i|z), and contructing an
EventLog.
I've tested all of the EFI cases -- booting with an empty EventLog and
booting with a previous stage loader providing one and found no
regressions. Eddie tested the bootX part.
Eddie also fixed the sandbox TPM which couldn't be used for the EFI code
and it now supports all the required capabilities. This had a slight
sideeffect in our testing since the EFI subsystem initializes the TPM
early and 'tpm2 init' failed during some python tests. That code only
opens the device though, so we can replace it with 'tpm2 autostart'
which doesn't error out and still allows you to perfom the rest of the
tests but doesn't report an error if the device is already opened.
There's a few minor issues with this PR as well but since testing and
verifying the changes takes a considerable amount of time, I prefer
merging it now.
Heinrich has already sent a PR for -master containing "efi_loader: fix
EFI_ENTRY point on get_active_pcr_banks" and I am not sure if that will
cause any conflicts, but in any case they should be trivial to resolve.
Both the EFI and non-EFI code have a Kconfig for measuring the loaded
Device Tree. The reason this is optional is that we can't reason
when/if devices add random info like kaslr-seed, mac addresses etc in
the DT. In that case measurements are random, board specific and
eventually useless. The reason it was difficult to fix it prior to this
patchset is because the EFI subsystem and thus measurements was brought
up late and DT fixups might have already been applied. With this
patchset we can measure the DT really early in the future.
Heinrich also pointed out that the two Kconfigs for the DTB measurements
can be squashed in a single one and that the documentation only explains
the non-EFI case. I agree on both but as I said this is a sane working
version, so let's pull this first it's aleady big enough and painful to
test.
Add A1 SPIFC driver from Linux. Slightly modified to use u-boot driver
framework and accommodate to lack of ioread32_rep/iowrite32_rep.
Based on Linux version 6.6-rc4
Signed-off-by: Igor Prusov <IVPrusov@sberdevices.ru>
Signed-off-by: Martin Kurbanov <mmkurbanov@sberdevices.ru>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20231024225140.366571-2-ivprusov@sberdevices.ru
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
[trini: Drop <common.h> as it's not needed]
The driver needs to support getting the PCRs in the capabilities
command. Fix various other things and support the max number
of PCRs for TPM2.
Remove the !SANDBOX dependency for EFI TCG2 as well.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The R-Car Gen3 SD_CLK_CTRL register does not use BIT(16) to implement
divider 1/1024, instead BIT(16) is reserved bit and divider 1/1024 is
not supported. The divider 1/1024 is specific to Socionext variant of
the IP, as is indicated by Linux commit:
0196c8db8363 ("mmc: tmio: move tmio_mmc_set_clock() to platform hook")
"
Socionext (and Panasonic) uses bit 10 (CLKSEL) for 1/1. Also, newer
versions of UniPhier SoC variants use bit 16 for 1/1024.
"
Do not set the TMIO_SD_CAP_DIV1024 on Renesas R-Car platforms even if
the IP VERSION register does exist, and indicates IP version is newer
or equal to version 1.0 . The IP version 1.0 or newer does not imply
presence of the 1/1024 divider.
Since the TMIO driver is used exactly by two supported platforms, that
is Renesas R-Car and Socionext UniPhier, it is OK to check whether the
TMIO_SD_CAP_RCAR capability is not set to identify the UniPhier platform
and add the capability only on that platform.
Fixes: 58c35b17aa8f ("mmc: matsushita-common: Always check controller version")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-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>
Unconditionally check for errors even after successful reception
of IRQ flag, since the hardware may set both an IRQ completion
flag and an error flag at the same time.
This mode of failure happens in case of an error during transfer,
in which case the hardware may set the expected IRQ completion
flag as well as error flags. The later is currently not checked
by the driver and such an error is not detected. Improve the
error detection.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Thuan Nguyen Hong <thuan.nguyen-hong@banvien.com.vn>
This driver is long superseded by renesas-sdhi.c and unused.
Drop the driver.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Paul Barker <paul.barker.ct@bp.renesas.com>
We should ensure that reset_free() is called in the error path.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Fixes: 93c811b7331b ("mmc: renesas-sdhi: Initialize module on RZ/G2L")
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
When debugging, one sometimes only gets partial output lines or
nothing at all from the last printf, because the uart has a largish
buffer, and the code after the printf() may cause the CPU to hang
before the uart IP has time to actually emit all the characters. That
can be very confusing, because one doesn't then know exactly where the
hang happens.
Introduce a config knob allowing one to wait for the uart fifo to
drain whenever a newline character is printed, roughly corresponding
to the effect of setvbuf(..., _IOLBF, ...) in ordinary C programs.
Since this uses IS_ENABLED() instead of cpp ifdef, we can remove the
ifdef around the _serial_flush() definition - if neither
CONSOLE_FLUSH_SUPPORT or CONSOLE_FLUSH_ON_NEWLINE are enabled, the
compiler elides _serial_flush(), but it won't warn about it being
unused.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
