The driver currently reads the card-detect but does not register it with
the MMC stack. Update this so that card-detect works as expected.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function finds a device by its driver_info index. With
of-platdata-inst we do not use driver_info, but instead instantiate
udevice records at build-time.
However the semantics of using the function are the same in each case:
the caller provides an index and gets back a device.
So rename the function to device_get_by_ofplat_idx(), so that it can be
used for both situations. The caller does not really need to worry about
the details.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
The PCI MMC driver depends on the generic MMC SDHCI driver,
otherwise it does not compile.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Add tuning functionality which is needed for HS200 mode.
For HS200, program the correct needed 1.8 voltage
Signed-off-by: Bharat Gooty <bharat.gooty@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
On imx6Q/imx6DL, we find if config the DTOCV to 0~3, it will impact
cmd6 behavior, after cmd6 get transfer complete interrupt, the data0
line will keep low over 5 seconds. This should be a IC bug on imx6Q/DL.
For other platforms, do not has this issue.
To fix this issue, fix the DTOCV to 0xE, the max setting, this also align
with Linux configuration.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Add a compatible for i.MX51 so that i.MX51 can use this driver
via driver model.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
This adds support writing to the sandbox mmc backed by an in-memory
buffer. The unit test has been updated to test reading, writing, and
erasing. I'm not sure what MMCs erase to; I picked 0, but if it's 0xFF
then that can be easily changed.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
qspi:
- Support for dual/quad mode
- Fix speed handling
clk:
- Add clock enable function for zynq/zynqmp/versal
gem:
- Enable clock for Versal
- Fix error path
- Fix mdio deregistration path
fpga:
- Fix buffer alignment for ZynqMP
xilinx:
- Fix reset reason clearing in ZynqMP
- Show silicon version in SPL for Zynq/ZynqMP
- Fix DTB selection for ZynqMP
- Rename zc1275 to zcu1275 to match DT name
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQbPNTMvXmYlBPRwx7KSWXLKUoMIQUCYDUezQAKCRDKSWXLKUoM
IbtgAJ9jZ+BOtwFaHR19TENC2DsHTINnnwCfSDn3fU0OFJRI0HD7pRxXr4xrb3M=
=Kr8x
-----END PGP SIGNATURE-----
Merge tag 'xilinx-for-v2021.04-rc3' of https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze
Xilinx changes for v2021.04-rc3
qspi:
- Support for dual/quad mode
- Fix speed handling
clk:
- Add clock enable function for zynq/zynqmp/versal
gem:
- Enable clock for Versal
- Fix error path
- Fix mdio deregistration path
fpga:
- Fix buffer alignment for ZynqMP
xilinx:
- Fix reset reason clearing in ZynqMP
- Show silicon version in SPL for Zynq/ZynqMP
- Fix DTB selection for ZynqMP
- Rename zc1275 to zcu1275 to match DT name
A lot of Xilinx drivers are checking -ENOSYS which means that clock driver
doesn't have enable function. Remove this checking from drivers and create
dummy enable function as was done for clk_fixed_rate driver by
commit 6bf6d81c11 ("clk: fixed_rate: add dummy enable() function").
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
mmc_spi_sendcmd(), mmc_spi_readdata() and mmc_spi_writedata() are
currently undocumented. Add comment blocks to explain the arguments
and the return value.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
After command is sent and before card response shows up on the line,
there is a variable number of clock cycles in between called Ncr.
The spec [1] says the minimum is 1 byte and the maximum is 8 bytes.
Current logic in mmc_spi_sendcmd() has a flaw that it could only work
with certain SD cards with their Ncr being just 1 byte.
When resp_match is false, the codes try to receive only 1 byte from
the SD card. On the other hand when resp_match is true, the logic
happens to be no problem as it loops until timeout to receive as many
bytes as possible to see a match of the expected resp_match_value.
However not every call to mmc_spi_sendcmd() is made with resp_match
being true hence this exposes a potential issue with SD cards that
have a larger Ncr value.
Given no issue was reported as of today, we can reasonably conclude
that all cards being used on the supported boards happen to have a 1
byte Ncr timing requirement. But a broken case can be triggered by
utilizing QEMU to emulate a larger value of Ncr (by default 1 byte
Ncr is used on QEMU). This commit fixes such potential spec violation
to improve the card compatibility.
[1] "Physical Layer Specification Version 8.00"
chapter 7.5.1: Command / Response
chapter 7.5.4: Timing Values
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The argument check should happen before any transfer on the SPI lines.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
After issuing the switch command: Wait until 'current state' of the card
status becomes 'tran'. This prevents from response timeout at the next
command because of 'current state' = 'data'.
Signed-off-by: Stefan Bosch <stefan_b@posteo.net>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
If DMA(SDMA or ADMA) is not used, the cache invalidation
after reading is no need, should be skipped. Otherwise
U-Boot may hang at the cache invalidation.
Found this issue and tested this fix on DragonBoard 410c.
Fixes: commit 4155ad9aac ("mmc: sdhci: fix missing cache invalidation after reading by DMA")
Signed-off-by: Yuezhang.Mo <Yuezhang.Mo@sony.com>
Reviewed-by: Andy Wu <Andy.Wu@sony.com>
This will allow us to use DM variants of phys_to_bus()/bus_to_phys()
when relevant.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Call mmc_of_parse() so that generic DT properties like 'non-removable'
are taken into account.
This fixes boot on Clearfog with eMMC on SOM that requires the
non-removable property.
Reported-by: Thorsten Spille <thorsten_spille@netcor.de>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Use the generic sdhci_set_control_reg() instead of duplicating
in platform driver.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
According to the AM654x Data Manual[1], the setup timing in lower speed
modes can only be met if the controller uses a falling edge data launch.
To ensure this, the HIGH_SPEED_ENA (HOST_CONTROL[2]) bit should be
cleared in default speed, SD high speed, MMC high speed, SDR12 and SDR25
speed modes.
Use the sdhci writeb callback to implement this condition.
[1] http://www.ti.com/lit/gpn/am6546 Section 5.10.5.16.1
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
With the new SW tuning App note[1], a custom tuning algorithm is
required for eMMC HS200, HS400 and SD card UHS modes. The algorithm
involves running through the 32 possible input tap delay values and
sending the appropriate tuning command (CMD19/21) for each of them
to get a fail or pass result for each of the values. Typically, the
range will have a small contiguous failing window. Considering the
tuning range as a circular buffer, the algorithm then sets a final
tuned value directly opposite to the failing window.
[1] https://www.ti.com/lit/pdf/spract9
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Add support for writing new clock buffer select property for both
the am654x and j721e 4 bit IPs
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
DLL need only be enabled for speed modes and clock frequencies at or
above 50 MHz. For speed modes that don't enable the DLL, we need to
configure a static input delay value. This involves reading an optional
itap-del-sel-* value from the device tree and configuring it for the
appropriate speed mode.
Therefore, move all dll configurations to their own functions and gate it
with 50 MHz speed and a minimum mode. If both these conditions are not
satisfied then configure delay chain modes.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Add Support for AM65x PG2.0. Use the SoC bus framework to fixup
the platform data and do DLL calibration if the revision is 1.0
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Not all controllers need calibration for the PHY DLL. Add a DLL_CALIB
flag to indicate the same.
Also move the write of trm_icp and driver strength to the set_clock()
function to match the kernel configuration flow.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Convert the flags field defines to use the BIT() macro.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
There are some speed modes that work without switching the dll on.
Unconditionally switch off the DLL before setting clock frequency to
support this case. The software will automatically enable DLL for speed
modes that require it. This also means the dll_on priv data member is no
longer required.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Add a set_voltage() function which handles the switch from 3.3V to 1.8V
for SD card UHS modes.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
The R-Car3 SDHI should set these two bits in DMA_MODE register according
to the specification, to indicate 64bit bus width. No other bus width
options are permitted and the default value is 0, which is incorrect.
Set the bits accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Set this flag so that it is available to those looking at the device. For
non-removable devices there is no need to check for insertion/removable
since the media can never change.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
At present if an eMMC part is in the system, the ACPI table generated
will include information about that, as well as the SD card. We only need
to include the SD card, since it has a card-detect GPIO. Use a different
compatible string for each option, and add code only for the SD card.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
This change extends previous commit 061c6d1b23 ("arm: mvebu: Espressobin:
Detect presence of emmc at runtime") and when emmc is not present then emmc
is removed from U-Boot DM and corresponding slot is disabled. Therefore on
Espressobin board without soldered emmc, state of emmc hw should be same as
if emmc was disabled in DTS.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
So far the only difference between the various Allwinner MMC controller
we are concerned about is the mod clock register offset.
This is actually not directly related to the MMC controller IP, but an
integration choice, dependent on the SoC this appears in.
To avoid becoming trapped with some compatible fallback strings, let's
remove the whole struct sunxi_mmc_variant, and replace this with a SoC
based choice, which we can derive from the CONFIG_MACH_SUNx_y symbols.
This will later simplify H616 support.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
It turns out that several SoCs share same mmc configuration as H6. In
order to lower ifdef clutter replace H6 specific macro with common one.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Currently this driver does not set the value of plat->cfg.f_max, which
results in that MMC framework will always run at the lowest frequency.
This patch sets plat->cfg.f_max to the maximum allowed frequency, which
equals to the source clock frequency.
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
The driver is missing pad control settings (pad delay and pad conf) for
the mt7620 and mt76x8. Although mt76x8 still works well, mt7620 will
encounter CRC error on data transfers.
This patch adds default pad control settings for mt7620_compat.
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
It turns out that the sclk cycles used by mt7620/mt7628 is the same as
other chips (20 bits, 1048576), not 65536.
This patch removes sclk_cycle_shift from dev_comp, and uses a macro with
a value 20 instead.
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
There is no need to define the same macros in drivers.
All macros have been added by commit 17a42abb40 ("mmc: Define timing
macro's").
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Freeing a buffer before calling hang() is superfluous. Removing the call
reduces the SPL size.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>