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>
These PMICs each have two GPIO pins, and are supported by the axp_gpio
driver. In order to convert the axp_gpio driver to probe using the
device tree, the corresponding device tree nodes must be present. Add
them, following the same binding as the AXP209 and AXP813.
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>
While R40 puts the EMAC syscon register at a different address from
other variants, the relevant portion of the register's layout is the
same. Factor out the register offset so the same code can be shared
by all variants. This matches what the Linux driver does.
This change provides two benefits beyond the simplification:
- R40 boards now respect the RX delays from the devicetree
- This resolves a warning on architectures where readl/writel
expect the address to have a pointer type, not phys_addr_t.
Series-to: sunxi
Cover-letter:
net: sun8i-emac: Allwinner D1 Support
D1 is a RISC-V SoC containing an EMAC compatible with the A64 EMAC.
However, there are a couple of issues with the driver preventing it
being built for RISC-V. These are resolved by patches 2-3. Patch 1 is
a general cleanup.
END
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.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Since the D1 CCU binding is defined, we can add support for its
gates/resets, following the pattern of the existing drivers.
Series-to: sunxi
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 a GPIO-controlled fixed
regulator. In preparation for switching the USB PHY driver to use the
regulator uclass instead of driving the GPIO directly, ensure these
boards have fixed regulator support enabled.
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>
Now that some regulator driver exists for this PMIC, add support for
probing regulator drivers from the device tree subnodes.
Signed-off-by: Samuel Holland <samuel@sholland.org>
The first AXP regulator converted to use the regulator uclass is the
drivevbus switch, since it is used by the USB PHY driver.
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.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Update boards to use the USB power supply driver, as referenced in the
device tree, instead of a virtual GPIO. This removes the need for some
DM-incompatible special cases in the GPIO driver.
The following five boards used AXP0-VBUS-DETECT in their config, but are
missing the "usb0_vbus_power-supply" property in their device tree:
- Ainol_AW1_defconfig / sun7i-a20-ainol-aw1
- Cubieboard4_defconfig / sun9i-a80-cubieboard4
- Merrii_A80_Optimus_defconfig / sun9i-a80-optimus
- Yones_Toptech_BD1078_defconfig / sun7i-a20-yones-toptech-bd1078
- Yones_Toptech_BS1078_V2_defconfig /
sun6i-a31s-yones-toptech-bs1078-v2
None of those five boards have the MUSB controller (USB OTG) enabled in
their device trees, so this change should not break anything for them.
Additionally, the following board intentionally omits the property
because VBUS is always enabled:
- Nintendo_NES_Classic_Edition_defconfig /
sun8i-r16-nintendo-nes-classic
The PHY driver already assumes VBUS is enabled when no detection method
is available, so again this will not cause any problems.
Signed-off-by: Samuel Holland <samuel@sholland.org>
This driver reports the presence/absence of voltage on the PMIC's USB
VBUS pin. This information is used by the USB PHY driver. The
corresponding Linux driver uses the power supply class, which does not
exist in U-Boot. UCLASS_REGULATOR seems to be the closest match.
Signed-off-by: Samuel Holland <samuel@sholland.org>
This board is configured with CONFIG_USB1_VBUS_PIN="PH24", but no
regulator exists in its device tree. Add the regulator, so USB will
continue to work when the PHY driver switches to using the regulator
uclass instead of a GPIO.
Update the device tree here because it does not exist in Linux.
Signed-off-by: Samuel Holland <samuel@sholland.org>
To quote Simon:
This series provides an implementation of VBE from TPL through to U-Boot
proper, using VBE to load the relevant firmware stages. It buils a single
image.bin file containing all the phases:
TPL - initial phase, loads VPL using binman symbols
VPL - main firmware phase, loads SPL using VBE parameters
SPL - loads U-Boot proper using VBE parameters
U-Boot - final firmware phase, where OS booting is processed
This series does not include the OS-booting phase. That will be the
subject of a future series.
The implementation is entirely handled by sandbox. It should be possible
to enable this on a real board without much effort, but that is also the
subject of a future series.
Use a manual test for the VBE test, so we can make the pytest and the
C unit test work together properly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use binman to build an image which includes all the U-Boot phases so that
a full VBE boot can take place with just that image.bin file. Attach the
image file to mmc2 so it can be loaded.
VBE is used to load images in two phases:
- In VPL, VBE decides which SPL image to load
- In SPL, VBE decides which U-Boot image to load
The latter should really be determined by VPL, since it does the full
signature verification on the selected configuration. However, we have
separate configurations for SPL and U-Boot proper, so for now we keep it
simple and have SPL do its own verification. This will need to be
tidied up later.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we put the driver in the /chosen node in U-Boot. This is a bit
strange, since U-Boot doesn't normally use that node itself. It is better
to put it under the bootstd node.
To make this work we need to copy create the node under /chosen when
fixing up the device tree. Copy over all the properties so that fwupd
knows what to do.
Update the sandbox device tree accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Enable the various features needed in VPL, by adding Kconfig options.
Update the defconfig for sandbox_vpl so that the build for each phase
includes what is needed. Drop LZMA for now and make sure partition support
is omitted in SPL, since it is not needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't need the U-Boot prefix on the version and in fact it is harmful
since pytest gets confused seeing the U-Boot banner bring displayed when
the version is printed.
Drop the prefix from the string.
We could produce an entirely new string from the component parts, but this
adds to the rodata size and would break the use of version_string as the
only thing which holds this information.
Signed-off-by: Simon Glass <sjg@chromium.org>
VBE supports booting firmware during the SPL phases, i.e. so that VPL can
start SPL and SPL can start U-Boot.
It also supports booting an OS, when in U-Boot.
As a first step towards these features, add functions to indicate the
current VBE phase. The firmware selection is done in VPL and the OS
selection is done in U-Boot proper.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present sandbox runs the next phase from discrete executables, so for
example u-boot-tpl runs u-boot-vpl to get to the next phase.
In some cases the phases are all built into a single firmware image, as is
done for real boards. Add support for this to sandbox.
Make it higher priority so that it takes precedence over the existing
method.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we only support a single loader of each time. Extra ones are
ignored. This means that only one BOOT_DEVICE_BOARD can be used in the SPL
image.
This is inconvenient since we sometimes want to provide several
board-specific drivers, albeit at different priorties. Add support for
this.
This should have no functional change for existing boards.
Signed-off-by: Simon Glass <sjg@chromium.org>
The vbe_fixup file handles device tree fixups, but these are called OS
requests in VBE. Rename the file to reflect its wider purpose.
Signed-off-by: Simon Glass <sjg@chromium.org>
