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>
Now that the USB PHY driver uses the device tree to get VBUS supply
regulators, these Kconfig symbols are unused. Remove them.
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>
On many boards, the USB ports are powered by the PMIC's "drivevbus"
regulator. In preparation for switching the USB PHY driver to use the
regulator uclass instead of a virtual GPIO pin, ensure these boards
have AXP PMIC regulator support enabled.
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>
Some RISC-V CPUs, such as the T-HEAD XuanTie series, have a
vendor-specific way to invalidate a portion of the instruction cache.
Allow them to override invalidate_icache_range().
Series-to: Rick Chen <rick@andestech.com>
Series-to: Leo <ycliang@andestech.com>
Series-cc: u-boot@lists.denx.de
Signed-off-by: Samuel Holland <samuel@sholland.org>
This is required on CPUs which always operate in CLIC mode, such as the
T-HEAD E906 and E907. Per the CLIC specification: "In this mode, the
trap vector base address held in mtvec is constrained to be aligned on a
64-byte or larger power-of-two boundary."
Series-to: Rick Chen <rick@andestech.com>
Series-to: Leo <ycliang@andestech.com>
Series-cc: u-boot@lists.denx.de
Reported-by: Madushan Nishantha <jlmadushan@gmail.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Clean things up for the next time somebody adds a target.
Series-to: Rick Chen <rick@andestech.com>
Series-to: Leo <ycliang@andestech.com>
Series-cc: u-boot@lists.denx.de
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>
Now that 32-bit SoCs can load U-Boot proper (and possibly other
firmware) from a FIT, use this method by default. SPL_FIT_IMAGE_TINY is
required to stay within the 24 or 32 KiB SPL size limit on early SoCs;
for consistency, enable it everywhere.
Series-to: Andre Przywara <andre.przywara@arm.com>
Series-to: Jagan Teki <jagan@amarulasolutions.com>
Series-cc: Icenowy Zheng <icenowy@aosc.io>
Series-cc: Jesse Taube <Mr.Bossman075@gmail.com>
Series-cc: u-boot@lists.denx.de
Series-version: 3
Commit-changes: 2
- New patch for v2, split from the .dtsi changes
Cover-changes: 3
- Rebased and collected tags
Cover-letter:
sunxi: SPL FIT support for 32-bit sunxi SoCs
This series makes the necessary changes so 32-bit sunxi SoCs can load
additional device trees or firmware from SPL along with U-Boot proper.
Crust (SCP firmware) has support for A33 and H3, and H3 also needs to
load an eGon blob to support CPU 0 hotplug (a silicon bug workaround).
FIT unlocks more features (signatures, multiple DTBs, etc.), so enable
it by default. A10 (sun4i) only has 24 KiB of SRAM A1, so it needs
SPL_FIT_IMAGE_TINY. For consistency, enable that option everywhere.
After this series is applied, we can increase SPL_MAX_SIZE for H6 and
newer SoCs, both 32-bit (e.g. A50, T113) and 64-bit. I did not do that
yet because there is some discussion to be had about the correct value:
it must be adjusted to guarantee return-to-FEL functionality, and the
exact adjustment depends on the sunxi-fel tool implementation.
END
Signed-off-by: Samuel Holland <samuel@sholland.org>
Some 32-bit SoCs can use SCP firmware to implement additional PSCI
functionality, such as system suspend. In order to load this firmware
from SPL, we need to generate and use a FIT instead of a legacy image.
Adjust the binman FIT definition so it does not rely on TF-A BL31, as
this is not used on 32-bit SoCs. Instead, after loading the firmware,
U-Boot proper is executed directly.
Series-changes: 2
- Rely on binman min-size instead of using explicit offsets
- Use Kconfig for firmware addresses instead of an #ifdef staircase
Signed-off-by: Samuel Holland <samuel@sholland.org>
This is easier to read than the #ifdef staircase, provides better
visibility into the memory map (alongside the other Kconfig
definitions), and allows these addresses to be reused from code.
Commit-changes: 2
- New patch for v2, split from the .dtsi changes
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
