Re: [PATCH v2 2/2] mmc: Add quirk to disable PWREN for dw_mmc
On 7/10/23 22:00, David Hewitt wrote:
> This is required for correct booting of the PINE64 PineTab2. If
> PWREN is pulled high on this device, the SD card cannot be detected.
>
> This is required in other PINE64 devices (e.g. Quartz64 Model A) too.
>
> See commit ba33172a36f298641f51a5e6b855c3e89e3f5d3e in
> https://github.com/CounterPillow/u-boot-quartz64
>
> Signed-off-by: David Hewitt
> Cc: Simon Glass
> Cc: Philipp Tomsich
> Cc: Kever Yang
> Cc: Peng Fan
> Cc: Jaehoon Chung
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Changes for v2:
> - Removed an unrelated change
>
> drivers/mmc/dw_mmc.c | 3 ++-
> drivers/mmc/rockchip_dw_mmc.c | 3 +++
> include/dwmmc.h | 1 +
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 5085a3b491..cb1d99132f 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -530,7 +530,8 @@ static int dwmci_init(struct mmc *mmc)
> if (host->board_init)
> host->board_init(host);
>
> - dwmci_writel(host, DWMCI_PWREN, 1);
> + if (!(host->quirks & DWMCI_QUIRK_DISABLE_PWREN))
> + dwmci_writel(host, DWMCI_PWREN, 1);
>
> if (!dwmci_wait_reset(host, DWMCI_RESET_ALL)) {
> debug("%s[%d] Fail-reset!!\n", __func__, __LINE__);
> diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c
> index 72c820ee63..af6ac59a46 100644
> --- a/drivers/mmc/rockchip_dw_mmc.c
> +++ b/drivers/mmc/rockchip_dw_mmc.c
> @@ -78,6 +78,9 @@ static int rockchip_dwmmc_of_to_plat(struct udevice *dev)
> else
> host->dev_index = 1;
>
> + if (dev_read_bool(dev, "rockchip,disable-pwren-quirk"))
> + host->quirks |= DWMCI_QUIRK_DISABLE_PWREN;
> +
> priv->fifo_depth = dev_read_u32_default(dev, "fifo-depth", 0);
>
> if (priv->fifo_depth < 0)
> diff --git a/include/dwmmc.h b/include/dwmmc.h
> index 136a95b8cd..98aebb46f1 100644
> --- a/include/dwmmc.h
> +++ b/include/dwmmc.h
> @@ -141,6 +141,7 @@
>
> /* quirks */
> #define DWMCI_QUIRK_DISABLE_SMU (1 << 0)
> +#define DWMCI_QUIRK_DISABLE_PWREN(1 << 1)
>
> /**
> * struct dwmci_host - Information about a designware MMC host
[PATCH] event: Fix an wrong type_name from dm_post_init to dm_post_init_f
DM_POST_INIT was changed to DM_POST_INIT_F.
To debug correct message, change type_name from dm_post_init to
dm_post_init_f.
Signed-off-by: Jaehoon Chung
---
common/event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/event.c b/common/event.c
index 20720c52839e..3224e2812224 100644
--- a/common/event.c
+++ b/common/event.c
@@ -27,7 +27,7 @@ const char *const type_name[] = {
"test",
/* Events related to driver model */
- "dm_post_init",
+ "dm_post_init_f",
"dm_pre_probe",
"dm_post_probe",
"dm_pre_remove",
--
2.25.1
RE: Trying to boot JH7110 RISCV-V CPU from MMC
Hi,
> -Original Message-
> From: U-Boot On Behalf Of Roland Ruckerbauer
> Sent: Wednesday, June 28, 2023 4:52 AM
> To: u-boot@lists.denx.de; yanhong.w...@starfivetech.com
> Subject: Trying to boot JH7110 RISCV-V CPU from MMC
>
> Hi!
>
> I am trying to use upstream u-boot + opensbi, to boot my visionfive2 SBC
> I got from external SD card. I had not much luck with the vendor
> provided images / tools, they seem to have a lot of hard coded stuff and
> just won`t work correctly.
>
> With upstream u-boot I followed the doc/board/starfive/visionfive2.rst
> to the point, but unfortunately it did not work.
>
> First I ran into an issue, where the chip would pick up a random SPL
> somewhere else on the SD card, and so I could not test my build.
> I fixed it by completely erasing the whole sdcard to make sure there can
> be no other SPL/Uboot on it. This worked, but unfortunately
> the sd card I made with the steps from
> doc/board/starfive/visionfive2.rst still did not work.
>
> I managed to figure out, that I need to make special modifications to
> the first 2 sectors of the sd card (protective MBR and GPT header), using
> https://protect2.fireeye.com/v1/url?k=61d64ba7-00ade130-61d7c0e8-74fe4860001d-
> 48ffcb4bd9c5658e=1=38e576e4-b8ca-4e7f-92e3-90b65f990704=https%3A%2F%2Fgithub.com%2Fstarfive-
> tech%2FTools%2Ftree%2Fmaster%2Fspl_tool. Calling
> spl_tool -i -f /dev/sdb on my sdcard patches the first sectors with an
> invalid
> SPL, and also a offset to the backup SPL (which is the primary one I
> flashed according to the documentation).
>
> Maybe this should be added to the docu, otherwise it will not work, or
> worse, load some other SPL also on the SD card and cause confusion.
> There also is a mention in the docu, that the boot ROM searches for the
> SPL by looking for the offset of its partition in the GPT with a specific
> GUID. Not sure where this information comes from, but testing showed,
> that its probably not true.
>
>
> Now to my actual problem, hopefully someone can help:
>
> The sdcard I built with u-boot and opensbi can now boot the spl, and
> also start opensbi and load u-boot. Unfortunately
> the init_sequence_r now fails with an error: initcall sequence
> fffe0738 failed at call 40216240 (err=-19)
Did you find what's caused? It seems it's not working fine with latest yet.
It seems that your analysis is right way.
When I have tested on v2023.07-rc1, it's booting fine.
So I did the git bisect from v2023.07-rc1 to master.
2023-05-04 16:50 -0600 Simon Glass * [HEAD]
[refs/bisect/bad] dm: Emit the arch_cpu_init_dm() even only before relocation
2023-05-04 16:55 -0600 Simon Glass *
[refs/bisect/good-44dc33042f8465764bddeba4e4b362dd5372b74a] coreboot: Enable ms
command
After applied the below patch, visionfive2 doesn't work fine.
55171aedda88d12666e2a1bbc661dea1bec65337 is the first bad commit
commit 55171aedda88d12666e2a1bbc661dea1bec65337
Author: Simon Glass
Date: Thu May 4 16:50:45 2023 -0600
dm: Emit the arch_cpu_init_dm() even only before relocation
The original function was only called once, before relocation. The new
one is called again after relocation. This was not the intent of the
original call. Fix this by renaming and updating the calling logic.
With this, chromebook_link64 makes it through SPL.
Fixes: 7fe32b3442f0 ("event: Convert arch_cpu_init_dm() to use events")
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
arch/arm/mach-imx/imx8/cpu.c| 2 +-
arch/arm/mach-imx/imx8m/soc.c | 2 +-
arch/arm/mach-imx/imx8ulp/soc.c | 2 +-
arch/arm/mach-imx/imx9/soc.c| 2 +-
arch/arm/mach-omap2/am33xx/board.c | 2 +-
arch/arm/mach-omap2/hwinit-common.c | 2 +-
arch/mips/mach-pic32/cpu.c | 2 +-
arch/nios2/cpu/cpu.c| 2 +-
arch/riscv/cpu/cpu.c| 2 +-
arch/x86/cpu/baytrail/cpu.c | 2 +-
arch/x86/cpu/broadwell/cpu.c| 2 +-
arch/x86/cpu/ivybridge/cpu.c| 2 +-
arch/x86/cpu/quark/quark.c | 2 +-
arch/x86/lib/fsp2/fsp_init.c| 2 +-
doc/develop/event.rst | 6 +++---
drivers/core/root.c | 4 ++--
drivers/cpu/microblaze_cpu.c| 2 +-
include/event.h | 2 +-
18 files changed, 21 insertions(+), 21 deletions(-)
Best Regards,
Jaehoon Chung
>
> Digging through the source and some printf debugging revealed to me,
> that initr_dm_devices() fails, because it can not find
> a timer device with in dm_timer_init() call.
>
> For the JH7110 and pretty much any other RISCV chip the timer device
> should be provided by the SBI, which is functioning correctly as far as
> I can tell. I searched for it in the u-boot code, and figured out that
> riscv_t
RE: [PATCH v1 0/6] Add support for PMICs used on Tegra 3 devices
> -Original Message- > From: Svyatoslav Ryhel > Sent: Thursday, July 20, 2023 12:26 PM > To: Jaehoon Chung ; 'Simon Glass' > Cc: u-boot@lists.denx.de > Subject: RE: [PATCH v1 0/6] Add support for PMICs used on Tegra 3 devices > > > > 20 липня 2023 р. 06:12:23 GMT+03:00, Jaehoon Chung > написав(-ла): > >Hi > > > >> -Original Message- > >> From: Svyatoslav Ryhel > >> Sent: Saturday, July 15, 2023 1:16 AM > >> To: Jaehoon Chung ; Simon Glass > >> ; Svyatoslav Ryhel > >> > >> Cc: u-boot@lists.denx.de > >> Subject: [PATCH v1 0/6] Add support for PMICs used on Tegra 3 devices > >> > >> Patch set adds basic support for PMICs used in many Tegra 3 devices. > >> All PMIC drivers are based on datasheets provided by vendors. > >> Implemented API include regulator set/get voltage enable/disable and > >> basic PMIC r/w capabilities. > >> > >> Drivers were tested by me on LG P895 (max77663), HTC One X (TPS80032) > >> and ASUS TF300T (tps65911). Calculations and behavior were correct, > >> predictable and reproducible. > > > >I didn't find where those drivers is using. Do you have any plan to update > >the enabling CONFIG? > >I hope the enabling CONFIG will be included. Otherwise, I can't check > >whether its building is fine or > not. > >If I missed some patches, let me know, plz > > > >Until enabled CONFIG, these drivers can be dead codes. > > Enabling configs is planned as next step of this > https://protect2.fireeye.com/v1/url?k=a8a63aa5- > c92d2f85-a8a7b1ea-74fe485fb347-c1cc2b9c6f97e343=1=c08f18ed-4f66-46bb-b871- > 17167bc5b502=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D361808 > patchset (initial bringup of devices). Unfortunately tegra custodians are too > "busy" to initiate merge > of those devices. Thanks for sharing information. :) Best Regards, Jaehoon Chung > > >Best Regards, > >Jaehoon Chung > > > >> > >> Svyatoslav Ryhel (6): > >> power: pmic: add the base max77663 pmic support > >> power: regulator: max77663: add regulator support > >> power: pmic: add the base TPS80031 PMIC support > >> power: regulator: tps80031: add regulator support > >> power: pmic: tps65910: add TPS65911 PMIC support > >> power: regulator: tps65911: add regulator support > >> > >> doc/device-tree-bindings/pmic/max77663.txt | 84 + > >> doc/device-tree-bindings/pmic/tps65911.txt | 78 > >> doc/device-tree-bindings/pmic/tps80031.txt | 76 > >> drivers/power/pmic/Kconfig | 12 + > >> drivers/power/pmic/Makefile | 2 + > >> drivers/power/pmic/max77663.c| 81 > >> drivers/power/pmic/pmic_tps65910_dm.c| 26 +- > >> drivers/power/pmic/tps80031.c| 82 > >> drivers/power/regulator/Kconfig | 24 ++ > >> drivers/power/regulator/Makefile | 3 + > >> drivers/power/regulator/max77663_regulator.c | 362 ++ > >> drivers/power/regulator/tps65911_regulator.c | 375 +++ > >> drivers/power/regulator/tps80031_regulator.c | 296 +++ > >> include/power/max77663.h | 40 ++ > >> include/power/tps65910_pmic.h| 47 +++ > >> include/power/tps80031.h | 42 +++ > >> 16 files changed, 1627 insertions(+), 3 deletions(-) > >> create mode 100644 doc/device-tree-bindings/pmic/max77663.txt > >> create mode 100644 doc/device-tree-bindings/pmic/tps65911.txt > >> create mode 100644 doc/device-tree-bindings/pmic/tps80031.txt > >> create mode 100644 drivers/power/pmic/max77663.c > >> create mode 100644 drivers/power/pmic/tps80031.c > >> create mode 100644 drivers/power/regulator/max77663_regulator.c > >> create mode 100644 drivers/power/regulator/tps65911_regulator.c > >> create mode 100644 drivers/power/regulator/tps80031_regulator.c > >> create mode 100644 include/power/max77663.h > >> create mode 100644 include/power/tps80031.h > >> > >> -- > >> 2.39.2 > > > >
RE: [PATCH v1 0/6] Add support for PMICs used on Tegra 3 devices
Hi > -Original Message- > From: Svyatoslav Ryhel > Sent: Saturday, July 15, 2023 1:16 AM > To: Jaehoon Chung ; Simon Glass ; > Svyatoslav Ryhel > > Cc: u-boot@lists.denx.de > Subject: [PATCH v1 0/6] Add support for PMICs used on Tegra 3 devices > > Patch set adds basic support for PMICs used in many Tegra 3 devices. > All PMIC drivers are based on datasheets provided by vendors. > Implemented API include regulator set/get voltage enable/disable and > basic PMIC r/w capabilities. > > Drivers were tested by me on LG P895 (max77663), HTC One X (TPS80032) > and ASUS TF300T (tps65911). Calculations and behavior were correct, > predictable and reproducible. I didn't find where those drivers is using. Do you have any plan to update the enabling CONFIG? I hope the enabling CONFIG will be included. Otherwise, I can't check whether its building is fine or not. If I missed some patches, let me know, plz Until enabled CONFIG, these drivers can be dead codes. Best Regards, Jaehoon Chung > > Svyatoslav Ryhel (6): > power: pmic: add the base max77663 pmic support > power: regulator: max77663: add regulator support > power: pmic: add the base TPS80031 PMIC support > power: regulator: tps80031: add regulator support > power: pmic: tps65910: add TPS65911 PMIC support > power: regulator: tps65911: add regulator support > > doc/device-tree-bindings/pmic/max77663.txt | 84 + > doc/device-tree-bindings/pmic/tps65911.txt | 78 > doc/device-tree-bindings/pmic/tps80031.txt | 76 > drivers/power/pmic/Kconfig | 12 + > drivers/power/pmic/Makefile | 2 + > drivers/power/pmic/max77663.c| 81 > drivers/power/pmic/pmic_tps65910_dm.c| 26 +- > drivers/power/pmic/tps80031.c| 82 > drivers/power/regulator/Kconfig | 24 ++ > drivers/power/regulator/Makefile | 3 + > drivers/power/regulator/max77663_regulator.c | 362 ++ > drivers/power/regulator/tps65911_regulator.c | 375 +++ > drivers/power/regulator/tps80031_regulator.c | 296 +++ > include/power/max77663.h | 40 ++ > include/power/tps65910_pmic.h| 47 +++ > include/power/tps80031.h | 42 +++ > 16 files changed, 1627 insertions(+), 3 deletions(-) > create mode 100644 doc/device-tree-bindings/pmic/max77663.txt > create mode 100644 doc/device-tree-bindings/pmic/tps65911.txt > create mode 100644 doc/device-tree-bindings/pmic/tps80031.txt > create mode 100644 drivers/power/pmic/max77663.c > create mode 100644 drivers/power/pmic/tps80031.c > create mode 100644 drivers/power/regulator/max77663_regulator.c > create mode 100644 drivers/power/regulator/tps65911_regulator.c > create mode 100644 drivers/power/regulator/tps80031_regulator.c > create mode 100644 include/power/max77663.h > create mode 100644 include/power/tps80031.h > > -- > 2.39.2
RE: [PATCH 1/3] mmc: sdhci-cadence: Rename functions to SD4 specific
> -Original Message-
> From: Piyush Malgujar
> Sent: Monday, June 5, 2023 10:58 PM
> To: peng@nxp.com; jh80.ch...@samsung.com; u-boot@lists.denx.de
> Cc: jannadu...@marvell.com; ccha...@marvell.com; Dhananjay Kangude
> ; Piyush
> Malgujar
> Subject: [PATCH 1/3] mmc: sdhci-cadence: Rename functions to SD4 specific
>
> From: Dhananjay Kangude
>
> Renaming the functions and structures specific to SD4 so
> that it can be separated from upcoming SD6 related
> functionality.
>
> Signed-off-by: Dhananjay Kangude
> Co-developed-by: Jayanthi Annadurai
> Signed-off-by: Jayanthi Annadurai
> Signed-off-by: Piyush Malgujar
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/sdhci-cadence.c | 48 ++---
> 1 file changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
> index
> 327a05ad11d00fad415bd18b93d83f08e2b6ed5a..0bb258da63e442232310d9433b7b6882992bd45d
> 100644
> --- a/drivers/mmc/sdhci-cadence.c
> +++ b/drivers/mmc/sdhci-cadence.c
> @@ -18,14 +18,14 @@
> #include
> #include
>
> -/* HRS - Host Register Set (specific to Cadence) */
> +/* SD 4.0 Controller HRS - Host Register Set (specific to Cadence) */
> #define SDHCI_CDNS_HRS04 0x10/* PHY access port */
> -#define SDHCI_CDNS_HRS04_ACK BIT(26)
> -#define SDHCI_CDNS_HRS04_RDBIT(25)
> -#define SDHCI_CDNS_HRS04_WRBIT(24)
> -#define SDHCI_CDNS_HRS04_RDATA GENMASK(23, 16)
> -#define SDHCI_CDNS_HRS04_WDATA GENMASK(15, 8)
> -#define SDHCI_CDNS_HRS04_ADDR GENMASK(5, 0)
> +#define SDHCI_CDNS_SD4_HRS04_ACK BIT(26)
> +#define SDHCI_CDNS_SD4_HRS04_RD BIT(25)
> +#define SDHCI_CDNS_SD4_HRS04_WR BIT(24)
> +#define SDHCI_CDNS_SD4_HRS04_RDATA GENMASK(23, 16)
> +#define SDHCI_CDNS_SD4_HRS04_WDATA GENMASK(15, 8)
> +#define SDHCI_CDNS_SD4_HRS04_ADDRGENMASK(5, 0)
>
> #define SDHCI_CDNS_HRS06 0x18/* eMMC control */
> #define SDHCI_CDNS_HRS06_TUNE_UP BIT(15)
> @@ -41,7 +41,7 @@
> /* SRS - Slot Register Set (SDHCI-compatible) */
> #define SDHCI_CDNS_SRS_BASE 0x200
>
> -/* PHY */
> +/* PHY registers for SD4 controller */
> #define SDHCI_CDNS_PHY_DLY_SD_HS 0x00
> #define SDHCI_CDNS_PHY_DLY_SD_DEFAULT0x01
> #define SDHCI_CDNS_PHY_DLY_UHS_SDR12 0x02
> @@ -73,7 +73,7 @@ struct sdhci_cdns_phy_cfg {
> u8 addr;
> };
>
> -static const struct sdhci_cdns_phy_cfg sdhci_cdns_phy_cfgs[] = {
> +static const struct sdhci_cdns_phy_cfg sdhci_cdns_sd4_phy_cfgs[] = {
> { "cdns,phy-input-delay-sd-highspeed", SDHCI_CDNS_PHY_DLY_SD_HS, },
> { "cdns,phy-input-delay-legacy", SDHCI_CDNS_PHY_DLY_SD_DEFAULT, },
> { "cdns,phy-input-delay-sd-uhs-sdr12", SDHCI_CDNS_PHY_DLY_UHS_SDR12, },
> @@ -87,45 +87,45 @@ static const struct sdhci_cdns_phy_cfg
> sdhci_cdns_phy_cfgs[] = {
> { "cdns,phy-dll-delay-strobe", SDHCI_CDNS_PHY_DLY_STROBE, },
> };
>
> -static int sdhci_cdns_write_phy_reg(struct sdhci_cdns_plat *plat,
> - u8 addr, u8 data)
> +static int sdhci_cdns_sd4_write_phy_reg(struct sdhci_cdns_plat *plat,
> + u8 addr, u8 data)
> {
> void __iomem *reg = plat->hrs_addr + SDHCI_CDNS_HRS04;
> u32 tmp;
> int ret;
>
> - tmp = FIELD_PREP(SDHCI_CDNS_HRS04_WDATA, data) |
> - FIELD_PREP(SDHCI_CDNS_HRS04_ADDR, addr);
> + tmp = FIELD_PREP(SDHCI_CDNS_SD4_HRS04_WDATA, data) |
> + FIELD_PREP(SDHCI_CDNS_SD4_HRS04_ADDR, addr);
> writel(tmp, reg);
>
> - tmp |= SDHCI_CDNS_HRS04_WR;
> + tmp |= SDHCI_CDNS_SD4_HRS04_WR;
> writel(tmp, reg);
>
> - ret = readl_poll_timeout(reg, tmp, tmp & SDHCI_CDNS_HRS04_ACK, 10);
> + ret = readl_poll_timeout(reg, tmp, tmp & SDHCI_CDNS_SD4_HRS04_ACK, 10);
> if (ret)
> return ret;
>
> - tmp &= ~SDHCI_CDNS_HRS04_WR;
> + tmp &= ~SDHCI_CDNS_SD4_HRS04_WR;
> writel(tmp, reg);
>
> return 0;
> }
>
> -static int sdhci_cdns_phy_init(struct sdhci_cdns_plat *plat,
> - const void *fdt, int nodeoffset)
> +static int sdhci_cdns_sd4_phy_init(struct sdhci_cdns_plat *plat,
> +const void *fdt, int nodeoffset)
> {
> const fdt32_t *prop;
> int ret, i;
>
> - for (i =
[GIT PULL] Please pull u-boot-mmc master
Dear Tom, Please pull u-boot-mmc master into u-boot master branch. If there is any problem, let me know, plz. Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/16946 The following changes since commit 13aa090b87a0fbdfe690011669b9fdb96bb1ccc7: Merge https://source.denx.de/u-boot/custodians/u-boot-x86 (2023-07-17 10:38:28 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master for you to fetch changes up to 50dee4f3610331cc31f1f02f9d4116b716907011: mmc: Set clock when reverting to safe bus mode (2023-07-18 09:17:29 +0900) Hai Pham (2): mmc: Introduce mmc_send_stop_transmission() mmc: renesas-sdhi: Send stop when MMC tuning command fails Marek Vasut (1): mmc: Fix MMC_CMD_STOP_TRANSMISSION response type and add comment Valentine Barshak (1): mmc: Set clock when reverting to safe bus mode drivers/mmc/mmc.c | 26 ++ drivers/mmc/renesas-sdhi.c | 11 +++ include/mmc.h | 2 ++ 3 files changed, 35 insertions(+), 4 deletions(-)
RE: [PATCH] mmc:Remove thr legacy mode clock setting operation
Hi,
> -Original Message-
> From: 869470...@qq.com <869470...@qq.com>
> Sent: Wednesday, July 12, 2023 4:19 PM
> To: u-boot@lists.denx.de
> Cc: peng@nxp.com; jh80.ch...@samsung.com; xiefei
> Subject: [PATCH] mmc:Remove thr legacy mode clock setting operation
>
> From: xiefei
>
> Due to the need to read the register value before
> switching to hs mode, the standard protocol does
> not explicitly specify that the setting before
> switching to hs mode is in legacy mode. Therefore,
> the code at this point may cause communication
> abnormalities between the host and card
Thanks for resend patch after updated.
Which board and driver does it occur the issue?
Best Regards,
Jaehoon Chung
>
> Signed-off-by: xiefei
> ---
> drivers/mmc/mmc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 1af6af82e6..96cc7e7332 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2136,9 +2136,7 @@ static int mmc_select_mode_and_width(struct mmc *mmc,
> uint card_caps)
> mmc->selected_mode == MMC_HS_400 ||
> mmc->selected_mode == MMC_HS_400_ES)
> mmc_set_card_speed(mmc, MMC_HS, true);
> - else
> #endif
> - mmc_set_clock(mmc, mmc->legacy_speed, MMC_CLK_ENABLE);
>
> for_each_mmc_mode_by_pref(card_caps, mwt) {
> for_each_supported_width(card_caps & mwt->widths,
> --
> 2.17.1
RE: [PATCH] mmc: zynq_sdhci: Dll reset only for ZynqMP platform
Hi, > -Original Message- > From: Michal Simek > Sent: Tuesday, July 11, 2023 3:28 PM > To: Jaehoon Chung ; u-boot@lists.denx.de; > g...@xilinx.com > Cc: 'Ashok Reddy Soma' ; 'Peng Fan' > > Subject: Re: [PATCH] mmc: zynq_sdhci: Dll reset only for ZynqMP platform > > Hi, > > On 7/11/23 07:00, Jaehoon Chung wrote: > > Hi, > > > >> -Original Message- > >> From: Michal Simek > >> Sent: Monday, July 10, 2023 9:12 PM > >> To: u-boot@lists.denx.de; g...@xilinx.com > >> Cc: Ashok Reddy Soma ; Jaehoon Chung > >> ; Peng Fan > >> > >> Subject: [PATCH] mmc: zynq_sdhci: Dll reset only for ZynqMP platform > >> > >> From: Ashok Reddy Soma > >> > >> Dll reset is needed only for ZynqMP platforms, add condition in tuning > >> to call arasan_zynqmp_dll_reset() just for ZynqMP platforms. > >> > >> On other platforms like Versal NET, If this condition is not added, we > >> see PLM error messages when dll reset smc is called. > >> > >> Signed-off-by: Ashok Reddy Soma > >> Signed-off-by: Michal Simek > >> --- > >> > >> drivers/mmc/zynq_sdhci.c | 7 +-- > >> 1 file changed, 5 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c > >> index e779251ce34f..935540d17194 100644 > >> --- a/drivers/mmc/zynq_sdhci.c > >> +++ b/drivers/mmc/zynq_sdhci.c > >> @@ -422,7 +422,8 @@ static int arasan_sdhci_execute_tuning(struct mmc > >> *mmc, u8 opcode) > >> > >>mdelay(1); > >> > >> - arasan_zynqmp_dll_reset(host, priv->node_id); > >> + if (device_is_compatible(mmc->dev, "xlnx,zynqmp-8.9a")) > >> + arasan_zynqmp_dll_reset(host, priv->node_id); > > > > How about using local variable to check whether it needs to reset or not? > > It's not efficient to call device_is_compatible() everytime. > > (I'm not sure that it will be added more in future.) > > > > e.g) > > bool reset = device_is_compatible(mmc->dev, "xlx,zynmp-8.8a"); > > > > if (reset) > > arasan_zynqmp_dll_reset(host, priv->node_id); > > > > .. > > > > If (reset) > > arasan_zynqmp_dll_reset(host, priv->node_id); > > This is very valid request and TBH I have already added this to our TODO list > to > convert all device_is_compatible() to flags because over time the driver was > extended and this construct is used more than it should be. > > This is going to be the last device_is_compatible() patch. > Is it fine for you? It's fine. Thanks! Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > > Thanks, > Michal > >
RE: [PATCH] mmc: zynq_sdhci: Dll reset only for ZynqMP platform
Hi,
> -Original Message-
> From: Michal Simek
> Sent: Monday, July 10, 2023 9:12 PM
> To: u-boot@lists.denx.de; g...@xilinx.com
> Cc: Ashok Reddy Soma ; Jaehoon Chung
> ; Peng Fan
>
> Subject: [PATCH] mmc: zynq_sdhci: Dll reset only for ZynqMP platform
>
> From: Ashok Reddy Soma
>
> Dll reset is needed only for ZynqMP platforms, add condition in tuning
> to call arasan_zynqmp_dll_reset() just for ZynqMP platforms.
>
> On other platforms like Versal NET, If this condition is not added, we
> see PLM error messages when dll reset smc is called.
>
> Signed-off-by: Ashok Reddy Soma
> Signed-off-by: Michal Simek
> ---
>
> drivers/mmc/zynq_sdhci.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
> index e779251ce34f..935540d17194 100644
> --- a/drivers/mmc/zynq_sdhci.c
> +++ b/drivers/mmc/zynq_sdhci.c
> @@ -422,7 +422,8 @@ static int arasan_sdhci_execute_tuning(struct mmc *mmc,
> u8 opcode)
>
> mdelay(1);
>
> - arasan_zynqmp_dll_reset(host, priv->node_id);
> + if (device_is_compatible(mmc->dev, "xlnx,zynqmp-8.9a"))
> + arasan_zynqmp_dll_reset(host, priv->node_id);
How about using local variable to check whether it needs to reset or not?
It's not efficient to call device_is_compatible() everytime.
(I'm not sure that it will be added more in future.)
e.g)
bool reset = device_is_compatible(mmc->dev, "xlx,zynmp-8.8a");
if (reset)
arasan_zynqmp_dll_reset(host, priv->node_id);
..
If (reset)
arasan_zynqmp_dll_reset(host, priv->node_id);
Best Regards,
Jaehoon Chung
>
> sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_INT_ENABLE);
> sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_SIGNAL_ENABLE);
> @@ -468,7 +469,9 @@ static int arasan_sdhci_execute_tuning(struct mmc *mmc,
> u8 opcode)
> }
>
> udelay(1);
> - arasan_zynqmp_dll_reset(host, priv->node_id);
> +
> + if (device_is_compatible(mmc->dev, "xlnx,zynqmp-8.9a"))
> + arasan_zynqmp_dll_reset(host, priv->node_id);
>
> /* Enable only interrupts served by the SD controller */
> sdhci_writel(host, SDHCI_INT_DATA_MASK | SDHCI_INT_CMD_MASK,
> --
> 2.36.1
RE: [PATCH u-boot 0/4] mmc: Explain and cleanup partition selection
> -Original Message- > From: Pali Rohár > Sent: Thursday, July 6, 2023 7:51 PM > To: Jaehoon Chung ; Tom Rini > Cc: Peng Fan ; Stefan Roese ; > u-boot@lists.denx.de > Subject: Re: [PATCH u-boot 0/4] mmc: Explain and cleanup partition selection > > On Monday 03 July 2023 21:16:37 Jaehoon Chung wrote: > > Hi, > > > > On 4/14/23 06:10, Pali Rohár wrote: > > > Some people do not want to read review comments in emails. So put > > > comments and explanation into the source code itself; make emmc > > > partition selection code more explicit and validate configuration in > > > bubt command. > > > > Sorry for too late. > > After applied this patch-set, some board are failed with spl's size > > overflowed > > > > The below is one of failed log. > > > > +arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 352 bytes > > +make[2]: *** [scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 > > +make[1]: *** [Makefile:2049: spl/u-boot-spl] Error 2 > > Crap, and again we have there same issue. Patch after months does not > apply anymore. And resending the patch would again result in the same > problem that it would not apply anymore after half of the year... > > > Anyway, only first patch is SPL specific, other should apply without any > problem. Except spl specific patch, I will check again about your other patches. Thanks! Best Regards, Jaehoon Chung > > > > > Best Regards, > > Jaehoon Chung > > > > > > > > Pali Rohár (4): > > > mmc: spl: Make partition choice in > > > default_spl_mmc_emmc_boot_partition() more explicit > > > cmd: mvebu/bubt: Validate EXT_CSD[179] eMMC register in > > > mmc_burn_image() > > > sunxi: eMMC: Add comments explaining mapping between bootpart and > > > mmc_switch_part() > > > board: purism: Use U-Boot mmc function for converting boot part to > > > part access > > > > > > arch/arm/mach-sunxi/board.c| 12 ++- > > > board/purism/librem5/librem5.c | 6 +- > > > cmd/mvebu/bubt.c | 24 +++-- > > > common/spl/spl_mmc.c | 38 +++--- > > > 4 files changed, 64 insertions(+), 16 deletions(-) > >
RE: [PATCH] ARM: dts: imx: Fix eMMC boot on Data Modul i.MX8M Plus eDM SBC
> -Original Message-
> From: U-Boot On Behalf Of Peng Fan
> Sent: Thursday, July 6, 2023 5:01 PM
> To: Marek Vasut ; u-boot@lists.denx.de
> Cc: tr...@konsulko.com; Fabio Estevam ; Peng Fan
> ; Stefano Babic
>
> Subject: Re: [PATCH] ARM: dts: imx: Fix eMMC boot on Data Modul i.MX8M Plus
> eDM SBC
>
>
>
> On 7/6/2023 7:26 AM, Marek Vasut wrote:
> > In case the i.MX8M Plus starts from eMMC BOOT1/BOOT2 HW partitions, the
> > flash.bin container is stored at offset 0 from the start, that means the
> > fitImage itb is at offset 0x2c0 instead of 0x300 sectors from the start.
> > Handle this difference in custom spl_mmc_get_uboot_raw_sector() .
> >
> > Signed-off-by: Marek Vasut
>
> Reviewed-by: Peng Fan
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
>
> > ---
> > Cc: Fabio Estevam
> > Cc: Peng Fan
> > Cc: Stefano Babic
> > ---
> > board/data_modul/imx8mp_edm_sbc/spl.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/board/data_modul/imx8mp_edm_sbc/spl.c
> > b/board/data_modul/imx8mp_edm_sbc/spl.c
> > index c30185e48d4..2fdd95a730c 100644
> > --- a/board/data_modul/imx8mp_edm_sbc/spl.c
> > +++ b/board/data_modul/imx8mp_edm_sbc/spl.c
> > @@ -107,6 +107,20 @@ void board_boot_order(u32 *spl_boot_list)
> > spl_boot_list[4] = BOOT_DEVICE_NONE;
> > }
> >
> > +unsigned long spl_mmc_get_uboot_raw_sector(struct mmc *mmc, unsigned long
> > sect)
> > +{
> > + const u32 boot_dev = spl_boot_device();
> > + int part;
> > +
> > + if (boot_dev == BOOT_DEVICE_MMC2) { /* eMMC */
> > + part = spl_mmc_emmc_boot_partition(mmc);
> > + if (part == 1 || part == 2) /* eMMC BOOT1/BOOT2 HW
> > partitions */
> > + return sect - 0x40;
> > + }
> > +
> > + return sect;
> > +}
> > +
> > static struct dram_timing_info *dram_timing_info[8] = {
> > _imx8mp_sbc_dram_timing_32_32, /* 32 Gbit x32 */
> > NULL, /* 32 Gbit x16 */
RE: [PATCH u-boot 0/4] mmc: Explain and cleanup partition selection
Hi > -Original Message- > From: Pali Rohár > Sent: Friday, July 7, 2023 2:39 AM > To: Jaehoon Chung ; Tom Rini > Cc: Peng Fan ; Stefan Roese ; > u-boot@lists.denx.de > Subject: Re: [PATCH u-boot 0/4] mmc: Explain and cleanup partition selection > > On Thursday 06 July 2023 12:50:34 Pali Rohár wrote: > > On Monday 03 July 2023 21:16:37 Jaehoon Chung wrote: > > > Hi, > > > > > > On 4/14/23 06:10, Pali Rohár wrote: > > > > Some people do not want to read review comments in emails. So put > > > > comments and explanation into the source code itself; make emmc > > > > partition selection code more explicit and validate configuration in > > > > bubt command. > > > > > > Sorry for too late. > > > After applied this patch-set, some board are failed with spl's size > > > overflowed > > > > > > The below is one of failed log. > > > > > > +arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 352 bytes > > > +make[2]: *** [scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 > > > +make[1]: *** [Makefile:2049: spl/u-boot-spl] Error 2 > > > > Crap, and again we have there same issue. Patch after months does not > > apply anymore. And resending the patch would again result in the same > > problem that it would not apply anymore after half of the year... > > Here is v2 patch with simple fix for that platform: > https://protect2.fireeye.com/v1/url?k=bec9bc29-df42a906-bec83766-74fe485cbfe7- > 2e40f47b53afb09d=1=e8f6a6f2-8f6f-4bf1-9b91- > 3f71d3577fc7=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20230706173502.2796-1- > pali%40kernel.org%2F > > And it passed _now_ CI pipeline: > https://protect2.fireeye.com/v1/url?k=543f3751-35b4227e-543ebc1e-74fe485cbfe7- > ff5f636a3c274f12=1=e8f6a6f2-8f6f-4bf1-9b91-3f71d3577fc7=https%3A%2F%2Fgithub.com%2Fu-boot%2Fu- > boot%2Fpull%2F340 > Thanks for sharing it. Best Regards, Jaehoon Chung > > > > Anyway, only first patch is SPL specific, other should apply without any > > problem. > > > > > > > > Best Regards, > > > Jaehoon Chung > > > > > > > > > > > Pali Rohár (4): > > > > mmc: spl: Make partition choice in > > > > default_spl_mmc_emmc_boot_partition() more explicit > > > > cmd: mvebu/bubt: Validate EXT_CSD[179] eMMC register in > > > > mmc_burn_image() > > > > sunxi: eMMC: Add comments explaining mapping between bootpart and > > > > mmc_switch_part() > > > > board: purism: Use U-Boot mmc function for converting boot part to > > > > part access > > > > > > > > arch/arm/mach-sunxi/board.c| 12 ++- > > > > board/purism/librem5/librem5.c | 6 +- > > > > cmd/mvebu/bubt.c | 24 +++-- > > > > common/spl/spl_mmc.c | 38 +++--- > > > > 4 files changed, 64 insertions(+), 16 deletions(-) > > >
RE: [GIT PULL] Please pull u-boot-mmc master
Dear Tom, > -Original Message- > From: U-Boot On Behalf Of Jaehoon Chung > Sent: Tuesday, July 4, 2023 10:29 AM > To: U-Boot Mailing List > Cc: Tom Rini ; Hai Pham ; Marek > Vasut ; > Pali Rohár ; alentine Barshak > ; Jae hoon Chung > ; Peng Fan > Subject: [GIT PULL] Please pull u-boot-mmc master > > Dear Tom, > > Please pull u-boot-mmc master into u-boot master branch. > If there is any problem, let me know, plz. Sorry for too late. > > Those patches are the fixing reensas-sdhi tuning command error and improve > the comment. > (I have also tested with this patchset on my board.) Discard this PR. I will resend PR for next with other patches. Best Regards, Jaehoon Chung > > Best Regards, > Jaehoon Chung > > CI: > https://protect2.fireeye.com/v1/url?k=3413c387-6b8feaad-341248c8-000babe598f7- > 1d8ae2363cc60248=1=aa47dcdd-bf48-4c74-8476-5a86c94862a1=https%3A%2F%2Fsource.denx.de%2Fu- > boot%2Fcustodians%2Fu-boot-mmc%2F-%2Fpipelines%2F16765 > > > The following changes since commit e1bebc16e1d9aa0ddd56c53c0b781f7186dce557: > > Prepare v2023.07-rc6 (2023-07-03 13:48:58 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master > > for you to fetch changes up to 40825dbac96542e914df4baa3aa0252a503b6b88: > > mmc: Set clock when reverting to safe bus mode (2023-07-04 08:14:18 +0900) > > > Hai Pham (2): > mmc: Introduce mmc_send_stop_transmission() > mmc: renesas-sdhi: Send stop when MMC tuning command fails > > Marek Vasut (1): > mmc: Fix MMC_CMD_STOP_TRANSMISSION response type and add comment > > Pali Rohár (1): > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition() > > Valentine Barshak (1): > mmc: Set clock when reverting to safe bus mode > > common/spl/spl_mmc.c | 42 +++--- > drivers/mmc/mmc.c | 26 ++ > drivers/mmc/renesas-sdhi.c | 11 +++ > include/mmc.h | 2 ++ > 4 files changed, 74 insertions(+), 7 deletions(-)
RE: [PATCH v2 1/5] dm: test: Fix partition test to use mmc2
> -Original Message-
> From: U-Boot On Behalf Of Joshua Watt
> Sent: Monday, July 3, 2023 10:40 PM
> To: u-boot@lists.denx.de
> Cc: Joshua Watt ; Simon Glass
> Subject: [PATCH v2 1/5] dm: test: Fix partition test to use mmc2
>
> d94d9844bc ("dm: part: Update test to use mmc2") attempted to make the
> test use mmc2, but the change was incomplete in that it didn't also
> change the strings that reference a specific partition. Fix these so
> that the test passes again
>
> Signed-off-by: Joshua Watt
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> test/dm/part.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/test/dm/part.c b/test/dm/part.c
> index 35e99eeb01..d5c58d6e3f 100644
> --- a/test/dm/part.c
> +++ b/test/dm/part.c
> @@ -76,15 +76,15 @@ static int dm_test_part(struct unit_test_state *uts)
> test(-EINVAL, "#test1", true);
> test(1, "2", false);
> test(1, "2", true);
> - test(-ENOENT, "1:0", false);
> - test(0, "1:0", true);
> - test(1, "1:1", false);
> - test(2, "1:2", false);
> - test(1, "1.0", false);
> - test(0, "1.0:0", true);
> - test(1, "1.0:1", false);
> - test(2, "1.0:2", false);
> - test(-EINVAL, "1#bogus", false);
> + test(-ENOENT, "2:0", false);
> + test(0, "2:0", true);
> + test(1, "2:1", false);
> + test(2, "2:2", false);
> + test(1, "2.0", false);
> + test(0, "2.0:0", true);
> + test(1, "2.0:1", false);
> + test(2, "2.0:2", false);
> + test(-EINVAL, "2#bogus", false);
> test(1, "2#test1", false);
> test(2, "2#test2", false);
> ret = 0;
> --
> 2.33.0
[GIT PULL] Please pull u-boot-pmic next
Dear Tom, Please pull u-boot-pmic next into u-boot next branch. If there is a problem, let me know, plz. Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-pmic/-/pipelines/16767 The following changes since commit 67d8b46e6efa306403e45f4c76f24b86a5e63b75: Merge tag 'u-boot-amlogic-next-20230628' of https://source.denx.de/u-boot/custodians/u-boot-amlogic into next (2023-06-28 10:10:03 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-pmic.git next for you to fetch changes up to 8202bc29454cfdd5839058e4b79c36a3fbb221cf: regulator: handle different error codes in regulator_set_enable_if_allowed (2023-07-04 11:21:12 +0900) Eugen Hristev (3): regulator: implement basic reference counter regulator: rename dev_pdata to plat regulator: handle different error codes in regulator_set_enable_if_allowed drivers/power/regulator/fan53555.c | 10 ++--- drivers/power/regulator/fixed.c| 16 drivers/power/regulator/gpio-regulator.c | 46 +++--- drivers/power/regulator/regulator-uclass.c | 6 +++ drivers/power/regulator/regulator_common.c | 61 -- drivers/power/regulator/regulator_common.h | 27 +++-- 6 files changed, 107 insertions(+), 59 deletions(-)
[GIT PULL] Please pull u-boot-mmc master
Dear Tom, Please pull u-boot-mmc master into u-boot master branch. If there is any problem, let me know, plz. Sorry for too late. Those patches are the fixing reensas-sdhi tuning command error and improve the comment. (I have also tested with this patchset on my board.) Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/16765 The following changes since commit e1bebc16e1d9aa0ddd56c53c0b781f7186dce557: Prepare v2023.07-rc6 (2023-07-03 13:48:58 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master for you to fetch changes up to 40825dbac96542e914df4baa3aa0252a503b6b88: mmc: Set clock when reverting to safe bus mode (2023-07-04 08:14:18 +0900) Hai Pham (2): mmc: Introduce mmc_send_stop_transmission() mmc: renesas-sdhi: Send stop when MMC tuning command fails Marek Vasut (1): mmc: Fix MMC_CMD_STOP_TRANSMISSION response type and add comment Pali Rohár (1): mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition() Valentine Barshak (1): mmc: Set clock when reverting to safe bus mode common/spl/spl_mmc.c | 42 +++--- drivers/mmc/mmc.c | 26 ++ drivers/mmc/renesas-sdhi.c | 11 +++ include/mmc.h | 2 ++ 4 files changed, 74 insertions(+), 7 deletions(-)
Re: [PATCH 2/3] mmc: sdhci-cadence: SD6 Controller support
Hi, On 6/5/23 22:58, Piyush Malgujar wrote: > From: Dhananjay Kangude > > Add support for SD6 controller along with: > - HS200, HS400 and HS400ES support > - Host side Slew and drive configuration > > These changes to support SD6 cadence IP are isolated from the > existing support of SD4 controller. > > Signed-off-by: Dhananjay Kangude > Co-developed-by: Jayanthi Annadurai > Signed-off-by: Jayanthi Annadurai > Signed-off-by: Piyush Malgujar > --- > drivers/mmc/Kconfig |1 + > drivers/mmc/sdhci-cadence.c | 1317 ++- > 2 files changed, 1301 insertions(+), 17 deletions(-) > > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig > index > de01b9687bad28f3b493208c145f5c5dd2f59f78..6b724f1d1ed050b49e31a6cbe5f898b4b636c330 > 100644 > --- a/drivers/mmc/Kconfig > +++ b/drivers/mmc/Kconfig > @@ -566,6 +566,7 @@ config MMC_SDHCI_CADENCE > depends on BLK && DM_MMC > depends on MMC_SDHCI > depends on OF_CONTROL > + select MMC_SDHCI_IO_ACCESSORS > help > This selects the Cadence SD/SDIO/eMMC driver. > > diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c > index > 0bb258da63e442232310d9433b7b6882992bd45d..1d8e8e177eeeb6464ba9ade5fd63c1cca4554bb6 > 100644 > --- a/drivers/mmc/sdhci-cadence.c > +++ b/drivers/mmc/sdhci-cadence.c > @@ -6,6 +6,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -18,8 +19,19 @@ > #include > #include > > +#define SDHCI_CDNS_SD6_MAXCLK2 > + > +#define DEFAULT_CMD_DELAY16 > +#define SDHCI_CDNS_TUNE_START16 > +#define SDHCI_CDNS_TUNE_STEP 6 > +#define SDHCI_CDNS_TUNE_ITERATIONS 40 > + > +#define SDHCI_CDNS_HRS00 0x00 > +#define SDHCI_CDNS_HRS00_SWR BIT(0) > + > +#define SDHCI_CDNS_HRS02 0x08/* PHY access > port */ > +#define SDHCI_CDNS_HRS04 0x10/* PHY access > port */ > /* SD 4.0 Controller HRS - Host Register Set (specific to Cadence) */ > -#define SDHCI_CDNS_HRS04 0x10/* PHY access port */ > #define SDHCI_CDNS_SD4_HRS04_ACK BIT(26) > #define SDHCI_CDNS_SD4_HRS04_RD BIT(25) > #define SDHCI_CDNS_SD4_HRS04_WR BIT(24) > @@ -32,12 +44,93 @@ > #define SDHCI_CDNS_HRS06_TUNE GENMASK(13, 8) > #define SDHCI_CDNS_HRS06_MODE GENMASK(2, 0) > #define SDHCI_CDNS_HRS06_MODE_SD 0x0 > +#define SDHCI_CDNS_HRS06_MODE_LEGACY 0x1 > #define SDHCI_CDNS_HRS06_MODE_MMC_SDR 0x2 > #define SDHCI_CDNS_HRS06_MODE_MMC_DDR 0x3 > #define SDHCI_CDNS_HRS06_MODE_MMC_HS2000x4 > #define SDHCI_CDNS_HRS06_MODE_MMC_HS4000x5 > #define SDHCI_CDNS_HRS06_MODE_MMC_HS400ES 0x6 > > +/* SD 6.0 Controller HRS - Host Register Set (Specific to Cadence) */ > +#define SDHCI_CDNS_SD6_HRS04_ADDRGENMASK(15, 0) > + > +#define SDHCI_CDNS_HRS05 0x14 > + > +#define SDHCI_CDNS_HRS07 0x1C > +#define SDHCI_CDNS_HRS07_RW_COMPENSATE GENMASK(20, 16) > +#define SDHCI_CDNS_HRS07_IDELAY_VAL GENMASK(4, 0) > + > +#define SDHCI_CDNS_HRS09 0x24 > +#define SDHCI_CDNS_HRS09_RDDATA_EN BIT(16) > +#define SDHCI_CDNS_HRS09_RDCMD_EN BIT(15) > +#define SDHCI_CDNS_HRS09_EXTENDED_WR_MODE BIT(3) > +#define SDHCI_CDNS_HRS09_EXTENDED_RD_MODE BIT(2) > +#define SDHCI_CDNS_HRS09_PHY_INIT_COMPLETE BIT(1) > +#define SDHCI_CDNS_HRS09_PHY_SW_RESET BIT(0) > + > +#define SDHCI_CDNS_HRS10 0x28 > +#define SDHCI_CDNS_HRS10_HCSDCLKADJ GENMASK(19, 16) > + > +#define SDHCI_CDNS_SRS11 0x2c > +#define SDHCI_CDNS_SRS11_SW_RESET_ALLBIT(24) > +#define SDHCI_CDNS_SRS11_SW_RESET_CMDBIT(25) > +#define SDHCI_CDNS_SRS11_SW_RESET_DATBIT(26) > + > +#define SDHCI_CDNS_HRS16 0x40 > +#define SDHCI_CDNS_HRS16_WRDATA1_SDCLK_DLY GENMASK(31, 28) > +#define SDHCI_CDNS_HRS16_WRDATA0_SDCLK_DLY GENMASK(27, 24) > +#define SDHCI_CDNS_HRS16_WRCMD1_SDCLK_DLYGENMASK(23, 20) > +#define SDHCI_CDNS_HRS16_WRCMD0_SDCLK_DLYGENMASK(19, 16) > +#define SDHCI_CDNS_HRS16_WRDATA1_DLY GENMASK(15, 12) > +#define SDHCI_CDNS_HRS16_WRDATA0_DLY GENMASK(11, 8) > +#define SDHCI_CDNS_HRS16_WRCMD1_DLY GENMASK(7, 4) > +#define SDHCI_CDNS_HRS16_WRCMD0_DLY GENMASK(3, 0) > + > +/* PHY registers for SD6 controller */ > +#define SDHCI_CDNS_SD6_PHY_DQ_TIMING 0x2000 > +#define SDHCI_CDNS_SD6_PHY_DQ_TIMING_IO_MASK_ALWAYS_ON BIT(31) > +#define SDHCI_CDNS_SD6_PHY_DQ_TIMING_IO_MASK_END > GENMASK(29, 27) > +#define
Re: [PATCH u-boot 0/4] mmc: Explain and cleanup partition selection
Hi, On 4/14/23 06:10, Pali Rohár wrote: > Some people do not want to read review comments in emails. So put > comments and explanation into the source code itself; make emmc > partition selection code more explicit and validate configuration in > bubt command. Sorry for too late. After applied this patch-set, some board are failed with spl's size overflowed The below is one of failed log. +arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 352 bytes +make[2]: *** [scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 +make[1]: *** [Makefile:2049: spl/u-boot-spl] Error 2 Best Regards, Jaehoon Chung > > Pali Rohár (4): > mmc: spl: Make partition choice in > default_spl_mmc_emmc_boot_partition() more explicit > cmd: mvebu/bubt: Validate EXT_CSD[179] eMMC register in > mmc_burn_image() > sunxi: eMMC: Add comments explaining mapping between bootpart and > mmc_switch_part() > board: purism: Use U-Boot mmc function for converting boot part to > part access > > arch/arm/mach-sunxi/board.c| 12 ++- > board/purism/librem5/librem5.c | 6 +- > cmd/mvebu/bubt.c | 24 +++-- > common/spl/spl_mmc.c | 38 +++--- > 4 files changed, 64 insertions(+), 16 deletions(-)
Re: [PATCH] mmc:Remove the legacy mode clock setting operation
On 6/21/23 12:11, xf_...@163.com wrote:
> From: xiefei
>
> Due to the need to read the register value before
> switching to hs mode, the standard protocol does
> not explicitly specify that the setting before
> switching to hs mode is in legacy mode. Therefore,
> the code at this point may cause communication
> abnormalities between the host and card
>
> Signed-off-by: xiefei
NACK.
> ---
> drivers/mmc/mmc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 1af6af82e6..915f446973 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2138,7 +2138,6 @@ static int mmc_select_mode_and_width(struct mmc *mmc,
> uint card_caps)
> mmc_set_card_speed(mmc, MMC_HS, true);
> else
> #endif
> - mmc_set_clock(mmc, mmc->legacy_speed, MMC_CLK_ENABLE);
Even except your intention, your patch didn't consider #ifdef ~ #endif.
Best Regards,
Jaehoon Chung
>
> for_each_mmc_mode_by_pref(card_caps, mwt) {
> for_each_supported_width(card_caps & mwt->widths,
[GIT PULL] Please pull u-boot-mmc master
Dear Tom, Please pull u-boot-mmc master into u-boot master branch. If there is any problem, let me know, plz. Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/15969 The following changes since commit 7daa8dd59bc8455a43cdd2d0e34206e406e5cdcc: Merge tag 'efi-2023-07-rc1' of https://source.denx.de/u-boot/custodians/u-boot-efi (2023-04-09 11:08:39 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master for you to fetch changes up to fbf368f176641029ac30843d4d3dbf26e384df38: cmd: mmc: Return CMD_RET_* from commands (2023-04-10 12:18:45 +0900) Loic Poulain (3): mmc: Check support for TRIM operations mmc: erase: Use TRIM erase when available test: dm: mmc: Check block erasing boundaries Pali Rohár (2): mmc: Use EXT_CSD_EXTRACT_BOOT_PART() macro for extracting boot part cmd: mmc: Return CMD_RET_* from commands Stefan Roese (3): mmc: mv_sdhci: Simplify call to sdhci_mvebu_mbus_config() mmc: mv_sdhci: Remove CONFIG_MMC_SDHCI_IO_ACCESSORS support mmc: mv_sdhci: Depend on DM_MMC board/purism/librem5/librem5.c | 2 +- cmd/mmc.c | 18 ++ cmd/mvebu/bubt.c | 3 +-- common/spl/spl_mmc.c | 2 +- drivers/mmc/Kconfig| 1 + drivers/mmc/mmc.c | 3 +++ drivers/mmc/mmc_write.c| 34 +- drivers/mmc/mv_sdhci.c | 55 +++--- include/mmc.h | 4 +++ test/dm/mmc.c | 14 +-- 10 files changed, 63 insertions(+), 73 deletions(-)
Re: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
Hi Andy,
On 3/15/23 14:26, andy...@sony.com wrote:
> Hi Jaehoon
>
>> commit 4a3ea75de4c5b3053eac326bf1c753ed65df8cb9
>> Author: yuezhang...@sony.com
>> Date: Wed Mar 17 06:44:37 2021 +
>>
>> Revert "mmc: sdhci: set to INT_DATA_END when there are data"
>>
>> This reverts commit 17ea3c862865c0d704646f67dbf8412f9ff54f59.
>>
>> Revert the above commit.
>>
>> To Andy,
>>
>> Was there any problem without above commit?
>
> Without above revert commit, we found "sdhci_transfer_data: Transfer data
> timeout" on db410c board with v2018.01.
Thanks for sharing it. I had been trying to find db410c board.
I found its board, so I will try to check with/without its patch.
After checked, I will reply again ASAP.
Best Regards,
Jaehoon Chung
>
> Best Regards
> Andy Wu
>
>> -Original Message-
>> From: Jaehoon Chung
>> Sent: Monday, March 13, 2023 9:03 PM
>> To: Henrik Grimler ; Jaehoon Chung
>>
>> Cc: jo...@diskos.nl; peng@nxp.com; Wu, Andy ;
>> s...@chromium.org; u-boot@lists.denx.de;
>> ~postmarketos/upstream...@lists.sr.ht
>> Subject: Re: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the
>> SDHCI_QUIRK_BROKEN_R1B"
>>
>> Hi,
>>
>> On 3/11/23 19:31, Henrik Grimler wrote:
>>> Hi Jaehoon,
>>>
>>> On Fri, Feb 10, 2023 at 09:00:33AM +0900, Jaehoon Chung wrote:
>>>> Hi,
>>>>
>>>>> -Original Message-
>>>>> From: U-Boot On Behalf Of Henrik
>>>>> Grimler
>>>>> Sent: Thursday, February 9, 2023 4:04 AM
>>>>> To: jo...@diskos.nl; jh80.ch...@gmail.com; andy...@sony.com;
>>>>> s...@chromium.org; m.szyprow...@samsung.com; u-boot@lists.denx.de;
>>>>> ~postmarketos/upstream...@lists.sr.ht
>>>>> Cc: Henrik Grimler
>>>>> Subject: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the
>> SDHCI_QUIRK_BROKEN_R1B"
>>>>>
>>>>> This reverts commit a034ec06ff1d558bbe11d5ee05edbb4de3ee2215.
>>>>>
>>>>> Commit 4a3ea75de4c5 ("Revert "mmc: sdhci: set to INT_DATA_END when
>>>>> there are data"") reverted the alternative fix that was added for
>>>>> Exynos 4 devices, causing an error when trying to boot from an sdcard:
>>>>>
>>>>> <...>
>>>>> Loading Environment from MMC... sdhci_send_command: Timeout
>> for status update!
>>>>> mmc fail to send stop cmd
>>>>> <...>
>>>>
>>>> Thanks for sharing issue.
>>>>
>>>> I will check this on Exynos Board. Frankly, I hope not to re-add QUIRK.
>>>> Because it was verified that it was working fine without
>> SDHCI_QUIKR_BROKEN_RIB.
>>>
>>> Just wondering if you have had an opportunity to test this on any of
>>> your devices? You can find v2 here, though this patch had no changes:
>>> INVALID URI REMOVED
>>>
>> 3-February/508928.html__;!!JmoZiZGBv3RvKRSx!5wpP-x5Y69S7MynP1sOmQI
>> HaVG
>>> N9_ZLl5dxDDenNWPHdwFnNPdAEvBrUt69tSpQ9o0Nv-LQ9Gie_aGgP$
>>
>> In my opinion,
>>
>> commit 4a3ea75de4c5b3053eac326bf1c753ed65df8cb9
>> Author: yuezhang...@sony.com
>> Date: Wed Mar 17 06:44:37 2021 +
>>
>> Revert "mmc: sdhci: set to INT_DATA_END when there are data"
>>
>> This reverts commit 17ea3c862865c0d704646f67dbf8412f9ff54f59.
>>
>> Revert the above commit.
>>
>> To Andy,
>>
>> Was there any problem without above commit?
>>
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>
>>>
>>>> Best Regards,
>>>> Jaehoon Chung
>>>
>>> Best regards,
>>> Henrik Grimler
>>>
>>>>>
>>>>> Re-add the quirk to allow booting from sdcards again.
>>>>>
>>>>> Signed-off-by: Henrik Grimler
>>>>> ---
>>>>> drivers/mmc/s5p_sdhci.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c index
>>>>> dee84263c3fd..3b74feae68c7 100644
>>>>> --- a/drivers/mmc/s5p_sdhci.c
>>>>> +++ b/drivers/mmc/s5p_sdhci.c
>>>>> @@ -90,7 +90,7 @@ static int s5p_sdhci_core_init(struct sdhci_host
>> *host)
>>>>> host->name = S5P_NAME;
>>>>>
>>>>> host->quirks = SDHCI_QUIRK_NO_HISPD_BIT |
>> SDHCI_QUIRK_BROKEN_VOLTAGE |
>>>>> - SDHCI_QUIRK_32BIT_DMA_ADDR |
>>>>> + SDHCI_QUIRK_BROKEN_R1B | SDHCI_QUIRK_32BIT_DMA_ADDR
>> |
>>>>> SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_USE_WIDE8;
>>>>> host->max_clk = 5200;
>>>>> host->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 |
>> MMC_VDD_165_195;
>>>>> --
>>>>> 2.30.2
>>>>
>>>>
Re: [PATCH v2 2/2] mmc: tmio: Replace ifdeffery with IS_ENABLED/CONFIG_IS_ENABLED macros
On 3/1/23 06:18, Marek Vasut wrote:
> Instead of #if and #ifdef, use IS_ENABLED and CONFIG_IS_ENABLED macros.
> This improves build test coverage. The CONFIG_SPL_BUILD must remain an
> ifdef, as CONFIG_SPL_STACK may not always be defined, e.g. in U-Boot
> proper build. No functional change.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Cc: Jaehoon Chung
> Cc: Peng Fan
> ---
> V2: - Rebase on 1/2
> - Drop DM_REGULATOR check from struct tmio_sd_priv in tmio-common.h
> ---
> drivers/mmc/tmio-common.c | 59 +++
> drivers/mmc/tmio-common.h | 2 --
> 2 files changed, 29 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c
> index 0b24a5a7bdb..d8b6a4a8821 100644
> --- a/drivers/mmc/tmio-common.c
> +++ b/drivers/mmc/tmio-common.c
> @@ -369,22 +369,23 @@ static bool tmio_sd_addr_is_dmaable(struct mmc_data
> *data)
> if (!IS_ALIGNED(addr, TMIO_SD_DMA_MINALIGN))
> return false;
>
> -#if defined(CONFIG_RCAR_GEN3)
> - if (!(data->flags & MMC_DATA_READ) && !IS_ALIGNED(addr, 128))
> - return false;
> - /* Gen3 DMA has 32bit limit */
> - if (sizeof(addr) > 4 && addr >> 32)
> - return false;
> -#endif
> + if (IS_ENABLED(CONFIG_RCAR_GEN3)) {
> + if (!(data->flags & MMC_DATA_READ) && !IS_ALIGNED(addr, 128))
> + return false;
> + /* Gen3 DMA has 32bit limit */
> + if (sizeof(addr) > 4 && addr >> 32)
> + return false;
> + }
>
> -#if defined(CONFIG_ARCH_UNIPHIER) && !defined(CONFIG_ARM64) && \
> - defined(CONFIG_SPL_BUILD)
> - /*
> - * For UniPhier ARMv7 SoCs, the stack is allocated in the locked ways
> - * of L2, which is unreachable from the DMA engine.
> - */
> - if (addr < CONFIG_SPL_STACK)
> - return false;
> +#ifdef CONFIG_SPL_BUILD
> + if (IS_ENABLED(CONFIG_ARCH_UNIPHIER) &&
> !CONFIG_IS_ENABLED(CONFIG_ARM64)) {
> + /*
> + * For UniPhier ARMv7 SoCs, the stack is allocated in locked
> + * ways of L2, which is unreachable from the DMA engine.
> + */
> + if (addr < CONFIG_SPL_STACK)
> + return false;
> + }
> #endif
>
> return true;
> @@ -622,25 +623,22 @@ static void tmio_sd_set_clk_rate(struct tmio_sd_priv
> *priv, struct mmc *mmc)
> static void tmio_sd_set_pins(struct udevice *dev)
> {
> __maybe_unused struct mmc *mmc = mmc_get_mmc_dev(dev);
> -
> -#ifdef CONFIG_DM_REGULATOR
> struct tmio_sd_priv *priv = dev_get_priv(dev);
>
> - if (priv->vqmmc_dev) {
> + if (CONFIG_IS_ENABLED(DM_REGULATOR) && priv->vqmmc_dev) {
> if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180)
> regulator_set_value(priv->vqmmc_dev, 180);
> else
> regulator_set_value(priv->vqmmc_dev, 330);
> regulator_set_enable(priv->vqmmc_dev, true);
> }
> -#endif
>
> -#ifdef CONFIG_PINCTRL
> - if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180)
> - pinctrl_select_state(dev, "state_uhs");
> - else
> - pinctrl_select_state(dev, "default");
> -#endif
> + if (CONFIG_IS_ENABLED(PINCTRL)) {
> + if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180)
> + pinctrl_select_state(dev, "state_uhs");
> + else
> + pinctrl_select_state(dev, "default");
> + }
> }
>
> int tmio_sd_set_ios(struct udevice *dev)
> @@ -734,11 +732,12 @@ int tmio_sd_probe(struct udevice *dev, u32 quirks)
> if (!priv->regbase)
> return -ENOMEM;
>
> -#ifdef CONFIG_DM_REGULATOR
> - device_get_supply_regulator(dev, "vqmmc-supply", >vqmmc_dev);
> - if (priv->vqmmc_dev)
> - regulator_set_value(priv->vqmmc_dev, 330);
> -#endif
> + if (CONFIG_IS_ENABLED(DM_REGULATOR)) {
> + device_get_supply_regulator(dev, "vqmmc-supply",
> + >vqmmc_dev);
> + if (priv->vqmmc_dev)
> + regulator_set_value(priv->vqmmc_dev, 330);
> + }
>
> ret = mmc_of_parse(dev, >cfg);
> if (ret < 0) {
> diff --git a/drivers/mmc/tmio-common.h b/drivers/mmc/tmio-common.h
> index 4d717d85dec..f489fb70766 100644
> --- a/drivers/mmc/tmio-common.h
> +++ b/drivers/mmc/tmio-common.h
> @@ -133,9 +133,7 @@ struct tmio_sd_priv {
> #define TMIO_SD_CAP_RCAR_UHS BIT(7) /* Renesas RCar UHS/SDR modes */
> #define TMIO_SD_CAP_RCAR \
> (TMIO_SD_CAP_RCAR_GEN2 | TMIO_SD_CAP_RCAR_GEN3)
> -#ifdef CONFIG_DM_REGULATOR
> struct udevice *vqmmc_dev;
> -#endif
> #if CONFIG_IS_ENABLED(CLK)
> struct clk clk;
> struct clk clkh;
Re: [PATCH v2 1/2] mmc: tmio: Check 'addr' width before checking for 64bit limitation
On 3/1/23 06:18, Marek Vasut wrote: > The 64bit limitation check is compiled and optimized out on 32bit > platforms, but generates a type width warning: > > drivers/mmc/tmio-common.c: In function ‘tmio_sd_addr_is_dmaable’: > drivers/mmc/tmio-common.c:376:26: warning: right shift count >= width of type > [-Wshift-count-overflow] > 376 | if (addr >> 32) > | ^~ > > Fix the warning by checking the addr type width to see whether the > shift even makes sense in the first place. The width check is also > optimized out at compile time. > > Signed-off-by: Marek Vasut Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > Cc: Jaehoon Chung > Cc: Peng Fan > --- > V2: New patch > --- > drivers/mmc/tmio-common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c > index e9c7d3a2e00..0b24a5a7bdb 100644 > --- a/drivers/mmc/tmio-common.c > +++ b/drivers/mmc/tmio-common.c > @@ -373,7 +373,7 @@ static bool tmio_sd_addr_is_dmaable(struct mmc_data *data) > if (!(data->flags & MMC_DATA_READ) && !IS_ALIGNED(addr, 128)) > return false; > /* Gen3 DMA has 32bit limit */ > - if (addr >> 32) > + if (sizeof(addr) > 4 && addr >> 32) > return false; > #endif >
Re: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
Hi,
On 3/11/23 19:31, Henrik Grimler wrote:
> Hi Jaehoon,
>
> On Fri, Feb 10, 2023 at 09:00:33AM +0900, Jaehoon Chung wrote:
>> Hi,
>>
>>> -Original Message-
>>> From: U-Boot On Behalf Of Henrik Grimler
>>> Sent: Thursday, February 9, 2023 4:04 AM
>>> To: jo...@diskos.nl; jh80.ch...@gmail.com; andy...@sony.com;
>>> s...@chromium.org;
>>> m.szyprow...@samsung.com; u-boot@lists.denx.de;
>>> ~postmarketos/upstream...@lists.sr.ht
>>> Cc: Henrik Grimler
>>> Subject: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the
>>> SDHCI_QUIRK_BROKEN_R1B"
>>>
>>> This reverts commit a034ec06ff1d558bbe11d5ee05edbb4de3ee2215.
>>>
>>> Commit 4a3ea75de4c5 ("Revert "mmc: sdhci: set to INT_DATA_END when
>>> there are data"") reverted the alternative fix that was added for
>>> Exynos 4 devices, causing an error when trying to boot from an sdcard:
>>>
>>> <...>
>>> Loading Environment from MMC... sdhci_send_command: Timeout for status
>>> update!
>>> mmc fail to send stop cmd
>>> <...>
>>
>> Thanks for sharing issue.
>>
>> I will check this on Exynos Board. Frankly, I hope not to re-add QUIRK.
>> Because it was verified that it was working fine without
>> SDHCI_QUIKR_BROKEN_RIB.
>
> Just wondering if you have had an opportunity to test this on any of
> your devices? You can find v2 here, though this patch had no changes:
> https://lists.denx.de/pipermail/u-boot/2023-February/508928.html
In my opinion,
commit 4a3ea75de4c5b3053eac326bf1c753ed65df8cb9
Author: yuezhang...@sony.com
Date: Wed Mar 17 06:44:37 2021 +
Revert "mmc: sdhci: set to INT_DATA_END when there are data"
This reverts commit 17ea3c862865c0d704646f67dbf8412f9ff54f59.
Revert the above commit.
To Andy,
Was there any problem without above commit?
Best Regards,
Jaehoon Chung
>
>> Best Regards,
>> Jaehoon Chung
>
> Best regards,
> Henrik Grimler
>
>>>
>>> Re-add the quirk to allow booting from sdcards again.
>>>
>>> Signed-off-by: Henrik Grimler
>>> ---
>>> drivers/mmc/s5p_sdhci.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
>>> index dee84263c3fd..3b74feae68c7 100644
>>> --- a/drivers/mmc/s5p_sdhci.c
>>> +++ b/drivers/mmc/s5p_sdhci.c
>>> @@ -90,7 +90,7 @@ static int s5p_sdhci_core_init(struct sdhci_host *host)
>>> host->name = S5P_NAME;
>>>
>>> host->quirks = SDHCI_QUIRK_NO_HISPD_BIT | SDHCI_QUIRK_BROKEN_VOLTAGE |
>>> - SDHCI_QUIRK_32BIT_DMA_ADDR |
>>> + SDHCI_QUIRK_BROKEN_R1B | SDHCI_QUIRK_32BIT_DMA_ADDR |
>>> SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_USE_WIDE8;
>>> host->max_clk = 5200;
>>> host->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
>>> --
>>> 2.30.2
>>
>>
RE: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
Hi Henrik,
> -Original Message-
> From: Henrik Grimler
> Sent: Saturday, March 11, 2023 7:32 PM
> To: Jaehoon Chung
> Cc: jo...@diskos.nl; peng@nxp.com; andy...@sony.com; s...@chromium.org;
> u-boot@lists.denx.de;
> ~postmarketos/upstream...@lists.sr.ht
> Subject: Re: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the
> SDHCI_QUIRK_BROKEN_R1B"
>
> Hi Jaehoon,
>
> On Fri, Feb 10, 2023 at 09:00:33AM +0900, Jaehoon Chung wrote:
> > Hi,
> >
> > > -Original Message-
> > > From: U-Boot On Behalf Of Henrik Grimler
> > > Sent: Thursday, February 9, 2023 4:04 AM
> > > To: jo...@diskos.nl; jh80.ch...@gmail.com; andy...@sony.com;
> > > s...@chromium.org;
> > > m.szyprow...@samsung.com; u-boot@lists.denx.de;
> > > ~postmarketos/upstream...@lists.sr.ht
> > > Cc: Henrik Grimler
> > > Subject: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the
> > > SDHCI_QUIRK_BROKEN_R1B"
> > >
> > > This reverts commit a034ec06ff1d558bbe11d5ee05edbb4de3ee2215.
> > >
> > > Commit 4a3ea75de4c5 ("Revert "mmc: sdhci: set to INT_DATA_END when
> > > there are data"") reverted the alternative fix that was added for
> > > Exynos 4 devices, causing an error when trying to boot from an sdcard:
> > >
> > > <...>
> > > Loading Environment from MMC... sdhci_send_command: Timeout for
> > > status update!
> > > mmc fail to send stop cmd
> > > <...>
> >
> > Thanks for sharing issue.
> >
> > I will check this on Exynos Board. Frankly, I hope not to re-add QUIRK.
> > Because it was verified that it was working fine without
> > SDHCI_QUIKR_BROKEN_RIB.
>
> Just wondering if you have had an opportunity to test this on any of
> your devices? You can find v2 here, though this patch had no changes:
> https://protect2.fireeye.com/v1/url?k=f02940b0-91a25586-f028cbff-74fe485fffe0-
> 524f6754708289dd=1=39932d75-a824-41c5-a3b2-
> d9b467bd34a8=https%3A%2F%2Flists.denx.de%2Fpipermail%2Fu-boot%2F2023-February%2F508928.html
I have found what you faced.
U-Boot 2023.04-rc3-00265-gbcf343146ff3-dirty (Mar 13 2023 - 14:35:43 +0900)
CPU: Exynos4412 @ 1 GHz
Model: Odroid based on Exynos4412
Type: u3
DRAM: 2 GiB
Core: 101 devices, 12 uclasses, devicetree: separate
LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
LDO21@TFLASH_2.8V: set 280 uV; enabling
MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
Loading Environment from MMC... sdhci_send_command: Timeout for status update!
mmc fail to send stop cmd
sdhci_send_command: Timeout for status update!
mmc fail to send stop cmd
** fs_devread read error - block
sdhci_send_command: Timeout for status update!
mmc fail to send stop cmd
*** Warning - !read failed, using default environment
I'm checking yours on my u3 board. I will reply today. Sorry for too late.
Best Regards,
Jaehoon Chung
>
> > Best Regards,
> > Jaehoon Chung
>
> Best regards,
> Henrik Grimler
>
> > >
> > > Re-add the quirk to allow booting from sdcards again.
> > >
> > > Signed-off-by: Henrik Grimler
> > > ---
> > > drivers/mmc/s5p_sdhci.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
> > > index dee84263c3fd..3b74feae68c7 100644
> > > --- a/drivers/mmc/s5p_sdhci.c
> > > +++ b/drivers/mmc/s5p_sdhci.c
> > > @@ -90,7 +90,7 @@ static int s5p_sdhci_core_init(struct sdhci_host *host)
> > > host->name = S5P_NAME;
> > >
> > > host->quirks = SDHCI_QUIRK_NO_HISPD_BIT | SDHCI_QUIRK_BROKEN_VOLTAGE |
> > > - SDHCI_QUIRK_32BIT_DMA_ADDR |
> > > + SDHCI_QUIRK_BROKEN_R1B | SDHCI_QUIRK_32BIT_DMA_ADDR |
> > > SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_USE_WIDE8;
> > > host->max_clk = 5200;
> > > host->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
> > > --
> > > 2.30.2
> >
> >
RE: [GIT PULL] Please pull u-boot-mmc master
Hi, > -Original Message- > From: Tom Rini > Sent: Saturday, March 11, 2023 3:09 AM > To: Marek Vasut > Cc: Jaehoon Chung ; U-Boot Mailing List > ; Loic Poulain > ; Stefan Roese ; Jae hoon Chung > > Subject: Re: [GIT PULL] Please pull u-boot-mmc master > > On Fri, Mar 10, 2023 at 05:28:40PM +0100, Marek Vasut wrote: > > On 3/10/23 16:44, Tom Rini wrote: > > > On Fri, Mar 10, 2023 at 01:22:15PM +0900, Jaehoon Chung wrote: > > > > Dear Tom, > > > > > > > > > > > > Please pull u-boot-mmc master into u-boot master branch. > > > > If there is any problem, let me know, plz. > > > > > > At this point in the cycle I have to ask, are these all fixes of > > > specific issues? If not, I'd rather take this to -next. Thanks! > > > > The stuff from me can easily go into next. > > And on that note, I have bad news. This commit: > Author: Marek Vasut > Date: Thu Jan 5 15:28:31 2023 +0100 > > spl: mmc: Pass eMMC HW partition 7 through > > leads to my pine64_plus board hanging in SPL with: > U-Boot SPL 2023.04-rc3-00084-g85f29eb025cb (Mar 10 2023 - 13:05:36 -0500) > DRAM: 1024 MiB > Trying to boot from MMC1 > > When trying to boot from SD card. If you don't have something there that > you can get to fail, let me know and I'll get you access to my lab. I will check again this. Thanks! Best Regards, Jaehoon Chung > > -- > Tom
RE: [GIT PULL] Please pull u-boot-mmc master
Dear Tom, > -Original Message- > From: Tom Rini > Sent: Saturday, March 11, 2023 12:44 AM > To: Jaehoon Chung > Cc: U-Boot Mailing List ; Loic Poulain > ; Marek Vasut > ; Stefan Roese ; Jae hoon Chung > > Subject: Re: [GIT PULL] Please pull u-boot-mmc master > > On Fri, Mar 10, 2023 at 01:22:15PM +0900, Jaehoon Chung wrote: > > Dear Tom, > > > > > > Please pull u-boot-mmc master into u-boot master branch. > > If there is any problem, let me know, plz. > > At this point in the cycle I have to ask, are these all fixes of > specific issues? If not, I'd rather take this to -next. Thanks! Okay. I will request PR as -next again. Discard this PR. Best Regards, Jaehoon Chung > > -- > Tom
[GIT PULL] Please pull u-boot-mmc master
Dear Tom, Please pull u-boot-mmc master into u-boot master branch. If there is any problem, let me know, plz. Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/15512 The following changes since commit b08ffdffdce95e267e782366f4a77bf6b5537b28: Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2023-03-06 14:56:05 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master for you to fetch changes up to 279b0f4a9265bb9fd55cf2005646ebf43e47b50e: mmc: mv_sdhci: Depend on DM_MMC (2023-03-09 14:33:40 +0900) Loic Poulain (3): mmc: Check support for TRIM operations mmc: erase: Use TRIM erase when available test: dm: mmc: Check block erasing boundaries Marek Vasut (2): spl: mmc: Pass eMMC HW partition and SW partition to spl_mmc_get_uboot_raw_sector() spl: mmc: Pass eMMC HW partition 7 through Stefan Roese (3): mmc: mv_sdhci: Simplify call to sdhci_mvebu_mbus_config() mmc: mv_sdhci: Remove CONFIG_MMC_SDHCI_IO_ACCESSORS support mmc: mv_sdhci: Depend on DM_MMC arch/arm/mach-imx/image-container.c | 2 ++ arch/arm/mach-sunxi/board.c | 2 ++ common/spl/spl_mmc.c| 10 +-- drivers/mmc/Kconfig | 1 + drivers/mmc/mmc.c | 3 ++ drivers/mmc/mmc_write.c | 34 +++ drivers/mmc/mv_sdhci.c | 55 ++--- include/mmc.h | 4 +++ test/dm/mmc.c | 14 +- 9 files changed, 58 insertions(+), 67 deletions(-)
Re: [PATCH 3/3] mmc: mv_sdhci: Depend on DM_MMC
On 2/10/23 21:23, Stefan Roese wrote:
> All build targets using this driver already use DM_MMC. So let's depend
> this driver on this Kconfig symbol and remove the non-DM driver part.
>
> Signed-off-by: Stefan Roese
> Cc: Tom Rini
> Cc: Simon Glass
> Cc: Peng Fan
> Cc: Jaehoon Chung
> Reviewed-by: Simon Glass
> Reviewed-by: Jaehoon Chung
Applied to u-boot-mmc/master.
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/Kconfig| 1 +
> drivers/mmc/mv_sdhci.c | 39 +++
> 2 files changed, 8 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 878f867c627b..3f5f61503fb6 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -621,6 +621,7 @@ config MMC_SDHCI_MV
> bool "SDHCI support on Marvell platform"
> depends on ARCH_MVEBU
> depends on MMC_SDHCI
> + depends on DM_MMC
> help
> This selects the Secure Digital Host Controller Interface on
> Marvell platform.
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index 42fa735f3160..dbdd671c88bc 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -15,6 +15,13 @@
> #define SDHCI_WINDOW_CTRL(win) (0x4080 + ((win) << 4))
> #define SDHCI_WINDOW_BASE(win) (0x4084 + ((win) << 4))
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct mv_sdhci_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> +};
> +
> static void sdhci_mvebu_mbus_config(void __iomem *base)
> {
> const struct mbus_dram_target_info *dram;
> @@ -40,37 +47,6 @@ static void sdhci_mvebu_mbus_config(void __iomem *base)
> }
> }
>
> -#ifndef CONFIG_DM_MMC
> -
> -int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 min_clk, u32 quirks)
> -{
> - struct sdhci_host *host = NULL;
> - host = calloc(1, sizeof(*host));
> - if (!host) {
> - printf("sdh_host malloc fail!\n");
> - return -ENOMEM;
> - }
> -
> - host->name = MVSDH_NAME;
> - host->ioaddr = (void *)regbase;
> - host->quirks = quirks;
> - host->max_clk = max_clk;
> -
> - /* Configure SDHCI MBUS mbus bridge windows */
> - sdhci_mvebu_mbus_config((void __iomem *)regbase);
> -
> - return add_sdhci(host, 0, min_clk);
> -}
> -
> -#else
> -
> -DECLARE_GLOBAL_DATA_PTR;
> -
> -struct mv_sdhci_plat {
> - struct mmc_config cfg;
> - struct mmc mmc;
> -};
> -
> static int mv_sdhci_probe(struct udevice *dev)
> {
> struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> @@ -123,4 +99,3 @@ U_BOOT_DRIVER(mv_sdhci_drv) = {
> .priv_auto = sizeof(struct sdhci_host),
> .plat_auto = sizeof(struct mv_sdhci_plat),
> };
> -#endif /* CONFIG_DM_MMC */
Re: [PATCH 2/3] mmc: mv_sdhci: Remove CONFIG_MMC_SDHCI_IO_ACCESSORS support
On 2/10/23 21:23, Stefan Roese wrote:
> CONFIG_MMC_SDHCI_IO_ACCESSORS is not supported and/or used by this
> driver so let's remove these unused parts completely.
>
> Signed-off-by: Stefan Roese
> Cc: Tom Rini
> Cc: Simon Glass
> Cc: Peng Fan
> Cc: Jaehoon Chung
> Reviewed-by: Jaehoon Chung
Applied to u-boot-mmc/master.
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/mv_sdhci.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index 50d03b703ed7..42fa735f3160 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -42,10 +42,6 @@ static void sdhci_mvebu_mbus_config(void __iomem *base)
>
> #ifndef CONFIG_DM_MMC
>
> -#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
> -static struct sdhci_ops mv_ops;
> -#endif /* CONFIG_MMC_SDHCI_IO_ACCESSORS */
> -
> int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 min_clk, u32 quirks)
> {
> struct sdhci_host *host = NULL;
> @@ -59,10 +55,6 @@ int mv_sdh_init(unsigned long regbase, u32 max_clk, u32
> min_clk, u32 quirks)
> host->ioaddr = (void *)regbase;
> host->quirks = quirks;
> host->max_clk = max_clk;
> -#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
> - memset(_ops, 0, sizeof(struct sdhci_ops));
> - host->ops = _ops;
> -#endif
>
> /* Configure SDHCI MBUS mbus bridge windows */
> sdhci_mvebu_mbus_config((void __iomem *)regbase);
Re: [PATCH 1/3] mmc: mv_sdhci: Simplify call to sdhci_mvebu_mbus_config()
On 2/10/23 21:23, Stefan Roese wrote:
> This driver already depends on CONFIG_ARCH_MVEBU, so there is no need
> to have some checks for this Kconfig symbol in the driver itself. Let's
> remove these superfluous checks.
>
> Signed-off-by: Stefan Roese
> Cc: Tom Rini
> Cc: Simon Glass
> Cc: Peng Fan
> Cc: Jaehoon Chung
> Reviewed-by: Jaehoon Chung
Applied to u-boot-mmc/master.
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/mv_sdhci.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index 336ebf141026..50d03b703ed7 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -64,10 +64,8 @@ int mv_sdh_init(unsigned long regbase, u32 max_clk, u32
> min_clk, u32 quirks)
> host->ops = _ops;
> #endif
>
> - if (CONFIG_IS_ENABLED(ARCH_MVEBU)) {
> - /* Configure SDHCI MBUS mbus bridge windows */
> - sdhci_mvebu_mbus_config((void __iomem *)regbase);
> - }
> + /* Configure SDHCI MBUS mbus bridge windows */
> + sdhci_mvebu_mbus_config((void __iomem *)regbase);
>
> return add_sdhci(host, 0, min_clk);
> }
> @@ -103,10 +101,8 @@ static int mv_sdhci_probe(struct udevice *dev)
> if (ret)
> return ret;
>
> - if (CONFIG_IS_ENABLED(ARCH_MVEBU)) {
> - /* Configure SDHCI MBUS mbus bridge windows */
> - sdhci_mvebu_mbus_config(host->ioaddr);
> - }
> + /* Configure SDHCI MBUS mbus bridge windows */
> + sdhci_mvebu_mbus_config(host->ioaddr);
>
> upriv->mmc = host->mmc;
>
Re: [PATCH v2 3/3] test: dm: mmc: Check block erasing boundaries
On 1/26/23 18:24, Loic Poulain wrote:
> Verify that erasing blocks does not impact adjacent ones.
> - Write four blocks [0 1 2 3]
> - Erase two blocks [ 1 2 ]
> - Verify [0 1 2 3 ]
>
> Signed-off-by: Loic Poulain
Applied to u-boot-mmc/master.
Best Regards,
Jaehoon Chung
> ---
> v2: Add this change to the series
>
> test/dm/mmc.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/test/dm/mmc.c b/test/dm/mmc.c
> index f744452ff2..b1eb8bee2f 100644
> --- a/test/dm/mmc.c
> +++ b/test/dm/mmc.c
> @@ -30,7 +30,7 @@ static int dm_test_mmc_blk(struct unit_test_state *uts)
> struct udevice *dev;
> struct blk_desc *dev_desc;
> int i;
> - char write[1024], read[1024];
> + char write[4 * 512], read[4 * 512];
>
> ut_assertok(uclass_get_device(UCLASS_MMC, 0, ));
> ut_assertok(blk_get_device_by_str("mmc", "0", _desc));
> @@ -39,14 +39,14 @@ static int dm_test_mmc_blk(struct unit_test_state *uts)
> ut_asserteq(512, dev_desc->blksz);
> for (i = 0; i < sizeof(write); i++)
> write[i] = i;
> - ut_asserteq(2, blk_dwrite(dev_desc, 0, 2, write));
> - ut_asserteq(2, blk_dread(dev_desc, 0, 2, read));
> + ut_asserteq(4, blk_dwrite(dev_desc, 0, 4, write));
> + ut_asserteq(4, blk_dread(dev_desc, 0, 4, read));
> ut_asserteq_mem(write, read, sizeof(write));
>
> - /* Now erase them */
> - memset(write, '\0', sizeof(write));
> - ut_asserteq(2, blk_derase(dev_desc, 0, 2));
> - ut_asserteq(2, blk_dread(dev_desc, 0, 2, read));
> + /* Now erase two of them [1 - 2] and verify all blocks */
> + memset([512], '\0', 2 * 512);
> + ut_asserteq(2, blk_derase(dev_desc, 1, 2));
> + ut_asserteq(4, blk_dread(dev_desc, 0, 4, read));
> ut_asserteq_mem(write, read, sizeof(write));
>
> return 0;
Re: [PATCH v2 2/3] mmc: erase: Use TRIM erase when available
On 1/26/23 18:24, Loic Poulain wrote:
> The default erase command applies on erase group unit, and
> simply round down to erase group size. When the start block
> is not aligned to erase group size (e.g. erasing partition)
> it causes unwanted erasing of the previous blocks, part of
> the same erase group (e.g. owned by other logical partition,
> or by the partition table itself).
>
> To prevent this issue, a simple solution is to use TRIM as
> argument of the Erase command, which is usually supported
> with eMMC > 4.0, and allow to apply erase operation to write
> blocks instead of erase group
>
> Signed-off-by: Loic Poulain
> Reviewed-by: Simon Glass
Applied to u-boot-mmc/master.
Best Regards,
Jaehoon Chung
> ---
> v2: Add mmc unit test change to the series
>
> drivers/mmc/mmc_write.c | 34 +++---
> 1 file changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
> index 5b7aeeb012..a6f93380dd 100644
> --- a/drivers/mmc/mmc_write.c
> +++ b/drivers/mmc/mmc_write.c
> @@ -15,7 +15,7 @@
> #include
> #include "mmc_private.h"
>
> -static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
> +static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt, u32
> args)
> {
> struct mmc_cmd cmd;
> ulong end;
> @@ -52,7 +52,7 @@ static ulong mmc_erase_t(struct mmc *mmc, ulong start,
> lbaint_t blkcnt)
> goto err_out;
>
> cmd.cmdidx = MMC_CMD_ERASE;
> - cmd.cmdarg = MMC_ERASE_ARG;
> + cmd.cmdarg = args ? args : MMC_ERASE_ARG;
> cmd.resp_type = MMC_RSP_R1b;
>
> err = mmc_send_cmd(mmc, , NULL);
> @@ -77,7 +77,7 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t
> start, lbaint_t blkcnt)
> #endif
> int dev_num = block_dev->devnum;
> int err = 0;
> - u32 start_rem, blkcnt_rem;
> + u32 start_rem, blkcnt_rem, erase_args = 0;
> struct mmc *mmc = find_mmc_device(dev_num);
> lbaint_t blk = 0, blk_r = 0;
> int timeout_ms = 1000;
> @@ -97,13 +97,25 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t
> start, lbaint_t blkcnt)
>*/
> err = div_u64_rem(start, mmc->erase_grp_size, _rem);
> err = div_u64_rem(blkcnt, mmc->erase_grp_size, _rem);
> - if (start_rem || blkcnt_rem)
> - printf("\n\nCaution! Your devices Erase group is 0x%x\n"
> -"The erase range would be change to "
> -"0x" LBAF "~0x" LBAF "\n\n",
> -mmc->erase_grp_size, start & ~(mmc->erase_grp_size - 1),
> -((start + blkcnt + mmc->erase_grp_size - 1)
> -& ~(mmc->erase_grp_size - 1)) - 1);
> + if (start_rem || blkcnt_rem) {
> + if (mmc->can_trim) {
> + /* Trim function applies the erase operation to write
> + * blocks instead of erase groups.
> + */
> + erase_args = MMC_TRIM_ARG;
> + } else {
> + /* The card ignores all LSB's below the erase group
> + * size, rounding down the addess to a erase group
> + * boundary.
> + */
> + printf("\n\nCaution! Your devices Erase group is 0x%x\n"
> +"The erase range would be change to "
> +"0x" LBAF "~0x" LBAF "\n\n",
> +mmc->erase_grp_size, start &
> ~(mmc->erase_grp_size - 1),
> +((start + blkcnt + mmc->erase_grp_size - 1)
> +& ~(mmc->erase_grp_size - 1)) - 1);
> + }
> + }
>
> while (blk < blkcnt) {
> if (IS_SD(mmc) && mmc->ssr.au) {
> @@ -113,7 +125,7 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t
> start, lbaint_t blkcnt)
> blk_r = ((blkcnt - blk) > mmc->erase_grp_size) ?
> mmc->erase_grp_size : (blkcnt - blk);
> }
> - err = mmc_erase_t(mmc, start + blk, blk_r);
> + err = mmc_erase_t(mmc, start + blk, blk_r, erase_args);
> if (err)
> break;
>
Re: [PATCH v2 1/3] mmc: Check support for TRIM operations
On 1/26/23 18:24, Loic Poulain wrote:
> 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
> Reviewed-by: Simon Glass
> Reviewed-by: Jaehoon Chung
Applied to u-boot-mmc/master.
Best Regards,
Jaehoon Chung
> ---
> v2: Add mmc unit test change to the series
>
> drivers/mmc/mmc.c | 3 +++
> include/mmc.h | 4
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 210703ea46..e5f5ccb5f4 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2432,6 +2432,9 @@ static int mmc_startup_v4(struct mmc *mmc)
>
> mmc->wr_rel_set = ext_csd[EXT_CSD_WR_REL_SET];
>
> + mmc->can_trim =
> + !!(ext_csd[EXT_CSD_SEC_FEATURE] & EXT_CSD_SEC_FEATURE_TRIM_EN);
> +
> return 0;
> error:
> if (mmc->ext_csd) {
> diff --git a/include/mmc.h b/include/mmc.h
> index 571fa625d0..f6e23625ca 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -241,6 +241,7 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx)
> #define EXT_CSD_HC_WP_GRP_SIZE 221 /* RO */
> #define EXT_CSD_HC_ERASE_GRP_SIZE224 /* RO */
> #define EXT_CSD_BOOT_MULT226 /* RO */
> +#define EXT_CSD_SEC_FEATURE 231 /* RO */
> #define EXT_CSD_GENERIC_CMD6_TIME 248 /* RO */
> #define EXT_CSD_BKOPS_SUPPORT502 /* RO */
>
> @@ -315,6 +316,8 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx)
> #define EXT_CSD_WR_DATA_REL_USR (1 << 0)/* user data
> area WR_REL */
> #define EXT_CSD_WR_DATA_REL_GP(x)(1 << ((x)+1)) /* GP part (x+1) WR_REL
> */
>
> +#define EXT_CSD_SEC_FEATURE_TRIM_EN (1 << 4) /* Support secure & insecure
> trim */
> +
> #define R1_ILLEGAL_COMMAND (1 << 22)
> #define R1_APP_CMD (1 << 5)
>
> @@ -687,6 +690,7 @@ struct mmc {
> uint tran_speed;
> uint legacy_speed; /* speed for the legacy mode provided by the card */
> uint read_bl_len;
> + bool can_trim;
> #if CONFIG_IS_ENABLED(MMC_WRITE)
> uint write_bl_len;
> uint erase_grp_size;/* in 512-byte sectors */
Re: [PATCH 2/2] spl: mmc: Pass eMMC HW partition 7 through
On 1/5/23 23:28, Marek Vasut wrote:
> The eMMC HW partition 0 and 7 both mean USER HW partition. Use this as
> a mean of propagating A/B copy selection within USER HW partition. The
> spl_mmc_get_uboot_raw_sector() can detect that a USER HW partition is
> in use and based on whether it is 0 or 7, select appropriate sector to
> load from.
>
> Signed-off-by: Fedor Ross
> Signed-off-by: Marek Vasut
Applied to u-boot-mmc/master.
Best Regards,
Jaehoon Chung
> ---
> Cc: Jaehoon Chung
> Cc: Peng Fan
> ---
> common/spl/spl_mmc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index 8a0c7331267..d634ccb0b9a 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -420,7 +420,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
> static struct mmc *mmc;
> u32 boot_mode;
> int err = 0;
> - __maybe_unused int hw_part = 0;
> + __maybe_unused int part, hw_part = 0;
> int mmc_dev;
>
> /* Perform peripheral init only once for an mmc device */
> @@ -445,11 +445,12 @@ int spl_mmc_load(struct spl_image_info *spl_image,
> switch (boot_mode) {
> case MMCSD_MODE_EMMCBOOT:
> hw_part = spl_mmc_emmc_boot_partition(mmc);
> + part = hw_part == 7 ? 0 : hw_part;
>
> if (CONFIG_IS_ENABLED(MMC_TINY))
> - err = mmc_switch_part(mmc, hw_part);
> + err = mmc_switch_part(mmc, part);
> else
> - err = blk_dselect_hwpart(mmc_get_blk_desc(mmc),
> hw_part);
> + err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), part);
>
> if (err) {
> #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> @@ -479,7 +480,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
> #endif
> #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
> err = mmc_load_image_raw_sector(spl_image, bootdev, mmc,
> - raw_sect + spl_mmc_raw_uboot_offset(hw_part));
> + raw_sect + spl_mmc_raw_uboot_offset(part));
> if (!err)
> return err;
> #endif
Re: [PATCH 1/2] spl: mmc: Pass eMMC HW partition and SW partition to spl_mmc_get_uboot_raw_sector()
On 1/5/23 23:28, Marek Vasut wrote:
> Pass both eMMC HW partition and software partition numbers to
> spl_mmc_get_uboot_raw_sector() so the function can better decide
> which offset within the partition to load payload from.
>
> Signed-off-by: Fedor Ross
> Signed-off-by: Marek Vasut
Applied to u-boot-mmc/master.
Best Regards,
Jaehoon Chung
> ---
> Cc: Jaehoon Chung
> Cc: Peng Fan
> ---
> arch/arm/mach-imx/image-container.c | 2 ++
> arch/arm/mach-sunxi/board.c | 2 ++
> common/spl/spl_mmc.c| 15 +--
> 3 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-imx/image-container.c
> b/arch/arm/mach-imx/image-container.c
> index 0e767864822..4518ea1f479 100644
> --- a/arch/arm/mach-imx/image-container.c
> +++ b/arch/arm/mach-imx/image-container.c
> @@ -215,6 +215,8 @@ unsigned long spl_spi_get_uboot_offs(struct spi_flash
> *flash)
>
> #ifdef CONFIG_SPL_MMC
> unsigned long spl_mmc_get_uboot_raw_sector(struct mmc *mmc,
> +unsigned long hw_part,
> +unsigned long raw_part,
> unsigned long raw_sect)
> {
> int end;
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index 0c4b6dd1ca3..5a79e14535a 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -325,6 +325,8 @@ uint32_t sunxi_get_spl_size(void)
> * immediately follow the SPL if that is bigger than that.
> */
> unsigned long spl_mmc_get_uboot_raw_sector(struct mmc *mmc,
> +unsigned long hw_part,
> +unsigned long raw_part,
> unsigned long raw_sect)
> {
> unsigned long spl_size = sunxi_get_spl_size();
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index e4135b20487..8a0c7331267 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -370,6 +370,8 @@ int __weak spl_mmc_boot_partition(const u32 boot_device)
> #endif
>
> unsigned long __weak spl_mmc_get_uboot_raw_sector(struct mmc *mmc,
> + unsigned long hw_part,
> + unsigned long raw_part,
> unsigned long raw_sect)
> {
> return raw_sect;
> @@ -418,7 +420,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
> static struct mmc *mmc;
> u32 boot_mode;
> int err = 0;
> - __maybe_unused int part = 0;
> + __maybe_unused int hw_part = 0;
> int mmc_dev;
>
> /* Perform peripheral init only once for an mmc device */
> @@ -442,12 +444,12 @@ int spl_mmc_load(struct spl_image_info *spl_image,
> err = -EINVAL;
> switch (boot_mode) {
> case MMCSD_MODE_EMMCBOOT:
> - part = spl_mmc_emmc_boot_partition(mmc);
> + hw_part = spl_mmc_emmc_boot_partition(mmc);
>
> if (CONFIG_IS_ENABLED(MMC_TINY))
> - err = mmc_switch_part(mmc, part);
> + err = mmc_switch_part(mmc, hw_part);
> else
> - err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), part);
> + err = blk_dselect_hwpart(mmc_get_blk_desc(mmc),
> hw_part);
>
> if (err) {
> #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> @@ -465,7 +467,8 @@ int spl_mmc_load(struct spl_image_info *spl_image,
> return err;
> }
>
> - raw_sect = spl_mmc_get_uboot_raw_sector(mmc, raw_sect);
> + raw_sect = spl_mmc_get_uboot_raw_sector(mmc, hw_part,
> + raw_part, raw_sect);
>
> #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> err = mmc_load_image_raw_partition(spl_image, bootdev,
> @@ -476,7 +479,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
> #endif
> #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
> err = mmc_load_image_raw_sector(spl_image, bootdev, mmc,
> - raw_sect + spl_mmc_raw_uboot_offset(part));
> + raw_sect + spl_mmc_raw_uboot_offset(hw_part));
> if (!err)
> return err;
> #endif
Re: [PATCH 3/3] mmc: mv_sdhci: Depend on DM_MMC
On 2/10/23 21:23, Stefan Roese wrote:
> All build targets using this driver already use DM_MMC. So let's depend
> this driver on this Kconfig symbol and remove the non-DM driver part.
>
> Signed-off-by: Stefan Roese
> Cc: Tom Rini
> Cc: Simon Glass
> Cc: Peng Fan
> Cc: Jaehoon Chung
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/Kconfig| 1 +
> drivers/mmc/mv_sdhci.c | 39 +++
> 2 files changed, 8 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 878f867c627b..3f5f61503fb6 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -621,6 +621,7 @@ config MMC_SDHCI_MV
> bool "SDHCI support on Marvell platform"
> depends on ARCH_MVEBU
> depends on MMC_SDHCI
> + depends on DM_MMC
> help
> This selects the Secure Digital Host Controller Interface on
> Marvell platform.
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index 42fa735f3160..dbdd671c88bc 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -15,6 +15,13 @@
> #define SDHCI_WINDOW_CTRL(win) (0x4080 + ((win) << 4))
> #define SDHCI_WINDOW_BASE(win) (0x4084 + ((win) << 4))
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct mv_sdhci_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> +};
> +
> static void sdhci_mvebu_mbus_config(void __iomem *base)
> {
> const struct mbus_dram_target_info *dram;
> @@ -40,37 +47,6 @@ static void sdhci_mvebu_mbus_config(void __iomem *base)
> }
> }
>
> -#ifndef CONFIG_DM_MMC
> -
> -int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 min_clk, u32 quirks)
> -{
> - struct sdhci_host *host = NULL;
> - host = calloc(1, sizeof(*host));
> - if (!host) {
> - printf("sdh_host malloc fail!\n");
> - return -ENOMEM;
> - }
> -
> - host->name = MVSDH_NAME;
> - host->ioaddr = (void *)regbase;
> - host->quirks = quirks;
> - host->max_clk = max_clk;
> -
> - /* Configure SDHCI MBUS mbus bridge windows */
> - sdhci_mvebu_mbus_config((void __iomem *)regbase);
> -
> - return add_sdhci(host, 0, min_clk);
> -}
> -
> -#else
> -
> -DECLARE_GLOBAL_DATA_PTR;
> -
> -struct mv_sdhci_plat {
> - struct mmc_config cfg;
> - struct mmc mmc;
> -};
> -
> static int mv_sdhci_probe(struct udevice *dev)
> {
> struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> @@ -123,4 +99,3 @@ U_BOOT_DRIVER(mv_sdhci_drv) = {
> .priv_auto = sizeof(struct sdhci_host),
> .plat_auto = sizeof(struct mv_sdhci_plat),
> };
> -#endif /* CONFIG_DM_MMC */
Re: [PATCH 2/3] mmc: mv_sdhci: Remove CONFIG_MMC_SDHCI_IO_ACCESSORS support
On 2/10/23 21:23, Stefan Roese wrote:
> CONFIG_MMC_SDHCI_IO_ACCESSORS is not supported and/or used by this
> driver so let's remove these unused parts completely.
>
> Signed-off-by: Stefan Roese
> Cc: Tom Rini
> Cc: Simon Glass
> Cc: Peng Fan
> Cc: Jaehoon Chung
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/mv_sdhci.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index 50d03b703ed7..42fa735f3160 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -42,10 +42,6 @@ static void sdhci_mvebu_mbus_config(void __iomem *base)
>
> #ifndef CONFIG_DM_MMC
>
> -#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
> -static struct sdhci_ops mv_ops;
> -#endif /* CONFIG_MMC_SDHCI_IO_ACCESSORS */
> -
> int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 min_clk, u32 quirks)
> {
> struct sdhci_host *host = NULL;
> @@ -59,10 +55,6 @@ int mv_sdh_init(unsigned long regbase, u32 max_clk, u32
> min_clk, u32 quirks)
> host->ioaddr = (void *)regbase;
> host->quirks = quirks;
> host->max_clk = max_clk;
> -#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
> - memset(_ops, 0, sizeof(struct sdhci_ops));
> - host->ops = _ops;
> -#endif
>
> /* Configure SDHCI MBUS mbus bridge windows */
> sdhci_mvebu_mbus_config((void __iomem *)regbase);
Re: [PATCH 1/3] mmc: mv_sdhci: Simplify call to sdhci_mvebu_mbus_config()
On 2/10/23 21:23, Stefan Roese wrote:
> This driver already depends on CONFIG_ARCH_MVEBU, so there is no need
> to have some checks for this Kconfig symbol in the driver itself. Let's
> remove these superfluous checks.
>
> Signed-off-by: Stefan Roese
> Cc: Tom Rini
> Cc: Simon Glass
> Cc: Peng Fan
> Cc: Jaehoon Chung
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/mv_sdhci.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index 336ebf141026..50d03b703ed7 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -64,10 +64,8 @@ int mv_sdh_init(unsigned long regbase, u32 max_clk, u32
> min_clk, u32 quirks)
> host->ops = _ops;
> #endif
>
> - if (CONFIG_IS_ENABLED(ARCH_MVEBU)) {
> - /* Configure SDHCI MBUS mbus bridge windows */
> - sdhci_mvebu_mbus_config((void __iomem *)regbase);
> - }
> + /* Configure SDHCI MBUS mbus bridge windows */
> + sdhci_mvebu_mbus_config((void __iomem *)regbase);
>
> return add_sdhci(host, 0, min_clk);
> }
> @@ -103,10 +101,8 @@ static int mv_sdhci_probe(struct udevice *dev)
> if (ret)
> return ret;
>
> - if (CONFIG_IS_ENABLED(ARCH_MVEBU)) {
> - /* Configure SDHCI MBUS mbus bridge windows */
> - sdhci_mvebu_mbus_config(host->ioaddr);
> - }
> + /* Configure SDHCI MBUS mbus bridge windows */
> + sdhci_mvebu_mbus_config(host->ioaddr);
>
> upriv->mmc = host->mmc;
>
RE: [PATCH v2 1/2] env: mmc: Clean up macro usage
> -Original Message-
> From: U-Boot On Behalf Of Marek Vasut
> Sent: Thursday, February 9, 2023 9:30 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Patrice Chotard
> ; Patrick Delaunay
> ; Tom Rini
> Subject: [PATCH v2 1/2] env: mmc: Clean up macro usage
>
> Consistently use 'if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID))' instead of
> mix of ifdef.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Tom Rini
> ---
> V2: Replace CONFIG_IS_ENABLED(PARTITION_TYPE_GUID) with
> IS_ENABLED(CONFIG_PARTITION_TYPE_GUID)
> ---
> env/mmc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/env/mmc.c b/env/mmc.c
> index 5b01f657a7a..d51a5579128 100644
> --- a/env/mmc.c
> +++ b/env/mmc.c
> @@ -73,8 +73,7 @@ static inline int mmc_offset_try_partition(const char *str,
> int copy, s64 *val)
>
> if (str && !strncmp((const char *)info.name, str,
> sizeof(info.name)))
> break;
> -#ifdef CONFIG_PARTITION_TYPE_GUID
> - if (!str) {
> + if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID) && !str) {
> const efi_guid_t env_guid =
> PARTITION_U_BOOT_ENVIRONMENT;
> efi_guid_t type_guid;
>
> @@ -82,7 +81,6 @@ static inline int mmc_offset_try_partition(const char *str,
> int copy, s64 *val)
> if (!memcmp(_guid, _guid, sizeof(efi_guid_t)))
> break;
> }
> -#endif
> }
>
> /* round up to info.blksz */
> --
> 2.39.1
RE: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
Hi,
> -Original Message-
> From: U-Boot On Behalf Of Henrik Grimler
> Sent: Thursday, February 9, 2023 4:04 AM
> To: jo...@diskos.nl; jh80.ch...@gmail.com; andy...@sony.com;
> s...@chromium.org;
> m.szyprow...@samsung.com; u-boot@lists.denx.de;
> ~postmarketos/upstream...@lists.sr.ht
> Cc: Henrik Grimler
> Subject: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
>
> This reverts commit a034ec06ff1d558bbe11d5ee05edbb4de3ee2215.
>
> Commit 4a3ea75de4c5 ("Revert "mmc: sdhci: set to INT_DATA_END when
> there are data"") reverted the alternative fix that was added for
> Exynos 4 devices, causing an error when trying to boot from an sdcard:
>
> <...>
> Loading Environment from MMC... sdhci_send_command: Timeout for status
> update!
> mmc fail to send stop cmd
> <...>
Thanks for sharing issue.
I will check this on Exynos Board. Frankly, I hope not to re-add QUIRK.
Because it was verified that it was working fine without SDHCI_QUIKR_BROKEN_RIB.
Best Regards,
Jaehoon Chung
>
> Re-add the quirk to allow booting from sdcards again.
>
> Signed-off-by: Henrik Grimler
> ---
> drivers/mmc/s5p_sdhci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
> index dee84263c3fd..3b74feae68c7 100644
> --- a/drivers/mmc/s5p_sdhci.c
> +++ b/drivers/mmc/s5p_sdhci.c
> @@ -90,7 +90,7 @@ static int s5p_sdhci_core_init(struct sdhci_host *host)
> host->name = S5P_NAME;
>
> host->quirks = SDHCI_QUIRK_NO_HISPD_BIT | SDHCI_QUIRK_BROKEN_VOLTAGE |
> - SDHCI_QUIRK_32BIT_DMA_ADDR |
> + SDHCI_QUIRK_BROKEN_R1B | SDHCI_QUIRK_32BIT_DMA_ADDR |
> SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_USE_WIDE8;
> host->max_clk = 5200;
> host->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
> --
> 2.30.2
RE: [PATCH v2 2/3] mmc: erase: Use TRIM erase when available
Hi Loic,
> -Original Message-
> From: Loic Poulain
> Sent: Wednesday, February 8, 2023 5:09 PM
> To: Jaehoon Chung
> Cc: s...@chromium.org; peng@nxp.com; u-boot@lists.denx.de
> Subject: Re: [PATCH v2 2/3] mmc: erase: Use TRIM erase when available
>
> Hi Jaehoon,
>
> On Mon, 6 Feb 2023 at 06:05, Jaehoon Chung wrote:
> >
> > Hi,
> >
> > > -Original Message-
> > > From: Loic Poulain
> > > Sent: Thursday, January 26, 2023 6:24 PM
> > > To: s...@chromium.org; peng@nxp.com; jh80.ch...@samsung.com
> > > Cc: u-boot@lists.denx.de; Loic Poulain
> > > Subject: [PATCH v2 2/3] mmc: erase: Use TRIM erase when available
> > >
> > > The default erase command applies on erase group unit, and
> > > simply round down to erase group size. When the start block
> > > is not aligned to erase group size (e.g. erasing partition)
> > > it causes unwanted erasing of the previous blocks, part of
> > > the same erase group (e.g. owned by other logical partition,
> > > or by the partition table itself).
> > >
> > > To prevent this issue, a simple solution is to use TRIM as
> > > argument of the Erase command, which is usually supported
> > > with eMMC > 4.0, and allow to apply erase operation to write
> > > blocks instead of erase group
> > >
> > > Signed-off-by: Loic Poulain
> > > ---
> > > v2: Add mmc unit test change to the series
> > >
> > > drivers/mmc/mmc_write.c | 34 +++---
> > > 1 file changed, 23 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
> > > index 5b7aeeb012..a6f93380dd 100644
> > > --- a/drivers/mmc/mmc_write.c
> > > +++ b/drivers/mmc/mmc_write.c
> > > @@ -15,7 +15,7 @@
> > > #include
> > > #include "mmc_private.h"
> > >
> > > -static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
> > > +static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt,
> > > u32 args)
> > > {
> > > struct mmc_cmd cmd;
> > > ulong end;
> > > @@ -52,7 +52,7 @@ static ulong mmc_erase_t(struct mmc *mmc, ulong start,
> > > lbaint_t blkcnt)
> > > goto err_out;
> > >
> > > cmd.cmdidx = MMC_CMD_ERASE;
> > > - cmd.cmdarg = MMC_ERASE_ARG;
> > > + cmd.cmdarg = args ? args : MMC_ERASE_ARG;
> >
> > It there any case to pass by other value?
>
> Not at the moment, but it can be used to support eMMC 'Secure Erase' arg.
I had mis-read. I had read the MMC_TRIM_ARG as MMC_ERASE_ARG. Thanks for kindly
explanation. :)
Best Regards,
Jaehoon Chung
>
> Regards,
> Loic
RE: [PATCH v2 2/3] mmc: erase: Use TRIM erase when available
Hi,
> -Original Message-
> From: Loic Poulain
> Sent: Thursday, January 26, 2023 6:24 PM
> To: s...@chromium.org; peng@nxp.com; jh80.ch...@samsung.com
> Cc: u-boot@lists.denx.de; Loic Poulain
> Subject: [PATCH v2 2/3] mmc: erase: Use TRIM erase when available
>
> The default erase command applies on erase group unit, and
> simply round down to erase group size. When the start block
> is not aligned to erase group size (e.g. erasing partition)
> it causes unwanted erasing of the previous blocks, part of
> the same erase group (e.g. owned by other logical partition,
> or by the partition table itself).
>
> To prevent this issue, a simple solution is to use TRIM as
> argument of the Erase command, which is usually supported
> with eMMC > 4.0, and allow to apply erase operation to write
> blocks instead of erase group
>
> Signed-off-by: Loic Poulain
> ---
> v2: Add mmc unit test change to the series
>
> drivers/mmc/mmc_write.c | 34 +++---
> 1 file changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
> index 5b7aeeb012..a6f93380dd 100644
> --- a/drivers/mmc/mmc_write.c
> +++ b/drivers/mmc/mmc_write.c
> @@ -15,7 +15,7 @@
> #include
> #include "mmc_private.h"
>
> -static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
> +static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt, u32
> args)
> {
> struct mmc_cmd cmd;
> ulong end;
> @@ -52,7 +52,7 @@ static ulong mmc_erase_t(struct mmc *mmc, ulong start,
> lbaint_t blkcnt)
> goto err_out;
>
> cmd.cmdidx = MMC_CMD_ERASE;
> - cmd.cmdarg = MMC_ERASE_ARG;
> + cmd.cmdarg = args ? args : MMC_ERASE_ARG;
It there any case to pass by other value?
Best Regards,
Jaehoon Chung
> cmd.resp_type = MMC_RSP_R1b;
>
> err = mmc_send_cmd(mmc, , NULL);
> @@ -77,7 +77,7 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t
> start, lbaint_t blkcnt)
> #endif
> int dev_num = block_dev->devnum;
> int err = 0;
> - u32 start_rem, blkcnt_rem;
> + u32 start_rem, blkcnt_rem, erase_args = 0;
> struct mmc *mmc = find_mmc_device(dev_num);
> lbaint_t blk = 0, blk_r = 0;
> int timeout_ms = 1000;
> @@ -97,13 +97,25 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t
> start, lbaint_t blkcnt)
>*/
> err = div_u64_rem(start, mmc->erase_grp_size, _rem);
> err = div_u64_rem(blkcnt, mmc->erase_grp_size, _rem);
> - if (start_rem || blkcnt_rem)
> - printf("\n\nCaution! Your devices Erase group is 0x%x\n"
> -"The erase range would be change to "
> -"0x" LBAF "~0x" LBAF "\n\n",
> -mmc->erase_grp_size, start & ~(mmc->erase_grp_size - 1),
> -((start + blkcnt + mmc->erase_grp_size - 1)
> -& ~(mmc->erase_grp_size - 1)) - 1);
> + if (start_rem || blkcnt_rem) {
> + if (mmc->can_trim) {
> + /* Trim function applies the erase operation to write
> + * blocks instead of erase groups.
> + */
> + erase_args = MMC_TRIM_ARG;
> + } else {
> + /* The card ignores all LSB's below the erase group
> + * size, rounding down the addess to a erase group
> + * boundary.
> + */
> + printf("\n\nCaution! Your devices Erase group is 0x%x\n"
> +"The erase range would be change to "
> +"0x" LBAF "~0x" LBAF "\n\n",
> +mmc->erase_grp_size, start &
> ~(mmc->erase_grp_size - 1),
> +((start + blkcnt + mmc->erase_grp_size - 1)
> +& ~(mmc->erase_grp_size - 1)) - 1);
> + }
> + }
>
> while (blk < blkcnt) {
> if (IS_SD(mmc) && mmc->ssr.au) {
> @@ -113,7 +125,7 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t
> start, lbaint_t blkcnt)
> blk_r = ((blkcnt - blk) > mmc->erase_grp_size) ?
> mmc->erase_grp_size : (blkcnt - blk);
> }
> - err = mmc_erase_t(mmc, start + blk, blk_r);
> + err = mmc_erase_t(mmc, start + blk, blk_r, erase_args);
> if (err)
> break;
>
> --
> 2.34.1
RE: [PATCH v2 1/3] mmc: Check support for TRIM operations
> -Original Message-
> From: Loic Poulain
> Sent: Thursday, January 26, 2023 6:24 PM
> To: s...@chromium.org; peng@nxp.com; jh80.ch...@samsung.com
> Cc: u-boot@lists.denx.de; Loic Poulain
> Subject: [PATCH v2 1/3] mmc: Check support for TRIM operations
>
> 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
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> v2: Add mmc unit test change to the series
>
> drivers/mmc/mmc.c | 3 +++
> include/mmc.h | 4
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 210703ea46..e5f5ccb5f4 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2432,6 +2432,9 @@ static int mmc_startup_v4(struct mmc *mmc)
>
> mmc->wr_rel_set = ext_csd[EXT_CSD_WR_REL_SET];
>
> + mmc->can_trim =
> + !!(ext_csd[EXT_CSD_SEC_FEATURE] & EXT_CSD_SEC_FEATURE_TRIM_EN);
> +
> return 0;
> error:
> if (mmc->ext_csd) {
> diff --git a/include/mmc.h b/include/mmc.h
> index 571fa625d0..f6e23625ca 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -241,6 +241,7 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx)
> #define EXT_CSD_HC_WP_GRP_SIZE 221 /* RO */
> #define EXT_CSD_HC_ERASE_GRP_SIZE224 /* RO */
> #define EXT_CSD_BOOT_MULT226 /* RO */
> +#define EXT_CSD_SEC_FEATURE 231 /* RO */
> #define EXT_CSD_GENERIC_CMD6_TIME 248 /* RO */
> #define EXT_CSD_BKOPS_SUPPORT502 /* RO */
>
> @@ -315,6 +316,8 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx)
> #define EXT_CSD_WR_DATA_REL_USR (1 << 0)/* user data
> area WR_REL */
> #define EXT_CSD_WR_DATA_REL_GP(x)(1 << ((x)+1)) /* GP part (x+1) WR_REL
> */
>
> +#define EXT_CSD_SEC_FEATURE_TRIM_EN (1 << 4) /* Support secure & insecure
> trim */
> +
> #define R1_ILLEGAL_COMMAND (1 << 22)
> #define R1_APP_CMD (1 << 5)
>
> @@ -687,6 +690,7 @@ struct mmc {
> uint tran_speed;
> uint legacy_speed; /* speed for the legacy mode provided by the card */
> uint read_bl_len;
> + bool can_trim;
> #if CONFIG_IS_ENABLED(MMC_WRITE)
> uint write_bl_len;
> uint erase_grp_size;/* in 512-byte sectors */
> --
> 2.34.1
RE: [PATCH v2 145/169] Correct SPL use of SUPPORT_EMMC_RPMB
> -Original Message- > From: U-Boot On Behalf Of Simon Glass > Sent: Monday, February 6, 2023 7:41 AM > To: U-Boot Mailing List > Cc: Tom Rini ; Simon Glass > Subject: [PATCH v2 145/169] Correct SPL use of SUPPORT_EMMC_RPMB > > This converts 1 usage of this option to the non-SPL form, since there is > no SPL_SUPPORT_EMMC_RPMB defined in Kconfig > > Signed-off-by: Simon Glass Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > > (no changes since v1) > > drivers/mmc/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile > index 3a664c2ebbb..3dc757108d5 100644 > --- a/drivers/mmc/Makefile > +++ b/drivers/mmc/Makefile > @@ -46,7 +46,7 @@ obj-$(CONFIG_MMC_MXS) += mxsmmc.o > obj-$(CONFIG_MMC_OCTEONTX) += octeontx_hsmmc.o > obj-$(CONFIG_MMC_OWL)+= owl_mmc.o > obj-$(CONFIG_MMC_PCI)+= pci_mmc.o > -obj-$(CONFIG_$(SPL_TPL_)SUPPORT_EMMC_RPMB) += rpmb.o > +obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o > obj-$(CONFIG_MMC_SANDBOX)+= sandbox_mmc.o > obj-$(CONFIG_SH_MMCIF) += sh_mmcif.o > obj-$(CONFIG_SH_SDHI) += sh_sdhi.o > -- > 2.39.1.519.gcb327c4b5f-goog
RE: [PATCH v2 107/169] Correct SPL use of MMC_QUIRKS
> -Original Message-
> From: U-Boot On Behalf Of Simon Glass
> Sent: Monday, February 6, 2023 7:40 AM
> To: U-Boot Mailing List
> Cc: Tom Rini ; Simon Glass
> Subject: [PATCH v2 107/169] Correct SPL use of MMC_QUIRKS
>
> This converts 1 usage of this option to the non-SPL form, since there is
> no SPL_MMC_QUIRKS defined in Kconfig
>
> Signed-off-by: Simon Glass
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> (no changes since v1)
>
> drivers/mmc/mmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 210703ea46b..fd4aa946e2a 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -247,7 +247,7 @@ static int mmc_send_cmd_retry(struct mmc *mmc, struct
> mmc_cmd *cmd,
> static int mmc_send_cmd_quirks(struct mmc *mmc, struct mmc_cmd *cmd,
> struct mmc_data *data, u32 quirk, uint retries)
> {
> - if (CONFIG_IS_ENABLED(MMC_QUIRKS) && mmc->quirks & quirk)
> + if (IS_ENABLED(CONFIG_MMC_QUIRKS) && mmc->quirks & quirk)
> return mmc_send_cmd_retry(mmc, cmd, data, retries);
> else
> return mmc_send_cmd(mmc, cmd, data);
> --
> 2.39.1.519.gcb327c4b5f-goog
RE: [PATCH v3 16/76] Drop dataflash_mmc_mux command
> -Original Message-
> From: U-Boot On Behalf Of Simon Glass
> Sent: Thursday, February 2, 2023 5:19 AM
> To: u-boot@lists.denx.de
> Cc: Tom Rini ; Simon Glass
> Subject: [PATCH v3 16/76] Drop dataflash_mmc_mux command
>
> This is not used. Drop it.
>
> Signed-off-by: Simon Glass
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> (no changes since v1)
>
> cmd/Makefile| 1 -
> cmd/dataflash_mmc_mux.c | 48 -
> 2 files changed, 49 deletions(-)
> delete mode 100644 cmd/dataflash_mmc_mux.c
>
> diff --git a/cmd/Makefile b/cmd/Makefile
> index 4adc7530a0a..b6888a52f49 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -47,7 +47,6 @@ obj-$(CONFIG_CMD_CONFIG) += config.o
> obj-$(CONFIG_CMD_CONITRACE) += conitrace.o
> obj-$(CONFIG_CMD_CONSOLE) += console.o
> obj-$(CONFIG_CMD_CPU) += cpu.o
> -obj-$(CONFIG_DATAFLASH_MMC_SELECT) += dataflash_mmc_mux.o
> obj-$(CONFIG_CMD_DATE) += date.o
> obj-$(CONFIG_CMD_DEMO) += demo.o
> obj-$(CONFIG_CMD_DM) += dm.o
> diff --git a/cmd/dataflash_mmc_mux.c b/cmd/dataflash_mmc_mux.c
> deleted file mode 100644
> index 73876e9464a..000
> --- a/cmd/dataflash_mmc_mux.c
> +++ /dev/null
> @@ -1,48 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * (C) Copyright 2000
> - * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> - */
> -
> -#include
> -#include
> -
> -static int mmc_nspi (const char *);
> -
> -int do_dataflash_mmc_mux(struct cmd_tbl *cmdtp, int flag, int argc,
> - char *const argv[])
> -{
> - switch (argc) {
> - case 2: /* on / off */
> - switch (mmc_nspi (argv[1])) {
> - case 0: AT91F_SelectSPI ();
> - break;
> - case 1: AT91F_SelectMMC ();
> - break;
> - }
> - case 1: /* get status */
> - printf ("Mux is configured to be %s\n",
> - AT91F_GetMuxStatus () ? "MMC" : "SPI");
> - return 0;
> - default:
> - return CMD_RET_USAGE;
> - }
> - return 0;
> -}
> -
> -static int mmc_nspi (const char *s)
> -{
> - if (strcmp (s, "mmc") == 0) {
> - return 1;
> - } else if (strcmp (s, "spi") == 0) {
> - return 0;
> - }
> - return -1;
> -}
> -
> -U_BOOT_CMD(
> - dataflash_mmc_mux, 2, 1, do_dataflash_mmc_mux,
> - "enable or disable MMC or SPI\n",
> - "[mmc, spi]\n"
> - "- enable or disable MMC or SPI"
> -);
> --
> 2.39.1.456.gfc5497dd1b-goog
Re: [PATCH] env: mmc: Fix offset issue for env save
On 1/31/23 15:41, Ye Li wrote:
> Fix the issue in commit 46c9016 (env: mcc: Drop unnecessary #ifdefs)
> If CONFIG_SYS_REDUNDAND_ENVIRONMENT is not defined, the offset value
> becomes undetermined, so write env to unexpected offset.
>
> Signed-off-by: Ye Li
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> env/mmc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/env/mmc.c b/env/mmc.c
> index 8576141..5b01f65 100644
> --- a/env/mmc.c
> +++ b/env/mmc.c
> @@ -273,11 +273,11 @@ static int env_mmc_save(void)
> if (ret)
> goto fini;
> }
> + }
>
> - if (mmc_get_env_addr(mmc, copy, )) {
> - ret = 1;
> - goto fini;
> - }
> + if (mmc_get_env_addr(mmc, copy, )) {
> + ret = 1;
> + goto fini;
> }
>
> printf("Writing to %sMMC(%d)... ", copy ? "redundant " : "", dev);
[GIT PULL] Please pull u-boot-mmc master
Dear Tom, Please pull u-boot-mmc master into u-boot master branch. If there is any problem, let me know, plz. Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/14951 The following changes since commit 30db474704405be823259851cbb76fa05366c8af: Prepare v2023.04-rc1 (2023-01-30 15:36:45 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master for you to fetch changes up to a1f8abf4686065f46ac840e956a1aeb68d90d969: mmc: zynq_sdhci: Add support and quirk for HS400 (2023-01-31 22:02:27 +0900) Ashok Reddy Soma (4): mmc: zynq_sdhci: Add support for eMMC5.1 for Versal NET platform mmc: sdhci: Check and call config_dll callback functions mmc: sdhci: Enable HS400 support if available in caps mmc: zynq_sdhci: Add support and quirk for HS400 Marek Vasut (1): cmd: mmc: Expand bkops handling cmd/mmc.c| 49 ++-- drivers/mmc/mmc.c| 14 ++- drivers/mmc/sdhci.c | 20 drivers/mmc/zynq_sdhci.c | 292 ++- include/mmc.h| 14 ++- include/sdhci.h | 5 + 6 files changed, 375 insertions(+), 19 deletions(-)
Re: [PATCH 07/13] mmc: renesas-sdhi: Flag non-standard SDnH handling for V3M
On 1/27/23 05:06, Marek Vasut wrote:
> From: Hai Pham
>
> V3M handles SDnH differently than other Gen3 SoCs, so let's add a
> separate entry for that. This will allow better SDnH handling in the
> future.
>
> Based on Linux commit 627151b4966f ("mmc: renesas_sdhi: Flag
> non-standard SDnH handling for V3M") by Wolfram Sang
>
> Signed-off-by: Hai Pham
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/renesas-sdhi.c | 6 ++
> drivers/mmc/tmio-common.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
> index f85ced26ed8..f30d7847bf2 100644
> --- a/drivers/mmc/renesas-sdhi.c
> +++ b/drivers/mmc/renesas-sdhi.c
> @@ -930,6 +930,12 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
> priv->read_poll_flag = TMIO_SD_DMA_INFO1_END_RD;
> else
> priv->read_poll_flag = TMIO_SD_DMA_INFO1_END_RD2;
> +
> + /* V3M handles SD0H differently than other Gen3 SoCs */
> + if (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A77970)
> + priv->needs_clkh_fallback = true;
> + else
> + priv->needs_clkh_fallback = false;
> }
>
> static int renesas_sdhi_probe(struct udevice *dev)
> diff --git a/drivers/mmc/tmio-common.h b/drivers/mmc/tmio-common.h
> index 59d5a0e22e9..e517ed978bf 100644
> --- a/drivers/mmc/tmio-common.h
> +++ b/drivers/mmc/tmio-common.h
> @@ -151,6 +151,7 @@ struct tmio_sd_priv {
> u8 hs400_bad_tap;
> const u8*adjust_hs400_calib_table;
> u32 quirks;
> + boolneeds_clkh_fallback;
> #endif
> ulong (*clk_get_rate)(struct tmio_sd_priv *);
> };
Re: [PATCH 06/13] mmc: renesas-sdhi: Drop R-Car H3 ES3.0 HS400 calibration table
On 1/27/23 05:06, Marek Vasut wrote:
> From: Hai Pham
>
> It is unnecessary, so clean it up.
>
> Reviewed-by: Marek Vasut
> Signed-off-by: Hai Pham
> Signed-off-by: Marek Vasut # update commit
> message, mention ES3.0
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/renesas-sdhi.c | 16
> 1 file changed, 16 deletions(-)
>
> diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
> index 95db8aca931..f85ced26ed8 100644
> --- a/drivers/mmc/renesas-sdhi.c
> +++ b/drivers/mmc/renesas-sdhi.c
> @@ -71,13 +71,6 @@
>
> #define CALIB_TABLE_MAX (RENESAS_SDHI_SCC_TMPPORT_CALIB_CODE_MASK + 1)
>
> -static const u8 r8a7795_calib_table[2][CALIB_TABLE_MAX] = {
> - { 0, 0, 0, 0, 0, 1, 1, 2, 3, 4, 5, 5, 6, 6, 7, 11,
> - 15, 16, 16, 17, 17, 17, 17, 17, 18, 18, 18, 18, 19, 20, 21, 21 },
> - { 3, 3, 4, 4, 5, 6, 6, 7, 8, 8, 9, 9, 10, 11, 12, 15,
> - 16, 16, 17, 17, 17, 17, 17, 18, 18, 18, 18, 19, 20, 21, 22, 22 }
> -};
> -
> static const u8 r8a7796_rev13_calib_table[2][CALIB_TABLE_MAX] = {
> { 3, 3, 3, 3, 3, 3, 3, 4, 4, 5, 6, 7, 8, 9, 10, 15,
>16, 16, 16, 16, 16, 16, 17, 18, 18, 19, 20, 21, 22, 23, 24, 25 },
> @@ -886,15 +879,6 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
> (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A77965))
> priv->hs400_bad_tap = BIT(2) | BIT(3) | BIT(6) | BIT(7);
>
> - /* H3 ES3.0 can use HS400 with manual adjustment */
> - if ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7795) &&
> - (rmobile_get_cpu_rev_integer() >= 3)) {
> - priv->adjust_hs400_enable = true;
> - priv->adjust_hs400_offset = 0;
> - priv->adjust_hs400_calib_table =
> - r8a7795_calib_table[!rmobile_is_gen3_mmc0(priv)];
> - }
> -
> /* M3W ES1.x for x>2 can use HS400 with manual adjustment and taps */
> if ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
> (rmobile_get_cpu_rev_integer() == 1) &&
Re: [PATCH 05/13] mmc: renesas-sdhi: Add R8A77961 M3-W+ support
On 1/27/23 05:05, Marek Vasut wrote:
> From: Hai Pham
>
> Support R8A77961 M3-W+ SoC.
>
> Reviewed-by: Marek Vasut
> Signed-off-by: Hai Pham
> Signed-off-by: Marek Vasut
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/renesas-sdhi.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
> index 90e8aaddb05..95db8aca931 100644
> --- a/drivers/mmc/renesas-sdhi.c
> +++ b/drivers/mmc/renesas-sdhi.c
> @@ -836,6 +836,7 @@ static const struct udevice_id renesas_sdhi_match[] = {
> { .compatible = "renesas,sdhi-r8a7794", .data = RENESAS_GEN2_QUIRKS },
> { .compatible = "renesas,sdhi-r8a7795", .data = RENESAS_GEN3_QUIRKS },
> { .compatible = "renesas,sdhi-r8a7796", .data = RENESAS_GEN3_QUIRKS },
> + { .compatible = "renesas,sdhi-r8a77961", .data = RENESAS_GEN3_QUIRKS },
> { .compatible = "renesas,rcar-gen3-sdhi", .data = RENESAS_GEN3_QUIRKS },
> { .compatible = "renesas,sdhi-r8a77965", .data = RENESAS_GEN3_QUIRKS },
> { .compatible = "renesas,sdhi-r8a77970", .data = RENESAS_GEN3_QUIRKS },
> @@ -905,6 +906,11 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
> r8a7796_rev13_calib_table[!rmobile_is_gen3_mmc0(priv)];
> }
>
> + /* M3W+ bad taps */
> + if ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
> + (rmobile_get_cpu_rev_integer() == 3))
> + priv->hs400_bad_tap = BIT(1) | BIT(3) | BIT(5) | BIT(7);
> +
> /* M3N can use HS400 with manual adjustment */
> if (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A77965) {
> priv->adjust_hs400_enable = true;
Re: [PATCH 04/13] mmc: renesas-sdhi: Adjust HS400 calibration offsets for M3-W r1.3
On 1/27/23 05:05, Marek Vasut wrote:
> From: Hai Pham
>
> Still uses 0x3 for now, adjust the offset value to TMPPORT3 accordingly
>
> Reviewed-by: Marek Vasut
> Signed-off-by: Hai Pham
> Signed-off-by: Marek Vasut
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/renesas-sdhi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
> index f9155bc44de..90e8aaddb05 100644
> --- a/drivers/mmc/renesas-sdhi.c
> +++ b/drivers/mmc/renesas-sdhi.c
> @@ -899,7 +899,7 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
> (rmobile_get_cpu_rev_integer() == 1) &&
> (rmobile_get_cpu_rev_fraction() > 2)) {
> priv->adjust_hs400_enable = true;
> - priv->adjust_hs400_offset = 0;
> + priv->adjust_hs400_offset = 3;
> priv->hs400_bad_tap = BIT(1) | BIT(3) | BIT(5) | BIT(7);
> priv->adjust_hs400_calib_table =
> r8a7796_rev13_calib_table[!rmobile_is_gen3_mmc0(priv)];
Re: [PATCH 03/13] mmc: renesas-sdhi: Adjust HS400 calibration tables
On 1/27/23 05:05, Marek Vasut wrote:
> From: Hai Pham
>
> Adjust HS400 calibration tables based on Linux settings
>
> Reviewed-by: Marek Vasut
> Signed-off-by: Hai Pham
> Signed-off-by: Marek Vasut
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/renesas-sdhi.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
> index 3ec0444700e..f9155bc44de 100644
> --- a/drivers/mmc/renesas-sdhi.c
> +++ b/drivers/mmc/renesas-sdhi.c
> @@ -79,24 +79,24 @@ static const u8 r8a7795_calib_table[2][CALIB_TABLE_MAX] =
> {
> };
>
> static const u8 r8a7796_rev13_calib_table[2][CALIB_TABLE_MAX] = {
> - { 0, 0, 0, 0, 2, 3, 4, 4, 5, 6, 7, 7, 8, 9, 9, 10,
> - 11, 12, 13, 15, 16, 17, 17, 18, 19, 19, 20, 21, 21, 22, 23, 23 },
> - { 1, 2, 2, 3, 4, 4, 5, 6, 6, 7, 8, 9, 9, 10, 11, 12,
> - 13, 14, 15, 16, 17, 17, 18, 19, 20, 20, 21, 22, 22, 23, 24, 24 }
> + { 3, 3, 3, 3, 3, 3, 3, 4, 4, 5, 6, 7, 8, 9, 10, 15,
> + 16, 16, 16, 16, 16, 16, 17, 18, 18, 19, 20, 21, 22, 23, 24, 25 },
> + { 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6, 7, 8, 11,
> + 12, 17, 18, 18, 18, 18, 18, 18, 18, 19, 20, 21, 22, 23, 25, 25 }
> };
>
> static const u8 r8a77965_calib_table[2][CALIB_TABLE_MAX] = {
> - { 0, 1, 2, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15,
> - 16, 17, 18, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 29 },
> - { 0, 1, 2, 2, 2, 3, 4, 5, 6, 7, 9, 10, 11, 12, 13, 15,
> - 16, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 31 }
> + { 1, 2, 6, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 15, 15, 16,
> + 17, 18, 19, 20, 21, 22, 23, 24, 25, 25, 26, 27, 28, 29, 30, 31 },
> + { 2, 3, 4, 4, 5, 6, 7, 9, 10, 11, 12, 13, 14, 15, 16, 17,
> + 17, 17, 20, 21, 22, 23, 24, 25, 27, 28, 29, 30, 31, 31, 31, 31 }
> };
>
> static const u8 r8a77990_calib_table[2][CALIB_TABLE_MAX] = {
> { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> - { 0, 0, 1, 2, 3, 4, 4, 4, 4, 5, 5, 6, 7, 8, 10, 11,
> - 12, 13, 14, 16, 17, 18, 18, 18, 19, 19, 20, 24, 26, 26, 26, 26 }
> + { 0, 0, 0, 1, 2, 3, 3, 4, 4, 4, 5, 5, 6, 8, 9, 10,
> + 11, 12, 13, 15, 16, 17, 17, 18, 18, 19, 20, 22, 24, 25, 26, 26 }
> };
>
> static int rmobile_is_gen3_mmc0(struct tmio_sd_priv *priv)
Re: [PATCH 02/13] mmc: renesas-sdhi: Filter out HS400 on M3-W r1.2, V3M, V3H r1.x, D3
On 1/27/23 05:05, Marek Vasut wrote:
> From: Hai Pham
>
> Further filter out HS400 support on certain SoCs.
>
> Since M3-W r1.2 does not support HS400, drop the calibration table and
> rename the one for M3-W r1.3 to r8a7796_rev13_calib_table
>
> Reviewed-by: Marek Vasut
> Signed-off-by: Hai Pham
> Signed-off-by: Marek Vasut
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/renesas-sdhi.c | 29 -
> 1 file changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
> index 9f8a272d03d..3ec0444700e 100644
> --- a/drivers/mmc/renesas-sdhi.c
> +++ b/drivers/mmc/renesas-sdhi.c
> @@ -78,14 +78,7 @@ static const u8 r8a7795_calib_table[2][CALIB_TABLE_MAX] = {
>16, 16, 17, 17, 17, 17, 17, 18, 18, 18, 18, 19, 20, 21, 22, 22 }
> };
>
> -static const u8 r8a7796_rev1_calib_table[2][CALIB_TABLE_MAX] = {
> - { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 2, 3, 4, 9,
> - 15, 15, 15, 16, 16, 16, 16, 16, 17, 18, 19, 20, 21, 21, 22, 22 },
> - { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
> - 2, 9, 16, 17, 17, 17, 18, 18, 18, 18, 19, 20, 21, 22, 23, 24}
> -};
> -
> -static const u8 r8a7796_rev3_calib_table[2][CALIB_TABLE_MAX] = {
> +static const u8 r8a7796_rev13_calib_table[2][CALIB_TABLE_MAX] = {
> { 0, 0, 0, 0, 2, 3, 4, 4, 5, 6, 7, 7, 8, 9, 9, 10,
>11, 12, 13, 15, 16, 17, 17, 18, 19, 19, 20, 21, 21, 22, 23, 23 },
> { 1, 2, 2, 3, 4, 4, 5, 6, 6, 7, 8, 9, 9, 10, 11, 12,
> @@ -871,12 +864,16 @@ static void renesas_sdhi_filter_caps(struct udevice
> *dev)
> CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
> struct tmio_sd_plat *plat = dev_get_plat(dev);
>
> - /* HS400 is not supported on H3 ES1.x and M3W ES1.0, ES1.1 */
> + /* HS400 is not supported on H3 ES1.x, M3W ES1.[012], V3M, V3H ES1.x,
> D3 */
> if (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7795) &&
> (rmobile_get_cpu_rev_integer() <= 1)) ||
> ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
> (rmobile_get_cpu_rev_integer() == 1) &&
> - (rmobile_get_cpu_rev_fraction() < 2)))
> + (rmobile_get_cpu_rev_fraction() <= 2)) ||
> + (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A77970) ||
> + ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A77980) &&
> + (rmobile_get_cpu_rev_integer() <= 1)) ||
> + (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A77995))
> plat->cfg.host_caps &= ~MMC_MODE_HS400;
>
> /* H3 ES2.0, ES3.0 and M3W ES1.2 and M3N bad taps */
> @@ -897,16 +894,6 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
> r8a7795_calib_table[!rmobile_is_gen3_mmc0(priv)];
> }
>
> - /* M3W ES1.2 can use HS400 with manual adjustment */
> - if ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
> - (rmobile_get_cpu_rev_integer() == 1) &&
> - (rmobile_get_cpu_rev_fraction() == 2)) {
> - priv->adjust_hs400_enable = true;
> - priv->adjust_hs400_offset = 3;
> - priv->adjust_hs400_calib_table =
> - r8a7796_rev1_calib_table[!rmobile_is_gen3_mmc0(priv)];
> - }
> -
> /* M3W ES1.x for x>2 can use HS400 with manual adjustment and taps */
> if ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
> (rmobile_get_cpu_rev_integer() == 1) &&
> @@ -915,7 +902,7 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
> priv->adjust_hs400_offset = 0;
> priv->hs400_bad_tap = BIT(1) | BIT(3) | BIT(5) | BIT(7);
> priv->adjust_hs400_calib_table =
> - r8a7796_rev3_calib_table[!rmobile_is_gen3_mmc0(priv)];
> + r8a7796_rev13_calib_table[!rmobile_is_gen3_mmc0(priv)];
> }
>
> /* M3N can use HS400 with manual adjustment */
[GIT PULL] Please pull u-boot-pmic master
Dear Tom, Please pull u-boot-pmic master into u-boot master branch. If there is a problem, let me know, plz Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-pmic/-/pipelines/14954 The following changes since commit 30db474704405be823259851cbb76fa05366c8af: Prepare v2023.04-rc1 (2023-01-30 15:36:45 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-pmic.git master for you to fetch changes up to 519fa7aa252789677939f0bd991bf26a4fe469ec: power: act8846_pmic: fix number of registers (2023-01-31 22:05:03 +0900) John Keeping (1): power: act8846_pmic: fix number of registers include/power/act8846_pmic.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
RE: [0/4] Add eMMC 5.1 support for Versal NET
Hi, > -Original Message- > From: Michal Simek > Sent: Tuesday, January 31, 2023 10:08 PM > To: Jaehoon Chung ; 'Ashok Reddy Soma' > ; u- > b...@lists.denx.de > Cc: peng@nxp.com; kever.y...@rock-chips.com; > hayashi.kunih...@socionext.com; > alpernebiya...@gmail.com; xypron.g...@gmx.de; g...@amd.com > Subject: Re: [0/4] Add eMMC 5.1 support for Versal NET > > Hi Jaehoon, > > On 1/26/23 03:29, Jaehoon Chung wrote: > > Hi, > > > >> -Original Message- > >> From: Michal Simek > >> Sent: Tuesday, January 24, 2023 10:02 PM > >> To: Ashok Reddy Soma ; u-boot@lists.denx.de; > >> Jaehoon Chung > >> > >> Cc: peng@nxp.com; kever.y...@rock-chips.com; > >> hayashi.kunih...@socionext.com; > >> alpernebiya...@gmail.com; xypron.g...@gmx.de; g...@amd.com > >> Subject: Re: [0/4] Add eMMC 5.1 support for Versal NET > >> > >> Hi Jaehoon, > >> > >> On 1/10/23 12:31, Ashok Reddy Soma wrote: > >>> This patch series, > >>>- Add support for eMMC5.1 on Versal NET platform by adding new > >>> compatible > >>> string and PHY support. > >>>- Add support for input and output tap delays for eMMC > >>>- Add support for enabling HS400 in host capabilities by checking > >>> quirk. > >>>- Add quirk to support HS400 for Versal NET > >>> > >>> Ashok Reddy Soma (4): > >>> mmc: zynq_sdhci: Add support for eMMC5.1 for Versal NET platform > >>> mmc: sdhci: Check and call config_dll callback functions > >>> mmc: sdhci: Enable HS400 support if available in caps > >>> mmc: zynq_sdhci: Add support and quirk for HS400 > >>> > >>>drivers/mmc/sdhci.c | 20 +++ > >>>drivers/mmc/zynq_sdhci.c | 292 ++- > >>> include/sdhci.h | 5 + > >>>3 files changed, 314 insertions(+), 3 deletions(-) > >>> > >> > >> Can you please review this series? > > > > Sorry for too late. I will review them. > > I see you just reviewed it. Are you going to pick it up to your tree or do you > want me to queue it via my tree? Both ways work for me. I have picked this and I will do PR today. Best Regards, Jaehoon Chung > > Thanks, > Michal
Re: [PATCH v2] cmd: mmc: Expand bkops handling
On 1/5/23 23:19, Marek Vasut wrote:
> 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
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Cc: Jaehoon Chung
> Cc: Peng Fan
> ---
> V2: - Add kerneldoc comment to mmc_set_bkops_enable
> - Drop ifdef around mmc_set_bkops_enable in mmc.h
> ---
> cmd/mmc.c | 49 +++
> drivers/mmc/mmc.c | 14 +-
> include/mmc.h | 14 +++---
> 3 files changed, 61 insertions(+), 16 deletions(-)
>
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index c79d9407986..94deb9a1686 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -1020,16 +1020,12 @@ static int do_mmc_setdsr(struct cmd_tbl *cmdtp, int
> flag,
> }
>
> #ifdef CONFIG_CMD_BKOPS_ENABLE
> -static int do_mmc_bkops_enable(struct cmd_tbl *cmdtp, int flag,
> -int argc, char *const argv[])
> +static int mmc_bkops_common(char *device, bool autobkops, bool enable)
> {
> - int dev;
> struct mmc *mmc;
> + int dev;
>
> - if (argc != 2)
> - return CMD_RET_USAGE;
> -
> - dev = dectoul(argv[1], NULL);
> + dev = dectoul(device, NULL);
>
> mmc = init_mmc_device(dev, false);
> if (!mmc)
> @@ -1040,7 +1036,41 @@ static int do_mmc_bkops_enable(struct cmd_tbl *cmdtp,
> int flag,
> return CMD_RET_FAILURE;
> }
>
> - return mmc_set_bkops_enable(mmc);
> + return mmc_set_bkops_enable(mmc, autobkops, enable);
> +}
> +
> +static int do_mmc_bkops(struct cmd_tbl *cmdtp, int flag,
> + int argc, char * const argv[])
> +{
> + bool autobkops, enable;
> +
> + if (argc != 4)
> + return CMD_RET_USAGE;
> +
> + if (!strcmp(argv[2], "manual"))
> + autobkops = false;
> + else if (!strcmp(argv[2], "auto"))
> + autobkops = true;
> + else
> + return CMD_RET_FAILURE;
> +
> + if (!strcmp(argv[3], "disable"))
> + enable = false;
> + else if (!strcmp(argv[3], "enable"))
> + enable = true;
> + else
> + return CMD_RET_FAILURE;
> +
> + return mmc_bkops_common(argv[1], autobkops, enable);
> +}
> +
> +static int do_mmc_bkops_enable(struct cmd_tbl *cmdtp, int flag,
> +int argc, char * const argv[])
> +{
> + if (argc != 2)
> + return CMD_RET_USAGE;
> +
> + return mmc_bkops_common(argv[1], false, true);
> }
> #endif
>
> @@ -1102,6 +1132,7 @@ static struct cmd_tbl cmd_mmc[] = {
> U_BOOT_CMD_MKENT(setdsr, 2, 0, do_mmc_setdsr, "", ""),
> #ifdef CONFIG_CMD_BKOPS_ENABLE
> U_BOOT_CMD_MKENT(bkops-enable, 2, 0, do_mmc_bkops_enable, "", ""),
> + U_BOOT_CMD_MKENT(bkops, 4, 0, do_mmc_bkops, "", ""),
> #endif
> };
>
> @@ -1188,6 +1219,8 @@ U_BOOT_CMD(
> #ifdef CONFIG_CMD_BKOPS_ENABLE
> "mmc bkops-enable - enable background operations handshake on
> device\n"
> " WARNING: This is a write-once setting.\n"
> + "mmc bkops [auto|manual] [enable|disable]\n"
> + " - configure background operations handshake on device\n"
> #endif
> );
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 210703ea46b..afbc497b12c 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -3127,9 +3127,10 @@ int mmc_init_device(int num)
> #endif
>
> #ifdef CONFIG_CMD_BKOPS_ENABLE
> -int mmc_set_bkops_enable(struct mmc *mmc)
> +int mmc_set_bkops_enable(struct mmc *mmc, bool autobkops, bool enable)
> {
> int err;
> + u32 bit = autobkops ? BIT(1) : BIT(0);
> ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
>
> err = mmc_send_ext_csd(mmc, ext_csd);
> @@ -3143,18 +3144,21 @@ int mmc_set_bkops_enable(struct mmc *mmc)
> return -EMEDIUMTYPE;
> }
>
> - if (ext_csd[EXT_CSD_BKOPS_EN] & 0x1) {
> + if (enable && (ext_csd[EXT_CSD_BKOPS_EN] & bit)) {
> puts("Background operations already enabled\n");
> return 0;
> }
>
> - err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BKOPS_EN, 1);
> + err = mmc_switch(mmc, EX
Re: [PATCH 59/88] power: Drop unused muic_max8997 driver
On 1/24/23 07:00, Simon Glass wrote:
> This is not used. Drop the driver and Kconfig option.
>
> Signed-off-by: Simon Glass
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> drivers/power/pmic/Makefile | 1 -
> drivers/power/pmic/muic_max8997.c | 74 ---
> 2 files changed, 75 deletions(-)
> delete mode 100644 drivers/power/pmic/muic_max8997.c
>
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index c3180c58208..0b3b3d62d0e 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -37,7 +37,6 @@ obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
>
> ifeq ($(CONFIG_$(SPL_)POWER_LEGACY),y)
> obj-$(CONFIG_POWER_LTC3676) += pmic_ltc3676.o
> -obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
> obj-$(CONFIG_POWER_PCA9450) += pmic_pca9450.o
> obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
> obj-$(CONFIG_POWER_PFUZE3000) += pmic_pfuze3000.o
> diff --git a/drivers/power/pmic/muic_max8997.c
> b/drivers/power/pmic/muic_max8997.c
> deleted file mode 100644
> index 969ce902395..000
> --- a/drivers/power/pmic/muic_max8997.c
> +++ /dev/null
> @@ -1,74 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (C) 2012 Samsung Electronics
> - * Lukasz Majewski
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -static int power_chrg_get_type(struct pmic *p)
> -{
> - unsigned int val;
> - unsigned char charge_type, charger;
> -
> - if (pmic_probe(p))
> - return CHARGER_NO;
> -
> - pmic_reg_read(p, MAX8997_MUIC_STATUS2, );
> - charge_type = val & MAX8997_MUIC_CHG_MASK;
> -
> - switch (charge_type) {
> - case MAX8997_MUIC_CHG_NO:
> - charger = CHARGER_NO;
> - break;
> - case MAX8997_MUIC_CHG_USB:
> - case MAX8997_MUIC_CHG_USB_D:
> - charger = CHARGER_USB;
> - break;
> - case MAX8997_MUIC_CHG_TA:
> - case MAX8997_MUIC_CHG_TA_1A:
> - charger = CHARGER_TA;
> - break;
> - case MAX8997_MUIC_CHG_TA_500:
> - charger = CHARGER_TA_500;
> - break;
> - default:
> - charger = CHARGER_UNKNOWN;
> - break;
> - }
> -
> - return charger;
> -}
> -
> -static struct power_chrg power_chrg_muic_ops = {
> - .chrg_type = power_chrg_get_type,
> -};
> -
> -int power_muic_init(unsigned int bus)
> -{
> - static const char name[] = "MAX8997_MUIC";
> - struct pmic *p = pmic_alloc();
> -
> - if (!p) {
> - printf("%s: POWER allocation error!\n", __func__);
> - return -ENOMEM;
> - }
> -
> - debug("Board Micro USB Interface Controller init\n");
> -
> - p->name = name;
> - p->interface = PMIC_I2C;
> - p->number_of_regs = MUIC_NUM_OF_REGS;
> - p->hw.i2c.addr = MAX8997_MUIC_I2C_ADDR;
> - p->hw.i2c.tx_num = 1;
> - p->bus = bus;
> -
> - p->chrg = _chrg_muic_ops;
> - return 0;
> -}
Re: [PATCH 58/88] power: Drop unused muic_max77693 driver and mfd code
On 1/24/23 07:00, Simon Glass wrote:
> This driver is not used and has lain unconverted since:
>
>fc47cf9d054 arm: exynos: i2c: Convert exynos boards to use DM_I2C
>
> Drop it and the entire mfd directory, since there is nothing left.
>
> Signed-off-by: Simon Glass
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> drivers/power/Makefile| 1 -
> drivers/power/mfd/Makefile| 6 ---
> drivers/power/mfd/muic_max77693.c | 77 ---
> 3 files changed, 84 deletions(-)
> delete mode 100644 drivers/power/mfd/Makefile
> delete mode 100644 drivers/power/mfd/muic_max77693.c
>
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 93003e97e01..ba64b2c5938 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -5,7 +5,6 @@
>
> obj-$(CONFIG_$(SPL_TPL_)ACPI_PMC) += acpi_pmc/
> obj-$(CONFIG_$(SPL_TPL_)POWER_DOMAIN) += domain/
> -obj-y += mfd/
> obj-y += pmic/
> obj-y += regulator/
>
> diff --git a/drivers/power/mfd/Makefile b/drivers/power/mfd/Makefile
> deleted file mode 100644
> index b5ec8f00bb0..000
> --- a/drivers/power/mfd/Makefile
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0+
> -#
> -# Copyright (C) 2013 Samsung Electronics
> -# Piotr Wilczek
> -
> -obj-$(CONFIG_POWER_MUIC_MAX77693) += muic_max77693.o
> diff --git a/drivers/power/mfd/muic_max77693.c
> b/drivers/power/mfd/muic_max77693.c
> deleted file mode 100644
> index 36ee44b9a2c..000
> --- a/drivers/power/mfd/muic_max77693.c
> +++ /dev/null
> @@ -1,77 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (C) 2013 Samsung Electronics
> - * Piotr Wilczek
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -static int power_chrg_get_type(struct pmic *p)
> -{
> - unsigned int val;
> - unsigned int charge_type, charger;
> -
> - /* if probe failed, return cable none */
> - if (pmic_probe(p))
> - return CHARGER_NO;
> -
> - pmic_reg_read(p, MAX77693_MUIC_STATUS2, );
> -
> - charge_type = val & MAX77693_MUIC_CHG_MASK;
> -
> - switch (charge_type) {
> - case MAX77693_MUIC_CHG_NO:
> - charger = CHARGER_NO;
> - break;
> - case MAX77693_MUIC_CHG_USB:
> - case MAX77693_MUIC_CHG_USB_D:
> - charger = CHARGER_USB;
> - break;
> - case MAX77693_MUIC_CHG_TA:
> - case MAX77693_MUIC_CHG_TA_1A:
> - charger = CHARGER_TA;
> - break;
> - case MAX77693_MUIC_CHG_TA_500:
> - charger = CHARGER_TA_500;
> - break;
> - default:
> - charger = CHARGER_UNKNOWN;
> - break;
> - }
> -
> - return charger;
> -}
> -
> -static struct power_chrg power_chrg_muic_ops = {
> - .chrg_type = power_chrg_get_type,
> -};
> -
> -int power_muic_init(unsigned int bus)
> -{
> - static const char name[] = "MAX77693_MUIC";
> - struct pmic *p = pmic_alloc();
> -
> - if (!p) {
> - printf("%s: POWER allocation error!\n", __func__);
> - return -ENOMEM;
> - }
> -
> - debug("Board Micro USB Interface Controller init\n");
> -
> - p->name = name;
> - p->interface = PMIC_I2C;
> - p->number_of_regs = MUIC_NUM_OF_REGS;
> - p->hw.i2c.addr = MAX77693_MUIC_I2C_ADDR;
> - p->hw.i2c.tx_num = 1;
> - p->bus = bus;
> -
> - p->chrg = _chrg_muic_ops;
> -
> - return 0;
> -}
Re: [PATCH 57/88] power: Drop unused fg_max17042 driver and fuel gauge code
On 1/24/23 07:00, Simon Glass wrote:
> This driver is not used. Drop it and the entire fuel_gauge directory,
> since there is nothing left.
>
> Signed-off-by: Simon Glass
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> drivers/power/Makefile | 1 -
> drivers/power/fuel_gauge/Makefile | 6 -
> drivers/power/fuel_gauge/fg_max17042.c | 287 -
> include/power/fg_battery_cell_params.h | 73 ---
> 4 files changed, 367 deletions(-)
> delete mode 100644 drivers/power/fuel_gauge/Makefile
> delete mode 100644 drivers/power/fuel_gauge/fg_max17042.c
> delete mode 100644 include/power/fg_battery_cell_params.h
>
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index efdae3655ac..93003e97e01 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -5,7 +5,6 @@
>
> obj-$(CONFIG_$(SPL_TPL_)ACPI_PMC) += acpi_pmc/
> obj-$(CONFIG_$(SPL_TPL_)POWER_DOMAIN) += domain/
> -obj-y += fuel_gauge/
> obj-y += mfd/
> obj-y += pmic/
> obj-y += regulator/
> diff --git a/drivers/power/fuel_gauge/Makefile
> b/drivers/power/fuel_gauge/Makefile
> deleted file mode 100644
> index ca2df947585..000
> --- a/drivers/power/fuel_gauge/Makefile
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0+
> -#
> -# Copyright (C) 2012 Samsung Electronics
> -# Lukasz Majewski
> -
> -obj-$(CONFIG_POWER_FG_MAX17042) += fg_max17042.o
> diff --git a/drivers/power/fuel_gauge/fg_max17042.c
> b/drivers/power/fuel_gauge/fg_max17042.c
> deleted file mode 100644
> index a395d587a86..000
> --- a/drivers/power/fuel_gauge/fg_max17042.c
> +++ /dev/null
> @@ -1,287 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (C) 2012 Samsung Electronics
> - * Lukasz Majewski
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -static int fg_write_regs(struct pmic *p, u8 addr, u16 *data, int num)
> -{
> - int ret = 0;
> - int i;
> -
> - for (i = 0; i < num; i++, addr++) {
> - ret = pmic_reg_write(p, addr, *(data + i));
> - if (ret)
> - return ret;
> - }
> -
> - return 0;
> -}
> -
> -static int fg_read_regs(struct pmic *p, u8 addr, u16 *data, int num)
> -{
> - unsigned int dat;
> - int ret = 0;
> - int i;
> -
> - for (i = 0; i < num; i++, addr++) {
> - ret = pmic_reg_read(p, addr, );
> - if (ret)
> - return ret;
> -
> - *(data + i) = (u16)dat;
> - }
> -
> - return 0;
> -}
> -
> -static int fg_write_and_verify(struct pmic *p, u8 addr, u16 data)
> -{
> - unsigned int val = data;
> - int ret = 0;
> -
> - ret |= pmic_reg_write(p, addr, val);
> - ret |= pmic_reg_read(p, addr, );
> -
> - if (ret)
> - return ret;
> -
> - if (((u16) val) == data)
> - return 0;
> -
> - return -1;
> -}
> -
> -static void por_fuelgauge_init(struct pmic *p)
> -{
> - u16 r_data0[16], r_data1[16], r_data2[16];
> - u32 rewrite_count = 5;
> - u32 check_count;
> - u32 lock_count;
> - u32 i = 0;
> - u32 val;
> - s32 ret = 0;
> - char *status_msg;
> -
> - /* Delay 500 ms */
> - mdelay(500);
> - /* Initilize Configuration */
> - pmic_reg_write(p, MAX17042_CONFIG, 0x2310);
> -
> -rewrite_model:
> - check_count = 5;
> - lock_count = 5;
> -
> - if (!rewrite_count--) {
> - status_msg = "init failed!";
> - goto error;
> - }
> -
> - /* Unlock Model Access */
> - pmic_reg_write(p, MAX17042_MLOCKReg1, MODEL_UNLOCK1);
> - pmic_reg_write(p, MAX17042_MLOCKReg2, MODEL_UNLOCK2);
> -
> - /* Write/Read/Verify the Custom Model */
> - ret = fg_write_regs(p, MAX17042_MODEL1, cell_character0,
> - ARRAY_SIZE(cell_character0));
> - if (ret)
> - goto rewrite_model;
> -
> - ret = fg_write_regs(p, MAX17042_MODEL2, cell_character1,
> - ARRAY_SIZE(cell_character1));
> - if (ret)
> - goto rewrite_model;
> -
> - ret = fg_write_regs(p, MAX17042_MODEL3, cell_character2,
> - ARRAY_SIZE(cell_character2));
> - if (ret)
> - goto rewrite_model;
> -
> -check_model:
> - if (!check_count--) {
> - if (rewrite_count)
> -
Re: [PATCH 56/88] power: Drop unused bat_trats driver and battery code
On 1/24/23 06:59, Simon Glass wrote:
> This driver and bat_trats2 are not used. Drop them and the entire battery
> directory, since there is nothing left.
>
> Signed-off-by: Simon Glass
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> drivers/power/Makefile | 1 -
> drivers/power/battery/Makefile | 7 ---
> drivers/power/battery/bat_trats.c | 91 --
> drivers/power/battery/bat_trats2.c | 65 -
> 4 files changed, 164 deletions(-)
> delete mode 100644 drivers/power/battery/Makefile
> delete mode 100644 drivers/power/battery/bat_trats.c
> delete mode 100644 drivers/power/battery/bat_trats2.c
>
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 34a84808a9c..efdae3655ac 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -4,7 +4,6 @@
> # Tom Rix
>
> obj-$(CONFIG_$(SPL_TPL_)ACPI_PMC) += acpi_pmc/
> -obj-y += battery/
> obj-$(CONFIG_$(SPL_TPL_)POWER_DOMAIN) += domain/
> obj-y += fuel_gauge/
> obj-y += mfd/
> diff --git a/drivers/power/battery/Makefile b/drivers/power/battery/Makefile
> deleted file mode 100644
> index 370923a6ed9..000
> --- a/drivers/power/battery/Makefile
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0+
> -#
> -# Copyright (C) 2012 Samsung Electronics
> -# Lukasz Majewski
> -
> -obj-$(CONFIG_POWER_BATTERY_TRATS) += bat_trats.o
> -obj-$(CONFIG_POWER_BATTERY_TRATS2) += bat_trats2.o
> diff --git a/drivers/power/battery/bat_trats.c
> b/drivers/power/battery/bat_trats.c
> deleted file mode 100644
> index 54b2bf91e5c..000
> --- a/drivers/power/battery/bat_trats.c
> +++ /dev/null
> @@ -1,91 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (C) 2012 Samsung Electronics
> - * Lukasz Majewski
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -static struct battery battery_trats;
> -
> -static int power_battery_charge(struct pmic *bat)
> -{
> - struct power_battery *p_bat = bat->pbat;
> - struct battery *battery = p_bat->bat;
> - int k;
> -
> - if (bat->chrg->chrg_state(p_bat->chrg, PMIC_CHARGER_ENABLE, 450))
> - return -1;
> -
> - for (k = 0; bat->chrg->chrg_bat_present(p_bat->chrg) &&
> - bat->chrg->chrg_type(p_bat->muic) &&
> - battery->state_of_chrg < 100; k++) {
> - udelay(200);
> - if (!(k % 5))
> - puts(".");
> - bat->fg->fg_battery_update(p_bat->fg, bat);
> -
> - if (k == 200) {
> - debug(" %d [V]", battery->voltage_uV);
> - puts("\n");
> - k = 0;
> - }
> -
> - if (ctrlc()) {
> - printf("\nCharging disabled on request.\n");
> - goto exit;
> - }
> - }
> - exit:
> - bat->chrg->chrg_state(p_bat->chrg, PMIC_CHARGER_DISABLE, 0);
> -
> - return 0;
> -}
> -
> -static int power_battery_init_trats(struct pmic *bat_,
> - struct pmic *fg_,
> - struct pmic *chrg_,
> - struct pmic *muic_)
> -{
> - bat_->pbat->fg = fg_;
> - bat_->pbat->chrg = chrg_;
> - bat_->pbat->muic = muic_;
> -
> - bat_->fg = fg_->fg;
> - bat_->chrg = chrg_->chrg;
> - bat_->chrg->chrg_type = muic_->chrg->chrg_type;
> - return 0;
> -}
> -
> -static struct power_battery power_bat_trats = {
> - .bat = _trats,
> - .battery_init = power_battery_init_trats,
> - .battery_charge = power_battery_charge,
> -};
> -
> -int power_bat_init(unsigned char bus)
> -{
> - static const char name[] = "BAT_TRATS";
> - struct pmic *p = pmic_alloc();
> -
> - if (!p) {
> - printf("%s: POWER allocation error!\n", __func__);
> - return -ENOMEM;
> - }
> -
> - debug("Board BAT init\n");
> -
> - p->interface = PMIC_NONE;
> - p->name = name;
> - p->bus = bus;
> -
> - p->pbat = _bat_trats;
> - return 0;
> -}
> diff --git a/drivers/power/battery/bat_trats2.c
> b/drivers/power/battery/bat_trats2.c
> deleted file mode 100644
> index 1172970d1e0..000
> ---
Re: [PATCH 03/88] power: Drop fg_max77693
On 1/24/23 06:59, Simon Glass wrote:
> This is not used in U-Boot. Drop it.
>
> Signed-off-by: Simon Glass
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> drivers/power/mfd/Makefile | 1 -
> drivers/power/mfd/fg_max77693.c | 137
> 2 files changed, 138 deletions(-)
> delete mode 100644 drivers/power/mfd/fg_max77693.c
>
> diff --git a/drivers/power/mfd/Makefile b/drivers/power/mfd/Makefile
> index a8eb7f81e72..5dfbdbd1b0f 100644
> --- a/drivers/power/mfd/Makefile
> +++ b/drivers/power/mfd/Makefile
> @@ -5,4 +5,3 @@
>
> obj-$(CONFIG_POWER_PMIC_MAX77693) += pmic_max77693.o
> obj-$(CONFIG_POWER_MUIC_MAX77693) += muic_max77693.o
> -obj-$(CONFIG_POWER_FG_MAX77693) += fg_max77693.o
> diff --git a/drivers/power/mfd/fg_max77693.c b/drivers/power/mfd/fg_max77693.c
> deleted file mode 100644
> index 983a6d4a2bd..000
> --- a/drivers/power/mfd/fg_max77693.c
> +++ /dev/null
> @@ -1,137 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (C) 2013 Samsung Electronics
> - * Piotr Wilczek
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -static int max77693_get_vcell(u32 *vcell)
> -{
> - u16 value;
> - u8 ret;
> -
> - ret = i2c_read(MAX77693_FUEL_I2C_ADDR, MAX77693_VCELL, 1,
> -(u8 *), 2);
> - if (ret)
> - return ret;
> -
> - *vcell = (u32)(value >> 3);
> - *vcell = *vcell * 625;
> -
> - return 0;
> -}
> -
> -static int max77693_get_soc(u32 *soc)
> -{
> - u16 value;
> - u8 ret;
> -
> - ret = i2c_read(MAX77693_FUEL_I2C_ADDR, MAX77693_VFSOC, 1,
> -(u8 *), 2);
> - if (ret)
> - return ret;
> -
> - *soc = (u32)(value >> 8);
> -
> - return 0;
> -}
> -
> -static int power_update_battery(struct pmic *p, struct pmic *bat)
> -{
> - struct power_battery *pb = bat->pbat;
> - int ret;
> -
> - if (pmic_probe(p)) {
> - puts("Can't find max77693 fuel gauge\n");
> - return -ENODEV;
> - }
> -
> - ret = max77693_get_soc(>bat->state_of_chrg);
> - if (ret)
> - return ret;
> -
> - max77693_get_vcell(>bat->voltage_uV);
> -
> - return 0;
> -}
> -
> -static int power_check_battery(struct pmic *p, struct pmic *bat)
> -{
> - struct power_battery *pb = bat->pbat;
> - unsigned int val;
> - int ret = 0;
> -
> - if (pmic_probe(p)) {
> - puts("Can't find max77693 fuel gauge\n");
> - return -ENODEV;
> - }
> -
> - ret = pmic_reg_read(p, MAX77693_STATUS, );
> - if (ret)
> - return ret;
> - debug("fg status: 0x%x\n", val);
> -
> - ret = pmic_reg_read(p, MAX77693_VERSION, >bat->version);
> - if (ret)
> - return ret;
> -
> - ret = power_update_battery(p, bat);
> - if (ret)
> - return ret;
> - debug("fg ver: 0x%x\n", pb->bat->version);
> - printf("BAT: state_of_charge(SOC):%d%%\n",
> -pb->bat->state_of_chrg);
> -
> - printf(" voltage: %d.%6.6d [V] (expected to be %d [mAh])\n",
> -pb->bat->voltage_uV / 100,
> -pb->bat->voltage_uV % 100,
> -pb->bat->capacity);
> -
> - if (pb->bat->voltage_uV > 385)
> - pb->bat->state = EXT_SOURCE;
> - else if (pb->bat->voltage_uV < 360 || pb->bat->state_of_chrg < 5)
> - pb->bat->state = CHARGE;
> - else
> - pb->bat->state = NORMAL;
> -
> - return 0;
> -}
> -
> -static struct power_fg power_fg_ops = {
> - .fg_battery_check = power_check_battery,
> - .fg_battery_update = power_update_battery,
> -};
> -
> -int power_fg_init(unsigned char bus)
> -{
> - static const char name[] = "MAX77693_FG";
> - struct pmic *p = pmic_alloc();
> -
> - if (!p) {
> - printf("%s: POWER allocation error!\n", __func__);
> - return -ENOMEM;
> - }
> -
> - debug("Board Fuel Gauge init\n");
> -
> - p->name = name;
> - p->interface = PMIC_I2C;
> - p->number_of_regs = FG_NUM_OF_REGS;
> - p->hw.i2c.addr = MAX77693_FUEL_I2C_ADDR;
> - p->hw.i2c.tx_num = 2;
> - p->sensor_byte_order = PMIC_SENSOR_BYTE_ORDER_BIG;
> - p->bus = bus;
> -
> - p->fg = _fg_ops;
> -
> - return 0;
> -}
Re: [PATCH 05/88] power: Drop pmic_max77693.c
On 1/24/23 06:59, Simon Glass wrote:
> Drop this driver and the associated CONFIG option, as it is not used.
>
> Signed-off-by: Simon Glass
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> drivers/power/mfd/Makefile| 1 -
> drivers/power/mfd/pmic_max77693.c | 96 ---
> 2 files changed, 97 deletions(-)
> delete mode 100644 drivers/power/mfd/pmic_max77693.c
>
> diff --git a/drivers/power/mfd/Makefile b/drivers/power/mfd/Makefile
> index 5dfbdbd1b0f..b5ec8f00bb0 100644
> --- a/drivers/power/mfd/Makefile
> +++ b/drivers/power/mfd/Makefile
> @@ -3,5 +3,4 @@
> # Copyright (C) 2013 Samsung Electronics
> # Piotr Wilczek
>
> -obj-$(CONFIG_POWER_PMIC_MAX77693) += pmic_max77693.o
> obj-$(CONFIG_POWER_MUIC_MAX77693) += muic_max77693.o
> diff --git a/drivers/power/mfd/pmic_max77693.c
> b/drivers/power/mfd/pmic_max77693.c
> deleted file mode 100644
> index e32a9722a40..000
> --- a/drivers/power/mfd/pmic_max77693.c
> +++ /dev/null
> @@ -1,96 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (C) 2013 Samsung Electronics
> - * Piotr Wilczek
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -static int max77693_charger_state(struct pmic *p, int state, int current)
> -{
> - unsigned int val;
> -
> - if (pmic_probe(p))
> - return -ENODEV;
> -
> - /* unlock write capability */
> - val = MAX77693_CHG_UNLOCK;
> - pmic_reg_write(p, MAX77693_CHG_CNFG_06, val);
> -
> - if (state == PMIC_CHARGER_DISABLE) {
> - puts("Disable the charger.\n");
> - pmic_reg_read(p, MAX77693_CHG_CNFG_00, );
> - val &= ~0x01;
> - pmic_reg_write(p, MAX77693_CHG_CNFG_00, val);
> - return -ENOTSUPP;
> - }
> -
> - if (current < CHARGER_MIN_CURRENT || current > CHARGER_MAX_CURRENT) {
> - printf("%s: Wrong charge current: %d [mA]\n",
> -__func__, current);
> - return -EINVAL;
> - }
> -
> - /* set charging current */
> - pmic_reg_read(p, MAX77693_CHG_CNFG_02, );
> - val &= ~MAX77693_CHG_CC;
> - val |= current * 10 / 333; /* 0.1A/3 steps */
> - pmic_reg_write(p, MAX77693_CHG_CNFG_02, val);
> -
> - /* enable charging */
> - val = MAX77693_CHG_MODE_ON;
> - pmic_reg_write(p, MAX77693_CHG_CNFG_00, val);
> -
> - /* check charging current */
> - pmic_reg_read(p, MAX77693_CHG_CNFG_02, );
> - val &= 0x3f;
> - printf("Enable the charger @ %d [mA]\n", val * 333 / 10);
> -
> - return 0;
> -}
> -
> -static int max77693_charger_bat_present(struct pmic *p)
> -{
> - unsigned int val;
> -
> - if (pmic_probe(p))
> - return -ENODEV;
> -
> - pmic_reg_read(p, MAX77693_CHG_INT_OK, );
> -
> - return !(val & MAX77693_CHG_DETBAT);
> -}
> -
> -static struct power_chrg power_chrg_pmic_ops = {
> - .chrg_bat_present = max77693_charger_bat_present,
> - .chrg_state = max77693_charger_state,
> -};
> -
> -int pmic_init_max77693(unsigned char bus)
> -{
> - static const char name[] = "MAX77693_PMIC";
> - struct pmic *p = pmic_alloc();
> -
> - if (!p) {
> - printf("%s: POWER allocation error!\n", __func__);
> - return -ENOMEM;
> - }
> -
> - debug("Board PMIC init\n");
> -
> - p->name = name;
> - p->interface = PMIC_I2C;
> - p->number_of_regs = PMIC_NUM_OF_REGS;
> - p->hw.i2c.addr = MAX77693_PMIC_I2C_ADDR;
> - p->hw.i2c.tx_num = 1;
> - p->bus = bus;
> -
> - p->chrg = _chrg_pmic_ops;
> -
> - return 0;
> -}
Re: [PATCH] power: act8846_pmic: fix number of registers
On 1/19/23 21:56, John Keeping wrote: > The highest register on ACT8846 is 0xf5, so set the number of registers > to 0xf6, ensuring that the pmic read/write commands are able to access > all of the supported registers (and many that are not valid, since the > register space is quite sparse). > > Signed-off-by: John Keeping Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > include/power/act8846_pmic.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/power/act8846_pmic.h b/include/power/act8846_pmic.h > index acd0fd671e..84845c70f9 100644 > --- a/include/power/act8846_pmic.h > +++ b/include/power/act8846_pmic.h > @@ -9,7 +9,7 @@ > > #include > > -#define ACT8846_NUM_OF_REGS 12 > +#define ACT8846_NUM_OF_REGS 0xf6 > > #define BUCK_VOL_MASK 0x3f > #define LDO_VOL_MASK 0x3f
Re: [PATCH] mmc: rockchip_dw_mmc: fix DDR52 8-bit mode handling
Hi,
On 1/18/23 02:07, John Keeping wrote:
> The RK3288 TRM states that, for 8-bit DDR modes:
>
> The CLKDIV register should always be programmed with a value
> higher than zero (0); that is, a clock divider should always be
> used for 8-bit DDR mode.
>
> In Linux, the driver applies this logic for all SoCs using the driver
> and does not distinguish RK3288, so presumably this requirement is the
> same for all other Rockchip SoCs using this IP.
>
> Add the necessary code to double the clock frequency when 8-bit DDR is
> selected. The dw_mmc core already handles setting CLKDIV correctly
> given the input clock and desired bus clock.
>
> Signed-off-by: John Keeping
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/rockchip_dw_mmc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c
> index 573bf16c87..3661ce3314 100644
> --- a/drivers/mmc/rockchip_dw_mmc.c
> +++ b/drivers/mmc/rockchip_dw_mmc.c
> @@ -41,6 +41,14 @@ static uint rockchip_dwmmc_get_mmc_clk(struct dwmci_host
> *host, uint freq)
> struct rockchip_dwmmc_priv *priv = dev_get_priv(dev);
> int ret;
>
> + /*
> + * The clock frequency chosen here affects CLKDIV in the dw_mmc core.
> + * That can be either 0 or 1, but it must be set to 1 for eMMC DDR52
> + * 8-bit mode. It will be set to 0 for all other modes.
> + */
> + if (host->mmc->selected_mode == MMC_DDR_52 && host->mmc->bus_width == 8)
> + freq *= 2;
> +
> ret = clk_set_rate(>clk, freq);
> if (ret < 0) {
> debug("%s: err=%d\n", __func__, ret);
Re: [3/4] mmc: sdhci: Enable HS400 support if available in caps
On 1/10/23 20:31, Ashok Reddy Soma wrote: > HS400 is indicated in bit63 of capability register in few IP's. > Add a quirk to check this and add HS400 to host capabilities. > > Signed-off-by: Ashok Reddy Soma Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > drivers/mmc/sdhci.c | 4 > include/sdhci.h | 3 +++ > 2 files changed, 7 insertions(+) > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c > index 181ab9b7cb..c6b250b9a1 100644 > --- a/drivers/mmc/sdhci.c > +++ b/drivers/mmc/sdhci.c > @@ -995,6 +995,10 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct > sdhci_host *host, > cfg->host_caps |= MMC_CAP(UHS_SDR50); > } > > + if ((host->quirks & SDHCI_QUIRK_CAPS_BIT63_FOR_HS400) && > + (caps_1 & SDHCI_SUPPORT_HS400)) > + cfg->host_caps |= MMC_CAP(MMC_HS_400); > + > if (caps_1 & SDHCI_SUPPORT_DDR50) > cfg->host_caps |= MMC_CAP(UHS_DDR50); > > diff --git a/include/sdhci.h b/include/sdhci.h > index 64a3d309da..70fefca2a9 100644 > --- a/include/sdhci.h > +++ b/include/sdhci.h > @@ -189,6 +189,7 @@ > #define SDHCI_SUPPORT_SDR50 0x0001 > #define SDHCI_SUPPORT_SDR1040x0002 > #define SDHCI_SUPPORT_DDR50 0x0004 > +#define SDHCI_SUPPORT_HS400 BIT(31) > #define SDHCI_USE_SDR50_TUNING 0x2000 > > #define SDHCI_CLOCK_MUL_MASK0x00FF > @@ -248,6 +249,8 @@ > #define SDHCI_QUIRK_USE_WIDE8(1 << 8) > #define SDHCI_QUIRK_NO_1_8_V (1 << 9) > #define SDHCI_QUIRK_SUPPORT_SINGLE (1 << 10) > +/* Capability register bit-63 indicates HS400 support */ > +#define SDHCI_QUIRK_CAPS_BIT63_FOR_HS400 BIT(11) > > /* to make gcc happy */ > struct sdhci_host;
Re: [4/4] mmc: zynq_sdhci: Add support and quirk for HS400
On 1/10/23 20:31, Ashok Reddy Soma wrote:
> Add support for HS400 in mode2timing array.
> Add a quirk for Versal NET platform to indicate that HS400 is supported
> through bit63 of capability register.
>
> Signed-off-by: Ashok Reddy Soma
Reviewd-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/zynq_sdhci.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
> index 8415da3373..72de6c6227 100644
> --- a/drivers/mmc/zynq_sdhci.c
> +++ b/drivers/mmc/zynq_sdhci.c
> @@ -153,6 +153,7 @@ static const u8 mode2timing[] = {
> [UHS_DDR50] = MMC_TIMING_UHS_DDR50,
> [UHS_SDR104] = MMC_TIMING_UHS_SDR104,
> [MMC_HS_200] = MMC_TIMING_MMC_HS200,
> + [MMC_HS_400] = MMC_TIMING_MMC_HS400,
> };
>
> #if defined(CONFIG_ARCH_VERSAL_NET)
> @@ -1133,6 +1134,10 @@ static int arasan_sdhci_probe(struct udevice *dev)
> if (priv->no_1p8)
> host->quirks |= SDHCI_QUIRK_NO_1_8_V;
>
> + if (CONFIG_IS_ENABLED(ARCH_VERSAL_NET) &&
> + device_is_compatible(dev, "xlnx,versal-net-5.1-emmc"))
> + host->quirks |= SDHCI_QUIRK_CAPS_BIT63_FOR_HS400;
> +
> plat->cfg.f_max = CONFIG_ZYNQ_SDHCI_MAX_FREQ;
>
> ret = mmc_of_parse(dev, >cfg);
Re: [2/4] mmc: sdhci: Check and call config_dll callback functions
On 1/10/23 20:31, Ashok Reddy Soma wrote:
> Check if the low level driver supports config_dll callback function and
> call it if it does. Call with dll disable before calling set_clock and
> with dll enable after it.
>
> Signed-off-by: Ashok Reddy Soma
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/sdhci.c | 16
> include/sdhci.h | 2 ++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index a80ad8329a..181ab9b7cb 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -396,6 +396,14 @@ int sdhci_set_clock(struct mmc *mmc, unsigned int clock)
> }
> }
>
> + if (host->ops && host->ops->config_dll) {
> + ret = host->ops->config_dll(host, clock, false);
> + if (ret) {
> + printf("%s: Error while configuring dll\n", __func__);
> + return ret;
> + }
> + }
> +
> if (SDHCI_GET_VERSION(host) >= SDHCI_SPEC_300) {
> /*
>* Check if the Host Controller supports Programmable Clock
> @@ -439,6 +447,14 @@ int sdhci_set_clock(struct mmc *mmc, unsigned int clock)
> if (host->ops && host->ops->set_clock)
> host->ops->set_clock(host, div);
>
> + if (host->ops && host->ops->config_dll) {
> + ret = host->ops->config_dll(host, clock, true);
> + if (ret) {
> + printf("%s: Error while configuring dll\n", __func__);
> + return ret;
> + }
> + }
> +
> clk |= (div & SDHCI_DIV_MASK) << SDHCI_DIVIDER_SHIFT;
> clk |= ((div & SDHCI_DIV_HI_MASK) >> SDHCI_DIV_MASK_LEN)
> << SDHCI_DIVIDER_HI_SHIFT;
> diff --git a/include/sdhci.h b/include/sdhci.h
> index 24b4599b85..64a3d309da 100644
> --- a/include/sdhci.h
> +++ b/include/sdhci.h
> @@ -272,6 +272,8 @@ struct sdhci_ops {
> void(*set_clock)(struct sdhci_host *host, u32 div);
> int (*platform_execute_tuning)(struct mmc *host, u8 opcode);
> int (*set_delay)(struct sdhci_host *host);
> + /* Callback function to set DLL clock configuration */
> + int (*config_dll)(struct sdhci_host *host, u32 clock, bool enable);>
> int (*deferred_probe)(struct sdhci_host *host);
>
> /**
Re: [1/4] mmc: zynq_sdhci: Add support for eMMC5.1 for Versal NET platform
On 1/10/23 20:31, Ashok Reddy Soma wrote:
> Add support for eMMC 5.1 for Versal NET platform
> - Add new compatible string(xlnx,versal-net-5.1-emmc).
> - Add CONFIG_ARCH_VERSAL_NET condition wherever required.
> - Add DLL and Delay Chain mode support
> - Add input and output tap delays for eMMC.
> - Add Strobe select tap for HS400 mode.
>
> Signed-off-by: Ashok Reddy Soma
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/zynq_sdhci.c | 287 ++-
> 1 file changed, 284 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
> index 7dcf6ad842..8415da3373 100644
> --- a/drivers/mmc/zynq_sdhci.c
> +++ b/drivers/mmc/zynq_sdhci.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * (C) Copyright 2013 - 2015 Xilinx, Inc.
> + * (C) Copyright 2013 - 2022, Xilinx, Inc.
> + * (C) Copyright 2022, Advanced Micro Devices, Inc.
> *
> * Xilinx Zynq SD Host Controller Interface
> */
> @@ -16,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -48,6 +50,41 @@
> #define SD0_OTAPDLYSEL_MASK GENMASK(5, 0)
> #define SD1_OTAPDLYSEL_MASK GENMASK(21, 16)
>
> +#define MIN_PHY_CLK_HZ 5000
> +
> +#define PHY_CTRL_REG10x270
> +#define PHY_CTRL_ITAPDLY_ENA_MASKBIT(0)
> +#define PHY_CTRL_ITAPDLY_SEL_MASKGENMASK(5, 1)
> +#define PHY_CTRL_ITAPDLY_SEL_SHIFT 1
> +#define PHY_CTRL_ITAP_CHG_WIN_MASK BIT(6)
> +#define PHY_CTRL_OTAPDLY_ENA_MASKBIT(8)
> +#define PHY_CTRL_OTAPDLY_SEL_MASKGENMASK(15, 12)
> +#define PHY_CTRL_OTAPDLY_SEL_SHIFT 12
> +#define PHY_CTRL_STRB_SEL_MASK GENMASK(23, 16)
> +#define PHY_CTRL_STRB_SEL_SHIFT 16
> +#define PHY_CTRL_TEST_CTRL_MASK GENMASK(31, 24)
> +
> +#define PHY_CTRL_REG20x274
> +#define PHY_CTRL_EN_DLL_MASK BIT(0)
> +#define PHY_CTRL_DLL_RDY_MASKBIT(1)
> +#define PHY_CTRL_FREQ_SEL_MASK GENMASK(6, 4)
> +#define PHY_CTRL_FREQ_SEL_SHIFT 4
> +#define PHY_CTRL_SEL_DLY_TX_MASK BIT(16)
> +#define PHY_CTRL_SEL_DLY_RX_MASK BIT(17)
> +#define FREQSEL_200M_170M0x0
> +#define FREQSEL_170M_140M0x1
> +#define FREQSEL_140M_110M0x2
> +#define FREQSEL_110M_80M 0x3
> +#define FREQSEL_80M_50M 0x4
> +#define FREQSEL_275M_250M0x5
> +#define FREQSEL_250M_225M0x6
> +#define FREQSEL_225M_200M0x7
> +#define PHY_DLL_TIMEOUT_MS 100
> +
> +#define VERSAL_NET_EMMC_ICLK_PHASE_DDR52_DLY_CHAIN 39
> +#define VERSAL_NET_EMMC_ICLK_PHASE_DDR52_DLL 146
> +#define VERSAL_NET_PHY_CTRL_STRB90_STRB180_VAL 0X77
> +
> struct arasan_sdhci_clk_data {
> int clk_phase_in[MMC_TIMING_MMC_HS400 + 1];
> int clk_phase_out[MMC_TIMING_MMC_HS400 + 1];
> @@ -64,6 +101,7 @@ struct arasan_sdhci_priv {
> u32 node_id;
> u8 bank;
> u8 no_1p8;
> + bool internal_phy_reg;
> struct reset_ctl_bulk resets;
> };
>
> @@ -84,7 +122,7 @@ __weak int zynqmp_pm_is_function_supported(const u32
> api_id, const u32 id)
> return 1;
> }
>
> -#if defined(CONFIG_ARCH_ZYNQMP) || defined(CONFIG_ARCH_VERSAL)
> +#if defined(CONFIG_ARCH_ZYNQMP) || defined(CONFIG_ARCH_VERSAL) ||
> defined(CONFIG_ARCH_VERSAL_NET)
> /* Default settings for ZynqMP Clock Phases */
> static const u32 zynqmp_iclk_phases[] = {0, 63, 63, 0, 63, 0,
>0, 183, 54, 0, 0};
> @@ -97,6 +135,12 @@ static const u32 versal_iclk_phases[] = {0, 132, 132, 0,
> 132,
> static const u32 versal_oclk_phases[] = {0, 60, 48, 0, 48, 72,
>90, 36, 60, 90, 0};
>
> +/* Default settings for versal-net eMMC Clock Phases */
> +static const u32 versal_net_emmc_iclk_phases[] = {0, 0, 0, 0, 0, 0, 0, 0, 39,
> + 0, 0};
> +static const u32 versal_net_emmc_oclk_phases[] = {0, 113, 0, 0, 0, 0, 0, 0,
> + 113, 79, 45};
> +
> static const u8 mode2timing[] = {
> [MMC_LEGACY] = MMC_TIMING_LEGACY,
> [MMC_HS] = MMC_TIMING_MMC_HS,
> @@ -111,6 +155,121 @@ static const u8 mode2timing[] = {
> [MMC_HS_200] = MMC_TIMING_MMC_HS200,
> };
>
> +#if defined(CONFIG_ARCH_VERSAL_NET)
> +/**
> + * arasan_phy_set_delaychain - Set eMMC delay chain based Input/Output clock
> + *
> + * @host:Pointer to the sdhci_host stru
RE: [0/4] Add eMMC 5.1 support for Versal NET
Hi, > -Original Message- > From: Michal Simek > Sent: Tuesday, January 24, 2023 10:02 PM > To: Ashok Reddy Soma ; u-boot@lists.denx.de; > Jaehoon Chung > > Cc: peng@nxp.com; kever.y...@rock-chips.com; > hayashi.kunih...@socionext.com; > alpernebiya...@gmail.com; xypron.g...@gmx.de; g...@amd.com > Subject: Re: [0/4] Add eMMC 5.1 support for Versal NET > > Hi Jaehoon, > > On 1/10/23 12:31, Ashok Reddy Soma wrote: > > This patch series, > > - Add support for eMMC5.1 on Versal NET platform by adding new compatible > > string and PHY support. > > - Add support for input and output tap delays for eMMC > > - Add support for enabling HS400 in host capabilities by checking quirk. > > - Add quirk to support HS400 for Versal NET > > > > Ashok Reddy Soma (4): > >mmc: zynq_sdhci: Add support for eMMC5.1 for Versal NET platform > >mmc: sdhci: Check and call config_dll callback functions > >mmc: sdhci: Enable HS400 support if available in caps > >mmc: zynq_sdhci: Add support and quirk for HS400 > > > > drivers/mmc/sdhci.c | 20 +++ > > drivers/mmc/zynq_sdhci.c | 292 ++- > > include/sdhci.h | 5 + > > 3 files changed, 314 insertions(+), 3 deletions(-) > > > > Can you please review this series? Sorry for too late. I will review them. Best Regards, Jaehoon Chung > > Thanks, > Michal
[GIT PULL] Please pull u-boot-pmic master
Dear Tom, Please pull u-boot-pmic master into u-boot master branch. If there is a problem, let me know, plz Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-pmic/-/pipelines/14522 The following changes since commit e1befc8512fe4f67056a6e4b5cd2ab936abc35c6: Merge tag 'tpm-23122022' of https://source.denx.de/u-boot/custodians/u-boot-tpm (2022-12-23 07:46:41 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-pmic.git master for you to fetch changes up to dbedf4a56b49544b0f9174856a14bd6be2d9e641: power: regulator: Add support for NPCM8xx (2022-12-26 15:44:00 +0900) Jim Liu (1): power: regulator: Add support for NPCM8xx drivers/power/regulator/Kconfig | 8 drivers/power/regulator/Makefile| 1 + drivers/power/regulator/npcm8xx_regulator.c | 132 3 files changed, 141 insertions(+) create mode 100644 drivers/power/regulator/npcm8xx_regulator.c
RE: [PATCH] cmd: mmc: Expand bkops handling
Hi,
> -Original Message-
> From: Marek Vasut
> Sent: Thursday, December 22, 2022 2:11 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Jaehoon Chung ; Peng
> Fan
> Subject: [PATCH] cmd: mmc: Expand bkops handling
>
> 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
> ---
> Cc: Jaehoon Chung
> Cc: Peng Fan
> ---
> cmd/mmc.c | 49 +++
> drivers/mmc/mmc.c | 14 +-
> include/mmc.h | 2 +-
> 3 files changed, 51 insertions(+), 14 deletions(-)
>
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index c79d9407986..94deb9a1686 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -1020,16 +1020,12 @@ static int do_mmc_setdsr(struct cmd_tbl *cmdtp, int
> flag,
> }
>
> #ifdef CONFIG_CMD_BKOPS_ENABLE
> -static int do_mmc_bkops_enable(struct cmd_tbl *cmdtp, int flag,
> -int argc, char *const argv[])
> +static int mmc_bkops_common(char *device, bool autobkops, bool enable)
> {
> - int dev;
> struct mmc *mmc;
> + int dev;
>
> - if (argc != 2)
> - return CMD_RET_USAGE;
> -
> - dev = dectoul(argv[1], NULL);
> + dev = dectoul(device, NULL);
>
> mmc = init_mmc_device(dev, false);
> if (!mmc)
> @@ -1040,7 +1036,41 @@ static int do_mmc_bkops_enable(struct cmd_tbl *cmdtp,
> int flag,
> return CMD_RET_FAILURE;
> }
>
> - return mmc_set_bkops_enable(mmc);
> + return mmc_set_bkops_enable(mmc, autobkops, enable);
> +}
> +
> +static int do_mmc_bkops(struct cmd_tbl *cmdtp, int flag,
> + int argc, char * const argv[])
> +{
> + bool autobkops, enable;
> +
> + if (argc != 4)
> + return CMD_RET_USAGE;
> +
> + if (!strcmp(argv[2], "manual"))
> + autobkops = false;
> + else if (!strcmp(argv[2], "auto"))
> + autobkops = true;
> + else
> + return CMD_RET_FAILURE;
> +
> + if (!strcmp(argv[3], "disable"))
> + enable = false;
AFAIK, "manual" enable is one time programmable. It can't disable again after
enabled, isn't it?
Best Regards,
Jaehoon Chung
> + else if (!strcmp(argv[3], "enable"))
> + enable = true;
> + else
> + return CMD_RET_FAILURE;
> +
> + return mmc_bkops_common(argv[1], autobkops, enable);
> +}
> +
> +static int do_mmc_bkops_enable(struct cmd_tbl *cmdtp, int flag,
> +int argc, char * const argv[])
> +{
> + if (argc != 2)
> + return CMD_RET_USAGE;
> +
> + return mmc_bkops_common(argv[1], false, true);
> }
> #endif
>
> @@ -1102,6 +1132,7 @@ static struct cmd_tbl cmd_mmc[] = {
> U_BOOT_CMD_MKENT(setdsr, 2, 0, do_mmc_setdsr, "", ""),
> #ifdef CONFIG_CMD_BKOPS_ENABLE
> U_BOOT_CMD_MKENT(bkops-enable, 2, 0, do_mmc_bkops_enable, "", ""),
> + U_BOOT_CMD_MKENT(bkops, 4, 0, do_mmc_bkops, "", ""),
> #endif
> };
>
> @@ -1188,6 +1219,8 @@ U_BOOT_CMD(
> #ifdef CONFIG_CMD_BKOPS_ENABLE
> "mmc bkops-enable - enable background operations handshake on
> device\n"
> " WARNING: This is a write-once setting.\n"
> + "mmc bkops [auto|manual] [enable|disable]\n"
> + " - configure background operations handshake on device\n"
> #endif
> );
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 210703ea46b..afbc497b12c 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -3127,9 +3127,10 @@ int mmc_init_device(int num)
> #endif
>
> #ifdef CONFIG_CMD_BKOPS_ENABLE
> -int mmc_set_bkops_enable(struct mmc *mmc)
> +int mmc_set_bkops_enable(struct mmc *mmc, bool autobkops, bool enable)
> {
> int err;
> + u32 bit = autobkops ? BIT(1) : BIT(0);
> ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
>
> err = mmc_send_ext_csd(mmc, ext_csd);
> @@ -3143,18 +3144,21 @@ int mmc_set_bkops_enable(struct mmc *mmc)
> return -EMEDIUMTYPE;
> }
>
> - if (ext_csd[EXT_CSD_BKOPS_EN] & 0x1) {
> + if (enable && (ext_csd[EXT_CSD_BKOPS_EN] & bit)) {
> puts("Background operations already enabled\n");
>
Re: [PATCH v2] power: regulator: Add support for NPCM8xx
Hi,
On 11/7/22 11:48, Jim Liu wrote:
> Add support for setting nuvoton BMC NPCM845 voltage supply.
>
> Signed-off-by: Jim Liu
Reviewed-by: Jaehoon Chung
Sorry for late.
Best Regards,
Jaehoon Chung
> ---
> Changes for v2:
>- modify Kconfig description
>- modify get_value function
> ---
> drivers/power/regulator/Kconfig | 8 ++
> drivers/power/regulator/Makefile| 1 +
> drivers/power/regulator/npcm8xx_regulator.c | 132
> 3 files changed, 141 insertions(+)
> create mode 100644 drivers/power/regulator/npcm8xx_regulator.c
>
> diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
> index c519e066ef..c02e6377d8 100644
> --- a/drivers/power/regulator/Kconfig
> +++ b/drivers/power/regulator/Kconfig
> @@ -128,6 +128,14 @@ config DM_REGULATOR_MAX77686
> features for REGULATOR MAX77686. The driver implements get/set api for:
> value, enable and mode.
>
> +config DM_REGULATOR_NPCM8XX
> + bool "Enable Driver Model for NPCM8xx voltage supply"
> + depends on DM_REGULATOR && ARCH_NPCM8XX
> + help
> + Enable support for configuring voltage supply on NPCM8XX SoC. The
> + voltage supplies support two voltage levels and the driver implements
> + get/set api for setting the value.
> +
> config DM_REGULATOR_FAN53555
> bool "Enable Driver Model for REGULATOR FAN53555"
> depends on DM_PMIC_FAN53555
> diff --git a/drivers/power/regulator/Makefile
> b/drivers/power/regulator/Makefile
> index bc736068bc..68e4c0f9dd 100644
> --- a/drivers/power/regulator/Makefile
> +++ b/drivers/power/regulator/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
> obj-$(CONFIG_REGULATOR_AS3722) += as3722_regulator.o
> obj-$(CONFIG_$(SPL_)DM_REGULATOR_DA9063) += da9063.o
> obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
> +obj-$(CONFIG_DM_REGULATOR_NPCM8XX) += npcm8xx_regulator.o
> obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
> obj-$(CONFIG_$(SPL_)DM_REGULATOR_BD71837) += bd71837.o
> obj-$(CONFIG_$(SPL_)DM_REGULATOR_PCA9450) += pca9450.o
> diff --git a/drivers/power/regulator/npcm8xx_regulator.c
> b/drivers/power/regulator/npcm8xx_regulator.c
> new file mode 100644
> index 00..fcd1058cdf
> --- /dev/null
> +++ b/drivers/power/regulator/npcm8xx_regulator.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2022 Nuvoton Technology Corp.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define REG_VSRCR0xf08000e8 /* Voltage Supply Control Register */
> +
> +/* Supported voltage levels (uV) */
> +static const u32 volts_type1[] = { 330, 180 };
> +static const u32 volts_type2[] = { 100, 180 };
> +#define VOLT_LEV00
> +#define VOLT_LEV11
> +
> +struct volt_supply {
> + char *name;
> + const u32 *volts;
> + u32 reg_shift; /* Register bit offset for setting voltage */
> +};
> +
> +static const struct volt_supply npcm8xx_volt_supps[] = {
> + {"v1", volts_type1, 0},
> + {"v2", volts_type1, 1},
> + {"v3", volts_type1, 2},
> + {"v4", volts_type1, 3},
> + {"v5", volts_type1, 4},
> + {"v6", volts_type1, 5},
> + {"v7", volts_type1, 6},
> + {"v8", volts_type1, 7},
> + {"v9", volts_type1, 8},
> + {"v10", volts_type1, 9},
> + {"v11", volts_type2, 10},
> + {"v12", volts_type1, 11},
> + {"v13", volts_type1, 12},
> + {"v14", volts_type2, 13},
> + {"vsif", volts_type1, 14},
> + {"vr2", volts_type1, 30},
> +};
> +
> +static const struct volt_supply *npcm8xx_volt_supply_get(const char *name)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(npcm8xx_volt_supps); i++) {
> + if (!strcmp(npcm8xx_volt_supps[i].name, name))
> + return _volt_supps[i];
> + }
> +
> + return NULL;
> +}
> +
> +static int npcm8xx_regulator_set_value(struct udevice *dev, int uV)
> +{
> + struct dm_regulator_uclass_plat *uc_pdata;
> + const struct volt_supply *supp;
> + u32 val, level;
> +
> + uc_pdata = dev_get_uclass_plat(dev);
> + if (!uc_pdata)
> + return -ENXIO;
> +
> + dev_dbg(dev, "%s set_value: %d\n", uc_pdata->name, uV);
> + supp = npcm8xx_volt_supply_get(uc_pdata->name);
> + if (!supp)
> + return -ENOENT;
> +
> + if (uV == supp->v
Re: Changing eMMC boot partition size
Hi, On 11/9/22 03:30, Tom Rini wrote: > On Tue, Nov 08, 2022 at 06:34:18PM +0100, Philip Oberfichtner wrote: >> Hi everybody, >> >> I have a question regarding changing the eMMC boot partition size. >> According the the JEDEC eMMC spec it is read-only (BOOT_SIZE_MULT >> register). >> >> But we still have mmc_boot_partition_size_change() in >> drivers/mmc/mmc_boot.c. It contains the comment >> >> /* Only use this command for raw EMMC moviNAND. Enter backdoor mode */ >> >> What is moviNAND? My research pointed me to Samsung products only. So >> is changing the boot partition size vendor specific or can it be used >> more generally? >> >> To be specific, I use the Kioxia THGBMJG6C1LBAB7 eMMC chip. > > Yes, moviNAND was some Samsung technology that may or may not still be > used on some platforms. And yes, some eMMC parts do allow for boot > partitions to be resized but such information is often under NDA, so > contacting the hardware vendor or looking for eMMC chip documentation > may be helpful here. Thanks for replying this. As like Tom's comment, eMMC that is manufactured from Samsung was called MoviNand. It's used with Reserved Command for manufacturer. So If you want to change your eMMC's boot partition size, you need to check Kioxiz documentation. Best Regards, Jaehoon Chung >
Re: [PATCH] cmd: mmc: Print life time info
Hi,
On 11/2/22 23:17, Robert Krikke wrote:
> Added life time info:
> -EXT_CSD_PRE_EOL_INFO
> -EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A
> -EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B
I'm not sure that it really needs to display this information as mmc info.
I hope that mmc info command should be displayed essential information.
>
> Signed-off-by: Robert Krikke
> Reviewed-by: Harm Berntsen
> ---
> cmd/mmc.c | 6 ++
> include/mmc.h | 3 +++
> 2 files changed, 9 insertions(+)
>
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 7bd4cd9e016..b940e320295 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -127,6 +127,12 @@ static void print_mmcinfo(struct mmc *mmc)
> }
> wp >>= 2;
> }
> +
> + if (mmc->version >= MMC_VERSION_5_0) {
Move to outside of MMC_VERSION_4_41 if statement.
> + printf("Pre EOL Information: 0x%02X\n",
> ext_csd[EXT_CSD_PRE_EOL_INFO]);
> + printf("Life Time Estimation A: 0x%02X\n",
> ext_csd[EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]);
> + printf("Life Time Estimation B: 0x%02X\n",
> ext_csd[EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]);
It's not a readable value. If didn't check the eMMC5.0 spec, it's difficult to
know what means 0x01, 0x02..etc..
Best Regards,
Jaehoon Chung
> + }
> }
> }
>
> diff --git a/include/mmc.h b/include/mmc.h
> index f519d869725..d0c3e684595 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -242,6 +242,9 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx)
> #define EXT_CSD_HC_ERASE_GRP_SIZE224 /* RO */
> #define EXT_CSD_BOOT_MULT226 /* RO */
> #define EXT_CSD_GENERIC_CMD6_TIME 248 /* RO */
> +#define EXT_CSD_PRE_EOL_INFO 267 /* RO */
> +#define EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A 268 /* RO */
> +#define EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B 269 /* RO */
> #define EXT_CSD_BKOPS_SUPPORT502 /* RO */
>
> /*
RE: [PATCH v1] power: regulator: Add support for NPCM845
Hi,
> -Original Message-
> From: Jim Liu [mailto:jim.t90...@gmail.com]
> Sent: Tuesday, November 1, 2022 11:21 AM
> To: jim.t90...@gmail.com; jjl...@nuvoton.com; ys...@nuvoton.com;
> kw...@nuvoton.com;
> jh80.ch...@samsung.com
> Cc: u-boot@lists.denx.de
> Subject: [PATCH v1] power: regulator: Add support for NPCM845
>
> Add support for setting NPCM845 voltage supply
>
> regulator-force-microvolt is npcm proprietary property to
> set the voltage level.
What is regulator-force-microvolt. I didn't find this property in u-boot /
kernel side.
If I missed something, could you explain it?
And Is there no pmic for this regulator?
>
> Signed-off-by: Jim Liu
> ---
> drivers/power/regulator/Kconfig | 8 ++
> drivers/power/regulator/Makefile| 1 +
> drivers/power/regulator/npcm8xx_regulator.c | 133
> 3 files changed, 142 insertions(+)
> create mode 100644 drivers/power/regulator/npcm8xx_regulator.c
>
> diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
> index c519e066ef..e5f06874de 100644
> --- a/drivers/power/regulator/Kconfig
> +++ b/drivers/power/regulator/Kconfig
> @@ -128,6 +128,14 @@ config DM_REGULATOR_MAX77686
> features for REGULATOR MAX77686. The driver implements get/set api for:
> value, enable and mode.
>
> +config DM_REGULATOR_NPCM8XX
> + bool "Enable driver for NPCM8xx voltage supply"
"Enable Driver Model for "
> + depends on DM_REGULATOR && ARCH_NPCM8XX
> + help
> + Enable support for configuring voltage supply on NPCM8XX SoC. The
> + voltage supplies support two voltage levels and the driver implements
> + get/set api for setting the value.
> +
> config DM_REGULATOR_FAN53555
> bool "Enable Driver Model for REGULATOR FAN53555"
> depends on DM_PMIC_FAN53555
> diff --git a/drivers/power/regulator/Makefile
> b/drivers/power/regulator/Makefile
> index bc736068bc..68e4c0f9dd 100644
> --- a/drivers/power/regulator/Makefile
> +++ b/drivers/power/regulator/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
> obj-$(CONFIG_REGULATOR_AS3722) += as3722_regulator.o
> obj-$(CONFIG_$(SPL_)DM_REGULATOR_DA9063) += da9063.o
> obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
> +obj-$(CONFIG_DM_REGULATOR_NPCM8XX) += npcm8xx_regulator.o
> obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
> obj-$(CONFIG_$(SPL_)DM_REGULATOR_BD71837) += bd71837.o
> obj-$(CONFIG_$(SPL_)DM_REGULATOR_PCA9450) += pca9450.o
> diff --git a/drivers/power/regulator/npcm8xx_regulator.c
> b/drivers/power/regulator/npcm8xx_regulator.c
> new file mode 100644
> index 00..7903287132
> --- /dev/null
> +++ b/drivers/power/regulator/npcm8xx_regulator.c
> @@ -0,0 +1,133 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2022 Nuvoton Technology Corp.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define REG_VSRCR0xf08000e8 /* Voltage Supply Control Register */
> +
> +/* Supported voltage levels (uV) */
> +static const u32 volts_type1[] = { 330, 180 };
> +static const u32 volts_type2[] = { 100, 180 };
> +#define VOLT_LEV00
> +#define VOLT_LEV11
> +
> +struct volt_supply {
> + char *name;
> + const u32 *volts;
> + u32 reg_shift; /* Register bit offset for setting voltage */
> +};
> +
> +static const struct volt_supply npcm8xx_volt_supps[] = {
> + {"v1", volts_type1, 0},
> + {"v2", volts_type1, 1},
> + {"v3", volts_type1, 2},
> + {"v4", volts_type1, 3},
> + {"v5", volts_type1, 4},
> + {"v6", volts_type1, 5},
> + {"v7", volts_type1, 6},
> + {"v8", volts_type1, 7},
> + {"v9", volts_type1, 8},
> + {"v10", volts_type1, 9},
> + {"v11", volts_type2, 10},
> + {"v12", volts_type1, 11},
> + {"v13", volts_type1, 12},
> + {"v14", volts_type2, 13},
> + {"vsif", volts_type1, 14},
> + {"vr2", volts_type1, 30},
> +};
> +
> +static const struct volt_supply *npcm8xx_volt_supply_get(const char *name)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(npcm8xx_volt_supps); i++) {
> + if (!strcmp(npcm8xx_volt_supps[i].name, name))
> + return _volt_supps[i];
> + }
> +
> + return NULL;
> +}
> +
> +static int npcm8xx_regulator_set_value(struct udevice *dev, int uV)
> +{
> + struct dm_regulator_uclass_plat *uc_pdata;
> + const struct volt_supply *supp;
> + u32 val, level;
> +
> + uc_pdata = dev_get_uclass_plat(dev);
> + if (!uc_pdata)
> + return -ENXIO;
> +
> + dev_dbg(dev, "%s set_value: %d\n", uc_pdata->name, uV);
> + supp = npcm8xx_volt_supply_get(uc_pdata->name);
> + if (!supp)
> + return -ENOENT;
> +
> + if (uV == supp->volts[VOLT_LEV0])
> + level = VOLT_LEV0;
> + else if (uV == supp->volts[VOLT_LEV1])
> + level = VOLT_LEV1;
> + else
> + return -EINVAL;
> +
> +
RE: [PATCH 12/21] Convert CONFIG_SYS_MMC_MAX_BLK_COUNT to Kconfig
> -Original Message- > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Simon Glass > Sent: Sunday, October 30, 2022 10:44 AM > To: Tom Rini > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH 12/21] Convert CONFIG_SYS_MMC_MAX_BLK_COUNT to Kconfig > > On Fri, 28 Oct 2022 at 18:29, Tom Rini wrote: > > > > This converts the following to Kconfig: > >CONFIG_SYS_MMC_MAX_BLK_COUNT > > > > Signed-off-by: Tom Rini > > --- > > configs/hikey960_defconfig | 1 + > > configs/octeontx2_95xx_defconfig| 1 + > > configs/octeontx2_96xx_defconfig| 1 + > > configs/octeontx_81xx_defconfig | 1 + > > configs/octeontx_83xx_defconfig | 1 + > > configs/socfpga_agilex_atf_defconfig| 1 + > > configs/socfpga_agilex_defconfig| 1 + > > configs/socfpga_agilex_vab_defconfig| 1 + > > configs/socfpga_arria10_defconfig | 1 + > > configs/socfpga_arria5_defconfig| 1 + > > configs/socfpga_cyclone5_defconfig | 1 + > > configs/socfpga_dbm_soc1_defconfig | 1 + > > configs/socfpga_de0_nano_soc_defconfig | 1 + > > configs/socfpga_de10_nano_defconfig | 1 + > > configs/socfpga_de10_standard_defconfig | 1 + > > configs/socfpga_de1_soc_defconfig | 1 + > > configs/socfpga_mcvevk_defconfig| 1 + > > configs/socfpga_n5x_atf_defconfig | 1 + > > configs/socfpga_n5x_defconfig | 1 + > > configs/socfpga_n5x_vab_defconfig | 1 + > > configs/socfpga_secu1_defconfig | 1 + > > configs/socfpga_sockit_defconfig| 1 + > > configs/socfpga_socrates_defconfig | 1 + > > configs/socfpga_sr1500_defconfig| 1 + > > configs/socfpga_stratix10_atf_defconfig | 1 + > > configs/socfpga_stratix10_defconfig | 1 + > > configs/socfpga_vining_fpga_defconfig | 1 + > > configs/total_compute_defconfig | 1 + > > configs/vexpress_ca9x4_defconfig| 1 + > > drivers/mmc/Kconfig | 7 +++ > > include/configs/hikey960.h | 1 - > > include/configs/octeontx2_common.h | 2 -- > > include/configs/octeontx_common.h | 2 -- > > include/configs/socfpga_common.h| 9 - > > include/configs/socfpga_soc64_common.h | 3 --- > > include/configs/total_compute.h | 2 -- > > include/configs/vexpress_common.h | 2 -- > > include/mmc.h | 5 - > > 38 files changed, 36 insertions(+), 26 deletions(-) > > Reviewed-by: Simon Glass Reviewed-by: Jaehoon Chung
RE: [PATCH 13/21] Convert CONFIG_SYS_MMC_MAX_DEVICE to Kconfig
> -Original Message- > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Simon Glass > Sent: Tuesday, November 1, 2022 4:27 AM > To: Tom Rini > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH 13/21] Convert CONFIG_SYS_MMC_MAX_DEVICE to Kconfig > > On Sun, 30 Oct 2022 at 10:37, Tom Rini wrote: > > > > On Sat, Oct 29, 2022 at 07:43:36PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Fri, 28 Oct 2022 at 18:29, Tom Rini wrote: > > > > > > > > This converts the following to Kconfig: > > > >CONFIG_SYS_MMC_MAX_DEVICE > > > > > > > > Signed-off-by: Tom Rini > > > > --- > > > > api/Kconfig| 5 + > > > > api/api_storage.c | 4 > > > > include/configs/am335x_evm.h | 18 -- > > > > include/configs/stm32mp13_common.h | 3 --- > > > > include/configs/stm32mp15_common.h | 3 --- > > > > include/configs/sunxi-common.h | 2 -- > > > > include/configs/tegra-common.h | 7 --- > > > > include/configs/zynq-common.h | 3 --- > > > > 8 files changed, 5 insertions(+), 40 deletions(-) > > > > > > It seems odd that none of the boards end up with a defconfig setting > > > it to 2 or 3. > > > > What happened here is that boards were setting the value to something > > else, but never using it. > > Ah OK, that's good to fix. > > Reviewed-by: Simon Glass Reviewed-by: Jaehoon Chung
RE: Wolfgang Denk
> -Original Message- > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Stefano Babic > Sent: Saturday, October 22, 2022 12:12 AM > To: U-Boot@lists.denx.de > Subject: Wolfgang Denk > > Dear U-Boot community, > > it is my very sad duty to inform you that Wolfgang Denk, the father of > U-Boot, passed away last > week. We have lost a great developer and a very good friend. > > I met Wolfgang the first time quite 25 years ago, when we worked for the same > company. I was hired > as consultant for a (at the time very frequently used) RTOS. I had no time to > introduce me, > because Wolfgang interrupted me with : "Just install Linux !". Well, of > course I did. It was the > first good suggestion he gave me. Many others followed. > > Wolfgang was a pioneer and strong supporter of Open Source, in the time when > Linux for Embedded > System started its first steps. In many occasions he had strong discussions > with customers to > explain the advantages of Open Source, and he rejected business contracts if > customer was going > against his principles. We will miss him. > > Rest in peace, my friend So sad news. Rest in Peace, Wolfgang Denk. Jaehoon Chung > > Stefano Babic > > -- > = > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > =
RE: [PATCH] drivers: mmc: Reset watchdog when accessing mmc device
Hi, > -Original Message- > From: qianfan [mailto:qianfangui...@163.com] > Sent: Tuesday, August 30, 2022 12:43 PM > To: Jaehoon Chung ; u-boot@lists.denx.de > Cc: Peng Fan > Subject: Re: [PATCH] drivers: mmc: Reset watchdog when accessing mmc device > > > > 在 2022/7/26 16:31, Jaehoon Chung 写道: > > On 7/13/22 16:32, qianfangui...@163.com wrote: > >> From: qianfan Zhao > >> > >> watchdog will reset when 'mmc read' or 'ext4load' a large file from > >> mmc device. Reset watchdog when accessing mmc device. > > I don't know why this patch is need. > Hi: > > maybe your's board doesn't have a hardware watchdog. > on my board there has a gpio watchdog and we should trigger it no more than > 1.2 second. > otherwise it will reset CPU. > > But 'mmc read' command doesn't trigger watchdog, it's ok if we load a smaller > imges, but if we > load a very bigger image which more than 100MiB, the watchdog will dead and > trigger a system reset. Sorry for too late. I had missed your email. Is there a case to load more bigger image than 100MiB? Best Regards, Jaehoon Chung > > So I make this patch to make sure we can trigger watchdog while loading mmc. > > > > Best Regards, > > Jaehoon Chung > > > >> Signed-off-by: qianfan Zhao > >> --- > >> drivers/mmc/mmc.c | 4 > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index > >> 4d9871d69f..27ffdb7fa7 100644 > >> --- a/drivers/mmc/mmc.c > >> +++ b/drivers/mmc/mmc.c > >> @@ -24,6 +24,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> #include "mmc_private.h" > >> > >> #define DEFAULT_CMD6_TIMEOUT_MS 500 @@ -297,6 +298,7 @@ int > >> mmc_poll_for_busy(struct mmc *mmc, int timeout_ms) > >>if (timeout_ms-- <= 0) > >>break; > >> > >> + WATCHDOG_RESET(); > >>udelay(1000); > >>} > >> > >> @@ -500,6 +502,8 @@ ulong mmc_bread(struct blk_desc *block_dev, lbaint_t > >> start, lbaint_t blkcnt, > >>blocks_todo -= cur; > >>start += cur; > >>dst += cur * mmc->read_bl_len; > >> + > >> + WATCHDOG_RESET(); > >>} while (blocks_todo > 0); > >> > >>return blkcnt;
[GIT PULL] Please pull u-boot-pmic master
Dear Tom, Please pull u-boot-pmic master into u-boot master branch. If there is a problem, let me know, plz Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-pmic/-/pipelines/13944 The following changes since commit f9d16f2c0daf68dcb963c08c927f5f0a07cf75e4: Merge https://source.denx.de/u-boot/custodians/u-boot-spi (2022-10-25 09:54:59 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-pmic.git master for you to fetch changes up to 0b9186277a944dd7c34c5d01850fbe57b6bfa10a: power: fan53555: Fix missing newline in error message (2022-10-26 11:47:25 +0900) John Keeping (1): power: regulator: fix autoset error handling Michal Suchanek (1): power: fan53555: Fix missing newline in error message drivers/power/pmic/fan53555.c | 2 +- drivers/power/regulator/regulator-uclass.c | 8 +++- 2 files changed, 8 insertions(+), 2 deletions(-)
RE: [PATCH v5 4/5] drivers: power: pmic: Enable use of rn5t567 PMIC in SPL
> -Original Message- > From: Martyn Welch [mailto:martyn.we...@collabora.com] > Sent: Tuesday, October 25, 2022 6:55 PM > To: uboot-...@nxp.com; sba...@denx.de; Jaehoon Chung > Cc: Martyn Welch ; Simon Glass > ; u- > b...@lists.denx.de > Subject: [PATCH v5 4/5] drivers: power: pmic: Enable use of rn5t567 PMIC in > SPL > > From: Martyn Welch > > The support added later in this series tweaks the PMIC voltages in the > SPL. Enable support for the rn5t567 in SPL builds to allow this to be done > cleanly. > > Signed-off-by: Martyn Welch > Reviewed-by: Simon Glass Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > > Changes in v3: > - New patch (replaces addition of legacy support for rn5t567) > > Changes in v4: > - None > > Changes in v5: > - Rebase to current master branch > > drivers/power/pmic/Kconfig | 8 > drivers/power/pmic/Makefile | 2 +- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig > index 0478f2aa1d..628d3a94bc 100644 > --- a/drivers/power/pmic/Kconfig > +++ b/drivers/power/pmic/Kconfig > @@ -300,6 +300,14 @@ config PMIC_RN5T567 > regulators Real-Time Clock and 4 GPIOs. This driver provides > register access only. > > +config SPL_PMIC_RN5T567 > + bool "Enable driver for Ricoh RN5T567 PMIC in SPL" > + depends on SPL_DM_PMIC > + ---help--- > + The RN5T567 is a PMIC with 4 step-down DC/DC converters, 5 LDO > + regulators Real-Time Clock and 4 GPIOs. This driver provides > + register access only. > + > config PMIC_TPS65090 > bool "Enable driver for Texas Instruments TPS65090 PMIC" > ---help--- > diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile > index e1d3545490..58c6507c58 100644 > --- a/drivers/power/pmic/Makefile > +++ b/drivers/power/pmic/Makefile > @@ -22,7 +22,7 @@ obj-$(CONFIG_$(SPL_)PMIC_AXP) += axp.o > obj-$(CONFIG_PMIC_MAX8997) += max8997.o > obj-$(CONFIG_PMIC_QCOM) += pmic_qcom.o > obj-$(CONFIG_$(SPL_TPL_)PMIC_RK8XX) += rk8xx.o > -obj-$(CONFIG_PMIC_RN5T567) += rn5t567.o > +obj-$(CONFIG_$(SPL_)PMIC_RN5T567) += rn5t567.o > obj-$(CONFIG_PMIC_TPS65090) += tps65090.o > obj-$(CONFIG_PMIC_S5M8767) += s5m8767.o > obj-$(CONFIG_DM_PMIC_TPS65910) += pmic_tps65910_dm.o > -- > 2.35.1
RE: [PATCH v5 3/5] drivers: power: pmic: Add support for rn5t568 PMIC
> -Original Message-
> From: Martyn Welch [mailto:martyn.we...@collabora.com]
> Sent: Tuesday, October 25, 2022 6:55 PM
> To: uboot-...@nxp.com; sba...@denx.de; Jaehoon Chung
> Cc: Martyn Welch ; u-boot@lists.denx.de
> Subject: [PATCH v5 3/5] drivers: power: pmic: Add support for rn5t568 PMIC
>
> Add support for the rn5t568 PMIC to the rn5t567 driver.
>
> Signed-off-by: Martyn Welch
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> Changes in v2:
> - None
>
> Changes in v3:
> - None
>
> Changes in v4:
> - None
>
> Changes in v5:
> - None
>
> drivers/power/pmic/rn5t567.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/power/pmic/rn5t567.c b/drivers/power/pmic/rn5t567.c
> index d9a8298ebb..9d103dd840 100644
> --- a/drivers/power/pmic/rn5t567.c
> +++ b/drivers/power/pmic/rn5t567.c
> @@ -53,6 +53,7 @@ static struct dm_pmic_ops rn5t567_ops = {
>
> static const struct udevice_id rn5t567_ids[] = {
> { .compatible = "ricoh,rn5t567" },
> + { .compatible = "ricoh,rn5t568" },
> { }
> };
>
> --
> 2.35.1
[GIT PULL] Please pull u-boot-mmc master
Dear Tom, Please pull u-boot-mmc master into u-boot master branch. If there is any problem, let me know, plz. Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/13923 The following changes since commit 7723828c97bc107d2fba976fc50403ac8747f1bc: Merge branch '2022-10-21-enforce-some-DM-migrations' (2022-10-21 15:32:45 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master for you to fetch changes up to 337af54a36c6409b7eeb49619c796178b3c22372: mmc: Fix static checker warnings (2022-10-24 18:02:54 +0900) John Keeping (1): mmc: dwmmc: only clear handled interrupts Kunihiko Hayashi (2): mmc: sdhci: Add new quirks for SUPPORT_SINGLE mmc: f_sdh30: Add support for F_SDH30_E51 Sergei Antonov (1): mmc: ftsdc010: make command timeout 250 ms as in the comment Venkatesh Yadav Abbarapu (1): mmc: Fix static checker warnings Yann Gautier (3): mmc: stm32_sdmmc2: add dual data rate support mmc: stm32_sdmmc2: protect against unsupported modes mmc: stm32_sdmmc2: manage vqmmc drivers/mmc/Kconfig| 4 ++-- drivers/mmc/dw_mmc.c | 3 ++- drivers/mmc/f_sdh30.c | 66 -- drivers/mmc/ftsdc010_mci.c | 2 +- drivers/mmc/mmc.c | 6 -- drivers/mmc/sdhci.c| 8 +--- drivers/mmc/stm32_sdmmc2.c | 20 +++- include/sdhci.h| 1 + 8 files changed, 98 insertions(+), 12 deletions(-)
Re: [PATCH] mmc: Fix static checker warnings
On 9/29/22 13:52, Venkatesh Yadav Abbarapu wrote: > Correct pointer dereferencing check to be more consistent. > > Eliminate the below smatch warning: > drivers/mmc/mmc.c:3118 mmc_init_device() > warn: variable dereferenced before check 'm' (see line 3116) > > Signed-off-by: Venkatesh Yadav Abbarapu > Reviewed-by: Michal Simek > Reviewed-by: Jaehoon Chung Applied to u-boot-mmc. Thanks! Best Regards, Jaehoon Chung > --- > > drivers/mmc/mmc.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c > index 0b7c0be8cb..210703ea46 100644 > --- a/drivers/mmc/mmc.c > +++ b/drivers/mmc/mmc.c > @@ -3113,10 +3113,12 @@ int mmc_init_device(int num) > } > > m = mmc_get_mmc_dev(dev); > - m->user_speed_mode = MMC_MODES_END; /* Initialising user set speed mode > */ > - > if (!m) > return 0; > + > + /* Initialising user set speed mode */ > + m->user_speed_mode = MMC_MODES_END; > + > if (m->preinit) > mmc_start_init(m); >
Re: [PATCH] mmc: dwmmc: only clear handled interrupts
On 9/16/22 02:56, John Keeping wrote:
> Unconditionally clearing DTO when RXDR is set leads to spurious timeouts
> in FIFO mode transfers if events occur in the following order:
>
> mask = dwmci_readl(host, DWMCI_RINTSTS);
>
> // Hardware asserts DWMCI_INTMSK_DTO here
>
> dwmci_writel(host, DWMCI_RINTSTS, DWMCI_INTMSK_DTO);
>
> if (mask & DWMCI_INTMSK_DTO) {
> // Unreachable as DTO is cleared without being handled!
> return 0;
> }
>
> Only clear interrupts that we have seen and are handling so that DTO is
> not missed.
>
> Signed-off-by: John Keeping
> Tested-by: Jerome Forissier (Rock PI 4B)
> Tested-by: Quentin Schulz
> Reviewed-by: Jaehoon Chung
Applied to u-boot-mmc. Thanks!
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/dw_mmc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 4232c5eb8c..5085a3b491 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -168,7 +168,8 @@ static int dwmci_data_transfer(struct dwmci_host *host,
> struct mmc_data *data)
> if (data->flags == MMC_DATA_READ &&
> (mask & (DWMCI_INTMSK_RXDR | DWMCI_INTMSK_DTO))) {
> dwmci_writel(host, DWMCI_RINTSTS,
> - DWMCI_INTMSK_RXDR |
> DWMCI_INTMSK_DTO);
> + mask & (DWMCI_INTMSK_RXDR |
> + DWMCI_INTMSK_DTO));
> while (size) {
> ret = dwmci_fifo_ready(host,
> DWMCI_FIFO_EMPTY,
Re: [PATCH 1/3] mmc: stm32_sdmmc2: add dual data rate support
On 9/13/22 20:23, Yann Gautier wrote:
> To support dual data rate with STM32 sdmmc2 driver, the dedicated bit
> (DDR - BIT(18)) needs to be set in the CLKRC register. Clock bypass
> (no divider) is not allowed in this case. This is required for the
> eMMC DDR modes.
>
> Signed-off-by: Yann Gautier
> Reviewed-by: Jaehoon Chung
Applied to u-boot-mmc. Thanks! (with [PATCH 2/3] and [PATCH 3/3])
Best Regards,
Jaehoon Chung
> ---
>
> drivers/mmc/stm32_sdmmc2.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
> index bfce8a2e4a..3cfa5a66f1 100644
> --- a/drivers/mmc/stm32_sdmmc2.c
> +++ b/drivers/mmc/stm32_sdmmc2.c
> @@ -598,13 +598,16 @@ static int stm32_sdmmc2_set_ios(struct udevice *dev)
>* clk_div > 0 and NEGEDGE = 1 => command and data generated on
>* SDMMCCLK falling edge
>*/
> - if (desired && ((sys_clock > desired) ||
> + if (desired && (sys_clock > desired || mmc->ddr_mode ||
> IS_RISING_EDGE(plat->clk_reg_msk))) {
> clk = DIV_ROUND_UP(sys_clock, 2 * desired);
> if (clk > SDMMC_CLKCR_CLKDIV_MAX)
> clk = SDMMC_CLKCR_CLKDIV_MAX;
> }
>
> + if (mmc->ddr_mode)
> + clk |= SDMMC_CLKCR_DDR;
> +
> if (mmc->bus_width == 4)
> clk |= SDMMC_CLKCR_WIDBUS_4;
> if (mmc->bus_width == 8)
Re: [PATCH v2 2/2] mmc: f_sdh30: Add support for F_SDH30_E51
On 9/9/22 16:23, Kunihiko Hayashi wrote:
> Add Socionext F_SDH30_E51 IP support. The features of this IP includes
> CMD/DAT line delay and force card insertion mode for non-removable cards.
> And the IP needs to add some quirks.
>
> Signed-off-by: Kunihiko Hayashi
Applied to u-boot-mmc. Thanks!
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/Kconfig | 4 +--
> drivers/mmc/f_sdh30.c | 66 +--
> 2 files changed, 66 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 0dcec8adcee8..c30f20cba5f2 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -577,12 +577,12 @@ config MMC_SDHCI_IPROC
> If unsure, say N.
>
> config MMC_SDHCI_F_SDH30
> - bool "SDHCI support for Fujitsu Semiconductor F_SDH30"
> + bool "SDHCI support for Fujitsu Semiconductor/Socionext F_SDH30"
> depends on BLK && DM_MMC
> depends on MMC_SDHCI
> help
> This selects the Secure Digital Host Controller Interface (SDHCI)
> - Needed by some Fujitsu SoC for MMC / SD / SDIO support.
> + Needed by some Fujitsu/Socionext SoC for MMC / SD / SDIO support.
> If you have a controller with this interface, say Y or M here.
> If unsure, say N.
>
> diff --git a/drivers/mmc/f_sdh30.c b/drivers/mmc/f_sdh30.c
> index 3a85d9e348ab..3d587a464d50 100644
> --- a/drivers/mmc/f_sdh30.c
> +++ b/drivers/mmc/f_sdh30.c
> @@ -11,13 +11,48 @@
> #include
> #include
>
> +#define F_SDH30_ESD_CONTROL 0x124
> +#define F_SDH30_CMD_DAT_DELAYBIT(9)
> +
> +#define F_SDH30_TEST 0x158
> +#define F_SDH30_FORCE_CARD_INSERTBIT(6)
> +
> +struct f_sdh30_data {
> + void (*init)(struct udevice *dev);
> + u32 quirks;
> +};
> +
> struct f_sdh30_plat {
> struct mmc_config cfg;
> struct mmc mmc;
> +
> + bool enable_cmd_dat_delay;
> + const struct f_sdh30_data *data;
> };
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +static void f_sdh30_e51_init(struct udevice *dev)
> +{
> + struct f_sdh30_plat *plat = dev_get_plat(dev);
> + struct sdhci_host *host = dev_get_priv(dev);
> + u32 val;
> +
> + val = sdhci_readl(host, F_SDH30_ESD_CONTROL);
> + if (plat->enable_cmd_dat_delay)
> + val |= F_SDH30_CMD_DAT_DELAY;
> + else
> + val &= ~F_SDH30_CMD_DAT_DELAY;
> + sdhci_writel(host, val, F_SDH30_ESD_CONTROL);
> +
> + val = sdhci_readl(host, F_SDH30_TEST);
> + if (plat->cfg.host_caps & MMC_CAP_NONREMOVABLE)
> + val |= F_SDH30_FORCE_CARD_INSERT;
> + else
> + val &= ~F_SDH30_FORCE_CARD_INSERT;
> + sdhci_writel(host, val, F_SDH30_TEST);
> +}
> +
> static int f_sdh30_sdhci_probe(struct udevice *dev)
> {
> struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> @@ -25,6 +60,8 @@ static int f_sdh30_sdhci_probe(struct udevice *dev)
> struct sdhci_host *host = dev_get_priv(dev);
> int ret;
>
> + plat->data = (const struct f_sdh30_data *)dev_get_driver_data(dev);
> +
> ret = mmc_of_parse(dev, >cfg);
> if (ret)
> return ret;
> @@ -33,6 +70,9 @@ static int f_sdh30_sdhci_probe(struct udevice *dev)
> host->mmc->dev = dev;
> host->mmc->priv = host;
>
> + if (plat->data && plat->data->quirks)
> + host->quirks = plat->data->quirks;
> +
> ret = sdhci_setup_cfg(>cfg, host, 2, 40);
> if (ret)
> return ret;
> @@ -41,18 +81,29 @@ static int f_sdh30_sdhci_probe(struct udevice *dev)
>
> mmc_set_clock(host->mmc, host->mmc->cfg->f_min, MMC_CLK_ENABLE);
>
> - return sdhci_probe(dev);
> + ret = sdhci_probe(dev);
> + if (ret)
> + return ret;
> +
> + if (plat->data && plat->data->init)
> + plat->data->init(dev);
> +
> + return 0;
> }
>
> static int f_sdh30_of_to_plat(struct udevice *dev)
> {
> struct sdhci_host *host = dev_get_priv(dev);
> + struct f_sdh30_plat *plat = dev_get_plat(dev);
>
> host->name = strdup(dev->name);
> host->ioaddr = dev_read_addr_ptr(dev);
> host->bus_width = dev_read_u32_default(dev, "bus-width", 4);
> host->index = dev_read_u32_default(dev, "index", 0);
>
> + plat->enable_cmd_dat_delay =
> + dev_read_bool(dev, "socionext,enable-cmd-dat-delay");
> +
> retur
Re: [PATCH v2 1/2] mmc: sdhci: Add new quirks for SUPPORT_SINGLE
On 9/9/22 16:23, Kunihiko Hayashi wrote:
> This patch defines a quirk to disable the block count
> for single block transactions.
>
> This is similar to Linux kernel commit d3fc5d71ac4d
> ("mmc: sdhci: add a quirk for single block transactions").
>
> Signed-off-by: Kunihiko Hayashi
> Reviewed-by: Jaehoon Chung
Applied to u-boot-mmc. Thanks!
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/sdhci.c | 8 +---
> include/sdhci.h | 1 +
> 2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index bf989a594f7e..a80ad8329a38 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -211,7 +211,7 @@ static int sdhci_send_command(struct mmc *mmc, struct
> mmc_cmd *cmd,
> unsigned int stat = 0;
> int ret = 0;
> int trans_bytes = 0, is_aligned = 1;
> - u32 mask, flags, mode;
> + u32 mask, flags, mode = 0;
> unsigned int time = 0;
> int mmc_dev = mmc_get_blk_desc(mmc)->devnum;
> ulong start = get_timer(0);
> @@ -273,10 +273,12 @@ static int sdhci_send_command(struct mmc *mmc, struct
> mmc_cmd *cmd,
> /* Set Transfer mode regarding to data flag */
> if (data) {
> sdhci_writeb(host, 0xe, SDHCI_TIMEOUT_CONTROL);
> - mode = SDHCI_TRNS_BLK_CNT_EN;
> +
> + if (!(host->quirks & SDHCI_QUIRK_SUPPORT_SINGLE))
> + mode = SDHCI_TRNS_BLK_CNT_EN;
> trans_bytes = data->blocks * data->blocksize;
> if (data->blocks > 1)
> - mode |= SDHCI_TRNS_MULTI;
> + mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_BLK_CNT_EN;
>
> if (data->flags == MMC_DATA_READ)
> mode |= SDHCI_TRNS_READ;
> diff --git a/include/sdhci.h b/include/sdhci.h
> index 88f1917480b6..24b4599b857d 100644
> --- a/include/sdhci.h
> +++ b/include/sdhci.h
> @@ -247,6 +247,7 @@
> #define SDHCI_QUIRK_WAIT_SEND_CMD(1 << 6)
> #define SDHCI_QUIRK_USE_WIDE8(1 << 8)
> #define SDHCI_QUIRK_NO_1_8_V (1 << 9)
> +#define SDHCI_QUIRK_SUPPORT_SINGLE (1 << 10)
>
> /* to make gcc happy */
> struct sdhci_host;
Re: [PATCH] mmc: ftsdc010: make command timeout 250 ms as in the comment
On 9/2/22 16:40, Sergei Antonov wrote: > Get rid of discrepancy beween comment /* 250 ms */ and code > which shifts by 4 thus dividing by 16. > So change code to shift by 2 and make the timeout value 250 ms. > > Signed-off-by: Sergei Antonov > Reviewed-by: Rick Chen > Reviewed-by: Jaehoon Chung Applied to u-boot-mmc. Thanks! Best Regards, Jaehoon Chung > --- > drivers/mmc/ftsdc010_mci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/ftsdc010_mci.c b/drivers/mmc/ftsdc010_mci.c > index 570d54cf9d8f..cabb747fbbdb 100644 > --- a/drivers/mmc/ftsdc010_mci.c > +++ b/drivers/mmc/ftsdc010_mci.c > @@ -30,7 +30,7 @@ > #include > #include > > -#define CFG_CMD_TIMEOUT (CONFIG_SYS_HZ >> 4) /* 250 ms */ > +#define CFG_CMD_TIMEOUT (CONFIG_SYS_HZ >> 2) /* 250 ms */ > #define CFG_RST_TIMEOUT CONFIG_SYS_HZ /* 1 sec reset timeout */ > > #if CONFIG_IS_ENABLED(OF_PLATDATA)
RE: [PATCH] drivers: mmc: check the return value of mmc_send_if_cond() call
Hi Matt,
After applied this patch, CI Test is failed.
Test for Nokia RX-51 (aka N900)
I will not apply this patch at this time until fixing CI fail issue.
Best Regards,
Jaehoon Chung
> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of 정재훈
> Sent: Friday, October 21, 2022 6:08 PM
> To: 'Matt Ranostay' ; peng@nxp.com
> Cc: u-boot@lists.denx.de
> Subject: RE: [PATCH] drivers: mmc: check the return value of
> mmc_send_if_cond() call
>
>
> > -Original Message-
> > From: Matt Ranostay [mailto:mranos...@ti.com]
> > Sent: Friday, October 21, 2022 4:16 PM
> > To: peng@nxp.com; jh80.ch...@samsung.com
> > Cc: u-boot@lists.denx.de; Matt Ranostay
> > Subject: [PATCH] drivers: mmc: check the return value of mmc_send_if_cond()
> > call
> >
> > Return value from mmc_send_if_cond() isn't checked if it is a error state
> > and the result immediately is overwritten with the sd_send_op_cond() call.
> >
> > Add check for -EOPNOTSUPP to fail early, and trigger a retry for any other
> > error code.
> >
> > Fixes: afd5932b2c27 ("Revert "mmc: retry the cmd8 to meet 74 clocks
> > requirement in the spec")
> > Signed-off-by: Matt Ranostay
>
> Reviewed-by: Jaehoon Chung
>
> Best Regards,
> Jaehoon Chung
>
> > ---
> > drivers/mmc/mmc.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index 0b7c0be8cbc..e26a457a74c 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -2862,6 +2862,13 @@ retry:
> >
> > /* Test for SD version 2 */
> > err = mmc_send_if_cond(mmc);
> > + if (err == -EOPNOTSUPP)
> > + return err;
> > +
> > + if (err) {
> > + mmc_power_cycle(mmc);
> > + goto retry;
> > + }
> >
> > /* Now try to get the SD card's operating condition */
> > err = sd_send_op_cond(mmc, uhs_en);
> > --
> > 2.38.GIT
>
[PATCH] tools: env: fw_env: Fix unused-result warning
Fix unused-result warning about fread.
tools/env/fw_env.c: In function ‘find_nvmem_device’:
tools/env/fw_env.c:1751:3: warning: ignoring return value of ‘fread’, declared
with attribute warn_unused_result [-Wunused-result]
1751 | fread(buf, sizeof(buf), 1, fp);
| ^~
Signed-off-by: Jaehoon Chung
---
tools/env/fw_env.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index c251e2e6ba7d..c9a8774acefb 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -1733,6 +1733,7 @@ static int find_nvmem_device(void)
while (!nvmem && (dent = readdir(dir))) {
FILE *fp;
+ size_t size;
if (!strcmp(dent->d_name, ".") || !strcmp(dent->d_name, "..")) {
continue;
@@ -1748,7 +1749,14 @@ static int find_nvmem_device(void)
continue;
}
- fread(buf, sizeof(buf), 1, fp);
+ size = fread(buf, sizeof(buf), 1, fp);
+ if (size != 1) {
+ fprintf(stderr,
+ "read failed about %s\n", comp);
+ fclose(fp);
+ return -EIO;
+ }
+
if (!strcmp(buf, "u-boot,env")) {
bytes = asprintf(, "%s/%s/nvmem", path,
dent->d_name);
--
2.25.1
Re: [PATCH 1/3] mmc: zynq_sdhci: Change node_id prototype to u32
On 9/30/22 18:25, Ashok Reddy Soma wrote:
> In Versal platform power domain node_id is bigger than u8, hence
> change prototype to u32 to accommodate. Change u8 to u32 in the function
> prototypes that use node_id and remove casting to u32 from
> xilinx_pm_request() call parameters.
>
> Signed-off-by: Ashok Reddy Soma
> ---
>
> drivers/mmc/zynq_sdhci.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
> index 8f4071c8c2..3a4194452c 100644
> --- a/drivers/mmc/zynq_sdhci.c
> +++ b/drivers/mmc/zynq_sdhci.c
> @@ -111,7 +111,7 @@ static const u8 mode2timing[] = {
> [MMC_HS_200] = MMC_TIMING_MMC_HS200,
> };
>
> -static inline int arasan_zynqmp_set_in_tapdelay(u8 node_id, u32 itap_delay)
> +static inline int arasan_zynqmp_set_in_tapdelay(u32 node_id, u32 itap_delay)
Is it passed by u8 from sdhci_zynqmp_sampleclk_set_pahse()?
Best Regards,
Jaehoon Chung
> {
> int ret;
>
> @@ -155,7 +155,7 @@ static inline int arasan_zynqmp_set_in_tapdelay(u8
> node_id, u32 itap_delay)
> if (ret)
> return ret;
> } else {
> - return xilinx_pm_request(PM_IOCTL, (u32)node_id,
> + return xilinx_pm_request(PM_IOCTL, node_id,
>IOCTL_SET_SD_TAPDELAY,
>PM_TAPDELAY_INPUT, itap_delay, NULL);
> }
> @@ -163,7 +163,7 @@ static inline int arasan_zynqmp_set_in_tapdelay(u8
> node_id, u32 itap_delay)
> return 0;
> }
>
> -static inline int arasan_zynqmp_set_out_tapdelay(u8 node_id, u32 otap_delay)
> +static inline int arasan_zynqmp_set_out_tapdelay(u32 node_id, u32 otap_delay)
> {
> if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
> if (node_id == NODE_SD_0)
> @@ -174,13 +174,13 @@ static inline int arasan_zynqmp_set_out_tapdelay(u8
> node_id, u32 otap_delay)
> return zynqmp_mmio_write(SD_OTAP_DLY, SD1_OTAPDLYSEL_MASK,
>(otap_delay << 16));
> } else {
> - return xilinx_pm_request(PM_IOCTL, (u32)node_id,
> + return xilinx_pm_request(PM_IOCTL, node_id,
>IOCTL_SET_SD_TAPDELAY,
>PM_TAPDELAY_OUTPUT, otap_delay, NULL);
> }
> }
>
> -static inline int zynqmp_dll_reset(u8 node_id, u32 type)
> +static inline int zynqmp_dll_reset(u32 node_id, u32 type)
> {
> if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
> if (node_id == NODE_SD_0)
> @@ -192,12 +192,12 @@ static inline int zynqmp_dll_reset(u8 node_id, u32 type)
>type == PM_DLL_RESET_ASSERT ?
>SD1_DLL_RST : 0);
> } else {
> - return xilinx_pm_request(PM_IOCTL, (u32)node_id,
> + return xilinx_pm_request(PM_IOCTL, node_id,
>IOCTL_SD_DLL_RESET, type, 0, NULL);
> }
> }
>
> -static int arasan_zynqmp_dll_reset(struct sdhci_host *host, u8 node_id)
> +static int arasan_zynqmp_dll_reset(struct sdhci_host *host, u32 node_id)
> {
> struct mmc *mmc = (struct mmc *)host->mmc;
> struct udevice *dev = mmc->dev;
Re: [PATCH] mmc: Fix static checker warnings
On 9/29/22 13:52, Venkatesh Yadav Abbarapu wrote: > Correct pointer dereferencing check to be more consistent. > > Eliminate the below smatch warning: > drivers/mmc/mmc.c:3118 mmc_init_device() > warn: variable dereferenced before check 'm' (see line 3116) > > Signed-off-by: Venkatesh Yadav Abbarapu Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > > drivers/mmc/mmc.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c > index 0b7c0be8cb..210703ea46 100644 > --- a/drivers/mmc/mmc.c > +++ b/drivers/mmc/mmc.c > @@ -3113,10 +3113,12 @@ int mmc_init_device(int num) > } > > m = mmc_get_mmc_dev(dev); > - m->user_speed_mode = MMC_MODES_END; /* Initialising user set speed mode > */ > - > if (!m) > return 0; > + > + /* Initialising user set speed mode */ > + m->user_speed_mode = MMC_MODES_END; > + > if (m->preinit) > mmc_start_init(m); >
Re: [PATCH] power: fan53555: Fix missing newline in error message
On 9/25/22 22:43, Michal Suchanek wrote:
> Avoid concatenation with following message.
>
> Signed-off-by: Michal Suchanek
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> drivers/power/pmic/fan53555.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/pmic/fan53555.c b/drivers/power/pmic/fan53555.c
> index 4d1e686d27..0d91628f57 100644
> --- a/drivers/power/pmic/fan53555.c
> +++ b/drivers/power/pmic/fan53555.c
> @@ -23,7 +23,7 @@ static int pmic_fan53555_read(struct udevice *dev, uint reg,
> u8 *buff, int len)
> {
> if (dm_i2c_read(dev, reg, buff, len)) {
> - pr_err("%s: read error for register: %#x!", dev->name, reg);
> + pr_err("%s: read error for register: %#x!\n", dev->name, reg);
> return -EIO;
> }
>
Re: [PATCH] mmc: fsl_esdhc: fix problem when using clk driver
On 9/24/22 07:29, Marek Vasut wrote:
> From: Ye Li
>
> Move init_clk_usdhc to non-clk driver case, since assigned-clocks properties
> will initialize the clocks by clk driver.
>
> Signed-off-by: Ye Li
> Signed-off-by: Marek Vasut
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> NOTE: Was MLK-21848-5 fsl_esdhc: fix problem when using clk driver
> NOTE: Fixes SD SDR104 mode instability on MX8MP
> ---
> Cc: Fabio Estevam
> Cc: Jaehoon Chung
> Cc: Marcel Ziswiler
> Cc: Max Krummenacher
> Cc: Peng Fan
> Cc: Stefano Babic
> ---
> drivers/mmc/fsl_esdhc_imx.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
> index 9befb190bdf..92b152fc979 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -1519,8 +1519,6 @@ static int fsl_esdhc_probe(struct udevice *dev)
>* work as expected.
>*/
>
> - init_clk_usdhc(dev_seq(dev));
> -
> #if CONFIG_IS_ENABLED(CLK)
> /* Assigned clock already set clock */
> ret = clk_get_by_name(dev, "per", >per_clk);
> @@ -1536,6 +1534,8 @@ static int fsl_esdhc_probe(struct udevice *dev)
>
> priv->sdhc_clk = clk_get_rate(>per_clk);
> #else
> + init_clk_usdhc(dev_seq(dev));
> +
> priv->sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK + dev_seq(dev));
> if (priv->sdhc_clk <= 0) {
> dev_err(dev, "Unable to get clk for %s\n", dev->name);
Re: [PATCH] bootcount: pmic: Correct misleading comment
On 9/19/22 17:11, Philip Oberfichtner wrote: > Fix a copy-paste error I did when inserting the comment. > > Signed-off-by: Philip Oberfichtner Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > > --- > > drivers/bootcount/Kconfig | 2 +- > drivers/bootcount/pmic_pfuze100.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig > index e918f74694..8d6424c9da 100644 > --- a/drivers/bootcount/Kconfig > +++ b/drivers/bootcount/Kconfig > @@ -132,7 +132,7 @@ config DM_BOOTCOUNT_PMIC_PFUZE100 > depends on DM_PMIC_PFUZE100 > help > Enable support for the bootcounter using PMIC PFUZE100 registers. > - This works only, if the PMIC is not connected. > + This works only, if the PMIC is not connected to a battery. > > config DM_BOOTCOUNT_SPI_FLASH > bool "Support SPI flash devices as a backing store for bootcount" > diff --git a/drivers/bootcount/pmic_pfuze100.c > b/drivers/bootcount/pmic_pfuze100.c > index ad3bc03829..df046f1b0a 100644 > --- a/drivers/bootcount/pmic_pfuze100.c > +++ b/drivers/bootcount/pmic_pfuze100.c > @@ -5,7 +5,7 @@ > * Philip Oberfichtner > * > * A bootcount driver using the registers MEMA - MEMD on the PFUZE100. > - * This works only, if the PMIC is not connected. > + * This works only, if the PMIC is not connected to a battery. > */ > > #include
Re: [PATCH v3 4/5] drivers: power: pmic: Enable use of rn5t567 PMIC in SPL
On 9/16/22 19:24, Martyn Welch wrote: > The support added later in this series tweaks the PMIC voltages in the > SPL. Enable support for the rn5t567 in SPL builds to allow this to be done > cleanly. > > Signed-off-by: Martyn Welch Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > > Changes in v3: > - New patch (replaces addition of legacy support for rn5t567) > > drivers/power/pmic/Kconfig | 8 > drivers/power/pmic/Makefile | 2 +- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig > index 66b16b06e0..8e10ecae2e 100644 > --- a/drivers/power/pmic/Kconfig > +++ b/drivers/power/pmic/Kconfig > @@ -300,6 +300,14 @@ config PMIC_RN5T567 > regulators Real-Time Clock and 4 GPIOs. This driver provides > register access only. > > +config SPL_PMIC_RN5T567 > + bool "Enable driver for Ricoh RN5T567 PMIC in SPL" > + depends on SPL_DM_PMIC > + ---help--- > + The RN5T567 is a PMIC with 4 step-down DC/DC converters, 5 LDO > + regulators Real-Time Clock and 4 GPIOs. This driver provides > + register access only. > + > config PMIC_TPS65090 > bool "Enable driver for Texas Instruments TPS65090 PMIC" > ---help--- > diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile > index f73b326255..ae34e6b33e 100644 > --- a/drivers/power/pmic/Makefile > +++ b/drivers/power/pmic/Makefile > @@ -22,7 +22,7 @@ obj-$(CONFIG_$(SPL_)PMIC_AXP) += axp.o > obj-$(CONFIG_PMIC_MAX8997) += max8997.o > obj-$(CONFIG_PMIC_PM8916) += pm8916.o > obj-$(CONFIG_$(SPL_TPL_)PMIC_RK8XX) += rk8xx.o > -obj-$(CONFIG_PMIC_RN5T567) += rn5t567.o > +obj-$(CONFIG_$(SPL_)PMIC_RN5T567) += rn5t567.o > obj-$(CONFIG_PMIC_TPS65090) += tps65090.o > obj-$(CONFIG_PMIC_S5M8767) += s5m8767.o > obj-$(CONFIG_DM_PMIC_TPS65910) += pmic_tps65910_dm.o
