We use the U_BOOT_ prefix (i.e. U_BOOT_DRIVER) to declare a driver but
in every other case we just use DM_. Update the alias macros to use the
DM_ prefix.
We could perhaps rename U_BOOT_DRIVER() to DM_DRIVER(), but this macro
is widely used and there is at least some benefit to indicating it us a
U-Boot driver, particularly for code ported from Linux. So for now, let's
keep that name.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present ofnode is present in the device even if it is never used. With
of-platdata this field is not used, so can be removed. In preparation for
this, change the access to go through inline functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
We have two functions which do the same thing. Standardise on
dev_has_ofnode() since there is no such thing as an 'invalid' ofnode in
normal operation: it is either null or missing.
Also move the functions into one place.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Most drivers use these access methods but a few do not. Update them.
In some cases the access is not permitted, so mark those with a FIXME tag
for the maintainer to check.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Pratyush Yadav <p.yadav@ti.com>
Currently, when different spi slaves claim the bus consecutively using
spi_claim_bus(), spi_set_speed_mode() will only be executed on the first
two calls, leaving the bus in a bad state starting with the third call.
This patch drops spi_slave->speed member and adds caching of bus
speed/mode in dm_spi_bus struct. It also updates spi_claim_bus() to call
spi_set_speed_mode() if either speed or mode is different from what the
bus is currently configured for. Current behavior is to only take into
account the speed, but not the mode, which seems wrong.
Fixes: 60e2809a84 ("dm: spi: Avoid setting the speed with every transfer")
Reviewed-by: Simon Glass <sjg@chromium.org>
Reported-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reported-by: Moshe, Yaniv <yanivmo@amazon.com>
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Several Octeon drivers operate by setting the sequence number of their
device. This should not be needed with the new sequence number setup. Also
it is not permitted. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present various drivers etc. access the device's 'seq' member directly.
This makes it harder to change the meaning of that member. Change access
to go through a function instead.
The drivers/i2c/lpc32xx_i2c.c file is left unchanged for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
This name is far too long. Rename it to remove the 'data' bits. This makes
it consistent with the platdata->plat rename.
Signed-off-by: Simon Glass <sjg@chromium.org>
We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).
Rename some of the latter variables to end with 'plat' for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.
Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
Regulator can be set to "always-on".
It's not error about enable/disable. It needs to check about
its condition.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
It's useful to know an error number when it's debugging.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
For eMMC HS400 mode, the DLL reset is a required step for mmc rescan.
This step has not been documented in reference manual, but the RM will
be fixed sooner or later.
In previous commit to support eMMC HS400,
db8f936 mmc: fsl_esdhc: support eMMC HS400 mode
the steps to configure DLL could be found in commit message,
13. Set DLLCFG0[DLL_ENABLE] and DLLCFG0[DLL_FREQ_SEL].
14. Wait for delay chain to lock.
these would be fixed as,
13. Set DLLCFG0[DLL_ENABLE] and DLLCFG0[DLL_FREQ_SEL].
13.1 Write DLLCFG0[DLL_RESET] to 1 and wait for 1us,
then write DLLCFG0[DLL_RESET]
14. Wait for delay chain to lock.
This patch is to add the step of DLL reset, and make sure delay chain
locked for HS400.
Fixes: db8f93672b ("mmc: fsl_esdhc: support eMMC HS400 mode")
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The initial clock setting should be through sysctl register only,
while the mmc_set_clock() will call mmc_set_ios() introduce other
configurations like bus width, mode, and so on.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
All of the existing quirks add retries to various calls of mmc_send_cmd.
mmc_send_cmd_quirks is a helper function to do this retrying behavior. It
checks if quirks mode is enabled, and if a specific quirk is activated it
retries on error.
This also adds mmc_send_cmd_retry, which retries on error every time
(instead of if a quirk is activated).
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Amlogic SM1 SoCs doesn't work over 50MHz. When phase sets to 270', it's
working fine over 50MHz on Amlogic SM1 SoCs.
Since Other Amlogic SoCs doens't report an issue, phase value is using
to 180' by default.
To distinguish which value is used adds an u-boot only sm1 compatible.
In future, it needs to find what value is a proper about each SoCs.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Move the asm/arch-meson/sd_emmc.h to a local meson_gx_mmc.h,
remove the useless if/then and fix the meson_gx_mmc.c include.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
At present we use a 'node' pointer in the of-platadata phandle_n_arg
structs. This is a pointer to the struct driver_info for a particular
device, and we can use it to obtain the struct udevice pointer itself.
Since we don't know the struct udevice pointer until it is allocated in
memory, we have to fix up the phandle_n_arg.node at runtime. This is
annoying since it requires that SPL's data is writable and adds a small
amount of extra (generated) code in the dm_populate_phandle_data()
function.
Now that we can find a driver_info by its index, it is easier to put the
index in the phandle_n_arg structures.
Update dtoc to do this, add a new device_get_by_driver_info_idx() to look
up a device by drive_info index and update the tests to match.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fix the condition to set UHS timings for speeds upto HS200.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Define default values for input and output clock phase delays for
Versal. Also define functions for setting tapdelays based on these
clock phase delays.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Define and use functions for setting input and output tapdelays
based on clk phase delays.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Define input and output clock phase delays with pre-defined values.
Define arasan_sdhci_clk_data type structure and add it to priv
structure and store these clock phase delays in it.
Read input and output clock phase delays from dt. If these values are
not passed through dt, use pre-defined values.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Just group macros below headers. Other patches will be using this location
too.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Define timing macro's for all the available speeds of mmc. This is
done similar to linux. Replace speed macro's used with these new timing
macro's wherever applicable.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
This reverts commit 942b5fc032.
This is partial revert of the above commit.
mmc_of_parse() is reading no-1-8-v from device tree and if set,
it is clearing the UHS speed capabilities of cfg->host_caps.
cfg->host_caps &= ~(UHS_CAPS | MMC_MODE_HS200 |
MMC_MODE_HS400 | MMC_MODE_HS400_ES);
This is still missing to clear UHS speeds like SDHCI_SUPPORT_SDR104,
SDHCI_SUPPORT_SDR50 and SDHCI_SUPPORT_DDR50.
Even if we clear the flags SDHCI_SUPPORT_XXX in mmc_of_parse(),
these speed flags are getting set again in cfg->host_caps in
sdhci_setup_cfg().
The reason for this is, SDHCI_SUPPORT_XXX flags are cleared
only if controller is not capable of supporting MMC_VDD_165_195 volts.
if (caps & SDHCI_CAN_VDD_180)
cfg->voltages |= MMC_VDD_165_195;
if (!(cfg->voltages & MMC_VDD_165_195))
caps_1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
SDHCI_SUPPORT_DDR50);
It means "no-1-8-v", which is read from DT is not coming in to effect.
So it is better we keep the host quirks(SDHCI_QUIRK_NO_1_8_V) to
clear UHS speeds based on no-1-8-v from device tree.
Hence revert the functionality related to no-1-8-v only, rest is fine
in the patch.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
dev_err has been used for debugging and a few dev_err message are
printed for normal code execution. Make them dev_dbg instead.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
mmc_of_parse() can populate the 'f_max' and 'host_caps' fields of
struct mmc_config from devicetree.
The same logic is duplicated in stm32_sdmmc2_probe(). Use
mmc_of_parse(), which is more generic.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
"cap-mmc-highspeed" enables support for 26 MHz MMC, but there is no
additional flag to enable 52 MHz MMC. In Linux. "cap-mmc-highspeed"
is used for MMC HS at both 26MHz and 52MHz.
Use the same approach and enable MMC_CAP(MMC_HS_52) host capability
when "cap-mmc-highspeed" is found in the devicetree. In the event an
MMC card doesn't support 52 MHz, it will be clocked at a speed based
on its EXT CSD, even on 52 MHz host controllers
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Remove a left-over debug test message from the Octeon TX / TX2
MMC driver.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Aaron Williams <awilliams@marvell.com>
Cc: Suneel Garapati <sgarapati@marvell.com>
Cc: Chandrakala Chavva <cchavva@marvell.com>
- fsl_esdhc_imx cleanup
- not send cm13 if send_status is 0.
- Add reinit API
- Add mmc HS400 for fsl_esdhc
- Several cleanup for fsl_esdhc
- Add ADMA2 for sdhci
Since it's so trivial I could just about tolerate this when there were only
two copies of it. But now there are about to be three.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Newer eSDHC controllers support ADMA2 descriptor tables which support
64bit DMA addresses. One notable user of addresses in the upper memory
segment is the EFI loader.
If support is enabled, but the controller doesn't support ADMA2, we
will fall back to SDMA (and thus 32 bit DMA addresses only).
Signed-off-by: Michael Walle <michael@walle.cc>
Currently, readl/writel and esdhc_read32/esdhc_write32 are used. To align
the usage, change to only use esdhc_read32/esdhc_write32.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
There are other (non-SDHCI) controllers which supports ADMA2 descriptor
tables, namely the Freescale eSDHC. Instead of copying the code, move it
into an own module.
Signed-off-by: Michael Walle <michael@walle.cc>
First, we need the waterlevel setting for PIO mode only. Secondy, both DMA
setup code is identical for both directions, except for the data pointer.
Thus, unify them.
Signed-off-by: Michael Walle <michael@walle.cc>
Use the dma_{map,unmap}_single() calls. These will take care of the
flushing and invalidation of caches.
Signed-off-by: Michael Walle <michael@walle.cc>
SDMA can only do DMA with 32 bit addresses. This is true for all
architectures (just doesn't apply to 32 bit ones). Simplify the code and
remove unnecessary CONFIG_FSL_LAYERSCAPE.
Also make the error message more concise.
Signed-off-by: Michael Walle <michael@walle.cc>
This 1ms delay before sending command already exist from the beginning
of the fsl_esdhc driver added in year 2008. Now this driver has been
split for two files: fsl_esdhc.c and fsl_esdhc_imx.c. fsl_esdhc_imx.c
only for i.MX series. i.MX series esdhc/usdhc do not need this 1ms delay
before sending any command. So remove this 1ms, this will save a lot
time if handling a large mmc data.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
According to the code logic in __mmc_switch, if the parameter 'send_status'
is zero, no need to send cmd13, just wait the stated timeout time, then
can return directly.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
There was a fix-up for eMMC HS400 stability issue in Linux.
Patch link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?id=58d0bf843b49fa99588ac9f85178bd8dfd651b53
Description:
Currently only LX2160A eSDHC supports eMMC HS400. According to
a large number of tests, eMMC HS400 failed to work at 150MHz,
and for a few boards failed to work at 175MHz. But eMMC HS400
worked fine on 200MHz. We hadn't found the root cause but
setting eSDHC_DLLCFG0[DLL_FREQ_SEL] = 0 using slow delay chain
seemed to resovle this issue. Let's use this as fixup for now.
Introduce the fix-up in u-boot since the issue could be reproduced
in u-boot too.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Fix mmc->clock with actual clock which is divided by the
controller, and record it with priv->clock which was removed
accidentally.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
The process for eMMC HS400 mode for eSDHC is,
1. Perform the Tuning Process at the HS400 target operating frequency.
Latched the clock division value.
2. if read transaction, then set the SDTIMNGCTL[FLW_CTL_BG].
3. Switch to High Speed mode and then set the card clock frequency to
a value not greater than 52Mhz
4. Clear TBCTL[TB_EN],tuning block enable bit.
5. Change to 8 bit DDR Mode
6. Switch the card to HS400 mode.
7. Set TBCTL[TB_EN], tuning block enable bit.
8. Clear SYSCTL[SDCLKEN]
9. Wait for PRSSTAT[SDSTB] to be set
10. Change the clock division to latched value.Set TBCTL[HS 400 mode]
and Set SDCLKCTL[CMD_CLK_CTRL]
11. Set SYSCTL[SDCLKEN]
12. Wait for PRSSTAT[SDSTB] to be set
13. Set DLLCFG0[DLL_ENABLE] and DLLCFG0[DLL_FREQ_SEL].
14. Wait for delay chain to lock.
15. Set TBCTL[HS400_WNDW_ADJUST]
16. Again clear SYSCTL[SDCLKEN]
17. Wait for PRSSTAT[SDSTB] to be set
18. Set ESDHCCTL[FAF]
19. Wait for ESDHCCTL[FAF] to be cleared
20. Set SYSCTL[SDCLKEN]
21. Wait for PRSSTAT[SDSTB] to be set.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Add a mmc_hs400_prepare_ddr() interface for controllers
which needs preparation before switching to DDR mode for
HS400 mode.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
