Versal:
- xspi bootmode fix
- Removing one clock from clk driver
- Align u-boot memory setting with OS by default
- Map TCM and OCM by default
ZynqMP:
- Minor DT improvements
- Reduce console buffer for mini configurations
- Add fix for AMS
- Add support for XDP platform
Zynq:
- Support for AES engine
- Enable bigger memory test by default
- Extend documentation for SD preparation
- Use different freq for Topic miami board
mmc:
- minor GD pointer removal
net:
- Support fixed-link cases by zynq gem
- Fix phy looking loop in axi enet driver
spi:
- Cleanup global macros for xilinx spi drivers
firmware:
- Add support for pmufw reloading
fpga:
- Improve error status reporting
common:
- Remove 4kB addition space for FDT allocation
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQbPNTMvXmYlBPRwx7KSWXLKUoMIQUCXvScEQAKCRDKSWXLKUoM
IeHUAJ9Z1shAlbILuHZKEpqQySLHdUVgBQCff8Nf+wi1rByTrwflKt14MtIsdFY=
=2Yuu
-----END PGP SIGNATURE-----
Merge tag 'xilinx-for-v2020.10' of https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze into next
Xilinx changes for v2020.10
Versal:
- xspi bootmode fix
- Removing one clock from clk driver
- Align u-boot memory setting with OS by default
- Map TCM and OCM by default
ZynqMP:
- Minor DT improvements
- Reduce console buffer for mini configurations
- Add fix for AMS
- Add support for XDP platform
Zynq:
- Support for AES engine
- Enable bigger memory test by default
- Extend documentation for SD preparation
- Use different freq for Topic miami board
mmc:
- minor GD pointer removal
net:
- Support fixed-link cases by zynq gem
- Fix phy looking loop in axi enet driver
spi:
- Cleanup global macros for xilinx spi drivers
firmware:
- Add support for pmufw reloading
fpga:
- Improve error status reporting
common:
- Remove 4kB addition space for FDT allocation
SDHCI HISPD bits need to be configured based on desired mmc
timings mode and some HISPD quirks.
So, handle the HISPD bit based on the mmc computed selected
mode(timing parameter) rather than fixed mmc card clock
frequency.
Linux handle the HISPD similar like this in below commit but no
SDHCI_QUIRK_BROKEN_HISPD_MODE,
commit <501639bf2173> ("mmc: sdhci: fix SDHCI_QUIRK_NO_HISPD_BIT handling")
This eventually fixed the mmc write issue observed in
rk3399 sdhci controller.
Bug log for refernece,
=> gpt write mmc 0 $partitions
Writing GPT: mmc write failed
** Can't write to device 0 **
** Can't write to device 0 **
error!
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Peng Fan <peng.fan@nxp.com>
Peng Fan: added back "ctrl &= ~SDHCI_CTRL_HISPD;" per Jaehoon's suggestion
Tested-by: Suniel Mahesh <sunil@amarulasolutions.com> # roc-rk3399-pc
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
According to eMMC specification v5.1 section 6.4.3, we should issue
CMD1 repeatedly in the idle state until the eMMC is ready even if
mmc_send_op_cond() send CMD1 with argument = 0. Otherwise some eMMC
devices seems to enter the inactive mode after mmc_complete_op_cond()
issued CMD0 when the eMMC device is busy.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
In current code, we add 1ms dealy after each tuning command for standard
tuning method. Adding this 1ms dealy is because USDHC default check the
CMD CRC and DATA line. If detect the CMD CRC, USDHC standard tuning
IC logic do not wait for the tuning data sending out by the card, trigger
the buffer read ready interrupt immediately, and step to next cycle. So
when next time the new tuning command send out by USDHC, card may still
not send out the tuning data of the upper command，then some eMMC cards
may stuck, can't response to any command, block the whole tuning procedure.
If do not check the CMD CRC for tuning, then do not has this issue. USDHC
will wait for the tuning data of each tuning command and check them. If the
tuning data pass the check, it also means the CMD line also okay for tuning.
So this patch disable the CMD CRC check for tuning, save some time for the
whole tuning procedure.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
We only call the function omap_hsmmc_get_cfg in the case of OMAP34XX or
when we have to iodelay recalibration. Add guards for these checks as
clang will otherwise warn.
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Unsupported voltage on voltage switch is not an error, do not
print error message in such a case. This happens e.g. if the
eMMC is already in 1V8 mode or when testing 1V2 mode operation
on systems which only do 3V3/1V8 switching.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The 3V3/1V8 switching could never have worked on any of the iMXes
ever since 51313b49f2 ("mmc: fsl_esdhc: support SDR104 and HS200"),
because that commit uses priv->vqmmc_dev when switching voltages on
mode switch, while local vqmmc_dev in probe to store the regulator
pointer. Those are two different variables with the same name. So
the priv->vqmmc_dev was always NULL and thus voltage switch between
modes never really suceeded.
Fix this by assigning priv->vqmmc_dev with value of the vqmmc_dev
in probe.
Fixes: 51313b49f2 ("mmc: fsl_esdhc: support SDR104 and HS200")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
- Rename DT compatible name
- Remove uneccessary if-statement to support 8-bit buswidth
- Remove redundant error msg
- Use symbolic constants in switch statement
Signed-off-by: Arthur Li <arthur.li@cortina-access.com>
Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.com>
CC: Peng Fan <peng.fan@nxp.com>
CC: Jaehoon Chung <jh80.chung@samsung.com>
CC: Tom Rini <trini@konsulko.com>
When eSDHC operates at 3.3v, damage can accumulate in an internal
level shifter at a higher than expected rate. The faster the interface
runs, the more damage accumulates. This issue now is found on LX2160A
eSDHC1 for only SD card.
The hardware workaround is recommended to use an on-board level shifter
that is 1.8v on SoC side and 3.3v on SD card side.
For boards without hardware workaround, this option could be enabled,
ensuring 1.8v IO voltage and disabling eSDHC if no card.
This option assumes no hotplug, and u-boot has to make all the way to
to linux to use 1.8v UHS-I speed mode if has card.
If you do not want the workaround for better user experience, of course
you can choose to not select it running eSDHC in unsafe mode.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Cleanup this driver to use dt in U-boot and static platdata in SPL.
This requires the following steps:
1. Move all platdata assignment from probe() to ofdata_to_platdata().
This function is only called in U-boot.
2. Replicate all the platdata assignment being done in
ofdata_to_platdata() in the omapl138 board file. This data is used in
the SPL case where SPL_OF_CONTROL is not enabled.
3. Remove SPL_OF_CONTROL and related configs from omapl138_lcdk_defconfig
This cleanup effectively reverts 3ef94715cc ('mmc: davinci: fix mmc boot in SPL')
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Tested-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.
Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.
Signed-off-by: Simon Glass <sjg@chromium.org>
- stm32mp1: add command stm32prog
- stm32mp1: several board and arch updates
- stm32mp1: activate data cache in SPL and before relocation
- Many improvment for AV96 board and DHCOR SoM
(add new defconfig, DDR3 coding on DHCOR SoM, split between board and SOM
Synchronize DDR setttings on DH SoMs, setting for I2C EEPROM)
- clk: stm32mp1: fix CK_MPU calculation
- DT alignment of stm32mp1 device tree with Linux 5.7-rc2
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE56Yx6b9SnloYCWtD4rK92eCqk3UFAl69FWMACgkQ4rK92eCq
k3Vy9wgAmFLZ+u2C87A9Cs8i73QX/hs9TsjTJJPxsQWy3bOILgw8ZqBtzqD0qPvc
Mpqq7UEIZ17OW/lZCi3hqC0nGj7bT3N9rDpUQfu5Voq3GoO80yZqvCQU04AXGGpW
Aj0fjI5a6JRxQfR7XVoNw7UXPDUrDlchvBDR1GMK4cj4Sw/B+pXNDjkoJ1UWbxG6
INDgQQKhOCdMzbIsMLiUe4zkT6E8ADI0eJzgti3kWBzrdkwXZg40iEJu/MbMPRKE
Y22QZ6EkEMFTVYeCPXLU8keo4UbBIKDXWmVDbDeDbNa0QrKZ2IZ0TijajWeMWxZV
Q9J7JgpSchWcVB14vYNx+HXPUHANTA==
=bhlu
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20200514' of https://gitlab.denx.de/u-boot/custodians/u-boot-stm
- stm32mp1: migrate MTD and DFU configuration in Kconfig
- stm32mp1: add command stm32prog
- stm32mp1: several board and arch updates
- stm32mp1: activate data cache in SPL and before relocation
- Many improvment for AV96 board and DHCOR SoM
(add new defconfig, DDR3 coding on DHCOR SoM, split between board and SOM
Synchronize DDR setttings on DH SoMs, setting for I2C EEPROM)
- clk: stm32mp1: fix CK_MPU calculation
- DT alignment of stm32mp1 device tree with Linux 5.7-rc2
Change the mmc displayed name in U-Boot for stm32_sdmmc2 driver to
“STM32 SD/MMC”.
This stm32_sdmmc2 driver is for version 2 of the ST HW IP SDMMC but the
displayed name "STM32 SDMMC2" is confusing for user, between the
instance of SDMMC and the device identifier of MMC.
For example on EV1 board, we have:
STM32MP1> mmc list
STM32 SDMMC2: 0 (SD)
STM32 SDMMC2: 1 (eMMC)
Changed to more clear:
STM32MP1> mmc list
STM32 SD/MMC: 0 (SD)
STM32 SD/MMC: 1 (eMMC)
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
If CONFIG_MMC_SDHCI_SDMA is enabled but the HW could not support it,
we no longer error out. Instead we do not enable it in the host.
Change the output from printf to debug as this isn't an error but only
additional information now.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
If Host controller doesn't support SDMA, it doesn't need to return
error. Because it can be worked with PIO mode.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Use phys2bus macro when dma address is accessed.
Some targets need to use pyhs2bus macro. (e.g, RPI4)
After applied it, SDMA mode can be used.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Currently, the entry "bus-width = <8>" in the ZynqMP's sdhci nodes
is not evaluated. This results in the bus width staying at its default
value (4 bit in HS200 mode).
Fix this by calling mmc_of_parse. This function also checks for the
"no-1-8-v" and "max-frequency" entries. Remove the handling of those
nodes from this driver.
Signed-off-by: Benedikt Grassl <Benedikt.Grassl@rohde-schwarz.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
This function does not modify the device to change it to use const *, so
that callers with a const udevice * can call it without a cast.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
RPMB support is used by the 'mmc rpmb' command and by the OP-TEE support.
We do not need it in SPL.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Implement get_b_max() for the Renesas R-Car SDHI controller driver, limit
the b_max per hardware capabilities such that select Gen2 controllers have
16bit block transfer limit, the rest has 32bit block transfer limit and on
Gen3, the block transfer limit on addresses above the 32bit boundary is set
to 1/4 of the malloc area.
Originally, on Gen3, the block transfers above the 32bit area were limited
to PIO only, which resulted in (R8A7795 Salvator-X , HS200 eMMC):
=> time mmc read 0x0000000700000000 0 0x10000
time: 0.151 seconds
=> time mmc read 0x0000000700000000 0 0x100000
time: 11.090 seconds
with bounce buffer in place and b_max adjustment in place:
=> time mmc read 0x0000000700000000 0 0x10000
time: 0.156 seconds
=> time mmc read 0x0000000700000000 0 0x100000
time: 2.349 seconds
Note that the bounce buffer does mallocate and free the bounce buffer
for every transfer. Experiment which removes this results in further
increase of read speed, from 2.349s to 2.156s per 512 MiB of data,
which is not such a significant improvement anymore. It might however
be interesting to have bounce buffer directly in the MMC core or even
block core.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Add getter function which permits adjusting the maximum number of
blocks that could be read in a single sustained read transfer based
on the location of the source/target buffer and length, before such
transfer starts.
This is mainly useful on systems which have various DMA restrictions
for different memory locations, e.g. DMA limited to 32bit addresses,
and where a bounce buffer is used to work around such restrictions.
Since the U-Boot bounce buffer is mallocated, it's size is limited
by the malloc area size, and the read transfer to such a buffer must
also be limited. However, as not all areas are limited equally, the
b_max should be adjusted accordinly as needed to avoid degrading
performance unnecessarily.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
The R-Car SDHI DMA controller has various restrictions. To work around
those restrictions without falling back to PIO, implement bounce buffer
with custom alignment check function which tests for those limitations.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
set_ios_post return type changed from void to int, correcting
the same to fix compilation warning.
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty@broadcom.com>
Provide command 'mmc wp' to power on write protect boot areas on eMMC
devices.
The B_PWR_WP_EN bit in the extended CSD register BOOT_WP is set. The boot
area are write protected until the next power cycle occurs.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
In R-Car Gen 3, there is a DMA controller restriction of SDHI.
When the transfer exceeding the 4 kByte boundary is performed while
the DRAM address is not 128 byte aligned, the bus is occupied.
This patch avoids this.
Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Until now, the mmc clock was left in a good enough state by the ROM
code to be used by the controller. However on some SoC, if the ROM
code finds a bootloader on USB or SPI, it might leave the MMC clock
in state the controller cannot work with.
Enable the input clocks provided to the mmc controller. While the
u-boot mmc controller driver is not doing fancy settings like the Linux,
it at least needs to make these clocks are running.
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
According to the HW team, for some reason the normal clock select code
picks what appears to be a perfectly valid 375KHz SD card clock, based
on the CAR clock source and SDMMC1 controller register settings (CAR =
408MHz PLLP0 divided by 68 for 6MHz, then a SD Clock Control register
divisor of 16 = 375KHz). But the resulting SD card clock, as measured by
the HW team, is 700KHz, which is out-of-spec. So the WAR is to use the
values given in the TRM PLLP table to generate a 400KHz SD-clock (CAR
clock of 24.7MHz, SD Clock Control divisor of 62) only for SDMMC1 on
T210 when the requested clock is <= 400KHz. Note that as far as I can
tell, the other requests for clocks in the Tegra MMC driver result in
valid SD clocks.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
As per the T210 TRM, when running at 3.3v, the SDMMC1 tap/trim and
autocal values need to be set to condition the signals correctly before
talking to the SD-card. This is the same as what's being done in CBoot,
but it gets reset when the SDMMC1 HW is soft-reset during SD driver
init, so needs to be repeated here. Also set autocal and tap/trim for
SDMMC3, although no T210 boards use it for SD-card at this time.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The 4 bit MMC controllers have an internal debounce for the SDCD line
with a debounce delay of 1 second. Therefore, after clocks to the IP are
enabled, software has to wait for this time before it can power on the
controller.
Add a deferred_probe() callback which polls on sdcd for a maximum of 2 seconds
before switching on power to the controller or (in the case of no card)
returning a ENOMEDIUM. This pushes the 1 second wait time to when the
card is actually needed rather than at every probe() making sure that
users who don't insert an SD card in the slot don't have to wait such a
long time.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
With the latest RIOT, there is a different otap delay value for each
speed mode. Add a new binding with every supported speed mode. Also
disable a given speed mode in the host caps if its corresponding
otap-del-sel is not present.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
MMC_LEGACY & SD_LEGACY are not differentiated timings in the spec and
don't have any meaningful differences. Therefore, get rid of all
references to SD_LEGACY and use MMC_LEGACY to mean both of them.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Add the sdhci_deferred_probe() function to register as the
deferred_probe() callback to the mmc core. It will in turn call the
deferred_probe() callback of the platform drivers as declared in the
sdhci_ops.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Add a deferred_probe() API for platforms that want to do some
configurations just before starting to enumerate the device.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Initial DesignWare based DM support for Cortina Access CAxxxx SoCs.
Signed-off-by: Arthur Li <arthur.li@cortina-access.com>
Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.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>
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>
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>
Drop local dma_map_single() and dma_unmap_single() and use arch specific
common implementation
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Read generic MMC properties from device-tree. This allows to specify for
example cd-inverted property and let MMC core to properly handle such
case.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
K3 J721E:
* DMA support.
* MMC and ADMA support.
* EEPROM support.
* J721e High Security EVM support.
* USB DT nodes
K3 AM654:
* Fixed boot due to pmic probe error.
* USB support and DT nodes.
* ADMA support
DRA7xx/AM57xx:
* BBAI board support
* Clean up of net platform code under board/ti
AM33/AM43/Davinci:
* Reduce SPL size for omap3 boards.
* SPL DT support for da850-lcdk
* PLL divider fix for AM335x
Add Support for writing to PHY registers for J721e. There are number of
differences between the J721e 8 bit PHY, J721e 4 bit PHY and AM654 PHY.
Create a driver_data structure with an ops and flags field and use the
flags field to indicate these differences. The differences are as
follows:
1. The J721e 4 bit instance PHY does not have a DLL. Introduce a
DLL_PRESENT flag to make sure that DLL related registers are accessed
only where they are present. Also add a separate set_ios_post()
callback.
2. The J721e 8 bit instance is not muxed with anything else inside the
SoC and hence the IOMUX_ENABLE filed does not exist. Add a flag which is
used to indicate the presence of this field.
3. The register field used to select DLL frequency is 3 bit wide in
J721e as compared to 2 bits in AM65x. Add another flag that
distinguishes these fields.
4. The strobe select field is 8 bit wide as compared to 4 bit wide for
AM65x. Add yet another flag to indicate this difference. Strobe select
is used only for HS400 speed mode, support for which has not been added
in AM65x.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Get clk_xin by name instead of by index to avoid having to put clocks in
the same order in all devices.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
At present panic() is in the vsprintf.h header file. That does not seem
like an obvious choice for hang(), even though it relates to panic(). So
let's put hang() in its own header.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Migrate a few more files]
Signed-off-by: Tom Rini <trini@konsulko.com>
This patch add mmc and sd support for Mediatek MT7622 SoCs
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Reviewed-by: Ryder Lee <ryder.lee@mediatek.com>
For CMD21 tuning data, the 128/64 bytes data may coming in very
short time, before msdc_start_data(), the read data has already
come, in this case, clear MSDC_INT will cause the interrupt disappear
and lead to the thread hang.
the solution is just clear all interrupts before command was sent.
Signed-off-by: mingming lee <mingming.lee@mediatek.com>
This patch adds mmc support for MediaTek MT8512/MT8110 SoCs.
MT8512/MT8110 SoCs puts the tune register at top layer, so
need add new code to support it.
Signed-off-by: mingming lee <mingming.lee@mediatek.com>
It was observed (on ClearFog Base) that sending MMC APP_CMD returned
an error on the first attempt. The issue appears to be timing related
since even inserting a puts() short debug entry before the execution
added sufficient delay to receive success on first attempt.
Follow the existing quirks pattern to retry if initial issuance
failed so as to not introduce any delay unless needed.
Signed-off-by: Joel Johnson <mrjoel@lixil.net>
The eSDHC reference clocks should be provided by speed.c in arch/.
And we do not need CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK option to
select which clock to use. Because we can make the driver to select
the periperhal clock which is better (provides higher frequency)
automatically if its value is provided by speed.c.
This patch is to drop this option and make driver to select clock
automatically. Also fix peripheral clock calculation issue in
fsl_lsch2_speed.c/fsl_lsch3_speed.c.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
The fdt fixup for properties "peripheral-frequency" and "adapter-type"
was once for a Freescale SDK release. The properties haven't been existed
in linux mainline. Drop these useless code.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Add compatible "fsl,imxrt-usdhc" to make mmc working on i.MXRT platforms
with CONFIG_DM_MMC=y.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Not all architectures(i.e. i.MXRT) support mxc_get_clock() and use DM_CLK
instead. So building could result in failure due to missing
mxc_get_clock().
Make if(CONFIG_IS_ENABLED(CLK)) an #if statement.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
When no GPIO is used to read the card detect status the following
error is seen:
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... MMC: no card present
*** Warning - No block device, using default environment
Fix it by handling the "broken-cd" property in the same way
that drivers/mmc/sdhci.c does, which considers that the SD card
is present when the "broken-cd" property is passed.
Tested on a imx6ul-evk board.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Stefano Babic <sbabic@denx.de>
Convert clock manager for Gen5, Arria 10 and Stratix 10 from struct
to defines.
Change to get clock manager base address from DT node instead of using
#define.
Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Convert system manager for Gen5, Arria 10 and Stratix 10 from struct
to defines.
Change to get system manager base address from DT node instead of
using #define.
Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Bring in the following merges:
commit 8fbbec12f7
Merge: 87f69f467a63618e71e8
Author: Tom Rini <trini@konsulko.com>
Date: Fri Jan 3 09:48:47 2020 -0500
Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq into next
- updates and fixes on ls1028a, lx2, ls1046a, MC-DPSPARSER support
commit 87f69f467a
Merge: c0912f9bbf4466b99703
Author: Tom Rini <trini@konsulko.com>
Date: Tue Dec 24 08:18:19 2019 -0500
Merge https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx into next
- Enable DM driver on ppc/km boards
- Enable DM_USB for some of NXP powerpc platforms: P5040, T4240, T208x,
T104x, P4080, P2041, P2020, P1020, P3041
- Some updates in mpc85xx-ddr driver, km boards
commit c0912f9bbf
Merge: 533c9f5714a1d6dc3f84
Author: Tom Rini <trini@konsulko.com>
Date: Wed Dec 18 07:20:19 2019 -0500
Merge branch 'next' of https://gitlab.denx.de/u-boot/custodians/u-boot-x86 into next
- Various x86 common codes updated for TPL/SPL
- I2C designware driver updated for PCI
- ICH SPI driver updated to support Apollo Lake
- Add Intel FSP2 base support
- Intel Apollo Lake platform specific drivers support
- Add a new board Google Chromebook Coral
commit 533c9f5714
Merge: 553cb06887033e18b47b
Author: Tom Rini <trini@konsulko.com>
Date: Tue Dec 17 07:53:08 2019 -0500
Merge tag '20191217-for-next' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2c into next
i2c: for next
- misc: i2c_eeprom:
Add partition support and add ability to query size
of eeprom device and partitions
- i2c common:
add support for offset overflow in to address and add
sandbox tests for it.
commit 553cb06887
Merge: f39abbbc53b4f98b3b16
Author: Tom Rini <trini@konsulko.com>
Date: Thu Dec 12 08:18:59 2019 -0500
Merge tag 'dm-next-13dec19' of https://gitlab.denx.de/u-boot/custodians/u-boot-dm into next
buildman improvements including toolchain environment feature
sandbox unicode support in serial
Adam Ford reports that this change breaks booting on da850-evm and
Bartosz Golaszewski agrees that with the impending release we should
revert the change for now. With that noted:
This reverts commit 21a4d80a71.
Cc: Bartosz Golaszewski <brgl@bgdev.pl>
Tested-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass
is included in SPL/TPL without any control for boards. Some boards may
want to disable this to reduce code size where GPIOs are not needed in
SPL or TPL.
Add a new Kconfig option to permit this. Default it to 'y' so that
existing boards work correctly.
Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to
preserve the current behaviour. Also update the 74x164 GPIO driver since
it cannot build with SPL.
This allows us to remove the hacks in config_uncmd_spl.h and
Makefile.uncmd_spl (eventually those files should be removed).
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The MMC boot is currently broken on omapl138-lcdk after enabling the
driver model in SPL. The main problem is the driver's bind callback not
being called after probe in SPL (even with the DM_FLAG_PRE_RELOC flag
specified).
While a proper fix is still being worked on, this hacky changeset at
least fixes the MMC boot on this platform by calling mmc_bind()
manually from probe().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
struct mmc_config & struct mmc don't need to be exported over platform
data, but can instead be private in the driver.
Remove struct davinci_mmc_plat.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The DM family of DaVinci SoCs is no longer supported. Drop the
irrelevant code from the driver.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
These functions are CPU-related and do not use driver model. Move them to
cpu_func.h
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This function belongs in time.h so move it over and add a comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Instead of using single fixed value for the calibration offset,
add tables which dynamically adjust this per calibration code
from the SCC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Some of the tuning taps produce suboptimal results. Add code
which skips those "bad" taps.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Check SCC for errors after check command if applicable and
optionally adjust the bus skew settings accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Disable the auto-retuning in HS400 mode in favor of manual calibration.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Adjust the TMPPORT3 offsets according to the latest information
from the chip vendor.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Adjust the DT2FF offsets in HS400 according to latest information
from the chip vendor.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
The M3W up to ES1.2 uses 4 tuning taps for HS400, make it so.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
