Replace infracfg clk ID with upstream linux version.
Add some missing clk for PWM3 and for PCIe. The same format is used here
with the factor first, then mux and then gates.
To correctly reference the gates in clk_gate function, define the
gates_offs value in clk_tree now that they are at an offset from mux and
factor.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Now that we can have advanced parent handling for mux, we can drop
spurious infracfg 1/1 factor. This is in preparation to make the clk
ID match the ID in upstream include for mt7981.
Drop the factor entry from mt7981-clk.h and reference to them in
mt7981.dtsi. Muxes and gates are updated to reference the topckgen clk
following how it's done in upstream kernel linux. Add relevant clk type
flag in clk_tree for infracfg and topckgen.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add missing clock for infra_ipcie_pipe to make PCIe correctly work. This
clock is a parent of the fixed clock from topckgen cb_cksq_40m.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Christian Marangi <ansuelsmth@gmail.com> says:
These are all the required patches to migrate clk and correctly support
OF_UPSTREAM. This will align the clk index to upstream to support the same
clk implementation with downstream and upstream DTS.
Define id_offs_map and use clk ID form upstream linux kernel to have a
1:1 match for the TOPCKGEN clock and permit usage of OF_UPSTREAM with
upstream dtsi.
For all the gate clock, the clk ID starts from 1 instead of zero. Define
an additional clock tree for them and set the .gates_offs to 1 to
account for this.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
host->quirks field is only used internally in exynos_dw_mmc.c driver.
To avoid cluttering the scope of struct dwmci_host, move quirks field
into Exynos driver's chip data, where it can be statically defined.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Some chips like Exynos4412 have fixed internal CIU clock divider.
Instead of reading it from non-standard "div" dts property, store its
value in the driver internally, in static chip data associated with
corresponding compatible. This makes it possible to avoid using
host->div for storing it, so the latter can be removed safely. Also
create a helper function called exynos_dwmmc_get_ciu_div() for getting
the current div value: in case the fixed div is provided in the chip
data it will be used, otherwise the current div value is being read from
CLKSEL register.
The insights for this change were taken from dw_mmc-exynos.c driver in
Linux kernel.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Rework kernel-doc comments in dwmmc.h header so it's actually possible
to generate a proper documentation from it usin scripts/kernel-doc
script, with no errors.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Replace fifoth_val property with its fifo-depth counterpart in all DW
MMC drivers. fifo-depth is a common property used in upstream Linux
kernel. The FIFOTH register value will be calculated using fifo-depth
value in DW MMC core (dw_mmc.c). This change reduces code duplication in
platform drivers, and pulls common FIFOTH register value calculation
into core dw_mmc driver where it belongs.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Some DW MMC blocks (e.g. those on modern Exynos chips) support 64-bit
DMA addressing mode. 64-bit DW MMC variants differ from their 32-bit
counterparts:
- the register layout is a bit different (because there are additional
IDMAC registers present for storing upper part of 64-bit addresses)
- DMA descriptor structure is bigger and different from 32-bit one
Introduce all necessary changes to enable support for 64-bit DMA capable
DW MMC blocks. Next changes were made:
1. Check which DMA address mode is supported in current IP-core
version. HCON register (bit 27) indicates whether it's 32-bit or
64-bit addressing. Add boolean .dma_64bit_address field to struct
dwmci_host and store the result there. dwmci_init_dma() function is
introduced for doing so, which is called on driver's init.
2. Add 64-bit DMA descriptor (struct dwmci_idmac64) and use it in
dwmci_prepare_desc() in case if .dma_64bit_address field is true.
A new dwmci_set_idma_desc64() function was added for populating that
descriptor.
3. Add registers for 64-bit DMA capable blocks. To make the access to
IDMAC registers universal between 32-bit / 64-bit cases, a new
struct dwmci_idmac_regs (and corresponding host->regs field) was
introduced, which abstracts the hardware by being set to
appropriate offset constants on init. All direct calls to IDMAC
registers were correspondingly replaced by accessing host->regs.
4. Allocate and use 64-bit DMA descriptors buffer in case when IDMAC
is 64-bit capable. Extract all the code (except for the IDMAC
descriptors buffer allocation) from dwmci_send_cmd() to
dwmci_send_cmd_common(), so that it's possible to keep IDMAC
buffer (either 32-bit or 64-bit) on stack during send_cmd routine.
The insights for this implementation were taken from Linux kernel DW MMC
driver.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
struct idmac is only used in dw_mmc.c, so move it there from dwmmc.h to
avoid cluttering the interface in the header.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
bootstage_get_size() returns the total size of the data structure
including associated records.
When copying from gd->bootstage, only the allocation size of gd->bootstage
must be used. Otherwise too much memory is copied.
This bug caused no harm so far because gd->new_bootstage is always
large enough and reading beyond the allocation length of gd->bootstage
caused no problem due to the U-Boot memory layout.
Fix by using the correct size and perform the initial copy directly
in bootstage_relocate() to have the whole relocation process in the
same function.
Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Simon Glass <sjg@chromium.org>
Evaluate the filesystem incompat and ro_compat bit fields to judge
whether the filesystem can be read or written.
For the read side only a scary warning is shown so far.
I'd love to abort mounting too, but I fear this will break some setups
where the driver works by chance.
Signed-off-by: Richard Weinberger <richard@nod.at>
Currently, the power_init_board() function is not executed because
CONFIG_POWER_LEGACY is not selected.
Convert to PMIC driver model, which allows removing board I2C code in
favor of the I2C driver model.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Part of the upower management was included in a previous commit [1].
This patch only adds the bits required to properly parse a config file
that would include the binary as follows:
IMAGE PWR upower.bin
[1] 6ec65c8558 (tools: image: support i.MX93)
Signed-off-by: Gary Bisson <bisson.gary@gmail.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Now that this is always 1, remove it and the associated dead code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Now that this is always 0, remove it and the associated dead code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
These functions are 11 years old and are only used by one board. Drop
them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Only one board uses this option and it is very old. Let's drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
This is very old, predating even the legacy I2C support, so drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
This is very old, predating even the legacy I2C support, so drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
This option is very old and the migration deadline was years ago. Drop
it so that the I2C system can be simplified.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
This is used by a few boards but we are years past the migration date,
so let's drop it now.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
This is only used by devkit3250 which is being removed. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
The Rock 5 ITX is a board in ITX form factor using the RK3588 SoC
It can be powered either by 12V, ATX power-supply or PoE.
Notable peripherals are the 4 SATA ports, M.2 M-Key slot, M.2 E-key slot,
2*2.5Gb PCIe-connected Ethernet NICs.
Display options are 2*HDMI, DP via USB-c, eDP + 2*DSI via PCB connectors.
USB ports are 4*USB3 + 2*USB2 on the back panel and 2-port front-panel
connector.
Schematics for the board can be found on
- https://dl.radxa.com/rock5/5itx/radxa_rock_5_itx_X1100_schematic.pdf
- https://dl.radxa.com/rock5/5itx/v1110/radxa_rock_5itx_v1110_schematic.pdf
The naming scheme with the dashes follows Dragan's comment on the mainline
devicetree commit:
"the name of this board deviates from the standard Radxa naming scheme,
which is something like "ROCK <number><letter>" thus, "rock-5a" is
fine, but it should be "rock-5-itx", simply because there's a space
between "5" and "ITX" in "ROCK 5 ITX"
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Simon Glass <sjg@chromium.org> says:
Universal Payload (UPL) is an Industry Standard for firmware
components[1]. UPL is designed to improve interoperability within the
firmware industry, allowing mixing and matching of projects with less
friction and fewer project-specific implementations. UPL is
cross-platform, supporting ARM, x86 and RISC-V initially.
This series provides some initial support for this, targeting 0.9.1 and
sandbox only.
Features still to come include:
- Support for architectures
- FIT validation
- Handoff validation
- Interoperability tests
Specify the FIT and include information about each loaded image, as
required by the UPL handoff.
Write the UPL handoff into the bloblist before jumping to the next phase.
Control this using a runtime flag to avoid conflicting with other
handoff mechanisms.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the basic code to create a handoff structure in SPL, so it can be
passed to the next phase. For now this is not plumbed in.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a 'upl' command to work with Universal Payload features. For now it
only supports reading and writing a handoff structure.
Signed-off-by: Simon Glass <sjg@chromium.org>
Universal Payload provides a standard way of handing off control between
two firmware phases. Add support for reading the handoff information into
a structure.
Signed-off-by: Simon Glass <sjg@chromium.org>
The existing API for these functions is different from the rest of
U-Boot, in that any error code must be obtained from the errno variable
on failure. This variable is part of the C library, so accessing it
outside of the special 'sandbox' shim-functions is not ideal.
Adjust the API to return an error code, to avoid this. Update existing
uses to check for any negative value, rather than just -1.
Signed-off-by: Simon Glass <sjg@chromium.org>
Most Rockchip aarch64 targets have now migrated to use OF_UPSTREAM,
however a few of the old dtsi and dt-bindings files still remain.
Remove remaining common dtsi and header files that can be included
directly from dts/upstream to prevent possible issues when future tags
from devicetree-binding is merged. No changes is expected with this.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
The commit f087f7fd27 ("rockchip: px30/rk3326: migrate to
OF_UPSTREAM") migrated px30/rk3326 boards to use OF_UPSTREAM, however
the soc dtsi and dt-bindings files remained.
Remove the remaining px30/rk3326 soc dtsi and dt-bindings to ensure the
files from dts/upstream is used.
The gpio-ranges props is moved to u-boot.dtsi files and a ethernet0
alias is added to px30-firefly, they are missing in the dts/upstream
files. No changes are expected with this.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
UBI block is an virtual device, that runs on top
of the MTD layer. The blocks are UBI volumes.
Intended to be used in combination with other MTD
drivers.
Despite the fact that it, like mtdblock abstraction,
it used with UCLASS_MTD, they can be used together
on the system without conflicting. For example,
using bcb command:
# Trying to load bcb via mtdblock:
$ bcb load mtd 0 mtd_partition_name
# Trying to load bcb via UBI block:
$ bcb load ubi 1 ubi_volume_name
User always must attach UBI layer (for example, using
ubi_part()) before using UBI block device.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Introduce ubi_volume_offset_write() helper, which
allow to write to ubi volume with specified offset.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
MTD block - abstraction over MTD subsystem, allowing
to read and write in blocks using BLK UCLASS.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Simon Glass <sjg@chromium.org> says:
This data structure provides a list of pointers / array of structures.
I was planning to use it for the lmb restructure, to allow it to
support any number of entries, but then I gave up on it.
There are quite a few places in U-Boot where such a list would be
useful, since it supports growing the array.
[...]
Example:
struct my_struct obj;
struct my_struct *ptr = alist_add(&lst, &obj, struct my_struct);
// now ptr is in the list
[trini: Reword the cover letter slightly, do not merge the RFC portion]
In various places it is useful to have an array of structures, but allow
it to grow. In some cases we work around it by setting maximum number of
entries, using a Kconfig option. In other places we use a linked list,
which does not provide for random access and can complicate the code.
Introduce a new data structure, which is a variable-sized list of structs
each of the same, pre-set size. It provides O(1) access and is reasonably
efficient at expanding linearly, since it doubles in size when it runs out
of space.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add driver model support by using the uclass UCLASS_USB_GADGET_GENERIC.
Disable local usb_gadget_register_driver()/usb_gadget_unregister_driver()
implementation which is implemented in udc-core.c when DM_USB_GADGET
is enabled.
Replace dm_usb_gadget_handle_interrupts() with handle_interrupts ops
when DM_USB_GADGET is enabled.
Disable legacy struct usba_udc controller as controller point is extracted
from udevice private data with DM.
Disable legacy usba_udc_probe() to avoid conflict with DM when it's
enabled.
Compared to Linux driver only supported devices' DT bindings are included
(sorted as Linux driver)
Signed-off-by: Zixun LI <admin@hifiphile.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20240725153204.358925-8-admin@hifiphile.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
