Add support to Orise Tech OTM8009A display on stm32f469-disco board.
It was necessary to retrieve the framebuffer address from the device tree
because the address returned by the video-uclass driver pointed to a memory
area that was not usable.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Set pllsaidivr only if the PLLSAIR output frequency is an exact multiple
of the pixel clock rate. Otherwise, we search through all combinations
of pllsaidivr * pllsair and use the one which gives the rate closest to
requested one.
Fixes: 5e993508cb ("clk: clk_stm32f: Add set_rate for LTDC clock")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
The value to be written to the register must be appropriately shifted,
as is correctly done in other parts of the code.
Fixes: 5e993508cb ("clk: clk_stm32f: Add set_rate for LTDC clock")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
- Add TPM support for venice boards
- Add networking support for imx93-evk
- Enable TCP, IPv6, wget for DHCOM and Data Modul boards
- Enable fastboot support for Toradex boards
- Allow pico-imx7d to boot from SD
- Enable fastboot for beacon imx8m beacon boards, disabled
SYS_CONSOLE_IS_IN_ENV
- Fix mxsboot to prevent NAND blocks being reported as bad
- Add imx8mm PWM clock support
- Several devicetree syncs with the kernel
- Add support for i.MX8MP Polyhex Debix Model A SBC
- Reworked ddr_load_train_firmware() to get a 50ms boot time improvement
Check the header before starting to use it, since this could provide
very confusing later, when ofnode calls start to fail.
Signed-off-by: Simon Glass <sjg@chromium.org>
Function acpi_get_rsdp_addr() is needed on all architectures which
write ACPI tables. Move the definition from the x86 include to an
architecture independent one.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
To quote the author:
It would be useful to be able to boot an OS when CONFIG_CMDLINE is
disabled. This could allow reduced code size.
Standard boot provides a way to handle programmatic boot, without
scripts, so such a feature is possible. The main impediment is the
inability to use the booting features of U-Boot without a command line.
So the solution is to avoid passing command arguments and the like to
code in boot/
A similar process has taken place with filesystems, for example, where
we have (somewhat) separate Kconfig options for the filesystem commands
and the filesystems themselves.
This series starts the process of refactoring the bootm logic so that
it can be called from standard boot without using the command line.
Mostly it removes the use of argc, argv and cmdtbl from the internal
logic.
Some limited tidy-up is included, but this is kept to smaller patches,
rather than trying to remove all #ifdefs etc. Some function comments
are added, however.
A simple programmatic boot is provided as a starting point.
This work will likely take many series, so this is just the start.
Size growth with this series for firefly-rk3288 (Thumb2) is:
arm: (for 1/1 boards) all +23.0 rodata -49.0 text +72.0
This should be removed by:
https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/11
but it is not included in this series as it is already large enough.
No functional change is intended in this series.
Changes in v3:
- Add a panic if programmatic boot fails
- Drop RFC tag
Changes in v2:
- Add new patch to adjust position of unmap_sysmem() in boot_get_kernel()
- Add new patch to obtain command arguments
- Fix 'boot_find_os' typo
- Pass in the command name
- Use the command table to provide the command name, instead of "bootm"
Add some functions which provide an argument to a command, or NULL if
the argument does not exist.
Use the same numbering as argv[] since it seems less confusing than the
previous idea.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>
To quote the author:
I wanted to add support for ti,lp5562, and found an old submission
from Doug. While trying to modify that to work in current U-Boot, I
found a problem with the "move label handling to core" patches.
Patch 1 is a prerequisite for the ti,lp5562 driver, which turned out
to be needed by Christian as well.
Patch 2 is an attempt at (quick-)fixing the mentioned "move label
handling to core" problem. The real fix consists of changing remaining
drivers to not bind the same driver to the top node as to the child
nodes, but I can't test those other drivers.
Patch 3 introduces a helper which should allow removing some
boilerplate in most individual drivers, and 4,5 apply that in the gpio
and pwm drivers. Converting remaining drivers is trivial, but left out
for now.
Finally patch 6 is the reworked lp5562 driver. While I've changed it
to match existing DT bindings (with the goal of making it work with
our .dts that is known to work with the linux driver), most of the
logic is unchanged from Doug's original patch, so he is still listed
as author.
Changes in v2: Interchange order of patches 1 and 2, add a few R-bs,
and try to trim down the commit message in patch 2.
Driver for the TI LP5562 4 channel LED controller. Supports
independent on/off control of all 4 channels. Supports LED_BLINK on 3
independent channels: blue/green/red. The white channel can blink, but
shares the blue channel blink rate.
Heavily based on patch originally from Doug Zobel [1].
I have modified it so it matches the DT bindings in the linux tree,
and also follows the linux driver implementation more closely. This
should address Tom's concerns, and also matches my goal of making the
U-Boot driver work with our existing .dts which is known to work in
linux.
As our boards only have the R,G,B outputs connected, I have not
actually tested how the white channel behaves, but the R,G,B work
exactly as expected.
[1] https://lore.kernel.org/u-boot/1547150757-1561-1-git-send-email-douglas.zobel@climate.com/
Cc: Doug Zobel <douglas.zobel@climate.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Use the helper led_bind_generic() to reduce code duplication.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Use the helper led_bind_generic() to reduce code duplication.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
All existing drivers in drivers/led/ contain a .bind method that does
exactly the same thing, with just the actual driver name
differing. Create a helper so all those individual methods can be
changed to one-liners.
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Many existing drivers, and led-uclass itself, rely on uc_plat->label
being NULL for the device representing the top node, as opposed to the
child nodes representing individual LEDs. This means that the drivers
whose .probe methods rely on this were broken by commit 83c63f0d11
("led: Move OF "label" property parsing to core"), and also that the top
node wrongly shows up with 'led list'.
Binding the same driver to the top node as to the individual child
nodes is arguably wrong, and the approach of using a UCLASS_NOP driver
for the top node is probably better - this has for example been done in
commit 0107469780 ("led: gpio: Use NOP uclass driver for top-level
node") and commit 910b01c27c ("drivers: led: bcm6753: do not use null
label to find the top")
Until remaining affected drivers are fixed, we can use a heuristic
that only sets the label to the fallback value derived from the node
name if the node does not have a "compatible" property - i.e., if it
has been bound to the LED driver explicitly via
device_bind_driver_to_node(). This is similar to what commit
e3aa76644c ("led: gpio: Check device compatible string to determine
the top level node") did for gpio_led, but that fix was then supplanted
by commit 0107469780 ("led: gpio: Use NOP uclass driver for top-level
node")
Fixes: 83c63f0d11 ("led: Move OF "label" property parsing to core")
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
If the driver's own .bind method has populated uc_plat->label, don't
override that. This is necessary for an upcoming driver for ti,lp5562,
where the DT binding unfortunately says to use "chan-name" and not
"label".
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Display port is using topsw_lsbus clock, it is failing
while enabling the clock, so enable the topsw_lsbus clock.
Signed-off-by: Sreekanth Sunnam <sreekanth.sunnam@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20231204084515.9488-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Based on Linux kernel 6.7-rc4, add necessary clocks for the PWM
controllers.
Signed-off-by: Nicolas Heemeryck <nicolas.heemeryck@devialet.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Currently, when running "ums 0 mmc 2" and breaking it via
CTRL + C, the following message is seen:
u-boot=> ums 0 mmc 1
UMS: LUN 0, dev mmc 1, hwpart 0, sector 0x0, count 0x1dacc00
CTRL+C - Operation aborted
clk usb_phy_root_clk already disabled
The USB PHY clock is disabled twice: first it gets disabled
inside imx8mq_usb_phy_power_off(), then it is disabled again
inside imx8mq_usb_phy_exit().
Let the USB PHY clock be disabled only once inside
imx8mq_usb_phy_power_off() by removing the .exit operation.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Add support for DWC EQoS MAC on i.MX93.
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Function ddr_load_train_firmware() is called 4 times in a loop by
ddr_cfg_phy(). The first 3 calls are all '1D' type and just loading the
same FWs. Let's add a type check and save 2 of them. This helps to
reduce DDRPHY training time from 269 ms down to 212 ms, and thus speed
up boot time ~ 50 ms.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Fabio Estevam <festevam@denx.de>
As of now only one mailbox agent is supported by mailbox driver.
On zynqmp platform there are about 7 mailbox agents which can communicate
over same IPI channel to U-Boot. This patch series introduces new
"zynqmp_ipi_dest" driver which adds one to multi-channel mailbox
support.
Following format in device-tree is expected as per latest bindings:
zynqmp-ipi {
compatible = "xlnx,zynqmp-ipi-mailbox";
mbox_1: mailbox@1 {
/* New compatible for child node */
compatible = "xlnx,zynqmp-ipi-dest-mailbox";
...
};
...
mbox_n: mailbox@n {
compatible = "xlnx,zynqmp-ipi-dest-mailbox";
...
}
};
Then mailbox client uses child mailbox node as following:
ipi-dest-1 {
...
mboxes = <mbox_1 0>, <mbox_1 1>;
mbox-names = "tx", "rx";
...
};
New "zynqmp_ipi_dest" driver is for devices with
"xlnx,zynqmp-ipi-dest-mailbox" compatible string. This driver will take care
of mailbox send recv ops and it replaces previous "zynqmp_ipi" driver.
Now "zynqmp_ipi" driver simply binds each child device with "zynqmp_ipi_dest"
driver.
However, its important to maintain backward comaptibility with previous
bindings where child node does not have compatible string. In such case, new
driver isn't probed by U-Boot during boot and system fails to boot. To
resolve this issue firmware-zynqmp.c driver probes all the IPI parent node
driver which binds each child node device with "zynqmp_ipi_dest" driver.
This makes sure corresponding child driver will be
probed when requested using mbox_get_by_name or mbox_get_by_idx
framework calls.
This way multiple mailbox agents are supported in device-tree without breaking
previous binding support.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20231204215620.63334-4-tanmay.shah@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
If U-Boot is running in Exception Level 3 then use hardcode
register values for mailbox message passing with PMU.
This is only supported for zynqmp platform.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20231204215620.63334-3-tanmay.shah@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Use SMC calls to TF-A to operate IPI for execution level below 3. For
EL3 use hardcode IPI registers as TF-A isn't available in EL3.
Hence, in EL3 remote and local IPI ids retrieved using xlnx,ipi-id
property are unused.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20231204215620.63334-2-tanmay.shah@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Add the xfer callback which is used by the MMC_SPI driver and generally by
the dm_spi_xfer callback.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Tested-by: Love Kumar <love.kumar@amd.com>
Link: https://lore.kernel.org/r/20231116164336.140171-3-mchitale@ventanamicro.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Modify start_transfer and related functions to take a udevice parameter
as input instead of spi_slave. This is needed so that start_transfer can
be used directly via the xfer callback. Also fix a compiler warning.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Tested-by: Love Kumar <love.kumar@amd.com>
Link: https://lore.kernel.org/r/20231116164336.140171-2-mchitale@ventanamicro.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The host bridge MMIO region is disabled by default due to which MMIO
accesses cause an exception. Fix it by setting the bridge enable bit.
This change is ported from the linux pcie-xilinx driver.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20231116165103.140968-3-mchitale@ventanamicro.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
As per the xlnx,axi-ethernet-1.00.a DT documentation in linux, the AXI
DMA registers can be obtained via the reg property or via a separate
node for the axistream DMA controller. Currently only the latter is
supported, so add support to fetch the DMA controller registers from the
"reg" property.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20231116164024.139934-1-mchitale@ventanamicro.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The wdt_start function takes timeout_ms as a parameter and starts the
watchdog with this value. However, when you output the message, it shows
the default timeout value for the watchdog device.
So this patch fixes that part to output the correct timeout value.
Before -->
StarFive # wdt start 3000
WDT: Started watchdog@13070000 without servicing (60s timeout)
After -->
StarFive # wdt start 3000
WDT: Started watchdog@13070000 without servicing (3s timeout)
Fixes: c2fd0ca1a8 ("watchdog: Integrate watchdog triggering into the cyclic framework")
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Compiling with CONFIG_USB_XHCI_PCI and CONFIG_PCI=n results in
usb/host/xhci-pci.c:48:(.text.xhci_pci_probe+0x44):
undefined reference to `dm_pci_write_config32
Add the missing Kconfig dependency.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Like Rockchip RK3328 and RK3568, the RK3588 also have a single node to
represent the glue and ctrl for USB 3.0.
Use rk_ops as driver data to select correct ctrl node for RK3588 DWC3.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Marek Vasut <marex@denx.de>
We need to get the DMA address before incrementing the pointer, as that
might move us onto another segment.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>
Now that we always check the return value, just return NULL on timeouts.
We can still log the error since this is a problem, but it's not reason
to panic.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>
This isn't going to work, don't pretend it will and then end up timing
out.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>
There is currently no codepath to recover from this case. In principle
we could require that the upper layer do this explicitly, but let's just
do it in xHCI when the next bulk transfer is started, since that
reasonably implies whatever caused the problem has been dealt with.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>
There is a race where an endpoint may halt by itself while we are trying
to halt it, which results in a context state error. See xHCI 4.6.9 which
mentions this case.
This also avoids BUGging when we attempt to stop an endpoint which was
already stopped to begin with, which is probably a bug elsewhere but
not a good reason to crash.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>
If the xHC has a problem with our STOP ENDPOINT command, it is likely to
return a completion directly instead of first a transfer event for the
in-progress transfer. Handle that more gracefully.
We still BUG() on the error code, but at least we don't end up timing
out on the event and ending up with unexpected event errors.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>
xhci_wait_for_event returns NULL on timeout, so the caller always has to
check for that. This addresses immediate explosions in this part
of the code when timeouts happen, but not the root cause for the
timeout.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>
This is a hacky way to have this file included in all source files that
include common.h, instead just include from the files that need it.
Signed-off-by: Andrew Davis <afd@ti.com>
The current implementation may cause BUG_ON() in blkfront_aio()
BUG_ON(n > BLKIF_MAX_SEGMENTS_PER_REQUEST);
In pvblock_iop(), a read/write operation will be split into smaller
chunks of data so that the size in one access (aio_nbytes) is limited
to, at the maximum,
BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
But this works only if when the *buffer* passed in to pvblock_io()
is page-aligned. If not, the given data region may stand across
(BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) pages. See the logic in
blkfront_aio():
start = (uintptr_t)aiocbp->aio_buf & PAGE_MASK;
end = ((uintptr_t)aiocbp->aio_buf + aiocbp->aio_nbytes +
PAGE_SIZE - 1) & PAGE_MASK;
Then this will lead to BUG_ON() above.
This can be fixed by decreasing the maximum size of aio_nbytes.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Fixes: commit 3a739cc6c9 ("xen: pvblock: Implement front-back protocol and do IO")
Currently the "clock-frequency" DT property is only being considered as an
fallback if either there is no clock driver, the clock driver implements
the request-op correctly or there is no clock defined for the timer at all.
This patch makes "clock-frequency" also being picked as a fallback if
getting the clock-rate fails, since clk_get(_by_index) will return no
error, if a clock driver does not implement the request-op and does also
not support getting the rate of the clock in question.
timer_post_probe will take care if the property does not exist in the DT or
is defined as 0.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
To quote the author:
"Scmi" command will be re-introduced per Michal's request.
The functionality is the same as I put it in my patch set of adding
SCMI base protocol support, but made some tweak to make UT, "ut dm
scmi_cmd," more flexible and tolerable when enabling/disabling a specific
SCMI protocol for test purpose.
Each commit may have some change history inherited from the preceding
patch series.
Test
====
The patch series was tested on the following platforms:
* sandbox
This change will be useful when we manually test SCMI on sandbox
by enabling/disabling a specific SCMI protocol.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
To quote the author:
This series imports generic versions of ioread_rep/iowrite_rep and
reads/writes from Linux. Some cleanup is done to make sure that all
platforms have proper defines for implemented functions and there are no
redefinitions.
Since {read,write}s{l, w, b}() functions are now supported in linux/io.h
there is no need to add custom implementation to driver.
Signed-off-by: Igor Prusov <ivprusov@salutedevices.com>
