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>
This reverts commit 1ee4942918.
Commit 1ee4942918 ("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>
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.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
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.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
host->mmc is already (struct mmc *).
memalign() returns an opaque pointer, so there is no need for casting.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Use {lower,upper}_32_bits() instead of the combination of cast
and shift.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The same code is run for both SDHCI_QUIRK_32BIT_DMA_ADDR and
define(CONFIG_FIXED_SDHCI_ALIGNED_BUFFER).
Unify the code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Using the global variable does not look nice.
Add a new field sthci::align_buffer to point to the bounce buffer.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
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.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
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>
Unfortunately a recent change adjusted the order of the checks here such
that 400MHz now shows up as fast-plus speed (1Mbps). Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: d96440d1e3 ("i2c: designware_i2c: Add support for fast-plus speed")
These functions are defined before the callers.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Since commit 01298da31d ("mmc: Change mode when switching to a boot
partition"), errors in mmc_select_mode_and_width() are ignored.
The return value should be checked.
Fixes: 01298da31d ("mmc: Change mode when switching to a boot partition")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Cadence sent out an errata report to their customers of this IP.
This errata is not so severe, but the tune request should be sent
twice to avoid the potential issue.
Quote from the report:
Problem Summary
---------------
The IP6116 SD/eMMC PHY design has a timing issue on receive data path.
This issue may lead to an incorrect values of read/write pointers of
the synchronization FIFO. Such a situation can happen at the SDR104
and HS200 tuning procedure when the PHY is requested to change a phase
of sampling clock when moving to the next tuning iteration.
Workarounds
-----------
The following are valid workarounds to resolve the issue:
1. In eMMC mode, software sends tune request twice instead of once at
each iteration. This means that the clock phase is not changed on
the second request so there is no potential for clock instability.
2. In SD mode, software must not use the hardware tuning and instead
perform an almost identical procedure to eMMC, using the HRS34 Tune
Force register.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
erase_grp_size is used, when MMC_WRITE is enabled.
- error: ‘struct mmc’ has no member named ‘erase_grp_size’
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
If the host has Broken R1B, use only R1 response type.
Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty@broadcom.com>
Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
- DT alignment with kernel v5.5-rc7 for stm32mp1 boards
- fix STM32 image format for big endian hosts in mkimage
- solve warnings in device tree and code for stm32mp1 boards
- remove fdt_high and initrd_high for stm32 and stih boards
- add support of STM32MP15x Rev.Z
- update stm32mp1 readme
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE56Yx6b9SnloYCWtD4rK92eCqk3UFAl5GcB0ACgkQ4rK92eCq
k3Wr9gf/dDPJi6UBhLDio/IVKDBddOEUN0Lwdr9W0upL+DrdvEOyNyMSEKuLccIE
UTd1NmNNwcvgDRaPvB5o3R7twWItTW0cYlmVkFSZ228aq6xdf/SElN2OUD6B9Gh+
8bi6oVLu41TNMYn4VYxsEftcT2megfH8s+SH/FlvR5ua1yCC1vyrytEQjPIbJAB2
sa90ewDyp5EYqGLdAk6AVjPLeNZsaleGwuyLf04PoC2xhn+3HTEKJCJN4O46aJUr
0GUI7YN7pTjIfZdYfFqjcwoQV1xV2HtbjCTcOb8Td8TEYjIoILF8tSyfIwDXWGB5
zMQIQxUdQyNiqdBPFcnkAufjk+zLIQ==
=0dG+
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20200214' of https://gitlab.denx.de/u-boot/custodians/u-boot-stm
- add DH Electronics DHCOM SoM and PDK2 board
- DT alignment with kernel v5.5-rc7 for stm32mp1 boards
- fix STM32 image format for big endian hosts in mkimage
- solve warnings in device tree and code for stm32mp1 boards
- remove fdt_high and initrd_high for stm32 and stih boards
- add support of STM32MP15x Rev.Z
- update stm32mp1 readme
Solve type issue in stm32mp1_lse_enable and stm32mp1_clktree.
This patch solves the warnings when compiling with W=1
on stm32mp1 board:
clk_stm32mp1.c: In function ‘stm32mp1_lse_enable’:
clk_stm32mp1.c:1238:15: warning: comparison of integer expressions
of different signedness: ‘u32’ {aka ‘unsigned int’} and ‘int’
[-Wsign-compare]
clk_stm32mp1.c:1239:13: warning: comparison of integer expressions
of different signedness: ‘u32’ {aka ‘unsigned int’} and ‘int’
[-Wsign-compare]
clk_stm32mp1.c: In function ‘stm32mp1_clktree’:
clk_stm32mp1.c:1814:17: warning: comparison of integer expressions
of different signedness: ‘int’ and ‘unsigned int’
[-Wsign-compare]
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Use int as result of dm_i2c_reg_read to avoid warning with
W=1 (warning: comparison is always false due to limited range
of data type [-Wtype-limits])
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
There is no reason to show RAM_ROCKCHIP_DEBUG entry in other .config files
as I see it for Xilinx ZynqMP.
\# CONFIG_U_QE is not set
\# CONFIG_RAM is not set
CONFIG_RAM_ROCKCHIP_DEBUG=y
Add missing dependency on RAM_ROCKCHIP driver.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
HDMI PLL has its own xtal with 27 MHz output but we treat it the same
way as other PLLs with 33.33 MHz input.
Fix that.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
TPM TEE driver
Various minor sandbox video enhancements
New driver model core utility functions
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAl48iogACgkQfxc6PpAI
reaVzAf/an3/yKe6r3CVWlcRV6H/dVg1ApnnLpX7jS0p0b++oCVvOiy7z1WPXj3k
b1SSgENDeeZ/8EHio+Gf7ZidH/TGEj7L6YEFwd1t60GMkZiWEkNf4Z53tw482YG+
96hoPD+ySTW+ddIdVHWAFG2I4aEiKHANJAp/ItNdD+rLbrEwNQy+eiK5JTOk80B6
/X8AJCLZeAC1s7vs+2+WolgjT78QGzA9HHalMiublcqh0ivKKk0QeQiOKKPe8JYJ
om5YY1TxayQ60Xmo5f39/SBfzEEklxw83sU9o1tBeYzyVUpu7fQdkxiDbWdsij77
DgwLdeYQJGbN+hdSWE0gjTqyhW+lWA==
=KRoA
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-6feb20' of https://gitlab.denx.de/u-boot/custodians/u-boot-dm
sandbox conversion to SDL2
TPM TEE driver
Various minor sandbox video enhancements
New driver model core utility functions
The commit e8e9715df2 ("regulator: fixed: Modify enable-active-high behavior")
fixed the regulator driver behavior when 'enable-active-high' is defined.
Unfortunately, this patch used dm_regulator_platdata()'s "boot_on" member
to set GPIOD_IS_OUT_ACTIVE flag and enable the regulator.
The issue here is that regulator_common_ofdata_to_platdata() is called
_before_ regulator_pre_probe() function in which the 'regulator-boot-on'
property is asserted.
As a result the GPIOD_IS_OUT_ACTIVE flag is not set and gpio_request_by_name()
called in the former function is not enabling the regulator.
This is problematic for e.g. i.MX ethernet driver, which then tries to
perform initialization without power (and fails).
The solution here is to explicitly enable regulator in regulator_pre_probe()
callback only when 'regulator-boot-on' property is present in device tree.
The GPIOD_IS_OUT_ACTIVE flag is not set at all, but relevant gpio is
requested.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Tested-by: Patrice Chotard <patrice.chotard@st.com>
- Move P2SB from Apollo Lake to a more generic location
- Add a function to find a device by drvdata in DM core
- Enhancement of DM IRQ uclass driver
- Add a clock driver for Intel devices
- Add support for ACPI general-purpose events
- Add a TPM driver for H1/Cr50
- Enable TPM on Google Chromebook Coral
- fix vid_console_color() build warning
- fix for mxsfb to ensure correct Linux logo position
-----BEGIN PGP SIGNATURE-----
iGwEABECACwWIQSC4hxrSoIUVfFO0kRM6ATMmsalXAUCXkGKMg4cYWd1c3RAZGVu
eC5kZQAKCRBM6ATMmsalXCY3AJ9zzSWCPRa6M6YbYiHyfasyP1uf+gCdG2bMDRaC
vNpAeNnM9aWgJMkje6k=
=al8x
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v2020.04' of https://gitlab.denx.de/u-boot/custodians/u-boot-video
- fix Coverity CID 280902 issue in vid_console_color()
- fix vid_console_color() build warning
- fix for mxsfb to ensure correct Linux logo position
Set the correct offset length and chip address offset mask for each
device to allow correct access to total capacity of the devices.
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Since commit bcee8d6764 ("dm: gpio: Allow control of GPIO uclass in SPL")
CONFIG_DM_74X164 is no longer built for mx7dsabresd_defconfig, as
this target does not use CONFIG_SPL_GPIO.
Remove such dependency and let the the 74X164 GPIO driver be built
again.
This restores Ethernet functionality on the imx7-sdb board as the
Ethernet reset PHY comes from a GPIO driven by a 74LV595PW I/O
expander.
Fixes: bcee8d6764 ("dm: gpio: Allow control of GPIO uclass in SPL")
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Alifer Moraes <alifer.wsdm@gmail.com>
Add serial UART driver support for all Cortina Access
CAxxxx family of SoCs.
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Jason Li <jason.li@cortina-access.com>
Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.com>
Add support for hardware watchdog timer on all Cortina Access
CAxxxx family of SoCs.
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Jason Li <jason.li@cortina-access.com>
Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.com>
DM_GPIO based GPIO controller driver for CAxxxx SoCs.
This driver support multiple CPU architectures and
Cortina Access SoC platforms.
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Jason Li <jason.li@cortina-access.com>
Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.com>
building mtk ethernet driver for aarch64 (mt7622) results
in warnings/errors
"error: cast from pointer to integer of different size"
Fixes: 23f17164d9 ("ethernet: MediaTek: add ethernet driver for MediaTek ARM-based SoCs")
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
This patch add sgmii init part for the mediatek SoC that
support sgmii mode. It is a must for mt7622.
Signed-off-by: MarkLee <Mark-MC.Lee@mediatek.com>
H1 is a Google security chip present in recent Chromebooks, Pixel phones
and other devices. Cr50 is the name of the software that runs on H1 in
Chromebooks.
This chip is used to handle TPM-like functionality and also has quite a
few additional features.
Add a driver for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present driver model supports the IRQ uclass but there is no way to
request a particular interrupt for a driver.
Add a mechanism, similar to clock and reset, to read the interrupts
required by a device from the device tree and to request those interrupts.
U-Boot itself does not have interrupt-driven handlers, so just provide a
means to read and clear an interrupt. This can be useful to handle
peripherals which must use an interrupt to determine when data is
available, for example.
Bring over the basic binding file as well, from Linux v5.4. Note that the
older binding is not supported in U-Boot; the newer 'special form' must be
used.
Add a simple test of the new functionality.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add an IRQ type to each driver and use irq_first_device_type() to find
and probe the correct one.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There can be different types of interrupt controllers in a system and some
drivers may need to distinguish between these. In general this can be
handled using the device tree by adding the interrupt information to
device nodes.
However on x86 devices we have interrupt controllers which are not tied
to any particular device and not really used in U-Boot. These still need
to be inited, so a convenient method is to give each controller a type
and allow a particular controller type to be probed.
Add support for this in sandbox along with a test.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: remove the new bland line at EOF of test/dm/irq.c]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
So far we have avoided adding a clock driver for Intel devices. But the
Designware I2C driver needs a different clock (133MHz) on Intel devices
than on others (166MHz). Add a simple driver that provides this
information.
This driver can be expanded later as needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Now that we have uclass_first_device_drvdata(), use it from the I2C driver
to reduce code duplication.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Now that we have uclass_first_device_drvdata(), use it from syscon to
reduce code duplication.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It is sometimes useful to find a device in a uclass using only its driver
data. The driver data often indicates the 'subtype' of the device, e,g,
via its compatible string.
Add a function to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This partially reverts changes by commit 2cc393f32f
("video: make BPP and ANSI configs optional") since it
caused issues with other boards (missing LCD console
output on pinebook, x86 platform or sandbox). Enable
all disabled options again and opt out of not supported
color depth in board defconfigs.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Reported-by: Vagrant Cascadian <vagrant@debian.org>
Now that we can use direct access to the system malloc() in sandbox, drop
the remaining uses of os_malloc().
The only one remaining now is for the RAM buffer, which we do want to be
at a known address, so this is intended.
Signed-off-by: Simon Glass <sjg@chromium.org>
Most files don't need this header and it pulls in quite of lots of stuff,
malloc() in particular. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.
Move the compatibility features into a separate header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present devres.h is included in all files that include dm.h but few
make use of it. Also this pulls in linux/compat which adds several more
headers. Drop the automatic inclusion and require files to include devres
themselves. This provides a good indication of which files use devres.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
