As Icenowy pointed out, newer manuals (starting with H6) actually
document the register block at offset 0x800 as "HCI controller and PHY
interface", also describe the bits in our "PMU_UNK1" register.
Let's put proper names to those "unknown" variables and symbols.
While we are at it, generalise the existing code by allowing a bitmap
of bits to clear and set, to cover newer SoCs: The A100 and H616 use a
different bit for the SIDDQ control.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
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.
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>
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>
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 is now handled automatically by the pinctrl driver.
Cover-letter:
sunxi: Add and use a pinctrl driver
This series resolves some longstanding TODOs by implementing a pinctrl
driver for sunxi platforms and converting DM drivers to use it.
I am sending this as RFC because I have only tested this on a limited
amount of hardware, and there are quite a few magic numbers involved,
so it is likely I missed something. Also, I'm not sure the how best to
split up the patches by subsystem, or if that is necessary.
This series depends on the sunxi-gpio series I just sent.
END
Series-to: sunxi
Series-to: sjg
Series-prefix: RFC
Signed-off-by: Samuel Holland <samuel@sholland.org>
When the DM_I2C driver is loaded, the pin setup is done automatically
from the device tree by the pinctrl driver.
Clean up the code in the process: remove #ifdefs and recognize that the
pin configuration is the same for all sun8i/sun50i SoCs, not just those
which select CONFIG_MACH_SUN8I.
Signed-off-by: Samuel Holland <samuel@sholland.org>
When the DM_I2C driver is loaded, the pin setup is done automatically
from the device tree by the pinctrl driver.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Where multiple options were available, the one matching board.c and the
device trees was chosen.
Pin lists and mux values were taken from the Linux drivers.
Signed-off-by: Samuel Holland <samuel@sholland.org>
This includes UART0 and R_UART (s_uart) on all supported platforms, plus
the additional UART configurations from arch/arm/mach-sunxi/board.c.
Pin lists and mux values were taken from the Linux drivers.
Signed-off-by: Samuel Holland <samuel@sholland.org>
The sunxi pinctrl hardware has bias and drive control. Add driver
support for configuring those options.
Signed-off-by: Samuel Holland <samuel@sholland.org>
The pinmux command uses this function to display pinmux status.
Since the driver cannot map pin numbers to a list of supported
functions, only functions which are common across all pins can be
reported by name.
Signed-off-by: Samuel Holland <samuel@sholland.org>
