This PMIC is used with SoCs which need a combination of BUCKs and LDOs. The
driver supports probing and basic register access. It supports the standard
device tree binding and supports driver model. A regulator driver can be
provided also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
The TPS65090 has 7 FETs which are modelled as regulators. This allows them
to be controlled by drivers easier, accessed through the 'regulator' command
and used by other drivers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
The existing TPS65090 driver does not support driver model. Add a new one
that does. This can be used as a base for a regulator driver also. It uses
the standard device tree binding.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
As a debugging aid, allow UART3 to be used as a debug UART in SPL. This
is a precursor to proper UART support, which requires a substantial
refactor.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a debug UART implementation for this serial driver. It does not set up
pinmux automatically - this must be done before calling debug_uart_init().
Signed-off-by: Simon Glass <sjg@chromium.org>
The debug UART code needs to perform the same init as the normal UART
driver. In preparation for this, move the init code into two functions, one
for the basic init and one for setting the baud rate. This will make adding
debug UART support easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a driver to support the special LDO access used by spring. This is a
custom method in the cros_ec protocol - it does not use an I2C
pass-through.
There are two implementation choices:
1. Write a special LDO driver which can talk across the EC. Duplicate all
the logic from TPS65090 for retrying when the LDO fails to come up.
2. Write a special I2C bus driver which pretends to be a TPS65090 and
transfers reads and writes using the LDO message.
Either is distasteful. The latter method is chosen since it results in less
code duplication and a fairly simple (30-line) implementation of the core
logic.
The crosec 'ldo' subcommand could be removed (since i2c md/mw will work
instead) but is retained as a convenience.
Signed-off-by: Simon Glass <sjg@chromium.org>
The Chrome OS EC supports tunnelling through to an I2C bus on the EC. This
currently uses a copy of the I2C command code and a special 'crosec'
sub-command.
With driver model we can define an I2C bus which tunnels through to the EC,
and use the normal 'i2c' command to access it. This simplifies the code and
removes some duplication.
Add an I2C driver which tunnels through to the EC. Adjust the EC code to
support binding child devices so that it can be set up. Adjust the existing
I2C xfer function to fit driver model better.
For now the old code remains to allow things to still work. It will be
removed in a later patch once the new flow is fully enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
On pit and pi the TPS65090 regulator is connected only to the EC and we
must use a tunnel to get to it. The existing U-Boot support relies on a
special driver. Add a tunnel definition so that the new device-model
TPS65090 driver can be used unmodified.
Signed-off-by: Simon Glass <sjg@chromium.org>
Snow and smdk5250 use a max77686 PMIC. We have a driver for this, so add
the relevant node to the device tree so it can be used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
The kernel uses upper case for I2C unit addresses. Follow the same
convention to reduce differences.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
The existing driver model implementation uses the old non-driver-model code
to operate, but has become impossibly tangled as a result. The actual
algorithm is quite simple.
Also the normal-speed and high-speed buses are quite different and it
doesn't seem that useful to put them in the same driver.
Finally, there is a bug which breaks communication with the Maxim sound
codec and may cause problems with other device.
Rewrite the driver model code for normal-speed operation so that it is
easier to understand, and fix the bug. Add a TODO to split the drivers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
This function should not use mixed case, and it is simpler to use
clrbits_le32() when clearing bits. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
While I2C supports multi-master buses this is difficult to get right.
The implementation on the master side in software is quite complex.
Clock-stretching and the arbitrary time that an I2C transaction can take
make it difficult to share the bus fairly in the face of high traffic.
When one or more masters can be reset independently part-way through a
transaction it is hard to know the state of the bus.
This driver provides a scheme based on two 'claim' GPIOs, one driven by the
AP (Application Processor, meaning the main CPU) and one driven by the EC
(Embedded Controller, a small CPU aimed at handling system tasks). With
these they can communicate and reliably share the bus. This scheme has
minimal overhead and involves very little code. It is used on snow to
permit the EC and the AP to share access to the main system PMIC and
battery. The scheme can survive reboots by either side without difficulty.
This scheme has been tested in the field with millions of devices.
Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO,
meaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology
is used by the device tree bindings in Linux also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new I2C_MUX uclass. Devices in this class can multiplex between
several I2C buses, selecting them one at a time for use by the system.
The multiplexing mechanism is left to the driver to decide - it may be
controlled by GPIOs, for example.
The uclass supports only two methods: select() and deselect().
The current mux state is expected to be stored in the mux itself since
it is the only thing that knows how to make things work. The mux can
record the current state and then avoid switching unless it is necessary.
So select() can be skipped if the mux is already in the correct state.
Also deselect() can be made a nop if required.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes it is useful to be able to transfer a raw I2C message. This
happens when the chip address needs to be set manually, or when the data to
be sent/received is in another buffer.
Add a function to provide access to this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
Move the flags and struct definitions higher in the file so that we can
reference them with functions declared in the driver model section.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
Add a way to dump the contents of an I2C message for debugging purposes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
It is common for one node to reference another via a phandle. Add support
for obtaining an attached device by this method. As an example, a node may
have a 'power-supply' property which references a regulator, allowing the
driver to turn on its power.
Signed-off-by: Simon Glass <sjg@chromium.org>
The following commit enforces CONFIG_DM_ETH for USB Ethernet which
breaks any board using CONFIG_USB_HOST_ETHER without CONFIG_DM_ETH
which this patch fixes.
commit 69559093f6
dm: usb: Avoid using USB ethernet with CONFIG_DM_USB and no DM_ETH
Tested on Colibri T20/T30 as well as Apalis T30 with
CONFIG_USB_HOST_ETHER and CONFIG_USB_ETHER_ASIX enabled and a LevelOne
USB-0301 ASIX AX88772 dongle.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Simon Glass <sjg@chromium.org>
Document the development flow on figuring out PIRQ information
during the U-Boot porting.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
The code in question polls an USB port status via USB_REQ_GET_STATUS
to determine whether there is a device on the port or not. The way to
figure that out is to check two bits. Those are wPortChange[0] and
wPortStatus[0].
The wPortChange[0] indicates whether some kind of a connection status
change happened on a port (a device was plugged or unplugged). The
wPortStatus[0] bit indicates the status of the connection (plugged or
unplugged).
The current code tests whether wPortChange[0] == wPortStatus[0] and
if that's the case, considers the loop polling for the presence of a
USB device on port finished.
This works for most USB sticks, since they come up really quickly and
trigger the USB port change detection before the first iteration of the
detection loop happens. Thus, both wPortChange[0] and wPortStatus[0]
are set to 1 and thus equal. The loop is existed in it's first iteration
and the stick is detected correctly.
The problem is with some obscure USB sticks, which take some time before
they pop up on the bus after the port was enabled. In this case, both
the wPortChange[0] and wPortStatus[0] are 0. They are equal again, so
the loop again exits in the first iteration, but this is incorrect, as
such USB stick didn't have the opportunity to get detected on the bus.
Rework the code such, that it checks for wPortChange[0] first to test
if any connection change happened at all. If no change occured, keep
polling. If a change did occur, test the wPortStatus[0] to see there is
some device present on the port and only if this is the case, break out
of the polling loop.
This patch also trims down the duration of the polling loop from 10s
per port to 1s per port. This is still annoyingly long, but there is
no better option in case of U-Boot unfortunatelly. This change will
most likely increase the duration of 'usb start' on some platforms,
but this is needed to fix a bug.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Hans de Goede <hdegoede@redhat.com>
This patch fixes operation of our on-board AX88772B chip without EEPROM
but with a ethaddr coming from the regular U-Boot environment. This is
a forward port of some remaining parts initially implemented by
Antmicro.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Marek Vasut <marex@denx.de>
usb_stor_reset is only defined when USB storage support is enabled, thus the
function is not declared when such support is missing.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
This adds some config options to the sunxi-common config to enable the USB
download gadget and the fastboot and USB mass storage functions.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Currently, the second use of a gadget will fail, while the first one works.
Forcing the EP0 at every enable fix this issue.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Now that some things were updated in Kconfig, they should be reflected on the
sunxi-common config too.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Now that the musb-new driver has a Kconfig, we can move Kconfig options to
enable controllers to it, so that it's easier in e.g. menuconfig.
In addition, this allows declaring support for USB_MUSB_HOST/GADGET in
defconfigs instead of the USB_MUSB_SUNXI controller, that will get selected
automatically when needed.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Having MUSB_HOST and MUSB_GADGET in Kconfig allows more flexibility with regard
to what Kconfig options to enable, such as USB_STORAGE or USB_KEYBOARD.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
USB-related options are usually prefixed with CONFIG_USB and platform-specific
adaptation for the MUSB controller already have a CONFIG_USB_MUSB prefix, so
this switches all MUSB-related options to a CONFIG_USB_MUSB prefix, for
consistency.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
There is no particular reason why the USB Kconfig option should be specific to
host mode. In prevision of adding MUSB host and gadget to Kconfig, this moves
the title and help message of the USB Kconfig option to a more generic format.
Adding comments to the usb Kconfig allows for a better separation and more
readability in generated configs and in menuconfig.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
The USB_ARCH_HAS_HCD currently serves no purpose and adds some confusion to the
required Kconfig options that are required to have USB support.
Dropping it makes things easier and doesn't break anything, since it was unused
anyways.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
This patch makes the dwc2 controller like ehci / ohci / xhci controllers
by calling the board_usb_init() function from usb_lowlevel_init.
This can then be implemented by specific platforms to initialise
their USB hardware (phys / clocks etc).
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Add some documentation on the EFI implementation in U-Boot.
Signed-off-by: Ben Stoltz <stoltz@google.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We cannot use this driver when running from EFI as we have no direct hardware
access. In fact coreboot uses a different driver which uses tables provided
by coreboot. So far it does not seem possible to use a normal video driver
when booting from EFI.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Disable a few things which interfere with the EFI init. This allows QEMU to
to boot into EFI, load a U-Boot payload then boot to the U-Boot prompt.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Disable a few things which interfere with the EFI init. This allows the
Minnowboard MAX to boot into EFI, load a U-Boot payload then boot to the
U-Boot prompt.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When U-Boot is running from EFI some of the x86 init is replaced with
EFI-specific init. For example, since DRAM has already been set up, we only
need to find it, not init it. Add these functions so that boards can easily
allow booting from EFI if required.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When U-Boot runs as an EFI payload it needs to avoid setting up the CPU
again. Also U-Boot currently does not handle interrupts for many devices, so
run with interrupts disabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The EFI memory map is passed from the stub to U-Boot in a table. Add a
command to display it in a vaguely readable fashion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested on QEMU
Tested-by: Bin Meng <bmeng.cn@gmail.com>
The EFI stub can pass a table to U-Boot with information about the memory map
Potentially other things will follow. Add a way to access this table.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The EFI stub provides information to U-Boot in a table. This includes the
memory map which is needed to decide where to relocate U-Boot. Collect this
information in the early init code and store it in global_data.
Fix up the BIST code at the same time since we don't have it when booting
from EFI and can assume it is 0.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Most EFI implementations use 64-bit. Add a way to build U-Boot as a 64-bit
EFI payload. The payload unpacks a (32-bit) U-Boot and starts it. This can
be enabled for x86 boards at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
Improvements to how the payload is built:
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
The procedure to drop from 64-bit mode to 32-bit is a bit messy. Add a
function to take care of it. It requires identity-mapped pages and that
the calling code is running below 4GB.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Rather than add these as open-coded values, create an enum with the commonly
used flags.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
