| Age | Commit message (Collapse) | Author |
|---|
|
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Use ENV_MMC_EMMC_HW_PARTITION to clarify this is the eMMC hardware
partition selector, not a software partition table entry selector.
Retain the ENV_MMC_ prefix to make it easier to search for all the
SD/MMC related ENV options. Update the help text accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
This file does not need <linux/sizes.h> nor <linux/compiler.h> so remove
them. This exposes however that a number of other files had been relying
on this implicit include for <linux/sizes.h> so add that where needed.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Add a new callback function *send_init_stream* which start a sequence of
at least 74 clock cycles.
The mmc core uses *mmc_send_init_stream* in order to invoke the callback
function. This will be used during power cycle where the specification
requires such a sequence after power up.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
resizing
Current mmc bootpart-resize command only support Samsung eMMC BOOT/RPMB
hardware partition resizing. Add Sandisk and Micron eMMC BOOT/RPMB hardware
partition resizing support. The commands and parameters for resizing
partitions are different for each manufacturer. Select the corresponding
function according to CID.
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Simplify 90cc07fd786d ("mmc: Poll CD in case cyclic framework is enabled")
according to suggestions by Rasmus. The struct cyclic_info is zero-size in
case CONFIG_CYCLIC is not enabled and does not add any size to struct mmc,
so it can unconditionally be part of that structure. This allows clean up
of all the other conditionals in mmc.c which can now be unconditionally
present, as they also add no extra space.
Suggested-by: Rasmus Villemoes <ravi@prevas.dk>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
The alignment hole caused by cmdidx in struct mmc_cmd cause strange
issues together with the peephole2 optimization on Amlogic SoCs.
Following was observed while working on SPL support for Amlogic SoCs.
sd_get_capabilities() normally issue a CMD55 followed by a CMD51.
However, on at least Amlogic S905 (Cortex-A53) and S905X3 (Cortex-A55),
CMD55 was instead followed by CMD8 (and a few reties) in SPL.
Code from the call site:
cmd.cmdidx = SD_CMD_APP_SEND_SCR; // 51
...
data.blocksize = 8;
...
err = mmc_send_cmd_retry(mmc, &cmd, &data, 3);
Running the code with MMC_TRACE enabled shows:
CMD_SEND:55
ARG 0x50480000
MMC_RSP_R1,5,6,7 0x00000920
CMD_SEND:8
ARG 0x00000000
RET -110
Removing the alignment hole by changing cmdidx from ushort to uint or
building with -fno-peephole2 flag seem to resolve this issue.
CMD_SEND:55
ARG 0x50480000
MMC_RSP_R1,5,6,7 0x00000920
CMD_SEND:51
ARG 0x00000000
MMC_RSP_R1,5,6,7 0x00000920
Same issue was observed building U-Boot with gcc 8 - 13.
Remove this alignment hole by changing cmdidx from ushort to uint.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
|
|
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
In case the cyclic framework is enabled, poll the card detect of already
initialized cards and deinitialize them in case they are removed. Since
the card initialization is a longer process and card initialization is
done on first access to an uninitialized card anyway, avoid initializing
newly detected uninitialized cards in the cyclic callback.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Tim Harvey <tharvey@gateworks.com> says:
Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC
specification described as:
Boot Area Partition 1
Boot Area Partition 2
RPMB Partition
General Purpose Partition 1
General Purpose Partition 2
General Purpose Partition 3
General Purpose Partition 4
User Data Area
These are referenced by fields in the PARTITION_CONFIG register
(Extended CSD Register 179) which is defined as:
bit 7: reserved
bit 6: BOOT_ACK
0x0: No boot acknowledge sent (default
0x1: Boot acknowledge sent during boot operation Bit
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Note that setting PARTITION_ACCESS to 0x0 results in selecting the User
Data Area partition.
You can see above that the two fields BOOT_PARTITION_ENABLE and
PARTITION_ACCESS do not use the same enumerated values.
U-Boot uses a set of macros to access fields of the PARTITION_CONFIG
register:
EXT_CSD_BOOT_ACK_ENABLE (1 << 6)
EXT_CSD_BOOT_PARTITION_ENABLE (1 << 3)
EXT_CSD_PARTITION_ACCESS_ENABLE (1 << 0)
EXT_CSD_PARTITION_ACCESS_DISABLE (0 << 0)
EXT_CSD_BOOT_ACK(x) (x << 6)
EXT_CSD_BOOT_PART_NUM(x) (x << 3)
EXT_CSD_PARTITION_ACCESS(x) (x << 0)
EXT_CSD_EXTRACT_BOOT_ACK(x) (((x) >> 6) & 0x1)
EXT_CSD_EXTRACT_BOOT_PART(x) (((x) >> 3) & 0x7)
EXT_CSD_EXTRACT_PARTITION_ACCESS(x) ((x) & 0x7)
There are various places in U-Boot where the BOOT_PARTITION_ENABLE field
is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a
hardware partition consistent with the definition of the
PARTITION_ACCESS field used by the various mmc_switch incarnations.
To add some sanity to the distinction between BOOT_PARTITION_ENABLE
(used to specify the active device on power-cycle) and PARTITION_ACCESS
(used to switch between hardware partitions) create two enumerated types
and use them wherever struct mmc * part_config is used or the above
macros are used.
Additionally provide arrays of the field names and allow those to be
used in the 'mmc partconf' command and in board support files.
The first patch adds enumerated types and makes use of them which
represents no compiled code change.
The 2nd patch adds the array of names and uses them in the 'mmc
partconf' command.
The 3rd patch uses the array of hardware partition names in a board
support file to show what emmc hardware partition U-Boot is being loaded
from.
|
|
eMMC v4+ devices have hardware partitions that are accessed via the
PARTITION_CONFIG (Extended CSD Register 179) PARTITION_ACCESS
and BOOT_PARTITION_ENABLE fields defined as:
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Add char arrays to provide names for these values.
Use these names which displaying or setting the PARTITION_CONFIG
register via the 'mmc partconf' command.
Before:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2
PARTITION_ACCESS: 0x0
After:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x1 (boot0)
PARTITION_ACCESS: 0x0 (user)
u-boot=> mmc partconf 2 1 boot1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2 (boot1)
PARTITION_ACCESS: 0x0 (user)
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
|
|
Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC
specification described as:
Boot Area Partition 1
Boot Area Partition 2
RPMB Partition
General Purpose Partition 1
General Purpose Partition 2
General Purpose Partition 3
General Purpose Partition 4
User Data Area
These are referenced by fields in the PARTITION_CONFIG register
(Extended CSD Register 179) which is defined as:
bit 7: reserved
bit 6: BOOT_ACK
0x0: No boot acknowledge sent (default
0x1: Boot acknowledge sent during boot operation Bit
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Note that setting PARTITION_ACCESS to 0x0 results in selecting the User
Data Area partition.
You can see above that the two fields BOOT_PARTITION_ENABLE and
PARTITION_ACCESS do not use the same enumerated values.
U-Boot uses a set of macros to access fields of the PARTITION_CONFIG
register:
There are various places in U-Boot where the BOOT_PARTITION_ENABLE field
is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a
hardware partition consistent with the definition of the
PARTITION_ACCESS field which is also the value used to specify the
hardware partition of the various mmc_switch incarnations.
To add some sanity to the distinction between BOOT_PARTITION_ENABLE
(used to specify the active device on power-cycle) and PARTITION_ACCESS
(used to switch between hardware partitions) create two enumerated types
and use them wherever struct mmc * part_config is used or the above
macros are used.
This represents no code changes.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
|
|
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The constraints on the MMC_SUPPORTS_TUNING symbol can easily be
expressed in Kconfig (with the addition of SPL_MMC_SUPPORTS_TUNING).
Furthermore, in order to remove <common.h> from the MMC subsystem, the
way this symbol is used today needs to be changed in order to continue
functioning.
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Set generic mmc->tuning flag when performing tuning to indicate
this condition to drivers. Drivers may use this to bypass various
checks during tuning.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
This hs400_tuning is a flag, make it bool. No functional change.
This will be useful in the following patch, which adds another
more generic flag, where the compiler can better use the space
now reserved for the u8 to store more flags in it.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
The cmd_error parameter is not used, remove it.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
With MMC_PWRSEQ enabled the following link issue may happen when
building SPL and SPL_PWRSEQ is not enabled.
aarch64-linux-gnu-ld.bfd: drivers/mmc/meson_gx_mmc.o: in function `meson_mmc_probe':
drivers/mmc/meson_gx_mmc.c:295: undefined reference to `pwrseq_set_power'
Fix this by adding a SPL_MMC_PWRSEQ Kconfig option used to enable mmc
pwrseq support in SPL.
Also add depends on DM_GPIO to fix following link issue:
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.o: in function `mmc_pwrseq_set_power':
drivers/mmc/mmc-pwrseq.c:26: undefined reference to `gpio_request_by_name'
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:29: undefined reference to `dm_gpio_set_value'
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:31: undefined reference to `dm_gpio_set_value'
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Acked-by: Ferass El Hafidi <vitali64pmemail@protonmail.com>
|
|
If a tuning command times out, the card could still be processing it,
which will cause problems for recovery. The eMMC specification section
6.6 Data transfer mode (cont’d) claims that CMD12 can be used to stop
CMD21:
"
The relationship between the various data transfer modes is summarized (see Figure 27):
- All data read commands can be aborted any time by the stop command (CMD12).
The data transfer will terminate and the Device will return to the Transfer State.
The read commands are: ... send tuning block (CMD21) ....
"
Add a function that does that.
Based on Linux commit [1] and [2].
[1] e711f0309109 ("mmc: mmc: Introduce mmc_abort_tuning()")
[2] 21adc2e45f4e ("mmc: Improve function name when aborting a tuning
cmd")
Reviewed-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: Update commit message, quote relevant part of the specification.
Rename to mmc_send_stop_transmission().
Remove tuning opcode check, this is controller driver specific.
Deduplicate part of mmc_read_blocks() using this function.]
Reviewed-by: Peng Fan <peng.fan@nxp.com>
|
|
When secure/insecure TRIM operations are supported.
When used as erase command argument it applies the
erase operation to write blocks instead of erase
groups.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
Add more capable "bkops" command which allows enabling and disabling both
manual and automatic bkops. The existing 'mmc bkops-enable' subcommand is
poorly named to cover all the possibilities, hence the new-ish subcommand.
Note that both commands are wrappers around the same common code.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
This converts the following to Kconfig:
CONFIG_SYS_MMC_MAX_BLK_COUNT
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
We currently have an if_type (interface type) and a uclass id. These are
closely related and we don't need to have both.
Drop the if_type values and use the uclass ones instead.
Maintain the existing, subtle, one-way conversion between UCLASS_USB and
UCLASS_MASS_STORAGE for now, and add a comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add features to write protect single boot area rather than all boot
areas.
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
|
|
There is no wait_dat0 mmc ops, causing operations waiting for data
line state change (e.g mmc_switch_voltage) to fallback to a 250ms
active delay. mmc_ops still used when DM_MMC is not enabled, which
is often the case for SPL. The result can be unexpectly long SPL
boot time.
This change adds support for wait_dat0() mmc operation.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
Add a bootdev driver for MMC. It mostly just calls the bootdev helper
function.
Add a function to obtain the block device for an MMC controller.
Fix up the comment for mmc_get_blk_desc() while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Sphinx expects Return: and not @return to indicate a return value.
find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;
find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
We want to replace '#ifdef' by 'if (IS_ENABLED(CONFIG_...))' in our code.
Therefore functions should be defined unconditionally even if they are not
implemented.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
Add support for enumerating MMC card in a given mode using mmc rescan and
mmc dev commands. The speed mode is provided as the last argument in these
commands and is indicated using the index from enum bus_mode in
include/mmc.h. A speed mode can be set only if it has already been enabled
in the device tree.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
Add a new 'quiet' argument to mmc_get_op_cond() function which avoids
printing error message when SD/eMMC card is not detected.
Espressobin and mx6cuboxi boards use this function for detecting presence
of eMMC and therefore it is expected and normal that eMMC does not have to
be connected. So error message "Card did not respond to voltage select!"
should be skipped in this case as it is not an error.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
Change to static about dm function.
They can be used with wrapper functions.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
Use mmc_send_cmd instead of dm_mmc_send_cmd.
It doesn't need to distinguish this function.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
Add mmc-pwrseq file to provide a generic interface.
Signed-off-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>
|
|
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>
|
|
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>
|
|
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>
|
|
Some controllers may have difference between HS200 tuning
and HS400 tuning, such as different registers setting,
different procedure, or different errata.
This patch is to add a hs400_tuning flag to identify the
tuning for HS400 mode.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
|
|
For DM_MMC, the controller re-initialization is needed to
clear old configuration for mmc rescan.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
This macro is necessary for arasan_zynqmp_dll_reset to compile.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
|
|
Move this uncommon header out of the common header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
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>
|
|
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>
|
|
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>
|
|
Add the EXT_CSD register definition related to write protection.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
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 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>
|
