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>
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>
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>
Currently, after config the clock rate, delay 10ms, this is quite a rough
method. Check the clock stable status in the present status register is
enough.
Tested-by: Ji Luo <ji.luo@nxp.com>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
After enabling OF_PLATDATA support to both MMC and GPIO drivers add the
support for card detection.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order to reduce the footprint of SPL by removing dtb and library
overhead, add OF_PLATDATA support to fsl_esdhc_imx. This initial
approach does not support card detection, which will be enabled after
adding OF_PLATDATA support to GPIO.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
As discussed in commit <addf358bac1d2bd0> rename fsl_esdhc_imx
driver to allow the OF_PLATDATA support.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The Linux coding style guide (Documentation/process/coding-style.rst)
clearly says:
It's a **mistake** to use typedef for structures and pointers.
Besides, using typedef for structures is annoying when you try to make
headers self-contained.
Let's say you have the following function declaration in a header:
void foo(bd_t *bd);
This is not self-contained since bd_t is not defined.
To tell the compiler what 'bd_t' is, you need to include <asm/u-boot.h>
#include <asm/u-boot.h>
void foo(bd_t *bd);
Then, the include direcective pulls in more bloat needlessly.
If you use 'struct bd_info' instead, it is enough to put a forward
declaration as follows:
struct bd_info;
void foo(struct bd_info *bd);
Right, typedef'ing bd_t is a mistake.
I used coccinelle to generate this commit.
The semantic patch that makes this change is as follows:
<smpl>
@@
typedef bd_t;
@@
-bd_t
+struct bd_info
</smpl>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
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>
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>
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>
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>
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>
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>
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>
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>
To enable HS400(ES) and UHS for imx8m platforms, update the driver data
to share with imx8qm esdhc_soc_data.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
During mmc initialization, there are several calls to mmc_set_clock
and mmc_set_ios. When mmc_power_off, the mmc->clock will be set,
but the imx driver will use 400KHz. So the following calls
to mmc_set_ios will set the clock several times which is redundant
in fsl_esdhc_imx driver. So let's simplify to remove redundant
clock settings.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Flash system partition with fastboot will earse the partition firstly
The 600ms timeout will fail on some SD Card. Enlarge it to 5s to make
it works for most of sdcard
Cc: guoyin.chen <guoyin.chen@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Implement set_enhanced_strobe hook for fsl_esdhc_imx,
,in esdhc_set_timing and esdhc_change_pinstate, also handle HS400_ES.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Should use CONFIG_IS_ENABLED not IS_ENABLED for clock and regulator drivers,
CONFIG_IS_ENABLED will check the CONFIG_SPL_CLK and CONFIG_SPL_DM_REGULATOR
when building SPL.
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The fsl_esdhc driver was for Freescale eSDHC on MPC83XX/MPC85XX
initially. The later QoriQ series PowerPC processors (which were
evolutions of MPC83XX/MPC85XX), QorIQ series ARM processors, and
i.MX series processors were using this driver for their eSDHCs too.
For the two series processors, the eSDHCs are becoming more and
more different. We should have split it into two drivers, like them
(sdhci-of-esdhc.c/sdhci-esdhc-imx.c) in linux kernel.
This patch is just to create a fsl_esdhc_imx driver which is a copy
of fsl_esdhc driver for i.MX processors. We will convert i.MX processors
to use fsl_esdhc_imx, and clean up the two drivers separately in the
future patches.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Tested-by: Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
