RE: [PATCH 42/81] mmc: Remove and add needed includes
> -Original Message- > From: Tom Rini > Sent: Thursday, May 2, 2024 10:31 AM > To: u-boot@lists.denx.de > Cc: Peng Fan ; Jaehoon Chung ; Ryan > Chen > ; Chia-Wei Wang ; > Aspeed BMC SW team s...@aspeedtech.com>; Joel Stanley ; Matthias Brugger > ; Peter > Robinson ; Thomas Fitzsimmons ; > Alex Nemirovsky > ; Masahisa Kojima > ; Neil Armstrong > ; Simon Glass ; Caleb Connolly > ; Sumit Garg ; Ryder Lee > ; > Weijie Gao ; Chunfeng Yun > ; GSS_MTK_Uboot_upstream > ; Tianrui Wei ; > Philipp Tomsich > ; Kever Yang ; Nobuhiro > Iwamatsu > ; Marek Vasut ; > Eugeniy Paltsev > ; Patrice Chotard > ; Patrick Delaunay > ; Thierry Reding ; > Svyatoslav Ryhel > ; Kunihiko Hayashi ; Dai > Okamura > ; Stefan Roese ; Michal Simek > > Subject: [PATCH 42/81] mmc: Remove and add needed includes > > Remove from this driver directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > Cc: Peng Fan > Cc: Jaehoon Chung > Cc: Tom Rini > Cc: Ryan Chen > Cc: Chia-Wei Wang > Cc: Aspeed BMC SW team > Cc: Joel Stanley > Cc: Matthias Brugger > Cc: Peter Robinson > Cc: Thomas Fitzsimmons > Cc: Alex Nemirovsky > Cc: Masahisa Kojima > Cc: Neil Armstrong > Cc: Simon Glass > Cc: Caleb Connolly > Cc: Sumit Garg > Cc: Ryder Lee > Cc: Weijie Gao > Cc: Chunfeng Yun > Cc: GSS_MTK_Uboot_upstream > Cc: Tianrui Wei > Cc: Philipp Tomsich > Cc: Kever Yang > Cc: Nobuhiro Iwamatsu > Cc: Marek Vasut > Cc: Eugeniy Paltsev > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: Thierry Reding > Cc: Svyatoslav Ryhel > Cc: Kunihiko Hayashi > Cc: Dai Okamura > Cc: Stefan Roese > Cc: Michal Simek > --- > drivers/mmc/am654_sdhci.c | 1 - > drivers/mmc/arm_pl180_mmci.c | 1 - > drivers/mmc/aspeed_sdhci.c| 1 - > drivers/mmc/atmel_sdhci.c | 1 - > drivers/mmc/bcm2835_sdhci.c | 1 - > drivers/mmc/bcm2835_sdhost.c | 1 - > drivers/mmc/bcmstb_sdhci.c| 1 - > drivers/mmc/ca_dw_mmc.c | 1 - > drivers/mmc/davinci_mmc.c | 1 - > drivers/mmc/dw_mmc.c | 1 - > drivers/mmc/exynos_dw_mmc.c | 1 - > drivers/mmc/f_sdh30.c | 1 - > drivers/mmc/fsl_esdhc.c | 1 - > drivers/mmc/fsl_esdhc_imx.c | 1 - > drivers/mmc/fsl_esdhc_spl.c | 2 +- > drivers/mmc/ftsdc010_mci.c| 1 - > drivers/mmc/gen_atmel_mci.c | 2 +- > drivers/mmc/hi6220_dw_mmc.c | 1 - > drivers/mmc/iproc_sdhci.c | 1 - > drivers/mmc/jz_mmc.c | 1 - > drivers/mmc/kona_sdhci.c | 1 - > drivers/mmc/meson_gx_mmc.c| 1 - > drivers/mmc/mmc-pwrseq.c | 1 - > drivers/mmc/mmc-uclass.c | 1 - > drivers/mmc/mmc.c | 3 ++- > drivers/mmc/mmc_boot.c| 1 - > drivers/mmc/mmc_bootdev.c | 1 - > drivers/mmc/mmc_legacy.c | 1 - > drivers/mmc/mmc_spi.c | 1 - > drivers/mmc/mmc_write.c | 1 - > drivers/mmc/msm_sdhci.c | 1 - > drivers/mmc/mtk-sd.c | 1 - > drivers/mmc/mv_sdhci.c| 1 - > drivers/mmc/mvebu_mmc.c | 1 - > drivers/mmc/mxcmmc.c | 1 - > drivers/mmc/mxsmmc.c | 1 - > drivers/mmc/nexell_dw_mmc.c | 1 - > drivers/mmc/npcm_sdhci.c | 1 - > drivers/mmc/omap_hsmmc.c | 1 - > drivers/mmc/owl_mmc.c | 1 - > drivers/mmc/pci_mmc.c | 1 - > drivers/mmc/piton_mmc.c | 1 - > drivers/mmc/rockchip_dw_mmc.c | 1 - > drivers/mmc/rockchip_sdhci.c | 1 - > drivers/mmc/rpmb.c| 1 - > drivers/mmc/s5p_sdhci.c | 1 - > drivers/mmc/sandbox_mmc.c | 1 - > drivers/mmc/sdhci-adma.c | 1 - > drivers/mmc/sdhci-cadence.c | 1 - > drivers/mmc/sdhci.c | 2 +- > drivers/mmc/sh_mmcif.c| 1 - > drivers/mmc/snps_dw_mmc.c | 1 - > drivers/mmc/socfpga_dw_mmc.c | 1 - > drivers/mmc/sti_sdhci.c | 1 - > drivers/mmc/stm32_sdmmc2.c| 1 - > drivers/mmc/sunxi_mmc.c | 1 - > drivers/mmc/tangier_sdhci.c | 1 - > drivers/mmc/tegra_mmc.c | 1 - > drivers/mmc/tmio-common.c | 1 - > drivers/mmc/uniphier-sd.c | 1 - > drivers/mmc/xenon_sdhci.c | 1 - > drivers/mmc/zynq_sdhci.c | 1 - > 62 files changed, 5 insertions(+), 62 deletions(-) > > diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c > index ffb461c2f6c1..48fac7a11b48 100644 > --- a/drivers/mmc/am654_sdhci.c > +++ b/drivers/mmc/am654_sdhci.c > @@ -6,7 +6,6 @@ > */ > > #include > -#include > #include > #include > #include > diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mm
RE: [PATCH 01/81] mmc: Migrate MMC_SUPPORTS_TUNING to Kconfig
> -Original Message- > From: Tom Rini > Sent: Thursday, May 2, 2024 10:30 AM > To: u-boot@lists.denx.de > Cc: Weijie Gao ; GSS_MTK_Uboot_upstream > ; > Peng Fan ; Jaehoon Chung > Subject: [PATCH 01/81] mmc: Migrate MMC_SUPPORTS_TUNING to Kconfig > > The constraints on the MMC_SUPPORTS_TUNING symbol can easily be > expressed in Kconfig (with the addition of SPL_MMC_SUPPORTS_TUNING). > Furthermore, in order to remove from the MMC subsystem, the > way this symbol is used today needs to be changed in order to continue > functioning. > > Signed-off-by: Tom Rini Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > Cc: Weijie Gao > Cc: GSS_MTK_Uboot_upstream > Cc: Peng Fan > Cc: Jaehoon Chung > --- > arch/arm/mach-mediatek/Kconfig | 1 + > arch/mips/mach-mtmips/Kconfig | 1 + > drivers/mmc/Kconfig| 11 +++ > drivers/mmc/am654_sdhci.c | 6 +++--- > drivers/mmc/fsl_esdhc.c| 4 ++-- > drivers/mmc/fsl_esdhc_imx.c| 8 > drivers/mmc/mmc-uclass.c | 2 +- > drivers/mmc/mmc.c | 12 ++-- > drivers/mmc/mtk-sd.c | 4 ++-- > drivers/mmc/octeontx_hsmmc.c | 12 ++-- > drivers/mmc/omap_hsmmc.c | 4 ++-- > drivers/mmc/sdhci-cadence.c| 2 +- > drivers/mmc/sdhci.c| 4 ++-- > include/configs/mt7621.h | 3 --- > include/configs/mt7623.h | 3 --- > include/configs/octeontx2_common.h | 5 - > include/mmc.h | 9 + > 17 files changed, 43 insertions(+), 48 deletions(-) > > diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig > index 82018bd9d3e3..ff1fdee5c8da 100644 > --- a/arch/arm/mach-mediatek/Kconfig > +++ b/arch/arm/mach-mediatek/Kconfig > @@ -23,6 +23,7 @@ config TARGET_MT7622 > config TARGET_MT7623 > bool "MediaTek MT7623 SoC" > select CPU_V7A > + select MMC_SUPPORTS_TUNING > help > The MediaTek MT7623 is a ARM-based SoC with a quad-core Cortex-A7 > including NEON and GPU, Mali-450 graphics, several DDR3 options, > diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig > index 15b2792e619b..3fcd0b8465b4 100644 > --- a/arch/mips/mach-mtmips/Kconfig > +++ b/arch/mips/mach-mtmips/Kconfig > @@ -80,6 +80,7 @@ config SOC_MT7621 > bool "MT7621" > select MIPS_CM > select MIPS_L2_CACHE > + select MMC_SUPPORTS_TUNING > select SYS_CACHE_SHIFT_5 > select SYS_MIPS_CACHE_INIT_RAM_LOAD > select PINCTRL_MT7621 > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig > index 549634891a36..d0944793c92d 100644 > --- a/drivers/mmc/Kconfig > +++ b/drivers/mmc/Kconfig > @@ -147,9 +147,16 @@ config SPL_MMC_IO_VOLTAGE > support. For eMMC this not mandatory, but not enabling this option may > prevent the driver of using the faster modes. > > +config MMC_SUPPORTS_TUNING > + bool > + > +config SPL_MMC_SUPPORTS_TUNING > + bool > + > config MMC_UHS_SUPPORT > bool "enable UHS support" > depends on MMC_IO_VOLTAGE > + select MMC_SUPPORTS_TUNING > help > The Ultra High Speed (UHS) bus is available on some SDHC and SDXC > cards. The IO voltage must be switchable from 3.3v to 1.8v. The bus > @@ -158,6 +165,7 @@ config MMC_UHS_SUPPORT > config SPL_MMC_UHS_SUPPORT > bool "enable UHS support in SPL" > depends on SPL_MMC_IO_VOLTAGE > + select SPL_MMC_SUPPORTS_TUNING > help > The Ultra High Speed (UHS) bus is available on some SDHC and SDXC > cards. The IO voltage must be switchable from 3.3v to 1.8v. The bus > @@ -193,6 +201,7 @@ config SPL_MMC_HS400_SUPPORT > > config MMC_HS200_SUPPORT > bool "enable HS200 support" > + select MMC_SUPPORTS_TUNING > help > The HS200 mode is support by some eMMC. The bus frequency is up to > 200MHz. This mode requires tuning the IO. > @@ -200,6 +209,7 @@ config MMC_HS200_SUPPORT > config SPL_MMC_HS200_SUPPORT > bool "enable HS200 support in SPL" > depends on SPL_MMC > + select SPL_MMC_SUPPORTS_TUNING > help > The HS200 mode is support by some eMMC. The bus frequency is up to > 200MHz. This mode requires tuning the IO. > @@ -347,6 +357,7 @@ config MMC_OCTEONTX > bool "Marvell Octeon Multimedia Card Interface support" > depends on (ARCH_OCTEON || ARCH_OCTEONTX || ARCH_OCTEONTX2) > depends on DM_MMC > + select MMC_SUPPORTS_TUNING if ARCH_OCTEONTX2 &
RE: [PATCH v4] mmc: Poll CD in case cyclic framework is enabled
> -Original Message- > From: Marek Vasut > Sent: Friday, April 26, 2024 8:41 PM > To: Jaehoon Chung ; u-boot@lists.denx.de > Cc: 'Peng Fan' ; 'Simon Glass' > Subject: Re: [PATCH v4] mmc: Poll CD in case cyclic framework is enabled > > On 4/26/24 8:27 AM, Jaehoon Chung wrote: > > Dear Marek, > > > >> -Original Message- > >> From: Marek Vasut > >> Sent: Wednesday, April 24, 2024 8:18 AM > >> To: u-boot@lists.denx.de; Jaehoon Chung > >> Cc: Peng Fan ; Simon Glass > >> Subject: Re: [PATCH v4] mmc: Poll CD in case cyclic framework is enabled > >> > >> On 3/16/24 9:13 PM, Marek Vasut wrote: > >>> In case the cyclic framework is enabled, poll the card detect of already > >>> initialized cards and deinitialize them in case they are removed. Since > >>> the card initialization is a longer process and card initialization is > >>> done on first access to an uninitialized card anyway, avoid initializing > >>> newly detected uninitialized cards in the cyclic callback. > >> > >> Any input on this ? > > > > When I have applied your patch from patchwork, it didn't apply directly. > > If you're ok, I will apply after touch your patch. Is it ok? > > Sure. After touching your patch, I will inform again to you. Best Regards, Jaehoon Chung
RE: [GIT PULL] Please pull u-boot-mmc master
Dear Judith, > -Original Message- > From: Judith Mendez > Sent: Tuesday, April 30, 2024 5:40 AM > To: Tom Rini ; Jaehoon Chung > Cc: U-Boot Mailing List ; > maximilian.br...@9elements.com; > curtis.mach...@intel.com; Jonas Karlman ; > greg.mal...@timesys.com; > ian.robe...@timesys.com; Jae hoon Chung ; Peng Fan > ; > sheng@9elements.com > Subject: Re: [GIT PULL] Please pull u-boot-mmc master > > Hi all, > > On 4/26/24 10:51 AM, Tom Rini wrote: > > On Fri, Apr 26, 2024 at 07:38:30PM +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 > >> > >> Best Regards, > >> Jaehoon Chung > >> > >> CI: > >> https://protect2.fireeye.com/v1/url?k=aa60f1d5-cbebe4f5-aa617a9a-74fe485fb347- > 9095c5a77eabfca7=1=d67a142c-0b69-4de3-be99-de9292c603f2=https%3A%2F%2Fsource.denx.de%2Fu- > boot%2Fcustodians%2Fu-boot-mmc%2F-%2Fpipelines%2F20547 > >> > >> The following changes since commit > >> d097f9e1299a3bdb7de468f0d9bbc63932f461cd: > >> > >>Merge tag 'fsl-qoriq-2024-4-24' of > >> https://protect2.fireeye.com/v1/url?k=93e2c287-f269d7a7- > 93e349c8-74fe485fb347-247fe01368500b3b=1=d67a142c-0b69-4de3-be99- > de9292c603f2=https%3A%2F%2Fsource.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-fsl-qoriq > (2024-04-23 > 17:53:06 -0600) > >> > >> 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 1776213dadef4b578f98bcf18beb152f8975a8bf: > >> > >>mmc: arm_pl180: Limit data transfer to U16_MAX (2024-04-26 15:32:06 > >> +0900) > >> > > > > Applied to u-boot/master, thanks! > > > > > A patch in this series caused a regression for AM62x SK with the > following error: > > Error reading cluster > spl_load_image_fat: error reading image u-boot.img, err - -22 > SPL: failed to boot from all boot devices (err=-6) > ### ERROR ### Please RESET the board ### > > Git bisect showed "mmc: sdhci: introduce adma_write_desc() hook to > struct sdhci_ops" to be the offending commit. > > Could someone point me to the next steps to fix this issue? I will check this problem. Thanks for pointing out. Best Regards, Jaehoon Chung > > regards, > Judith
[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/20569 The following changes since commit 174ac987655c888017c82df1883c0c2ea0dc2495: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-mmc (2024-04-26 07:39:18 -0600) 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 17fd67aedde714556895a0d39431f482accd0cc3: power: pmic: tps65941: Update compatible to aling with kernel DT (2024-04-29 09:20:51 +0900) Bhargav Raviprakash (5): power: tps65941: Add macros of TPS65224 PMIC power: pmic: tps65941: Add TI TPS65224 PMIC power: regulator: tps65941: Added macros for BUCK ID power: regulator: tps65941: use function callbacks for conversion ops power: regulator: tps65941: Add TPS65224 PMIC regulator support Udit Kumar (1): power: pmic: tps65941: Update compatible to aling with kernel DT drivers/power/pmic/tps65941.c| 4 + drivers/power/regulator/tps65941_regulator.c | 381 --- include/power/tps65941.h | 30 +++ 3 files changed, 384 insertions(+), 31 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 Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/20547 The following changes since commit d097f9e1299a3bdb7de468f0d9bbc63932f461cd: Merge tag 'fsl-qoriq-2024-4-24' of https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq (2024-04-23 17:53:06 -0600) 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 1776213dadef4b578f98bcf18beb152f8975a8bf: mmc: arm_pl180: Limit data transfer to U16_MAX (2024-04-26 15:32:06 +0900) Greg Malysa (1): mmc: Support 32-bit only ADMA on 64-bit platforms Ian Roberts (2): mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops mmc: sdhci: Fix potential ADMA descriptor table overflow Jonas Karlman (2): mmc: Imply HS200 cap with mmc-hs400 prop to match linux mmc: Add support for the no-mmc-hs400 prop Maximilian Brune (1): mmc: arm_pl180: Limit data transfer to U16_MAX cmachida (1): mmc: sdhci: programmable clock calculation needs multiplier +1 drivers/mmc/Kconfig | 18 ++ drivers/mmc/arm_pl180_mmci.c | 10 ++ drivers/mmc/fsl_esdhc.c | 2 +- drivers/mmc/mmc-uclass.c | 7 +-- drivers/mmc/sdhci-adma.c | 43 +-- drivers/mmc/sdhci.c | 26 ++ include/sdhci.h | 21 +++-- 7 files changed, 96 insertions(+), 31 deletions(-)
RE: [PATCH] power: pmic: tps65941: Update compatible to aling with kernel DT
> -Original Message-
> From: Udit Kumar
> Sent: Friday, April 19, 2024 3:00 PM
> To: n-fran...@ti.com; jh80.ch...@samsung.com; j-keer...@ti.com
> Cc: n...@ti.com; tr...@konsulko.com; s...@chromium.org; u-boot@lists.denx.de;
> Udit Kumar kum...@ti.com>
> Subject: [PATCH] power: pmic: tps65941: Update compatible to aling with
> kernel DT
>
> Linux kernel driver drivers/mfd/tps6594-i2c.c is using different
> name for compatible for tps6594 family PMIC.
> After sync of Linux kernel DT to u-boot for TI platforms
> J7200, J721S2 and J784S4 PMIC is no longer getting probed.
>
> So updating compatible field to align with Linux driver and DT.
>
> Signed-off-by: Udit Kumar
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/power/pmic/tps65941.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/power/pmic/tps65941.c b/drivers/power/pmic/tps65941.c
> index 727b42747a..bf762deb29 100644
> --- a/drivers/power/pmic/tps65941.c
> +++ b/drivers/power/pmic/tps65941.c
> @@ -75,6 +75,9 @@ static const struct udevice_id tps65941_ids[] = {
> { .compatible = "ti,tps659412", .data = TPS659411 },
> { .compatible = "ti,tps659413", .data = TPS659413 },
> { .compatible = "ti,lp876441", .data = LP876441 },
> + { .compatible = "ti,tps6594-q1", .data = TPS659411 },
> + { .compatible = "ti,tps6593-q1", .data = TPS659413 },
> + { .compatible = "ti,lp8764-q1", .data = LP876441 },
> { }
> };
>
> --
> 2.34.1
RE: [PATCH v4 5/5] power: regulator: tps65941: Add TPS65224 PMIC regulator support
> -Original Message-
> From: Bhargav Raviprakash
> Sent: Monday, April 22, 2024 6:49 PM
> To: u-boot@lists.denx.de
> Cc: d-g...@ti.com; dan.carpen...@linaro.org; jh80.ch...@samsung.com;
> s...@chromium.org;
> tr...@konsulko.com; m.nirmalad...@ltts.com; Bhargav Raviprakash
>
> Subject: [PATCH v4 5/5] power: regulator: tps65941: Add TPS65224 PMIC
> regulator support
>
> Reuse TPS65941 regulator driver to adds support for
> TPS65224 PMIC's regulators. 4 BUCKs and 3 LDOs, where
> BUCK1 and BUCK2 can be configured in dual phase mode.
>
> Signed-off-by: Bhargav Raviprakash
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/power/regulator/tps65941_regulator.c | 280 ++-
> 1 file changed, 267 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/power/regulator/tps65941_regulator.c
> b/drivers/power/regulator/tps65941_regulator.c
> index d879c2301b..5809a53fa2 100644
> --- a/drivers/power/regulator/tps65941_regulator.c
> +++ b/drivers/power/regulator/tps65941_regulator.c
> @@ -37,6 +37,8 @@
>
> #define TPS65941_BUCK_CONV_OPS_IDX 0
> #define TPS65941_LDO_CONV_OPS_IDX 0
> +#define TPS65224_LDO_CONV_OPS_IDX 1
> +#define TPS65224_BUCK_CONV_OPS_IDX 1
>
> struct tps65941_reg_conv_ops {
> int volt_mask;
> @@ -55,6 +57,11 @@ static const char tps65941_ldo_ctrl[TPS65941_BUCK_NUM] =
> {0x1D, 0x1E, 0x1F,
> static const char tps65941_ldo_vout[TPS65941_BUCK_NUM] = {0x23, 0x24, 0x25,
> 0x26};
>
> +static inline int tps65941_get_chip_id(struct udevice *dev)
> +{
> + return dev->parent->driver_data;
> +}
> +
> static int tps65941_buck_enable(struct udevice *dev, int op, bool *enable)
> {
> int ret;
> @@ -146,6 +153,112 @@ int tps65941_lookup_slew(int id)
> }
> }
>
> +static int tps65224_buck_volt2val(int idx, int uV)
> +{
> + /* This functions maps a value which is in micro Volts to the VSET
> value.
> + * The mapping is as per the datasheet of TPS65224.
> + */
> +
> + if (uV > TPS65224_BUCK_VOLT_MAX)
> + return -EINVAL;
> +
> + if (idx > 0) {
> + /* Buck2, Buck3 and Buck4 of TPS65224 has a different schema in
> + * converting b/w micro_volt and VSET hex values
> + *
> + * VSET value starts from 0x00 for 0.5V, and for every increment
> + * in VSET value the output voltage increases by 25mV. This is
> upto
> + * 1.15V where VSET is 0x1A.
> + *
> + * For 0x1B the output voltage is 1.2V, and for every increment
> of
> + * VSET the output voltage increases by 50mV upto the max
> voltage of
> + * 3.3V
> + *
> + * | Voltage Ranges | VSET Ranges | Voltage Step |
> + * +-+--+--+
> + * | 0.5V to 1.50V | 0x00 to 0x1A | 25mV|
> + * | 1.2V to 3.3V| 0x1B to 0x45 | 50mV|
> + */
> + if (uV >= 120)
> + return (uV - 120) / 5 + 0x1B;
> + else if (uV >= 50)
> + return (uV - 50) / 25000;
> + else
> + return -EINVAL;
> + }
> +
> + /* Buck1 and Buck12(dual phase) has a different mapping b/w output
> + * voltage and VSET value.
> + *
> + * | Voltage Ranges | VSET Ranges | Voltage Step |
> + * +-+--+--+
> + * | 0.5V to 0.58V | 0xA to 0xE | 20mV|
> + * | 0.6V to 1.095V | 0xF to 0x72 | 5mV |
> + * | 1.1V to 1.65V | 0x73 to 0xAA | 10mV|
> + * | 1.6V to 3.3V| 0xAB to 0xFD | 20mV|
> + *
> + */
> + if (uV >= 166)
> + return (uV - 166) / 2 + 0xAB;
> + else if (uV >= 110)
> + return (uV - 110) / 1 + 0x73;
> + else if (uV >= 60)
> + return (uV - 60) / 5000 + 0x0F;
> + else if (uV >= 50)
> + return (uV - 50) / 2 + 0x0A;
> + else
> + return -EINVAL;
> +}
> +
> +static int tps65224_buck_val2volt(int idx, int val)
> +{
> + /* This function does the opposite to the tps65224_buck_volt2val
> function
> + * described above.
> + * This maps the VSET value to micro volts. Please refer to the ranges
> + * mentioned the comments of tps65224_buck_volt2val.
> + */
> +
> + if (idx > 0) {
> +
RE: [PATCH v4] mmc: Poll CD in case cyclic framework is enabled
Dear Marek, > -Original Message- > From: Marek Vasut > Sent: Wednesday, April 24, 2024 8:18 AM > To: u-boot@lists.denx.de; Jaehoon Chung > Cc: Peng Fan ; Simon Glass > Subject: Re: [PATCH v4] mmc: Poll CD in case cyclic framework is enabled > > On 3/16/24 9:13 PM, Marek Vasut wrote: > > In case the cyclic framework is enabled, poll the card detect of already > > initialized cards and deinitialize them in case they are removed. Since > > the card initialization is a longer process and card initialization is > > done on first access to an uninitialized card anyway, avoid initializing > > newly detected uninitialized cards in the cyclic callback. > > Any input on this ? When I have applied your patch from patchwork, it didn't apply directly. If you're ok, I will apply after touch your patch. Is it ok? Best Regards, Jaehoon Chung
RE: [PATCH] mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops
Hi,
> -Original Message-
> From: U-Boot On Behalf Of Jaehoon Chung
> Sent: Wednesday, April 17, 2024 9:26 AM
> To: 'Greg Malysa' ; u-boot@lists.denx.de; 'Peng Fan'
>
> Cc: 'Ian Roberts' ; 'Nathan Barrett-Morrison'
> ;
> 'Jonas Karlman' ; 'Kever Yang' ;
> 'Peter Geis'
> ; 'Sean Anderson' ; 'Simon
> Glass' ;
> 'Tom Rini'
> Subject: RE: [PATCH] mmc: sdhci: introduce adma_write_desc() hook to struct
> sdhci_ops
>
>
>
> > -Original Message-
> > From: Greg Malysa
> > Sent: Tuesday, March 26, 2024 11:18 AM
> > To: u-boot@lists.denx.de; Peng Fan ; Jaehoon Chung
> >
> > Cc: Ian Roberts ; Nathan Barrett-Morrison
> > ;
> Greg
> > Malysa ; Jonas Karlman ; Kever
> > Yang > chips.com>; Peter Geis ; Sean Anderson
> > ; Simon Glass
> > ; Tom Rini
> > Subject: [PATCH] mmc: sdhci: introduce adma_write_desc() hook to struct
> > sdhci_ops
> >
> > From: Ian Roberts
> >
> > Add this hook so that it can be overridden with driver specific
> > implementations. We also let the original sdhci_adma_write_desc()
> > accept so that the function can set its new value. Then export
> > the function so that it could be reused by driver's specific
> > implementations.
> >
> > The above is a port of Linux kernel commit 54552e4948cbf
> >
> > In addition, allow drivers to allocate their own ADMA descriptor
> > tables if additional space is required.
> >
> > Finally, fix the assignment of adma_addr to fix compiler warning
> > on 64-bit platforms that still use 32-bit DMA addressing.
> >
> > Co-developed-by: Nathan Barrett-Morrison
> > Signed-off-by: Nathan Barrett-Morrison
> > Signed-off-by: Greg Malysa
> > Signed-off-by: Ian Roberts
>
> Reviewed-by: Jaehoon Chung
Some target are failed to build. (e.g, j721e_beagleboneai64_r5)
+drivers/mmc/sdhci-adma.c: In function '__sdhci_adma_write_desc':
+drivers/mmc/sdhci-adma.c:37:43: error: 'const struct sdhci_ops' has no member
named 'adma_write_desc'
+ 37 | if (host && host->ops && host->ops->adma_write_desc)
+ | ^~
+drivers/mmc/sdhci-adma.c:38:26: error: 'const struct sdhci_ops' has no member
named 'adma_write_desc'
+ 38 | host->ops->adma_write_desc(host, desc, addr, len, end);
+ | ^~
+make[3]: *** [scripts/Makefile.build:257: drivers/mmc/sdhci-adma.o] Error 1
+make[2]: *** [scripts/Makefile.build:397: drivers/mmc] Error 2
Best Regards,
Jaehoon Chung
>
> Best Regards,
> Jaehoon Chung
>
> >
> > ---
> >
> >
> > ---
> > drivers/mmc/fsl_esdhc.c | 2 +-
> > drivers/mmc/sdhci-adma.c | 41 +++-
> > drivers/mmc/sdhci.c | 8 +---
> > include/sdhci.h | 12 ++--
> > 4 files changed, 44 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> > index d50669..bd0671cc52 100644
> > --- a/drivers/mmc/fsl_esdhc.c
> > +++ b/drivers/mmc/fsl_esdhc.c
> > @@ -252,7 +252,7 @@ static void esdhc_setup_dma(struct fsl_esdhc_priv
> > *priv, struct mmc_data *data)
> > priv->adma_desc_table) {
> > debug("Using ADMA2\n");
> > /* prefer ADMA2 if it is available */
> > - sdhci_prepare_adma_table(priv->adma_desc_table, data,
> > + sdhci_prepare_adma_table(NULL, priv->adma_desc_table, data,
> > priv->dma_addr);
> >
> > adma_addr = virt_to_phys(priv->adma_desc_table);
> > diff --git a/drivers/mmc/sdhci-adma.c b/drivers/mmc/sdhci-adma.c
> > index 8213223d3f..8c38448b6a 100644
> > --- a/drivers/mmc/sdhci-adma.c
> > +++ b/drivers/mmc/sdhci-adma.c
> > @@ -9,9 +9,10 @@
> > #include
> > #include
> >
> > -static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
> > - dma_addr_t addr, u16 len, bool end)
> > +void sdhci_adma_write_desc(struct sdhci_host *host, void **next_desc,
> > + dma_addr_t addr, int len, bool end)
> > {
> > + struct sdhci_adma_desc *desc = *next_desc;
> > u8 attr;
> >
> > attr = ADMA_DESC_ATTR_VALID | ADMA_DESC_TRANSFER_DATA;
> > @@ -19,17 +20,30 @@ static void sdhci_adma_desc(struct sdhci_adma_desc
> > *desc,
> > attr |= ADMA_DESC_ATTR_END;
> >
> > desc->attr = attr;
> > - desc->len = len;
> > + desc->len = len & 0x;
&g
Re: [RESEND PATCH v3 5/5] power: regulator: tps65941: Add TPS65224 PMIC regulator support
tatic const struct tps65941_reg_conv_ops ldo_conv_ops[] = {
> [TPS65941_LDO_CONV_OPS_IDX] = {
> .volt_mask = TPS65941_LDO_VOLT_MASK,
> .volt2val = tps65941_buck_volt2val,
> .val2volt = tps65941_ldo_val2volt,
> },
> + [TPS65224_LDO_CONV_OPS_IDX] = {
> + .volt_mask = TPS65224_LDO_VOLT_MASK,
> + .volt2val = tps65224_ldo_volt2val,
> + .val2volt = tps65224_ldo_val2volt,
> + },
> };
>
> static int tps65941_ldo_val(struct udevice *dev, int op, int *uV)
> {
> unsigned int hex, adr;
> - int ret, idx;
> + int ret, ret_volt, idx;
> struct dm_regulator_uclass_plat *uc_pdata;
> const struct tps65941_reg_conv_ops *conv_ops;
> + ulong chip_id;
>
> + chip_id = tps65941_get_chip_id(dev);
> idx = dev->driver_data;
> - conv_ops = _conv_ops[TPS65941_LDO_CONV_OPS_IDX];
> + if (chip_id == TPS65224) {
> + /* idx is the ldo id number as per devicetree node which will
> be same
> + * as the regulator name in the datasheet.
> + * The idx for ldo1, ldo2, ldo3 will be 1, 2 & 3 respectively.
> + * In the driver the numbering is from 0. Hence the -1.
> + */
> + idx = idx - 1;
> + conv_ops = _conv_ops[TPS65224_LDO_CONV_OPS_IDX];
> + } else {
> + conv_ops = _conv_ops[TPS65941_LDO_CONV_OPS_IDX];
> + }
> +
> uc_pdata = dev_get_uclass_plat(dev);
>
> if (op == PMIC_OP_GET)
> @@ -294,21 +504,36 @@ static int tps65941_ldo_val(struct udevice *dev, int
> op, int *uV)
> return ret;
>
> ret &= conv_ops->volt_mask;
> - ret = conv_ops->val2volt(idx, ret);
> - if (ret < 0)
> - return ret;
> + ret_volt = conv_ops->val2volt(idx, ret);
> + if (ret_volt < 0)
> + return ret_volt;
>
> if (op == PMIC_OP_GET) {
> - *uV = ret;
> + *uV = ret_volt;
> return 0;
> }
>
> + /* TPS65224 LDO1 in BYPASS mode only supports 2.2V min to 3.6V max */
> + if (chip_id == TPS65224 && idx == 0 && (ret &
> BIT(TPS65224_LDO_BYP_CONFIG)) &&
> + *uV < TPS65224_LDO1_VOLT_BYP_MIN)
> + return -EINVAL;
> +
> + /* TPS65224 LDO2 & LDO3 in BYPASS mode supports 1.5V min to 5.5V max */
> + if (chip_id == TPS65224 && idx > 0 && (ret &
> BIT(TPS65224_LDO_BYP_CONFIG)) &&
> + *uV < TPS65224_LDO23_VOLT_BYP_MIN)
> + return -EINVAL;
> +
> hex = conv_ops->volt2val(idx, *uV);
> if (hex < 0)
> return hex;
>
> - ret &= 0x0;
> - ret = hex;
> + if (chip_id == TPS65224) {
> + hex = hex << TPS65941_LDO_MODE_MASK;
> + ret &= ~TPS65224_LDO_VOLT_MASK;
> + ret |= hex;
> + } else {
> + ret = hex;
> + }
>
> ret = pmic_reg_write(dev->parent, adr, ret);
>
> @@ -319,6 +544,9 @@ static int tps65941_ldo_probe(struct udevice *dev)
> {
> struct dm_regulator_uclass_plat *uc_pdata;
> int idx;
> + ulong chip_id;
> +
> + chip_id = tps65941_get_chip_id(dev);
>
> uc_pdata = dev_get_uclass_plat(dev);
> uc_pdata->type = REGULATOR_TYPE_LDO;
> @@ -328,9 +556,16 @@ static int tps65941_ldo_probe(struct udevice *dev)
> case TPS65941_LDO_ID_1:
> case TPS65941_LDO_ID_2:
> case TPS65941_LDO_ID_3:
> - case TPS65941_LDO_ID_4:
> debug("Single phase regulator\n");
> break;
> + case TPS65941_LDO_ID_4:
> + if (chip_id != TPS65224) {
> + debug("Single phase regulator\n");
> + } else {
> + pr_err("Wrong ID for regulator\n");
> + return -EINVAL;
> + }
> + break;
Is it possible to use the below?
if (chip_id != TPS65224) {
debug("Single phase regulator\n");
break;
}
/* fallthrough */
Best Regards,
Jaehoon Chung
> default:
> pr_err("Wrong ID for regulator\n");
> return -EINVAL;
> @@ -346,6 +581,9 @@ static int tps65941_buck_probe(struct udevice *dev)
> {
> struct dm_regulator_uclass_plat *uc_pdata;
> int idx;
> + ulong chip_id;
> +
> + chip_id = tps65941_get_chip_id(dev);
>
> uc_pdata = dev_get_uclass_plat(dev);
> uc_pdata->type = REGULATOR_TYPE_BUCK;
> @@ -356,16 +594,35 @@ static int tps65941_buck_probe(struct udevice *dev)
> case TPS65941_BUCK_ID_2:
> case TPS65941_BUCK_ID_3:
> case TPS65941_BUCK_ID_4:
> - case TPS65941_BUCK_ID_5:
> debug("Single phase regulator\n");
> break;
> + case TPS65941_BUCK_ID_5:
> + if (chip_id != TPS65224) {
> + debug("Single phase regulator\n");
> + } else {
> + pr_err("Wrong ID for regulator\n");
> + return -EINVAL;
> + }
> + break;
> case TPS65941_BUCK_ID_12:
> + idx = 1;
> + break;
> case TPS65941_BUCK_ID_123:
> case TPS65941_BUCK_ID_1234:
> - idx = 1;
> + if (chip_id != TPS65224) {
> + idx = 1;
> + } else {
> + pr_err("Wrong ID for regulator\n");
> + return -EINVAL;
> + }
> break;
> case TPS65941_BUCK_ID_34:
> - idx = 3;
> + if (chip_id != TPS65224) {
> + idx = 3;
> + } else {
> + pr_err("Wrong ID for regulator\n");
> + return -EINVAL;
> + }
> break;
> default:
> pr_err("Wrong ID for regulator\n");
Re: [RESEND PATCH v3 3/5] power: regulator: tps65941: Added macros for BUCK ID
On 3/18/24 18:49, Bhargav Raviprakash wrote:
> Adds macros for buck and ldo ids and switched to using switch
> case instead of if else in probe functions. Helps in adding
> support for TPS65224 PMIC.
>
> Signed-off-by: Bhargav Raviprakash
> Reviewed-by: Dhruva Gole
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/power/regulator/tps65941_regulator.c | 54 +++-
> 1 file changed, 42 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/power/regulator/tps65941_regulator.c
> b/drivers/power/regulator/tps65941_regulator.c
> index b041126775..cf54e30df5 100644
> --- a/drivers/power/regulator/tps65941_regulator.c
> +++ b/drivers/power/regulator/tps65941_regulator.c
> @@ -16,6 +16,25 @@
> #include
> #include
>
> +/* Single Phase Buck IDs */
> +#define TPS65941_BUCK_ID_11
> +#define TPS65941_BUCK_ID_22
> +#define TPS65941_BUCK_ID_33
> +#define TPS65941_BUCK_ID_44
> +#define TPS65941_BUCK_ID_55
> +
> +/* Multi Phase Buck IDs */
> +#define TPS65941_BUCK_ID_12 12
> +#define TPS65941_BUCK_ID_34 34
> +#define TPS65941_BUCK_ID_123123
> +#define TPS65941_BUCK_ID_1234 1234
> +
> +/* LDO IDs */
> +#define TPS65941_LDO_ID_1 1
> +#define TPS65941_LDO_ID_2 2
> +#define TPS65941_LDO_ID_3 3
> +#define TPS65941_LDO_ID_4 4
> +
> static const char tps65941_buck_ctrl[TPS65941_BUCK_NUM] = {0x4, 0x6, 0x8,
> 0xA,
> 0xC};
> static const char tps65941_buck_vout[TPS65941_BUCK_NUM] = {0xE, 0x10, 0x12,
> @@ -270,10 +289,15 @@ static int tps65941_ldo_probe(struct udevice *dev)
> uc_pdata->type = REGULATOR_TYPE_LDO;
>
> idx = dev->driver_data;
> - if (idx == 1 || idx == 2 || idx == 3 || idx == 4) {
> + switch (idx) {
> + case TPS65941_LDO_ID_1:
> + case TPS65941_LDO_ID_2:
> + case TPS65941_LDO_ID_3:
> + case TPS65941_LDO_ID_4:
> debug("Single phase regulator\n");
> - } else {
> - printf("Wrong ID for regulator\n");
> + break;
> + default:
> + pr_err("Wrong ID for regulator\n");
> return -EINVAL;
> }
>
> @@ -292,18 +316,24 @@ static int tps65941_buck_probe(struct udevice *dev)
> uc_pdata->type = REGULATOR_TYPE_BUCK;
>
> idx = dev->driver_data;
> - if (idx == 1 || idx == 2 || idx == 3 || idx == 4 || idx == 5) {
> + switch (idx) {
> + case TPS65941_BUCK_ID_1:
> + case TPS65941_BUCK_ID_2:
> + case TPS65941_BUCK_ID_3:
> + case TPS65941_BUCK_ID_4:
> + case TPS65941_BUCK_ID_5:
> debug("Single phase regulator\n");
> - } else if (idx == 12) {
> + break;
> + case TPS65941_BUCK_ID_12:
> + case TPS65941_BUCK_ID_123:
> + case TPS65941_BUCK_ID_1234:
> idx = 1;
> - } else if (idx == 34) {
> + break;
> + case TPS65941_BUCK_ID_34:
> idx = 3;
> - } else if (idx == 123) {
> - idx = 1;
> - } else if (idx == 1234) {
> - idx = 1;
> - } else {
> - printf("Wrong ID for regulator\n");
> + break;
> + default:
> + pr_err("Wrong ID for regulator\n");
> return -EINVAL;
> }
>
Re: [RESEND PATCH v3 4/5] power: regulator: tps65941: use function callbacks for conversion ops
On 3/18/24 18:49, Bhargav Raviprakash wrote:
> Use function callbacks for volt2val, val2volt and slewrate lookups.
> This makes it easier to add support for TPS65224 PMIC regulators.
>
> Signed-off-by: Bhargav Raviprakash
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/power/regulator/tps65941_regulator.c | 61 +++-
> 1 file changed, 48 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/power/regulator/tps65941_regulator.c
> b/drivers/power/regulator/tps65941_regulator.c
> index cf54e30df5..d879c2301b 100644
> --- a/drivers/power/regulator/tps65941_regulator.c
> +++ b/drivers/power/regulator/tps65941_regulator.c
> @@ -35,6 +35,17 @@
> #define TPS65941_LDO_ID_3 3
> #define TPS65941_LDO_ID_4 4
>
> +#define TPS65941_BUCK_CONV_OPS_IDX 0
> +#define TPS65941_LDO_CONV_OPS_IDX 0
> +
> +struct tps65941_reg_conv_ops {
> + int volt_mask;
> + int (*volt2val)(int idx, int uV);
> + int (*val2volt)(int idx, int volt);
> + int slew_mask;
> + int (*lookup_slew)(int id);
> +};
> +
> static const char tps65941_buck_ctrl[TPS65941_BUCK_NUM] = {0x4, 0x6, 0x8,
> 0xA,
> 0xC};
> static const char tps65941_buck_vout[TPS65941_BUCK_NUM] = {0xE, 0x10, 0x12,
> @@ -79,7 +90,7 @@ static int tps65941_buck_enable(struct udevice *dev, int
> op, bool *enable)
> return 0;
> }
>
> -static int tps65941_buck_volt2val(int uV)
> +static int tps65941_buck_volt2val(__maybe_unused int idx, int uV)
> {
> if (uV > TPS65941_BUCK_VOLT_MAX)
> return -EINVAL;
> @@ -95,7 +106,7 @@ static int tps65941_buck_volt2val(int uV)
> return -EINVAL;
> }
>
> -static int tps65941_buck_val2volt(int val)
> +static int tps65941_buck_val2volt(__maybe_unused int idx, int val)
> {
> if (val > TPS65941_BUCK_VOLT_MAX_HEX)
> return -EINVAL;
> @@ -135,12 +146,25 @@ int tps65941_lookup_slew(int id)
> }
> }
>
> +static const struct tps65941_reg_conv_ops buck_conv_ops[] = {
> + [TPS65941_BUCK_CONV_OPS_IDX] = {
> + .volt_mask = TPS65941_BUCK_VOLT_MASK,
> + .volt2val = tps65941_buck_volt2val,
> + .val2volt = tps65941_buck_val2volt,
> + .slew_mask = TP65941_BUCK_CONF_SLEW_MASK,
> + .lookup_slew = tps65941_lookup_slew,
> + },
> +};
> +
> static int tps65941_buck_val(struct udevice *dev, int op, int *uV)
> {
> unsigned int hex, adr;
> - int ret, delta, uwait, slew;
> + int ret, delta, uwait, slew, idx;
> struct dm_regulator_uclass_plat *uc_pdata;
> + const struct tps65941_reg_conv_ops *conv_ops;
>
> + idx = dev->driver_data;
> + conv_ops = _conv_ops[TPS65941_BUCK_CONV_OPS_IDX];
> uc_pdata = dev_get_uclass_plat(dev);
>
> if (op == PMIC_OP_GET)
> @@ -152,8 +176,8 @@ static int tps65941_buck_val(struct udevice *dev, int op,
> int *uV)
> if (ret < 0)
> return ret;
>
> - ret &= TPS65941_BUCK_VOLT_MASK;
> - ret = tps65941_buck_val2volt(ret);
> + ret &= conv_ops->volt_mask;
> + ret = conv_ops->val2volt(idx, ret);
> if (ret < 0)
> return ret;
>
> @@ -175,14 +199,14 @@ static int tps65941_buck_val(struct udevice *dev, int
> op, int *uV)
> if (slew < 0)
> return ret;
>
> - slew &= TP65941_BUCK_CONF_SLEW_MASK;
> - slew = tps65941_lookup_slew(slew);
> + slew &= conv_ops->slew_mask;
> + slew = conv_ops->lookup_slew(slew);
> if (slew <= 0)
> return ret;
>
> uwait = delta / slew;
>
> - hex = tps65941_buck_volt2val(*uV);
> + hex = conv_ops->volt2val(idx, *uV);
> if (hex < 0)
> return hex;
>
> @@ -231,7 +255,7 @@ static int tps65941_ldo_enable(struct udevice *dev, int
> op, bool *enable)
> return 0;
> }
>
> -static int tps65941_ldo_val2volt(int val)
> +static int tps65941_ldo_val2volt(__maybe_unused int idx, int val)
> {
> if (val > TPS65941_LDO_VOLT_MAX_HEX || val < TPS65941_LDO_VOLT_MIN_HEX)
> return -EINVAL;
> @@ -241,12 +265,23 @@ static int tps65941_ldo_val2volt(int val)
> return -EINVAL;
> }
>
> +static const struct tps65941_reg_conv_ops ldo_conv_ops[] = {
> + [TPS65941_LDO_CONV_OPS_IDX] = {
> + .volt_mask = TPS65941_LDO_VOLT_MASK,
> + .volt2val = tps65941_buck_volt2val,
> + .val2volt = tps65941_ldo_val2volt,
> + },
> +};
> +
> static int tps6594
Re: [RESEND PATCH v3 2/5] power: pmic: tps65941: Add TI TPS65224 PMIC
On 3/18/24 18:49, Bhargav Raviprakash wrote:
> Adds compatible and data field values of TPS65224 driver in
> TPS65941 PMIC driver.
>
> Signed-off-by: Bhargav Raviprakash
> Reviewed-by: Dhruva Gole
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/power/pmic/tps65941.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/power/pmic/tps65941.c b/drivers/power/pmic/tps65941.c
> index 727b42747a..ef63eb733a 100644
> --- a/drivers/power/pmic/tps65941.c
> +++ b/drivers/power/pmic/tps65941.c
> @@ -75,6 +75,7 @@ static const struct udevice_id tps65941_ids[] = {
> { .compatible = "ti,tps659412", .data = TPS659411 },
> { .compatible = "ti,tps659413", .data = TPS659413 },
> { .compatible = "ti,lp876441", .data = LP876441 },
> + { .compatible = "ti,tps65224", .data = TPS65224 },
> { }
> };
>
Re: [RESEND PATCH v3 1/5] power: tps65941: Add macros of TPS65224 PMIC
On 3/18/24 18:49, Bhargav Raviprakash wrote: > Re-use the TPS65941 PMIC driver for TPS65224 PMIC. > Add additional macros of TPS65224 to aid in the driver > re-use. > > Signed-off-by: Bhargav Raviprakash > Reviewed-by: Dhruva Gole Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > include/power/tps65941.h | 30 ++ > 1 file changed, 30 insertions(+) > > diff --git a/include/power/tps65941.h b/include/power/tps65941.h > index a2bc6814ba..cec85333f0 100644 > --- a/include/power/tps65941.h > +++ b/include/power/tps65941.h > @@ -3,11 +3,14 @@ > #define TPS6594130x2 > #define TPS6594140x3 > #define LP8764410x4 > +#define TPS652240x5 > > /* I2C device address for pmic tps65941 */ > #define TPS65941_I2C_ADDR(0x12 >> 1) > #define TPS65941_LDO_NUM 4 > #define TPS65941_BUCK_NUM5 > +#define TPS65224_LDO_NUM 3 > +#define TPS65224_BUCK_NUM4 > > /* Drivers name */ > #define TPS65941_LDO_DRIVER "tps65941_ldo" > @@ -25,3 +28,30 @@ > #define TPS65941_LDO_MODE_MASK 0x1 > #define TPS65941_LDO_BYPASS_EN 0x80 > #define TP65941_BUCK_CONF_SLEW_MASK 0x7 > + > +#define TPS65224_BUCK_VOLT_MAX 330 > +#define TPS65224_BUCK1_VOLT_MAX_HEX 0xFD > +#define TPS65224_BUCK234_VOLT_MAX_HEX0x45 > + > +#define TPS65224_BUCK_CONF_SLEW_MASK 0x3 > +#define TPS65224_LDO_VOLT_MASK(0x3F << 1) > + > +#define TPS65224_LDO1_VOLT_MIN_HEX 0x0C > +#define TPS65224_LDO23_VOLT_MIN_HEX 0x00 > +#define TPS65224_LDO1_VOLT_MAX_HEX 0x36 > +#define TPS65224_LDO23_VOLT_MAX_HEX 0x38 > + > +#define TPS65224_LDO1_VOLT_MAX330 > +#define TPS65224_LDO23_VOLT_MAX 340 > +#define TPS65224_LDO1_VOLT_MIN120 > +#define TPS65224_LDO23_VOLT_MIN60 > + > +#define TPS65224_LDO_STEP 5 > + > +#define TPS65224_LDO_BYP_CONFIG 7 > + > +#define TPS65224_LDO1_VOLT_BYP_MIN220 > +#define TPS65224_LDO1_VOLT_BYP_MAX360 > + > +#define TPS65224_LDO23_VOLT_BYP_MIN 150 > +#define TPS65224_LDO23_VOLT_BYP_MAX 550
RE: [PATCH] mmc: cv1800b: Add transmit tap delay config to fix write error
> -Original Message-
> From: Kongyang Liu
> Sent: Tuesday, April 16, 2024 4:31 PM
> To: u-boot@lists.denx.de
> Cc: Jaehoon Chung ; Leo Yu-Chi Liang
> ; Peng Fan
> ; Tom Rini
> Subject: [PATCH] mmc: cv1800b: Add transmit tap delay config to fix write
> error
>
> Currently, only the receive delay is configured while the transmit delay
> is not set, which may result in errors when writing to the file. This issue
> can be resolved by setting PHY_TX_SRC_INVERT to SDHCI_PHY_TX_RX_DLY.
>
> Signed-off-by: Kongyang Liu
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> drivers/mmc/cv1800b_sdhci.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/cv1800b_sdhci.c b/drivers/mmc/cv1800b_sdhci.c
> index 2275c53777..a50f4cff0d 100644
> --- a/drivers/mmc/cv1800b_sdhci.c
> +++ b/drivers/mmc/cv1800b_sdhci.c
> @@ -12,6 +12,8 @@
> #define MMC_MAX_CLOCK37500
> #define TUNE_MAX_PHCODE 128
>
> +#define PHY_TX_SRC_INVERT BIT(8)
> +
> struct cv1800b_sdhci_plat {
> struct mmc_config cfg;
> struct mmc mmc;
> @@ -19,7 +21,7 @@ struct cv1800b_sdhci_plat {
>
> static void cv1800b_set_tap_delay(struct sdhci_host *host, u16 tap)
> {
> - sdhci_writel(host, tap << 16, SDHCI_PHY_TX_RX_DLY);
> + sdhci_writel(host, PHY_TX_SRC_INVERT | tap << 16, SDHCI_PHY_TX_RX_DLY);
> }
>
> static void cv1800b_sdhci_reset(struct sdhci_host *host, u8 mask)
> --
> 2.41.0
RE: [PATCH 4/5] mmc: am654_sdhci: Set ENDLL=1 for DDR52 mode
> -Original Message-
> From: Judith Mendez
> Sent: Tuesday, April 16, 2024 6:28 AM
> To: Peng Fan ; Jaehoon Chung ; Tom
> Rini
> Cc: Nitin Yadav ; Simon Glass ;
> u-boot@lists.denx.de
> Subject: [PATCH 4/5] mmc: am654_sdhci: Set ENDLL=1 for DDR52 mode
>
> According to the device datasheet [0], ENDLL=1 for
> DDR52 mode, so call am654_sdhci_setup_dll() and write
> itapdly after since we do not carry out tuning.
>
> [0] https://www.ti.com/lit/ds/symlink/am62p.pdf
> Fixes: c964447ea3d6 ("mmc: am654_sdhci: Add support for input tap delay")
> Signed-off-by: Judith Mendez
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/am654_sdhci.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
> index 38f1ad28ec4..dee56dfdbaa 100644
> --- a/drivers/mmc/am654_sdhci.c
> +++ b/drivers/mmc/am654_sdhci.c
> @@ -287,12 +287,14 @@ static int am654_sdhci_set_ios_post(struct sdhci_host
> *host)
>
> regmap_update_bits(plat->base, PHY_CTRL4, mask, val);
>
> - if (mode > UHS_SDR25 && speed >= CLOCK_TOO_SLOW_HZ) {
> + if ((mode > UHS_SDR25 || mode == MMC_DDR_52) && speed >=
> CLOCK_TOO_SLOW_HZ) {
> ret = am654_sdhci_setup_dll(plat, speed);
> if (ret)
> return ret;
>
> plat->dll_enable = true;
> + am654_sdhci_write_itapdly(plat, plat->itap_del_sel[mode],
> + plat->itap_del_ena[mode]);
> } else {
> am654_sdhci_setup_delay_chain(plat, mode);
> plat->dll_enable = false;
> --
> 2.43.2
RE: [PATCH 3/5] mmc: am654_sdhci: Add itap_del_ena[] to store itapdlyena bit
Hi,
> -Original Message-
> From: Judith Mendez
> Sent: Tuesday, April 16, 2024 6:28 AM
> To: Peng Fan ; Jaehoon Chung ; Tom
> Rini
> Cc: Nitin Yadav ; Simon Glass ;
> u-boot@lists.denx.de
> Subject: [PATCH 3/5] mmc: am654_sdhci: Add itap_del_ena[] to store itapdlyena
> bit
>
> Set itap_del_ena if ITAPDLY is found in DT or if the tuning
> algorithm was executed and found the optimal ITAPDLY. Add the
> functionality to save ITAPDLYENA that can be referenced later
> by storing the bit in array itap_del_ena[].
>
> Signed-off-by: Judith Mendez
> ---
> drivers/mmc/am654_sdhci.c | 30 --
> 1 file changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
> index 1dd032e1e36..38f1ad28ec4 100644
> --- a/drivers/mmc/am654_sdhci.c
> +++ b/drivers/mmc/am654_sdhci.c
> @@ -92,6 +92,7 @@ struct am654_sdhci_plat {
> bool non_removable;
> u32 otap_del_sel[MMC_MODES_END];
> u32 itap_del_sel[MMC_MODES_END];
> + u32 itap_del_ena[MMC_MODES_END];
> u32 trm_icp;
> u32 drv_strength;
> u32 strb_sel;
> @@ -223,8 +224,10 @@ static int am654_sdhci_setup_dll(struct am654_sdhci_plat
> *plat,
> }
>
> static void am654_sdhci_write_itapdly(struct am654_sdhci_plat *plat,
> - u32 itapdly)
> + u32 itapdly, u32 enable)
> {
> + regmap_update_bits(plat->base, PHY_CTRL4, ITAPDLYENA_MASK,
> +enable << ITAPDLYENA_SHIFT);
> /* Set ITAPCHGWIN before writing to ITAPDLY */
> regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK,
> 1 << ITAPCHGWIN_SHIFT);
> @@ -242,7 +245,8 @@ static void am654_sdhci_setup_delay_chain(struct
> am654_sdhci_plat *plat,
> mask = SELDLYTXCLK_MASK | SELDLYRXCLK_MASK;
> regmap_update_bits(plat->base, PHY_CTRL5, mask, val);
>
> - am654_sdhci_write_itapdly(plat, plat->itap_del_sel[mode]);
> + am654_sdhci_write_itapdly(plat, plat->itap_del_sel[mode],
> + plat->itap_del_ena[mode]);
> }
>
> static int am654_sdhci_set_ios_post(struct sdhci_host *host)
> @@ -443,6 +447,7 @@ static int am654_sdhci_execute_tuning(struct mmc *mmc, u8
> opcode)
> struct udevice *dev = mmc->dev;
> struct am654_sdhci_plat *plat = dev_get_plat(dev);
> struct window fail_window[ITAPDLY_LENGTH];
> + int mode = mmc->selected_mode;
> u8 curr_pass, itap;
> u8 fail_index = 0;
> u8 prev_pass = 1;
> @@ -450,11 +455,10 @@ static int am654_sdhci_execute_tuning(struct mmc *mmc,
> u8 opcode)
> memset(fail_window, 0, sizeof(fail_window));
>
> /* Enable ITAPDLY */
> - regmap_update_bits(plat->base, PHY_CTRL4, ITAPDLYENA_MASK,
> -1 << ITAPDLYENA_SHIFT);
> + plat->itap_del_ena[mode] = 0x1;
0x1 means "enable"? I want to use a macro with meaning.
>
> for (itap = 0; itap < ITAPDLY_LENGTH; itap++) {
> - am654_sdhci_write_itapdly(plat, itap);
> + am654_sdhci_write_itapdly(plat, itap, plat->itap_del_ena[mode]);
>
> curr_pass = !mmc_send_tuning(mmc, opcode, NULL);
>
> @@ -478,7 +482,7 @@ static int am654_sdhci_execute_tuning(struct mmc *mmc, u8
> opcode)
> itap = am654_sdhci_calculate_itap(dev, fail_window, fail_index,
> plat->dll_enable);
>
> - am654_sdhci_write_itapdly(plat, itap);
> + am654_sdhci_write_itapdly(plat, itap, plat->itap_del_ena[mode]);
>
> return 0;
> }
> @@ -515,6 +519,7 @@ static int j721e_4bit_sdhci_set_ios_post(struct
> sdhci_host *host)
> struct am654_sdhci_plat *plat = dev_get_plat(dev);
> int mode = host->mmc->selected_mode;
> u32 otap_del_sel;
> + u32 itap_del_ena;
> u32 itap_del_sel;
> u32 mask, val;
>
> @@ -524,10 +529,11 @@ static int j721e_4bit_sdhci_set_ios_post(struct
> sdhci_host *host)
> val = (1 << OTAPDLYENA_SHIFT) |
> (otap_del_sel << OTAPDLYSEL_SHIFT);
>
> + itap_del_ena = plat->itap_del_ena[mode];
> itap_del_sel = plat->itap_del_sel[mode];
>
> mask |= ITAPDLYENA_MASK | ITAPDLYSEL_MASK;
> - val = (1 << ITAPDLYENA_SHIFT) |
> + val = (itap_del_ena << ITAPDLYENA_SHIFT) |
> (itap_del_sel << ITAPDLYSEL_SHIFT);
>
> regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK,
> @@ -599,9 +605,13 @@ static int sdhci_am654_get_otap_delay(struct udevice
RE: [PATCH 2/5] mmc: am654_sdhci: Fix OTAP/ITAP delay values
Hi Judith,
> -Original Message-
> From: Judith Mendez
> Sent: Tuesday, April 16, 2024 6:28 AM
> To: Peng Fan ; Jaehoon Chung ; Tom
> Rini
> Cc: Nitin Yadav ; Simon Glass ;
> u-boot@lists.denx.de
> Subject: [PATCH 2/5] mmc: am654_sdhci: Fix OTAP/ITAP delay values
>
> From: Nitin Yadav
>
> U-Boot is failing to boot class U1 UHS SD cards due to incorrect
> OTAP and ITAP delay select values. Update OTAP and ITAP delay select
> values from DT.
>
> Fixes: c7d106b4eb3 ("mmc: am654_sdhci: Update output tap delay writes")
> Signed-off-by: Nitin Yadav
> Signed-off-by: Judith Mendez
> ---
> drivers/mmc/am654_sdhci.c | 23 +++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
> index e5ad00e2531..1dd032e1e36 100644
> --- a/drivers/mmc/am654_sdhci.c
> +++ b/drivers/mmc/am654_sdhci.c
> @@ -513,12 +513,27 @@ static int j721e_4bit_sdhci_set_ios_post(struct
> sdhci_host *host)
> {
> struct udevice *dev = host->mmc->dev;
> struct am654_sdhci_plat *plat = dev_get_plat(dev);
> - u32 otap_del_sel, mask, val;
> + int mode = host->mmc->selected_mode;
> + u32 otap_del_sel;
> + u32 itap_del_sel;
> + u32 mask, val;
> +
> + otap_del_sel = plat->otap_del_sel[mode];
>
> - otap_del_sel = plat->otap_del_sel[host->mmc->selected_mode];
> mask = OTAPDLYENA_MASK | OTAPDLYSEL_MASK;
> - val = (1 << OTAPDLYENA_SHIFT) | (otap_del_sel << OTAPDLYSEL_SHIFT);
> + val = (1 << OTAPDLYENA_SHIFT) |
> + (otap_del_sel << OTAPDLYSEL_SHIFT);
Is there any reason to touch this? And I can't understood this, this val
doesn’t use anywhere.
Because val is resetting the below. It seems same value, right?
> +
> + itap_del_sel = plat->itap_del_sel[mode];
> +
> + mask |= ITAPDLYENA_MASK | ITAPDLYSEL_MASK;
Can it be set at above?
mask |= OTAPDLYENA_MASK | OTAPDLYSEL_MASK |
ITAPDLYENA_MASK | ITAPDLYSEL_MASK;
Best Regards,
Jaehoon Chung
> + val = (1 << ITAPDLYENA_SHIFT) |
> + (itap_del_sel << ITAPDLYSEL_SHIFT);
> +
> + regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK,
> +1 << ITAPCHGWIN_SHIFT);
> regmap_update_bits(plat->base, PHY_CTRL4, mask, val);
> + regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK, 0);
>
> regmap_update_bits(plat->base, PHY_CTRL5, CLKBUFSEL_MASK,
> plat->clkbuf_sel);
> @@ -572,7 +587,7 @@ static int sdhci_am654_get_otap_delay(struct udevice *dev,
>* Remove the corresponding capability if an otap-del-sel
>* value is not found
>*/
> - for (i = MMC_HS; i <= MMC_HS_400; i++) {
> + for (i = MMC_LEGACY; i <= MMC_HS_400; i++) {
> ret = dev_read_u32(dev, td[i].otap_binding,
> >otap_del_sel[i]);
> if (ret) {
> --
> 2.43.2
RE: [PATCH 1/5] mmc: am654_sdhci: Add tuning algorithm for delay chain
> -Original Message-
> From: Judith Mendez
> Sent: Tuesday, April 16, 2024 6:28 AM
> To: Peng Fan ; Jaehoon Chung ; Tom
> Rini
> Cc: Nitin Yadav ; Simon Glass ;
> u-boot@lists.denx.de
> Subject: [PATCH 1/5] mmc: am654_sdhci: Add tuning algorithm for delay chain
>
> Currently the sdhci_am654 driver only supports one tuning
> algorithm which should be used only when DLL is enabled. The
> ITAPDLY is selected from the largest passing window and the
> buffer is viewed as a circular buffer.
>
> The new tuning algorithm should be used when the delay chain
> is enabled; the ITAPDLY is selected from the largest passing
> window and the buffer is not viewed as a circular buffer.
>
> This implementation is based off of the following paper: [1].
>
> Also add support for multiple failing windows.
>
> [1] https://www.ti.com/lit/an/spract9/spract9.pdf
>
> Fixes: a759abf569d4 ("mmc: am654_sdhci: Add support for software tuning")
> Signed-off-by: Judith Mendez
> ---
> drivers/mmc/am654_sdhci.c | 107 +++---
> 1 file changed, 89 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
> index 05595bdac39..e5ad00e2531 100644
> --- a/drivers/mmc/am654_sdhci.c
> +++ b/drivers/mmc/am654_sdhci.c
> @@ -97,6 +97,7 @@ struct am654_sdhci_plat {
> u32 strb_sel;
> u32 clkbuf_sel;
> u32 flags;
> + bool dll_enable;
> #define DLL_PRESENT BIT(0)
> #define IOMUX_PRESENTBIT(1)
> #define FREQSEL_2_BITBIT(2)
> @@ -110,6 +111,12 @@ struct timing_data {
> u32 capability;
> };
>
> +struct window {
> + u8 start;
> + u8 end;
> + u8 length;
> +};
> +
> static const struct timing_data td[] = {
> [MMC_LEGACY]= {"ti,otap-del-sel-legacy",
> "ti,itap-del-sel-legacy",
> @@ -280,8 +287,11 @@ static int am654_sdhci_set_ios_post(struct sdhci_host
> *host)
> ret = am654_sdhci_setup_dll(plat, speed);
> if (ret)
> return ret;
> +
> + plat->dll_enable = true;
> } else {
> am654_sdhci_setup_delay_chain(plat, mode);
> + plat->dll_enable = false;
> }
>
> regmap_update_bits(plat->base, PHY_CTRL5, CLKBUFSEL_MASK,
> @@ -375,38 +385,99 @@ static void am654_sdhci_write_b(struct sdhci_host
> *host, u8 val, int reg)
> writeb(val, host->ioaddr + reg);
> }
> #ifdef MMC_SUPPORTS_TUNING
> -#define ITAP_MAX 32
> +#define ITAPDLY_LENGTH 32
> +#define ITAPDLY_LAST_INDEX (ITAPDLY_LENGTH - 1)
> +
> +static u32 am654_sdhci_calculate_itap(struct udevice *dev, struct window
> + *fail_window, u8 num_fails, bool circular_buffer)
> +{
> + u8 itap = 0, start_fail = 0, end_fail = 0, pass_length = 0;
> + u8 first_fail_start = 0, last_fail_end = 0;
> + struct window pass_window = {0, 0, 0};
> + int prev_fail_end = -1;
> + u8 i;
> +
> + if (!num_fails)
> + return ITAPDLY_LAST_INDEX >> 1;
> +
> + if (fail_window->length == ITAPDLY_LENGTH) {
> + dev_err(dev, "No passing ITAPDLY, return 0\n");
> + return 0;
> + }
> +
> + first_fail_start = fail_window->start;
> + last_fail_end = fail_window[num_fails - 1].end;
> +
> + for (i = 0; i < num_fails; i++) {
> + start_fail = fail_window[i].start;
> + end_fail = fail_window[i].end;
> + pass_length = start_fail - (prev_fail_end + 1);
> +
> + if (pass_length > pass_window.length) {
> + pass_window.start = prev_fail_end + 1;
> + pass_window.length = pass_length;
> + }
> + prev_fail_end = end_fail;
> + }
> +
> + if (!circular_buffer)
> + pass_length = ITAPDLY_LAST_INDEX - last_fail_end;
> + else
> + pass_length = ITAPDLY_LAST_INDEX - last_fail_end +
> first_fail_start;
> +
> + if (pass_length > pass_window.length) {
> + pass_window.start = last_fail_end + 1;
> + pass_window.length = pass_length;
> + }
> +
> + if (!circular_buffer)
> + itap = pass_window.start + (pass_window.length >> 1);
> + else
> + itap = (pass_window.start + (pass_window.length >> 1)) %
> ITAPDLY_LENGTH;
> +
> + return (itap > ITAPDLY_LAST_INDEX) ? ITAPDLY_LAST_INDEX >> 1 : itap;
> +}
> +
> static int am654_sdhci_execute_tuning(struct mmc *mmc, u8 opcode)
RE: [PATCH 2/2] mmc: stm32_sdmmc2: Fix AARCH64 compilation warnings
> -Original Message-
> From: Patrick DELAUNAY
> Sent: Wednesday, April 17, 2024 6:02 PM
> To: Patrice Chotard ; u-boot@lists.denx.de
> Cc: U-Boot STM32 ; Jaehoon Chung
> ;
> Peng Fan ; Sean Anderson ; Simon Glass
> ; Tom
> Rini
> Subject: Re: [PATCH 2/2] mmc: stm32_sdmmc2: Fix AARCH64 compilation warnings
>
> Hi,
>
> On 3/8/24 15:26, Patrice Chotard wrote:
> > When building with AARCH64 defconfig, we got warnings, fix them.
> >
> > Signed-off-by: Patrice Chotard
> > ---
> >
> > drivers/mmc/stm32_sdmmc2.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
> > index d4982a14281..39ae79ba129 100644
> > --- a/drivers/mmc/stm32_sdmmc2.c
> > +++ b/drivers/mmc/stm32_sdmmc2.c
> > @@ -220,9 +220,9 @@ static void stm32_sdmmc2_start_data(struct udevice *dev,
> >
> > if (data->flags & MMC_DATA_READ) {
> > data_ctrl |= SDMMC_DCTRL_DTDIR;
> > - idmabase0 = (u32)data->dest;
> > + idmabase0 = (u32)(long)data->dest;
> > } else {
> > - idmabase0 = (u32)data->src;
> > + idmabase0 = (u32)(long)data->src;
> > }
> >
> > /* Set the SDMMC DataLength value */
> > @@ -463,8 +463,8 @@ retry_cmd:
> >
> > stm32_sdmmc2_start_cmd(dev, cmd, cmdat, );
> >
> > - dev_dbg(dev, "send cmd %d data: 0x%x @ 0x%x\n",
> > - cmd->cmdidx, data ? ctx.data_length : 0, (unsigned int)data);
> > + dev_dbg(dev, "send cmd %d data: 0x%x @ 0x%p\n",
> > + cmd->cmdidx, data ? ctx.data_length : 0, data);
> >
> > ret = stm32_sdmmc2_end_cmd(dev, cmd, );
> >
>
>
>
> Reviewed-by: Patrick Delaunay
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
>
> Thanks
> Patrick
RE: [PATCH 1/2] mmc: stm32_sdmmc2: Add "st,stm32mp25-sdmmc2" compatible
Hi
> -Original Message-
> From: Patrick DELAUNAY
> Sent: Wednesday, April 17, 2024 6:02 PM
> To: Patrice Chotard ; u-boot@lists.denx.de
> Cc: U-Boot STM32 ; Jaehoon Chung
> ;
> Peng Fan ; Sean Anderson ; Simon Glass
> ; Tom
> Rini
> Subject: Re: [PATCH 1/2] mmc: stm32_sdmmc2: Add "st,stm32mp25-sdmmc2"
> compatible
>
> Hi,
>
> On 3/8/24 15:26, Patrice Chotard wrote:
> > From: Patrick Delaunay
> >
> > Add compatible used for STM32MP25 family.
> >
> > Signed-off-by: Patrick Delaunay
> > Signed-off-by: Patrice Chotard
> > ---
> >
> > drivers/mmc/stm32_sdmmc2.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
> > index a2b111a8435..d4982a14281 100644
> > --- a/drivers/mmc/stm32_sdmmc2.c
> > +++ b/drivers/mmc/stm32_sdmmc2.c
> > @@ -789,6 +789,7 @@ static int stm32_sdmmc2_bind(struct udevice *dev)
> >
> > static const struct udevice_id stm32_sdmmc2_ids[] = {
> > { .compatible = "st,stm32-sdmmc2" },
> > + { .compatible = "st,stm32mp25-sdmmc2" },
> > { }
> > };
> >
>
>
> Reviewed-by: Patrick Delaunay
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
>
> Thanks
> Patrick
>
RE: [RFC PATCH v1 1/1] mmc: snps_sdhci: Add sdhci driver support for TH1520 SoC
Hi, > -Original Message- > From: Maxim Kiselev > Sent: Wednesday, April 3, 2024 3:57 AM > To: Sean Anderson > Cc: Tom Rini ; Peng Fan ; Jaehoon Chung > ; > Marek Vasut ; Paul Barker > ; Kever Yang > ; Peter Geis ; Oleksandr > Suvorov > ; Stefan Roese ; > u-boot@lists.denx.de > Subject: Re: [RFC PATCH v1 1/1] mmc: snps_sdhci: Add sdhci driver support for > TH1520 SoC > > Hi, Sean > > вт, 2 апр. 2024 г. в 18:39, Sean Anderson : > > > > On 3/30/24 13:59, Maksim Kiselev wrote: > > > Add support for DesignWare SDHCI host controller on Alibaba TH1520 SoC > > > > > > Signed-off-by: Maksim Kiselev > > > --- > > > drivers/mmc/Kconfig | 12 + > > > drivers/mmc/Makefile | 1 + > > > drivers/mmc/snps_sdhci.c | 464 +++ > > > 3 files changed, 477 insertions(+) > > > create mode 100644 drivers/mmc/snps_sdhci.c > > > > > > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig > > > index cef05790dd..6936fa0928 100644 > > > --- a/drivers/mmc/Kconfig > > > +++ b/drivers/mmc/Kconfig > > > @@ -671,6 +671,18 @@ config MMC_SDHCI_S5P > > > > > > If unsure, say N. > > > > > > +config MMC_SDHCI_SNPS > > > + bool "Synopsys DesignWare SDHCI controller" > > > + depends on MMC_SDHCI > > > + depends on DM_MMC > > > + help > > > + Support for DesignWare SDHCI host controller on Alibaba TH1520 SoC. > > > + This is a highly configurable and programmable, high performance > > > + Mobile Storage Host Controller (MSHC) with AXI as the bus interface > > > + for data transfer. > > > + > > > + If unsure, say N. > > > + > > > > Why not use MMC_DW? > > That driver looks completely different. As I notice in the cover letter, > the MMC_SDHCI_ROCKCHIP driver is closer to TH1520 driver. > https://lore.kernel.org/u-boot/20240330175948.80931-1-biguncle...@gmail.com/ > > Their IP blocks look very similar. > Moreover, on Linux, Rockchip SDHCI controllers (ex. rockchip,rk3588-dwcmshc) > and the TH1520 controller live in the same driver - sdhci-of-dwcmshc.c Right. I didn't have its TRM. AFAIK, It's a different IP with DW_MMC. > > We could do the same for U-boot. It will require to get rid of Rockchip > specific defines that come from asm/arch-rockchip/hardware.h. > And maybe rename the rockchip_sdhci.c driver to sdhci-of-dwcmshc.c. In u-boot, rochkip_sdhci.c is including the specific rockchip code. (rockchip header..) So I think that it can be a huge refactoring to use both SoC. But if it's possible, I think that it can be reusable. > > That's why I mark this series as RFC. So I'm willing to discuss any option. > > > --Sean > > > > > > [Embedded World 2024, SECO SpA]<https://www.messe- > ticket.de/Nuernberg/embeddedworld2024/Register/ew24517689> > > Cheers, > Maksim
RE: [PATCH] mmc: Support 32-bit only ADMA on 64-bit platforms
> -Original Message-
> From: Greg Malysa
> Sent: Tuesday, March 26, 2024 11:28 AM
> To: u-boot@lists.denx.de; Peng Fan ; Jaehoon Chung
>
> Cc: Greg Malysa ; Nathan Barrett-Morrison
> ; Ian
> Roberts ; Jonas Karlman ; Kever
> Yang chips.com>; Marek Vasut ; Oleksandr Suvorov
> ; Paul Barker
> ; Peter Geis
> ; Sean Anderson ; Simon Glass
> ; Stefan
> Roese ; Tom Rini
> Subject: [PATCH] mmc: Support 32-bit only ADMA on 64-bit platforms
>
> Some arm64 platforms may include SDIO host controllers that
> only support 32-bit ADMA. While the Linux kernel detects which
> size is supported and adjusts the descriptor size used dynamically,
> the previous u-boot implementation statically selected between the
> two depending on whether DMA_ADDR_T_64BIT was defined. Because the
> static selection is already in place and effective for most platforms,
> this patch logically separates "64 bit addresses are used for DMA on
> this platform" and "64 bit addresses are used by the SDIO host
> controller for ADMA" in order to support the small number of platforms
> where these statements are not equivalent.
>
> Using 32 bits is opt-in and existing 64 bit platforms should be
> unaffected by this change.
>
> Co-developed-by: Nathan Barrett-Morrison
> Signed-off-by: Nathan Barrett-Morrison
> Co-developed-by: Ian Roberts
> Signed-off-by: Ian Roberts
> Signed-off-by: Greg Malysa
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
>
> ---
>
>
> ---
> drivers/mmc/Kconfig | 18 ++
> drivers/mmc/sdhci-adma.c | 2 +-
> drivers/mmc/sdhci.c | 9 -
> include/sdhci.h | 4 ++--
> 4 files changed, 25 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index cef05790dd..4538286c64 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -495,6 +495,24 @@ config SPL_MMC_SDHCI_ADMA
> This enables support for the ADMA (Advanced DMA) defined
> in the SD Host Controller Standard Specification Version 3.00 in SPL.
>
> +config MMC_SDHCI_ADMA_FORCE_32BIT
> + bool "Force 32 bit mode for ADMA on 64 bit platforms"
> + help
> + This forces SDHCI ADMA to be built for 32 bit descriptors, even
> + on a 64 bit platform where they would otherwise be assumed to
> + be 64 bits. This is necessary for certain hardware platforms
> + that are 64-bit but include only 32-bit support within the selected
> + SD host controller IP.
> +
> +config MMC_SDHCI_ADMA_64BIT
> + bool "Use SHDCI ADMA with 64 bit descriptors"
> + depends on !MMC_SDHCI_ADMA_FORCE_32BIT
> + default y if DMA_ADDR_T_64BIT
> + help
> + This selects 64 bit descriptors for SDHCI ADMA. It is enabled by
> + default on 64 bit systems, but can be disabled if one of these
> + systems includes 32-bit ADMA.
> +
> config FIXED_SDHCI_ALIGNED_BUFFER
> hex "SDRAM address for fixed buffer"
> depends on SPL && MVEBU_SPL_BOOT_DEVICE_MMC
> diff --git a/drivers/mmc/sdhci-adma.c b/drivers/mmc/sdhci-adma.c
> index 8213223d3f..474647c3fd 100644
> --- a/drivers/mmc/sdhci-adma.c
> +++ b/drivers/mmc/sdhci-adma.c
> @@ -22,7 +22,7 @@ static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
> desc->len = len;
> desc->reserved = 0;
> desc->addr_lo = lower_32_bits(addr);
> -#ifdef CONFIG_DMA_ADDR_T_64BIT
> +#ifdef CONFIG_MMC_SDHCI_ADMA_64BIT
> desc->addr_hi = upper_32_bits(addr);
> #endif
> }
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index 0178ed8a11..b27ce57d96 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -900,11 +900,10 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
> sdhci_host *host,
> host->adma_desc_table = sdhci_adma_init();
> host->adma_addr = (dma_addr_t)host->adma_desc_table;
>
> -#ifdef CONFIG_DMA_ADDR_T_64BIT
> - host->flags |= USE_ADMA64;
> -#else
> - host->flags |= USE_ADMA;
> -#endif
> + if (IS_ENABLED(CONFIG_MMC_SDHCI_ADMA_64BIT))
> + host->flags |= USE_ADMA64;
> + else
> + host->flags |= USE_ADMA;
> #endif
> if (host->quirks & SDHCI_QUIRK_REG32_RW)
> host->version =
> diff --git a/include/sdhci.h b/include/sdhci.h
> index a1b74e3bd7..07b84d6715 100644
> --- a/include/sdhci.h
> +++ b/include/sdhci.h
> @@ -294,7 +294,7 @@ struct sdhci_ops {
> };
>
> #define ADMA_MAX_LEN 65532
> -#ifdef CONFIG_DMA_ADDR_T_64BIT
> +#ifdef CONFIG_MMC_SDHCI_ADMA_64BIT
> #define ADMA_DESC_LEN16
> #else
> #define ADMA_DESC_LEN8
> @@ -319,7 +319,7 @@ struct sdhci_adma_desc {
> u8 reserved;
> u16 len;
> u32 addr_lo;
> -#ifdef CONFIG_DMA_ADDR_T_64BIT
> +#ifdef CONFIG_MMC_SDHCI_ADMA_64BIT
> u32 addr_hi;
> #endif
> } __packed;
> --
> 2.43.2
RE: [PATCH] mmc: sdhci: Fix potential ADMA descriptor table overflow
> -Original Message-
> From: Greg Malysa
> Sent: Tuesday, March 26, 2024 11:23 AM
> To: u-boot@lists.denx.de; Peng Fan ; Jaehoon Chung
>
> Cc: Ian Roberts ; Nathan Barrett-Morrison
> ; Greg
> Malysa ; Sean Anderson ; Tom
> Rini
>
> Subject: [PATCH] mmc: sdhci: Fix potential ADMA descriptor table overflow
>
> From: Ian Roberts
>
> Change ADMA_TABLE_NO_ENTRIES to round the division up to fully
> contain CONFIG_SYS_MMC_MAX_BLK_COUNT, fixing potential buffer overflow
> of the ADMA descriptor table.
>
> sdhci_prepare_adma_table() expecitily states it does _not_ check for
> overflow as the descriptor table size is dependent on
> CONFIG_SYS_MMC_MAX_BLK_COUNT. However, the ADMA_TABLE_NO_ENTRIES
> calculation does not round up the divison, so with the current u-boot
> defaults:
> max_mmc_transfer = (CONFIG_SYS_MMC_MAX_BLK_COUNT * MMC_MAX_BLOCK_LEN) =
> 65535 * 512 = 33553920 bytes.
> ADMA_TABLE_NO_ENTRIES = max_mmc_transfer / ADMA_MAX_LEN =
> 33553920 / 65532, which does not divide cleanly.
> actual_max_transfer = ADMA_TABLE_NO_ENTRIES * ADMA_MAX_LEN = 512 *
> 65532 = 33552384, which is smaller than max_mmc_transfer.
> This can cause sdhci_prepare_adma_table() to write one extra
> descriptor, overflowing the table when a transaction larger than
> actual_max_transfer is issued.
>
> Co-developed-by: Nathan Barrett-Morrison
> Signed-off-by: Nathan Barrett-Morrison
> Signed-off-by: Greg Malysa
> Signed-off-by: Ian Roberts
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
>
> ---
>
>
> ---
> include/sdhci.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/sdhci.h b/include/sdhci.h
> index a1b74e3bd7..fbc0f0391c 100644
> --- a/include/sdhci.h
> +++ b/include/sdhci.h
> @@ -11,6 +11,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -299,8 +300,8 @@ struct sdhci_ops {
> #else
> #define ADMA_DESC_LEN8
> #endif
> -#define ADMA_TABLE_NO_ENTRIES (CONFIG_SYS_MMC_MAX_BLK_COUNT * \
> -MMC_MAX_BLOCK_LEN) / ADMA_MAX_LEN
> +#define ADMA_TABLE_NO_ENTRIES DIV_ROUND_UP(CONFIG_SYS_MMC_MAX_BLK_COUNT * \
> + MMC_MAX_BLOCK_LEN, ADMA_MAX_LEN)
>
> #define ADMA_TABLE_SZ (ADMA_TABLE_NO_ENTRIES * ADMA_DESC_LEN)
>
> --
> 2.43.2
RE: [PATCH] mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops
> -Original Message-
> From: Greg Malysa
> Sent: Tuesday, March 26, 2024 11:18 AM
> To: u-boot@lists.denx.de; Peng Fan ; Jaehoon Chung
>
> Cc: Ian Roberts ; Nathan Barrett-Morrison
> ; Greg
> Malysa ; Jonas Karlman ; Kever Yang
> chips.com>; Peter Geis ; Sean Anderson
> ; Simon Glass
> ; Tom Rini
> Subject: [PATCH] mmc: sdhci: introduce adma_write_desc() hook to struct
> sdhci_ops
>
> From: Ian Roberts
>
> Add this hook so that it can be overridden with driver specific
> implementations. We also let the original sdhci_adma_write_desc()
> accept so that the function can set its new value. Then export
> the function so that it could be reused by driver's specific
> implementations.
>
> The above is a port of Linux kernel commit 54552e4948cbf
>
> In addition, allow drivers to allocate their own ADMA descriptor
> tables if additional space is required.
>
> Finally, fix the assignment of adma_addr to fix compiler warning
> on 64-bit platforms that still use 32-bit DMA addressing.
>
> Co-developed-by: Nathan Barrett-Morrison
> Signed-off-by: Nathan Barrett-Morrison
> Signed-off-by: Greg Malysa
> Signed-off-by: Ian Roberts
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
>
> ---
>
>
> ---
> drivers/mmc/fsl_esdhc.c | 2 +-
> drivers/mmc/sdhci-adma.c | 41 +++-
> drivers/mmc/sdhci.c | 8 +---
> include/sdhci.h | 12 ++--
> 4 files changed, 44 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index d50669..bd0671cc52 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -252,7 +252,7 @@ static void esdhc_setup_dma(struct fsl_esdhc_priv *priv,
> struct mmc_data *data)
> priv->adma_desc_table) {
> debug("Using ADMA2\n");
> /* prefer ADMA2 if it is available */
> - sdhci_prepare_adma_table(priv->adma_desc_table, data,
> + sdhci_prepare_adma_table(NULL, priv->adma_desc_table, data,
>priv->dma_addr);
>
> adma_addr = virt_to_phys(priv->adma_desc_table);
> diff --git a/drivers/mmc/sdhci-adma.c b/drivers/mmc/sdhci-adma.c
> index 8213223d3f..8c38448b6a 100644
> --- a/drivers/mmc/sdhci-adma.c
> +++ b/drivers/mmc/sdhci-adma.c
> @@ -9,9 +9,10 @@
> #include
> #include
>
> -static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
> - dma_addr_t addr, u16 len, bool end)
> +void sdhci_adma_write_desc(struct sdhci_host *host, void **next_desc,
> +dma_addr_t addr, int len, bool end)
> {
> + struct sdhci_adma_desc *desc = *next_desc;
> u8 attr;
>
> attr = ADMA_DESC_ATTR_VALID | ADMA_DESC_TRANSFER_DATA;
> @@ -19,17 +20,30 @@ static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
> attr |= ADMA_DESC_ATTR_END;
>
> desc->attr = attr;
> - desc->len = len;
> + desc->len = len & 0x;
> desc->reserved = 0;
> desc->addr_lo = lower_32_bits(addr);
> #ifdef CONFIG_DMA_ADDR_T_64BIT
> desc->addr_hi = upper_32_bits(addr);
> #endif
> +
> + *next_desc += ADMA_DESC_LEN;
> +}
> +
> +static inline void __sdhci_adma_write_desc(struct sdhci_host *host,
> +void **desc, dma_addr_t addr,
> +int len, bool end)
> +{
> + if (host && host->ops && host->ops->adma_write_desc)
> + host->ops->adma_write_desc(host, desc, addr, len, end);
> + else
> + sdhci_adma_write_desc(host, desc, addr, len, end);
> }
>
> /**
> * sdhci_prepare_adma_table() - Populate the ADMA table
> *
> + * @host:Pointer to the sdhci_host
> * @table: Pointer to the ADMA table
> * @data:Pointer to MMC data
> * @addr:DMA address to write to or read from
> @@ -39,25 +53,26 @@ static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
> * Please note, that the table size depends on CONFIG_SYS_MMC_MAX_BLK_COUNT
> and
> * we don't have to check for overflow.
> */
> -void sdhci_prepare_adma_table(struct sdhci_adma_desc *table,
> - struct mmc_data *data, dma_addr_t addr)
> +void sdhci_prepare_adma_table(struct sdhci_host *host,
> + struct sdhci_adma_desc *table,
> + struct mmc_data *data, dma_addr_t start_addr)
> {
> + dma_addr_t addr = start_addr;
> uint trans_bytes = data->blocksize * data-&g
RE: [PATCH] mmc: cv1800b: Add transmit tap delay config to fix write error
Hi,
> -Original Message-
> From: Kongyang Liu
> Sent: Tuesday, April 16, 2024 4:31 PM
> To: u-boot@lists.denx.de
> Cc: Jaehoon Chung ; Leo Yu-Chi Liang
> ; Peng Fan
> ; Tom Rini
> Subject: [PATCH] mmc: cv1800b: Add transmit tap delay config to fix write
> error
>
> Currently, only the receive delay is configured while the transmit delay
> is not set, which may result in errors when writing to the file. This issue
> can be resolved by setting PHY_TX_SRC_INVERT to SDHCI_PHY_TX_RX_DLY.
>
> Signed-off-by: Kongyang Liu
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> drivers/mmc/cv1800b_sdhci.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/cv1800b_sdhci.c b/drivers/mmc/cv1800b_sdhci.c
> index 2275c53777..a50f4cff0d 100644
> --- a/drivers/mmc/cv1800b_sdhci.c
> +++ b/drivers/mmc/cv1800b_sdhci.c
> @@ -12,6 +12,8 @@
> #define MMC_MAX_CLOCK37500
> #define TUNE_MAX_PHCODE 128
>
> +#define PHY_TX_SRC_INVERT BIT(8)
> +
> struct cv1800b_sdhci_plat {
> struct mmc_config cfg;
> struct mmc mmc;
> @@ -19,7 +21,7 @@ struct cv1800b_sdhci_plat {
>
> static void cv1800b_set_tap_delay(struct sdhci_host *host, u16 tap)
> {
> - sdhci_writel(host, tap << 16, SDHCI_PHY_TX_RX_DLY);
> + sdhci_writel(host, PHY_TX_SRC_INVERT | tap << 16, SDHCI_PHY_TX_RX_DLY);
> }
>
> static void cv1800b_sdhci_reset(struct sdhci_host *host, u8 mask)
> --
> 2.41.0
RE: [PATCH 2/2] mmc: Add support for the no-mmc-hs400 prop
Hi
> -Original Message-
> From: Jonas Karlman
> Sent: Tuesday, April 9, 2024 6:06 AM
> To: Peng Fan ; Jaehoon Chung ; Tom
> Rini
> Cc: Jonas Karlman ; u-boot@lists.denx.de
> Subject: [PATCH 2/2] mmc: Add support for the no-mmc-hs400 prop
>
> The linux commit f722e650d965 ("mmc: core: add support for disabling
> HS400 mode via DT") added support for a no-mmc-hs400 prop.
>
> Add support for the no-mmc-hs400 prop to disable HS400 host caps.
>
> Signed-off-by: Jonas Karlman
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/mmc-uclass.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 1349da72b102..1b454e8ec758 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -256,6 +256,9 @@ int mmc_of_parse(struct udevice *dev, struct mmc_config
> *cfg)
> cfg->host_caps |= MMC_CAP(MMC_HS_400) | MMC_CAP(MMC_HS_200);
> if (dev_read_bool(dev, "mmc-hs400-enhanced-strobe"))
> cfg->host_caps |= MMC_CAP(MMC_HS_400_ES);
> + if (dev_read_bool(dev, "no-mmc-hs400"))
> + cfg->host_caps &= ~(MMC_CAP(MMC_HS_400) |
> + MMC_CAP(MMC_HS_400_ES));
>
> if (dev_read_bool(dev, "non-removable")) {
> cfg->host_caps |= MMC_CAP_NONREMOVABLE;
> --
> 2.43.2
RE: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux
Hi, > -Original Message- > From: Quentin Schulz > Sent: Wednesday, April 10, 2024 5:57 PM > To: Dragan Simic > Cc: Jonas Karlman ; Peng Fan ; Jaehoon > Chung > ; Tom Rini ; u-boot@lists.denx.de > Subject: Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match > linux > > Hi Dragan, > > On 4/9/24 21:28, Dragan Simic wrote: > > [...] > > > Let's keep in mind that the troublesome DT properties describe the > > capabilities of the MMC controller and the board, not the capabilities > > of the MMC storage device. As we know, eMMC devices provide automatic > > detection capabilities, to allow the host to determine its supported > > modes, and match them with the ones the host is configured to support. > > It's all described in the JEDEC standards. > > I didn't see the above mail in my mailbox. So I can miss something. > > So why do we have those properties specified in board DTSes instead of > in the SoC DTSI? Logic would want us to have this defined in one place > only. I assume the issue is that even if the eMMC chip itself says it > supports HS400 but the HW routing or some other issue make it impossible > to use, we need a way to disable it from the DT for that board? > > > Having that in mind, I find the approach in the Linux kernel rather > > reasonable, because I highly doubt that some MMC controllers support, > > for example, HS400 without supporting DDR52, or HS400 without supporting > > DDR52. A reasonable approach for an MMC IP block is to make it capable > > of supporting all the speeds below its highest supported speed, to make > > itself capable of supporting more, if not all, MMC storage devices. > > > > That's true for the IP block which is self-contained in the SoC, but > it's forgetting about the other part, the eMMC chip/card. It depends on > the HW routing, where mistakes/limitations can happen. And I don't think > we have a mechanism today to disable the modes set in the MMC controller > for a given MMC card from DT (aside from /delete-property/ in board files). The both opinions make sense. But, It doesn't set to all capabilities when nodes has mmc-hs400-* property. That's why it's describing to each property is because they want to clarify only which mode they use. AFAIK, I can't remember exactly, there were some boards that even though HS400 is working fine, but HS200 was not working fine. (It's depends on which IP board is using.) There were too many cases not to work fine because of *HW* design. eMMC and Host IP were supporting the HS400/200 and all modes, but there was a problem of handling clock. So it couldn't use HS200/400 and other dual modes. And We needs to know if it's working fine. If we want to use hs400 mode, but board can be working to other mode without any error. Of course, we can see a mode as log. But it's at least approach to limit. Best Regards, Jaehoon Chung > > > In fact, I'll probably go ahead and submit a Linux kernel patch that > > updates the descriptions in the binding, to hopefully eliminate any > > ambiguities like these. I hope you agree. > > I for sure do not have enough knowledge in MMC to argue more than I just > did, so having people with more experience/knowledge have a look at this > would make sense, let's see what they have to say :) > > Cheers, > Quentin
RE: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux
Hi, > -Original Message- > From: Quentin Schulz > Sent: Wednesday, April 10, 2024 12:27 AM > To: Jonas Karlman ; Peng Fan ; Jaehoon > Chung > ; Tom Rini > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match > linux > > Hi Jonas, > > On 4/8/24 23:06, Jonas Karlman wrote: > > eMMC nodes in linux device tree files typically only contain a mmc-hs400 > > prop to signal support for both HS400 and HS200. However, U-Boot require > > an explicit mmc-hs200 prop to signal support for the HS200 mode. > > > Fix this by follow linux and imply HS200 cap when HS400 cap is signaled > > using a mmc-hs400 prop. > > > > Technically speaking, the DT binding should be the one and only source > of truth and should be implementation-agnostic. > > There it says: > """ >mmc-hs400-1_2v: > $ref: /schemas/types.yaml#/definitions/flag > description: >eMMC HS400 mode (1.2V I/O) is supported. > >mmc-hs400-1_8v: > $ref: /schemas/types.yaml#/definitions/flag > description: >eMMC HS400 mode (1.8V I/O) is supported. > """ > > So I'd say, the DTs should be fixed to add mmc-hs200 as well wherever it > makes sense. > > The point of the DT/DT binding is to be system-agnostic and > representative of the **HW** implementation. At least that's what the DT > people want it to be. > > If the eMMC standard doesn't allow to have HS400 without HS200, then I > think this change is acceptable as is, because it is the reality of the > HW standard. Couldn't find this implied in the standard though (but I > just skimmed through). > > It's also quite surprising, as it's not because the eMMC works with > HS400 that it necessarily does with HS200 or that it's desired (EMI, > signal integrity/stability, etc...)? > > Now, it wouldn't be the first time U-Boot follows whatever is done in > Linux, so... up to you/the maintainers :) I want to follow the linux kernel. > > Reviewed-by: Quentin Schulz Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > > Cheers, > Quentin
RE: [PATCH v2] mmc: arm_pl180: Limit data transfer to U16_MAX
> -Original Message-
> From: c...@mailbox.org
> Sent: Monday, April 15, 2024 6:53 PM
> To: u-boot@lists.denx.de
> Cc: Maximilian Brune ; Peng Fan
> ; Jaehoon Chung
>
> Subject: [PATCH v2] mmc: arm_pl180: Limit data transfer to U16_MAX
>
> From: Maximilian Brune
>
> Currently fetching files bigger that cause a data transfer greater than
> U16_MAX fails.
>
> The reason is that the specification defines the datalength register
> as a 16 bit wide register, but in u-boot it is used as if it is an
> 32 bit register. Therefore values greater than U16_MAX cause an
> infinite loop inside u-boot. U-boot expects to get more data from
> interface/hardware then it will ever get and therefore inifintely waits
> for more data that will never come.
>
> Signed-off-by: Maximilian Brune
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> Cc: Peng Fan
> Cc: Jaehoon Chung
> ---
> drivers/mmc/arm_pl180_mmci.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
> index 2666b65362..cecc7ad783 100644
> --- a/drivers/mmc/arm_pl180_mmci.c
> +++ b/drivers/mmc/arm_pl180_mmci.c
> @@ -229,6 +229,7 @@ static int do_data_transfer(struct mmc *dev,
> u32 blksz = 0;
> u32 data_ctrl = 0;
> u32 data_len = (u32) (data->blocks * data->blocksize);
> + assert(data_len < U16_MAX); /* should be ensured by arm_pl180_get_b_max
> */
>
> if (!host->version2) {
> blksz = (ffs(data->blocksize) - 1);
> @@ -356,6 +357,14 @@ static int host_set_ios(struct mmc *dev)
> return 0;
> }
>
> +static int arm_pl180_get_b_max(struct udevice *dev, void *dst, lbaint_t
> blkcnt)
> +{
> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct mmc *mmc = upriv->mmc;
> +
> + return U16_MAX / mmc->read_bl_len;
> +}
> +
> static void arm_pl180_mmc_init(struct pl180_mmc_host *host)
> {
> u32 sdi_u32;
> @@ -470,6 +479,7 @@ static const struct dm_mmc_ops arm_pl180_dm_mmc_ops = {
> .send_cmd = dm_host_request,
> .set_ios = dm_host_set_ios,
> .get_cd = dm_mmc_getcd,
> + .get_b_max = arm_pl180_get_b_max,
> };
>
> static int arm_pl180_mmc_of_to_plat(struct udevice *dev)
> --
> 2.44.0
RE: [PATCH] mmc: sdhci: programmable clock calculation needs multiplier +1
> -Original Message-
> From: curtis.mach...@intel.com
> Sent: Saturday, April 13, 2024 4:27 AM
> To: u-boot@lists.denx.de; Peng Fan ; Jaehoon Chung
>
> Cc: cmachida ; Jonas Karlman ;
> Kever Yang chips.com>; Peter Geis ; Sean Anderson
> ; Simon Glass
> ; Tom Rini
> Subject: [PATCH] mmc: sdhci: programmable clock calculation needs multiplier
> +1
>
> From: cmachida
>
> According to the SD Host Controller Simplified Specification v4.20,
> the multiplier value M is one more than the Clock Multiplier field.
>
> Copied code from Linux project. drivers/mmc/host/sdhci.c line 4405
>
> Signed-off-by: cmachida
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> drivers/mmc/sdhci.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index 0178ed8a11..a8476ec4e9 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -929,6 +929,15 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
> sdhci_host *host,
> debug("%s, caps_1: 0x%x\n", __func__, caps_1);
> host->clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >>
> SDHCI_CLOCK_MUL_SHIFT;
> +
> + /*
> + * In case the value in Clock Multiplier is 0, then programmable
> + * clock mode is not supported, otherwise the actual clock
> + * multiplier is one more than the value of Clock Multiplier
> + * in the Capabilities Register.
> + */
> + if (host->clk_mul)
> + host->clk_mul += 1;
> }
>
> if (host->max_clk == 0) {
> --
> 2.43.2
[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. BTW, I'm checking other pending patches in more detail. After checking, I will apply them into u-boot-mmc. Sorry for too late. Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/20345 The following changes since commit b03b49046af5dfca599d2ce8f0aafed89b97aa91: Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2024-04-14 15:58:31 -0600) 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 3657ef738ad6aa2c32c569e7ae67a5557343f7d0: mmc: cv1800b_sdhci: Remove the unused argument (2024-04-15 17:58:59 +0900) Heinrich Schuchardt (2): mmc: Avoid buffer overrun in mmc_startup() mmc: Don't suggest to build modules in Kconfig. Jaehoon Chung (1): mmc: cv1800b_sdhci: Remove the unused argument Jonas Karlman (1): mmc: Add SPL_MMC_PWRSEQ to fix link issue when building SPL Linus Walleij (1): mmc: arm_pl180_mmci: Rely on DM Marek Vasut (7): mmc: Drop unused mmc_send_tuning() cmd_error parameter mmc: tmio: Check INFO1 for completion during DMA transfer mmc: renesas-sdhi: Stop transmission in case tuning block transfer fails mmc: Convert hs400_tuning flag from u8 to bool mmc: Add generic tuning flag mmc: renesas-sdhi: Do not access SCC during tuning in send_cmd callback mmc: Unconditionally call mmc_deinit() Yang Xiwen (3): mmc: hi6220-dwmmc: handle clocks and resets if CONFIG_CLK and CONFIG_DM_RESET enabled mmc: dw_mmc: Don't return error if data busy timeout mmc: hi6220_dw_mmc: add fifoth_val to private data and set it in .probe drivers/mmc/Kconfig | 23 +- drivers/mmc/Makefile | 2 +- drivers/mmc/am654_sdhci.c | 2 +- drivers/mmc/arm_pl180_mmci.c | 66 ++- drivers/mmc/cv1800b_sdhci.c | 2 +- drivers/mmc/dw_mmc.c | 4 +-- drivers/mmc/fsl_esdhc.c | 2 +- drivers/mmc/fsl_esdhc_imx.c | 2 +- drivers/mmc/hi6220_dw_mmc.c | 72 +-- drivers/mmc/meson_gx_mmc.c| 2 +- drivers/mmc/mmc-uclass.c | 21 + drivers/mmc/mmc.c | 38 +-- drivers/mmc/mtk-sd.c | 21 ++--- drivers/mmc/octeontx_hsmmc.c | 8 - drivers/mmc/omap_hsmmc.c | 6 ++-- drivers/mmc/renesas-sdhi.c| 21 +++-- drivers/mmc/rockchip_dw_mmc.c | 2 +- drivers/mmc/sdhci-cadence.c | 2 +- drivers/mmc/tmio-common.c | 8 - include/mmc.h | 9 +++--- 20 files changed, 179 insertions(+), 134 deletions(-)
RE: [PATCH] mmc: cv1800b_sdhci: Remove the unused argument
Hi,
> -Original Message-
> From: Jaehoon Chung
> Sent: Monday, April 15, 2024 4:57 PM
> To: u-boot@lists.denx.de
> Cc: tr...@konsulko.com; ycli...@andestech.com; Jaehoon Chung
>
> Subject: [PATCH] mmc: cv1800b_sdhci: Remove the unused argument
>
> Remove the unused argument about cmd_error.
>
> Fixes: a3b2786651c7 ("mmc: Drop unused mmc_send_tuning() cmd_error parameter")
>
> Signed-off-by: Jaehoon Chung
This patch is based on u-boot-mmc/master.
Best Regards,
Jaehoon Chung
>
> ---
> drivers/mmc/cv1800b_sdhci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/cv1800b_sdhci.c b/drivers/mmc/cv1800b_sdhci.c
> index 2275c5377723..9af6b9719844 100644
> --- a/drivers/mmc/cv1800b_sdhci.c
> +++ b/drivers/mmc/cv1800b_sdhci.c
> @@ -42,7 +42,7 @@ static int cv1800b_execute_tuning(struct mmc *mmc, u8
> opcode)
> for (tap = 0; tap < TUNE_MAX_PHCODE; tap++) {
> cv1800b_set_tap_delay(host, tap);
>
> - if (mmc_send_tuning(host->mmc, opcode, NULL)) {
> + if (mmc_send_tuning(host->mmc, opcode)) {
> current_size = 0;
> } else {
> current_size++;
> --
> 2.25.1
[PATCH] mmc: cv1800b_sdhci: Remove the unused argument
Remove the unused argument about cmd_error.
Fixes: a3b2786651c7 ("mmc: Drop unused mmc_send_tuning() cmd_error parameter")
Signed-off-by: Jaehoon Chung
1
---
drivers/mmc/cv1800b_sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/cv1800b_sdhci.c b/drivers/mmc/cv1800b_sdhci.c
index 2275c5377723..9af6b9719844 100644
--- a/drivers/mmc/cv1800b_sdhci.c
+++ b/drivers/mmc/cv1800b_sdhci.c
@@ -42,7 +42,7 @@ static int cv1800b_execute_tuning(struct mmc *mmc, u8 opcode)
for (tap = 0; tap < TUNE_MAX_PHCODE; tap++) {
cv1800b_set_tap_delay(host, tap);
- if (mmc_send_tuning(host->mmc, opcode, NULL)) {
+ if (mmc_send_tuning(host->mmc, opcode)) {
current_size = 0;
} else {
current_size++;
--
2.25.1
RE: [PATCH v2] mmc: arm_pl180: Limit data transfer to U16_MAX
Hi,
> -Original Message-
> From: c...@mailbox.org
> Sent: Thursday, April 4, 2024 3:58 PM
> To: u-boot@lists.denx.de
> Cc: Maximilian Brune ; Peng Fan
> ; Jaehoon Chung
>
> Subject: [PATCH v2] mmc: arm_pl180: Limit data transfer to U16_MAX
>
> From: Maximilian Brune
>
> Currently fetching files bigger that cause a data transfer greater than
> U16_MAX fails.
>
> The reason is that the specification defines the datalength register
> as a 16 bit wide register, but in u-boot it is used as if it is an
> 32 bit register. Therefore values greater than U16_MAX cause an
> infinite loop inside u-boot. U-boot expects to get more data from
> interface/hardware then it will ever get and therefore inifintely waits
> for more data that will never come.
>
> Signed-off-by: Maximilian Brune
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> Cc: Peng Fan
> Cc: Jaehoon Chung
> ---
> drivers/mmc/arm_pl180_mmci.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
> index 5cf5502ed5..cad73ea106 100644
> --- a/drivers/mmc/arm_pl180_mmci.c
> +++ b/drivers/mmc/arm_pl180_mmci.c
> @@ -231,6 +231,7 @@ static int do_data_transfer(struct mmc *dev,
> u32 blksz = 0;
> u32 data_ctrl = 0;
> u32 data_len = (u32) (data->blocks * data->blocksize);
> + assert(data_len < U16_MAX); /* should be ensured by arm_pl180_get_b_max
> */
>
> if (!host->version2) {
> blksz = (ffs(data->blocksize) - 1);
> @@ -358,6 +359,14 @@ static int host_set_ios(struct mmc *dev)
> return 0;
> }
>
> +static int arm_pl180_get_b_max(struct udevice *dev, void *dst, lbaint_t
> blkcnt)
> +{
> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct mmc *mmc = upriv->mmc;
> +
> + return U16_MAX / mmc->read_bl_len;
> +}
> +
> #ifndef CONFIG_DM_MMC
> /* MMC uses open drain drivers in the enumeration phase */
> static int mmc_host_reset(struct mmc *dev)
> @@ -373,6 +382,7 @@ static const struct mmc_ops arm_pl180_mmci_ops = {
> .send_cmd = host_request,
> .set_ios = host_set_ios,
> .init = mmc_host_reset,
> + .get_b_max = arm_pl180_get_b_max,
> };
>
> /*
> @@ -531,6 +541,7 @@ static const struct dm_mmc_ops arm_pl180_dm_mmc_ops = {
> .send_cmd = dm_host_request,
> .set_ios = dm_host_set_ios,
> .get_cd = dm_mmc_getcd,
> + .get_b_max = arm_pl180_get_b_max,
> };
>
> static int arm_pl180_mmc_of_to_plat(struct udevice *dev)
> --
> 2.44.0
RE: [PATCH v2 3/3] mmc: hi6220_dw_mmc: add fifoth_val to private data and set it in .probe
Hi,
> -Original Message-
> From: Yang Xiwen
> Sent: Wednesday, April 3, 2024 10:22 AM
> To: Jaehoon Chung ; Peng Fan
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH v2 3/3] mmc: hi6220_dw_mmc: add fifoth_val to private
> data and set it in .probe
>
> On 4/3/2024 8:43 AM, Jaehoon Chung wrote:
> > Hi
> >
> > On 2/1/24 23:05, Yang Xiwen via B4 Relay wrote:
> >> From: Yang Xiwen
> >>
> >> The value defaults to 0 and is ignored by dw_mmc code, so the other
> >> users are not affected.
> >>
> >> Setting this explicitly fixes some weird reading error found on
> >> Hi3798MV200.
> >>
> >> Fixes: 8a5dc8140e62 ("mmc: hi6220_dw_mmc: add compatible for HC2910
> >> support")
> >>
> >> Signed-off-by: Yang Xiwen
Reviewed-by: Jaehoon Chung
> >> ---
> >> drivers/mmc/hi6220_dw_mmc.c | 11 ++-
> >> 1 file changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mmc/hi6220_dw_mmc.c b/drivers/mmc/hi6220_dw_mmc.c
> >> index a4b8072976..dc0210402b 100644
> >> --- a/drivers/mmc/hi6220_dw_mmc.c
> >> +++ b/drivers/mmc/hi6220_dw_mmc.c
> >> @@ -37,6 +37,7 @@ struct hi6220_dwmmc_priv_data {
> >> struct hisi_mmc_data {
> >>unsigned int clock;
> >>bool use_fifo;
> >> + u32 fifoth_val;
> >> };
> >>
> >> static int hi6220_dwmmc_of_to_plat(struct udevice *dev)
> >> @@ -125,6 +126,7 @@ static int hi6220_dwmmc_probe(struct udevice *dev)
> >>host->mmc = >mmc;
> >>
> >>host->fifo_mode = mmc_data->use_fifo;
> >> + host->fifoth_val = mmc_data->fifoth_val;
> >>host->mmc->priv = >host;
> >>upriv->mmc = host->mmc;
> >>host->mmc->dev = dev;
> >> @@ -154,13 +156,20 @@ static const struct hisi_mmc_data hi6220_mmc_data = {
> >>.use_fifo = false,
> >> };
> >>
> >> +static const struct hisi_mmc_data hi3798mv2x_mmc_data = {
> >> + .clock = 5000,
> >> + .use_fifo = false,
> >> + // FIFO depth is 256
> > Removed unnecessary comment.
>
>
> Will do. It seems that this should also apply to hi3798cv200-dw-mshc.
> tests are needed from cv200 users.
In future, It can be removed. Others looks good to me.
Best Regards,
Jaehoon Chung
>
>
> >
> > Best Regards,
> > Jaehoon Chung
> >
> >> + .fifoth_val = MSIZE(4) | RX_WMARK(0x7f) | TX_WMARK(0x80),
> >> +};
> >> +
> >> static const struct udevice_id hi6220_dwmmc_ids[] = {
> >>{ .compatible = "hisilicon,hi6220-dw-mshc",
> >> .data = (ulong)_mmc_data },
> >>{ .compatible = "hisilicon,hi3798cv200-dw-mshc",
> >> .data = (ulong)_mmc_data },
> >>{ .compatible = "hisilicon,hi3798mv200-dw-mshc",
> >> -.data = (ulong)_mmc_data },
> >> +.data = (ulong)_mmc_data },
> >>{ .compatible = "hisilicon,hi3660-dw-mshc",
> >> .data = (ulong)_mmc_data },
> >>{ }
>
>
> --
> Regards,
> Yang Xiwen
RE: [PATCH v2 2/3] mmc: dw_mmc: Don't return error if data busy timeout
Hi,
> -Original Message-
> From: Yang Xiwen
> Sent: Wednesday, April 3, 2024 10:20 AM
> To: Jaehoon Chung ; Peng Fan
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH v2 2/3] mmc: dw_mmc: Don't return error if data busy
> timeout
>
> On 4/3/2024 8:41 AM, Jaehoon Chung wrote:
> > Hi,
> >
> > On 2/1/24 23:05, Yang Xiwen via B4 Relay wrote:
> >> From: Yang Xiwen
> >>
> >> As described in [1], some poor hardware or cards would fail to release
> >> the bus and keep driving data lines low. Ignore it and send the next cmd
> >> directly seems okay for most cases.
> > This patch seems to be same with previous patch, right?
>
>
> From my observation, this patch does fix some weird problems and is
> mostly okay for other dwmmc users. I can't say it is very well tested
> because of I can't come up of other tests i can do except some `mmc
> read` and `mmc write`.
>
>
> >
> > Best Regards,
> > Jaehoon Chung
> >
> >> [1]:
> >> https://patchwork.kernel.org/project/linux-mmc/patch/1424458179-5456-1-git-send-email-
> diand...@chromium.org/
> >>
> >> Signed-off-by: Yang Xiwen
Tested-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> >> ---
> >> drivers/mmc/dw_mmc.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> >> index 400066fa99..e103664145 100644
> >> --- a/drivers/mmc/dw_mmc.c
> >> +++ b/drivers/mmc/dw_mmc.c
> >> @@ -262,8 +262,8 @@ static int dwmci_send_cmd(struct mmc *mmc, struct
> >> mmc_cmd *cmd,
> >>
> >>while (dwmci_readl(host, DWMCI_STATUS) & DWMCI_BUSY) {
> >>if (get_timer(start) > timeout) {
> >> - debug("%s: Timeout on data busy\n", __func__);
> >> - return -ETIMEDOUT;
> >> + debug("%s: Timeout on data busy, continue anyway\n",
> >> __func__);
> >> + break;
> >>}
> >>}
> >>
>
>
> --
> Regards,
> Yang Xiwen
RE: [PATCH v2 1/3] mmc: hi6220-dwmmc: handle clocks and resets if CONFIG_CLK and CONFIG_DM_RESET enabled
Hi,
> -Original Message-
> From: Yang Xiwen
> Sent: Wednesday, April 3, 2024 10:16 AM
> To: Jaehoon Chung ; Peng Fan
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH v2 1/3] mmc: hi6220-dwmmc: handle clocks and resets if
> CONFIG_CLK and
> CONFIG_DM_RESET enabled
>
> On 4/3/2024 8:39 AM, Jaehoon Chung wrote:
> > Hi,
> >
> > On 2/1/24 23:05, Yang Xiwen via B4 Relay wrote:
> >> From: Yang Xiwen
> >>
> >> This can avoid hardcoding a clock rate in driver. Also can enable the
> >> clocks and deassert the resets if the pre-bootloader does not do this
> >> for us.
> >>
> >> Currently only enabled for Hi3798MV200.
> >>
> >> Signed-off-by: Yang Xiwen
Reviewed-by: Jaehoon Chung
> >> ---
> >> drivers/mmc/hi6220_dw_mmc.c | 61
> >> -
> >> 1 file changed, 60 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mmc/hi6220_dw_mmc.c b/drivers/mmc/hi6220_dw_mmc.c
> >> index 71962cd47e..a4b8072976 100644
> >> --- a/drivers/mmc/hi6220_dw_mmc.c
> >> +++ b/drivers/mmc/hi6220_dw_mmc.c
> >> @@ -5,15 +5,24 @@
> >>*/
> >>
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> +#include
> >>
> >> DECLARE_GLOBAL_DATA_PTR;
> >>
> >> +enum hi6220_dwmmc_clk_type {
> >> + HI6220_DWMMC_CLK_BIU,
> >> + HI6220_DWMMC_CLK_CIU,
> >> + HI6220_DWMMC_CLK_CNT,
> >> +};
> >> +
> >> struct hi6220_dwmmc_plat {
> >>struct mmc_config cfg;
> >>struct mmc mmc;
> >> @@ -21,6 +30,8 @@ struct hi6220_dwmmc_plat {
> >>
> >> struct hi6220_dwmmc_priv_data {
> >>struct dwmci_host host;
> >> + struct clk *clks[HI6220_DWMMC_CLK_CNT];
> >> + struct reset_ctl_bulk rsts;
> >> };
> >>
> >> struct hisi_mmc_data {
> >> @@ -32,7 +43,29 @@ static int hi6220_dwmmc_of_to_plat(struct udevice *dev)
> >> {
> >>struct hi6220_dwmmc_priv_data *priv = dev_get_priv(dev);
> >>struct dwmci_host *host = >host;
> >> + int ret;
> > If CONFIG_CLK and DM_RESET aren't enabled, this value is a dead code.
> > It also needs to initialize.
>
>
> I think a alternative solution is replacing the if stmt below with some
> `#ifdef`s just like some unittests code. So we can mask variable `ret'
> out if it's not used However, this seems not favored by checkpatch.pl.
It's not a critical thing. If possible to change more generic, I will change
them.
Thanks!
Best Regards,
Jaehoon Chung
>
>
> >
> >>
> >> + if (CONFIG_IS_ENABLED(CLK) && CONFIG_IS_ENABLED(DM_RESET)) {
> >> + priv->clks[HI6220_DWMMC_CLK_BIU] = devm_clk_get(dev, "biu");
> >> + if (IS_ERR(priv->clks[HI6220_DWMMC_CLK_BIU])) {
> >> + ret = PTR_ERR(priv->clks[HI6220_DWMMC_CLK_BIU]);
> >> + dev_err(dev, "Failed to get BIU clock(ret = %d).\n",
> >> ret);
> >> + return log_msg_ret("clk", ret);
> >> + }
> >> +
> >> + priv->clks[HI6220_DWMMC_CLK_CIU] = devm_clk_get(dev, "ciu");
> >> + if (IS_ERR(priv->clks[HI6220_DWMMC_CLK_CIU])) {
> >> + ret = PTR_ERR(priv->clks[HI6220_DWMMC_CLK_CIU]);
> >> + dev_err(dev, "Failed to get CIU clock(ret = %d).\n",
> >> ret);
> >> + return log_msg_ret("clk", ret);
> >> + }
> >> +
> >> + ret = reset_get_bulk(dev, >rsts);
> >> + if (ret) {
> >> + dev_err(dev, "Failed to get resets(ret = %d)", ret);
> >> + return log_msg_ret("rst", ret);
> >> + }
> >> + }
> >>host->name = dev->name;
> >>host->ioaddr = dev_read_addr_ptr(dev);
> >>host->buswidth = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> >> @@ -56,11 +89,37 @@ static int hi6220_dwmmc_probe(struct udevice *dev)
> >>struct hi6220_dwmmc_priv_data *priv = dev_get_priv(dev);
> >>struct dwmci_host *host = >host;
> >>struct hisi_mmc_data *mmc_data;
> >> + int ret;
> > Ditto.
> >
> >
> &g
Re: [PATCH] mmc: arm_pl180: Limit data transfer to U16_MAX
Hi,
On 2/28/24 05:18, c...@mailbox.org wrote:
> From: max
>
> Currently fetching files bigger that cause a data transfer greater than
> U16_MAX fails.
>
> The reason is that the specification defines the datalength register
> as a 16 bit wide register, but in u-boot it is used as if it is an
> 32 bit register. Therefore values greater than U16_MAX cause an
> infinite loop inside u-boot. U-boot expects to get more data from
> interface/hardware then it will ever get and therefore inifintely waits
> for more data that will never come.
>
> Signed-off-by: max
Could you add your full name as Signed-off's tag?
> Cc: Peng Fan
> Cc: Jaehoon Chung
> ---
> drivers/mmc/arm_pl180_mmci.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
> index 5cf5502ed5..af2f9a5a84 100644
> --- a/drivers/mmc/arm_pl180_mmci.c
> +++ b/drivers/mmc/arm_pl180_mmci.c
> @@ -231,6 +231,7 @@ static int do_data_transfer(struct mmc *dev,
> u32 blksz = 0;
> u32 data_ctrl = 0;
> u32 data_len = (u32) (data->blocks * data->blocksize);
> + assert(data_len < U16_MAX); // should be ensured by arm_pl180_get_b_max
Add the comment at above with "/* ... */"
/* Should be ensured by arm_pl180_get_b_max */
assert(data_len < U16_MAX);
Best Regards,
Jaehoon Chung
>
> if (!host->version2) {
> blksz = (ffs(data->blocksize) - 1);
> @@ -358,6 +359,14 @@ static int host_set_ios(struct mmc *dev)
> return 0;
> }
>
> +static int arm_pl180_get_b_max(struct udevice *dev, void *dst, lbaint_t
> blkcnt)
> +{
> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct mmc *mmc = upriv->mmc;
> +
> + return U16_MAX / mmc->read_bl_len;
> +}
> +
> #ifndef CONFIG_DM_MMC
> /* MMC uses open drain drivers in the enumeration phase */
> static int mmc_host_reset(struct mmc *dev)
> @@ -373,6 +382,7 @@ static const struct mmc_ops arm_pl180_mmci_ops = {
> .send_cmd = host_request,
> .set_ios = host_set_ios,
> .init = mmc_host_reset,
> + .get_b_max = arm_pl180_get_b_max,
> };
>
> /*
> @@ -531,6 +541,7 @@ static const struct dm_mmc_ops arm_pl180_dm_mmc_ops = {
> .send_cmd = dm_host_request,
> .set_ios = dm_host_set_ios,
> .get_cd = dm_mmc_getcd,
> + .get_b_max = arm_pl180_get_b_max,
> };
>
> static int arm_pl180_mmc_of_to_plat(struct udevice *dev)
Re: [PATCH v2 3/3] mmc: renesas-sdhi: Do not access SCC during tuning in send_cmd callback
On 2/25/24 07:32, Marek Vasut wrote: > Do not access SCC when sending commands during tuning operation as that > will disrupt the tuning operation. The tuning operation is adjusting the > SCC settings itself in execute_tuning callback. > > When renesas_sdhi_execute_tuning() is called by the MMC core code, a loop > which consists of renesas_sdhi_prepare_tuning(), mmc_send_tuning() and > renesas_sdhi_compare_scc_data() iterates over each SCC tuning tap. > > The renesas_sdhi_prepare_tuning() configures the SCC tuning tap number into > hardware, mmc_send_tuning() triggers transfer of tuning block which depends > on the bus mode for which the bus is currently being tuned, this information > is supplied by the MMC core code, and finally renesas_sdhi_compare_scc_data() > tests the received tuning block for validity. > > Because renesas_sdhi_prepare_tuning() configures the SCC tuning tap into > the hardware to fit the tuning operation, mmc_send_tuning() which triggers > command transfer using renesas_sdhi_send_cmd() must not manipulate with > the SCC in any way. Currently renesas_sdhi_send_cmd() does unconditionally > call renesas_sdhi_check_scc_error(), which may adjust the SCC tuning tap > position by writing RENESAS_SDHI_SCC_TAPSET, which would overwrite the > required tuning configuration set by renesas_sdhi_prepare_tuning() and > disrupt the tuning operation. > > Fix this by skipping the renesas_sdhi_check_scc_error() call in case the > MMC subsystem is in tuning state. This way, the SCC settings are left > unmodified by command transfer during tuning operation. > > Reviewed-by: Paul Barker > Tested-by: Paul Barker > Signed-off-by: Marek Vasut Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > Cc: Hai Pham > Cc: Jaehoon Chung > Cc: Nobuhiro Iwamatsu > Cc: Paul Barker > Cc: Peng Fan > Cc: Sean Anderson > Cc: Tom Rini > Cc: Yoshihiro Shimoda > --- > V2: Add RB/TB from Paul > --- > drivers/mmc/renesas-sdhi.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c > index 29a742f404e..c4d0733b621 100644 > --- a/drivers/mmc/renesas-sdhi.c > +++ b/drivers/mmc/renesas-sdhi.c > @@ -798,9 +798,12 @@ static int renesas_sdhi_send_cmd(struct udevice *dev, > struct mmc_cmd *cmd, > #if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \ > CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \ > CONFIG_IS_ENABLED(MMC_HS400_SUPPORT) > + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev); > struct tmio_sd_priv *priv = dev_get_priv(dev); > + struct mmc *mmc = upriv->mmc; > > - renesas_sdhi_check_scc_error(dev); > + if (!mmc->tuning) > + renesas_sdhi_check_scc_error(dev); > > if (cmd->cmdidx == MMC_CMD_SEND_STATUS) > renesas_sdhi_adjust_hs400_mode_enable(priv);
Re: [PATCH v2 2/3] mmc: Add generic tuning flag
On 2/25/24 07:32, Marek Vasut wrote:
> Set generic mmc->tuning flag when performing tuning to indicate
> this condition to drivers. Drivers may use this to bypass various
> checks during tuning.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Cc: Hai Pham
> Cc: Jaehoon Chung
> Cc: Nobuhiro Iwamatsu
> Cc: Paul Barker
> Cc: Peng Fan
> Cc: Sean Anderson
> Cc: Tom Rini
> Cc: Yoshihiro Shimoda
> ---
> V2: Use bool var:1;
> ---
> drivers/mmc/mmc-uclass.c | 8 +++-
> include/mmc.h| 1 +
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 328456831dd..304bd5eaee2 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -124,7 +124,13 @@ static int dm_mmc_execute_tuning(struct udevice *dev,
> uint opcode)
>
> int mmc_execute_tuning(struct mmc *mmc, uint opcode)
> {
> - return dm_mmc_execute_tuning(mmc->dev, opcode);
> + int ret;
> +
> + mmc->tuning = true;
> + ret = dm_mmc_execute_tuning(mmc->dev, opcode);
> + mmc->tuning = false;
> +
> + return ret;
> }
> #endif
>
> diff --git a/include/mmc.h b/include/mmc.h
> index afca123b386..5c1be5c5b1e 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -736,6 +736,7 @@ struct mmc {
> * accessing the boot partitions
> */
> u32 quirks;
> + bool tuning:1;
> bool hs400_tuning:1;
>
> enum bus_mode user_speed_mode; /* input speed mode from user */
Re: [PATCH v2 1/3] mmc: Convert hs400_tuning flag from u8 to bool
On 2/25/24 07:32, Marek Vasut wrote:
> This hs400_tuning is a flag, make it bool. No functional change.
> This will be useful in the following patch, which adds another
> more generic flag, where the compiler can better use the space
> now reserved for the u8 to store more flags in it.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Cc: Hai Pham
> Cc: Jaehoon Chung
> Cc: Nobuhiro Iwamatsu
> Cc: Paul Barker
> Cc: Peng Fan
> Cc: Sean Anderson
> Cc: Tom Rini
> Cc: Yoshihiro Shimoda
> ---
> V2: Use bool var:1;
> ---
> drivers/mmc/mmc.c | 4 ++--
> include/mmc.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 83f9ae8bb7d..07d87c993a6 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2027,9 +2027,9 @@ static int mmc_select_hs400(struct mmc *mmc)
> mmc_set_clock(mmc, mmc->tran_speed, false);
>
> /* execute tuning if needed */
> - mmc->hs400_tuning = 1;
> + mmc->hs400_tuning = true;
> err = mmc_execute_tuning(mmc, MMC_CMD_SEND_TUNING_BLOCK_HS200);
> - mmc->hs400_tuning = 0;
> + mmc->hs400_tuning = false;
> if (err) {
> debug("tuning failed\n");
> return err;
> diff --git a/include/mmc.h b/include/mmc.h
> index 2b9a6aa8ee0..afca123b386 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -736,7 +736,7 @@ struct mmc {
> * accessing the boot partitions
> */
> u32 quirks;
> - u8 hs400_tuning;
> + bool hs400_tuning:1;
>
> enum bus_mode user_speed_mode; /* input speed mode from user */
> };
Re: [PATCH] mmc: renesas-sdhi: Stop transmission in case tuning block transfer fails
On 2/20/24 17:38, Marek Vasut wrote:
> The current code uses the state of tuning block received by SCC to
> determine whether or not to send transmission stop command. This is
> not correct. Use the state of tuning block transfer to determine
> whether or not to send transmission stop command instead, because
> the transmission stop command has to be sent in case the tuning
> block transfer failed.
>
> This requires two changes, separate variable to store and check the
> state of tuning block received by SCC, and another separate variable
> to store and check return value from transmission stop command.
>
> Signed-off-by: Marek Vasut
> Reviewed-by: Paul Barker
> Tested-by: Paul Barker
> ---
> Cc: Hai Pham
> Cc: Jaehoon Chung
> Cc: Nobuhiro Iwamatsu
> Cc: Paul Barker
> Cc: Peng Fan
> Cc: Sean Anderson
> Cc: Tom Rini
> Cc: Yoshihiro Shimoda
Reviewed-by: Jaehoon Chung
Sorry for late. Will apply to u-boot-mmc/master, Thanks!
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/renesas-sdhi.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
> index 316b75b35fe..c4d0733b621 100644
> --- a/drivers/mmc/renesas-sdhi.c
> +++ b/drivers/mmc/renesas-sdhi.c
> @@ -568,8 +568,8 @@ int renesas_sdhi_execute_tuning(struct udevice *dev, uint
> opcode)
> struct mmc *mmc = upriv->mmc;
> unsigned int tap_num;
> unsigned int taps = 0;
> - int i, ret = 0;
> - u32 caps;
> + int i, ret = 0, sret;
> + u32 caps, reg;
>
> /* Only supported on Renesas RCar */
> if (!(priv->caps & TMIO_SD_CAP_RCAR_UHS))
> @@ -612,8 +612,8 @@ int renesas_sdhi_execute_tuning(struct udevice *dev, uint
> opcode)
> if (ret == 0)
> taps |= BIT(i);
>
> - ret = renesas_sdhi_compare_scc_data(priv);
> - if (ret == 0)
> + reg = renesas_sdhi_compare_scc_data(priv);
> + if (reg == 0)
> priv->smpcmp |= BIT(i);
>
> mdelay(1);
> @@ -624,9 +624,9 @@ int renesas_sdhi_execute_tuning(struct udevice *dev, uint
> opcode)
>* eMMC.
>*/
> if (ret && (opcode == MMC_CMD_SEND_TUNING_BLOCK_HS200)) {
> - ret = mmc_send_stop_transmission(mmc, false);
> - if (ret < 0)
> - dev_dbg(dev, "Tuning abort fail (%d)\n", ret);
> + sret = mmc_send_stop_transmission(mmc, false);
> + if (sret < 0)
> + dev_dbg(dev, "Tuning abort fail (%d)\n", sret);
> }
> }
>
Re: [PATCH] mmc: tmio: Check INFO1 for completion during DMA transfer
On 2/20/24 17:38, Marek Vasut wrote:
> In case a CRC error occurs during DMA transfer, the transfer completion
> flag is not set in TMIO_SD_DMA_INFO1 and the transfer would eventually
> time out. The timeout could be very long in case the transfer consists
> of a large amount of blocks, the base timeout is 10 seconds and every
> block adds 100 us more.
>
> In case a CRC error does occur, a completion flag is set in a different
> register, TMIO_SD_INFO1. Use this other completion flag to detect DMA
> transfer ended and stop waiting for TMIO_SD_DMA_INFO1 completion flag.
> This reduces the lengthy timeout in case of an error. The unconditional
> check of TMIO_SD_DMA_INFO2 register for DMA related errors must not be
> skipped in any case to actually recognize the DMA error and report it.
>
> Signed-off-by: Marek Vasut
> Reviewed-by: Paul Barker
> Tested-by: Paul Barker
Reviewed-by: Jaehoon Chung
Sorry for late. Will apply to u-boot-mmc/master, Thanks!
Best Regards,
Jaehoon Chung
> ---
> Cc: Hai Pham
> Cc: Jaehoon Chung
> Cc: Nobuhiro Iwamatsu
> Cc: Paul Barker
> Cc: Peng Fan
> Cc: Sean Anderson
> Cc: Tom Rini
> Cc: Yoshihiro Shimoda
> ---
> drivers/mmc/tmio-common.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c
> index 890c496b535..719c4830bc3 100644
> --- a/drivers/mmc/tmio-common.c
> +++ b/drivers/mmc/tmio-common.c
> @@ -299,7 +299,13 @@ static int tmio_sd_dma_wait_for_irq(struct udevice *dev,
> u32 flag,
> struct tmio_sd_priv *priv = dev_get_priv(dev);
> long wait = 100 + 10 * blocks;
>
> - while (!(tmio_sd_readl(priv, TMIO_SD_DMA_INFO1) & flag)) {
> + for (;;) {
> + if (tmio_sd_readl(priv, TMIO_SD_DMA_INFO1) & flag)
> + break;
> +
> + if (tmio_sd_readl(priv, TMIO_SD_INFO1) & TMIO_SD_INFO1_CMP)
> + break;
> +
> if (wait-- < 0) {
> dev_err(dev, "timeout during DMA\n");
> return -ETIMEDOUT;
Re: [PATCH] mmc: arm_pl180_mmci: Rely on DM
On 2/8/24 18:33, Linus Walleij wrote:
> The PL180/MMCI driver is implied to use CONFIG_DM and the ARM
> defconfigs such as configs/vexpress_ca9x4_defconfig will get it
> as well.
>
> With a simple oneline to default to not being the v2 variant,
> the original ARM MMCI variant works fine with the driver as well.
> The IP version actually needs to be read out from a register on
> the ARM versions, but we will simply assume we are running on the
> original hardware if arm,primecell-periphid is not explicitly
> specified in the device tree.
>
> Drop the !CONFIG_DM code and depend on DM_MMC.
>
> Tested on the Versatile Express CA9x4 board.
>
> Signed-off-by: Linus Walleij
Reviewed-by: Jaehoon Chung
Sorry for late. I will apply this patch to u-boot-mmc/master. Thanks.
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/Kconfig | 1 +
> drivers/mmc/arm_pl180_mmci.c | 66
> ++--
> 2 files changed, 3 insertions(+), 64 deletions(-)
>
>
> ---
> base-commit: 0101a2ffe125911ebf89172b495f5ff14f2fd058
> change-id: 20240208-uboot-vexpress-ca9-127bd6b163df
>
> Best regards,
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 17618c3bdcc1..59716c3966e5 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -79,6 +79,7 @@ config MMC_SPI_CRC_ON
>
> config ARM_PL180_MMCI
> bool "ARM AMBA Multimedia Card Interface and compatible support"
> + depends on DM_MMC
> help
> This selects the ARM(R) AMBA(R) PrimeCell Multimedia Card
> Interface (PL180, PL181 and compatible) support.
> diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
> index 5cf5502ed545..2666b65362bc 100644
> --- a/drivers/mmc/arm_pl180_mmci.c
> +++ b/drivers/mmc/arm_pl180_mmci.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -25,8 +26,6 @@
> #include "arm_pl180_mmci.h"
> #include
>
> -#ifdef CONFIG_DM_MMC
> -#include
> #define MMC_CLOCK_MAX4800
> #define MMC_CLOCK_MIN40
>
> @@ -34,7 +33,6 @@ struct arm_pl180_mmc_plat {
> struct mmc_config cfg;
> struct mmc mmc;
> };
> -#endif
>
> static int wait_for_command_end(struct mmc *dev, struct mmc_cmd *cmd)
> {
> @@ -358,65 +356,6 @@ static int host_set_ios(struct mmc *dev)
> return 0;
> }
>
> -#ifndef CONFIG_DM_MMC
> -/* MMC uses open drain drivers in the enumeration phase */
> -static int mmc_host_reset(struct mmc *dev)
> -{
> - struct pl180_mmc_host *host = dev->priv;
> -
> - writel(host->pwr_init, >base->power);
> -
> - return 0;
> -}
> -
> -static const struct mmc_ops arm_pl180_mmci_ops = {
> - .send_cmd = host_request,
> - .set_ios = host_set_ios,
> - .init = mmc_host_reset,
> -};
> -
> -/*
> - * mmc_host_init - initialize the mmc controller.
> - * Set initial clock and power for mmc slot.
> - * Initialize mmc struct and register with mmc framework.
> - */
> -
> -int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct mmc **mmc)
> -{
> - u32 sdi_u32;
> -
> - writel(host->pwr_init, >base->power);
> - writel(host->clkdiv_init, >base->clock);
> - udelay(CLK_CHANGE_DELAY);
> -
> - /* Disable mmc interrupts */
> - sdi_u32 = readl(>base->mask0) & ~SDI_MASK0_MASK;
> - writel(sdi_u32, >base->mask0);
> -
> - host->cfg.name = host->name;
> - host->cfg.ops = _pl180_mmci_ops;
> -
> - /* TODO remove the duplicates */
> - host->cfg.host_caps = host->caps;
> - host->cfg.voltages = host->voltages;
> - host->cfg.f_min = host->clock_min;
> - host->cfg.f_max = host->clock_max;
> - if (host->b_max != 0)
> - host->cfg.b_max = host->b_max;
> - else
> - host->cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
> -
> - *mmc = mmc_create(>cfg, host);
> - if (!*mmc)
> - return -1;
> - debug("registered mmc interface number is:%d\n",
> - (*mmc)->block_dev.devnum);
> -
> - return 0;
> -}
> -#endif
> -
> -#ifdef CONFIG_DM_MMC
> static void arm_pl180_mmc_init(struct pl180_mmc_host *host)
> {
> u32 sdi_u32;
> @@ -477,7 +416,7 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
> host->version2 = true;
> break;
> default:
> - host->version2 = true;
> + host->version2 = false; /* ARM variant */
> }
>
> gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio, GPIOD_IS_IN);
> @@ -561,4 +500,3 @@ U_BOOT_DRIVER(arm_pl180_mmc) = {
> .priv_auto = sizeof(struct pl180_mmc_host),
> .plat_auto = sizeof(struct arm_pl180_mmc_plat),
> };
> -#endif
Re: [PATCH v2 3/3] mmc: hi6220_dw_mmc: add fifoth_val to private data and set it in .probe
Hi
On 2/1/24 23:05, Yang Xiwen via B4 Relay wrote:
> From: Yang Xiwen
>
> The value defaults to 0 and is ignored by dw_mmc code, so the other
> users are not affected.
>
> Setting this explicitly fixes some weird reading error found on Hi3798MV200.
>
> Fixes: 8a5dc8140e62 ("mmc: hi6220_dw_mmc: add compatible for HC2910 support")
>
> Signed-off-by: Yang Xiwen
> ---
> drivers/mmc/hi6220_dw_mmc.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/hi6220_dw_mmc.c b/drivers/mmc/hi6220_dw_mmc.c
> index a4b8072976..dc0210402b 100644
> --- a/drivers/mmc/hi6220_dw_mmc.c
> +++ b/drivers/mmc/hi6220_dw_mmc.c
> @@ -37,6 +37,7 @@ struct hi6220_dwmmc_priv_data {
> struct hisi_mmc_data {
> unsigned int clock;
> bool use_fifo;
> + u32 fifoth_val;
> };
>
> static int hi6220_dwmmc_of_to_plat(struct udevice *dev)
> @@ -125,6 +126,7 @@ static int hi6220_dwmmc_probe(struct udevice *dev)
> host->mmc = >mmc;
>
> host->fifo_mode = mmc_data->use_fifo;
> + host->fifoth_val = mmc_data->fifoth_val;
> host->mmc->priv = >host;
> upriv->mmc = host->mmc;
> host->mmc->dev = dev;
> @@ -154,13 +156,20 @@ static const struct hisi_mmc_data hi6220_mmc_data = {
> .use_fifo = false,
> };
>
> +static const struct hisi_mmc_data hi3798mv2x_mmc_data = {
> + .clock = 5000,
> + .use_fifo = false,
> + // FIFO depth is 256
Removed unnecessary comment.
Best Regards,
Jaehoon Chung
> + .fifoth_val = MSIZE(4) | RX_WMARK(0x7f) | TX_WMARK(0x80),
> +};
> +
> static const struct udevice_id hi6220_dwmmc_ids[] = {
> { .compatible = "hisilicon,hi6220-dw-mshc",
> .data = (ulong)_mmc_data },
> { .compatible = "hisilicon,hi3798cv200-dw-mshc",
> .data = (ulong)_mmc_data },
> { .compatible = "hisilicon,hi3798mv200-dw-mshc",
> - .data = (ulong)_mmc_data },
> + .data = (ulong)_mmc_data },
> { .compatible = "hisilicon,hi3660-dw-mshc",
> .data = (ulong)_mmc_data },
> { }
Re: [PATCH v2 2/3] mmc: dw_mmc: Don't return error if data busy timeout
Hi,
On 2/1/24 23:05, Yang Xiwen via B4 Relay wrote:
> From: Yang Xiwen
>
> As described in [1], some poor hardware or cards would fail to release
> the bus and keep driving data lines low. Ignore it and send the next cmd
> directly seems okay for most cases.
This patch seems to be same with previous patch, right?
Best Regards,
Jaehoon Chung
>
> [1]:
> https://patchwork.kernel.org/project/linux-mmc/patch/1424458179-5456-1-git-send-email-diand...@chromium.org/
>
> Signed-off-by: Yang Xiwen
> ---
> drivers/mmc/dw_mmc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 400066fa99..e103664145 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -262,8 +262,8 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
> *cmd,
>
> while (dwmci_readl(host, DWMCI_STATUS) & DWMCI_BUSY) {
> if (get_timer(start) > timeout) {
> - debug("%s: Timeout on data busy\n", __func__);
> - return -ETIMEDOUT;
> + debug("%s: Timeout on data busy, continue anyway\n",
> __func__);
> + break;
> }
> }
>
Re: [PATCH v2 1/3] mmc: hi6220-dwmmc: handle clocks and resets if CONFIG_CLK and CONFIG_DM_RESET enabled
Hi,
On 2/1/24 23:05, Yang Xiwen via B4 Relay wrote:
> From: Yang Xiwen
>
> This can avoid hardcoding a clock rate in driver. Also can enable the
> clocks and deassert the resets if the pre-bootloader does not do this
> for us.
>
> Currently only enabled for Hi3798MV200.
>
> Signed-off-by: Yang Xiwen
> ---
> drivers/mmc/hi6220_dw_mmc.c | 61
> -
> 1 file changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/hi6220_dw_mmc.c b/drivers/mmc/hi6220_dw_mmc.c
> index 71962cd47e..a4b8072976 100644
> --- a/drivers/mmc/hi6220_dw_mmc.c
> +++ b/drivers/mmc/hi6220_dw_mmc.c
> @@ -5,15 +5,24 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +enum hi6220_dwmmc_clk_type {
> + HI6220_DWMMC_CLK_BIU,
> + HI6220_DWMMC_CLK_CIU,
> + HI6220_DWMMC_CLK_CNT,
> +};
> +
> struct hi6220_dwmmc_plat {
> struct mmc_config cfg;
> struct mmc mmc;
> @@ -21,6 +30,8 @@ struct hi6220_dwmmc_plat {
>
> struct hi6220_dwmmc_priv_data {
> struct dwmci_host host;
> + struct clk *clks[HI6220_DWMMC_CLK_CNT];
> + struct reset_ctl_bulk rsts;
> };
>
> struct hisi_mmc_data {
> @@ -32,7 +43,29 @@ static int hi6220_dwmmc_of_to_plat(struct udevice *dev)
> {
> struct hi6220_dwmmc_priv_data *priv = dev_get_priv(dev);
> struct dwmci_host *host = >host;
> + int ret;
If CONFIG_CLK and DM_RESET aren't enabled, this value is a dead code.
It also needs to initialize.
>
> + if (CONFIG_IS_ENABLED(CLK) && CONFIG_IS_ENABLED(DM_RESET)) {
> + priv->clks[HI6220_DWMMC_CLK_BIU] = devm_clk_get(dev, "biu");
> + if (IS_ERR(priv->clks[HI6220_DWMMC_CLK_BIU])) {
> + ret = PTR_ERR(priv->clks[HI6220_DWMMC_CLK_BIU]);
> + dev_err(dev, "Failed to get BIU clock(ret = %d).\n",
> ret);
> + return log_msg_ret("clk", ret);
> + }
> +
> + priv->clks[HI6220_DWMMC_CLK_CIU] = devm_clk_get(dev, "ciu");
> + if (IS_ERR(priv->clks[HI6220_DWMMC_CLK_CIU])) {
> + ret = PTR_ERR(priv->clks[HI6220_DWMMC_CLK_CIU]);
> + dev_err(dev, "Failed to get CIU clock(ret = %d).\n",
> ret);
> + return log_msg_ret("clk", ret);
> + }
> +
> + ret = reset_get_bulk(dev, >rsts);
> + if (ret) {
> + dev_err(dev, "Failed to get resets(ret = %d)", ret);
> + return log_msg_ret("rst", ret);
> + }
> + }
> host->name = dev->name;
> host->ioaddr = dev_read_addr_ptr(dev);
> host->buswidth = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> @@ -56,11 +89,37 @@ static int hi6220_dwmmc_probe(struct udevice *dev)
> struct hi6220_dwmmc_priv_data *priv = dev_get_priv(dev);
> struct dwmci_host *host = >host;
> struct hisi_mmc_data *mmc_data;
> + int ret;
Ditto.
Best Regards,
Jaehoon Chung
>
> mmc_data = (struct hisi_mmc_data *)dev_get_driver_data(dev);
>
> - /* Use default bus speed due to absence of clk driver */
> host->bus_hz = mmc_data->clock;
> + if (CONFIG_IS_ENABLED(CLK) && CONFIG_IS_ENABLED(DM_RESET)) {
> + ret = clk_prepare_enable(priv->clks[HI6220_DWMMC_CLK_BIU]);
> + if (ret) {
> + dev_err(dev, "Failed to enable biu clock(ret = %d).\n",
> ret);
> + return log_msg_ret("clk", ret);
> + }
> +
> + ret = clk_prepare_enable(priv->clks[HI6220_DWMMC_CLK_CIU]);
> + if (ret) {
> + dev_err(dev, "Failed to enable ciu clock(ret = %d).\n",
> ret);
> + return log_msg_ret("clk", ret);
> + }
> +
> + ret = reset_deassert_bulk(>rsts);
> + if (ret) {
> + dev_err(dev, "Failed to deassert resets(ret = %d).\n",
> ret);
> + return log_msg_ret("rst", ret);
> + }
> +
> + host->bus_hz = clk_get_rate(priv->clks[HI6220_DWMMC_CLK_CIU]);
> + if (host->bus_hz <= 0) {
> + dev_err(dev, "Failed to get ciu clock rate(ret =
> %d).\n", ret);
> + return log_msg_ret("clk", ret);
> + }
> + }
> + dev_dbg(dev, "bus clock rate: %d.\n", host->bus_hz);
>
> dwmci_setup_cfg(>cfg, host, host->bus_hz, 40);
> host->mmc = >mmc;
Re: [PATCH v2] mmc: Add SPL_MMC_PWRSEQ to fix link issue when building SPL
On 1/28/24 02:12, Jonas Karlman wrote:
> With MMC_PWRSEQ enabled the following link issue may happen when
> building SPL and SPL_PWRSEQ is not enabled.
>
> aarch64-linux-gnu-ld.bfd: drivers/mmc/meson_gx_mmc.o: in function
> `meson_mmc_probe':
> drivers/mmc/meson_gx_mmc.c:295: undefined reference to `pwrseq_set_power'
>
> Fix this by adding a SPL_MMC_PWRSEQ Kconfig option used to enable mmc
> pwrseq support in SPL.
>
> Also add depends on DM_GPIO to fix following link issue:
>
> aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.o: in function
> `mmc_pwrseq_set_power':
> drivers/mmc/mmc-pwrseq.c:26: undefined reference to `gpio_request_by_name'
> aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:29: undefined reference
> to `dm_gpio_set_value'
> aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:31: undefined reference
> to `dm_gpio_set_value'
>
> Signed-off-by: Jonas Karlman
> Reviewed-by: Kever Yang
> Reviewed-by: Neil Armstrong
> Acked-by: Ferass El Hafidi
Reviewed-by: Jaehoon Chung
Applied to u-boot-mmc/master, thanks! Sorry for late.
Best Regards,
Jaehoon Chung
> ---
> Changes in v2:
> - Fix Ths typo
> - Collect r-b and a-b tags
>
> Link to v1: https://patchwork.ozlabs.org/patch/1839392/
> ---
> drivers/mmc/Kconfig | 12 ++--
> drivers/mmc/Makefile | 2 +-
> drivers/mmc/meson_gx_mmc.c| 2 +-
> drivers/mmc/rockchip_dw_mmc.c | 2 +-
> include/mmc.h | 4 ++--
> 5 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 17618c3bdcc1..a141007a576f 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -20,11 +20,19 @@ config MMC_WRITE
>
> config MMC_PWRSEQ
> bool "HW reset support for eMMC"
> - depends on PWRSEQ
> + depends on PWRSEQ && DM_GPIO
> help
> - Ths select Hardware reset support aka pwrseq-emmc for eMMC
> + This select Hardware reset support aka pwrseq-emmc for eMMC
> devices.
>
> +config SPL_MMC_PWRSEQ
> + bool "HW reset support for eMMC in SPL"
> + depends on SPL_PWRSEQ && SPL_DM_GPIO
> + default y if MMC_PWRSEQ
> + help
> + This select Hardware reset support aka pwrseq-emmc for eMMC
> + devices in SPL.
> +
> config MMC_BROKEN_CD
> bool "Poll for broken card detection case"
> help
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index e9cf1fcc6400..2b94cc2f1c34 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -11,7 +11,7 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += mmc_bootdev.o
> endif
>
> obj-$(CONFIG_$(SPL_TPL_)MMC_WRITE) += mmc_write.o
> -obj-$(CONFIG_MMC_PWRSEQ) += mmc-pwrseq.o
> +obj-$(CONFIG_$(SPL_)MMC_PWRSEQ) += mmc-pwrseq.o
> obj-$(CONFIG_MMC_SDHCI_ADMA_HELPERS) += sdhci-adma.o
>
> ifndef CONFIG_$(SPL_)BLK
> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
> index fcf4f03d1e24..0825c0a2a838 100644
> --- a/drivers/mmc/meson_gx_mmc.c
> +++ b/drivers/mmc/meson_gx_mmc.c
> @@ -288,7 +288,7 @@ static int meson_mmc_probe(struct udevice *dev)
>
> mmc_set_clock(mmc, cfg->f_min, MMC_CLK_ENABLE);
>
> -#ifdef CONFIG_MMC_PWRSEQ
> +#if CONFIG_IS_ENABLED(MMC_PWRSEQ)
> /* Enable power if needed */
> ret = mmc_pwrseq_get_power(dev, cfg);
> if (!ret) {
> diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c
> index 72c820ee6330..ad4529d6afa8 100644
> --- a/drivers/mmc/rockchip_dw_mmc.c
> +++ b/drivers/mmc/rockchip_dw_mmc.c
> @@ -145,7 +145,7 @@ static int rockchip_dwmmc_probe(struct udevice *dev)
>
> host->fifo_mode = priv->fifo_mode;
>
> -#ifdef CONFIG_MMC_PWRSEQ
> +#if CONFIG_IS_ENABLED(MMC_PWRSEQ)
> /* Enable power if needed */
> ret = mmc_pwrseq_get_power(dev, >cfg);
> if (!ret) {
> diff --git a/include/mmc.h b/include/mmc.h
> index 1022db3ffa7c..9aef31ea5deb 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -590,7 +590,7 @@ struct mmc_config {
> uint f_max;
> uint b_max;
> unsigned char part_type;
> -#ifdef CONFIG_MMC_PWRSEQ
> +#if CONFIG_IS_ENABLED(MMC_PWRSEQ)
> struct udevice *pwr_dev;
> #endif
> };
> @@ -808,7 +808,7 @@ int mmc_deinit(struct mmc *mmc);
> */
> int mmc_of_parse(struct udevice *dev, struct mmc_config *cfg);
>
> -#ifdef CONFIG_MMC_PWRSEQ
> +#if CONFIG_IS_ENABLED(MMC_PWRSEQ)
> /**
> * mmc_pwrseq_get_power() - get a power device from device tree
> *
Re: [PATCH v2] mmc: Remove alignment hole for cmdidx in struct mmc_cmd
Hi,
On 1/28/24 01:29, Jonas Karlman wrote:
> The alignment hole caused by cmdidx in struct mmc_cmd cause strange
> issues together with the peephole2 optimization on Amlogic SoCs.
> Following was observed while working on SPL support for Amlogic SoCs.
>
> sd_get_capabilities() normally issue a CMD55 followed by a CMD51.
> However, on at least Amlogic S905 (Cortex-A53) and S905X3 (Cortex-A55),
> CMD55 was instead followed by CMD8 (and a few reties) in SPL.
I read your RFC "https://patchwork.ozlabs.org/patch/1841495/;.
First, I will retry to reproduce your case with other compiler.
After that, I will inform again about this patch.
Best Regards,
Jaehoon Chung
>
> Code from the call site:
>
> cmd.cmdidx = SD_CMD_APP_SEND_SCR; // 51
> ...
> data.blocksize = 8;
> ...
> err = mmc_send_cmd_retry(mmc, , , 3);
>
> Running the code with MMC_TRACE enabled shows:
>
> CMD_SEND:55
> ARG 0x5048
> MMC_RSP_R1,5,6,7 0x0920
> CMD_SEND:8
> ARG 0x
> RET -110
>
> Removing the alignment hole by changing cmdidx from ushort to uint or
> building with -fno-peephole2 flag seem to resolve this issue.
>
> CMD_SEND:55
> ARG 0x5048
> MMC_RSP_R1,5,6,7 0x0920
> CMD_SEND:51
> ARG 0x
> MMC_RSP_R1,5,6,7 0x0920
>
> Same issue was observed building U-Boot with gcc 8 - 13.
>
> Remove this alignment hole by changing cmdidx from ushort to uint.
>
> Signed-off-by: Jonas Karlman
> ---
> Changes in v2:
> - Drop use of -fno-peephole2 flag
>
> Link to RFC: https://patchwork.ozlabs.org/patch/1841495/
> ---
> include/mmc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/mmc.h b/include/mmc.h
> index 1022db3ffa7c..031ea0fb3545 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -413,7 +413,7 @@ struct mmc_cid {
> };
>
> struct mmc_cmd {
> - ushort cmdidx;
> + uint cmdidx;
> uint resp_type;
> uint cmdarg;
> uint response[4];
Re: [PATCH] mmc: dw_mmc: Don't return error if data busy timeout
Hi,
On 1/26/24 12:29, Yang Xiwen wrote:
> As described in [1], some poor hardware or cards would fail to release
> the bus and keep driving data lines low. Ignore it and send the next cmd
> directly seems okay for most cases.
I didn't test on my board. But it's not same with below patch.
Did you check all cases?
Best Regards,
Jaehoon Chung
>
> [1]:
> https://patchwork.kernel.org/project/linux-mmc/patch/1424458179-5456-1-git-send-email-diand...@chromium.org/
>
> Signed-off-by: Yang Xiwen
> ---
> drivers/mmc/dw_mmc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 400066fa99..e103664145 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -262,8 +262,8 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
> *cmd,
>
> while (dwmci_readl(host, DWMCI_STATUS) & DWMCI_BUSY) {
> if (get_timer(start) > timeout) {
> - debug("%s: Timeout on data busy\n", __func__);
> - return -ETIMEDOUT;
> + debug("%s: Timeout on data busy, continue anyway\n",
> __func__);
> + break;
> }
> }
>
Re: [PATCH 1/1] mmc: Don't suggest to build modules in Kconfig.
On 1/24/24 01:18, Heinrich Schuchardt wrote:
> U-Boot does not support building kernel modules.
>
> Fixes: 3c0dbed232bd ("mmc: arm_pl180_mmci: adapt driver to DM usage")
> Fixes: 36645f45a048 ("drivers: mmc: Add sdhci driver for Broadcom iProc
> platform")
> Fixes: dadd43c14368 ("mmc: synquacer: Add SynQuacer F_SDH30 SDHCI driver")
> Fixes: b312c590bcd8 ("mmc: Add MMC support for stm32h7 Socs")
> Fixes: d24b69395949 ("mmc: mtk-sd: add SD/MMC host controller driver for
> MT7623 SoC")
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Patrice Chotard
Reviewed-by: Jaehoon Chung
Applied to u-boot-mmc/master, Thanks! Sorry for late.
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/Kconfig | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index ffde442cb29..9ce331677b8 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -83,7 +83,7 @@ config ARM_PL180_MMCI
> This selects the ARM(R) AMBA(R) PrimeCell Multimedia Card
> Interface (PL180, PL181 and compatible) support.
> If you have an ARM(R) platform with a Multimedia Card slot,
> - say Y or M here.
> + say Y here.
>
> config MMC_QUIRKS
> bool "Enable quirks"
> @@ -592,7 +592,7 @@ config MMC_SDHCI_IPROC
> This selects the iProc SD/MMC controller.
>
> If you have a Broadcom IPROC platform with SD or MMC devices,
> - say Y or M here.
> + say Y here.
>
> If unsure, say N.
>
> @@ -603,7 +603,7 @@ config MMC_SDHCI_F_SDH30
> help
> This selects the Secure Digital Host Controller Interface (SDHCI)
> 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 you have a controller with this interface, say Y here.
> If unsure, say N.
>
> config MMC_SDHCI_KONA
> @@ -797,7 +797,7 @@ config STM32_SDMMC2
> help
> This selects support for the SD/MMC controller on STM32H7 SoCs.
> If you have a board based on such a SoC and with a SD/MMC slot,
> - say Y or M here.
> + say Y here.
>
> config FTSDC010
> bool "Ftsdc010 SD/MMC controller Support"
> @@ -817,7 +817,7 @@ config MMC_MTK
> depends on OF_CONTROL
> help
> This selects the MediaTek(R) Secure digital and Multimedia card
> Interface.
> - If you have a machine with a integrated SD/MMC card reader, say Y or
> M here.
> + If you have a machine with a integrated SD/MMC card reader, say Y
> here.
> This is needed if support for any SD/SDIO/MMC devices is required.
> If unsure, say N.
>
Re: [PATCH 1/1] mmc: Avoid buffer overrun in mmc_startup()
On 1/4/24 12:49, Heinrich Schuchardt wrote:
> If the CSD register contains a reserved value (4 - 7) in bits 0:2 of the
> TRAN_SPEED field, a buffer overrun occurs. Resize the mapping table.
>
> According to the original report
> https://lore.kernel.org/u-boot/20180826231332.2491-11-ero...@de.adit-jv.com/
> reserved values have been observed resulting in a buffer overrun.
>
> Reported-by: Eugeniu Rosca
> Fixes: 272cc70b211e ("Add MMC Framework")
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Jaehoon Chung
Applied to u-boot-mmc/master.
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/mmc.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index d96db7a0f8..00f4964aae 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1570,13 +1570,20 @@ static int sd_read_ssr(struct mmc *mmc)
> return 0;
> }
> #endif
> -/* frequency bases */
> -/* divided by 10 to be nice to platforms without floating point */
> +/*
> + * TRAN_SPEED bits 0:2 encode the frequency unit:
> + * 0 = 100KHz, 1 = 1MHz, 2 = 10MHz, 3 = 100MHz, values 4 - 7 are reserved.
> + * The values in fbase[] are divided by 10 to avoid floats in multiplier[].
> + */
> static const int fbase[] = {
> 1,
> 10,
> 100,
> 1000,
> + 0, /* reserved */
> + 0, /* reserved */
> + 0, /* reserved */
> + 0, /* reserved */
> };
>
> /* Multiplier values for TRAN_SPEED. Multiplied by 10 to be nice
> @@ -2560,6 +2567,8 @@ static int mmc_startup(struct mmc *mmc)
> mult = multipliers[((cmd.response[0] >> 3) & 0xf)];
>
> mmc->legacy_speed = freq * mult;
> + if (!mmc->legacy_speed)
> + log_debug("TRAN_SPEED: reserved value");
> mmc_select_mode(mmc, MMC_LEGACY);
>
> mmc->dsr_imp = ((cmd.response[1] >> 12) & 0x1);
Re: [PATCH 1/1] mmc: Avoid buffer overrun in mmc_startup()
On 1/4/24 12:49, Heinrich Schuchardt wrote:
> If the CSD register contains a reserved value (4 - 7) in bits 0:2 of the
> TRAN_SPEED field, a buffer overrun occurs. Resize the mapping table.
>
> According to the original report
> https://lore.kernel.org/u-boot/20180826231332.2491-11-ero...@de.adit-jv.com/
> reserved values have been observed resulting in a buffer overrun.
>
> Reported-by: Eugeniu Rosca
> Fixes: 272cc70b211e ("Add MMC Framework")
> Signed-off-by: Heinrich Schuchardt
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/mmc.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index d96db7a0f8..00f4964aae 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1570,13 +1570,20 @@ static int sd_read_ssr(struct mmc *mmc)
> return 0;
> }
> #endif
> -/* frequency bases */
> -/* divided by 10 to be nice to platforms without floating point */
> +/*
> + * TRAN_SPEED bits 0:2 encode the frequency unit:
> + * 0 = 100KHz, 1 = 1MHz, 2 = 10MHz, 3 = 100MHz, values 4 - 7 are reserved.
> + * The values in fbase[] are divided by 10 to avoid floats in multiplier[].
> + */
> static const int fbase[] = {
> 1,
> 10,
> 100,
> 1000,
> + 0, /* reserved */
> + 0, /* reserved */
> + 0, /* reserved */
> + 0, /* reserved */
> };
>
> /* Multiplier values for TRAN_SPEED. Multiplied by 10 to be nice
> @@ -2560,6 +2567,8 @@ static int mmc_startup(struct mmc *mmc)
> mult = multipliers[((cmd.response[0] >> 3) & 0xf)];
>
> mmc->legacy_speed = freq * mult;
> + if (!mmc->legacy_speed)
> + log_debug("TRAN_SPEED: reserved value");
> mmc_select_mode(mmc, MMC_LEGACY);
>
> mmc->dsr_imp = ((cmd.response[1] >> 12) & 0x1);
Re: [PATCH] mmc: Unconditionally call mmc_deinit()
On 12/3/23 08:39, Marek Vasut wrote:
> Place the SDR104/HS200/HS400 checks into the mmc_deinit() and always
> call it. This simplifies the code and removes ifdeffery. No functional
> change is expected.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Cc: Jaehoon Chung
> Cc: Peng Fan
> ---
> drivers/mmc/mmc-uclass.c | 13 +
> drivers/mmc/mmc.c| 9 +
> 2 files changed, 6 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 328456831dd..cdead044177 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -494,10 +494,7 @@ static int mmc_blk_probe(struct udevice *dev)
> if (ret) {
> debug("Probing %s failed (err=%d)\n", dev->name, ret);
>
> - if (CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) ||
> - CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) ||
> - CONFIG_IS_ENABLED(MMC_HS400_SUPPORT))
> - mmc_deinit(mmc);
> + mmc_deinit(mmc);
>
> return ret;
> }
> @@ -505,9 +502,6 @@ static int mmc_blk_probe(struct udevice *dev)
> return 0;
> }
>
> -#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \
> -CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
> -CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
> static int mmc_blk_remove(struct udevice *dev)
> {
> struct udevice *mmc_dev = dev_get_parent(dev);
> @@ -516,7 +510,6 @@ static int mmc_blk_remove(struct udevice *dev)
>
> return mmc_deinit(mmc);
> }
> -#endif
>
> static const struct blk_ops mmc_blk_ops = {
> .read = mmc_bread,
> @@ -532,12 +525,8 @@ U_BOOT_DRIVER(mmc_blk) = {
> .id = UCLASS_BLK,
> .ops= _blk_ops,
> .probe = mmc_blk_probe,
> -#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \
> -CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
> -CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
> .remove = mmc_blk_remove,
> .flags = DM_FLAG_OS_PREPARE,
> -#endif
> };
> #endif /* CONFIG_BLK */
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index d96db7a0f83..eb5010c1465 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -3010,13 +3010,15 @@ int mmc_init(struct mmc *mmc)
> return err;
> }
>
> -#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \
> -CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
> -CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
> int mmc_deinit(struct mmc *mmc)
> {
> u32 caps_filtered;
>
> + if (!CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) &&
> + !CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) &&
> + !CONFIG_IS_ENABLED(MMC_HS400_SUPPORT))
> + return 0;
> +
> if (!mmc->has_init)
> return 0;
>
> @@ -3034,7 +3036,6 @@ int mmc_deinit(struct mmc *mmc)
> return mmc_select_mode_and_width(mmc, caps_filtered);
> }
> }
> -#endif
>
> int mmc_set_dsr(struct mmc *mmc, u16 val)
> {
Re: [PATCH v2] mmc: sdhci-cadence: Add support for Cadence sdmmc v6
On 11/28/23 15:38, Kuan Lim Lee wrote: > Cadence SDMMC v6 controller has a lot of changes on initialize > compared to v4 controller. PHY is needed by v6 controller. > > Signed-off-by: Kuan Lim Lee > Co-developed-by: Alex Soo > Signed-off-by: Wei Liang Lim Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > Changes in v2 > - Rename file sdhci-cadence6-phy.c to sdhci-cadence6.c > - Remove CONFIG_MMC_SDHCI_CADENCE_V6 > - Rewrite code of v6 configuration part > - Add sdhci_cdns6_phy_init() function > --- > drivers/mmc/Makefile | 1 + > drivers/mmc/sdhci-cadence.c | 63 ++-- > drivers/mmc/sdhci-cadence.h | 69 > drivers/mmc/sdhci-cadence6.c | 294 +++ > 4 files changed, 376 insertions(+), 51 deletions(-) > create mode 100644 drivers/mmc/sdhci-cadence.h > create mode 100644 drivers/mmc/sdhci-cadence6.c
Re: [PATCH v2 RESEND] mmc: dw_mmc: reset controller after data error
On 6/19/23 19:33, Eugen Hristev wrote:
> From: Ziyuan Xu
>
> Per dw_mmc databook, it's recommended to reset the host controller if
> some data-related error occurred.
> Implement a reset mechanism.
>
> Signed-off-by: Ziyuan Xu
> Co-developed-by: Jason Zhu
> Signed-off-by: Jason Zhu
> [eugen.hris...@collabora.com: modified a bit the variables initialization]
> Signed-off-by: Eugen Hristev
> Reviewed-by: Kever Yang
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/dw_mmc.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 5085a3b491da..d6cad998b0cd 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -138,7 +138,7 @@ static int dwmci_data_transfer(struct dwmci_host *host,
> struct mmc_data *data)
> {
> struct mmc *mmc = host->mmc;
> int ret = 0;
> - u32 timeout, mask, size, i, len = 0;
> + u32 timeout, reset_timeout = 100, status, ctrl, mask, size, i, len = 0;
> u32 *buf = NULL;
> ulong start = get_timer(0);
> u32 fifo_depth = (((host->fifoth_val & RX_WMARK_MASK) >>
> @@ -159,6 +159,24 @@ static int dwmci_data_transfer(struct dwmci_host *host,
> struct mmc_data *data)
> /* Error during data transfer. */
> if (mask & (DWMCI_DATA_ERR | DWMCI_DATA_TOUT)) {
> debug("%s: DATA ERROR!\n", __func__);
> +
> + dwmci_wait_reset(host, DWMCI_RESET_ALL);
> + dwmci_writel(host, DWMCI_CMD, DWMCI_CMD_PRV_DAT_WAIT |
> + DWMCI_CMD_UPD_CLK | DWMCI_CMD_START);
> +
> + do {
> + status = dwmci_readl(host, DWMCI_CMD);
> + if (!reset_timeout--)
> + break;
> + udelay(100);
> + } while (status & DWMCI_CMD_START);
> +
> + if (!host->fifo_mode) {
> + ctrl = dwmci_readl(host, DWMCI_BMOD);
> + ctrl |= DWMCI_BMOD_IDMAC_RESET;
> + dwmci_writel(host, DWMCI_BMOD, ctrl);
> + }
> +
> ret = -EINVAL;
> break;
> }
Re: [PATCH v3 2/5] gpio: qcom_pmic: rework pwrkey driver into a button driver
Dear Caleb,
On 11/14/23 22:48, Caleb Connolly wrote:
> The power and resin keys were implemented as GPIOs here, but their only
> use would be as buttons. Avoid the additional layer of introspection and
> rework this driver into a button driver.
>
> While we're here, replace the "qcom,pm8998-pwrkey" compatible with
> "qcom,pm8941-pwrkey" to match upstream (Linux).
>
> The dragonboard410c and 820c boards are adjusted to benefit from this
> change too, simplify their custom board init code.
I think that this patch can be splited.
How about?
Best Regards,
Jaehoon Chung
>
> Signed-off-by: Caleb Connolly
> ---
> MAINTAINERS | 1 +
> arch/arm/dts/dragonboard410c-uboot.dtsi | 11 --
> arch/arm/dts/dragonboard410c.dts | 22 ++-
> arch/arm/dts/dragonboard820c-uboot.dtsi | 12 --
> arch/arm/dts/dragonboard820c.dts | 23 +++-
> arch/arm/dts/dragonboard845c-uboot.dtsi | 11 --
> arch/arm/dts/dragonboard845c.dts | 4 +
> arch/arm/dts/sdm845.dtsi | 23 +++-
> arch/arm/dts/starqltechn-uboot.dtsi | 10 --
> arch/arm/dts/starqltechn.dts | 20 +--
> arch/arm/mach-snapdragon/Kconfig | 3 +
> arch/arm/mach-snapdragon/init_sdm845.c | 45 ++-
> board/qualcomm/dragonboard410c/dragonboard410c.c | 31 ++---
> board/qualcomm/dragonboard820c/dragonboard820c.c | 29 ++--
> drivers/button/Kconfig | 9 ++
> drivers/button/Makefile | 1 +
> drivers/button/button-qcom-pmic.c| 165
> +++
> drivers/gpio/Kconfig | 3 +-
> drivers/gpio/qcom_pmic_gpio.c| 104 --
> 19 files changed, 269 insertions(+), 258 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f6d63c8ab563..8cd102eaa070 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -572,6 +572,7 @@ M:Neil Armstrong
> R: Sumit Garg
> S: Maintained
> F: arch/arm/mach-snapdragon/
> +F: drivers/button/button-qcom-pmic.c
> F: drivers/clk/qcom/
> F: drivers/gpio/msm_gpio.c
> F: drivers/mmc/msm_sdhci.c
> diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi
> b/arch/arm/dts/dragonboard410c-uboot.dtsi
> index 3b0bd0ed0a1b..cec64bf80f99 100644
> --- a/arch/arm/dts/dragonboard410c-uboot.dtsi
> +++ b/arch/arm/dts/dragonboard410c-uboot.dtsi
> @@ -42,14 +42,3 @@
> gpios = <_gpios 3 0>;
> };
> };
> -
> -
> -_pon {
> - key_vol_down {
> - gpios = <_pon 1 0>;
> - };
> -
> - key_power {
> - gpios = <_pon 0 0>;
> - };
> -};
> diff --git a/arch/arm/dts/dragonboard410c.dts
> b/arch/arm/dts/dragonboard410c.dts
> index 9230dd3fd96c..c41fee977813 100644
> --- a/arch/arm/dts/dragonboard410c.dts
> +++ b/arch/arm/dts/dragonboard410c.dts
> @@ -147,11 +147,23 @@
> #address-cells = <0x1>;
> #size-cells = <0x1>;
>
> - pm8916_pon: pm8916_pon@800 {
> - compatible = "qcom,pm8916-pwrkey";
> - reg = <0x800 0x96>;
> - #gpio-cells = <2>;
> - gpio-controller;
> + pon@800 {
> + compatible = "qcom,pm8916-pon";
> + reg = <0x800 0x100>;
> + mode-bootloader = <0x2>;
> + mode-recovery = <0x1>;
> +
> + pwrkey {
> + compatible =
> "qcom,pm8941-pwrkey";
> + debounce = <15625>;
> + bias-pull-up;
> + };
> +
> + pm8916_resin: resin {
> + compatible =
> "qcom,pm8941-resin";
> + debounce = <15625>;
> + bias-pull-up;
> + };
> };
>
> pm8916_gpios: pm8916_gpios@c000 {
> diff --git a/arch/arm/dts/dragonboard820c-uboot.dtsi
> b/arch/arm/dts/dragonboard820c-uboot.dtsi
> ind
Re: [PATCH] mmc: sdhci-cadence: Add support for Cadence sdmmc v6
On 11/15/23 12:36, KuanLim.Lee wrote: > Hi Jaehoon, > If there are no more feedback, I will send out version2 patch soon. > > On 11/7/23 14:24, Kuan Lim Lee wrote: >> >> Hi Jaehoon, >> >> On 11/1/23 08:20, Jaehoon Chung wrote: >>> From: Jaehoon Chung Hi >>> >>> On 10/3/23 16:22, Kuan Lim Lee wrote: >>>> From: Kuan Lim Lee >>>> >>>> Cadence SDMMC v6 controller has a lot of changes on initialize >>>> compared to v4 controller. PHY is needed by v6 controller. >>>> >>>> Signed-off-by: Kuan Lim Lee >>>> Reviewed-by: Alex Soo >>>> Reviewed-by: Wei Liang Lim >>> >>> I didn't see their Reviewed-by tag in mailing list. >> They are my colleagues who collaborated develop code with me. >> I think I should them in Signed-off-by, and put your name in Reviewed-by >> >>> >>>> --- >>>> drivers/mmc/Kconfig | 13 ++ >>>> drivers/mmc/Makefile | 1 + >>>> drivers/mmc/sdhci-cadence.c | 63 ++- >>>> drivers/mmc/sdhci-cadence.h | 68 +++ >>>> drivers/mmc/sdhci-cadence6-phy.c | 302 >>>> +++ >>>> 5 files changed, 396 insertions(+), 51 deletions(-) create mode >>>> 100644 drivers/mmc/sdhci-cadence.h create mode 100644 >>>> drivers/mmc/sdhci-cadence6-phy.c >>>> >>>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index >>>> de01b9687b..cec881d862 100644 >>>> --- a/drivers/mmc/Kconfig >>>> +++ b/drivers/mmc/Kconfig >>>> @@ -573,6 +573,19 @@ config MMC_SDHCI_CADENCE >>>> >>>> If unsure, say N. >>>> >>>> +config MMC_SDHCI_CADENCE_V6 >>>> + bool "SDHCI support for the Cadence SD/SDIO/eMMC controller & >>> driver version 6" >>>> + depends on BLK && DM_MMC >>>> + depends on MMC_SDHCI >>>> + depends on OF_CONTROL >>>> + select MMC_SDHCI_CADENCE >>>> + help >>>> +This selects the Cadence SD/SDIO/eMMC driver version 6. >>>> + >>>> +If you have a controller with this interface, say Y here. >>>> + >>>> +If unsure, say N. >>>> + >>>> config MMC_SDHCI_AM654 >>>>bool "SDHCI Controller on TI's Am654 devices" >>>>depends on ARCH_K3 >>>> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index >>>> 2c65c4765a..cdcce55b8b 100644 >>>> --- a/drivers/mmc/Makefile >>>> +++ b/drivers/mmc/Makefile >>>> @@ -61,6 +61,7 @@ obj-$(CONFIG_MMC_SDHCI_ATMEL)+= >>> atmel_sdhci.o >>>> obj-$(CONFIG_MMC_SDHCI_BCM2835) += bcm2835_sdhci.o >>>> obj-$(CONFIG_MMC_SDHCI_BCMSTB)+= bcmstb_sdhci.o >>>> obj-$(CONFIG_MMC_SDHCI_CADENCE) += sdhci-cadence.o >>>> +obj-$(CONFIG_MMC_SDHCI_CADENCE_V6)+= sdhci-cadence6-phy.o >>>> obj-$(CONFIG_MMC_SDHCI_AM654) += am654_sdhci.o >>>> obj-$(CONFIG_MMC_SDHCI_IPROC) += iproc_sdhci.o >>>> obj-$(CONFIG_MMC_SDHCI_KONA) += kona_sdhci.o >>>> diff --git a/drivers/mmc/sdhci-cadence.c >>>> b/drivers/mmc/sdhci-cadence.c index 327a05ad11..d7a270e74c 100644 >>>> --- a/drivers/mmc/sdhci-cadence.c >>>> +++ b/drivers/mmc/sdhci-cadence.c >>>> @@ -17,56 +17,7 @@ >>>> #include >>>> #include >>>> #include >>>> - >>>> -/* HRS - Host Register Set (specific to Cadence) */ >>>> -#define SDHCI_CDNS_HRS04 0x10/* PHY access >> port */ >>>> -#define SDHCI_CDNS_HRS04_ACKBIT(26) >>>> -#define SDHCI_CDNS_HRS04_RD BIT(25) >>>> -#define SDHCI_CDNS_HRS04_WR BIT(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_HRS06 0x18/* eMMC >> control */ >>>> -#define SDHCI_CDNS_HRS06_TUNE_UPBIT(15) >>>> -#define SDHCI_CDNS_HRS06_TUNE GENMASK(13, >> 8) >>>> -#define SDHCI_CDNS_HRS06_MODE GENMASK(2, >> 0) >>>&
Re: [PATCH 2/3] sunxi: H616: remove default AXP305 selection
On 11/14/23 10:31, Andre Przywara wrote: > The original H616 devices released about three years ago were typically > paired with an X-Powers AXP305 PMIC. Newer devices uses the smaller > AXP313, and there seem to be far more systems with this PMIC around now. > > Remove the default AXP305 selection for the H616 SoC from the Kconfig, > and move the PMIC selection into the board defconfig files instead. > > Signed-off-by: Andre Przywara Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > configs/orangepi_zero2_defconfig | 1 + > configs/x96_mate_defconfig | 1 + > drivers/power/Kconfig| 1 - > 3 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/configs/orangepi_zero2_defconfig > b/configs/orangepi_zero2_defconfig > index f13735e91c7..127cf9e365a 100644 > --- a/configs/orangepi_zero2_defconfig > +++ b/configs/orangepi_zero2_defconfig > @@ -19,6 +19,7 @@ CONFIG_SYS_I2C_SPEED=40 > CONFIG_SPI_FLASH_MACRONIX=y > CONFIG_PHY_REALTEK=y > CONFIG_SUN8I_EMAC=y > +CONFIG_AXP305_POWER=y > CONFIG_SPI=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_OHCI_HCD=y > diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig > index 318951e19c2..e805e0952b3 100644 > --- a/configs/x96_mate_defconfig > +++ b/configs/x96_mate_defconfig > @@ -18,6 +18,7 @@ CONFIG_SPL_SYS_I2C_LEGACY=y > CONFIG_SYS_I2C_MVTWSI=y > CONFIG_SYS_I2C_SLAVE=0x7f > CONFIG_SYS_I2C_SPEED=40 > +CONFIG_AXP305_POWER=y > CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_OHCI_HCD=y > diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig > index 2395720c99c..33b8bc1214d 100644 > --- a/drivers/power/Kconfig > +++ b/drivers/power/Kconfig > @@ -56,7 +56,6 @@ choice > depends on ARCH_SUNXI > default AXP209_POWER if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I > default AXP221_POWER if MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33 > || MACH_SUN8I_R40 > - default AXP305_POWER if MACH_SUN50I_H616 > default AXP818_POWER if MACH_SUN8I_A83T > default SUNXI_NO_PMIC if MACH_SUNXI_H3_H5 || MACH_SUN50I || > MACH_SUN8I_V3S >
RE: [PATCH v2 1/2] driver: power: add support for TPS65224
> -Original Message-
> From: U-Boot On Behalf Of Jaehoon Chung
> Sent: Tuesday, November 7, 2023 3:42 PM
> To: 'Bhargav Raviprakash' ; u-boot@lists.denx.de
> Subject: RE: [PATCH v2 1/2] driver: power: add support for TPS65224
>
> Hi Bhargav,
>
> > -Original Message-
> > From: Bhargav Raviprakash
> > Sent: Monday, November 6, 2023 11:07 PM
> > To: u-boot@lists.denx.de
> > Cc: jh80.ch...@samsung.com; Bhargav Raviprakash
> > Subject: [PATCH v2 1/2] driver: power: add support for TPS65224
> >
> > Added support for PMIC TPS65224. Includes driver for pmic,
> > and disabling Watchdog.
> >
> > Signed-off-by: Bhargav Raviprakash
> > ---
> > drivers/power/pmic/Kconfig| 6 ++
> > drivers/power/pmic/Makefile | 1 +
> > drivers/power/pmic/tps65224.c | 141 ++
> > include/power/tps65224.h | 57 ++
> > 4 files changed, 205 insertions(+)
> > create mode 100644 drivers/power/pmic/tps65224.c
> > create mode 100644 include/power/tps65224.h
> >
> > diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> > index 4a6f0ce093..b06bd31823 100644
> > --- a/drivers/power/pmic/Kconfig
> > +++ b/drivers/power/pmic/Kconfig
> > @@ -378,6 +378,12 @@ config PMIC_TPS65941
> > The TPS65941 is a PMIC containing a bunch of SMPS & LDOs.
> > This driver binds the pmic children.
> >
> > +config PMIC_TPS65224
> > + bool "Enable driver for Texas Instruments TPS65224 PMIC"
> > + help
> > + The TPS65224 is a PMIC containing a bunch of SMPS & LDOs.
> > + This driver binds the pmic children.
> > +
> > config PMIC_TPS65219
> > bool "Enable driver for Texas Instruments TPS65219 PMIC"
> > depends on DM_PMIC
> > diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> > index 0b3b3d62d0..cec16e57d3 100644
> > --- a/drivers/power/pmic/Makefile
> > +++ b/drivers/power/pmic/Makefile
> > @@ -33,6 +33,7 @@ obj-$(CONFIG_PMIC_STPMIC1) += stpmic1.o
> > obj-$(CONFIG_PMIC_TPS65217) += pmic_tps65217.o
> > obj-$(CONFIG_PMIC_TPS65219) += tps65219.o
> > obj-$(CONFIG_PMIC_TPS65941) += tps65941.o
> > +obj-$(CONFIG_PMIC_TPS65224) += tps65224.o
>
> Ordering this. Maybe it can be located at tps65941.o.
>
> > obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
> >
> > ifeq ($(CONFIG_$(SPL_)POWER_LEGACY),y)
> > diff --git a/drivers/power/pmic/tps65224.c b/drivers/power/pmic/tps65224.c
> > new file mode 100644
> > index 00..33395f6edf
> > --- /dev/null
> > +++ b/drivers/power/pmic/tps65224.c
> > @@ -0,0 +1,141 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * (C) Copyright 2023 Texas Instruments Incorporated,
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static const struct pmic_child_info pmic_children_info[] = {
> > + { .prefix = "ldo", .driver = TPS65224_LDO_DRIVER },
> > + { .prefix = "buck", .driver = TPS65224_BUCK_DRIVER },
> > + { },
> > +};
> > +
> > +static int tps65224_write(struct udevice *dev, uint reg, const uint8_t
> > *buff,
> > + int len)
> > +{
> > + if (dm_i2c_write(dev, reg, buff, len)) {
> > + pr_err("write error to device: %p register: %#x!\n", dev, reg);
> > + return -EIO;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int tps65224_read(struct udevice *dev, uint reg, uint8_t *buff, int
> > len)
> > +{
> > + if (dm_i2c_read(dev, reg, buff, len)) {
> > + pr_err("read error from device: %p register: %#x!\n", dev, reg);
> > + return -EIO;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int tps65224_bind(struct udevice *dev)
> > +{
> > + ofnode regulators_node;
> > + int children;
> > +
> > + if (dev->driver_data == TPS65224_WD)
> > + return 0;
> > +
> > + regulators_node = dev_read_subnode(dev, "regulators");
> > + if (!ofnode_valid(regulators_node)) {
> > + debug("%s: %s regulators subnode not found!\n", __func__,
> > + dev->name);
> > + return -ENXIO;
> > + }
> > +
> > + debug("%s: '%s' - found regulators subnode\n", __fun
RE: [PATCH v2 1/2] driver: power: add support for TPS65224
Hi Bhargav,
> -Original Message-
> From: Bhargav Raviprakash
> Sent: Monday, November 6, 2023 11:07 PM
> To: u-boot@lists.denx.de
> Cc: jh80.ch...@samsung.com; Bhargav Raviprakash
> Subject: [PATCH v2 1/2] driver: power: add support for TPS65224
>
> Added support for PMIC TPS65224. Includes driver for pmic,
> and disabling Watchdog.
>
> Signed-off-by: Bhargav Raviprakash
> ---
> drivers/power/pmic/Kconfig| 6 ++
> drivers/power/pmic/Makefile | 1 +
> drivers/power/pmic/tps65224.c | 141 ++
> include/power/tps65224.h | 57 ++
> 4 files changed, 205 insertions(+)
> create mode 100644 drivers/power/pmic/tps65224.c
> create mode 100644 include/power/tps65224.h
>
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index 4a6f0ce093..b06bd31823 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -378,6 +378,12 @@ config PMIC_TPS65941
> The TPS65941 is a PMIC containing a bunch of SMPS & LDOs.
> This driver binds the pmic children.
>
> +config PMIC_TPS65224
> + bool "Enable driver for Texas Instruments TPS65224 PMIC"
> + help
> + The TPS65224 is a PMIC containing a bunch of SMPS & LDOs.
> + This driver binds the pmic children.
> +
> config PMIC_TPS65219
> bool "Enable driver for Texas Instruments TPS65219 PMIC"
> depends on DM_PMIC
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 0b3b3d62d0..cec16e57d3 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_PMIC_STPMIC1) += stpmic1.o
> obj-$(CONFIG_PMIC_TPS65217) += pmic_tps65217.o
> obj-$(CONFIG_PMIC_TPS65219) += tps65219.o
> obj-$(CONFIG_PMIC_TPS65941) += tps65941.o
> +obj-$(CONFIG_PMIC_TPS65224) += tps65224.o
Ordering this. Maybe it can be located at tps65941.o.
> obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
>
> ifeq ($(CONFIG_$(SPL_)POWER_LEGACY),y)
> diff --git a/drivers/power/pmic/tps65224.c b/drivers/power/pmic/tps65224.c
> new file mode 100644
> index 00..33395f6edf
> --- /dev/null
> +++ b/drivers/power/pmic/tps65224.c
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2023 Texas Instruments Incorporated,
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static const struct pmic_child_info pmic_children_info[] = {
> + { .prefix = "ldo", .driver = TPS65224_LDO_DRIVER },
> + { .prefix = "buck", .driver = TPS65224_BUCK_DRIVER },
> + { },
> +};
> +
> +static int tps65224_write(struct udevice *dev, uint reg, const uint8_t *buff,
> + int len)
> +{
> + if (dm_i2c_write(dev, reg, buff, len)) {
> + pr_err("write error to device: %p register: %#x!\n", dev, reg);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int tps65224_read(struct udevice *dev, uint reg, uint8_t *buff, int
> len)
> +{
> + if (dm_i2c_read(dev, reg, buff, len)) {
> + pr_err("read error from device: %p register: %#x!\n", dev, reg);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int tps65224_bind(struct udevice *dev)
> +{
> + ofnode regulators_node;
> + int children;
> +
> + if (dev->driver_data == TPS65224_WD)
> + return 0;
> +
> + regulators_node = dev_read_subnode(dev, "regulators");
> + if (!ofnode_valid(regulators_node)) {
> + debug("%s: %s regulators subnode not found!\n", __func__,
> + dev->name);
> + return -ENXIO;
> + }
> +
> + debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
> +
> + children = pmic_bind_children(dev, regulators_node, pmic_children_info);
> + if (!children)
> + printf("%s: %s - no child found\n", __func__, dev->name);
> +
> + /* Probe all the child devices */
> + return dm_scan_fdt_dev(dev);
> +}
> +
> +static int stop_watchdog(struct udevice *wd_i2c_dev)
> +{
> + int ret;
> +
> + /* Maintain WD long window */
> + ret = dm_i2c_reg_read(wd_i2c_dev, TPS65224_WD_MODE_REG);
> + if (ret < 0) {
> + debug("failed to read i2c reg (%d)\n", ret);
> + return ret;
> + }
> +
> + ret &= ~TPS65224_WD_PWRHOLD_MASK;
> + ret |= TPS65224_WD_PWRHOLD_MASK;
Is it a right behavior? After cleared its bit, set again?
Any reason to do this?
How about using val and ret as variable to clarify?
> + ret = dm_i2c_reg_write(wd_i2c_dev, TPS65224_WD_MODE_REG, ret);
> + if (ret) {
> + debug("%s: %s write WD_PWRHOLD fail!\n", __func__,
> wd_i2c_dev->name);
> + return ret;
> + }
> +
> + ret = dm_i2c_reg_read(wd_i2c_dev, TPS65224_WD_MODE_REG);
> + if (ret < 0) {
> + debug("failed to read back i2c reg (%d)\n", ret);
> + return ret;
> + }
> +
RE: [PATCH] mmc: renesas-sdhi: Disable clock after tuning reset when possible
> -Original Message-
> From: Marek Vasut
> Sent: Monday, November 6, 2023 7:43 AM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Jaehoon Chung
> ; Nobuhiro
> Iwamatsu ; Paul Barker ;
> Peng Fan
>
> Subject: [PATCH] mmc: renesas-sdhi: Disable clock after tuning reset when
> possible
>
> Currently the renesas_sdhi_reset_tuning() unconditionally leaves SDHI
> clock enabled after the tuning reset. This is not always necessary.
>
> After the driver performed tuning reset at the end of probe function,
> or in the unlikely case that tuning failed during regular operation,
> the SDHI clock can be disabled after the tuning reset. The following
> set_ios call would reconfigure the clock as needed.
>
> In case of regular set_ios call which requires a tuning reset, keep
> the clock enabled or disabled according to the mmc->clk_disable state.
>
> With this in place, the controllers which have not been accessed via
> block subsystem after boot are left in quiescent state. However, if an
> MMC device is used e.g. for environment storage, that controller would
> be accessed during the environment load and left active, including its
> clock which would still be generated. This is due to the design of the
> MMC subsystem, which does not deinit a controller after it was started
> once, the controller is only deinited in case of mmc rescan, or before
> OS boot.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Note: To address the part where MMC device has been inited once and
> is never deinited until rescan or OS boot, it would likely be
> necessary to implement something like runtime PM, possibly
> based on the cyclic framework. Basically, keep track of when
> the MMC was accessed last, and if certain time elapsed, deinit
> the MMC. This could also be used to handle card detect polling
> at the same time.
> ---
> Cc: Jaehoon Chung
> Cc: Nobuhiro Iwamatsu
> Cc: Paul Barker
> Cc: Peng Fan
> ---
> drivers/mmc/renesas-sdhi.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
> index 8cd501c5f7c..97aaf1e4ec3 100644
> --- a/drivers/mmc/renesas-sdhi.c
> +++ b/drivers/mmc/renesas-sdhi.c
> @@ -318,7 +318,7 @@ static unsigned int renesas_sdhi_init_tuning(struct
> tmio_sd_priv *priv)
> RENESAS_SDHI_SCC_DTCNTL_TAPNUM_MASK;
> }
>
> -static void renesas_sdhi_reset_tuning(struct tmio_sd_priv *priv)
> +static void renesas_sdhi_reset_tuning(struct tmio_sd_priv *priv, bool
> clk_disable)
> {
> u32 reg;
>
> @@ -350,6 +350,12 @@ static void renesas_sdhi_reset_tuning(struct
> tmio_sd_priv *priv)
> reg = tmio_sd_readl(priv, RENESAS_SDHI_SCC_RVSCNTL);
> reg &= ~RENESAS_SDHI_SCC_RVSCNTL_RVSEN;
> tmio_sd_writel(priv, reg, RENESAS_SDHI_SCC_RVSCNTL);
> +
> + if (clk_disable) {
> + reg = tmio_sd_readl(priv, TMIO_SD_CLKCTL);
> + reg &= ~TMIO_SD_CLKCTL_SCLKEN;
> + tmio_sd_writel(priv, reg, TMIO_SD_CLKCTL);
> + }
> }
>
> static int renesas_sdhi_hs400(struct udevice *dev)
> @@ -629,7 +635,7 @@ int renesas_sdhi_execute_tuning(struct udevice *dev, uint
> opcode)
> out:
> if (ret < 0) {
> dev_warn(dev, "Tuning procedure failed\n");
> - renesas_sdhi_reset_tuning(priv);
> + renesas_sdhi_reset_tuning(priv, true);
> }
>
> return ret;
> @@ -668,7 +674,7 @@ static int renesas_sdhi_set_ios(struct udevice *dev)
> (mmc->selected_mode != UHS_SDR104) &&
> (mmc->selected_mode != MMC_HS_200) &&
> (mmc->selected_mode != MMC_HS_400)) {
> - renesas_sdhi_reset_tuning(priv);
> + renesas_sdhi_reset_tuning(priv, mmc->clk_disable);
> }
> #endif
>
> @@ -1095,7 +1101,7 @@ static int renesas_sdhi_probe(struct udevice *dev)
> CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
> CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
> if (priv->caps & TMIO_SD_CAP_RCAR_UHS)
> - renesas_sdhi_reset_tuning(priv);
> + renesas_sdhi_reset_tuning(priv, true);
> #endif
> return 0;
>
> --
> 2.42.0
RE: [PATCH] dfu: add CONFIG_DFU_NAME_MAX_SIZE configuration
Hi,
> -Original Message-
> From: U-Boot On Behalf Of Jaehoon Chung
> Sent: Friday, November 3, 2023 10:07 AM
> To: 'Mattijs Korpershoek'
> Cc: lu...@denx.de; u-boot@lists.denx.de
> Subject: RE: [PATCH] dfu: add CONFIG_DFU_NAME_MAX_SIZE configuration
>
> Hi Mathtjjs,
>
> > -Original Message-
> > From: Mattijs Korpershoek
> > Sent: Thursday, November 2, 2023 6:15 PM
> > To: Jaehoon Chung
> > Cc: lu...@denx.de; u-boot@lists.denx.de
> > Subject: Re: [PATCH] dfu: add CONFIG_DFU_NAME_MAX_SIZE configuration
> >
> > Hi Jaehoon,
> >
> > On mar., oct. 31, 2023 at 15:50, Mattijs Korpershoek
> > wrote:
> >
> > > Hi,
> > >
> > > On Mon, 20 Jun 2022 20:13:54 +0900, Jaehoon Chung wrote:
> > >> Add CONFIG_DFU_NAME_MAX_SIZE to change the proper size.
> > >> If name is longer than default size, it can do wrong behavior during
> > >> updating
> > >> image. So it need to change the proper maximum size.
> > >>
> > >> This patch is proviced the solution to change value with configuration.
> > >>
> > >>
> > >> [...]
> > >
> > > Thanks, Applied to
> > > https://protect2.fireeye.com/v1/url?k=195a8ba3-78d19e99-195b00ec-74fe4860008a-
> > e609da47a4bcadff=1=b6fd9ce6-85b6-46a3-81aa-8aa89d16a9ed=https%3A%2F%2Fsource.denx.de%2Fu-
> > boot%2Fcustodians%2Fu-boot-dfu (u-boot-dfu-next)
> > >
> > > [1/1] dfu: add CONFIG_DFU_NAME_MAX_SIZE configuration
> > >
> > > https://protect2.fireeye.com/v1/url?k=b04b2ae8-d1c03fd2-b04aa1a7-74fe4860008a-
> > d8ec8502221dcca0=1=b6fd9ce6-85b6-46a3-81aa-8aa89d16a9ed=https%3A%2F%2Fsource.denx.de%2Fu-
> > boot%2Fcustodians%2Fu-boot-dfu%2F-%2Fcommit%2Fde9b2e10f10996050a10998a0836abe2f9e425e3
> >
> >
> > This patch breaks CI for both arm32 and arm64 platforms:
> >
> > *
> > https://protect2.fireeye.com/v1/url?k=3179f7cc-50f2e2f6-31787c83-74fe4860008a-
> > a4f5d2c73833c4d5=1=b6fd9ce6-85b6-46a3-81aa-8aa89d16a9ed=https%3A%2F%2Fsource.denx.de%2Fu-
> > boot%2Fcustodians%2Fu-boot-dfu%2F-%2Fjobs%2F725163
> > *
> > https://protect2.fireeye.com/v1/url?k=22773f8e-43fc2ab4-2276b4c1-74fe4860008a-
> > f6dc3d75fe9b283a=1=b6fd9ce6-85b6-46a3-81aa-8aa89d16a9ed=https%3A%2F%2Fsource.denx.de%2Fu-
> > boot%2Fcustodians%2Fu-boot-dfu%2F-%2Fjobs%2F725164
>
> I couldn't access the above CI URL.
>
> >
> > It breaks because multiple boards which include dfu.h without having
> > CONFIG_DFU being set.
> >
> > Tom attempted to fix this with:
> > https://protect2.fireeye.com/v1/url?k=452a9007-24a1853d-452b1b48-74fe4860008a-
> > a88f870953497071=1=b6fd9ce6-85b6-46a3-81aa-
> > 8aa89d16a9ed=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D369275
> >
> > But that had some different issues, see:
> > https://protect2.fireeye.com/v1/url?k=f1c007bd-904b1287-f1c18cf2-74fe4860008a-
> > a305de1bab5bdff1=1=b6fd9ce6-85b6-46a3-81aa-
> > 8aa89d16a9ed=https%3A%2F%2Flibera.irclog.whitequark.org%2Fu-boot%2F2023-10-31%2335154532;
> >
> > I've fixed it up with the following diff:
> >
> > diff --git a/include/dfu.h b/include/dfu.h
> > index 4573f753c565..2c3ffa3f9297 100644
> > --- a/include/dfu.h
> > +++ b/include/dfu.h
> > @@ -99,7 +99,12 @@ struct virt_internal_data {
> > int dev_num;
> > };
> >
> > +
> > +#if defined(CONFIG_DFU_NAME_MAX_SIZE)
> > #define DFU_NAME_SIZE CONFIG_DFU_NAME_MAX_SIZE
> > +#else
> > +#define DFU_NAME_SIZE 32
> > +#endif
> > #ifndef DFU_DEFAULT_POLL_TIMEOUT
> > #define DFU_DEFAULT_POLL_TIMEOUT 0
> > #endif
> >
> > If you have a better idea to fix this, can you please let me know?
>
> After checking this, let you inform.
It seems that it is depended on USB_GADGET and SPL_USB_GADGET. How about this?
About is included in some board files, It needs to check more.
diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig
index 6502aba96f54..9922da56e704 100644
--- a/drivers/dfu/Kconfig
+++ b/drivers/dfu/Kconfig
@@ -13,6 +13,14 @@ config DFU_OVER_TFTP
bool
depends on NET
+config DFU_NAME_MAX_SIZE
+ int "Size of the name to be added in dfu entity"
+ default 32
+ depends on DFU || USB_GADGET_DOWNLOAD || SPL_USB_GADGET
+ help
+ This value is used to maximum size. If name is longer than default
size,
+ we need to change the proper maximum size.
+
if DFU
config DFU_WRITE_ALT
bool
@@ -112,13 +120,5 @@ config SYS_DFU_MAX_FILE_SIZE
this to the maximum filesize (in bytes) for the buffer.
If undefined it defaults to the CONFIG_SYS_DFU_DATA_BUF_SIZE.
-config DFU_NAME_MAX_SIZE
- int "Size of the name to be added in dfu entity"
- default 32
- depends on DFU
- help
- This value is used to maximum size. If name is longer than default
size,
- we need to change the proper maximum size.
I'm running CI with some patch. After checked, I will inform.
Best Regards,
Jaehoon Chung
>
> > Otherwise, I will squash this to keep CI green.
> >
> > Thank you
> >
> > >
> > > --
> > > Mattijs
RE: [PATCH] dfu: add CONFIG_DFU_NAME_MAX_SIZE configuration
Hi Mathtjjs,
> -Original Message-
> From: Mattijs Korpershoek
> Sent: Thursday, November 2, 2023 6:15 PM
> To: Jaehoon Chung
> Cc: lu...@denx.de; u-boot@lists.denx.de
> Subject: Re: [PATCH] dfu: add CONFIG_DFU_NAME_MAX_SIZE configuration
>
> Hi Jaehoon,
>
> On mar., oct. 31, 2023 at 15:50, Mattijs Korpershoek
> wrote:
>
> > Hi,
> >
> > On Mon, 20 Jun 2022 20:13:54 +0900, Jaehoon Chung wrote:
> >> Add CONFIG_DFU_NAME_MAX_SIZE to change the proper size.
> >> If name is longer than default size, it can do wrong behavior during
> >> updating
> >> image. So it need to change the proper maximum size.
> >>
> >> This patch is proviced the solution to change value with configuration.
> >>
> >>
> >> [...]
> >
> > Thanks, Applied to
> > https://protect2.fireeye.com/v1/url?k=195a8ba3-78d19e99-195b00ec-74fe4860008a-
> e609da47a4bcadff=1=b6fd9ce6-85b6-46a3-81aa-8aa89d16a9ed=https%3A%2F%2Fsource.denx.de%2Fu-
> boot%2Fcustodians%2Fu-boot-dfu (u-boot-dfu-next)
> >
> > [1/1] dfu: add CONFIG_DFU_NAME_MAX_SIZE configuration
> >
> > https://protect2.fireeye.com/v1/url?k=b04b2ae8-d1c03fd2-b04aa1a7-74fe4860008a-
> d8ec8502221dcca0=1=b6fd9ce6-85b6-46a3-81aa-8aa89d16a9ed=https%3A%2F%2Fsource.denx.de%2Fu-
> boot%2Fcustodians%2Fu-boot-dfu%2F-%2Fcommit%2Fde9b2e10f10996050a10998a0836abe2f9e425e3
>
>
> This patch breaks CI for both arm32 and arm64 platforms:
>
> *
> https://protect2.fireeye.com/v1/url?k=3179f7cc-50f2e2f6-31787c83-74fe4860008a-
> a4f5d2c73833c4d5=1=b6fd9ce6-85b6-46a3-81aa-8aa89d16a9ed=https%3A%2F%2Fsource.denx.de%2Fu-
> boot%2Fcustodians%2Fu-boot-dfu%2F-%2Fjobs%2F725163
> *
> https://protect2.fireeye.com/v1/url?k=22773f8e-43fc2ab4-2276b4c1-74fe4860008a-
> f6dc3d75fe9b283a=1=b6fd9ce6-85b6-46a3-81aa-8aa89d16a9ed=https%3A%2F%2Fsource.denx.de%2Fu-
> boot%2Fcustodians%2Fu-boot-dfu%2F-%2Fjobs%2F725164
I couldn't access the above CI URL.
>
> It breaks because multiple boards which include dfu.h without having
> CONFIG_DFU being set.
>
> Tom attempted to fix this with:
> https://protect2.fireeye.com/v1/url?k=452a9007-24a1853d-452b1b48-74fe4860008a-
> a88f870953497071=1=b6fd9ce6-85b6-46a3-81aa-
> 8aa89d16a9ed=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D369275
>
> But that had some different issues, see:
> https://protect2.fireeye.com/v1/url?k=f1c007bd-904b1287-f1c18cf2-74fe4860008a-
> a305de1bab5bdff1=1=b6fd9ce6-85b6-46a3-81aa-
> 8aa89d16a9ed=https%3A%2F%2Flibera.irclog.whitequark.org%2Fu-boot%2F2023-10-31%2335154532;
>
> I've fixed it up with the following diff:
>
> diff --git a/include/dfu.h b/include/dfu.h
> index 4573f753c565..2c3ffa3f9297 100644
> --- a/include/dfu.h
> +++ b/include/dfu.h
> @@ -99,7 +99,12 @@ struct virt_internal_data {
> int dev_num;
> };
>
> +
> +#if defined(CONFIG_DFU_NAME_MAX_SIZE)
> #define DFU_NAME_SIZE CONFIG_DFU_NAME_MAX_SIZE
> +#else
> +#define DFU_NAME_SIZE 32
> +#endif
> #ifndef DFU_DEFAULT_POLL_TIMEOUT
> #define DFU_DEFAULT_POLL_TIMEOUT 0
> #endif
>
> If you have a better idea to fix this, can you please let me know?
After checking this, let you inform.
> Otherwise, I will squash this to keep CI green.
>
> Thank you
>
> >
> > --
> > Mattijs
Re: [PATCH] mmc: sdhci-cadence: Add support for Cadence sdmmc v6
+ 0x0008,
> + 0x00018000,
> + 0x0008,
> + 0x1100,
> +};
> +
> +static unsigned int sdhci_cdns6_read_phy_reg(struct sdhci_cdns_plat *plat,
> + u32 addr)
> +{
> + u32 data = 0;
> +
> + writel(addr, plat->hrs_addr + SDHCI_CDNS_HRS04);
> + data = readl(plat->hrs_addr + SDHCI_CDNS_HRS05);
> + return data;
> +}
> +
> +static void sdhci_cdns6_write_phy_reg(struct sdhci_cdns_plat *plat,
> + u32 addr, u32 data)
> +{
> + u32 readdat = 0;
> +
> + writel(addr, plat->hrs_addr + SDHCI_CDNS_HRS04);
> + writel(data, plat->hrs_addr + SDHCI_CDNS_HRS05);
> + readdat = readl(plat->hrs_addr + SDHCI_CDNS_HRS05);
> +
> + if (readdat != data) {
> + pr_err("Error, %s: Writing failed!: address: 0x%x, value :
> 0x%x,
> +readval: 0x%x\n", __func__, addr, data, readdat);
Doesn't need to return error value?
> + }
> +}
> +
> +static int sdhci_cdns6_reset_phy_dll(struct sdhci_cdns_plat *plat,
> + unsigned int reset)
> +{
> + void __iomem *reg = plat->hrs_addr + SDHCI_CDNS_HRS09;
> + u32 tmp;
> + int ret;
> +
> + tmp = readl(reg);
> + tmp &= ~SDHCI_CDNS_HRS09_PHY_SW_RESET;
> +
> + if (reset) /* Switch On DLL Reset */
/* Swithc On DLL Reset */
if (reset)
...
else
...
> + tmp |= FIELD_PREP(SDHCI_CDNS_HRS09_PHY_SW_RESET, 0);
> + else/* Switch Off DLL Reset */
> + tmp |= FIELD_PREP(SDHCI_CDNS_HRS09_PHY_SW_RESET, 1);
> +
> + writel(tmp, reg);
> +
> + if (!reset) {
> + ret = readl_poll_timeout(reg, tmp,
> + (tmp &
> SDHCI_CDNS_HRS09_PHY_INIT_COMPLETE),
> + 3000);
Add a comment why it needs to poll during 3000.
> + }
> +
> + return ret;
> +}
> +
> +int sdhci_cdns6_phy_init(struct sdhci_cdns_plat *plat, u32 mode)
> +{
> + struct phy_reg *phy_cfgs;
> + struct controller_reg *ctrl_cfgs;
> + void __iomem *reg = NULL;
> + u32 tmp;
> + int ret;
> +
> + switch (mode) {
> + case SDHCI_CDNS_HRS06_MODE_SD:
> + phy_cfgs = _ds_phy_cfg;
> + ctrl_cfgs = _ds_ctrl_cfg;
> + break;
> +
> + case SDHCI_CDNS_HRS06_MODE_MMC_SDR:
> + phy_cfgs = _sdr_phy_cfg;
> + ctrl_cfgs = _sdr_ctrl_cfg;
> + break;
> +
> + case SDHCI_CDNS_HRS06_MODE_MMC_DDR:
> + phy_cfgs = _ddr_phy_cfg;
> + ctrl_cfgs = _ddr_ctrl_cfg;
> + break;
> +
> + case SDHCI_CDNS_HRS06_MODE_MMC_HS200:
> + phy_cfgs = _hs200_phy_cfg;
> + ctrl_cfgs = _hs200_ctrl_cfg;
> + break;
> +
> + case SDHCI_CDNS_HRS06_MODE_MMC_HS400:
> + phy_cfgs = _hs400_phy_cfg;
> + ctrl_cfgs = _hs400_ctrl_cfg;
> + break;
If there is no matched mod, phy_cfgs and ctrl_cfgs should be NULL.
> + }
> +
> + /* Switch On the DLL Reset */
> + sdhci_cdns6_reset_phy_dll(plat, 1);
> +
> + sdhci_cdns6_write_phy_reg(plat, PHY_DQS_TIMING_REG_ADDR,
> + phy_cfgs->phy_dqs_timing);
> + sdhci_cdns6_write_phy_reg(plat, PHY_GATE_LPBK_CTRL_REG_ADDR,
> + phy_cfgs->phy_gate_lpbk_ctrl);
> + sdhci_cdns6_write_phy_reg(plat, PHY_DLL_SLAVE_CTRL_REG_ADDR,
> + phy_cfgs->phy_dll_slave_ctrl);
> +
> + /* Switch Off the DLL Reset */
> + ret = sdhci_cdns6_reset_phy_dll(plat, 0);
> + if (ret) {
> + printf("sdhci_cdns6_reset_phy is not completed\n");
> + return ret;
> + }
> +
> + /* Set PHY DQ TIMING control register */
> + sdhci_cdns6_write_phy_reg(plat, PHY_DQ_TIMING_REG_ADDR,
> + phy_cfgs->phy_dq_timing);
> +
> + /* Set HRS09 register */
> + reg = plat->hrs_addr + SDHCI_CDNS_HRS09;
> + tmp = readl(reg);
I'm not suer why plat-hrs_addr assigned to reg.
How about using the below?
hrs_base_addr = plat->hrs_addr;
readl(hrs_base_addr + SDHCI_CDNS_HRS10);
Then you can change the below code like
readl(hrs_base_addr + SDHCI_CDNS_HRS16);
readl(hrs_base_addr + SDHCI_CDNS_HRS07);
Otherwise, readl(plat->hrs_addr + SDHCI_xxx);
> + tmp &= ~(SDHCI_CDNS_HRS09_EXTENDED_WR_MODE |
> + SDHCI_CDNS_HRS09_EXTENDED_RD_MODE |
> + SDHCI_CDNS_HRS09_RDDATA_EN |
> + SDHCI_CDNS_HRS09_RDCMD_EN);
> + tmp |= ctrl_cfgs->hrs09;
> + writel(tmp, reg);
> +
> + /* Set HRS10 register */
> + reg = plat->hrs_addr + SDHCI_CDNS_HRS10;
> + tmp = readl(reg);
> + tmp &= ~SDHCI_CDNS_HRS10_HCSDCLKADJ;
> + tmp |= ctrl_cfgs->hrs10;
> + writel(tmp, reg);
> +
> + /* Set HRS16 register */
> + reg = plat->hrs_addr + SDHCI_CDNS_HRS16;
> + tmp = ctrl_cfgs->hrs16;
> + writel(tmp, reg);
> +
> + /* Set HRS07 register */
> + reg = plat->hrs_addr + SDHCI_CDNS_HRS07;
> + tmp = ctrl_cfgs->hrs07;
> + writel(tmp, reg);
> +
> + return 0;
> +}
> +
> +int sdhci_cdns6_set_tune_val(struct sdhci_cdns_plat *plat,
> + unsigned int val)
> +{
> + u32 tmp, tuneval;
Ditto.
Best Regards,
Jaehoon Chung
> +
> + tuneval = (val * 256) / SDHCI_CDNS_MAX_TUNING_LOOP;
> +
> + tmp = sdhci_cdns6_read_phy_reg(plat, PHY_DLL_SLAVE_CTRL_REG_ADDR);
> + tmp &= ~(PHY_DLL_SLAVE_CTRL_REG_READ_DQS_CMD_DELAY |
> + PHY_DLL_SLAVE_CTRL_REG_READ_DQS_DELAY);
> + tmp |= FIELD_PREP(PHY_DLL_SLAVE_CTRL_REG_READ_DQS_CMD_DELAY, tuneval) |
> + FIELD_PREP(PHY_DLL_SLAVE_CTRL_REG_READ_DQS_DELAY, tuneval);
> + sdhci_cdns6_write_phy_reg(plat, PHY_DLL_SLAVE_CTRL_REG_ADDR, tmp);
> +
> + return 0;
> +}
Re: [PATCH 5/8] mmc: renesas-sdhi: Drop
On 11/2/23 05:05, Paul Barker wrote: > In line with changes elsewhere, drop inclusion of the common header. > > Signed-off-by: Paul Barker Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > drivers/mmc/renesas-sdhi.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c > index 865efdd32184..8cd501c5f7c7 100644 > --- a/drivers/mmc/renesas-sdhi.c > +++ b/drivers/mmc/renesas-sdhi.c > @@ -3,7 +3,6 @@ > * Copyright (C) 2018 Marek Vasut > */ > > -#include > #include > #include > #include
[PATCH] usb: dwc3-meson-g12a: Use regulator_set_enable_if_allowed
Some meson targets are using a fixed regulator about usb.
It's always returning to EARLEADY, so driver doesn't init fine.
To prevent this problem, use the regulator_set_enable_if_allowed
instead of regulator_set_enable.
Fixes: 4fcba5d556b ("regulator: implement basic reference counter")
Signed-off-by: Jaehoon Chung
---
drivers/usb/dwc3/dwc3-meson-g12a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-meson-g12a.c
b/drivers/usb/dwc3/dwc3-meson-g12a.c
index e0356e653fcc..59276483c19d 100644
--- a/drivers/usb/dwc3/dwc3-meson-g12a.c
+++ b/drivers/usb/dwc3/dwc3-meson-g12a.c
@@ -291,7 +291,7 @@ int dwc3_meson_g12a_force_mode(struct udevice *dev, enum
usb_dr_mode mode)
#if CONFIG_IS_ENABLED(DM_REGULATOR)
if (priv->vbus_supply) {
- int ret = regulator_set_enable(priv->vbus_supply,
+ int ret = regulator_set_enable_if_allowed(priv->vbus_supply,
(mode == USB_DR_MODE_PERIPHERAL));
if (ret)
return ret;
@@ -420,7 +420,7 @@ static int dwc3_meson_g12a_probe(struct udevice *dev)
}
if (priv->vbus_supply) {
- ret = regulator_set_enable(priv->vbus_supply, true);
+ ret = regulator_set_enable_if_allowed(priv->vbus_supply, true);
if (ret)
return ret;
}
--
2.25.1
RE: [PATCH] power: regulator: Fix an handling error about EALREADY
Hi,
> -Original Message-
> From: Jonas Karlman
> Sent: Wednesday, November 1, 2023 6:33 PM
> To: Jaehoon Chung
> Cc: s...@chromium.org; patrice.chot...@foss.st.com;
> eugen.hris...@collabora.com; tr...@konsulko.com; u-
> b...@lists.denx.de
> Subject: Re: [PATCH] power: regulator: Fix an handling error about EALREADY
>
> On 2023-11-01 09:19, Jaehoon Chung wrote:
> >
> >
> >> -Original Message-
> >> From: U-Boot On Behalf Of Jaehoon Chung
> >> Sent: Wednesday, November 1, 2023 5:11 PM
> >> To: 'Jonas Karlman'
> >> Cc: s...@chromium.org; patrice.chot...@foss.st.com;
> >> eugen.hris...@collabora.com; tr...@konsulko.com;
> u-
> >> b...@lists.denx.de
> >> Subject: RE: [PATCH] power: regulator: Fix an handling error about EALREADY
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: U-Boot On Behalf Of Jaehoon Chung
> >>> Sent: Wednesday, November 1, 2023 5:07 PM
> >>> To: 'Jonas Karlman'
> >>> Cc: s...@chromium.org; patrice.chot...@foss.st.com;
> >>> eugen.hris...@collabora.com; tr...@konsulko.com;
> >> u-
> >>> b...@lists.denx.de
> >>> Subject: RE: [PATCH] power: regulator: Fix an handling error about
> >>> EALREADY
> >>>
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Jonas Karlman
> >>>> Sent: Wednesday, November 1, 2023 4:47 PM
> >>>> To: Jaehoon Chung
> >>>> Cc: s...@chromium.org; patrice.chot...@foss.st.com;
> >>>> eugen.hris...@collabora.com;
> tr...@konsulko.com;
> >>> u-
> >>>> b...@lists.denx.de
> >>>> Subject: Re: [PATCH] power: regulator: Fix an handling error about
> >>>> EALREADY
> >>>>
> >>>> On 2023-11-01 08:23, Jaehoon Chung wrote:
> >>>>> If reegulator is already enabled, it will be return to EALREADY.
> >>>>> But driver that its function is called can notice as error, even though
> >>>>> it's working fine.
> >>>>>
> >>>>> Fixes: 4fcba5d556b ("regulator: implement basic reference counter")
> >>>>>
> >>>>> Signed-off-by: Jaehoon Chung
> >>>>> ---
> >>>>> drivers/power/regulator/regulator-uclass.c | 4
> >>>>> 1 file changed, 4 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/power/regulator/regulator-uclass.c
> >>>>> b/drivers/power/regulator/regulator-
> >>> uclass.c
> >>>>> index 3a6ba69f6d5f..fc1c3eb93c9d 100644
> >>>>> --- a/drivers/power/regulator/regulator-uclass.c
> >>>>> +++ b/drivers/power/regulator/regulator-uclass.c
> >>>>> @@ -187,6 +187,10 @@ int regulator_set_enable(struct udevice *dev, bool
> >>>>> enable)
> >>>>> }
> >>>>> }
> >>>>>
> >>>>> + /* Regulator is already enabled */
> >>>>> + if (ret == -EALREADY)
> >>>>> + return 0;
> >>>>> +
> >>>>
> >>>> Use of regulator_set_enable_if_allowed() will cover this error,
> >>>> and regulator_set_enable() should continue to return this error.
> >
> > regulator_set_enable_if_allowed() can be covered. But regulator_set_enable
> > is called in some drivers.
> > You means that it needs to replace to regulator_set_enable_if_allowed()
> > from regulator_set_enable()
> about all driver?
>
> I think that was the consensus when basic reference counter was
> implemented for gpio/fixed regulators. It should return -EALREADY when
> a regulator is already enabled, and if a caller need a more relaxed
> enable/disable regulator_set_enable_if_allowed() could be used.
Ok. I understood.
>
> Tried to fix a few commons callers in following series, but did not
> cover hw I could not test. Can see that I missed the meson usb driver
> and was something I could have tested.
>
> Keep fixed/gpio regulator enable count in balance
> https://protect2.fireeye.com/v1/url?k=d568c889-b4136201-d56943c6-74fe4860018a-
> 0f3e262ba2f98d29=1=fab7227e-c990-4824-b601-
> b8ba154d2255=https%3A%2F%2Fpatchwork.ozlabs.org%2Fcover%2F1810049%2F
Thanks for informing this.
Then discard this patch. It seems that make sense to fix meson usb. How about?
I will send the patch about meson-usb.
Best Regards,
Jaehoon Chung
>
> Regards,
> Jonas
>
> >
> > Best Regards,
> > Jaehoon Chung
> >
> >>
> >> Well.. I will recheck about your comment.
> >>
> >> Best Regards,
> >> Jaehoon Chung
> >>
> >>>
> >>> When I have checked on my target, It seems that it can't cover all cases.
> >>>
> >>> On odroid-c4, USB doesn't work, even though its regulator is enabled.
> >>>
> >>> => ums 0 mmc 0
> >>> UMS: LUN 0, dev mmc 0, hwpart 0, sector 0x0, count 0x1dacc00
> >>> No USB device found
> >>> Couldn't init USB controller.
> >>>
> >>>
> >>> Best Regards,
> >>> Jaehoon Chung
> >>>
> >>>>
> >>>> Regards,
> >>>> Jonas
> >>>>
> >>>>> return ret;
> >>>>> }
> >>>>>
> >>>
> >>
> >
> >
RE: [PATCH] power: regulator: Fix an handling error about EALREADY
> -Original Message-
> From: U-Boot On Behalf Of Jaehoon Chung
> Sent: Wednesday, November 1, 2023 5:11 PM
> To: 'Jonas Karlman'
> Cc: s...@chromium.org; patrice.chot...@foss.st.com;
> eugen.hris...@collabora.com; tr...@konsulko.com; u-
> b...@lists.denx.de
> Subject: RE: [PATCH] power: regulator: Fix an handling error about EALREADY
>
>
>
> > -Original Message-
> > From: U-Boot On Behalf Of Jaehoon Chung
> > Sent: Wednesday, November 1, 2023 5:07 PM
> > To: 'Jonas Karlman'
> > Cc: s...@chromium.org; patrice.chot...@foss.st.com;
> > eugen.hris...@collabora.com; tr...@konsulko.com;
> u-
> > b...@lists.denx.de
> > Subject: RE: [PATCH] power: regulator: Fix an handling error about EALREADY
> >
> >
> >
> > > -Original Message-
> > > From: Jonas Karlman
> > > Sent: Wednesday, November 1, 2023 4:47 PM
> > > To: Jaehoon Chung
> > > Cc: s...@chromium.org; patrice.chot...@foss.st.com;
> > > eugen.hris...@collabora.com; tr...@konsulko.com;
> > u-
> > > b...@lists.denx.de
> > > Subject: Re: [PATCH] power: regulator: Fix an handling error about
> > > EALREADY
> > >
> > > On 2023-11-01 08:23, Jaehoon Chung wrote:
> > > > If reegulator is already enabled, it will be return to EALREADY.
> > > > But driver that its function is called can notice as error, even though
> > > > it's working fine.
> > > >
> > > > Fixes: 4fcba5d556b ("regulator: implement basic reference counter")
> > > >
> > > > Signed-off-by: Jaehoon Chung
> > > > ---
> > > > drivers/power/regulator/regulator-uclass.c | 4
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/drivers/power/regulator/regulator-uclass.c
> > > > b/drivers/power/regulator/regulator-
> > uclass.c
> > > > index 3a6ba69f6d5f..fc1c3eb93c9d 100644
> > > > --- a/drivers/power/regulator/regulator-uclass.c
> > > > +++ b/drivers/power/regulator/regulator-uclass.c
> > > > @@ -187,6 +187,10 @@ int regulator_set_enable(struct udevice *dev, bool
> > > > enable)
> > > > }
> > > > }
> > > >
> > > > + /* Regulator is already enabled */
> > > > + if (ret == -EALREADY)
> > > > + return 0;
> > > > +
> > >
> > > Use of regulator_set_enable_if_allowed() will cover this error,
> > > and regulator_set_enable() should continue to return this error.
regulator_set_enable_if_allowed() can be covered. But regulator_set_enable is
called in some drivers.
You means that it needs to replace to regulator_set_enable_if_allowed() from
regulator_set_enable() about all driver?
Best Regards,
Jaehoon Chung
>
> Well.. I will recheck about your comment.
>
> Best Regards,
> Jaehoon Chung
>
> >
> > When I have checked on my target, It seems that it can't cover all cases.
> >
> > On odroid-c4, USB doesn't work, even though its regulator is enabled.
> >
> > => ums 0 mmc 0
> > UMS: LUN 0, dev mmc 0, hwpart 0, sector 0x0, count 0x1dacc00
> > No USB device found
> > Couldn't init USB controller.
> >
> >
> > Best Regards,
> > Jaehoon Chung
> >
> > >
> > > Regards,
> > > Jonas
> > >
> > > > return ret;
> > > > }
> > > >
> >
>
RE: [PATCH] power: regulator: Fix an handling error about EALREADY
> -Original Message-
> From: U-Boot On Behalf Of Jaehoon Chung
> Sent: Wednesday, November 1, 2023 5:07 PM
> To: 'Jonas Karlman'
> Cc: s...@chromium.org; patrice.chot...@foss.st.com;
> eugen.hris...@collabora.com; tr...@konsulko.com; u-
> b...@lists.denx.de
> Subject: RE: [PATCH] power: regulator: Fix an handling error about EALREADY
>
>
>
> > -Original Message-
> > From: Jonas Karlman
> > Sent: Wednesday, November 1, 2023 4:47 PM
> > To: Jaehoon Chung
> > Cc: s...@chromium.org; patrice.chot...@foss.st.com;
> > eugen.hris...@collabora.com; tr...@konsulko.com;
> u-
> > b...@lists.denx.de
> > Subject: Re: [PATCH] power: regulator: Fix an handling error about EALREADY
> >
> > On 2023-11-01 08:23, Jaehoon Chung wrote:
> > > If reegulator is already enabled, it will be return to EALREADY.
> > > But driver that its function is called can notice as error, even though
> > > it's working fine.
> > >
> > > Fixes: 4fcba5d556b ("regulator: implement basic reference counter")
> > >
> > > Signed-off-by: Jaehoon Chung
> > > ---
> > > drivers/power/regulator/regulator-uclass.c | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/power/regulator/regulator-uclass.c
> > > b/drivers/power/regulator/regulator-
> uclass.c
> > > index 3a6ba69f6d5f..fc1c3eb93c9d 100644
> > > --- a/drivers/power/regulator/regulator-uclass.c
> > > +++ b/drivers/power/regulator/regulator-uclass.c
> > > @@ -187,6 +187,10 @@ int regulator_set_enable(struct udevice *dev, bool
> > > enable)
> > > }
> > > }
> > >
> > > + /* Regulator is already enabled */
> > > + if (ret == -EALREADY)
> > > + return 0;
> > > +
> >
> > Use of regulator_set_enable_if_allowed() will cover this error,
> > and regulator_set_enable() should continue to return this error.
Well.. I will recheck about your comment.
Best Regards,
Jaehoon Chung
>
> When I have checked on my target, It seems that it can't cover all cases.
>
> On odroid-c4, USB doesn't work, even though its regulator is enabled.
>
> => ums 0 mmc 0
> UMS: LUN 0, dev mmc 0, hwpart 0, sector 0x0, count 0x1dacc00
> No USB device found
> Couldn't init USB controller.
>
>
> Best Regards,
> Jaehoon Chung
>
> >
> > Regards,
> > Jonas
> >
> > > return ret;
> > > }
> > >
>
RE: [PATCH] power: regulator: Fix an handling error about EALREADY
> -Original Message-
> From: Jonas Karlman
> Sent: Wednesday, November 1, 2023 4:47 PM
> To: Jaehoon Chung
> Cc: s...@chromium.org; patrice.chot...@foss.st.com;
> eugen.hris...@collabora.com; tr...@konsulko.com; u-
> b...@lists.denx.de
> Subject: Re: [PATCH] power: regulator: Fix an handling error about EALREADY
>
> On 2023-11-01 08:23, Jaehoon Chung wrote:
> > If reegulator is already enabled, it will be return to EALREADY.
> > But driver that its function is called can notice as error, even though
> > it's working fine.
> >
> > Fixes: 4fcba5d556b ("regulator: implement basic reference counter")
> >
> > Signed-off-by: Jaehoon Chung
> > ---
> > drivers/power/regulator/regulator-uclass.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/power/regulator/regulator-uclass.c
> > b/drivers/power/regulator/regulator-uclass.c
> > index 3a6ba69f6d5f..fc1c3eb93c9d 100644
> > --- a/drivers/power/regulator/regulator-uclass.c
> > +++ b/drivers/power/regulator/regulator-uclass.c
> > @@ -187,6 +187,10 @@ int regulator_set_enable(struct udevice *dev, bool
> > enable)
> > }
> > }
> >
> > + /* Regulator is already enabled */
> > + if (ret == -EALREADY)
> > + return 0;
> > +
>
> Use of regulator_set_enable_if_allowed() will cover this error,
> and regulator_set_enable() should continue to return this error.
When I have checked on my target, It seems that it can't cover all cases.
On odroid-c4, USB doesn't work, even though its regulator is enabled.
=> ums 0 mmc 0
UMS: LUN 0, dev mmc 0, hwpart 0, sector 0x0, count 0x1dacc00
No USB device found
Couldn't init USB controller.
Best Regards,
Jaehoon Chung
>
> Regards,
> Jonas
>
> > return ret;
> > }
> >
[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/18386 The following changes since commit 62fc66b6d228d628c3f672c736aa57e4174ac783: Merge branch '2023-10-31-platform-updates' (2023-10-31 13:08:10 -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 b5f403936d037e0bc08e78b8af64adf53da13b90: cmd: mmc: Add mmc reg read command for reading card registers (2023-11-01 10:09:21 +0900) Bin Meng (1): mmc: pci: Drop the superfluous cast Marek Vasut (1): cmd: mmc: Add mmc reg read command for reading card registers Oleksandr Suvorov (1): mmc: spl: select SPL_BLK for SPL_DM_MMC Sean Anderson (1): mmc: sdhci: Rework SDHCI_QUIRK_BROKEN_R1B cmd/Kconfig | 7 cmd/mmc.c | 96 +++ doc/usage/cmd/mmc.rst | 26 ++ drivers/mmc/Kconfig | 1 + drivers/mmc/pci_mmc.c | 4 +-- drivers/mmc/sdhci.c | 19 ++ include/sdhci.h | 1 + 7 files changed, 145 insertions(+), 9 deletions(-)
[PATCH] power: regulator: Fix an handling error about EALREADY
If reegulator is already enabled, it will be return to EALREADY.
But driver that its function is called can notice as error, even though
it's working fine.
Fixes: 4fcba5d556b ("regulator: implement basic reference counter")
Signed-off-by: Jaehoon Chung
---
drivers/power/regulator/regulator-uclass.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/power/regulator/regulator-uclass.c
b/drivers/power/regulator/regulator-uclass.c
index 3a6ba69f6d5f..fc1c3eb93c9d 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -187,6 +187,10 @@ int regulator_set_enable(struct udevice *dev, bool enable)
}
}
+ /* Regulator is already enabled */
+ if (ret == -EALREADY)
+ return 0;
+
return ret;
}
--
2.25.1
RE: [PATCH v4] cmd: mmc: Add mmc reg read command for reading card registers
> -Original Message- > From: Fabio Estevam > Sent: Wednesday, November 1, 2023 1:09 AM > To: Marek Vasut > Cc: u-boot@lists.denx.de; Jaehoon Chung ; Abdellatif > El Khlifi > ; Heinrich Schuchardt ; > Ilias Apalodimas > ; Ramon Fried ; Roger > Knecht ; Sean > Edmond ; Simon Glass ; Tobias > Waldekranz > > Subject: Re: [PATCH v4] cmd: mmc: Add mmc reg read command for reading card > registers > > On Tue, Oct 31, 2023 at 9:20 AM Marek Vasut wrote: > > > > Add extension to the 'mmc' command to read out the card registers. > > Currently, only the eMMC OCR/CID/CSD/EXTCSD/RCA/DSR register are > > supported. A register value can either be displayed or read into > > an environment variable. > > > > Tested-by: Jaehoon Chung > > Reviewed-by: Jaehoon Chung > > Signed-off-by: Marek Vasut > > Reviewed-by: Fabio Estevam Applied to u-boot-mmc/master. Thanks! Best Regards, Jaehoon Chung
RE: [PATCH] mmc: sdhci: Rework SDHCI_QUIRK_BROKEN_R1B
> -Original Message-
> From: U-Boot On Behalf Of Jaehoon Chung
> Sent: Wednesday, November 1, 2023 10:09 AM
> To: 'Henrik Grimler' ; 'Sean Anderson'
>
> Cc: u-boot@lists.denx.de; 'Rayagonda Kokatanur'
> ; 'Bharat Kumar
> Reddy Gooty'
> Subject: RE: [PATCH] mmc: sdhci: Rework SDHCI_QUIRK_BROKEN_R1B
>
> Hi,
>
> > -Original Message-
> > From: Henrik Grimler
> > Sent: Sunday, October 29, 2023 5:31 AM
> > To: Sean Anderson
> > Cc: u-boot@lists.denx.de; Jaehoon Chung ; Rayagonda
> > Kokatanur
> > ; Bharat Kumar Reddy Gooty
> >
> > Subject: Re: [PATCH] mmc: sdhci: Rework SDHCI_QUIRK_BROKEN_R1B
> >
> > Hi Sean,
> >
> > Tested on odroid-u2 (exynos4412-odroid) on top of 2024.01-rc1, still
> > works fine, so feel free to add:
> >
> > Tested-by: Henrik Grimler
> >
> > Best regards,
> > Henrik Grimler
> >
> > On Fri, Oct 27, 2023 at 04:57:03PM -0400, Sean Anderson wrote:
> > > As noted in commit 3a6383207be ("mmc: sdhci: add the quirk for broken
> > > r1b response"), some MMC controllers don't always set the transfer
> > > complete bit with R1b responses.
> > >
> > > According to the SD Host Controller Simplified Specification v4.20,
> > >
> > > > In the case of a command pairing with response-with-busy[, Transfer
> > > > Complete] is set when busy is de-asserted. Refer to DAT Line Active
> > > > and Command Inhibit (DAT) in the Present State register.
> > >
> > > By polling the DAT Line Active bit in the present state register, we can
> > > detect when we are no longer busy, without waiting for a long timeout.
> > > This results in much faster reads/writes on buggy controllers.
> > >
> > > Signed-off-by: Sean Anderson
>
> Reviewed-by: Jaehoon Chung
Applied to u-boot-mmc/master. Thanks!
Best Regards,
Jaehoon Chung
>
> Best Regards,
> Jaehoon Chung
>
> > > ---
> > > I've CC'd a few people who've added this quirk to controllers recently.
> > > Please let me know if your hardware still works. It's possible that my
> > > hardware is buggy in a different way.
> > >
> > > drivers/mmc/sdhci.c | 19 ---
> > > include/sdhci.h | 1 +
> > > 2 files changed, 13 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> > > index fc9c6c37996..0178ed8a11e 100644
> > > --- a/drivers/mmc/sdhci.c
> > > +++ b/drivers/mmc/sdhci.c
> > > @@ -306,14 +306,19 @@ static int sdhci_send_command(struct mmc *mmc,
> > > struct mmc_cmd *cmd,
> > > if (stat & SDHCI_INT_ERROR)
> > > break;
> > >
> > > - if (get_timer(start) >= SDHCI_READ_STATUS_TIMEOUT) {
> > > - if (host->quirks & SDHCI_QUIRK_BROKEN_R1B) {
> > > + if (host->quirks & SDHCI_QUIRK_BROKEN_R1B &&
> > > + cmd->resp_type & MMC_RSP_BUSY && !data) {
> > > + unsigned int state =
> > > + sdhci_readl(host, SDHCI_PRESENT_STATE);
> > > +
> > > + if (!(state & SDHCI_DAT_ACTIVE))
> > > return 0;
> > > - } else {
> > > - printf("%s: Timeout for status update!\n",
> > > -__func__);
> > > - return -ETIMEDOUT;
> > > - }
> > > + }
> > > +
> > > + if (get_timer(start) >= SDHCI_READ_STATUS_TIMEOUT) {
> > > + printf("%s: Timeout for status update: %08x %08x\n",
> > > +__func__, stat, mask);
> > > + return -ETIMEDOUT;
> > > }
> > > } while ((stat & mask) != mask);
> > >
> > > diff --git a/include/sdhci.h b/include/sdhci.h
> > > index 70fefca2a97..a1b74e3bd79 100644
> > > --- a/include/sdhci.h
> > > +++ b/include/sdhci.h
> > > @@ -57,6 +57,7 @@
> > > #define SDHCI_PRESENT_STATE 0x24
> > > #define SDHCI_CMD_INHIBIT BIT(0)
> > > #define SDHCI_DATA_INHIBIT BIT(1)
> > > +#define SDHCI_DAT_ACTIVEBIT(2)
> > > #define SDHCI_DOING_WRITE BIT(8)
> > > #define SDHCI_DOING_READBIT(9)
> > > #define SDHCI_SPACE_AVAILABLE BIT(10)
> > > --
> > > 2.35.1.1320.gc452695387.dirty
> > >
RE: [PATCH] mmc: pci: Drop the superfluous cast
> -Original Message- > From: U-Boot On Behalf Of Jaehoon Chung > Sent: Tuesday, October 31, 2023 3:09 PM > To: Bin Meng ; Peng Fan > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH] mmc: pci: Drop the superfluous cast > > On 10/11/23 20:00, Bin Meng wrote: > > dm_pci_map_bar() return a value of (void *) already, hence no need > > to cast it again before assigning to host->ioaddr. > > > > Signed-off-by: Bin Meng > > Reviewed-by: Simon Glass > > Reviewed-by: Jaehoon Chung Applied to u-boot-mmc/master. Thanks! Best Regards, Jaehoon Chung > > Best Regards, > Jaehoon Chung > > > --- > > > > drivers/mmc/pci_mmc.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/mmc/pci_mmc.c b/drivers/mmc/pci_mmc.c > > index 9fb7044029..4d163ccba0 100644 > > --- a/drivers/mmc/pci_mmc.c > > +++ b/drivers/mmc/pci_mmc.c > > @@ -50,8 +50,8 @@ static int pci_mmc_probe(struct udevice *dev) > > desc = mmc_get_blk_desc(>mmc); > > desc->removable = !(plat->cfg.host_caps & MMC_CAP_NONREMOVABLE); > > > > - host->ioaddr = (void *)dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0, 0, 0, > > PCI_REGION_TYPE, > > - PCI_REGION_MEM); > > + host->ioaddr = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0, 0, 0, > > + PCI_REGION_TYPE, PCI_REGION_MEM); > > host->name = dev->name; > > host->cd_gpio = priv->cd_gpio; > > host->mmc = >mmc;
RE: [PATCH] mmc: spl: select SPL_BLK for SPL_DM_MMC
> -Original Message- > From: U-Boot On Behalf Of Jaehoon Chung > Sent: Tuesday, October 31, 2023 2:04 PM > To: Oleksandr Suvorov ; u-boot@lists.denx.de > Cc: Peng Fan > Subject: Re: [PATCH] mmc: spl: select SPL_BLK for SPL_DM_MMC > > On 8/24/23 00:45, Oleksandr Suvorov wrote: > > mmc_bind() in mmc-uclass.c calls blk_create_devicef() which is > > defined in blk-uclass.c, so SPL_BLK is required by SPL_DM_MMC. > > Implicitly select SPL_BLK for SPL_DM_MMC. > > > > Signed-off-by: Oleksandr Suvorov > > Reviewed-by: Tom Rini > > Reviewed-by: Jaehoon Chung Applied to u-boot-mmc/master. Thanks! Best Regards, Jaehoon Chung > > Best Regards, > Jaehoon Chung > > > --- > > > > drivers/mmc/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig > > index de01b9687ba..d24677de076 100644 > > --- a/drivers/mmc/Kconfig > > +++ b/drivers/mmc/Kconfig > > @@ -46,6 +46,7 @@ config SPL_DM_MMC > > depends on SPL_DM && DM_MMC > > default n if ARCH_MVEBU && !MVEBU_SPL_BOOT_DEVICE_MMC > > default y > > + select SPL_BLK > > help > > This enables the MultiMediaCard (MMC) uclass which supports MMC and > > Secure Digital I/O (SDIO) cards. Both removable (SD, micro-SD, etc.)
RE: [PATCH] mmc: sdhci: Rework SDHCI_QUIRK_BROKEN_R1B
Hi,
> -Original Message-
> From: Henrik Grimler
> Sent: Sunday, October 29, 2023 5:31 AM
> To: Sean Anderson
> Cc: u-boot@lists.denx.de; Jaehoon Chung ; Rayagonda
> Kokatanur
> ; Bharat Kumar Reddy Gooty
>
> Subject: Re: [PATCH] mmc: sdhci: Rework SDHCI_QUIRK_BROKEN_R1B
>
> Hi Sean,
>
> Tested on odroid-u2 (exynos4412-odroid) on top of 2024.01-rc1, still
> works fine, so feel free to add:
>
> Tested-by: Henrik Grimler
>
> Best regards,
> Henrik Grimler
>
> On Fri, Oct 27, 2023 at 04:57:03PM -0400, Sean Anderson wrote:
> > As noted in commit 3a6383207be ("mmc: sdhci: add the quirk for broken
> > r1b response"), some MMC controllers don't always set the transfer
> > complete bit with R1b responses.
> >
> > According to the SD Host Controller Simplified Specification v4.20,
> >
> > > In the case of a command pairing with response-with-busy[, Transfer
> > > Complete] is set when busy is de-asserted. Refer to DAT Line Active
> > > and Command Inhibit (DAT) in the Present State register.
> >
> > By polling the DAT Line Active bit in the present state register, we can
> > detect when we are no longer busy, without waiting for a long timeout.
> > This results in much faster reads/writes on buggy controllers.
> >
> > Signed-off-by: Sean Anderson
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> > ---
> > I've CC'd a few people who've added this quirk to controllers recently.
> > Please let me know if your hardware still works. It's possible that my
> > hardware is buggy in a different way.
> >
> > drivers/mmc/sdhci.c | 19 ---
> > include/sdhci.h | 1 +
> > 2 files changed, 13 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> > index fc9c6c37996..0178ed8a11e 100644
> > --- a/drivers/mmc/sdhci.c
> > +++ b/drivers/mmc/sdhci.c
> > @@ -306,14 +306,19 @@ static int sdhci_send_command(struct mmc *mmc, struct
> > mmc_cmd *cmd,
> > if (stat & SDHCI_INT_ERROR)
> > break;
> >
> > - if (get_timer(start) >= SDHCI_READ_STATUS_TIMEOUT) {
> > - if (host->quirks & SDHCI_QUIRK_BROKEN_R1B) {
> > + if (host->quirks & SDHCI_QUIRK_BROKEN_R1B &&
> > + cmd->resp_type & MMC_RSP_BUSY && !data) {
> > + unsigned int state =
> > + sdhci_readl(host, SDHCI_PRESENT_STATE);
> > +
> > + if (!(state & SDHCI_DAT_ACTIVE))
> > return 0;
> > - } else {
> > - printf("%s: Timeout for status update!\n",
> > - __func__);
> > - return -ETIMEDOUT;
> > - }
> > + }
> > +
> > + if (get_timer(start) >= SDHCI_READ_STATUS_TIMEOUT) {
> > + printf("%s: Timeout for status update: %08x %08x\n",
> > + __func__, stat, mask);
> > + return -ETIMEDOUT;
> > }
> > } while ((stat & mask) != mask);
> >
> > diff --git a/include/sdhci.h b/include/sdhci.h
> > index 70fefca2a97..a1b74e3bd79 100644
> > --- a/include/sdhci.h
> > +++ b/include/sdhci.h
> > @@ -57,6 +57,7 @@
> > #define SDHCI_PRESENT_STATE0x24
> > #define SDHCI_CMD_INHIBIT BIT(0)
> > #define SDHCI_DATA_INHIBITBIT(1)
> > +#define SDHCI_DAT_ACTIVE BIT(2)
> > #define SDHCI_DOING_WRITE BIT(8)
> > #define SDHCI_DOING_READ BIT(9)
> > #define SDHCI_SPACE_AVAILABLE BIT(10)
> > --
> > 2.35.1.1320.gc452695387.dirty
> >
RE: [PATCH v2 3/5] rng: Add StarFive JH7110 RNG driver
> -Original Message-
> From: U-Boot On Behalf Of Chanho Park
> Sent: Wednesday, November 1, 2023 8:55 AM
> To: Sughosh Ganu ; Heinrich Schuchardt
> ; Rick Chen
> ; Leo ; u-boot@lists.denx.de
> Cc: Chanho Park
> Subject: [PATCH v2 3/5] rng: Add StarFive JH7110 RNG driver
>
> Adds to support JH7110 TRNG driver which is based on linux kernel's
> jh7110-trng.c. This can support to generate 256-bit random numbers and
> 128-bit but this makes 256-bit default for convenience.
>
> Signed-off-by: Chanho Park
> ---
> drivers/rng/Kconfig | 6 +
> drivers/rng/Makefile | 1 +
> drivers/rng/jh7110_rng.c | 258 +++
> 3 files changed, 265 insertions(+)
> create mode 100644 drivers/rng/jh7110_rng.c
>
> diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> index 994cc35b2744..0dba1e06b429 100644
> --- a/drivers/rng/Kconfig
> +++ b/drivers/rng/Kconfig
> @@ -91,4 +91,10 @@ config TPM_RNG
> functionality. Enable random number generator on TPM
> devices.
>
> +config RNG_JH7110
> + bool "StarFive JH7110 Random Number Generator support"
> + depends on DM_RNG && STARFIVE_JH7110
> + help
> + Enable True Random Number Generator in StarFive JH7110 SoCs.
> +
> endif
> diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
> index 47b323e61ee3..9de762c8a1c3 100644
> --- a/drivers/rng/Makefile
> +++ b/drivers/rng/Makefile
> @@ -15,3 +15,4 @@ obj-$(CONFIG_RNG_IPROC200) += iproc_rng200.o
> obj-$(CONFIG_RNG_SMCCC_TRNG) += smccc_trng.o
> obj-$(CONFIG_RNG_ARM_RNDR) += arm_rndr.o
> obj-$(CONFIG_TPM_RNG) += tpm_rng.o
> +obj-$(CONFIG_RNG_JH7110) += jh7110_rng.o
> diff --git a/drivers/rng/jh7110_rng.c b/drivers/rng/jh7110_rng.c
> new file mode 100644
> index ..37ea8cc39945
> --- /dev/null
> +++ b/drivers/rng/jh7110_rng.c
> @@ -0,0 +1,258 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * TRNG driver for the StarFive JH7110 SoC
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* trng register offset */
> +#define STARFIVE_CTRL0x00
> +#define STARFIVE_STAT0x04
> +#define STARFIVE_MODE0x08
> +#define STARFIVE_SMODE 0x0C
> +#define STARFIVE_IE 0x10
> +#define STARFIVE_ISTAT 0x14
> +#define STARFIVE_RAND0 0x20
> +#define STARFIVE_RAND1 0x24
> +#define STARFIVE_RAND2 0x28
> +#define STARFIVE_RAND3 0x2C
> +#define STARFIVE_RAND4 0x30
> +#define STARFIVE_RAND5 0x34
> +#define STARFIVE_RAND6 0x38
> +#define STARFIVE_RAND7 0x3C
> +#define STARFIVE_AUTO_RQSTS 0x60
> +#define STARFIVE_AUTO_AGE0x64
> +
> +/* CTRL CMD */
> +#define STARFIVE_CTRL_EXEC_NOP 0x0
> +#define STARFIVE_CTRL_GENE_RANDNUM 0x1
> +#define STARFIVE_CTRL_EXEC_RANDRESEED0x2
> +
> +/* STAT */
> +#define STARFIVE_STAT_NONCE_MODE BIT(2)
> +#define STARFIVE_STAT_R256 BIT(3)
> +#define STARFIVE_STAT_MISSION_MODE BIT(8)
> +#define STARFIVE_STAT_SEEDED BIT(9)
> +#define STARFIVE_STAT_LAST_RESEED(x) ((x) << 16)
> +#define STARFIVE_STAT_SRVC_RQST BIT(27)
> +#define STARFIVE_STAT_RAND_GENERATINGBIT(30)
> +#define STARFIVE_STAT_RAND_SEEDING BIT(31)
> +#define STARFIVE_STAT_RUNNING(STARFIVE_STAT_RAND_GENERATING
> | \
> + STARFIVE_STAT_RAND_SEEDING)
> +
> +/* MODE */
> +#define STARFIVE_MODE_R256 BIT(3)
> +
> +/* SMODE */
> +#define STARFIVE_SMODE_NONCE_MODEBIT(2)
> +#define STARFIVE_SMODE_MISSION_MODE BIT(8)
> +#define STARFIVE_SMODE_MAX_REJECTS(x)((x) << 16)
> +
> +/* IE */
> +#define STARFIVE_IE_RAND_RDY_EN BIT(0)
> +#define STARFIVE_IE_SEED_DONE_EN BIT(1)
> +#define STARFIVE_IE_LFSR_LOCKUP_EN BIT(4)
> +#define STARFIVE_IE_GLBL_EN BIT(31)
> +
> +#define STARFIVE_IE_ALL (STARFIVE_IE_GLBL_EN | \
> + STARFIVE_IE_RAND_RDY_EN | \
> + STARFIVE_IE_SEED_DONE_EN | \
> + STARFIVE_IE_LFSR_LOCKUP_EN)
> +
> +/* ISTAT */
> +#define STARFIVE_ISTAT_RAND_RDY BIT(0)
> +#define STARFIVE_ISTAT_SEED_DONE BIT(1)
> +#define STARFIVE_ISTAT_LFSR_LOCKUP BIT(4)
> +
> +#define STARFIVE_RAND_LENsizeof(u32)
> +
> +enum mode {
> + PRNG_128BIT,
> + PRNG_256BIT,
> +};
> +
> +struct starfive_trng_plat {
> + void *base;
> + struct clk *hclk;
> + struct clk *ahb;
> + struct reset_ctl *rst;
> + u32 mode;
> +};
> +
> +static inline int starfive_trng_wait_idle(struct starfive_trng_plat *trng)
> +{
> + u32 stat;
> +
> + return
RE: [PATCH 1/2] riscv: dts: jh7110: Add a gpio-restart node
Hi,
> -Original Message-
> From: Tom Rini
> Sent: Tuesday, October 31, 2023 10:01 PM
> To: Jaehoon Chung
> Cc: u-boot@lists.denx.de; ycli...@andestech.com;
> yanhong.w...@starfivetech.com;
> minda.c...@starfivetech.com; xingyu...@starfivetech.com
> Subject: Re: [PATCH 1/2] riscv: dts: jh7110: Add a gpio-restart node
>
> On Tue, Oct 31, 2023 at 05:24:38PM +0900, Jaehoon Chung wrote:
>
> > Add gpio-restart node to do reset.
> >
> > Before applied this patch, System Reset Extension doesn't appear with
> > sbi command.
> >
> > OpenSBI 1.3
> > Machine:
> > Vendor ID 489
> > Architecture ID 8007
> > Implementation ID 4210427
> > Extensions:
> > sbi_set_timer
> > sbi_console_putchar
> > ...[snip]...
> > IPI Extension
> > RFENCE Extension
> > Hart State Management Extension
> > Performance Monitoring Unit Extension
> >
> > After applied this patch, System Reset Extension is supported from SBI.
> >
> > OpenSBI 1.3
> > Machine:
> > Vendor ID 489
> > Architecture ID 8007
> > Implementation ID 4210427
> > Extensions:
> > sbi_set_timer
> > sbi_console_putchar
> > ...[snip]...
> > IPI Extension
> > RFENCE Extension
> > Hart State Management Extension
> > System Reset Extension
> > Performance Monitoring Unit Extension
> >
> > Signed-off-by: Jaehoon Chung
> > ---
> > arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
> > b/arch/riscv/dts/jh7110-starfive-
> visionfive-2.dtsi
> > index e40f57a15080..e94f9fe826a8 100644
> > --- a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
> > +++ b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
> > @@ -34,6 +34,11 @@
> > device_type = "memory";
> > reg = <0x0 0x4000 0x2 0x0>;
> > };
> > +
> > + gpio-restart {
> > + compatible = "gpio-restart";
> > + gpios = < 35 GPIO_ACTIVE_HIGH>;
> > + };
> > };
> >
> > {
>
> My only concern with this change (and a few other similar things I've
> seen of late) is where is this change with respect to the upstream
> kernel? The goal is the dts files should be able to be dropped in from
> the kernel (except for -u-boot.dtsi), so we don't want to have changed
> get dropped when they're re-synced.
I understood what you said. Its node was applied with first dts files.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/riscv/boot/dts/starfive/jh7110-starfive-vision
five-2.dtsi?id=54baba33392d428a8be4942441a92a9b05cf537e
Then I will wait for re-syncing dt files about visionfive2.
Best Regards,
Jaehoon Chung
>
> --
> Tom
RE: [PATCH v9 4/8] power: regulator: max77663: add regulator support
> -Original Message-
> From: Svyatoslav Ryhel
> Sent: Friday, October 27, 2023 5:26 PM
> To: Tom Rini ; Jaehoon Chung ;
> Simon Glass
> ; Svyatoslav Ryhel
> Cc: u-boot@lists.denx.de
> Subject: [PATCH v9 4/8] power: regulator: max77663: add regulator support
>
> The driver provides regulator set/get voltage
> enable/disable functions for MAXIM MAX77663 PMICs.
>
> Signed-off-by: Svyatoslav Ryhel
> Reviewed-by: Simon Glass
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/power/regulator/Kconfig | 9 +
> drivers/power/regulator/Makefile | 1 +
> drivers/power/regulator/max77663_regulator.c | 375 +++
> 3 files changed, 385 insertions(+)
> create mode 100644 drivers/power/regulator/max77663_regulator.c
>
> diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
> index eb5aa38c1c..581816294c 100644
> --- a/drivers/power/regulator/Kconfig
> +++ b/drivers/power/regulator/Kconfig
> @@ -141,6 +141,15 @@ config SPL_REGULATOR_PWM
> This config enables implementation of driver-model regulator uclass
> features for PWM regulators in SPL.
>
> +config DM_REGULATOR_MAX77663
> + bool "Enable Driver Model for REGULATOR MAX77663"
> + depends on DM_REGULATOR && DM_PMIC_MAX77663
> + ---help---
> + This config enables implementation of driver-model regulator uclass
> + features for REGULATOR MAX77663. The driver supports both DC-to-DC
> + Step-Down (SD) Regulators and Low-Dropout Linear (LDO) Regulators
> + found in MAX77663 PMIC and implements get/set api for value and enable.
> +
> config DM_REGULATOR_MAX77686
> bool "Enable Driver Model for REGULATOR MAX77686"
> depends on DM_REGULATOR && DM_PMIC_MAX77686
> diff --git a/drivers/power/regulator/Makefile
> b/drivers/power/regulator/Makefile
> index d9e0cd5949..8d73169b50 100644
> --- a/drivers/power/regulator/Makefile
> +++ b/drivers/power/regulator/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_REGULATOR_AS3722) += as3722_regulator.o
> obj-$(CONFIG_$(SPL_)REGULATOR_AXP) += axp_regulator.o
> obj-$(CONFIG_$(SPL_)REGULATOR_AXP_USB_POWER) += axp_usb_power.o
> obj-$(CONFIG_$(SPL_)DM_REGULATOR_DA9063) += da9063.o
> +obj-$(CONFIG_$(SPL_)DM_REGULATOR_MAX77663) += max77663_regulator.o
> obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
> obj-$(CONFIG_DM_REGULATOR_NPCM8XX) += npcm8xx_regulator.o
> obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
> diff --git a/drivers/power/regulator/max77663_regulator.c
> b/drivers/power/regulator/max77663_regulator.c
> new file mode 100644
> index 00..ea4b7c63e5
> --- /dev/null
> +++ b/drivers/power/regulator/max77663_regulator.c
> @@ -0,0 +1,375 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright(C) 2023 Svyatoslav Ryhel
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/* fist row is control registers, second is voltage registers */
> +static const char max77663_sd_reg[][MAX77663_SD_NUM] = {
> + { 0x1d, 0x1e, 0x1f, 0x20, 0x21 },
> + { 0x16, 0x17, 0x18, 0x19, 0x2a },
> +};
> +
> +static const char max77663_ldo_reg[MAX77663_LDO_NUM] = {
> + 0x23, 0x25, 0x27, 0x29, 0x2b, 0x2d, 0x2f, 0x31, 0x33
> +};
> +
> +static int max77663_sd_enable(struct udevice *dev, int op, bool *enable)
> +{
> + struct dm_regulator_uclass_plat *uc_pdata =
> + dev_get_uclass_plat(dev);
> + u32 adr = uc_pdata->ctrl_reg;
> + int val, ret;
> +
> + val = pmic_reg_read(dev->parent, adr);
> + if (val < 0)
> + return val;
> +
> + if (op == PMIC_OP_GET) {
> + if (val & SD_STATUS_MASK)
> + *enable = true;
> + else
> + *enable = false;
> +
> + return 0;
> + } else if (op == PMIC_OP_SET) {
> + val &= ~SD_STATUS_MASK;
> +
> + if (*enable)
> + val |= SD_STATUS_MASK;
> +
> + ret = pmic_reg_write(dev->parent, adr, val);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * max77663_*_volt2hex() - convert voltage in uV into
> + * applicable to register hex value
> + *
> + * @idx: regulator index
> + * @uV: voltage in uV
> + *
> + * Return: voltage in hex on success, -ve on failure
> + */
> +static int max77663_sd_volt2hex(int idx, int uV)
> +{
> + switch (idx) {
> + case 0:
> + /* SD0 has m
RE: [PATCH v9 3/8] power: pmic: add the base MAX77663 PMIC support
> -Original Message-
> From: Svyatoslav Ryhel
> Sent: Friday, October 27, 2023 5:26 PM
> To: Tom Rini ; Jaehoon Chung ;
> Simon Glass
> ; Svyatoslav Ryhel
> Cc: u-boot@lists.denx.de
> Subject: [PATCH v9 3/8] power: pmic: add the base MAX77663 PMIC support
>
> Add support to bind the regulators/child nodes with the pmic.
> Also adds the pmic i2c based read/write functions to access pmic
> registers.
>
> Signed-off-by: Svyatoslav Ryhel
> Reviewed-by: Simon Glass
Reviewed-by: Jaehoon Chung
Just add a minor comment at below.
> ---
> doc/device-tree-bindings/pmic/max77663.txt | 84 ++
> drivers/power/pmic/Kconfig | 9 +++
> drivers/power/pmic/Makefile| 1 +
> drivers/power/pmic/max77663.c | 81 +
> include/power/max77663.h | 42 +++
> 5 files changed, 217 insertions(+)
> create mode 100644 doc/device-tree-bindings/pmic/max77663.txt
> create mode 100644 drivers/power/pmic/max77663.c
> create mode 100644 include/power/max77663.h
>
> diff --git a/doc/device-tree-bindings/pmic/max77663.txt
> b/doc/device-tree-bindings/pmic/max77663.txt
> new file mode 100644
> index 00..ddb7d3eb14
> --- /dev/null
> +++ b/doc/device-tree-bindings/pmic/max77663.txt
> @@ -0,0 +1,84 @@
> +MAXIM, MAX77663 PMIC
> +
> +This device uses two drivers:
> +- drivers/power/pmic/max77663.c (for parent device)
> +- drivers/power/regulator/max77663_regulator.c (for child regulators)
> +
> +This chapter describes the binding info for the PMIC driver and regulators.
> +
> +Required properties for PMIC:
> +- compatible: "maxim,max77663"
> +- reg: usually 0x1c or 0x3c
> +
> +With those two properties, the pmic device can be used for read/write only.
> +To bind each regulator, the optional regulators subnode should exists.
> +
> +Optional subnode:
> +- name: regulators (subnode list of each device's regulator)
> +
> +Regulators subnode contains set on supported regulators.
> +
> +Required properties:
> +- regulator-name: used for regulator uclass platform data '.name',
> +
> +List of supported regulator nodes names for max77663:
> +- sd0, sd1, sd2, sd3, ldo0, ldo1, ldo2, ldo3, ldo4, ldo5, ldo6, ldo7, ldo8
> +
> +Optional:
> +- regulator-min-microvolt: minimum allowed Voltage to set
> +- regulator-max-microvolt: minimum allowed Voltage to set
> +- regulator-always-on: regulator should be never disabled
> +- regulator-boot-on: regulator should be enabled by the bootloader
> +
> +Linux driver binding for this driver is compatible.
> +
> +Example:
> +
> +max77663@1c {
> + compatible = "maxim,max77663";
> + reg = <0x1c>;
> +
> + regulators {
> + sd0 {
> + regulator-name = "vdd_cpu";
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <125>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + ...
> +
> + ldo0 {
> + regulator-name = "avdd_pll";
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + };
> +
> + ...
> +
> + ldo2 {
> + regulator-name = "avdd_usb";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + ldo3 {
> + regulator-name = "vdd_sdmmc3";
> + regulator-min-microvolt = <300>;
> + regulator-max-microvolt = <300>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + ...
> +
> + ldo8 {
> + regulator-name = "avdd_dsi_csi";
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + };
> + };
> +};
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index 4a6f0ce093..54665d7e2b 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -184,6 +184,15 @@ config SPL_DM_PMIC_PFUZE100
> This config enables implementation of driver-model pmic uclass features
> for PMIC PFUZE10
[PATCH 2/2] configs: starfive2: Enable CONFIG_SYSRET config
Enable CONFIG_SYSREST config to do reset. Signed-off-by: Jaehoon Chung --- configs/starfive_visionfive2_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/starfive_visionfive2_defconfig b/configs/starfive_visionfive2_defconfig index b21754feafce..afa74e17ebd5 100644 --- a/configs/starfive_visionfive2_defconfig +++ b/configs/starfive_visionfive2_defconfig @@ -122,6 +122,7 @@ CONFIG_PINCTRL_STARFIVE=y # CONFIG_RAM_SIFIVE is not set CONFIG_SYS_NS16550=y CONFIG_CADENCE_QSPI=y +CONFIG_SYSRESET=y CONFIG_TIMER_EARLY=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -- 2.25.1
[PATCH 1/2] riscv: dts: jh7110: Add a gpio-restart node
Add gpio-restart node to do reset.
Before applied this patch, System Reset Extension doesn't appear with
sbi command.
OpenSBI 1.3
Machine:
Vendor ID 489
Architecture ID 8007
Implementation ID 4210427
Extensions:
sbi_set_timer
sbi_console_putchar
...[snip]...
IPI Extension
RFENCE Extension
Hart State Management Extension
Performance Monitoring Unit Extension
After applied this patch, System Reset Extension is supported from SBI.
OpenSBI 1.3
Machine:
Vendor ID 489
Architecture ID 8007
Implementation ID 4210427
Extensions:
sbi_set_timer
sbi_console_putchar
...[snip]...
IPI Extension
RFENCE Extension
Hart State Management Extension
System Reset Extension
Performance Monitoring Unit Extension
Signed-off-by: Jaehoon Chung
---
arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
index e40f57a15080..e94f9fe826a8 100644
--- a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
@@ -34,6 +34,11 @@
device_type = "memory";
reg = <0x0 0x4000 0x2 0x0>;
};
+
+ gpio-restart {
+ compatible = "gpio-restart";
+ gpios = < 35 GPIO_ACTIVE_HIGH>;
+ };
};
{
--
2.25.1
RE: [PATCH v9 1/8] power: pmic: palmas: support TI TPS65913 PMIC
> -Original Message-
> From: Svyatoslav Ryhel
> Sent: Friday, October 27, 2023 5:26 PM
> To: Tom Rini ; Jaehoon Chung ;
> Simon Glass
> ; Svyatoslav Ryhel
> Cc: u-boot@lists.denx.de
> Subject: [PATCH v9 1/8] power: pmic: palmas: support TI TPS65913 PMIC
>
> Existing PALMAS PMIC driver is fully compatible with TI TPS65913
> PMIC found in many Tegra 4 devices, like Tegra Note 7 and ASUS
> TF701T. TPS65913 shares same structure of regulators like TPS659038
> so data can be reused.
>
> Tested-by: Svyatoslav Ryhel # NVIDIA Tegratab
> Signed-off-by: Svyatoslav Ryhel
> Reviewed-by: Simon Glass
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/power/pmic/palmas.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/power/pmic/palmas.c b/drivers/power/pmic/palmas.c
> index eb83c88d56..b2e8a2930c 100644
> --- a/drivers/power/pmic/palmas.c
> +++ b/drivers/power/pmic/palmas.c
> @@ -88,6 +88,7 @@ static struct dm_pmic_ops palmas_ops = {
>
> static const struct udevice_id palmas_ids[] = {
> { .compatible = "ti,tps659038", .data = TPS659038 },
> + { .compatible = "ti,tps65913" , .data = TPS659038 },
> { .compatible = "ti,tps65917" , .data = TPS65917 },
> { }
> };
> --
> 2.39.2
RE: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions
Hi, > -Original Message- > From: Andre Przywara > Sent: Sunday, October 22, 2023 6:19 AM > To: Jernej Škrabec > Cc: Jagan Teki ; Jaehoon Chung > ; Samuel Holland > ; SASANO Takayoshi ; Mikhail > Kalashnikov ; > Piotr Oniszczuk ; u-boot@lists.denx.de; > linux-su...@lists.linux.dev > Subject: Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions > > On Sat, 21 Oct 2023 08:34:06 +0200 > Jernej Škrabec wrote: > > > On Wednesday, October 18, 2023 5:50:12 PM CEST Andre Przywara wrote: > > > So far we have a convoluted #ifdef mesh that guards the early AXP PMIC > > > setup in board.c. That combination of &&, || and negations is very hard > > > to read, maintain and especially to extend. > > > > > > Fortunately we have those same conditions already modelled in the > > > Kconfig file, so they are actually redundant. On top of that the real > > > reason we have those preprocessor guards in the first place is about the > > > symbols that are *conditionally* defined: without #ifdefs the build > > > would break because of them being undefined for many boards. > > > > > > To simplify this, just change the guards to actually look at the symbols > > > needed, so CONFIG_AXP_xxx_VOLT instead of CONFIG_AXPyyy_POWER. > > > This drastically improves the readability of this code, and makes adding > > > PMIC support a pure Kconfig matter. > > > > > > Signed-off-by: Andre Przywara > > > --- > > > board/sunxi/board.c | 32 ++-- > > > drivers/power/Kconfig | 2 +- > > > 2 files changed, 15 insertions(+), 19 deletions(-) > > > > > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c > > > index ebaa9431984..65d79a02c25 100644 > > > --- a/board/sunxi/board.c > > > +++ b/board/sunxi/board.c > > > @@ -597,50 +597,46 @@ void sunxi_board_init(void) > > > } > > > } > > > > > > -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \ > > > - defined CONFIG_AXP818_POWER > > > +#ifdef CONFIG_AXP_DCDC1_VOLT > > > power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT); > > > + power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT); > > > #endif > > > -#if !defined(CONFIG_AXP305_POWER) > > > +#ifdef CONFIG_AXP_DCDC2_VOLT > > > power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT); > > > power_failed |= axp_set_dcdc3(CONFIG_AXP_DCDC3_VOLT); > > > #endif > > > -#if !defined(CONFIG_AXP209_POWER) && !defined(CONFIG_AXP818_POWER) > > > +#ifdef CONFIG_AXP_DCDC4_VOLT > > > power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT); > > > #endif > > > -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \ > > > - defined CONFIG_AXP818_POWER > > > - power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT); > > > -#endif > > > > > > -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \ > > > - defined CONFIG_AXP818_POWER > > > +#ifdef CONFIG_AXP_ALDO1_VOLT > > > power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT); > > > #endif > > > -#if !defined(CONFIG_AXP305_POWER) > > > +#ifdef CONFIG_AXP_ALDO2_VOLT > > > power_failed |= axp_set_aldo2(CONFIG_AXP_ALDO2_VOLT); > > > #endif > > > -#if !defined(CONFIG_AXP152_POWER) && !defined(CONFIG_AXP305_POWER) > > > +#ifdef CONFIG_AXP_ALDO3_VOLT > > > power_failed |= axp_set_aldo3(CONFIG_AXP_ALDO3_VOLT); > > > #endif > > > -#ifdef CONFIG_AXP209_POWER > > > +#ifdef CONFIG_AXP_ALDO4_VOLT > > > power_failed |= axp_set_aldo4(CONFIG_AXP_ALDO4_VOLT); > > > #endif > > > > > > -#if defined(CONFIG_AXP221_POWER) || defined(CONFIG_AXP809_POWER) || \ > > > - defined(CONFIG_AXP818_POWER) > > > +#ifdef CONFIG_AXP_DLDO1_VOLT > > > power_failed |= axp_set_dldo(1, CONFIG_AXP_DLDO1_VOLT); > > > power_failed |= axp_set_dldo(2, CONFIG_AXP_DLDO2_VOLT); > > > -#if !defined CONFIG_AXP809_POWER > > > +#endif > > > +#ifdef CONFIG_AXP_DLDO3_VOLT > > > power_failed |= axp_set_dldo(3, CONFIG_AXP_DLDO3_VOLT); > > > power_failed |= axp_set_dldo(4, CONFIG_AXP_DLDO4_VOLT); > > > #endif > > > +#ifdef CONFIG_AXP_ELDO1_VOLT > > > power_failed |= axp_set_eldo(1, CONFIG_AXP_ELDO1_VOLT); > > > power_failed |= axp_set_eldo(2, CONFIG_AXP_ELDO2_VOLT); > > > power_failed |= axp_set_eldo(3, CONFIG_AXP_ELDO3_VOLT); > &
RE: [PATCH 2/2] sunxi: mmc: Move header to the driver directory
> -Original Message-
> From: Samuel Holland
> Sent: Tuesday, October 31, 2023 2:23 PM
> To: u-boot@lists.denx.de; Jagan Teki ; Andre
> Przywara
>
> Cc: Samuel Holland ; Jaehoon Chung
> ; Peng Fan
>
> Subject: [PATCH 2/2] sunxi: mmc: Move header to the driver directory
>
> The MMC controller driver is (and ought to be) the only user of these
> register definitions. Put them in a header next to the driver to remove
> the dependency on a specific ARM platform's headers.
>
> Due to the sunxi_mmc_init() prototype, the file was not renamed. None of
> the register definitions were changed.
>
> Signed-off-by: Samuel Holland
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> arch/arm/include/asm/arch-sunxi/mmc.h | 139 +-
> drivers/mmc/sunxi_mmc.c | 4 +
> drivers/mmc/sunxi_mmc.h | 138 +
> 3 files changed, 146 insertions(+), 135 deletions(-)
> create mode 100644 drivers/mmc/sunxi_mmc.h
>
> diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
> b/arch/arm/include/asm/arch-sunxi/mmc.h
> index 8ed3e0459c9..b8d91b5c64b 100644
> --- a/arch/arm/include/asm/arch-sunxi/mmc.h
> +++ b/arch/arm/include/asm/arch-sunxi/mmc.h
> @@ -1,139 +1,8 @@
> /* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * (C) Copyright 2007-2011
> - * Allwinner Technology Co., Ltd.
> <https://protect2.fireeye.com/v1/url?k=4cb2b925-2d39ac0a-4cb3326a-
> 74fe485cbfe7-043aa1e18727af33=1=c27b74b1-be1d-4124-b8c0-
> 7d4a5f8076a3=http%3A%2F%2Fwww.allwinnertech.com%2F>
> - * Aaron
> - *
> - * MMC register definition for allwinner sunxi platform.
> - */
>
> -#ifndef _SUNXI_MMC_H
> -#define _SUNXI_MMC_H
> -
> -#include
> -
> -struct sunxi_mmc {
> - u32 gctrl; /* 0x00 global control */
> - u32 clkcr; /* 0x04 clock control */
> - u32 timeout;/* 0x08 time out */
> - u32 width; /* 0x0c bus width */
> - u32 blksz; /* 0x10 block size */
> - u32 bytecnt;/* 0x14 byte count */
> - u32 cmd;/* 0x18 command */
> - u32 arg;/* 0x1c argument */
> - u32 resp0; /* 0x20 response 0 */
> - u32 resp1; /* 0x24 response 1 */
> - u32 resp2; /* 0x28 response 2 */
> - u32 resp3; /* 0x2c response 3 */
> - u32 imask; /* 0x30 interrupt mask */
> - u32 mint; /* 0x34 masked interrupt status */
> - u32 rint; /* 0x38 raw interrupt status */
> - u32 status; /* 0x3c status */
> - u32 ftrglevel; /* 0x40 FIFO threshold watermark*/
> - u32 funcsel;/* 0x44 function select */
> - u32 cbcr; /* 0x48 CIU byte count */
> - u32 bbcr; /* 0x4c BIU byte count */
> - u32 dbgc; /* 0x50 debug enable */
> - u32 res0; /* 0x54 reserved */
> - u32 a12a; /* 0x58 Auto command 12 argument */
> - u32 ntsr; /* 0x5c New timing set register */
> - u32 res1[8];
> - u32 dmac; /* 0x80 internal DMA control */
> - u32 dlba; /* 0x84 internal DMA descr list base address */
> - u32 idst; /* 0x88 internal DMA status */
> - u32 idie; /* 0x8c internal DMA interrupt enable */
> - u32 chda; /* 0x90 */
> - u32 cbda; /* 0x94 */
> - u32 res2[26];
> -#if defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_SUN50I_GEN_H6) ||
> defined(CONFIG_SUNXI_GEN_NCAT2)
> - u32 res3[17];
> - u32 samp_dl;
> - u32 res4[46];
> -#endif
> - u32 fifo; /* 0x100 / 0x200 FIFO access address */
> -};
> -
> -#define SUNXI_MMC_CLK_POWERSAVE (0x1 << 17)
> -#define SUNXI_MMC_CLK_ENABLE (0x1 << 16)
> -#define SUNXI_MMC_CLK_DIVIDER_MASK (0xff)
> -
> -#define SUNXI_MMC_GCTRL_SOFT_RESET (0x1 << 0)
> -#define SUNXI_MMC_GCTRL_FIFO_RESET (0x1 << 1)
> -#define SUNXI_MMC_GCTRL_DMA_RESET(0x1 << 2)
> -#define SUNXI_MMC_GCTRL_RESET(SUNXI_MMC_GCTRL_SOFT_RESET|\
> - SUNXI_MMC_GCTRL_FIFO_RESET|\
> - SUNXI_MMC_GCTRL_DMA_RESET)
> -#define SUNXI_MMC_GCTRL_DMA_ENABLE (0x1 << 5)
> -#define SUNXI_MMC_GCTRL_ACCESS_BY_AHB (0x1 << 31)
> -
> -#define SUNXI_MMC_CMD_RESP_EXPIRE(0x1 << 6)
> -#define SUNXI_MMC_CMD_LONG_RESPONSE (0x1 << 7)
> -#define SUNXI_MMC_CMD_CHK_RESPONSE_CRC (0x1 <<
RE: [PATCH 1/2] sunxi: mmc: Sort compatible strings numerically
> -Original Message-
> From: Samuel Holland
> Sent: Tuesday, October 31, 2023 2:23 PM
> To: u-boot@lists.denx.de; Jagan Teki ; Andre
> Przywara
>
> Cc: Samuel Holland ; Jaehoon Chung
> ; Peng Fan
>
> Subject: [PATCH 1/2] sunxi: mmc: Sort compatible strings numerically
>
> commit 95168d77d391 ("sunxi: add Allwinner R528/T113 SoC support") added
> the new entry out of order.
>
> Signed-off-by: Samuel Holland
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> drivers/mmc/sunxi_mmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 4d6351bf275..7caefa153dc 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -701,13 +701,13 @@ static const struct udevice_id sunxi_mmc_ids[] = {
> { .compatible = "allwinner,sun7i-a20-mmc" },
> { .compatible = "allwinner,sun8i-a83t-emmc" },
> { .compatible = "allwinner,sun9i-a80-mmc" },
> + { .compatible = "allwinner,sun20i-d1-mmc" },
> { .compatible = "allwinner,sun50i-a64-mmc" },
> { .compatible = "allwinner,sun50i-a64-emmc" },
> { .compatible = "allwinner,sun50i-h6-mmc" },
> { .compatible = "allwinner,sun50i-h6-emmc" },
> { .compatible = "allwinner,sun50i-a100-mmc" },
> { .compatible = "allwinner,sun50i-a100-emmc" },
> - { .compatible = "allwinner,sun20i-d1-mmc" },
> { /* sentinel */ }
> };
>
> --
> 2.41.0
RE: [PATCH v2] cmd: mmc: Add mmc reg read command for reading card registers
Hi,
> -Original Message-
> From: U-Boot On Behalf Of Jaehoon Chung
> Sent: Tuesday, October 31, 2023 3:08 PM
> To: Marek Vasut ; u-boot@lists.denx.de
> Cc: Abdellatif El Khlifi ; Heinrich Schuchardt
> ;
> Ilias Apalodimas ; Ramon Fried
> ; Roger Knecht
> ; Sean Edmond ; Simon Glass
> ; Tobias
> Waldekranz
> Subject: Re: [PATCH v2] cmd: mmc: Add mmc reg read command for reading card
> registers
>
> Hi Marek,
>
> On 10/10/23 21:47, Marek Vasut wrote:
> > Add extension to the 'mmc' command to read out the card registers.
> > Currently, only the eMMC OCR/CID/CSD/EXTCSD/RCA/DSR register are
> > supported. A register value can either be displayed or read into
> > an environment variable.
> >
> > Signed-off-by: Marek Vasut
> > ---
> > Cc: Abdellatif El Khlifi
> > Cc: Heinrich Schuchardt
> > Cc: Ilias Apalodimas
> > Cc: Jaehoon Chung
> > Cc: Ramon Fried
> > Cc: Roger Knecht
> > Cc: Sean Edmond
> > Cc: Simon Glass
> > Cc: Tobias Waldekranz
>
> Looks good to me. I have tested with your patch on my target.
>
> mmc reg read cid all
> CID[0]: 0x15010042
> => mmc reg read extcsd all
> EXT_CSD:
> 000: 00 00 00 00 00 00 00 00 00 00
> 010: 00 00 00 00 00 00 39 00 00 00
> ..[snip]..
>
> Tested-by: Jaehoon Chung
> Reviewed-by: Jaehoon Chung
>
> Best Regards,
> Jaehoon Chung
>
> > ---
> > V2: - Update documentation
> > ---
> > cmd/Kconfig | 8
> > cmd/mmc.c | 96 +++
> > doc/usage/cmd/mmc.rst | 26
> > 3 files changed, 130 insertions(+)
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index 6470b138d2f..dcd99757a1e 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -1307,6 +1307,14 @@ config CMD_BKOPS_ENABLE
> > on a eMMC device. The feature is optionally available on eMMC devices
> > conforming to standard >= 4.41.
> >
> > +config CMD_MMC_REG
> > + bool "Enable support for reading card registers in the mmc command"
> > + depends on CMD_MMC
> > + default n
> > + help
> > + Enable the commands for reading card registers. This is useful
> > + mostly for debugging or extracting details from the card.
> > +
> > config CMD_MMC_RPMB
> > bool "Enable support for RPMB in the mmc command"
> > depends on SUPPORT_EMMC_RPMB
> > diff --git a/cmd/mmc.c b/cmd/mmc.c
> > index c6bd81cebbc..c29f44b7a18 100644
> > --- a/cmd/mmc.c
> > +++ b/cmd/mmc.c
> > @@ -1110,6 +1110,93 @@ static int do_mmc_boot_wp(struct cmd_tbl *cmdtp, int
> > flag,
> > return CMD_RET_SUCCESS;
> > }
> >
> > +#if CONFIG_IS_ENABLED(CMD_MMC_REG)
> > +static int do_mmc_reg(struct cmd_tbl *cmdtp, int flag,
> > + int argc, char *const argv[])
> > +{
> > + ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> > + struct mmc *mmc;
> > + int i, ret;
> > + u32 off;
> > +
> > + if (argc < 3 || argc > 5)
> > + return CMD_RET_USAGE;
> > +
> > + mmc = find_mmc_device(curr_device);
> > + if (!mmc) {
> > + printf("no mmc device at slot %x\n", curr_device);
> > + return CMD_RET_FAILURE;
> > + }
> > +
> > + if (IS_SD(mmc)) {
> > + printf("SD registers are not supported\n");
> > + return CMD_RET_FAILURE;
> > + }
> > +
> > + off = simple_strtoul(argv[3], NULL, 10);
> > + if (!strcmp(argv[2], "cid")) {
> > + if (off > 3)
> > + return CMD_RET_USAGE;
> > + printf("CID[%i]: 0x%08x\n", off, mmc->cid[off]);
> > + if (argv[4])
> > + env_set_hex(argv[4], mmc->cid[off]);
> > + return CMD_RET_SUCCESS;
> > + }
> > + if (!strcmp(argv[2], "csd")) {
> > + if (off > 3)
> > + return CMD_RET_USAGE;
> > + printf("CSD[%i]: 0x%08x\n", off, mmc->csd[off]);
> > + if (argv[4])
> > + env_set_hex(argv[4], mmc->csd[off]);
> > + return CMD_RET_SUCCESS;
> > + }
> > + if (!strcmp(argv[2], "dsr")) {
> > + printf("DSR: 0x%08x\n", mmc->dsr);
> > + if (argv[4])
> > + env_set_hex(argv[4], mmc->dsr);
> > + return CMD_RET_SUCCESS;
> > + }
> >
Re: [PATCH 3/3] power: regulator: add AXP313 support
On 10/19/23 00:50, Andre Przywara wrote:
> The X-Powers AXP313a is a small PMIC with just three buck converters and
> three LDOs, one of which is actually fixed (so not modelled here).
>
> Add the compatible string and the respective regulator ranges to allow
> drivers to adjust voltages.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/power/pmic/axp.c| 1 +
> drivers/power/regulator/axp_regulator.c | 17 +
> include/axp_pmic.h | 1 +
> 3 files changed, 19 insertions(+)
>
> diff --git a/drivers/power/pmic/axp.c b/drivers/power/pmic/axp.c
> index 025dac24f28..0e1e45fba74 100644
> --- a/drivers/power/pmic/axp.c
> +++ b/drivers/power/pmic/axp.c
> @@ -87,6 +87,7 @@ static const struct udevice_id axp_pmic_ids[] = {
> { .compatible = "x-powers,axp209", .data = AXP209_ID },
> { .compatible = "x-powers,axp221", .data = AXP221_ID },
> { .compatible = "x-powers,axp223", .data = AXP223_ID },
> + { .compatible = "x-powers,axp313a", .data = AXP313_ID },
> { .compatible = "x-powers,axp803", .data = AXP803_ID },
> { .compatible = "x-powers,axp806", .data = AXP806_ID },
> { .compatible = "x-powers,axp809", .data = AXP809_ID },
> diff --git a/drivers/power/regulator/axp_regulator.c
> b/drivers/power/regulator/axp_regulator.c
> index 02f320eac1e..d27e09538e0 100644
> --- a/drivers/power/regulator/axp_regulator.c
> +++ b/drivers/power/regulator/axp_regulator.c
> @@ -173,6 +173,22 @@ static const struct axp_regulator_plat
> axp22x_regulators[] = {
> { }
> };
>
> +/*
> + * The "dcdc1" regulator has another range, beyond 1.54V up to 3.4V, in
> + * steps of 100mV. We cannot model this easily, but also don't need that,
> + * since it's typically only used for ~1.1V anyway, so just ignore it.
> + * Also the DCDC3 regulator is described wrongly in the (available) manual,
> + * experiments show that the split point is at 1200mV, as for DCDC1/2.
> + */
> +static const struct axp_regulator_plat axp313_regulators[] = {
> + { "dcdc1", 0x10, BIT(0), 0x13, 0x7f, 500, 1540, 10, 70 },
> + { "dcdc2", 0x10, BIT(1), 0x14, 0x7f, 500, 1540, 10, 70 },
> + { "dcdc3", 0x10, BIT(2), 0x15, 0x7f, 500, 1840, 10, 70 },
> + { "aldo1", 0x10, BIT(3), 0x16, 0x1f, 500, 3500, 100, NA },
> + { "dldo1", 0x10, BIT(4), 0x17, 0x1f, 500, 3500, 100, NA },
> + { }
> +};
> +
> static const struct axp_regulator_plat axp803_regulators[] = {
> { "dcdc1", 0x10, BIT(0), 0x20, 0x1f, 1600, 3400, 100, NA },
> { "dcdc2", 0x10, BIT(1), 0x21, 0x7f, 500, 1300, 10, 70 },
> @@ -274,6 +290,7 @@ static const struct axp_regulator_plat *const
> axp_regulators[] = {
> [AXP209_ID] = axp20x_regulators,
> [AXP221_ID] = axp22x_regulators,
> [AXP223_ID] = axp22x_regulators,
> + [AXP313_ID] = axp313_regulators,
> [AXP803_ID] = axp803_regulators,
> [AXP806_ID] = axp806_regulators,
> [AXP809_ID] = axp809_regulators,
> diff --git a/include/axp_pmic.h b/include/axp_pmic.h
> index 4ac64865831..aabafc8501b 100644
> --- a/include/axp_pmic.h
> +++ b/include/axp_pmic.h
> @@ -32,6 +32,7 @@ enum {
> AXP209_ID,
> AXP221_ID,
> AXP223_ID,
> + AXP313_ID,
> AXP803_ID,
> AXP806_ID,
> AXP809_ID,
Re: [PATCH] mmc: pci: Drop the superfluous cast
On 10/11/23 20:00, Bin Meng wrote: > dm_pci_map_bar() return a value of (void *) already, hence no need > to cast it again before assigning to host->ioaddr. > > Signed-off-by: Bin Meng > Reviewed-by: Simon Glass Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > > drivers/mmc/pci_mmc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/pci_mmc.c b/drivers/mmc/pci_mmc.c > index 9fb7044029..4d163ccba0 100644 > --- a/drivers/mmc/pci_mmc.c > +++ b/drivers/mmc/pci_mmc.c > @@ -50,8 +50,8 @@ static int pci_mmc_probe(struct udevice *dev) > desc = mmc_get_blk_desc(>mmc); > desc->removable = !(plat->cfg.host_caps & MMC_CAP_NONREMOVABLE); > > - host->ioaddr = (void *)dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0, 0, 0, > PCI_REGION_TYPE, > - PCI_REGION_MEM); > + host->ioaddr = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0, 0, 0, > + PCI_REGION_TYPE, PCI_REGION_MEM); > host->name = dev->name; > host->cd_gpio = priv->cd_gpio; > host->mmc = >mmc;
Re: [PATCH v2] cmd: mmc: Add mmc reg read command for reading card registers
Hi Marek,
On 10/10/23 21:47, Marek Vasut wrote:
> Add extension to the 'mmc' command to read out the card registers.
> Currently, only the eMMC OCR/CID/CSD/EXTCSD/RCA/DSR register are
> supported. A register value can either be displayed or read into
> an environment variable.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Abdellatif El Khlifi
> Cc: Heinrich Schuchardt
> Cc: Ilias Apalodimas
> Cc: Jaehoon Chung
> Cc: Ramon Fried
> Cc: Roger Knecht
> Cc: Sean Edmond
> Cc: Simon Glass
> Cc: Tobias Waldekranz
Looks good to me. I have tested with your patch on my target.
mmc reg read cid all
CID[0]: 0x15010042
=> mmc reg read extcsd all
EXT_CSD:
000: 00 00 00 00 00 00 00 00 00 00
010: 00 00 00 00 00 00 39 00 00 00
..[snip]..
Tested-by: Jaehoon Chung
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> V2: - Update documentation
> ---
> cmd/Kconfig | 8
> cmd/mmc.c | 96 +++
> doc/usage/cmd/mmc.rst | 26
> 3 files changed, 130 insertions(+)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 6470b138d2f..dcd99757a1e 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1307,6 +1307,14 @@ config CMD_BKOPS_ENABLE
> on a eMMC device. The feature is optionally available on eMMC devices
> conforming to standard >= 4.41.
>
> +config CMD_MMC_REG
> + bool "Enable support for reading card registers in the mmc command"
> + depends on CMD_MMC
> + default n
> + help
> + Enable the commands for reading card registers. This is useful
> + mostly for debugging or extracting details from the card.
> +
> config CMD_MMC_RPMB
> bool "Enable support for RPMB in the mmc command"
> depends on SUPPORT_EMMC_RPMB
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index c6bd81cebbc..c29f44b7a18 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -1110,6 +1110,93 @@ static int do_mmc_boot_wp(struct cmd_tbl *cmdtp, int
> flag,
> return CMD_RET_SUCCESS;
> }
>
> +#if CONFIG_IS_ENABLED(CMD_MMC_REG)
> +static int do_mmc_reg(struct cmd_tbl *cmdtp, int flag,
> + int argc, char *const argv[])
> +{
> + ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> + struct mmc *mmc;
> + int i, ret;
> + u32 off;
> +
> + if (argc < 3 || argc > 5)
> + return CMD_RET_USAGE;
> +
> + mmc = find_mmc_device(curr_device);
> + if (!mmc) {
> + printf("no mmc device at slot %x\n", curr_device);
> + return CMD_RET_FAILURE;
> + }
> +
> + if (IS_SD(mmc)) {
> + printf("SD registers are not supported\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + off = simple_strtoul(argv[3], NULL, 10);
> + if (!strcmp(argv[2], "cid")) {
> + if (off > 3)
> + return CMD_RET_USAGE;
> + printf("CID[%i]: 0x%08x\n", off, mmc->cid[off]);
> + if (argv[4])
> + env_set_hex(argv[4], mmc->cid[off]);
> + return CMD_RET_SUCCESS;
> + }
> + if (!strcmp(argv[2], "csd")) {
> + if (off > 3)
> + return CMD_RET_USAGE;
> + printf("CSD[%i]: 0x%08x\n", off, mmc->csd[off]);
> + if (argv[4])
> + env_set_hex(argv[4], mmc->csd[off]);
> + return CMD_RET_SUCCESS;
> + }
> + if (!strcmp(argv[2], "dsr")) {
> + printf("DSR: 0x%08x\n", mmc->dsr);
> + if (argv[4])
> + env_set_hex(argv[4], mmc->dsr);
> + return CMD_RET_SUCCESS;
> + }
> + if (!strcmp(argv[2], "ocr")) {
> + printf("OCR: 0x%08x\n", mmc->ocr);
> + if (argv[4])
> + env_set_hex(argv[4], mmc->ocr);
> + return CMD_RET_SUCCESS;
> + }
> + if (!strcmp(argv[2], "rca")) {
> + printf("RCA: 0x%08x\n", mmc->rca);
> + if (argv[4])
> + env_set_hex(argv[4], mmc->rca);
> + return CMD_RET_SUCCESS;
> + }
> + if (!strcmp(argv[2], "extcsd") &&
> + mmc->version >= MMC_VERSION_4_41) {
> + ret = mmc_send_ext_csd(mmc, ext_csd);
> + if (ret)
> + return ret;
> + if (!strcmp(argv[3], "all")) {
> + /* Dump the entire register */
> + printf(&q
RE: [PATCH v2 2/2] power: pmic: fix regulators behaviour
Hi,
If will resend this patch according Simon's comment, I will check again.
Best Regards,
Jaehoon Chung
> -Original Message-
> From: Simon Glass
> Sent: Wednesday, July 19, 2023 10:08 AM
> To: Svyatoslav Ryhel
> Cc: Jaehoon Chung ; Patrick Delaunay
> ; u-
> b...@lists.denx.de
> Subject: Re: [PATCH v2 2/2] power: pmic: fix regulators behaviour
>
> Hi Svyatoslav,
>
> On Sun, 16 Jul 2023 at 07:20, Svyatoslav Ryhel wrote:
> >
> >
> >
> > 16 липня 2023 р. 16:08:10 GMT+03:00, Simon Glass
> > написав(-ла):
> > >Hi Svyatoslav,
> > >
> > >On Sat, 15 Jul 2023 at 22:08, Svyatoslav Ryhel wrote:
> > >>
> > >>
> > >>
> > >> 16 липня 2023 р. 02:40:37 GMT+03:00, Simon Glass
> > >> написав(-ла):
> > >> >Hi Svyatoslav,
> > >> >
> > >> >On Sat, 15 Jul 2023 at 12:34, Svyatoslav Ryhel
> > >> >wrote:
> > >> >>
> > >> >> Currently device tree entries of regulators are completely
> > >> >> ignored and regulators are probed only if they are called
> > >> >> by the device which uses it. This results into two issues:
> > >> >> regulators which must run under boot-on or always-on mode
> > >> >> are ignored and not enabled; dts props like voltage are
> > >> >> not applied to the regulator so the regulator may be enabled
> > >> >> with random actual voltage, which may have unexpected
> > >> >> consequences.
> > >> >>
> > >> >> This patch changes this behavior. Post-probe function is
> > >> >> introduced which performs probing of each pmics child and if
> > >> >> it is a regulator, regulator_autoset function is called, which
> > >> >> handles always-on and boot-on regulators, but if none of those
> > >> >> props are set, the regulator is disabled.
> > >> >>
> > >> >> Later disabled regulators can be re-enabled by devices which
> > >> >> use them without issues.
> > >> >>
> > >> >> Signed-off-by: Svyatoslav Ryhel
> > >> >> ---
> > >> >> drivers/power/pmic/pmic-uclass.c | 18 ++
> > >> >> 1 file changed, 18 insertions(+)
> > >> >
> > >> >Can you add a test for this to test/dm/pmic.c ?
> > >> >
> > >>
> > >> Sure, may you specify what I should add to tests/dm/pmic.c? Which
> > >> behavior is needed?
> > >
> > >Just for the change you are making...you should be able to check that
> > >it sets the regulators if you make sure there are some autoset ones in
> > >sandbox.
> >
> > Easier to tell then to do. I am basically interfering into device
> > establishment process. If smth
> goes wrong, any regulator related test should fail. At least my devices
> refused to boot/gave
> unexpected behavior while developing. I will look if I can find anything
> meaningful.
>
> Something like this in test/dm/regulator.c:
>
> struct udevice *pmic, *reg;
>
> // This should automatically probe the
> ut_asserok(pmic_get("pmic@41"), );
>
> // Check that the regulators are probed and on
> ut_assertok(regulator_get_by_devname("ldo2", ));
> ut_assert(regulator_get_enable(reg));
>
> See test.dtsi and sandbox_pmic.dtsi for the DT nodes. You'll need to
> update ldo2 t too add the properties to cause an autoset.
>
> Regards,
> Simon
Re: [PATCH] spl: mmc: Resolve emmc not load image after switched hw partition
On 10/3/23 13:16, Kuan Lim Lee wrote:
> When selecting MMCSD_MODE_EMMCBOOT as boot_mode, emmc do not load U-boot
> proper image after switched hardware partition.
>
> Signed-off-by: Kuan Lim Lee
> Reviewed-by: Chee Hong Ang
> Reviewed-by: Wei Liang Lim
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> common/spl/spl_mmc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index 20f687e138..dc8a45222b 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -447,6 +447,9 @@ int spl_mmc_load(struct spl_image_info *spl_image,
> #endif
> return err;
> }
> + err = mmc_load_image_raw_sector(spl_image, bootdev, mmc, 0);
> + if (!err)
> + return err;
> /* Fall through */
> case MMCSD_MODE_RAW:
> debug("spl: mmc boot mode: raw\n");
Re: [PATCH] power: mp5416: Fix LDO SVAL for MP5416 PMIC
On 9/25/23 07:30, Sidharth Prabukumar wrote:
> The MP5416 PMIC's LDO set-value formula is incorrect. This patch fixes
> it by using the correct formula.
>
> Signed-off-by: Sidharth Prabukumar
> Cc: Jaehoon Chung
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> include/power/mp5416.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/power/mp5416.h b/include/power/mp5416.h
> index dc096fed3f..4326baaa42 100644
> --- a/include/power/mp5416.h
> +++ b/include/power/mp5416.h
> @@ -32,7 +32,7 @@ enum {
> #define MP5416_VSET_SW3_GVAL(x) x) & 0x7f) * 12500) + 60)
> #define MP5416_VSET_SW4_GVAL(x) x) & 0x7f) * 25000) + 80)
> #define MP5416_VSET_LDO_GVAL(x) x) & 0x7f) * 25000) + 80)
> -#define MP5416_VSET_LDO_SVAL(x) x) & 0x7f) * 25000) + 80)
> +#define MP5416_VSET_LDO_SVAL(x) (((x) - 80) / 25000)
> #define MP5416_VSET_SW1_SVAL(x) (((x) - 60) / 12500)
> #define MP5416_VSET_SW2_SVAL(x) (((x) - 80) / 25000)
> #define MP5416_VSET_SW3_SVAL(x) (((x) - 60) / 12500)
Re: [PATCH] mmc: spl: select SPL_BLK for SPL_DM_MMC
On 8/24/23 00:45, Oleksandr Suvorov wrote: > mmc_bind() in mmc-uclass.c calls blk_create_devicef() which is > defined in blk-uclass.c, so SPL_BLK is required by SPL_DM_MMC. > Implicitly select SPL_BLK for SPL_DM_MMC. > > Signed-off-by: Oleksandr Suvorov > Reviewed-by: Tom Rini Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > > drivers/mmc/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig > index de01b9687ba..d24677de076 100644 > --- a/drivers/mmc/Kconfig > +++ b/drivers/mmc/Kconfig > @@ -46,6 +46,7 @@ config SPL_DM_MMC > depends on SPL_DM && DM_MMC > default n if ARCH_MVEBU && !MVEBU_SPL_BOOT_DEVICE_MMC > default y > + select SPL_BLK > help > This enables the MultiMediaCard (MMC) uclass which supports MMC and > Secure Digital I/O (SDIO) cards. Both removable (SD, micro-SD, etc.)
Re: [PATCH v2 2/2] power: pmic: fix regulators behaviour
On 7/16/23 03:34, Svyatoslav Ryhel wrote:
> Currently device tree entries of regulators are completely
> ignored and regulators are probed only if they are called
> by the device which uses it. This results into two issues:
> regulators which must run under boot-on or always-on mode
> are ignored and not enabled; dts props like voltage are
> not applied to the regulator so the regulator may be enabled
> with random actual voltage, which may have unexpected
> consequences.
>
> This patch changes this behavior. Post-probe function is
> introduced which performs probing of each pmics child and if
> it is a regulator, regulator_autoset function is called, which
> handles always-on and boot-on regulators, but if none of those
> props are set, the regulator is disabled.
>
> Later disabled regulators can be re-enabled by devices which
> use them without issues.
>
> Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/power/pmic/pmic-uclass.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/power/pmic/pmic-uclass.c
> b/drivers/power/pmic/pmic-uclass.c
> index 0e2f5e1f41..8a26b519c9 100644
> --- a/drivers/power/pmic/pmic-uclass.c
> +++ b/drivers/power/pmic/pmic-uclass.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #if CONFIG_IS_ENABLED(PMIC_CHILDREN)
> @@ -198,9 +199,26 @@ static int pmic_pre_probe(struct udevice *dev)
> return 0;
> }
>
> +static int pmic_post_probe(struct udevice *dev)
> +{
> + struct udevice *child;
> + int ret;
> +
> + device_foreach_child_probe(child, dev) {
> + if (device_get_uclass_id(child) == UCLASS_REGULATOR) {
> + ret = regulator_autoset(child);
> + if (ret == -EMEDIUMTYPE)
> + regulator_set_enable(child, false);
> + };
> + };
> +
> + return 0;
> +}
> +
> UCLASS_DRIVER(pmic) = {
> .id = UCLASS_PMIC,
> .name = "pmic",
> .pre_probe = pmic_pre_probe,
> + .post_probe = pmic_post_probe,
> .per_device_auto= sizeof(struct uc_pmic_priv),
> };
Re: [PATCH v2 1/2] power: pmic: support TI TPS65913 PMIC
On 7/16/23 03:34, Svyatoslav Ryhel wrote:
> Existing PALMAS PMIC driver is fully compatible with TI TPS65913
> PMIC found in many Tegra 4 devices, like Tegra Note 7 and ASUS
> TF701T. TPS65913 shares same structure of regulators like TPS659038
> so data can be reused.
>
> Tested-by: Svyatoslav Ryhel # NVIDIA Tegratab
> Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/power/pmic/palmas.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/power/pmic/palmas.c b/drivers/power/pmic/palmas.c
> index 6080cbff0b..d6eb9cb433 100644
> --- a/drivers/power/pmic/palmas.c
> +++ b/drivers/power/pmic/palmas.c
> @@ -87,6 +87,7 @@ static struct dm_pmic_ops palmas_ops = {
>
> static const struct udevice_id palmas_ids[] = {
> { .compatible = "ti,tps659038", .data = TPS659038 },
> + { .compatible = "ti,tps65913" , .data = TPS659038 },
> { .compatible = "ti,tps65917" , .data = TPS65917 },
> { }
> };
