| Age | Commit message (Collapse) | Author |
|---|
|
This new flag can be added to DM device drivers, which need to do some
final configuration before U-Boot exits and the OS (e.g. Linux) is
started. The remove functions of those drivers will get called at
this stage to do these last-stage configuration steps.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
|
|
The PHY framework provides a set of APIs to control a PHY. This API is
derived from the linux version of the generic PHY framework.
Currently the API supports init(), deinit(), power_on, power_off() and
reset(). The framework provides a way to get a reference to a phy from the
device-tree.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This is a simple uclass for Watchdog Timers. It has four operations:
start, restart, reset, stop. Drivers must implement start, restart and
stop operations, while implementing reset is optional: It's default
implementation expires watchdog timer in one clock tick.
Signed-off-by: Maxim Sloyko <maxims@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
If the system is running PSCI firmware, the System Reset function
(func ID: 0x80000009) is supposed to be handled by PSCI, that is,
the SoC/board specific reset implementation should be moved to PSCI.
U-Boot should call the PSCI service according to the arm-smccc
manner.
The arm-smccc is supported on ARMv7 or later. Especially, ARMv8
generation SoCs are likely to run ARM Trusted Firmware BL31. In
this case, U-Boot is a non-secure world boot loader, so it should
not be able to reset the system directly.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
The new function dm_remove_devices_flags() is intented for driver specific
last-stage cleanup operations before the OS is started. This patch adds
this functionality and hooks it into the common device_remove()
function.
Drivers wanting to use this feature for some last-stage removal calls,
need to add one of the DM_REMOVE_xx flags to their driver .flags.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This patch adds the flags parameter to device_remove() and changes all
calls to this function to provide the default value of DM_REMOVE_NORMAL
for "normal" device removal.
This is in preparation for the driver specific pre-OS (e.g. DMA
cancelling) remove support.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Documentation says that we're returning true/false, not 1/0 so adapt
the function to return actual booleans.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Right now the u-boot,dm-pre-reloc flag will make each marked node
always appear in both spl and tpl. But systems needing an additional
tpl might have special constraints for each, like the spl needing to
be very tiny.
So introduce two additional flags to mark nodes for only spl or tpl
environments and introduce a function dm_fdt_pre_reloc to automate
the necessary checks in code instances checking for pre-relocation
flags.
The behaviour of the original flag stays untouched and still marks
a node for both spl and tpl.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
|
|
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
All sata based drivers are bind and corresponding block
device is created. Based on this find_scsi_device() is able
to get back block device based on scsi_curr_dev pointer.
intr_scsi() is commented now but it can be replaced by calling
find_scsi_device() and scsi_scan().
scsi_dev_desc[] is commented out but common/scsi.c heavily depends on
it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol
is reassigned to a block description allocated by uclass.
There is only one block description by device now but it doesn't need to
be correct when more devices are present.
scsi_bind() ensures corresponding block device creation.
uclass post_probe (scsi_post_probe()) is doing low level init.
SCSI/SATA DM based drivers requires to have 64bit base address as
the first entry in platform data structure to setup mmio_base.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This reverts commit 3edc0c252257e4afed163a3a74aba24a5509b198, reversing
changes made to bb135a0180c31fbd7456021fb9700b49bba7f533.
|
|
All sata based drivers are bind and corresponding block
device is created. Based on this find_scsi_device() is able
to get back block device based on scsi_curr_dev pointer.
intr_scsi() is commented now but it can be replaced by calling
find_scsi_device() and scsi_scan().
scsi_dev_desc[] is commented out but common/scsi.c heavily depends on
it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol
is reassigned to a block description allocated by uclass.
There is only one block description by device now but it doesn't need to
be correct when more devices are present.
scsi_bind() ensures corresponding block device creation.
uclass post_probe (scsi_post_probe()) is doing low level init.
SCSI/SATA DM based drivers requires to have 64bit base address as
the first entry in platform data structure to setup mmio_base.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Series-changes: 2
- Use CONFIG_DM_SCSI instead of mix of DM_SCSI and DM_SATA
Ceva sata has never used sata commands that's why keep it in
SCSI part only.
- Separate scsi_scan() for DM_SCSI and do not change cmd/scsi.c
- Extend platdata
Series-changes: 3
- Fix scsi_scan return path
- Fix header location uclass-internal.h
- Add scsi_max_devs under !DM_SCSI
- Add new header device-internal because of device_probe()
- Redesign block device creation algorithm
- Use device_unbind in error path
- Create block device with id and lun numbers (lun was there in v2)
- Cleanup dev_num initialization in block device description
with fixing parameters in blk_create_devicef
- Create new Kconfig menu for SATA/SCSI drivers
- Extend description for DM_SCSI
- Fix Kconfig dependencies
- Fix kernel doc format in scsi_platdata
- Fix ahci_init_one - vendor variable
Series-changes: 4
- Fix Kconfig entry
- Remove SPL ifdef around SCSI uclass
- Clean ahci_print_info() ifdef logic
|
|
The currently available functions accessing the 'reg' property of a
device only retrieve the address. Sometimes its also necessary to
retrieve the size described by the 'reg' property. This patch adds
the new function dev_get_addr_size_index() which retrieves both,
the address and the size described by the 'reg' property.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
When CONFIG_SPL_STACK_R is enabled, and spl_init() is called before
board_init_r(), spl_relocate_stack_gd() will move global_data to a new
place in memory. This affects driver model since it uses a list for the
uclasses. Unless this is updated the list will become invalid. When
looking for a non-existent uclass, such as when adding a new one, the loop
in uclass_find() may continue forever, thus causing a hang.
Add a function to correct this rather obscure bug.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Optional driver model handling integration.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Marek Vasut <marex@denx.de>
|
|
It is useful in debug() statements to display the name of the uclass for a
device. Add a simple function to provide this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
On the raspberry pi, you can disable the serial port to gain dynamic frequency
scaling which can get handy at times.
However, in such a configuration the serial controller gets its rx queue filled
up with zero bytes which then happily get transmitted on to whoever calls
getc() today.
This patch adds detection logic for that case by checking whether the RX pin is
mapped to GPIO15 and disables the mini uart if it is not mapped properly.
That way we can leave the driver enabled in the tree and can determine during
runtime whether serial is usable or not, having a single binary that allows for
uart and non-uart operation.
Signed-off-by: Alexander Graf <agraf@suse.de>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The ethoc device can be configured to have a private memory region
instead of having access to the main memory. In that case egress packets
must be copied into that memory for transmission and pointers to that
memory need to be passed to net_process_received_packet or returned from
the recv callback.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
Extract reusable parts from ethoc_init, ethoc_set_mac_address,
ethoc_send and ethoc_receive, move the rest under #ifdef CONFIG_DM_ETH.
Add U_BOOT_DRIVER, eth_ops structure and implement required methods.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
|
|
Many SoCs allow power to be applied to or removed from portions of the SoC
(power domains). This may be used to save power. This API provides the
means to control such power management hardware.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
We currently use dm_scan_fdt_node() to bind devices. It is an internal
function and it requires the caller to know whether we are pre- or post-
relocation.
This requirement has become quite common in drivers, so the current function
is not ideal.
Add a new function with fewer arguments, that does not require internal
headers. This can be used directly as a post_bind() method if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Some SoCs have a single clock device. Provide a way to find it given its
driver name. This is handled by the linker so will fail if the name is not
found, avoiding strange errors when names change and do not match. It is
also faster than a string comparison.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The MXC UART IP can be run in DTE or DCE mode. This depends on the
board wiring and the pinmux used and hence is board specific. This
extends platform data with a new field to choose wheather DTE
mode shall be used.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Devices which use of-platdata have their own platdata. However, in many
cases the driver will have its own auto-alloced platdata, for use with the
device tree. The ofdata_to_platdata() method converts the device tree
settings to platdata.
With of-platdata we would not normally allocate the platdata since it is
provided by the U_BOOT_DEVICE() declaration. However this is inconvenient
since the of-platdata struct is closely tied to the device tree properties.
It is unlikely to exactly match the platdata needed by the driver.
In fact a useful approach is to declare platdata in the driver like this:
struct r3288_mmc_platdata {
struct dtd_rockchip_rk3288_dw_mshc of_platdata;
/* the 'normal' fields go here */
};
In this case we have dt_platadata available, but the normal fields are not
present, since ofdata_to_platdata() is never called. In fact driver model
doesn't allocate any space for the 'normal' fields, since it sees that there
is already platform data attached to the device.
To make this easier, adjust driver model to allocate the full size of the
struct (i.e. platdata_auto_alloc_size from the driver) and copy in the
of-platdata. This means that when the driver's bind() method is called,
the of-platdata will be present, followed by zero bytes for the empty
'normal field' portion.
A new DM_FLAG_OF_PLATDATA flag is available that indicates that the platdata
came from of-platdata. When the allocation/copy happens, the
DM_FLAG_ALLOC_PDATA flag will be set as well. The dtoc tool is updated to
output the platdata_size field, since U-Boot has no other way of knowing
the size of the of-platdata struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This is a flag. Adjust the name to be consistent with the other flags.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
Some uclass ids are out of order. Per the comments, sort them
in alphabetical order.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
This API helps to map physical register addresss pace of device to
virtual address space easily. Its just a wrapper around map_physmem()
with MAP_NOCACHE flag.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Suggested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jagan Teki <jteki@openedev.com>
|
|
A reset controller is a hardware module that controls reset signals that
affect other hardware modules or chips.
This patch defines a standard API that connects reset clients (i.e. the
drivers for devices affected by reset signals) to drivers for reset
controllers/providers. Initially, DT is the only supported method for
connecting the two.
The DT binding specification (reset.txt) was taken from Linux kernel
v4.5's Documentation/devicetree/bindings/reset/reset.txt.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
A mailbox is a hardware mechanism for transferring small message and/or
notifications between the CPU on which U-Boot runs and some other device
such as an auxilliary CPU running firmware or a hardware module.
This patch defines a standard API that connects mailbox clients to mailbox
providers (drivers). Initially, DT is the only supported method for
connecting the two.
The DT binding specification (mailbox.txt) was taken from Linux kernel
v4.5's Documentation/devicetree/bindings/mailbox/mailbox.txt.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
The current reset API implements a method to reset the entire system.
In the near future, I'd like to introduce code that implements the device
tree reset bindings; i.e. the equivalent of the Linux kernel's reset API.
This controls resets to individual HW blocks or external chips with reset
signals. It doesn't make sense to merge the two APIs into one since they
have different semantic purposes. Resolve the naming conflict by renaming
the existing reset API to sysreset instead, so the new reset API can be
called just reset.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
This will allow a driver's bind function to use the driver data. One
example is the Tegra186 GPIO driver, which instantiates child devices
for each of its GPIO ports, yet supports two different HW instances each
with a different set of ports, and identified by the udevice_id .data
field.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Provide an api to check whether the given device or machine is
compatible with the given compat string which helps in making
decisions in drivers based on device or machine compatible.
Idea taken from Linux.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
Some devices have a name that is stored in allocated memory. At present
there is no mechanism to free this memory when the device is unbound.
Add a device flag to track whether a name is allocated and a function to
add the flag. Free the memory when the device is unbound.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This started as 'ahci' and was renamed to 'disk' during code review. But it
seems that this is too generic. Now that we have a 'blk' uclass, we can use
that as the generic piece, and revert to ahci for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Boards can now use DM serial driver, or still legacy mcf uart
driver version.
Signed-off-by: Angelo Dureghello <angelo@sysam.it>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
On some platforms (e.g. x86), the return value of dev_get_addr() can't
be assigned to a pointer type variable directly. As there might be a
difference between the size of fdt_addr_t and the pointer type. On
x86 for example, "fdt_addr_t" is 64bit but "void *" only 32bit. So
assigning the register base directly in dev_get_addr() results in this
compilation warning:
warning: cast to pointer from integer of different size
This patch introduces the new function dev_get_addr_ptr() that
returns a pointer to the 'reg' address that can be used by drivers
in this case.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
This function parses the reg property based on an index found in the
reg-names property. This is required for bindings that are written
using reg-names rather than hard-coding indices in reg.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Qualcom processors use proprietary bus to talk with PMIC devices -
SPMI (System Power Management Interface).
On wiring level it is similar to I2C, but on protocol level, it's
multi-master and has simple autodetection capabilities.
This commit adds simple uclass that provides bus read/write interface.
Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
The RPi3 typically uses the regular UART for high-speed communication with
the Bluetooth device, leaving us the mini UART to use for the serial
console. Add support for this UART so we can use it.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
|
|
For Raspberry Pi, we had the input clock rate to the pl011 fixed in
the rpi.c file, but it may be changed by firmware due to user changes
to config.txt. Since the firmware always sets up the uart (default
115200 output unless the user changes it), we can just skip our own
uart init to simplify the boot process and more reliably get serial
output.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Stephen Warren <swarren@wwwdotorg.org>
|
|
Add a uclass for block devices. These provide block-oriented data access,
supporting reading, writing and erasing of whole blocks.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
|
|
A common pattern is to call uclass_first_device() and then check if it
actually returns a device. Add a new function which does this, returning
an error if there are no devices in that uclass.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This patch adds support for stm32f7 family usart peripheral.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Implement a DMA uclass so that the devices like ethernet, spi,
mmc etc can offload the data transfers from/to the device and
memory.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jteki@openedev.com>
|
|
For testing it is useful to be able to select the font size and the console
driver for sandbox. Add this information to platform data and copy it to
the video device when needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This function is not used as the use case for it did not eventuate. Remove
it to avoid confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Add a uclass ID for a disk controller. This can be used by AHCI/SATA or
other controller types. There are no operations and no interface so far,
but it is possible to probe a SATA device.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Add a uclass for the northbridge / SDRAM controller found on some older
Intel chipsets.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
