aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2023-10-22sunxi: add Allwinner R528/T113 SoC supportAndre Przywara
This adds the remaining code bits to teach U-Boot about Allwinner's newest SoC generation. This was introduced with the RISC-V based Allwinner D1 SoC, which actually shares a die with the ARM cores versions called R528 (BGA, without DRAM) and T113s (QFP, with embedded DRAM). This adds the new Kconfig stanza, using the two newly introduced symbols for the new SoC generation and pincontroller. It also adds the new symbols to the relavent code places, to set all the hardcoded bits directly. We need one DT override: The ARM core version of the DT specifies the CPUX watchdog as "reserved", which means it won't be recognised by U-Boot. Override this in our generic sunxi-u-boot.dtsi, to let U-Boot pick up this watchdog, so that the generic reset driver will work. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2023-10-22sunxi: add R528/T113-s3/D1(s) DRAM initialisation codeAndre Przywara
The Allwinner R528/T113-s/D1/D1s SoCs all share the same die, so use the same DRAM initialisation code. Make use of prior art here and lift some code from awboot[1], which carried init code based on earlier decompilation efforts, but with a GPL2 license tag. This code has been heavily reworked and cleaned up, to match previous DRAM routines for other SoCs, and also to be closer to U-Boot's coding style and support routines. The actual DRAM chip timing parameters are included in the main file, since they cover all DRAM types, and are protected by a new Kconfig CONFIG_SUNXI_DRAM_TYPE symbol, which allows the compiler to pick only the relevant settings, at build time. The relevant DRAM chips/board specific configuration parameters are delivered via Kconfig, so this code here should work for all supported SoCs and DRAM chips combinations. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Sam Edwards <CFSworks@gmail.com>
2023-10-22Kconfig: sunxi: prepare for using drivers/ram/sunxiAndre Przywara
At the moment all Allwinner DRAM initialisation routines are stored in arch/arm/mach-sunxi, even though those "drivers" are just a giant collection of writel's, without any architectural dependency. The R528/T113-s SoC (with ARM cores) and the D1/D1s Soc (with RISC-V cores) share the same die, so should share the same DRAM init routines as well. To prepare for this, add a new sunxi directory inside drivers/ram, and add some stub entries to prepare for the addition of the share DRAM code for those SoCs. The RISC-V D1(s) SoCs will probably use SPL_DM, so for that SoC this would be the right directory anyway. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2023-10-22clk: sunxi: Add support for the D1 CCUSamuel Holland
Since the D1 CCU binding is defined, we can add support for its gates/resets, following the pattern of the existing drivers. Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2023-10-22pinctrl: sunxi: add Allwinner D1 pinctrl descriptionAndre Przywara
Apart from using the new pinctrl MMIO register layout, the Allwinner D1 and related SoCs still need to usual set of mux values hardcoded in U-Boot's pinctrl driver. Add the values we need so far to this list, so that DM based drivers will just work without further ado. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2023-10-22sunxi: introduce NCAT2 generation modelAndre Przywara
Allwinner seems to typically stick to a common MMIO memory map for several SoCs, but from time to time does some breaking changes, which also introduce new generations of some peripherals. The last time this happened with the H6, which apart from re-organising the base addresses also changed the clock controller significantly. We added a CONFIG_SUN50I_GEN_H6 symbol back then to mark SoCs sharing those traits. Now the Allwinner D1 changes the memory map again, and also extends the pincontroller, among other peripherals. To mark this generation of SoCs, add a CONFIG_SUNXI_GEN_NCAT2 symbol, this name is reportedly used in the Allwinner BSP code, and prevents us from inventing our own name. Add this new symbol to some guards that were already checking for the H6 generation, since many features are shared between the two (like the renovated clock controller). This paves the way to introduce a first user of this generation. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Samuel Holland <samuel@sholland.org>
2023-10-22pinctrl: sunxi: add new D1 pinctrl supportAndre Przywara
For the first time since at least the Allwinner A10 SoCs, the D1 (and related cores) use a new pincontroller MMIO register layout, so we cannot use our hardcoded, fixed offsets anymore. Ideally this would all be handled by devicetree and DM drivers, but for the DT-less SPL we still need the legacy interfaces. Add a new Kconfig symbol to differenciate between the two generations of pincontrollers, and just use that to just switch some basic symbols. The rest is already abstracted enough, so works out of the box. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Sam Edwards <CFSworks@gmail.com> Tested-by: Sam Edwards <CFSworks@gmail.com> Tested-by: Samuel Holland <samuel@sholland.org>
2023-10-22pinctrl: sunxi: remove GPIO_EXTRA_HEADERAndre Przywara
U-Boot's generic GPIO_EXTRA_HEADER is a convenience symbol to allow code to more easily include platform specific GPIO headers. This should not be needed in a DM world anymore, since the generic GPIO framework handles that nicely. For Allwinner boards we still need to deal with non-DM GPIO in the SPL, but this should become the exception, not the rule. Make this more obvious by removing the definition of GPIO_EXTRA_HEADER, and just force every legacy user of platform specific GPIO to include the new sunxi_gpio.h header explicitly. Everyone doing so should feel ashamed and should find a way to avoid it from now on. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Samuel Holland <samuel@sholland.org>
2023-10-22pinctrl: sunxi: remove struct sunxi_gpioAndre Przywara
So far every Allwinner SoC used the same basic pincontroller/GPIO register frame, and just differed by the number of implemented banks and pins, plus some special functionality from time to time. However the D1 and successors use a slightly different pinctrl register layout. Use that opportunity to drop "struct sunxi_gpio", that described that MMIO frame in a C struct. That approach is somewhat frowned upon in the Linux world and rarely used there, though still popular with U-Boot. Switching from a C struct to a "base address plus offset" approach allows to switch between the two models more dynamically, without reverting to preprocessor macros and #ifdef's. Model the pinctrl MMIO register frame in the usual "base address + offset" way, and replace a hard-to-parse CPP macro with a more readable static function. All the users get converted over. There are no functional changes at this point, it just prepares the stages for the D1 and friends. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Samuel Holland <samuel@sholland.org> Tested-by: Samuel Holland <samuel@sholland.org>
2023-10-22pinctrl: sunxi: add GPIO in/out wrappersAndre Przywara
So far we were open-coding the pincontroller's GPIO output/input access in each function using that. Provide functions that wrap that nicely, and follow the existing pattern (set/get_{bank,}), so users don't need to know about the internals, and we can abstract the new D1 pinctrl more easily. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Samuel Holland <samuel@sholland.org>
2023-10-22pinctrl: sunxi: move pinctrl codeAndre Przywara
Move the existing sunxi-specific low level pinctrl routines from arch/arm/mach-sunxi into the existing GPIO code under drivers/gpio, so that the common code can be shared outside of arch/arm. This also takes the opportunity to move some definitions from our header file into the driver C file, as they are private to the driver and are not needed elsewhere. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Samuel Holland <samuel@sholland.org> Tested-by: Samuel Holland <samuel@sholland.org>
2023-10-22sunxi: remove CONFIG_MACPWRAndre Przywara
The CONFIG_MACPWR Kconfig symbol is used to point to a GPIO that enables the power for the Ethernet "MAC" (mostly PHY, really). In the DT this is described with the phy-supply property in the MAC DT node, pointing to a (GPIO controlled) regulator. Since we need Ethernet only in U-Boot proper, and use a DM driver there, we should use the DT instead of hardcoding this. Add code to the sun8i_emac and sunxi_emac drivers to check the DT for that regulator and enable it, at probe time. Then drop the current code from board.c, which was doing that job before. This allows us to remove the MACPWR Kconfig definition and the respective values from the defconfigs. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Sam Edwards <CFSworks@gmail.com>
2023-10-22net: sunxi_emac: chase DT nodes to find PHY regulatorAndre Przywara
At the moment the sun4i EMAC driver relies on hardcoded CONFIG_MACPWR Kconfig symbols to enable potential PHY regulators. As we want to get rid of those, we need to find the regulator by chasing up the DT. The sun4i-emac binding puts the PHY regulator into the MDIO node, which is the parent of the PHY device. U-Boot does not have (and does not need) an MDIO driver, so we need to chase down the regulator through the EMAC node: we follow the "phy-handle" property to find the PHY node, then go up to its parent, where we find the "phy-supply" link to the regulator. Let U-Boot find the associated regulator device, and put that into the private device struct, so we can find and enable the regulator at probe time, later. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Sam Edwards <CFSworks@gmail.com> Reviewed-by: Samuel Holland <samuel@sholland.org>
2023-10-22sunxi: remove CONFIG_SATAPWRAndre Przywara
The CONFIG_SATAPWR Kconfig symbol was used to point to a GPIO that enables the power for a SATA harddisk. In the DT this is described with the target-supply property in the AHCI DT node, pointing to a (GPIO controlled) regulator. Since we need SATA only in U-Boot proper, and use a DM driver for AHCI there, we should use the DT instead of hardcoding this. Add code to the sunxi AHCI driver to check the DT for that regulator and enable it, at probe time. Then drop the current code from board.c, which was doing that job before. This allows us to remove the SATAPWR Kconfig definition and the respective values from the defconfigs. We also select the generic fixed regulator driver, which handles those GPIO controlled regulators. Please note that the OrangePi Plus is a bit special here, it's a H3 board without native SATA, but with a USB-to-SATA bridge. The DT models the SATA power via a VBUS supply regulator, which we don't parse yet in the USB PHY driver. Use the hardcoded CONFIG_USB3_VBUS_PIN for that board meanwhile. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Sam Edwards <CFSworks@gmail.com> Reviewed-by: Samuel Holland <samuel@sholland.org>
2023-10-19serial: sh: Add RZ/G2L SCIF supportPaul Barker
Extend the existing driver to support the SCIF serial ports on the Renesas RZ/G2L (R9A07G044) SoC. This also requires us to ensure that if there is a reset signal defined in the device tree, it is de-asserted before we try to talk to the SCIF module. Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # R-Car H3 Salvator-XS
2023-10-19serial: sh: Fix error handlingPaul Barker
The current SCIF error handling is broken for the RZ/G2L. After a break condition has been triggered, the current code is unable to clear the error and serial port output never resumes. The RZ/G2L datasheet says that most error conditions are cleared by resetting the relevant error bits in the FSR & LSR registers to zero. To clear framing errors on SCIF ports, the invalid data also needs to be read out of the receive FIFO. After reviewing datasheets for RZ/G2{H,M,N,E}, R-Car Gen4, R-Car Gen3 and even SH7751 SoCs, it's clear that this is the way to clear errors for all of these SoCs. While we're here, annotate the handle_error() function with a couple of comments as the reads and writes themselves don't immediately make it clear what we're doing. Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Tested-by: Chris Paterson <chris.paterson2@renesas.com> # HiHope RZ/G2M board Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # R-Car H3 Salvator-XS
2023-10-19wdt: nuvoton: Fix reset/expire function errorJim Liu
Fix npcm845 watchdog halt for reset function and expire function. Reset function is restart wdt. Signed-off-by: Jim Liu <JJLIU0@nuvoton.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-10-17lib: acpi: Fix linking SPL when ACPIGEN is enabledSean Anderson
lib/acpi/acpigen.o is only compiled into SPL when SPL_ACPIGEN is enabled. Update several files which reference these functions accordingly. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-10-17spl: Allow enabling SPL_OF_REAL and SPL_OF_PLATDATA at the same timeSean Anderson
Sandbox unit tests in U-Boot proper load a test device tree to have some devices to work with. In order to do the same in SPL, we must enable SPL_OF_REAL. However, we already have SPL_OF_PLATDATA enabled. When generating platdata from a devicetree, it is expected that we will not need devicetree access functions (even though SPL_OF_CONTROL is enabled). This expectation does not hold for sandbox, so allow user control of SPL_OF_REAL. There are several places in the tree where conditions involving OF_PLATDATA or OF_REAL no longer function correctly when both of these options can be selected at the same time. Adjust these conditions accordingly. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-10-17arm: imx: Check header before calling spl_load_imx_containerSean Anderson
Make sure we have an IMX header before calling spl_load_imx_container, since if we don't it will fail with -ENOENT. This allows us to fall back to legacy/raw images if they are also enabled. This is a functional change, one which likely should have been in place from the start, but a functional change nonetheless. Previously, all non-IMX8 images (except FITs without FIT_FULL) would be optimized out if the only image load method enabled supported IMX8 images. With this change, support for other image types now has an effect. There are seven boards with SPL_LOAD_IMX_CONTAINER enabled: three with SPL_BOOTROM_SUPPORT: imx93_11x11_evk_ld imx93_11x11_evk imx8ulp_evk and four with SPL_MMC: deneb imx8qxp_mek giedi imx8qm_mek All of these boards also have SPL_RAW_IMAGE_SUPPORT and SPL_LEGACY_IMAGE_FORMAT enabled as well. However, none have FIT support enabled. Of the six load methods affected by this patch, only SPL_MMC and SPL_BOOTROM_SUPPORT are enabled with SPL_LOAD_IMX_CONTAINER. spl_romapi_load_image_seekable does not support legacy or raw images, so there is no growth. However, mmc_load_image_raw_sector does support loading legacy/raw images. Since these images could not have been booted before, I have disabled support for legacy/raw images on these four boards. This reduces bloat from around 800 bytes to around 200. There are no in-tree boards with SPL_LOAD_IMX_CONTAINER and AHAB_BOOT both enabled, so we do not need to worry about potentially falling back to legacy images in a secure boot scenario. Future work could include merging imx_container.h with imx8image.h, since they appear to define mostly the same structures. Signed-off-by: Sean Anderson <seanga2@gmail.com>
2023-10-17Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-shTom Rini
- RZ/G2L part 1, except for two serial port patches which I had to drop as they broke R2Dplus, they will come later via subsequent PR.
2023-10-17mmc: renesas-sdhi: Initialize module on RZ/G2LPaul Barker
On the Renesas RZ/G2L SoC family, we must ensure that the required clock signals are enabled and the reset signal is de-asserted before we try to communicate with the SDHI module. Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-10-17mmc: renesas-sdhi: Refactor probe functionPaul Barker
Move the assignment of priv->quirks earlier in the function. This allows us to drop the quirks local variable and makes it easier to maintain clean error handling when we add RZ/G2L support in the next patch. Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-10-17serial: sh: Sort includesPaul Barker
Tidy up the existing include list before we add more includes in the following patch. Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-10-16Merge tag 'u-boot-imx-20231016' of ↵Tom Rini
https://gitlab.denx.de/u-boot/custodians/u-boot-imx u-boot-imx-20231016 ------------------- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/18168 - Imrovement MX93 - Toradex: fixes - Convert to DM (serial, watchdog) for some boards - HAB improvements for Secure Boot - DTO overlay for DHCOM - USB fixes, Mass storage for MX28 - Cleanup some code - Phytec MX8M : EEProm detection, fixes - Gateworks Boards improvements
2023-10-16Merge https://source.denx.de/u-boot/custodians/u-boot-marvellTom Rini
- dns325: Enable 2nd harddrive (Peter & Stefan) - marvell: cn9310-crb: Misc fixes to SPI / pincntrl in DTS (Chris) - kirkwood: Add support for ZyXEL NSA325 board (Tony) - sata_mv: Add bootstd hook to enable sata_bootdev (Tony) - x240/AC5/AC5X: Disable SMBIOS (Chris) - Revert "arm: mvebu: x240: Use i2c-gpio instead of built in controller" (Chris) - DS116/N2350: Enable bootstd (Tony) - clearfog: Support multiple DDR sizes (Josua)
2023-10-16gpio: Add RZ/G2L GPIO driverPaul Barker
This driver adds support for the gpio features of the GPIO/PFC module in the Renesas RZ/G2L (R9A07G044) SoC. The new `rzg2l-pfc-gpio` driver is bound to the same device tree node as the `rzg2l-pfc-pinctrl` driver as the same hardware block provides both GPIO and pin multiplexing features. This patch is based on the corresponding Linux v6.5 driver (commit 52e12027d50affbf60c6c9c64db8017391b0c22e). Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-10-16pinctrl: renesas: Add RZ/G2L PFC driverPaul Barker
This driver adds support for the pinctrl features of the GPIO/PFC module in the Renesas RZ/G2L (R9A07G044) SoC. A multi-function `rzg2l-pfc` driver is defined for UCLASS_NOP, which binds the `rzg2l-pfc-pinctrl` UCLASS_PINCTRL driver dynamically. We also define common macros and functions for the PFC in <renesas/rzg2l-pfc.h>. This makes it easy to add an additional UCLASS_GPIO driver for the GPIO functionality of this module in a follow-up patch. This patch is based on the corresponding Linux v6.5 driver (commit 52e12027d50affbf60c6c9c64db8017391b0c22e). Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-10-16clk: renesas: Add RZ/G2L & RZ/G2LC CPG driverPaul Barker
This driver provides clock and reset control for the Renesas R9A07G044L (RZ/G2L) and R9A07G044C (RZ/G2LC) SoC. It consists of two parts: * driver code which is applicable to all SoCs in the RZ/G2L family. * static data describing the clocks and resets which are specific to the R9A07G044{L,C} SoCs. The identifier r9a07g044 (without a final letter) is used to indicate that both SoCs are supported. clk_set_rate() and clk_get_rate() are implemented only for the clocks that are actually used in u-boot. The CPG driver is marked with DM_FLAG_PRE_RELOC to ensure that its bind function is called before the SCIF (serial port) driver is probed. This is required so that we can de-assert the relevant reset signal during the serial driver probe function. This patch is based on the corresponding Linux v6.5 driver (commit 52e12027d50affbf60c6c9c64db8017391b0c22e). Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-10-16serial: sh: Fix compile error when lacking HSCIF supportPaul Barker
If we attempt to compile serial_sh.c for a system which lacks HSCIF support (e.g. R8A7740), we see the following compilation error: In file included from drivers/serial/serial_sh.c:20: drivers/serial/serial_sh.c: In function ‘sh_serial_init_generic’: drivers/serial/serial_sh.h:429:35: warning: implicit declaration of function ‘sci_HSSRR_out’; did you mean ‘sci_SCSCR_out’? [-Wimplicit-function-declaration] 429 | #define sci_out(port, reg, value) sci_##reg##_out(port, value) | ^~~~ drivers/serial/serial_sh.c:62:17: note: in expansion of macro ‘sci_out’ 62 | sci_out(port, HSSRR, HSSRR_SRE | HSSRR_SRCYC8); | ^~~~~~~ To fix this, only try to support access to the HSSRR register for SoCs where it actually exists. Support for the RZ/G2L will be introduced in following patches, which selects CONFIG_RCAR_64 but does not have HSCIF interfaces, so check for CONFIG_RCAR_GEN2 || CONFIG_RCAR_GEN3 || CONFIG_RCAR_GEN4 to determine if HSCIF is present. Fixes: bbe36e29ca2c ('serial: sh: Add HSCIF support for R-Car SoC') Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Cc: Hai Pham <hai.pham.ud@renesas.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-10-16Merge tag 'u-boot-amlogic-20231015' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-amlogic - add Amlogic A1 clock driver - add Amlogic A1 reset support - add USB Device support for Amlogic A1 - enable RNG on Amlogic A1 & Amlogic S4 - move Amlogic Secure Monitor to standalone driver
2023-10-16serial: lpuart: Enable IPG clockYe Li
Current codes only ennable the PER clock. However on iMX8 the LPUART also needs IPG clock which is an LPCG. Should not depend on the default LPCG setting. Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
2023-10-16clk: imx: add i.MX93 CCF driverSébastien Szymanski
Add i.MX93 CCF driver support. Modifed from Linux Kernel v6.5-rc2 and adapted for U-Boot. Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
2023-10-16arm: mvebu: sata_mv: Add bootstd hook to enable sata_bootdevTony Dinh
Add hook in sata_mv probe to enable bootstd bootdev. Note: bootdev_setup_for_sibling_blk() invocation is a noop if bootsd is not enabled for ahci sata yet. Signed-off-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de>
2023-10-16usb: ehci: mxs: Use regulator_set_enable_if_allowed()Fabio Estevam
Since commit 4fcba5d556b4 ("regulator: implement basic reference counter") the return value of regulator_set_enable() may be EALREADY or EBUSY for fixed/GPIO regulators. Switch to using the more relaxed regulator_set_enable_if_allowed() to continue if regulator already was enabled or disabled. This fixes the following error when running the 'ums' command: => ums 0 mmc 0 UMS: LUN 0, dev mmc 0, hwpart 0, sector 0x0, count 0xece000 Error enabling VBUS supply g_dnl_register: failed!, error: -114 g_dnl_register failed Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Marek Vasut <marex@denx.de>
2023-10-16usb: ehci: mxs: Fix the USB node pointer retrievalFabio Estevam
Use dev_ofnode() to retrieve the USB node pointer from the udevice structure. This fixes the following build error: drivers/usb/host/ehci-mxs.c:143:38: error: 'struct udevice' has no member named 'node_' Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Marek Vasut <marex@denx.de>
2023-10-15drivers: introduce Meson Secure Monitor driverAlexey Romanov
This patch adds an implementation of the Meson Secure Monitor driver based on UCLASS_SM. Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/20230921081346.22157-7-avromanov@salutedevices.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2023-10-15sandbox: add sandbox sm uclass driverAlexey Romanov
This patch adds sandbox secure monitor driver. Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/20230921081346.22157-3-avromanov@salutedevices.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2023-10-15drivers: introduce Secure Monitor uclassAlexey Romanov
At the moment, we don't have a common API for working with SM, only the smc_call() function. This approach is not generic and difficult to configure and maintain. This patch adds UCLASS_SM with the generic API: - sm_call() - sm_call_write() - sm_call_read() These functions operate with struct pt_regs, which describes Secure Monitor arguments. Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/20230921081346.22157-2-avromanov@salutedevices.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2023-10-14Merge tag 'dm-pull-13oct23' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-dm improvements with dev_read_addr_..._ptr() scan all entries in multi-device boot_targets EFI empty-capsule support
2023-10-13firmware: scmi: Fix clearing variableFrancois Berder
The sess variable in open_channel was not entirely cleared to zero at the start of this function. This commit ensures that the entire struct is cleared. Signed-off-by: Francois Berder <fberder@outlook.fr>
2023-10-13firmware: scmi: add a check against availability of protocolsAKASHI Takahiro
Now that we have Base protocol support, we will be able to check if a given protocol is really supported by the SCMI server (firmware). Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-10-13firmware: scmi: install base protocol to SCMI agentAKASHI Takahiro
SCMI base protocol is mandatory, and once SCMI node is found in a device tree, the protocol handle (udevice) is unconditionally installed to the agent. Then basic information will be retrieved from SCMI server via the protocol and saved into the agent instance's local storage. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
2023-10-13test: dm: simplify SCMI unit test on sandboxAKASHI Takahiro
Adding SCMI base protocol makes it inconvenient to hold the agent instance (udevice) locally since the agent device will be re-created per each test. Just remove it and simplify the test flows. The test scenario is not changed at all. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
2023-10-13firmware: scmi: fake base protocol commands on sandboxAKASHI Takahiro
This is a simple implementation of SCMI base protocol for sandbox. The main use is in SCMI unit test. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
2023-10-13firmware: scmi: add a version check against base protocolAKASHI Takahiro
In SCMI base protocol version 2 (0x20000), new interfaces, BASE_SET_DEVICE_PERMISSIONS/BASE_SET_PROTOCOL_PERMISSIONS/ BASE_RESET_AGENT_CONFIGURATION, were added. Moreover, the api of BASE_DISCOVER_AGENT was changed to support self-agent discovery. So the driver expects SCMI firmware support version 2 of base protocol. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
2023-10-13firmware: scmi: implement SCMI base protocolAKASHI Takahiro
SCMI base protocol is mandatory according to the SCMI specification. With this patch, SCMI base protocol can be accessed via SCMI transport layers. All the commands, except SCMI_BASE_NOTIFY_ERRORS, are supported. This is because U-Boot doesn't support interrupts and the current transport layers are not able to handle asynchronous messages properly. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
2023-10-13firmware: scmi: framework for installing additional protocolsAKASHI Takahiro
This framework allows SCMI protocols to be installed and bound to the agent so that the agent can manage and utilize them later. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
2023-10-13firmware: scmi: move scmi_bind_protocols() backwardAKASHI Takahiro
Move the location of scmi_bind_protocols() backward for changes in later patches. There is no change in functionality. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
2023-10-13firmware: scmi: support dummy channels for sandbox agentAKASHI Takahiro
In sandbox scmi agent, channels are not used at all. But in this patch, dummy channels are supported in order to test protocol-specific channels. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>