| Age | Commit message (Collapse) | Author |
|---|
|
https://gitlab.denx.de/u-boot/custodians/u-boot-mips into next
- net: pcnet: cleanup and add DM support
- Makefile: add rule to build an endian-swapped U-Boot image
used by MIPS Malta EL variants
- CI: add Qemu tests for MIPS Malta
|
|
Add driver model (DM) support.
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
|
|
Move CONFIG_PXA_MMC_GENERIC to Kconfig.
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Add missing space before a comment delimiter.
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@toradex.com>
|
|
This converts the following to Kconfig:
CONFIG_ARM_PL180_MMCI
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
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
|
|
Driver is not calling gd anywhere that's why there is not need to define
it.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
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>
|
|
- Convert fsl_espi to driver model (Chuanhua)
- Enable am335x baltos to DM_SPI (Jagan)
- Drop few powerpc board which doesn't have DM enabled (Jagan)
|
|
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>
|
|
No need to poll register for card inserted status.
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 uncommon header out of the common header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Move this uncommon header out of the common header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Move this uncommon header out of the common header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Move this header out of the common header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Move this uncommon header out of the common header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
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>
|
|
Have this symbol follow the pattern of all other such symbols.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
|
|
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>
|
|
move host.mmc before sdhci_setup_cfg
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty@broadcom.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>
|
|
Enable SDHCI_QUIRK_BROKEN_R1B quirk.
Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
|
|
Free the pointer variable 'iproc_sdhci' upon failure to fix
possible memory leak.
Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@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>
|
|
Export function mmc_send_ext_csd() for reading the extended CSD register.
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>
|
