Suman Anna [Tue, 10 Mar 2020 23:34:54 +0000 (18:34 -0500)]
remoteproc: k3-r5: Fix rproc init failure for Main R5FSS0
The Main R5FSS0 cluster is also enabled to probe the R5F remoteproc
driver within R5 SPL for booting the Core0 very early. This results
in a ti_sci_power_domain_on failure during the probe from the A72
U-Boot when "rproc init" is executed at U-Boot prompt, and doesn't
enumerate all the rproc devices.
Fix this by suppressing the power_domain_on altogether using the
flag DM_FLAG_DEFAULT_PD_CTRL_OFF added in commit af94ad418dc7
("dm: core: Allow for not controlling the power-domain by DM framework").
Suman Anna [Tue, 10 Mar 2020 21:05:56 +0000 (16:05 -0500)]
remoteproc: k3-dsp: Add support for L2RAM loading on C66x DSPs
The resets for the DSP processors on K3 SoCs are managed through the
Power and Sleep Controller (PSC) module. Each DSP typically has two
resets - a global module reset for powering on the device, and a local
reset that affects only the CPU while allowing access to the other
sub-modules within the DSP processor sub-systems.
The C66x DSPs have two levels of internal RAMs that can be used to
boot from, and the firmware loading into these RAMs require the
local reset to be asserted with the device powered on/enabled using
the module reset. Enhance the K3 DSP remoteproc driver to add support
for loading into the internal RAMs. The local reset is deasserted on
SoC power-on-reset, so logic has to be added in probe in remoteproc
mode to balance the remoteproc state-machine.
Note that the local resets are a no-op on C71x cores, and the hardware
does not supporting loading into its internal RAMs.
Suman Anna [Tue, 10 Mar 2020 21:05:55 +0000 (16:05 -0500)]
armv8: K3: j721e: Add DSP internal memory regions in MMU table
The A72 U-Boot code supports early load and boot of a number of
remote processors including the C66_0 and C66_1 DSPs. The current
code supports only loading into the DDR regions which were already
given the appropriate memory attributes. The C66 DSPs also have L1
and L2 internal memory regions that can behave as normal-memories.
Add a new entry to the J721E MMU table covering these regions with
the appropriate memory attributes to allow the A72 U-Boot code to
support loading directly into these memory regions.
Suman Anna [Tue, 10 Mar 2020 21:05:54 +0000 (16:05 -0500)]
remoteproc: k3-dsp: Add a sanity check for DSP boot address alignment
The DSP remote processors on K3 SoCs require a boot register to be
programmed with a boot address, and these boot addresses need to be
aligned on certain address boundaries. The current code does not have
any error checks, and relies on the System Firmware to perform the
checking. Add logic to perform this sanity check within the remoteproc
driver itself to detect these anomalies specifically, and print a
meaningful trace. This avoids the cumbersome debug of root-causing
such failures from the corresponding TI-SCI failure.
The C66x and C71x DSP cores have different alignment needs and are
as follows:
C66x DSP = 1 KB (0x400)
C71x DSP = 2 MB (0x200000)
Suman Anna [Tue, 10 Mar 2020 21:05:53 +0000 (16:05 -0500)]
remoteproc: k3-dsp: Fix unbalanced state machine in k3_dsp_start
The global module reset is deasserted through the ti_sci_power_domain_on()
call in k3_dsp_start(), but is not asserted back if the local module reset
fails. Fix this.
While at this, remove the stale comment about assigned-clock-rates that
seems to have been copied from the K3 ARM64 Remoteproc driver.
Fixes: ab827b385718 ("remoteproc: Introduce K3 C66 and C71 remoteproc driver") Signed-off-by: Suman Anna <s-anna@ti.com>
Sam Protsenko [Wed, 26 Feb 2020 17:57:05 +0000 (19:57 +0200)]
configs: am335x_evm: Enable Fastboot
This config option was present in am335x_boneblack_defconfig, but we
have to use generic am335x_evm_defconfig now, as BBB defconfig was
removed in commit 8fa7f65dd02c ("configs: Remove
am335x_boneblack_defconfig"). So this patch merely brings that option
back.
Tested on BeagleBone Black:
=> fastboot 0
$ fastboot flash rootfs rootfs.img
Fixes: 8fa7f65dd02c ("configs: Remove am335x_boneblack_defconfig") Signed-off-by: Sam Protsenko <joe.skb7@gmail.com>
Sam Protsenko [Wed, 26 Feb 2020 17:43:01 +0000 (19:43 +0200)]
configs: am335x_evm: Enable DFU over TFTP support
DFU over TFTP flashing method might be helpful in order to speed-up the
flashing process of big images (as DFU works over USB EP0, which is
quite slow). Also, it's a good backup option in the case when USB got
broken (either in software or hardware), to avoid resorting to SD card
boot.
This config option was present in am335x_boneblack_defconfig, but we
have to use generic am335x_evm_defconfig now, as BBB defconfig was
removed in commit 8fa7f65dd02c ("configs: Remove
am335x_boneblack_defconfig"). So this patch merely brings that option
back.
Lokesh Vutla [Fri, 28 Feb 2020 12:26:20 +0000 (17:56 +0530)]
dma: ti: k3-udma: Mark flow id as valid parameter for RX channel config
When flow id is not marked as valid, sysfw reads the register value to
get the range of flow ids that are supported. Then compares the flow range
with the U-Boot's host id. This will definitely fail as board
configuration doesn't assign the full range to U-Boot's host id. In order
to work around this, mark the flow id as valid and pass range as 0.
Sam Protsenko [Fri, 21 Feb 2020 14:35:21 +0000 (16:35 +0200)]
env: ti: boot: Fix Android boot on AM57x EVM
When applying DTBO on top of DTB (with "fdt apply" command) on AM57x EVM
board, there is not enough memory reserved in RAM for DTB blob. Hence,
DTBO can't be merged in DTB. It leads to inability to boot Android with
next error message:
failed on fdt_overlay_apply(): FDT_ERR_NOSPACE
To overcome that issue let's provide 512 KiB of space to keep DTB and
all merged DTBO blobs. To do so, "length" parameter should be specified
for "fdt addr" command:
=> fdt addr $fdtaddr 0x80000
512 KiB is the maximum size we can use for this, because next address
after $fdtaddr is 512 KiB ahead of it:
fdtaddr=0x88000000
rdaddr=0x88080000
Also add size variables to 'adtimg' command invocations, to avoid
cluttering the console with DTBO blob sizes.
Signed-off-by: Sam Protsenko <joe.skb7@gmail.com> Reviewed-by: Eugeniu Rosca <rosca.eugeniu@gmail.com>
Dario Binacchi [Sat, 22 Feb 2020 13:05:49 +0000 (14:05 +0100)]
board: brxre1: fix building errors
Fix building errors if CONFIG_DM_VIDEO is enabled. This is the only
u-boot board that enables CONFIG_AM335X_LCD and from which I started
to develop the version of the frame buffer driver that supports the
driver model.
Dario Binacchi [Sat, 22 Feb 2020 13:05:46 +0000 (14:05 +0100)]
arm: dts: am335x: add 'u-boot, dm-pre-reloc' to panel
Add the "u-boot,dm-pre-reloc" property to the "ti,tilcdc,panel"
compatible node. In this way the video-uclass module can allocate the
amount of memory needed to be assigned to the frame buffer.
For boards that support Linux the property is added to the *-u-boot.dtsi
file since it is a u-boot specific dt flag.
Ran building tests with CONFIG_AM335X_LCD enabled and disabled for the
following configurations:
- brxre1_defconfig --> success
- am335x_guardian_defconfig --> success
- am335x_evm_defconfig --> success
- da850evm_defconfig --> failure with CONFIG_AM335X_LCD enabled
Enabling CONFIG_AM335X_LCD in da850evm_defconfig causes building errors
even without applying the patch. The driver has never been enabled on the
da850 and must be adapted for this platform.
Dario Binacchi [Sat, 22 Feb 2020 13:05:45 +0000 (14:05 +0100)]
video: omap: add support for DM/DTS
Update the driver to support the device tree and the driver model.
Timings and panel parameters are now loaded from the device tree.
The DM code replaces the am335x_lcdpanel structure with
tilcdc_panel_info taken from the linux kernel, as well the management
of additional parameters not covered in the legacy code. In addition,
the am335x_lcdpanel structure contains parameters and operations that
were probably a requirement of the board for which this driver was
developed and which, however, were not developed in the linux kernel.
All this led to rewrite th DM controller initialization code, except
for the pixel clock setting that is executed in a function created in a
previous patch with code taken from the legacy am335xfb_init.
The patch has been tested on a custom board with u-boot 2018.11-rc2 and
the following device-tree configuration:
Dario Binacchi [Sat, 22 Feb 2020 13:05:43 +0000 (14:05 +0100)]
video: omap: add loop exit conditions to the dpll setup
In case of null error, round rate is equal to target rate, so it is
useless to continue to search the DPLL setup parameters to get the
desidered pixel clock rate.
Tero Kristo [Fri, 14 Feb 2020 07:05:10 +0000 (09:05 +0200)]
power: mfd: k3_avs: update am65xx MPU_VDD voltage values
The latest data manual SPRSP08I –NOVEMBER 2017–REVISED DECEMBER 2019[1]
for am65xx SoC states the new MPU nominal voltages to be 1.1V (OPP_NOM),
1.2V (OPP_OD) and 1.24V (OPP_TURBO). Update the nominal voltages in the
K3 AVS driver to reflect this.
Tero Kristo [Fri, 14 Feb 2020 09:18:18 +0000 (11:18 +0200)]
arm: dts: k3-j721e: Add ESM PMIC support for tps659413 based board
The ESM handling on J7 processor board requires routing the
MCU_SAFETY_ERROR signal to the PMIC on the board for critical safety
error handling. The PMIC itself should then reset the board based on
receiving it. Enable the support for the board by adding the esm
node in place.
Tero Kristo [Fri, 14 Feb 2020 09:18:17 +0000 (11:18 +0200)]
arm: dts: k3-k721e: Add Main domain ESM support
Main domain ESM support is needed to configure main domain watchdogs
to generate ESM pin events by default. On J7 processor board these
propagate to the PMIC to generate a reset when watchdog expires.
Tero Kristo [Fri, 14 Feb 2020 09:18:16 +0000 (11:18 +0200)]
misc: pmic_esm: Add support for PMIC ESM driver
The ESM (Error Signal Monitor) is used on certain PMIC versions to
handle error signals propagating from rest of the system. If these
reach the PMIC, it is typically a last resort fatal error which
requires a system reset. The ESM driver does the proper configuration
for the ESM module to reach this end goal. Initially, only TPS65941
PMIC is supported for this.
Tero Kristo [Fri, 14 Feb 2020 09:18:15 +0000 (11:18 +0200)]
misc: k3_esm: Add support for Texas Instruments K3 ESM driver
The ESM (Error Signaling Module) is used to route error signals within
the K3 SoCs somewhat similar to interrupts. The handling for these is
different though, and can be routed for hardware error handling, to
be handled by safety processor or just as error interrupts handled
by the main processor. The u-boot level ESM driver is just used to
configure the ESM signals so that they get routed to proper destination.
Keerthy [Wed, 12 Feb 2020 08:25:10 +0000 (13:55 +0530)]
configs: j721e_evm_r5: Enable R5F remoteproc support
Enable R5F remoteproc support in R5 defconfig so that R5s can
be started in SPL. While at it enable the SPL_FS_EXT4 config
option to load the firmwares from file system.
Lokesh Vutla [Tue, 4 Feb 2020 05:39:50 +0000 (11:09 +0530)]
ARM: mach-k3: sysfw-loader: Use SPI memmapped addr when loading SYSFW
Since ROM configures OSPI controller to be in memory mapped mode in OSPI
boot, R5 SPL can directly pass the memory mapped pointer to ROM. With
this ROM can directly pull the SYSFW image from OSPI.
ARM: mach-k3: arm64-mmu: map 64bit FSS MMIO space in A53 MMU
Populate address mapping entries in A53 MMU for 4 GB of MMIO space
reserved for providing MMIO access to multiple flash devices through
OSPI/HBMC IPs within FSS.
Descend to drivers/soc directory unconditionally for SPL and U-Boot
builds. Individual drivers can have their own config to check what needs
to be built for SPL. There should be no increase in SPL code size
due to this change.
This is required on K3 SoCs to support DMA in SPL.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Printing the error message in verbose mode fails, since python3
doesn't implicitely convert bytes to strings.
Signed-off-by: Markus Klotzbuecher <mk@mkio.de> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Commit b237d358b425 ("moveconfig: expand simple expressions") added
support for expanding expressions in configs, but used the unsafe python
built-in "eval". This patch fixes this by replacing eval with the
asteval module.
Signed-off-by: Markus Klotzbuecher <mk@mkio.de> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Heiko Schocher <hs@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Commit 856b9cdb53f0 ("powerpc: mpc85xx: delete FSL_SATA for T2080QDS
board.") is to fit support sata DM mode, Now the driver will be reverted,
So revert it.
Signed-off-by: Peng Ma <peng.ma@nxp.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Commit 1ee494291880 ("ata: fsl_ahci: Add sata DM support for Freescale
powerpc socs") introduced SCSI layer to call AHCI private API in order
to support sata operations, In DM mode, This is not necessary for
non-AHCI sata. So revert it and have already updated the driver itself
to operate sata directly.
Signed-off-by: Peng Ma <peng.ma@nxp.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Update doc/sphinx/kerneldoc.py from Linux next-20200219 to avoid warnings
like:
doc/sphinx/kerneldoc.py:125: RemovedInSphinx20Warning:
AutodocReporter is now deprecated. Use
sphinx.util.docutils.switch_source_input() instead.
self.state.memo.reporter =
AutodocReporter(result, self.state.memo.reporter)
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Masahiro Yamada [Fri, 14 Feb 2020 07:40:27 +0000 (16:40 +0900)]
mmc: sdhci: fix missing cache invalidation after reading by DMA
This driver currently performs cache operation before the DMA start,
but does nothing after the DMA completion.
When reading data by DMA, the cache invalidation is needed also after
finishing the DMA transfer. Otherwise, the CPU might read data from
the cache instead of from the main memory when speculative memory read
or memory prefetch occurs.
Instead of calling the cache operation directly, this commit adds
dma_unmap_single(), which performs cache invalidation internally,
but drivers do not need which operation is being run.
Masahiro Yamada [Fri, 14 Feb 2020 07:40:26 +0000 (16:40 +0900)]
mmc: sdhci: use dma_map_single() instead of flush_cache() before DMA
Currently, sdhci_prepare_dma() calls flush_cache() regardless of the
DMA direction.
Actually, cache invalidation is enough when reading data from the device.
This is correctly handled by dma_map_single(), which mimics the DMA-API
in Linux kernel. Drivers can be agnostic which cache operation occurs
behind the scene.
This commit also sanitizes the difference between the virtual address
and the dma address.
Kever Yang [Wed, 19 Feb 2020 09:51:07 +0000 (17:51 +0800)]
rockchip: rk3399: add target type for evb based board
There are many boards share the board file and device header file with
rk3399 evb, add target type MACRO so that it is fixed instead of default
to the first target in "RK3399 board select".
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Masahiro Yamada [Fri, 14 Feb 2020 07:40:19 +0000 (16:40 +0900)]
dma-mapping: move dma_map_(un)single() to <linux/dma-mapping.h>
The implementation of dma_map_single() and dma_unmap_single() is
exactly the same for all the architectures that support them.
Factor them out to <linux/dma-mapping.h>, and make all drivers to
include <linux/dma-mapping.h> instead of <asm/dma-mapping.h>.
If we need to differentiate them for some architectures, we can
move the generic definitions to <asm-generic/dma-mapping.h>.
Add some comments to the helpers. The concept is quite similar to
the DMA-API of Linux kernel. Drivers are agnostic about what is
going on behind the scene. Just call dma_map_single() before the
DMA, and dma_unmap_single() after it.
Rasmus Villemoes [Thu, 30 Jan 2020 12:06:45 +0000 (12:06 +0000)]
mmc: fsl_esdhc: actually enable cache snooping on mpc830x
The reference manuals for MPC8308 and MPC8309 both say that the
esdhcctl aka DMA Control Register "is implemented as SDHCCR" in the
System configuration registers. Unfortunately, that doesn't mean that
the registers are just mirrors of each other - any write to esdhcctl
is simply ignored. So to actually enable cache snooping, we
unfortunately have to add a little ifdeffery.
There is, naturally, no description of the bit fields of esdhcctl in
the MPC8309 manual, but comparing the description of esdhcctl from the
LS1021A reference manual to the description of the sdhccr in MPC8309,
one also finds that the fields are bit-reversed, so the bit to set is
0x02000000 rather than 0x00000040 - this is also what board_mmc_init()
uses in the two gdsys/mpc8308/ boards.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Yangbo Lu <yangbo.lu@nxp.com>
projects / u-boot.git / log
