Re: [PATCH v2 05/30] global: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILD

2024-09-29 Thread Jonas Karlman
Hi Simon,

On 2024-09-28 22:00, Simon Glass wrote:
> Use the new symbol to refer to any 'SPL' build, including TPL and VPL
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 

[snip]

> diff --git a/arch/arm/include/asm/arch-rockchip/boot0.h 
> b/arch/arm/include/asm/arch-rockchip/boot0.h
> index 0c375e543a5..edb2a31c348 100644
> --- a/arch/arm/include/asm/arch-rockchip/boot0.h
> +++ b/arch/arm/include/asm/arch-rockchip/boot0.h
> @@ -12,7 +12,7 @@
>   * To make life easier for everyone, we build the SPL binary with
>   * space for this 4-byte header already included in the binary.
>   */
> -#ifdef CONFIG_SPL_BUILD
> +#ifdef CONFIG_XPL_BUILD
>   /*
>* We need to add 4 bytes of space for the 'RK33' at the
>* beginning of the executable.  However, as we want to keep
> @@ -39,7 +39,7 @@ entry_counter:
>   .word   0
>  #endif
>  
> -#if (defined(CONFIG_SPL_BUILD) || defined(CONFIG_ARM64))
> +#if (defined(CONFIG_XPL_BUILD) || defined(CONFIG_ARM64))
>   /* U-Boot proper of armv7 do not need this */
>   b reset
>  #endif
> @@ -54,7 +54,7 @@ _start:
>   ARM_VECTORS
>  #endif
>  
> -#if !defined(CONFIG_TPL_BUILD) && defined(CONFIG_SPL_BUILD) && \
> +#if !defined(CONFIG_TPL_BUILD) && defined(CONFIG_XPL_BUILD) && \

This is meant to be for SPL where TF-A is loaded into part of SRAM,
and is only needed/used when CONFIG_TPL=n, so no need to replace it with
XPL_BUILD.

>   (CONFIG_ROCKCHIP_SPL_RESERVE_IRAM > 0)
>   .space CONFIG_ROCKCHIP_SPL_RESERVE_IRAM /* space for the ATF data */
>  #endif
> diff --git a/arch/arm/include/asm/arch-rockchip/cru_rv1126.h 
> b/arch/arm/include/asm/arch-rockchip/cru_rv1126.h
> index 49a1f763795..ae273de3144 100644
> --- a/arch/arm/include/asm/arch-rockchip/cru_rv1126.h
> +++ b/arch/arm/include/asm/arch-rockchip/cru_rv1126.h
> @@ -11,7 +11,7 @@
>  #define KHz  1000
>  #define OSC_HZ   (24 * MHz)
>  
> -#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_KERNEL_BOOT)
> +#if defined(CONFIG_XPL_BUILD) && defined(CONFIG_SPL_KERNEL_BOOT)
>  #define APLL_HZ  (1008 * MHz)
>  #else
>  #define APLL_HZ  (816 * MHz)
> @@ -20,7 +20,7 @@
>  #define CPLL_HZ  (500 * MHz)
>  #define HPLL_HZ  (1400 * MHz)
>  #define PCLK_PDPMU_HZ(100 * MHz)
> -#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_KERNEL_BOOT)
> +#if defined(CONFIG_XPL_BUILD) && defined(CONFIG_SPL_KERNEL_BOOT)
>  #define ACLK_PDBUS_HZ(396 * MHz)
>  #else
>  #define ACLK_PDBUS_HZ(500 * MHz)
> @@ -32,7 +32,7 @@
>  #define HCLK_PDCORE_HZ   (200 * MHz)
>  #define HCLK_PDAUDIO_HZ  (150 * MHz)
>  #define CLK_OSC0_DIV_HZ  (32768)
> -#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_KERNEL_BOOT)
> +#if defined(CONFIG_XPL_BUILD) && defined(CONFIG_SPL_KERNEL_BOOT)
>  #define ACLK_PDVI_HZ (297 * MHz)
>  #define CLK_ISP_HZ   (297 * MHz)
>  #define ACLK_PDISPP_HZ   (297 * MHz)
> @@ -324,7 +324,7 @@ enum {
>   DCLK_VOP_DIV_SHIFT  = 0,
>   DCLK_VOP_DIV_MASK   = 0xff,
>  
> -#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_KERNEL_BOOT)
> +#if defined(CONFIG_XPL_BUILD) && defined(CONFIG_SPL_KERNEL_BOOT)
>   /* CRU_CLK_SEL49_CON */
>   ACLK_PDVI_SEL_SHIFT = 6,
>   ACLK_PDVI_SEL_MASK  = 0x3 << ACLK_PDVI_SEL_SHIFT,
> @@ -397,7 +397,7 @@ enum {
>   CLK_GMAC_SRC_DIV_SHIFT  = 0,
>   CLK_GMAC_SRC_DIV_MASK   = 0x1f << CLK_GMAC_SRC_DIV_SHIFT,
>  
> -#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_KERNEL_BOOT)
> +#if defined(CONFIG_XPL_BUILD) && defined(CONFIG_SPL_KERNEL_BOOT)
>   /* CRU_CLK_SEL68_CON */
>   ACLK_PDISPP_SEL_SHIFT   = 6,
>   ACLK_PDISPP_SEL_MASK= 0x3 << ACLK_PDISPP_SEL_SHIFT,

I am pretty sure all these are meant for SPL where it is possible to
SPL_KERNEL_BOOT, so no need to replace these with XPL_BUILD.

[snip]

> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index 2d7d0f82a2f..edccb2a3980 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -51,7 +51,7 @@ static struct mm_region rk3399_mem_map[] = {
>  
>  struct mm_region *mem_map = rk3399_mem_map;
>  
> -#ifdef CONFIG_SPL_BUILD
> +#ifdef CONFIG_XPL_BUILD
>  
>  #define TIMER_END_COUNT_L0x00
>  #define TIMER_END_COUNT_H0x04
> @@ -83,7 +83,7 @@ void rockchip_stimer_init(void)
>  int arch_cpu_init(void)
>  {
>  
> -#ifdef CONFIG_SPL_BUILD
> +#ifdef CONFIG_XPL_BUILD
>   struct rk3399_pmusgrf_regs *sgrf;
>   struct rk3399_grf_regs *grf;
>  
> @@ -136,7 +136,7 @@ void board_debug_uart_init(void)
>   struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE;
>   struct rockchip_gpio_regs * const gpio = (void *)GPIO0_BASE;
>  
> - if (IS_ENABLED(CONFIG_SPL_BUILD) &&
> + if (IS_ENABLED(CONFIG_XPL_BUILD) &&

This should not be changed to XPL, this part is meant for SPL and does
not even compile when CONFIG_TPL=y and TPL_BUILD is defined.

Re: [PATCH v2 21/30] xpl: Rename u_boot_first_phase to xpl_is_first_phase()

2024-09-28 Thread Jonas Karlman
Hi Simon,

On 2024-09-28 22:00, Simon Glass wrote:
> This is a better name for this function, so update it.
> 
> Tidy up the function comment to mention VPL. Use SPL_BUILD in the SPL
> check, for clarity.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  arch/arm/mach-omap2/am33xx/board.c |  2 +-
>  common/bloblist.c  |  4 ++--
>  common/spl/spl.c   |  4 ++--
>  include/spl.h  | 16 +---
>  4 files changed, 14 insertions(+), 12 deletions(-)
> 

[snip]

> --- a/include/spl.h
> +++ b/include/spl.h
> @@ -34,24 +34,26 @@ struct spl_boot_device;
>  enum boot_device;
>  
>  /*
> - * u_boot_first_phase() - check if this is the first U-Boot phase
> + * xpl_is_first_phase() - check if this is the first U-Boot phase
>   *
> - * U-Boot has up to three phases: TPL, SPL and U-Boot proper. Depending on 
> the
> - * build flags we can determine whether the current build is for the first
> + * U-Boot has up to four phases: TPL, VPL, SPL and U-Boot proper. Depending 
> on
> + * the build flags we can determine whether the current build is for the 
> first
>   * phase of U-Boot or not. If there is no SPL, then this is U-Boot proper. If
>   * there is SPL but no TPL, the the first phase is SPL. If there is TPL, then
> - * it is the first phase.
> + * it is the first phase, etc.
>   *
> - * @returns true if this is the first phase of U-Boot
> + * Note that VPL can never be the first phase. If it exists, it is loaded 
> from
> + * TPL
>   *
> + * Return: true if this is the first phase of U-Boot
>   */
> -static inline bool u_boot_first_phase(void)
> +static inline bool xpl_is_first_phase(void)
>  {
>   if (IS_ENABLED(CONFIG_TPL)) {
>   if (IS_ENABLED(CONFIG_TPL_BUILD))
>   return true;
>   } else if (IS_ENABLED(CONFIG_SPL)) {
> - if (IS_ENABLED(CONFIG_XPL_BUILD))
> + if (IS_ENABLED(CONFIG_SPL_BUILD))

Here is another instance where it made no sense to replace SPL with XPL
to just later restore it back to SPL.

Regards,
Jonas

>   return true;
>   } else {
>   return true;



Re: [PATCH v2 13/30] xpl: Define CONFIG_SPL_BUILD only for the SPL build

2024-09-28 Thread Jonas Karlman
Hi Simon,

On 2024-09-28 22:00, Simon Glass wrote:
> Make this define mean SPL only, not TPL, VPL, etc.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  scripts/Makefile.autoconf | 4 ++--
>  scripts/Makefile.xpl  | 9 ++---
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 

[snip]

> --- a/scripts/Makefile.xpl
> +++ b/scripts/Makefile.xpl
> @@ -21,9 +21,10 @@ include $(srctree)/scripts/Kbuild.include
>  
>  -include include/config/auto.conf
>  
> -# This file contains 0, 2 or 3 lines
> +# This file contains 0, or 2 lines
>  # It is empty for U-Boot proper (where $(obj) is empty)
> -# For any xPL build it contains CONFIG_SPL_BUILD=y and CONFIG_XPL_BUILD=y
> +# For any xPL build it contains CONFIG_XPL_BUILD=y
> +#- for SPL builds it also contains CONFIG_SPL_BUILD=y
>  #- for TPL builds it also contains CONFIG_TPL_BUILD=y
>  #- for VPL builds it also contains CONFIG_VPL_BUILD=y
>  -include $(obj)/include/autoconf.mk
> @@ -31,7 +32,9 @@ include $(srctree)/scripts/Kbuild.include
>  UBOOTINCLUDE := -I$(obj)/include $(UBOOTINCLUDE)
>  
>  KBUILD_CPPFLAGS += -DCONFIG_XPL_BUILD
> -KBUILD_CPPFLAGS += -DCONFIG_XPL_BUILD

This change look strange and this line should have defined
CONFIG_SPL_BUILD prior to this patch.

Regards,
Jonas

> +ifeq ($(CONFIG_SPL_BUILD),y)
> +KBUILD_CPPFLAGS += -DCONFIG_SPL_BUILD
> +endif
>  ifeq ($(CONFIG_TPL_BUILD),y)
>  KBUILD_CPPFLAGS += -DCONFIG_TPL_BUILD
>  else



Re: [PATCH v2 16/30] kconfig: binman: Check for SPL instead of XPL

2024-09-28 Thread Jonas Karlman
Hi Simon,

On 2024-09-28 22:00, Simon Glass wrote:
> Now that SPL means SPL (only) and is not defined for other phases,
> update kconfig rules.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  include/linux/kconfig.h| 10 +-
>  tools/binman/test/generated/autoconf.h |  2 +-
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
> index a59f2a61e6a..ec9584b2426 100644
> --- a/include/linux/kconfig.h
> +++ b/include/linux/kconfig.h
> @@ -40,7 +40,7 @@
>  #define _CONFIG_PREFIX TPL_
>  #elif defined(CONFIG_VPL_BUILD)
>  #define _CONFIG_PREFIX VPL_
> -#elif defined(CONFIG_XPL_BUILD)
> +#elif defined(CONFIG_SPL_BUILD)

This change back from XPL to SPL is probably not needed it you did not
change it to XPL in the first place.

Just doing a mass search and replace is making this series hard to
review.

Personally I did not fully realize that SPL_ or SPL_BUILD meant any xPL
build before this series, so I would look at each SPL_BUILD to XPL_BUILD
and SPL_ to XPL_ change and try to understand the original intent.

I know multiple places where I have used SPL_ and not SPL_TPL_ because
of this, and similar have used SPL_BUILD for parts I only want in SPL
and not in TPL.

How should I best handle sending fixes where I e.g. have used SPL_ in
Makefile that instead should be changed to SPL_TPL_/PHASE_ and similar
avoid a change to XPL_BUILD because the original intent was just for SPL?

I will also suggest you rearrange some of you patches to make this more
reviewable and possible also make git bisect easier, maybe:

- any fixes not involving XPL first, e.g. _SPL to _SPL_TPL in Makefile,
  SPL_BUILD in Kconfig etc
- add XPL_BUILD symbol
- all fixes and cleanup involving XPL_BUILD symbol
- rename and use spl_ to xpl_ functions
- doc updates
- replace SPL_BUILD with XPL_BUILD in code, preferably in multiple
  smaller logical patches instead of a single big patch
- remove SPL_BUILD for TPL and VPL
- rename SPL_ to XPL_ in Makefile
- rename SPL_TPL_ to PHASE_ in Makefile, NAME and PROMPT

or something similar instead of doing the big search and replace early.

Regards,
Jonas

>  #define _CONFIG_PREFIX SPL_
>  #else
>  #define _CONFIG_PREFIX
> @@ -54,7 +54,7 @@
>   * CONFIG_VAL(FOO) evaluates to the value of
>   *  CONFIG_TOOLS_FOO if USE_HOSTCC is defined,
>   *  CONFIG_FOO if CONFIG_XPL_BUILD is undefined,
> - *  CONFIG_SPL_FOO if CONFIG_XPL_BUILD is defined.
> + *  CONFIG_SPL_FOO if CONFIG_SPL_BUILD is defined.
>   *  CONFIG_TPL_FOO if CONFIG_TPL_BUILD is defined.
>   *  CONFIG_VPL_FOO if CONFIG_VPL_BUILD is defined.
>   */
> @@ -107,21 +107,21 @@ long invalid_use_of_IF_ENABLED_INT(void);
>   * CONFIG_IS_ENABLED(FOO) expands to
>   *  1 if USE_HOSTCC is defined and CONFIG_TOOLS_FOO is set to 'y',
>   *  1 if CONFIG_XPL_BUILD is undefined and CONFIG_FOO is set to 'y',
> - *  1 if CONFIG_XPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y',
> + *  1 if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y',
>   *  1 if CONFIG_TPL_BUILD is defined and CONFIG_TPL_FOO is set to 'y',
>   *  0 otherwise.
>   *
>   * CONFIG_IS_ENABLED(FOO, (abc)) expands to
>   *  abc if USE_HOSTCC is defined and CONFIG_TOOLS_FOO is set to 'y',
>   *  abc if CONFIG_XPL_BUILD is undefined and CONFIG_FOO is set to 'y',
> - *  abc if CONFIG_XPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y',
> + *  abc if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y',
>   *  abc if CONFIG_TPL_BUILD is defined and CONFIG_TPL_FOO is set to 'y',
>   *  nothing otherwise.
>   *
>   * CONFIG_IS_ENABLED(FOO, (abc), (def)) expands to
>   *  abc if USE_HOSTCC is defined and CONFIG_TOOLS_FOO is set to 'y',
>   *  abc if CONFIG_XPL_BUILD is undefined and CONFIG_FOO is set to 'y',
> - *  abc if CONFIG_XPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y',
> + *  abc if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y',
>   *  abc if CONFIG_TPL_BUILD is defined and CONFIG_TPL_FOO is set to 'y',
>   *  def otherwise.
>   *
> diff --git a/tools/binman/test/generated/autoconf.h 
> b/tools/binman/test/generated/autoconf.h
> index 75af48f9116..6a23039f469 100644
> --- a/tools/binman/test/generated/autoconf.h
> +++ b/tools/binman/test/generated/autoconf.h
> @@ -1,3 +1,3 @@
>  #define CONFIG_BINMAN 1
> -#define CONFIG_XPL_BUILD 1
> +#define CONFIG_SPL_BUILD 1
>  #define CONFIG_SPL_BINMAN_SYMBOLS 1



Re: [PATCH v2 04/30] scripts: Define CONFIG_XPL_BUILD for all xPL builds

2024-09-28 Thread Jonas Karlman
Hi Simon,

On 2024-09-28 22:00, Simon Glass wrote:
> The new name 'xPL' is intended to indicate a build of any phase which is
> not U-Boot proper. Define it for all such phases.
> 
> Note that we also define CONFIG_SPL_BUILD for all xPL builds. This
> preserves existing behaviour, but future patches will adjust that.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  scripts/Makefile.autoconf | 6 +++---
>  scripts/Makefile.xpl  | 9 +
>  2 files changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/scripts/Makefile.autoconf b/scripts/Makefile.autoconf
> index b42f9b525fe..d7544022a31 100644
> --- a/scripts/Makefile.autoconf
> +++ b/scripts/Makefile.autoconf
> @@ -83,15 +83,15 @@ u-boot.cfg: include/config.h FORCE
>  
>  spl/u-boot.cfg: include/config.h FORCE
>   $(Q)mkdir -p $(dir $@)
> - $(call cmd,u_boot_cfg,-DCONFIG_SPL_BUILD)
> + $(call cmd,u_boot_cfg,-DCONFIG_XPL_BUILD -DCONFIG_SPL_BUILD)
>  
>  tpl/u-boot.cfg: include/config.h FORCE
>   $(Q)mkdir -p $(dir $@)
> - $(call cmd,u_boot_cfg,-DCONFIG_SPL_BUILD -DCONFIG_TPL_BUILD)
> + $(call cmd,u_boot_cfg,-DCONFIG_XPL_BUILD -DCONFIG_SPL_BUILD 
> -DCONFIG_TPL_BUILD)
>  
>  vpl/u-boot.cfg: include/config.h FORCE
>   $(Q)mkdir -p $(dir $@)
> - $(call cmd,u_boot_cfg,-DCONFIG_SPL_BUILD -DCONFIG_VPL_BUILD)
> + $(call cmd,u_boot_cfg,-DCONFIG_XPL_BUILD -DCONFIG_SPL_BUILD 
> -DCONFIG_VPL_BUILD)
>  
>  include/autoconf.mk: u-boot.cfg
>   $(call cmd,autoconf)
> diff --git a/scripts/Makefile.xpl b/scripts/Makefile.xpl
> index 3091311a3d2..ad21d451a30 100644
> --- a/scripts/Makefile.xpl
> +++ b/scripts/Makefile.xpl
> @@ -21,15 +21,16 @@ include $(srctree)/scripts/Kbuild.include
>  
>  -include include/config/auto.conf
>  
> -# This file contains 0, 1 or 2 lines
> +# This file contains 0, 2 or 3 lines
>  # It is empty for U-Boot proper (where $(obj) is empty)
> -# For any xPL build it contains CONFIG_SPL_BUILD=y
> -# For TPL builds it has CONFIG_SPL_BUILD=y and CONFIG_TPL_BUILD=y
> -# For VPL builds it has CONFIG_SPL_BUILD=y and CONFIG_VPL_BUILD=y
> +# For any xPL build it contains CONFIG_SPL_BUILD=y and CONFIG_XPL_BUILD=y
> +#- for TPL builds it also contains CONFIG_TPL_BUILD=y
> +#- for VPL builds it also contains CONFIG_VPL_BUILD=y

This comment block was just added in the prior patch, and now changed
and re-formatted, why not just add the comments in this patch or at
least this patch should only contain the addition of XPL_BUILD.

Regards,
Jonas

>  -include $(obj)/include/autoconf.mk
>  
>  UBOOTINCLUDE := -I$(obj)/include $(UBOOTINCLUDE)
>  
> +KBUILD_CPPFLAGS += -DCONFIG_XPL_BUILD
>  KBUILD_CPPFLAGS += -DCONFIG_SPL_BUILD
>  ifeq ($(CONFIG_TPL_BUILD),y)
>  KBUILD_CPPFLAGS += -DCONFIG_TPL_BUILD



Re: [PATCH 14/42] rockchip: Simplify check for SPL

2024-09-26 Thread Jonas Karlman
Hi Simon,

On 2024-09-27 00:35, Simon Glass wrote:
> Now that SPL means SPL (only) and is not defined for TPL, simplify some
> checks for SPL.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  arch/arm/include/asm/arch-rockchip/boot0.h |  3 +--
>  arch/arm/mach-rockchip/rk3399/rk3399.c |  2 +-
>  drivers/clk/rockchip/clk_rk3368.c  |  8 
>  drivers/ram/rockchip/sdram_rk3288.c| 10 +-
>  drivers/ram/rockchip/sdram_rk3399.c|  2 +-
>  drivers/ram/rockchip/sdram_rv1126.c|  9 +++--
>  6 files changed, 15 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-rockchip/boot0.h 
> b/arch/arm/include/asm/arch-rockchip/boot0.h
> index edb2a31c348..918f0495fa0 100644
> --- a/arch/arm/include/asm/arch-rockchip/boot0.h
> +++ b/arch/arm/include/asm/arch-rockchip/boot0.h
> @@ -54,7 +54,6 @@ _start:
>   ARM_VECTORS
>  #endif
>  
> -#if !defined(CONFIG_TPL_BUILD) && defined(CONFIG_XPL_BUILD) && \
> - (CONFIG_ROCKCHIP_SPL_RESERVE_IRAM > 0)
> +#if defined(CONFIG_SPL_BUILD) && (CONFIG_ROCKCHIP_SPL_RESERVE_IRAM > 0)

This was changed from SPL to XPL just to be changed back to SPL in this
patch?, such change probably just clutter git blame, was the change to
use XPL really necessary in the first place?

Because SPL_BUILD was used together with !TPL_BUILD it is pretty obvious
that SPL_BUILD did not need to change to XPL_BUILD in the first place.

>   .space CONFIG_ROCKCHIP_SPL_RESERVE_IRAM /* space for the ATF data */
>  #endif
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index edccb2a3980..47bcc71038b 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -169,7 +169,7 @@ void board_debug_uart_init(void)
>  }
>  #endif
>  
> -#if defined(CONFIG_XPL_BUILD) && !defined(CONFIG_TPL_BUILD)
> +#if defined(CONFIG_SPL_BUILD)

Same.

>  static void rk3399_force_power_on_reset(void)
>  {
>   ofnode node;
> diff --git a/drivers/clk/rockchip/clk_rk3368.c 
> b/drivers/clk/rockchip/clk_rk3368.c
> index 630253fbb1d..5ba19bce7b2 100644
> --- a/drivers/clk/rockchip/clk_rk3368.c
> +++ b/drivers/clk/rockchip/clk_rk3368.c
> @@ -50,7 +50,7 @@ struct pll_div {
>  (_nr * _no) == hz, #hz "Hz cannot be hit with PLL " \
>  "divisors on line " __stringify(__LINE__));
>  
> -#if IS_ENABLED(CONFIG_XPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
> +#if IS_ENABLED(CONFIG_XPL_BUILD)
>  static const struct pll_div apll_l_init_cfg = PLL_DIVISORS(APLL_L_HZ, 12, 2);
>  static const struct pll_div apll_b_init_cfg = PLL_DIVISORS(APLL_B_HZ, 1, 2);
>  #if !defined(CONFIG_TPL_BUILD)
> @@ -88,7 +88,7 @@ static uint32_t rkclk_pll_get_rate(struct rk3368_cru *cru,
>   }
>  }
>  
> -#if IS_ENABLED(CONFIG_XPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
> +#if IS_ENABLED(CONFIG_XPL_BUILD)
>  static int rkclk_set_pll(struct rk3368_cru *cru, enum rk3368_pll_id pll_id,
>const struct pll_div *div)
>  {
> @@ -130,7 +130,7 @@ static int rkclk_set_pll(struct rk3368_cru *cru, enum 
> rk3368_pll_id pll_id,
>  }
>  #endif
>  
> -#if IS_ENABLED(CONFIG_XPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
> +#if IS_ENABLED(CONFIG_XPL_BUILD)
>  static void rkclk_init(struct rk3368_cru *cru)
>  {
>   u32 apllb, aplll, dpll, cpll, gpll;
> @@ -586,7 +586,7 @@ static int rk3368_clk_probe(struct udevice *dev)
>  
>   priv->cru = map_sysmem(plat->dtd.reg[0], plat->dtd.reg[1]);
>  #endif
> -#if IS_ENABLED(CONFIG_XPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
> +#if IS_ENABLED(CONFIG_XPL_BUILD)
>   rkclk_init(priv->cru);
>  #endif
>  
> diff --git a/drivers/ram/rockchip/sdram_rk3288.c 
> b/drivers/ram/rockchip/sdram_rk3288.c
> index 25ceab98ee9..b6d51068baa 100644
> --- a/drivers/ram/rockchip/sdram_rk3288.c
> +++ b/drivers/ram/rockchip/sdram_rk3288.c
> @@ -84,7 +84,7 @@ const int ddrconf_table[] = {
>  #define DQS_GATE_TRAINING_ERROR_RANK1(2 << 4)
>  
>  #if defined(CONFIG_TPL_BUILD) || \
> - (!defined(CONFIG_TPL) && defined(CONFIG_XPL_BUILD))
> + (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))

Same.

>  static void copy_to_reg(u32 *dest, const u32 *src, u32 n)
>  {
>   int i;
> @@ -1041,7 +1041,7 @@ static int conv_of_plat(struct udevice *dev)
>  static int rk3288_dmc_probe(struct udevice *dev)
>  {
>  #if defined(CONFIG_TPL_BUILD) || \
> - (!defined(CONFIG_TPL) && defined(CONFIG_XPL_BUILD))
> + (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))

Same.

>   struct rk3288_sdram_params *plat = dev_get_plat(dev);
>   struct udevice *dev_clk;
>   struct regmap *map;
> @@ -1051,7 +1051,7 @@ static int rk3288_dmc_probe(struct udevice *dev)
>  
>   priv->pmu = syscon_get_first_range(ROCKCHIP_SYSCON_PMU);
>  #if defined(CONFIG_TPL_BUILD) || \
> - (!defined(CONFIG_TPL) && defined(CONFIG_XPL_BUILD))
> + (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))

Same.

>  #if CONFIG_IS_ENABLED(OF_PLATDATA)
> 

Re: [PATCH v2 1/5] power: regulator: Trigger probe of regulators which are always-on or boot-on

2024-09-26 Thread Jonas Karlman
Hi Marek,

On 2024-09-25 04:21, Marek Vasut wrote:
> In case a regulator DT node contains regulator-always-on or regulator-boot-on
> property, make sure the regulator gets correctly configured by U-Boot on start
> up. Unconditionally probe such regulator drivers. This is a preparatory patch
> for introduction of .regulator_post_probe() which would trigger the regulator
> configuration.
> 
> Parsing of regulator-always-on and regulator-boot-on DT property has been
> moved to regulator_post_bind() as the information is required early, the
> rest of the DT parsing has been kept in regulator_pre_probe() to avoid
> slowing down the boot process.
> 
> Signed-off-by: Marek Vasut 

[snip]

>  
> - debug("'%s' of dev: '%s', has nonunique value: '%s\n",
> -   property, dev->name, uc_pdata->name);
> + /*
> +  * In case the regulator has regulator-always-on or
> +  * regulator-boot-on DT property, trigger probe() to
> +  * configure its default state during startup.
> +  */
> + if (uc_pdata->always_on && uc_pdata->boot_on)

This check for always_on _and_ boot_on does not fully match the commit
message, comment or the old behavior of regulators_enable_boot_on()
where any always_on _or_ boot_on would trigger autoset().

Regards,
Jonas

> + dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
>  
> - return -EINVAL;
> + return 0;
>  }
>  

[snip]


Re: [PATCH 1/4] power: regulator: Trigger probe of regulators which are always-on or boot-on

2024-09-25 Thread Jonas Karlman
On 2024-09-25 12:18, Svyatoslav Ryhel wrote:
> Hello there!
> I was digging this when I had some free time and found that with
> patches from Marek the only difference is that function
> i2c_get_chip_for_busnum is not called for PMIC's main i2c address
> which results in issues with i2c you have seen in logs before. I
> assume this is not a tegra specific issue and not even related to
> these regulator patches itself.

The i2c_get_chip_for_busnum call is typically protected by
CONFIG_IS_ENABLED(DM_I2C), do you have DM_I2C and SPL_DM_I2C enabled?

grep DM_I2C .config

> 
> To verify my suspicions, Tom and Marek my you please dump u-boot log
> with and without patches and with enabled debug logging from
> i2c-uclass and i2c driver of your SoC.
> 
> Here are logs from my device (Tegra SoC)

What board target / defconfig is used? Would like to understand what
bootph- props are used in the built control fdt.

> 
> Not working
> (bootloader) i2c: controller bus 0 at 7000d000, speed 0:
> i2c_init_controller: speed=40
> (bootloader) i2c_init_controller: CLK_DIV_STD_FAST_MODE setting = 25
> (bootloader) i2c_get_chip: Searching bus 'i2c@7000d000' for address 59:
> (bootloader) not found
> (bootloader) pmic_reg_read: reg=37 priv->trans_len:1i2c_xfer: 2 messages
> (bootloader)
> (bootloader) i2c_xfer: chip=0x58, len=0x1
> (bootloader) i2c_write_data: chip=0x58, len=0x1
> (bootloader) write_data:  0x37
> (bootloader) pkt header 1 sent (0x10010)
> (bootloader) pkt header 2 sent (0x0)
> (bootloader) pkt header 3 sent (0x100b0)
> (bootloader) pkt data sent (0x37)
> (bootloader) tegra_i2c_write_data: Error (-1) !!!

Is this at SPL, U-Boot pre-reloc or after relocation? A more complete
boot log may help us understand when this happens.

> 
> Working
> (bootloader) i2c: controller bus 0 at 7000d000, speed 0:
> i2c_init_controller: speed=40
> (bootloader) i2c_init_controller: CLK_DIV_STD_FAST_MODE setting = 25
> (bootloader) pkt header 1 sent (0x10010)
> (bootloader) pkt header 2 sent (0x0)
> (bootloader) pkt header 3 sent (0xb0)
> (bootloader) pkt data sent (0x0)
> (bootloader) i2c_get_chip: Searching bus 'i2c@7000d000' for address 58:
> (bootloader) i2c_get_chip: Searching bus 'i2c@7000d000' for address 59:
> (bootloader) not found
> (bootloader) found, ret=0
> (bootloader) i2c_xfer: 2 messages
> (bootloader) i2c_xfer: chip=0x58, len=0x1
> (bootloader) i2c_write_data: chip=0x58, len=0x1
> (bootloader) write_data:  0xfb
> (bootloader) pkt header 1 sent (0x10010)
> (bootloader) pkt header 2 sent (0x0)
> (bootloader) pkt header 3 sent (0x100b0)
> (bootloader) pkt data sent (0xfb)
> (bootloader) i2c_xfer: chip=0x58, len=0x1

Is the working scenario happening at same call site as not working?

Try with #define LOG_DEBUG in lib/initcall.c and compare/include a
longer part of the boot log.

Regards,
Jonas

> 
> As you can see this part
> 
> (bootloader) pkt header 1 sent (0x10010)
> (bootloader) pkt header 2 sent (0x0)
> (bootloader) pkt header 3 sent (0xb0)
> (bootloader) pkt data sent (0x0)
> (bootloader) i2c_get_chip: Searching bus 'i2c@7000d000' for address 58:
> 
> is missing in log from u-boot where Marek's patches are applied and
> this log fragment co-responds to i2c_get_chip_for_busnum call



Re: [PATCH v2 3/5] power: regulator: Exit from regulator_set_suspend_value on poorly described regulators

2024-09-24 Thread Jonas Karlman
Hi Marek,

On 2024-09-25 04:21, Marek Vasut wrote:
> In case the DT regulator node does not contain 'regulator-max-microvolt'
> property and does not contain 'regulator-state-mem' subnode (like the
> test.dts regul1_scmi: reg@1 {} regulator node), then regulator_pre_probe()
> will parse this regulator node and set uc_pdata->suspend_on = true and
> uc_pdata->suspend_uV = uc_pdata->max_uV, where uc_pdata->max_uV is set
> to -ENODATA because "regulator-max-microvolt" is missing, and therefore
> uc_pdata->suspend_uV is also -ENODATA. In case regulator_autoset() is
> used afterward, it will attempt to call regulator_set_suspend_value()
> with uV = uc_pdata->suspend_uV = -ENODATA and fail with -EINVAL. Check
> for this case in regulator_set_suspend_value() and immediately return 0,
> because there is no way to set meaningful suspend voltage, so do nothing
> and retain the existing settings of the regulator.

I sent a different fix for this some time ago, please check it out:

https://patchwork.ozlabs.org/patch/1964571/

Regards,
Jonas

> 
> Signed-off-by: Marek Vasut 
> ---
> Cc: Ben Wolsieffer 
> Cc: Caleb Connolly 
> Cc: Chris Morgan 
> Cc: Dragan Simic 
> Cc: Eugen Hristev 
> Cc: Francesco Dolcini 
> Cc: Heinrich Schuchardt 
> Cc: Jaehoon Chung 
> Cc: Jagan Teki 
> Cc: Jonas Karlman 
> Cc: Kever Yang 
> Cc: Matteo Lisi 
> Cc: Mattijs Korpershoek 
> Cc: Max Krummenacher 
> Cc: Neil Armstrong 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Philipp Tomsich 
> Cc: Quentin Schulz 
> Cc: Sam Day 
> Cc: Simon Glass 
> Cc: Sumit Garg 
> Cc: Svyatoslav Ryhel 
> Cc: Thierry Reding 
> Cc: Tom Rini 
> Cc: Volodymyr Babchuk 
> Cc: u-boot-amlo...@groups.io
> Cc: u-boot-q...@groups.io
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: New patch
> ---
>  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 14cf3159203..3c05fdf1966 100644
> --- a/drivers/power/regulator/regulator-uclass.c
> +++ b/drivers/power/regulator/regulator-uclass.c
> @@ -85,6 +85,10 @@ int regulator_set_suspend_value(struct udevice *dev, int 
> uV)
>   const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
>   struct dm_regulator_uclass_plat *uc_pdata;
>  
> + /* Regulator did not set limits, assume already configured. */
> + if (uV == -ENODATA)
> + return 0;
> +
>   uc_pdata = dev_get_uclass_plat(dev);
>   if (uc_pdata->min_uV != -ENODATA && uV < uc_pdata->min_uV)
>   return -EINVAL;



Re: [PATCH] power: regulator: Fix power on/off delay issue

2024-09-23 Thread Jonas Karlman
Hi,

On 2024-09-23 15:24, Peng Fan (OSS) wrote:
> From: Ye Li 
> 
> We meet SD initialization issue with some UHS-I SD cards on
> iMX8MM/iMX93/iMX91 EVK. When sending operation condition to card,
> the OCR does not return correct status. We find it is the issue
> in MMC power cycle after below commit applied:
> 4fcba5d (regulator: implement basic reference counter)
> 
> When SD startup, the sequence of MMC power cycle is:
> mmc_power_init(get vmmc_supply dev) -> mmc_power_off -> udelay(2000)
> -> mmc_power_on
> 
> Before the commit, as a fixed regulator, the GPIO is set as:
>   GPIO inactive (in mmc_power_init) ->
>   GPIO inactive and delay off-on-delay-us (in mmc_power_off) ->
>   udelay(2000) ->
>   GPIO active (in mmc_power_on)
> 
> After the commit:
>   GPIO inactive (in mmc_power_init) ->
>   enable_count is 0, regulator_set_enable returns -EALREADY,
>   GPIO is inactive but NO delay (in mmc_power_off) ->
>   udelay(2000) ->
>   GPIO active (in mmc_power_on)

If I understand correctly your regulator is enabled outside of the
reference counting, so the regulator common code never tries to disable
it.

This should probably be solved at the initialization of the reference
count, a gpio controlled regulator should possible check the gpio status
at probe.

Is your regulator flagged with regulator-boot-on flag?

If I remember correctly the reference count should be initialized to 1
with boot-on, if that is the case your regulator should have been
disabled and the delay would be applied.

> 
> Because the lost of off-on-delay-us, the SD card is not completely
> power off. To fix the issue, add the delay after the GPIO setting in
> regulator_common_of_to_plat which is called in device probing.
> So in mmc_power_init, after GPIO is set to default inactive, the
> off-on-delay-us is applied.
> 
> Fixes: 4fcba5d556b ("regulator: implement basic reference counter")
> Signed-off-by: Ye Li 
> Reviewed-by: Peng Fan 
> Signed-off-by: Peng Fan 
> ---
>  drivers/power/regulator/regulator_common.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/power/regulator/regulator_common.c 
> b/drivers/power/regulator/regulator_common.c
> index e3565d32a01..2192e900697 100644
> --- a/drivers/power/regulator/regulator_common.c
> +++ b/drivers/power/regulator/regulator_common.c
> @@ -45,6 +45,12 @@ int regulator_common_of_to_plat(struct udevice *dev,
>   dev_read_u32_default(dev, "u-boot,off-on-delay-us", 0);
>   }
>  
> + if ((flags & GPIOD_IS_OUT_ACTIVE) && plat->startup_delay_us)
> + udelay(plat->startup_delay_us);
> +
> + if (!(flags & GPIOD_IS_OUT_ACTIVE) && plat->off_on_delay_us)
> + udelay(plat->off_on_delay_us);

I do not understand why adding the delay here would solve your issue if
your enable_count is 0 and the GPIO is already inactive why is the power
off delay needed before you power on for the first time? Is your
regulator somehow disabled at probe time or enabled before probe time?

Regards,
Jonas

> +
>   return 0;
>  }
>  



Re: [PATCH v2 18/18] rockchip: Provided SPL control over efuse presence

2024-09-20 Thread Jonas Karlman
Hi Simon,

On 2024-09-20 09:24, Simon Glass wrote:
> This driver should not generally be present in SPL, even if misc devices
> are enabled. Update the Makefile rule accordingly.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  drivers/misc/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index e53d52c47b3..ff984d7b191 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -68,7 +68,7 @@ obj-$(CONFIG_QFW_MMIO) += qfw_mmio.o
>  obj-$(CONFIG_QFW_SMBIOS) += qfw_smbios.o
>  obj-$(CONFIG_SANDBOX) += qfw_sandbox.o
>  endif
> -obj-$(CONFIG_ROCKCHIP_EFUSE) += rockchip-efuse.o
> +obj-$(CONFIG_$(SPL_TPL_)ROCKCHIP_EFUSE) += rockchip-efuse.o
>  obj-$(CONFIG_ROCKCHIP_OTP) += rockchip-otp.o

Please also include similar change for ROCKCHIP_OTP, the EFUSE and OTP
drivers provide same functionality, just for different Rockchip SoCs.

Regards,
Jonas

>  obj-$(CONFIG_$(SPL_TPL_)ROCKCHIP_IODOMAIN) += rockchip-io-domain.o
>  obj-$(CONFIG_SANDBOX) += syscon_sandbox.o misc_sandbox.o



Re: [PATCH v6 0/6] FUSB302 USB-C controller support

2024-09-18 Thread Jonas Karlman
Hi Sebastian,

On 2024-09-18 11:41, Sebastian Reichel wrote:
> Hi Jonas,
> 
> On Wed, Sep 18, 2024 at 09:56:35AM GMT, Jonas Karlman wrote:
>> On 2024-09-05 17:08, Sebastian Reichel wrote:
>>> On ROCK 5B power is usually supplied via it's USB-C port. This port has the
>>> data lines connected to RK3588, VBUS connected to the input regulator and
>>> CC pins connected to FUSB302. FUSB302 is a USB-C controller, which can be
>>> accessed via I2C from RK3588. The USB-C controller is needed to figure out
>>> the USB-C cable orientation, but also to do USB PD communication. Thus it
>>> would be great to enable support for it in the operating system.
>>>
>>> But the USB-PD specification requires, that a device reacts to USB-PD 
>>> messages
>>> send by the power-supply within around 5 seconds. If that does not happen 
>>> the
>>> power-supply assumes, that the device does not support USB-PD. If a device
>>> later starts sending USB-PD messages it is considered an error, which is 
>>> solved
>>> by doing a hard reset. A USB-PD hard reset means, that all supply voltages 
>>> are
>>> removed for a short period of time. For boards, which are solely powered
>>> through their USB-C port, like the Radxa Rock 5B, this results in an machine
>>> reset. This is currently worked around by not describing the FUSB302 in the
>>> kernel DT, so nothing will ever speak USB-PD on the Rock 5B. This means
>>>
>>> 1. the USB-C port cannot be used at all
>>> 2. the board will be running via fallback supply, which provides limited
>>>power capabilities
>>>
>>> In order to avoid the hard reset, this adds FUSB302 support to U-Boot, so
>>> that we react to the power-supply's queries in time. The code, which is
>>> originally from the Linux kernel, consists of two parts:
>>>
>>> 1. the tcpm state machine, which implements the Type C port manager state
>>>machine as described in the USB PD specification
>>> 2. the fusb302 driver, which knows about specific registers
>>>
>>> Especially the first part has been heavily modified compared to the
>>> kernel, which makes use of multiple delayed works and threads. For this
>>> I used a priorly ported version from Rockchip, removed their hacks and
>>> any states not necessary in U-Boot (e.g. audio accessory support).
>>>
>>> This version has been tested on Radxa Rock 5B using the open source TF-A
>>> (patches recently got merged into master branch) using the following power
>>> supplies:
>>>
>>>  * non PD capable (reports 5V 0A)
>>>  * RavPower 90W
>>>  * UGREEN 100W
>>>  * Anker 45W
>>>  * RavPower PB
>>>
>>
>> [snip]
>>
>> This series look good and works great on my ROCK 5B, tested using two
>> different PD capable power supplies, so this entire series is:
>>
>> Reviewed-by: Jonas Karlman 
> 
> Thanks.
> 
>> I did notice that trying to hook up the ROCK 5B from my computer to use
>> UMS in U-Boot there is a slight delay at boot and following is shown:
>>
>>   fusb302 usb-typec@22: TCPM: PD transmit data failed: -110
>>
>> I suspect this work as intended, so nothing blocking.
> 
> Yes. These potential delays are the reason why I only wanted to
> enable this for affected boards.
> 
> I suppose we can try to get rid of the error message for the case
> of not having PD at all.

Not sure we need to do this, was just something I noticed for one of the
tests I typically perform when a board has an usb gadget port in U-Boot.

> Note, that a standard compliant USB port
> (limited to 500mA [USB2] or 900mA [USB3]) is not good enough to
> power the Rock 5B since cpufreq got enabled. the Rock 5Bs in
> Collabora's KernelCI farm were originally powered through a USB
> hub and the hub powered the port off during boot after applying
> the cpufreq patches. So the error might be useful to understand
> why there are boot issues.

My test/use-case only involve U-Boot and using one of the UMS or RockUSB
features to read/write from/to storage from a host computer, e.g. write
u-boot-rockchip.bin or a rootfs to eMMC or NVMe storage.

The ROCK 5B only seem to use/peek around 400mA until U-Boot cli and
around 750-900mA after "pci enum", so using the USB3 port on my host
computer for this test/use-case is fine.

When booting into and running Linux I always ensure to use a proper
power supply for the board :-)

Regards,
Jonas

> 
> Greetings,
> 
> -- Sebastian



Re: [PATCH v6 0/6] FUSB302 USB-C controller support

2024-09-18 Thread Jonas Karlman
On 2024-09-05 17:08, Sebastian Reichel wrote:
> Hi,
> 
> On ROCK 5B power is usually supplied via it's USB-C port. This port has the
> data lines connected to RK3588, VBUS connected to the input regulator and
> CC pins connected to FUSB302. FUSB302 is a USB-C controller, which can be
> accessed via I2C from RK3588. The USB-C controller is needed to figure out
> the USB-C cable orientation, but also to do USB PD communication. Thus it
> would be great to enable support for it in the operating system.
> 
> But the USB-PD specification requires, that a device reacts to USB-PD messages
> send by the power-supply within around 5 seconds. If that does not happen the
> power-supply assumes, that the device does not support USB-PD. If a device
> later starts sending USB-PD messages it is considered an error, which is 
> solved
> by doing a hard reset. A USB-PD hard reset means, that all supply voltages are
> removed for a short period of time. For boards, which are solely powered
> through their USB-C port, like the Radxa Rock 5B, this results in an machine
> reset. This is currently worked around by not describing the FUSB302 in the
> kernel DT, so nothing will ever speak USB-PD on the Rock 5B. This means
> 
> 1. the USB-C port cannot be used at all
> 2. the board will be running via fallback supply, which provides limited
>power capabilities
> 
> In order to avoid the hard reset, this adds FUSB302 support to U-Boot, so
> that we react to the power-supply's queries in time. The code, which is
> originally from the Linux kernel, consists of two parts:
> 
> 1. the tcpm state machine, which implements the Type C port manager state
>machine as described in the USB PD specification
> 2. the fusb302 driver, which knows about specific registers
> 
> Especially the first part has been heavily modified compared to the
> kernel, which makes use of multiple delayed works and threads. For this
> I used a priorly ported version from Rockchip, removed their hacks and
> any states not necessary in U-Boot (e.g. audio accessory support).
> 
> This version has been tested on Radxa Rock 5B using the open source TF-A
> (patches recently got merged into master branch) using the following power
> supplies:
> 
>  * non PD capable (reports 5V 0A)
>  * RavPower 90W
>  * UGREEN 100W
>  * Anker 45W
>  * RavPower PB
> 

[snip]

This series look good and works great on my ROCK 5B, tested using two
different PD capable power supplies, so this entire series is:

Reviewed-by: Jonas Karlman 

I did notice that trying to hook up the ROCK 5B from my computer to use
UMS in U-Boot there is a slight delay at boot and following is shown:

  fusb302 usb-typec@22: TCPM: PD transmit data failed: -110

I suspect this work as intended, so nothing blocking.

Regards,
Jonas


[PATCH v2 2/2] regulator: rk8xx: Use buck variable consistently

2024-09-17 Thread Jonas Karlman
The buck variable is zero based, i.e. buck=0 match BUCK1 in datasheet.

Remove any buck + 1 calculation to be more consistent in usage of the
buck variable across the different RK8xx variants in the driver.

Signed-off-by: Jonas Karlman 
---
v2:
- Move buck + 1 related changes into a separate patch
- Remove all buck + 1 use to be fully consistent
---
 drivers/power/regulator/rk8xx.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/power/regulator/rk8xx.c b/drivers/power/regulator/rk8xx.c
index b910943c2c46..375d06e3207f 100644
--- a/drivers/power/regulator/rk8xx.c
+++ b/drivers/power/regulator/rk8xx.c
@@ -381,7 +381,7 @@ static int _buck_set_value(struct udevice *pmic, int buck, 
int uvolt)
val = ((uvolt - info->min_uv) / info->step_uv) + info->min_sel;
 
debug("%s: volt=%d, buck=%d, reg=0x%x, mask=0x%x, val=0x%x\n",
- __func__, uvolt, buck + 1, info->vsel_reg, mask, val);
+ __func__, uvolt, buck, info->vsel_reg, mask, val);
 
if (priv->variant == RK816_ID) {
pmic_clrsetbits(pmic, info->vsel_reg, mask, val);
@@ -470,7 +470,7 @@ static int _buck_set_suspend_value(struct udevice *pmic, 
int buck, int uvolt)
val = ((uvolt - info->min_uv) / info->step_uv) + info->min_sel;
 
debug("%s: volt=%d, buck=%d, reg=0x%x, mask=0x%x, val=0x%x\n",
- __func__, uvolt, buck + 1, info->vsel_sleep_reg, mask, val);
+ __func__, uvolt, buck, info->vsel_sleep_reg, mask, val);
 
return pmic_clrsetbits(pmic, info->vsel_sleep_reg, mask, val);
 }
@@ -539,9 +539,10 @@ static int _buck_set_suspend_enable(struct udevice *pmic, 
int buck, bool enable)
{
u8 reg;
 
-   if (buck + 1 >= 9) {
+   if (buck >= 8) {
+   /* BUCK9 and BUCK10 */
reg = RK806_POWER_SLP_EN1;
-   mask = BIT(buck + 1 - 3);
+   mask = BIT(buck - 2);
} else {
reg = RK806_POWER_SLP_EN0;
mask = BIT(buck);
@@ -590,9 +591,10 @@ static int _buck_get_suspend_enable(struct udevice *pmic, 
int buck)
{
u8 reg;
 
-   if (buck + 1 >= 9) {
+   if (buck >= 8) {
+   /* BUCK9 and BUCK10 */
reg = RK806_POWER_SLP_EN1;
-   mask = BIT(buck + 1 - 3);
+   mask = BIT(buck - 2);
} else {
reg = RK806_POWER_SLP_EN0;
mask = BIT(buck);
-- 
2.46.1



[PATCH v2 1/2] regulator: rk8xx: Fix buck get and set enabled state on RK806

2024-09-17 Thread Jonas Karlman
Wrong POWER_EN reg is used to get and set enabled state for the RK806
buck 4 and 8 regulators, also wrong POWER_SLP_EN0 bit is used for
suspend state for the RK806 buck 1-8 regulators.

Fix this by not adding one to the zero based buck variable.

Fixes: f172575d92cd ("power: rk8xx: add support for RK806")
Signed-off-by: Jonas Karlman 
Reviewed-by: Kever Yang 
Reviewed-by: Quentin Schulz 
---
v2:
- Move buck + 1 related changes into a separate patch
- Collect r-b tags
---
 drivers/power/regulator/rk8xx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/power/regulator/rk8xx.c b/drivers/power/regulator/rk8xx.c
index 34e61511d884..b910943c2c46 100644
--- a/drivers/power/regulator/rk8xx.c
+++ b/drivers/power/regulator/rk8xx.c
@@ -415,7 +415,7 @@ static int _buck_set_enable(struct udevice *pmic, int buck, 
bool enable)
break;
case RK806_ID:
value = RK806_POWER_EN_CLRSETBITS(buck % 4, enable);
-   en_reg = RK806_POWER_EN((buck + 1) / 4);
+   en_reg = RK806_POWER_EN(buck / 4);
ret = pmic_reg_write(pmic, en_reg, value);
break;
case RK808_ID:
@@ -494,7 +494,7 @@ static int _buck_get_enable(struct udevice *pmic, int buck)
break;
case RK806_ID:
mask = BIT(buck % 4);
-   ret = pmic_reg_read(pmic, RK806_POWER_EN((buck + 1) / 4));
+   ret = pmic_reg_read(pmic, RK806_POWER_EN(buck / 4));
break;
case RK808_ID:
case RK818_ID:
@@ -544,7 +544,7 @@ static int _buck_set_suspend_enable(struct udevice *pmic, 
int buck, bool enable)
mask = BIT(buck + 1 - 3);
} else {
reg = RK806_POWER_SLP_EN0;
-   mask = BIT(buck + 1);
+   mask = BIT(buck);
}
ret = pmic_clrsetbits(pmic, reg, mask, enable ? mask : 
0);
}
@@ -595,7 +595,7 @@ static int _buck_get_suspend_enable(struct udevice *pmic, 
int buck)
mask = BIT(buck + 1 - 3);
} else {
reg = RK806_POWER_SLP_EN0;
-   mask = BIT(buck + 1);
+   mask = BIT(buck);
}
val = pmic_reg_read(pmic, reg);
}
-- 
2.46.1



Re: [PATCH v5 1/6] usb: tcpm: add core framework

2024-09-04 Thread Jonas Karlman
Hi Sebastian,

On 2024-09-03 20:16, Sebastian Reichel wrote:
> This adds TCPM framework in preparation for fusb302 support, which can
> handle USB power delivery messages. This is needed to solve issues with
> devices, that are running from a USB-C port supporting USB-PD, but not
> having a battery.
> 
> Such a device currently boots to the kernel without interacting with
> the power-supply at all. If there are no USB-PD message replies within
> 5 seconds, the power-supply assumes the peripheral is not capable of
> USB-PD. It usually takes more than 5 seconds for the system to reach
> the kernel and probe the I2C based fusb302 chip driver. Thus the
> system always runs into this state. The power-supply's solution to
> fix this error state is a hard reset, which involves removing the
> power from VBUS. Boards without a battery (or huge capacitors) will
> reset at this point resulting in a boot loop.
> 
> This imports the TCPM framework from the kernel. The porting has
> originally been done by Rockchip using hardware timers and the Linux
> kernel's TCPM code from some years ago.
> 
> I had a look at upgrading to the latest TCPM kernel code, but that
> beast became a lot more complex due to adding more USB-C features.
> I believe these features are not needed in U-Boot and with multiple
> kthreads and hrtimers being involved it is non-trivial to port them.
> Instead I worked on stripping down features from the Rockchip port
> to an even more basic level. Also the TCPM code has been reworked
> to avoid complete use of any timers (Rockchip used SoC specific
> hardware timers + IRQ to implement delayed work mechanism). Instead
> the delayed state changes are handled directly from the poll loop.
> 
> Note, that (in contrast to the original Rockchip port) the state
> machine has the same hard reset quirk, that the kernel has - i.e.
> it avoids disabling the CC pin resistors for devices that are not
> self-powered. Without that quirk, the Radxa Rock 5B will not just
> end up doing a machine reset when a hard reset is triggered, but will
> not even recover, because the CPU will loose power and the FUSB302
> will keep this state because of leak voltage arriving through the RX
> serial pin (assuming a serial adapter is connected).
> 
> This also includes a 'tcpm' command, which can be used to get
> information about the current state and the negotiated voltage
> and current.
> 
> Co-developed-by: Wang Jie 
> Signed-off-by: Wang Jie 
> Signed-off-by: Sebastian Reichel 
> ---
>  Makefile |1 +
>  cmd/Kconfig  |7 +
>  cmd/Makefile |1 +
>  cmd/tcpm.c   |  136 ++
>  doc/usage/cmd/tcpm.rst   |   66 +
>  doc/usage/index.rst  |1 +
>  drivers/usb/Kconfig  |2 +
>  drivers/usb/tcpm/Kconfig |8 +
>  drivers/usb/tcpm/Makefile|3 +
>  drivers/usb/tcpm/tcpm-internal.h |  173 +++
>  drivers/usb/tcpm/tcpm-uclass.c   |  145 ++
>  drivers/usb/tcpm/tcpm.c  | 2288 ++
>  include/dm/uclass-id.h   |1 +
>  include/usb/pd.h |  516 +++
>  include/usb/tcpm.h   |   99 ++
>  15 files changed, 3447 insertions(+)
>  create mode 100644 cmd/tcpm.c
>  create mode 100644 doc/usage/cmd/tcpm.rst
>  create mode 100644 drivers/usb/tcpm/Kconfig
>  create mode 100644 drivers/usb/tcpm/Makefile
>  create mode 100644 drivers/usb/tcpm/tcpm-internal.h
>  create mode 100644 drivers/usb/tcpm/tcpm-uclass.c
>  create mode 100644 drivers/usb/tcpm/tcpm.c
>  create mode 100644 include/usb/pd.h
>  create mode 100644 include/usb/tcpm.h
> 

[snip]

> diff --git a/drivers/usb/tcpm/tcpm-uclass.c b/drivers/usb/tcpm/tcpm-uclass.c
> new file mode 100644
> index ..738ab9b2b695
> --- /dev/null
> +++ b/drivers/usb/tcpm/tcpm-uclass.c
> @@ -0,0 +1,145 @@

[snip]

> +
> +static int tcpm_post_bind(struct udevice *dev)
> +{
> + const struct dm_tcpm_ops *drvops = dev_get_driver_ops(dev);
> + const char *cap_str;
> + ofnode node;
> + int ret;
> +
> + /*
> +  * USB Power Delivery (USB PD) specification requires, that 
> communication
> +  * with a sink happens within roughly 5 seconds. Otherwise the source
> +  * might assume that the sink does not support USB PD. Starting to do
> +  * USB PD communication after that results in a hard reset, which 
> briefly
> +  * removes any power from the USB-C port.
> +  *
> +  * On systems with alternative power supplies this is not an issue, but
> +  * systems, which get soleley powered through their USB-C port will end
> +  * up losing their power supply and doing a board level reset. The hard
> +  * reset will also restart the 5 second timeout. That means a operating
> +  * system initializing USB PD will put the system into a boot loop when
> +  * it takes more than 5 seconds from cold boot to the operating system
> +  * starting t

Re: [PATCH] regulator: rk8xx: Fix buck get and set enabled state on RK806

2024-09-02 Thread Jonas Karlman
Hi Quentin,

On 2024-09-02 13:14, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 8/31/24 12:42 AM, Jonas Karlman wrote:
>> Wrong POWER_EN reg is used to get and set enabled state for the RK806
>> buck 4 and 8 regulators, also wrong POWER_SLP_EN0 bit is used for
>> suspend state for the RK806 buck 1-8 regulators.
>>
>> Fix this by not adding one to the zero based buck variable.
>>
>> Fixes: f172575d92cd ("power: rk8xx: add support for RK806")
> 
> Shoot, I made a lot of mistakes in that driver :/
> 
> Thanks for catching those :)
> 
>> Signed-off-by: Jonas Karlman 
>> ---
>>   drivers/power/regulator/rk8xx.c | 12 ++--
>>   1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/power/regulator/rk8xx.c 
>> b/drivers/power/regulator/rk8xx.c
>> index 34e61511d884..3f5ec02b3824 100644
>> --- a/drivers/power/regulator/rk8xx.c
>> +++ b/drivers/power/regulator/rk8xx.c
>> @@ -415,7 +415,7 @@ static int _buck_set_enable(struct udevice *pmic, int 
>> buck, bool enable)
>>  break;
>>  case RK806_ID:
>>  value = RK806_POWER_EN_CLRSETBITS(buck % 4, enable);
>> -en_reg = RK806_POWER_EN((buck + 1) / 4);
>> +en_reg = RK806_POWER_EN(buck / 4);
>>  ret = pmic_reg_write(pmic, en_reg, value);
>>  break;
>>  case RK808_ID:
>> @@ -494,7 +494,7 @@ static int _buck_get_enable(struct udevice *pmic, int 
>> buck)
>>  break;
>>  case RK806_ID:
>>  mask = BIT(buck % 4);
>> -ret = pmic_reg_read(pmic, RK806_POWER_EN((buck + 1) / 4));
>> +ret = pmic_reg_read(pmic, RK806_POWER_EN(buck / 4));
>>  break;
>>  case RK808_ID:
>>  case RK818_ID:
>> @@ -541,10 +541,10 @@ static int _buck_set_suspend_enable(struct udevice 
>> *pmic, int buck, bool enable)
>>   
>>  if (buck + 1 >= 9) {
>>  reg = RK806_POWER_SLP_EN1;
>> -mask = BIT(buck + 1 - 3);
>> +mask = BIT(buck - 2);
> 
> I like my (+ 1 - 3) here to match buck + 1 above. buck + 1 represents 
> the buck number in the datasheet (index starts at one), so you need to 
> subtract 3 to that index to find the bit index in the register.

I understand this reasoning and would fully agree if this was the only
use of buck in BIT(), however each time I tried to scan over this code,
(with buck is 0-based in mind) this buck + 1 - 3 made me stop and
re-think if this really was correct.

I have no strong opinion and can revert this change if you like.

> 
>>  } else {
>>  reg = RK806_POWER_SLP_EN0;
>> -mask = BIT(buck + 1);
>> +mask = BIT(buck);
>>  }
>>  ret = pmic_clrsetbits(pmic, reg, mask, enable ? mask : 
>> 0);
>>  }
>> @@ -592,10 +592,10 @@ static int _buck_get_suspend_enable(struct udevice 
>> *pmic, int buck)
>>   
>>  if (buck + 1 >= 9) {
>>  reg = RK806_POWER_SLP_EN1;
>> -mask = BIT(buck + 1 - 3);
>> +mask = BIT(buck - 2);
> 
> Ditto.
> 
> Just a matter of taste though!

Let me know if you want me to send a v2 with this change reverted.

Regards,
Jonas

> 
> Reviewed-by: Quentin Schulz 
> 
> @Kever Since it's a bugfix, can we have this in your next MR for 
> v2024.10 please? Thanks!
> 
> Thanks!
> Quentin



[PATCH] regulator: rk8xx: Fix buck get and set enabled state on RK806

2024-08-30 Thread Jonas Karlman
Wrong POWER_EN reg is used to get and set enabled state for the RK806
buck 4 and 8 regulators, also wrong POWER_SLP_EN0 bit is used for
suspend state for the RK806 buck 1-8 regulators.

Fix this by not adding one to the zero based buck variable.

Fixes: f172575d92cd ("power: rk8xx: add support for RK806")
Signed-off-by: Jonas Karlman 
---
 drivers/power/regulator/rk8xx.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/power/regulator/rk8xx.c b/drivers/power/regulator/rk8xx.c
index 34e61511d884..3f5ec02b3824 100644
--- a/drivers/power/regulator/rk8xx.c
+++ b/drivers/power/regulator/rk8xx.c
@@ -415,7 +415,7 @@ static int _buck_set_enable(struct udevice *pmic, int buck, 
bool enable)
break;
case RK806_ID:
value = RK806_POWER_EN_CLRSETBITS(buck % 4, enable);
-   en_reg = RK806_POWER_EN((buck + 1) / 4);
+   en_reg = RK806_POWER_EN(buck / 4);
ret = pmic_reg_write(pmic, en_reg, value);
break;
case RK808_ID:
@@ -494,7 +494,7 @@ static int _buck_get_enable(struct udevice *pmic, int buck)
break;
case RK806_ID:
mask = BIT(buck % 4);
-   ret = pmic_reg_read(pmic, RK806_POWER_EN((buck + 1) / 4));
+   ret = pmic_reg_read(pmic, RK806_POWER_EN(buck / 4));
break;
case RK808_ID:
case RK818_ID:
@@ -541,10 +541,10 @@ static int _buck_set_suspend_enable(struct udevice *pmic, 
int buck, bool enable)
 
if (buck + 1 >= 9) {
reg = RK806_POWER_SLP_EN1;
-   mask = BIT(buck + 1 - 3);
+   mask = BIT(buck - 2);
} else {
reg = RK806_POWER_SLP_EN0;
-   mask = BIT(buck + 1);
+   mask = BIT(buck);
}
ret = pmic_clrsetbits(pmic, reg, mask, enable ? mask : 
0);
}
@@ -592,10 +592,10 @@ static int _buck_get_suspend_enable(struct udevice *pmic, 
int buck)
 
if (buck + 1 >= 9) {
reg = RK806_POWER_SLP_EN1;
-   mask = BIT(buck + 1 - 3);
+   mask = BIT(buck - 2);
} else {
reg = RK806_POWER_SLP_EN0;
-   mask = BIT(buck + 1);
+   mask = BIT(buck);
}
val = pmic_reg_read(pmic, reg);
}
-- 
2.46.0



Re: [PATCH 2/2] bootstage: Do not sort records

2024-08-29 Thread Jonas Karlman
Hi Simon,

On 2024-08-29 00:17, Simon Glass wrote:
> Hi Jonas,
> 
> On Wed, 28 Aug 2024 at 13:01, Jonas Karlman  wrote:
>>
>> Hi Simon,
>>
>> On 2024-08-28 20:11, Simon Glass wrote:
>>> Hi again Jonas,
>>>
>>> On Wed, 28 Aug 2024 at 11:06, Simon Glass  wrote:
>>>>
>>>> Hi Jonas,
>>>>
>>>> On Wed, 28 Aug 2024 at 10:15, Jonas Karlman  wrote:
>>>>>
>>>>> Hi Simon,
>>>>>
>>>>> On 2024-08-28 18:01, Simon Glass wrote:
>>>>>> Hi Jonas,
>>>>>>
>>>>>> On Tue, 6 Aug 2024 at 15:50, Simon Glass  wrote:
>>>>>>>
>>>>>>> Hi Jonas,
>>>>>>>
>>>>>>> On Sat, 3 Aug 2024 at 06:42, Jonas Karlman  wrote:
>>>>>>>>
>>>>>>>> The timer counter on Rockchip SoCs may be reset in TF-A, this may cause
>>>>>>>> the bootstage records to be printed out of order and with an incorrect
>>>>>>>> elapsed time.
>>>>>>>
>>>>>>> Eek can we just fix TF-A? That seems like a bug.
>>>>>
>>>>> TF-A is vendor blob, so we have no control of it.
>>>>
>>>> Can we replace it, or is it one of the ones that has not been released?
>>>>
>>>> Can you file a bug with the vendor?
>>>>
>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Fix this by not sorting the bootstage records.
>>>>>>>>
>>>>>>>> Before on a Radxa ZERO 3W (RK3566) board:
>>>>>>>>
>>>>>>>>   => bootstage report
>>>>>>>>   Timer summary in microseconds (12 records):
>>>>>>>>  MarkElapsed  Stage
>>>>>>>> 0  0  reset
>>>>>>>> 7,436  7,436  board_init_f
>>>>>>>>   164,826157,390  SPL
>>>>>>>>   375,392210,566  end phase
>>>>>>>>   423,909 48,517  board_init_r
>>>>>>>>   472,973 49,064  eth_common_init
>>>>>>>>   476,848  3,875  main_loop
>>>>>>>>   477,003155  cli_loop
>>>>>>>>
>>>>>>>>   Accumulated time:
>>>>>>>>7,181  of_live
>>>>>>>>   14,739  dm_spl
>>>>>>>>   15,029  dm_r
>>>>>>>>  315,150  dm_f
>>>>>>>>
>>>>>>>> With this the records can be printed in chronological order when the
>>>>>>>> counter is reset and SPL and board_init_r records show correct elapsed
>>>>>>>> time.
>>>>>>>>
>>>>>>>>   => bootstage report
>>>>>>>>   Timer summary in microseconds (12 records):
>>>>>>>>  MarkElapsed  Stage
>>>>>>>> 0  0  reset
>>>>>>>>   164,437164,437  SPL
>>>>>>>>   375,023210,586  end phase
>>>>>>>> 7,437  7,437  board_init_f
>>>>>>>>   424,390416,953  board_init_r
>>>>>>>>   473,515 49,125  eth_common_init
>>>>>>>>   477,402  3,887  main_loop
>>>>>>>>   477,571169  cli_loop
>>>>>>>>
>>>>>>>>   Accumulated time:
>>>>>>>>   14,734  dm_spl
>>>>>>>>  315,646  dm_f
>>>>>>>>7,339  of_live
>>>>>>>>   14,977  dm_r
>>>>>>>>
>>>>>>>> For the tested board external TPL and BROM take ~164 ms to initialize
>>>>>>>> DRAM and load SPL, SPL take ~210ms to load images from FIT and U-Boot
>>>>>>>> proper take ~477ms to reach cli prompt.
>>>>>>>>
>>>>>>>> Signed-off-by: Jonas Karlman 
>>>>>>>> ---
>>>>>>>>  common/bootstage.c | 12 ++--
>>>>>>>>  1 file changed, 2 insertions(+), 10 deletions

Re: [PATCH 2/2] bootstage: Do not sort records

2024-08-28 Thread Jonas Karlman
Hi Simon,

On 2024-08-28 20:11, Simon Glass wrote:
> Hi again Jonas,
> 
> On Wed, 28 Aug 2024 at 11:06, Simon Glass  wrote:
>>
>> Hi Jonas,
>>
>> On Wed, 28 Aug 2024 at 10:15, Jonas Karlman  wrote:
>>>
>>> Hi Simon,
>>>
>>> On 2024-08-28 18:01, Simon Glass wrote:
>>>> Hi Jonas,
>>>>
>>>> On Tue, 6 Aug 2024 at 15:50, Simon Glass  wrote:
>>>>>
>>>>> Hi Jonas,
>>>>>
>>>>> On Sat, 3 Aug 2024 at 06:42, Jonas Karlman  wrote:
>>>>>>
>>>>>> The timer counter on Rockchip SoCs may be reset in TF-A, this may cause
>>>>>> the bootstage records to be printed out of order and with an incorrect
>>>>>> elapsed time.
>>>>>
>>>>> Eek can we just fix TF-A? That seems like a bug.
>>>
>>> TF-A is vendor blob, so we have no control of it.
>>
>> Can we replace it, or is it one of the ones that has not been released?
>>
>> Can you file a bug with the vendor?
>>
>>>
>>>>>
>>>>>>
>>>>>> Fix this by not sorting the bootstage records.
>>>>>>
>>>>>> Before on a Radxa ZERO 3W (RK3566) board:
>>>>>>
>>>>>>   => bootstage report
>>>>>>   Timer summary in microseconds (12 records):
>>>>>>  MarkElapsed  Stage
>>>>>> 0  0  reset
>>>>>> 7,436  7,436  board_init_f
>>>>>>   164,826157,390  SPL
>>>>>>   375,392210,566  end phase
>>>>>>   423,909 48,517  board_init_r
>>>>>>   472,973 49,064  eth_common_init
>>>>>>   476,848  3,875  main_loop
>>>>>>   477,003155  cli_loop
>>>>>>
>>>>>>   Accumulated time:
>>>>>>7,181  of_live
>>>>>>   14,739  dm_spl
>>>>>>   15,029  dm_r
>>>>>>  315,150  dm_f
>>>>>>
>>>>>> With this the records can be printed in chronological order when the
>>>>>> counter is reset and SPL and board_init_r records show correct elapsed
>>>>>> time.
>>>>>>
>>>>>>   => bootstage report
>>>>>>   Timer summary in microseconds (12 records):
>>>>>>  MarkElapsed  Stage
>>>>>> 0  0  reset
>>>>>>   164,437164,437  SPL
>>>>>>   375,023210,586  end phase
>>>>>> 7,437  7,437  board_init_f
>>>>>>   424,390416,953  board_init_r
>>>>>>   473,515 49,125  eth_common_init
>>>>>>   477,402  3,887  main_loop
>>>>>>   477,571169  cli_loop
>>>>>>
>>>>>>   Accumulated time:
>>>>>>   14,734  dm_spl
>>>>>>  315,646  dm_f
>>>>>>7,339  of_live
>>>>>>   14,977  dm_r
>>>>>>
>>>>>> For the tested board external TPL and BROM take ~164 ms to initialize
>>>>>> DRAM and load SPL, SPL take ~210ms to load images from FIT and U-Boot
>>>>>> proper take ~477ms to reach cli prompt.
>>>>>>
>>>>>> Signed-off-by: Jonas Karlman 
>>>>>> ---
>>>>>>  common/bootstage.c | 12 ++--
>>>>>>  1 file changed, 2 insertions(+), 10 deletions(-)
>>>>>>
>>>>
>>>> To put this more strongly, this breaks the timing output on other boards.
>>>
>>> Please elaborate, I cannot understand why not sorting would break output
>>> on other boards, are other boards adding records out of order?
>>>
>>> Do you have an example of how this change break other boards?
>>
>> Oh sure. The original reason was that the array was ordered by ID.
>> That was changed in [1], which I forgot about.
>>
>> The other bit is for coreboot (or potentially other prior phases) we
>> receive timestamps as a block and add them into U-Boot. We want these
>> to appear in the correct order with respect to the ones already adding
>> to U-Boot.
>>
>> Sadly coreboot uses it

Re: [PATCH 1/2] bootstage: Fix unstash of records from SPL

2024-08-28 Thread Jonas Karlman
Hi Tom,

On 2024-08-28 20:26, Tom Rini wrote:
> On Sat, 03 Aug 2024 12:41:44 +0000, Jonas Karlman wrote:
> 
>> The commit b81e31a1e6c5 ("bootstash: Do not provide a default address
>> for all") changed a bootstage unstash call to bootstage stash, this
>> has resulted in bootstage records stashed in SPL no longer get unstaged
>> in U-Boot proper. Fix this by changing back to a unstage call.
>>
>>
> 
> Applied to u-boot/next, thanks!
> 

I expected this patch to go to master as it fixes a regression
introduced in v2024.10-rc1.

Regards,
Jonas



Re: [PATCH 2/2] bootstage: Do not sort records

2024-08-28 Thread Jonas Karlman
Hi Simon,

On 2024-08-28 18:01, Simon Glass wrote:
> Hi Jonas,
> 
> On Tue, 6 Aug 2024 at 15:50, Simon Glass  wrote:
>>
>> Hi Jonas,
>>
>> On Sat, 3 Aug 2024 at 06:42, Jonas Karlman  wrote:
>>>
>>> The timer counter on Rockchip SoCs may be reset in TF-A, this may cause
>>> the bootstage records to be printed out of order and with an incorrect
>>> elapsed time.
>>
>> Eek can we just fix TF-A? That seems like a bug.

TF-A is vendor blob, so we have no control of it.

>>
>>>
>>> Fix this by not sorting the bootstage records.
>>>
>>> Before on a Radxa ZERO 3W (RK3566) board:
>>>
>>>   => bootstage report
>>>   Timer summary in microseconds (12 records):
>>>  MarkElapsed  Stage
>>> 0  0  reset
>>> 7,436  7,436  board_init_f
>>>   164,826157,390  SPL
>>>   375,392210,566  end phase
>>>   423,909 48,517  board_init_r
>>>   472,973 49,064  eth_common_init
>>>   476,848  3,875  main_loop
>>>   477,003155  cli_loop
>>>
>>>   Accumulated time:
>>>7,181  of_live
>>>   14,739  dm_spl
>>>   15,029  dm_r
>>>  315,150  dm_f
>>>
>>> With this the records can be printed in chronological order when the
>>> counter is reset and SPL and board_init_r records show correct elapsed
>>> time.
>>>
>>>   => bootstage report
>>>   Timer summary in microseconds (12 records):
>>>  MarkElapsed  Stage
>>> 0  0  reset
>>>   164,437164,437  SPL
>>>   375,023210,586  end phase
>>> 7,437  7,437  board_init_f
>>>   424,390416,953  board_init_r
>>>   473,515 49,125  eth_common_init
>>>   477,402  3,887  main_loop
>>>   477,571169  cli_loop
>>>
>>>   Accumulated time:
>>>   14,734  dm_spl
>>>  315,646  dm_f
>>>7,339  of_live
>>>   14,977  dm_r
>>>
>>> For the tested board external TPL and BROM take ~164 ms to initialize
>>> DRAM and load SPL, SPL take ~210ms to load images from FIT and U-Boot
>>> proper take ~477ms to reach cli prompt.
>>>
>>> Signed-off-by: Jonas Karlman 
>>> ---
>>>  common/bootstage.c | 12 ++--
>>>  1 file changed, 2 insertions(+), 10 deletions(-)
>>>
> 
> To put this more strongly, this breaks the timing output on other boards.

Please elaborate, I cannot understand why not sorting would break output
on other boards, are other boards adding records out of order?

Do you have an example of how this change break other boards?

> 
> At the very least, this should be Kconfig option just enabled for
> boards with a broken ATF.

I can add a Kconfig option, but would like to understand why other/any
board would need to sort the records in the first place.

Regards,
Jonas

> 
> Regards,
> Simon



Re: OF_UPSTREAM vs. additional dtbs

2024-08-27 Thread Jonas Karlman
Hi Sumit,

On 2024-08-27 09:11, Sumit Garg wrote:
> On Mon, 26 Aug 2024 at 17:51, Jonas Karlman  wrote:
>>
>> Hi Sumit,
>>
>> On 2024-08-26 13:48, Sumit Garg wrote:
>>> Hi Jonas,
>>>
>>> On Mon, 26 Aug 2024 at 14:27, Jonas Karlman  wrote:
>>>>
>>>> Hi Sumit,
>>>>
>>>> On 2024-08-26 08:44, Sumit Garg wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, 14 Aug 2024 at 22:14, Jan Kiszka  wrote:
>>>>>>
>>>>>> On 14.08.24 11:41, Jan Kiszka wrote:
>>>>>>> On 13.08.24 14:52, Nishanth Menon wrote:
>>>>>>>> On 11:16-20240813, Jan Kiszka wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but 
>>>>>>>>> I'm
>>>>>>>>> facing issues because I need to still build the u-boot-only overlays. 
>>>>>>>>> It
>>>>>>>>> is also a bit weird (but works) having to specify
>>>>>>>>>
>>>>>>>>> CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl"
>>>>>>>>>
>>>>>>>
>>>>>>> Actually, this does NOT work: I just had a long morning debugging SPL
>>>>>>> which no longer started because it picked the non-filtered dtb. The
>>>>>>> filtered one ended up in a folder outside of the u-boot sources because
>>>>>>> of all those ../ and hard-wiring to dts/upstream.
>>>>>>>
>>>>>>>>> for our spl dtb.
>>>>>>>>>
>>>>>>>>> Are there means to still build certain dtb[o] files in 
>>>>>>>>> arch//dts?
>>>>>>>>> I'm a bit lost in the Makefile forest.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sumit: Any suggestions?
>>>>>>>>
>>>>>
>>>>> Apologies for the delayed reply. I was a bit busy with other high
>>>>> priority stuff.
>>>>>
>>>>>>>
>>>>>>> I would really like to hear some better proposals than my local
>>>>>>> workarounds to far. They don't converge although I already patched some
>>>>>>> core Makefile (overlays are building now).
>>>>>>>
>>>>>>
>>>>>> OK, I side-stepped the spl issue by using one of our variant DTBs for
>>>>>> spl as well - happens to work.
>>>>>
>>>>> That's good to know.
>>>>>
>>>>>>
>>>>>> For the overlays, I need to add
>>>>>>
>>>>>> --- a/scripts/Makefile.dts
>>>>>> +++ b/scripts/Makefile.dts
>>>>>> @@ -1,5 +1,7 @@
>>>>>>  # SPDX-License-Identifier: GPL-2.0+
>>>>>>
>>>>>> +include $(srctree)/config.mk
>>>>>> +
>>>>>>  dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) 
>>>>>> $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
>>>>>>
>>>>>>  ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
>>>>>>
>>>>>>
>>>>>> in order to then be able to do
>>>>>>
>>>>>> --- a/board/siemens/iot2050/config.mk
>>>>>> +++ b/board/siemens/iot2050/config.mk
>>>>>> @@ -5,4 +5,12 @@
>>>>>>  # Authors:
>>>>>>  #   Jan Kiszka 
>>>>>>
>>>>>> +ifneq ($(CONFIG_SPL_BUILD),y)
>>>>>> +dtbo-list = \
>>>>>> +   k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \
>>>>>> +   k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay
>>>>>> +
>>>>>> +dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list))
>>>>>> +endif
>>>>>> +
>>>>>>  flash.bin: all
>>>>>>
>>>>>>
>>>>>> Does that make sense?
>>>>>
>>>>> A switch to OF_UPSTREAM means that we build all the DT artifacts from
>>>>> dts/upstream/src/ directory with the only exception that we include
>>>>> U-Boot specific ove

Re: OF_UPSTREAM vs. additional dtbs

2024-08-26 Thread Jonas Karlman
Hi Sumit,

On 2024-08-26 13:48, Sumit Garg wrote:
> Hi Jonas,
> 
> On Mon, 26 Aug 2024 at 14:27, Jonas Karlman  wrote:
>>
>> Hi Sumit,
>>
>> On 2024-08-26 08:44, Sumit Garg wrote:
>>> Hi,
>>>
>>> On Wed, 14 Aug 2024 at 22:14, Jan Kiszka  wrote:
>>>>
>>>> On 14.08.24 11:41, Jan Kiszka wrote:
>>>>> On 13.08.24 14:52, Nishanth Menon wrote:
>>>>>> On 11:16-20240813, Jan Kiszka wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm
>>>>>>> facing issues because I need to still build the u-boot-only overlays. It
>>>>>>> is also a bit weird (but works) having to specify
>>>>>>>
>>>>>>> CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl"
>>>>>>>
>>>>>
>>>>> Actually, this does NOT work: I just had a long morning debugging SPL
>>>>> which no longer started because it picked the non-filtered dtb. The
>>>>> filtered one ended up in a folder outside of the u-boot sources because
>>>>> of all those ../ and hard-wiring to dts/upstream.
>>>>>
>>>>>>> for our spl dtb.
>>>>>>>
>>>>>>> Are there means to still build certain dtb[o] files in arch//dts?
>>>>>>> I'm a bit lost in the Makefile forest.
>>>>>>>
>>>>>>
>>>>>> Sumit: Any suggestions?
>>>>>>
>>>
>>> Apologies for the delayed reply. I was a bit busy with other high
>>> priority stuff.
>>>
>>>>>
>>>>> I would really like to hear some better proposals than my local
>>>>> workarounds to far. They don't converge although I already patched some
>>>>> core Makefile (overlays are building now).
>>>>>
>>>>
>>>> OK, I side-stepped the spl issue by using one of our variant DTBs for
>>>> spl as well - happens to work.
>>>
>>> That's good to know.
>>>
>>>>
>>>> For the overlays, I need to add
>>>>
>>>> --- a/scripts/Makefile.dts
>>>> +++ b/scripts/Makefile.dts
>>>> @@ -1,5 +1,7 @@
>>>>  # SPDX-License-Identifier: GPL-2.0+
>>>>
>>>> +include $(srctree)/config.mk
>>>> +
>>>>  dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) 
>>>> $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
>>>>
>>>>  ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
>>>>
>>>>
>>>> in order to then be able to do
>>>>
>>>> --- a/board/siemens/iot2050/config.mk
>>>> +++ b/board/siemens/iot2050/config.mk
>>>> @@ -5,4 +5,12 @@
>>>>  # Authors:
>>>>  #   Jan Kiszka 
>>>>
>>>> +ifneq ($(CONFIG_SPL_BUILD),y)
>>>> +dtbo-list = \
>>>> +   k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \
>>>> +   k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay
>>>> +
>>>> +dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list))
>>>> +endif
>>>> +
>>>>  flash.bin: all
>>>>
>>>>
>>>> Does that make sense?
>>>
>>> A switch to OF_UPSTREAM means that we build all the DT artifacts from
>>> dts/upstream/src/ directory with the only exception that we include
>>> U-Boot specific overrides via *-u-boot.dtsi from arch//dts. In
>>> case of overlays, is there any reason for IOT2050 board overlays not
>>> being pushed into Linux kernel repo? AFAIU, overlays are also
>>> describing puggable hardware so they shouldn't be referred to as
>>> "u-boot-only" overlays.
>>
>> I have a related issue where I would like to build board DT from
>> dts/upstream, however there is also a need for a limited U-Boot specific
>> DT that only is intended for initial boot so that U-Boot at runtime can
>> determine what hw revision is booting and select correct DT to use for
>> U-Boot proper and OS.
>>
>> For now I have just set the board target to use OF_UPSTREAM=n and
>> instead created minimal .dts-files in arch//dts that include the
>> full .dts-file from dts/upstream.
>>
>> Any suggestion on how we better can support having a U-Boot only
>> .dts-f

Re: OF_UPSTREAM vs. additional dtbs

2024-08-26 Thread Jonas Karlman
Hi Sumit,

On 2024-08-26 08:44, Sumit Garg wrote:
> Hi,
> 
> On Wed, 14 Aug 2024 at 22:14, Jan Kiszka  wrote:
>>
>> On 14.08.24 11:41, Jan Kiszka wrote:
>>> On 13.08.24 14:52, Nishanth Menon wrote:
 On 11:16-20240813, Jan Kiszka wrote:
> Hi all,
>
> I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm
> facing issues because I need to still build the u-boot-only overlays. It
> is also a bit weird (but works) having to specify
>
> CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl"
>
>>>
>>> Actually, this does NOT work: I just had a long morning debugging SPL
>>> which no longer started because it picked the non-filtered dtb. The
>>> filtered one ended up in a folder outside of the u-boot sources because
>>> of all those ../ and hard-wiring to dts/upstream.
>>>
> for our spl dtb.
>
> Are there means to still build certain dtb[o] files in arch//dts?
> I'm a bit lost in the Makefile forest.
>

 Sumit: Any suggestions?

> 
> Apologies for the delayed reply. I was a bit busy with other high
> priority stuff.
> 
>>>
>>> I would really like to hear some better proposals than my local
>>> workarounds to far. They don't converge although I already patched some
>>> core Makefile (overlays are building now).
>>>
>>
>> OK, I side-stepped the spl issue by using one of our variant DTBs for
>> spl as well - happens to work.
> 
> That's good to know.
> 
>>
>> For the overlays, I need to add
>>
>> --- a/scripts/Makefile.dts
>> +++ b/scripts/Makefile.dts
>> @@ -1,5 +1,7 @@
>>  # SPDX-License-Identifier: GPL-2.0+
>>
>> +include $(srctree)/config.mk
>> +
>>  dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) 
>> $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
>>
>>  ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
>>
>>
>> in order to then be able to do
>>
>> --- a/board/siemens/iot2050/config.mk
>> +++ b/board/siemens/iot2050/config.mk
>> @@ -5,4 +5,12 @@
>>  # Authors:
>>  #   Jan Kiszka 
>>
>> +ifneq ($(CONFIG_SPL_BUILD),y)
>> +dtbo-list = \
>> +   k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \
>> +   k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay
>> +
>> +dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list))
>> +endif
>> +
>>  flash.bin: all
>>
>>
>> Does that make sense?
> 
> A switch to OF_UPSTREAM means that we build all the DT artifacts from
> dts/upstream/src/ directory with the only exception that we include
> U-Boot specific overrides via *-u-boot.dtsi from arch//dts. In
> case of overlays, is there any reason for IOT2050 board overlays not
> being pushed into Linux kernel repo? AFAIU, overlays are also
> describing puggable hardware so they shouldn't be referred to as
> "u-boot-only" overlays.

I have a related issue where I would like to build board DT from
dts/upstream, however there is also a need for a limited U-Boot specific
DT that only is intended for initial boot so that U-Boot at runtime can
determine what hw revision is booting and select correct DT to use for
U-Boot proper and OS.

For now I have just set the board target to use OF_UPSTREAM=n and
instead created minimal .dts-files in arch//dts that include the
full .dts-file from dts/upstream.

Any suggestion on how we better can support having a U-Boot only
.dts-file together with OF_UPSTREAM=y ?

Please see following for more details:
https://source.denx.de/u-boot/u-boot/-/commit/a52099b4a2ae9e8cafc79268325249bcad308012
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3566-orangepi-3b.dts
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3566-orangepi-3b-v1.1.dts
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3566-orangepi-3b-v2.1.dts

Regards,
Jonas

> 
> -Sumit
> 
>>
>> Jan
>>
>> --
>> Siemens AG, Technology
>> Linux Expert Center
>>



Re: [PATCH v3 0/7] FUSB302 USB-C controller support

2024-08-18 Thread Jonas Karlman
Hi Marek and Sebastian,

On 2024-08-18 22:35, Marek Vasut wrote:
> On 8/2/24 7:59 PM, Sebastian Reichel wrote:
>> Hi,
> 
> Hello everyone,
> 
>> On ROCK 5B power is usually supplied via it's USB-C port. This port has the
>> data lines connected to RK3588, VBUS connected to the input regulator and
>> CC pins connected to FUSB302. FUSB302 is a USB-C controller, which can be
>> accessed via I2C from RK3588. The USB-C controller is needed to figure out
>> the USB-C cable orientation, but also to do USB PD communication. Thus it
>> would be great to enable support for it in the operating system.
>>
>> But the USB-PD specification requires, that a device reacts to USB-PD 
>> messages
>> send by the power-supply within around 5 seconds. If that does not happen the
>> power-supply assumes, that the device does not support USB-PD. If a device
>> later starts sending USB-PD messages it is considered an error, which is 
>> solved
>> by doing a hard reset. A USB-PD hard reset means, that all supply voltages 
>> are
>> removed for a short period of time. For boards, which are solely powered
>> through their USB-C port, like the Radxa Rock 5B, this results in an machine
>> reset. This is currently worked around by not describing the FUSB302 in the
>> kernel DT, so nothing will ever speak USB-PD on the Rock 5B. This means
>>
>> 1. the USB-C port cannot be used at all
>> 2. the board will be running via fallback supply, which provides limited
>> power capabilities
>>
>> In order to avoid the hard reset, this adds FUSB302 support to U-Boot, so
>> that we react to the power-supply's queries in time. The code, which is
>> originally from the Linux kernel, consists of two parts:
>>
>> 1. the tcpm state machine, which implements the Type C port manager state
>> machine as described in the USB PD specification
>> 2. the fusb302 driver, which knows about specific registers
>>
>> Especially the first part has been heavily modified compared to the
>> kernel, which makes use of multiple delayed works and threads. For this
>> I used a priorly ported version from Rockchip, removed their hacks and
>> any states not necessary in U-Boot (e.g. audio accessory support).
>>
>> Sorry for the delay in getting PATCHv3 ready.
> 
> I am the one who should be sorry here, really, sorry for the abysmal 
> delay in my replies.
> 
> So ... this series looks good to me. Thank you for working on this !
> 
> Jonas, are your concerns resolved ?

No, for ROCK 5B the full overwrite of the Rockchip common misc_init_r()
in mach-rockchip/board.c should be fixed, rockchip_early_misc_init_r()
could probably be used instead (or possible a PREBOOT cmd), see [1].

Also the check for MISC_INIT_R symbol does not make sense and should be
dropped, see [2].

[1] 
https://lore.kernel.org/u-boot/34c55a9f-0e49-4439-9360-a706cf60e...@kwiboo.se/
[2] 
https://lore.kernel.org/u-boot/56322afa-1595-4228-8259-728a92531...@kwiboo.se/

Regards,
Jonas


Re: [PATCH v3 4/7] board: rock5b-rk3588: enable USB-C in operating system

2024-08-09 Thread Jonas Karlman
Hi Sebastian,

On 2024-08-03 18:09, Sebastian Reichel wrote:
> Hi Jonas,
> 
> On Fri, Aug 02, 2024 at 11:04:05PM GMT, Jonas Karlman wrote:
>> Hi Sebastian,
>>
>> On 2024-08-02 19:59, Sebastian Reichel wrote:
>>> Since older U-Boot releases do not negotiate USB PD, the kernel
>>> DT may not enable the USB-C controller by default to avoid a
>>> regression. The plan is to upstream it with 'status = "fail";'
>>> instead. U-Boot should then mark it as 'status = "okay";' if
>>> it negotiated USB PD. Currently existing upstream kernel DTs do
>>> not yet have the USB-C controller at all, so we ignore any
>>> failures.
>>
>> I do not really understand why you need to upstream it this way, there
>> are plenty of other rk3588 boards with fcs,fusb302 already having status
>> "okay" that possible are affected by same USB PD issue that ROCK 5B
>> have.
>>
>> I guess you want to try and protect users that upgrade kernel DT and
>> ignore upgrading to a newer U-Boot, use vendor U-Boot or any other
>> bootloader from having possible issues with those USB PD power supplies
>> that have issues?
> 
> Correct. Existing upstream U-Boot with new kernel would result in a
> boot loop. That's precisly why we need this U-Boot series. Since the
> Rock 5B is usually powered via USB-C and Radxa explicitly requests a
> USB-C PD power-supply almost everyone would be affected. IDK how
> other boards solve this considering U-Boot does not yet have a
> fusb302 driver. For me **all** of my power-supplies trigger a hard
> reset and thus a power-loss when booting a kernel with fusb302
> combined with an old U-Boot version not supporting fusb302.
> 
> -- Sebastian
> 
>>> Signed-off-by: Sebastian Reichel 
>>> ---
>>>  board/radxa/rock5b-rk3588/rock5b-rk3588.c | 11 +++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/board/radxa/rock5b-rk3588/rock5b-rk3588.c 
>>> b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
>>> index 1c17ae93c76c..4e926ebf2cb0 100644
>>> --- a/board/radxa/rock5b-rk3588/rock5b-rk3588.c
>>> +++ b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
>>> @@ -3,6 +3,8 @@
>>>   * Copyright (c) 2023-2024 Collabora Ltd.
>>>   */
>>>  
>>> +#include 
>>> +#include 
>>>  #include 
>>>  
>>>  #ifdef CONFIG_MISC_INIT_R
>>> @@ -33,3 +35,12 @@ int misc_init_r(void)
>>> return 0;
>>>  }
>>>  #endif
>>> +
>>> +#ifdef CONFIG_OF_BOARD_SETUP
>>> +int ft_board_setup(void *blob, struct bd_info *bd)
>>> +{
>>> +   if (IS_ENABLED(CONFIG_MISC_INIT_R))
>>
>> It make very little sense to check for this, it is implied for almost
>> all Rockchip boards since it is used in rockchip board common code
>> to setup serial and Ethernet mac addresses env vars.

As noted, please drop this check, MISC_INIT_R is implied for almost all
Rockchip targets and has nothing to do with when status should change
for fcs,fusb302.

Regards,
Jonas

>>
>> Regards,
>> Jonas
>>
>>> +   fdt_status_okay_by_compatible(blob, "fcs,fusb302");
>>> +   return 0;
>>> +}
>>> +#endif
>>



Re: [PATCH v3 3/7] board: rock5b-rk3588: add USB-C controller support

2024-08-09 Thread Jonas Karlman
Hi Sebastian,

On 2024-08-03 18:17, Sebastian Reichel wrote:
> Hi Jonas,
> 
> On Fri, Aug 02, 2024 at 10:42:56PM GMT, Jonas Karlman wrote:
>> On 2024-08-02 19:59, Sebastian Reichel wrote:
>>> Enable support for the fusb302 USB Type-C controller.
>>>
>>> This will do early USB PD (power deliver) negotiation, which must happen
>>> within 5 seconds after the USB-C connector has plugged in according to
>>> the specification. It takes almost 5 seconds to go through the bootchain
>>> on Rock 5B and jump to the operating system. When the Linux initializes
>>> the fusb302 usually 20-30 seconds have gone since the device has been
>>> plugged, which is far too late. The USB PD power source reacts with a
>>> hard reset, which disables VBUS for some time. This is not a problem for
>>> a battery driven device, but Rock 5B will loose its power-supply and
>>> reset. By initializing PD in U-Boot, this can be avoided.
>>>
>>> Signed-off-by: Sebastian Reichel 
>>> ---
>>>  board/radxa/rock5b-rk3588/Makefile|  6 
>>>  board/radxa/rock5b-rk3588/rock5b-rk3588.c | 35 +++
>>>  2 files changed, 41 insertions(+)
>>>  create mode 100644 board/radxa/rock5b-rk3588/Makefile
>>>  create mode 100644 board/radxa/rock5b-rk3588/rock5b-rk3588.c
>>>
>>> diff --git a/board/radxa/rock5b-rk3588/Makefile 
>>> b/board/radxa/rock5b-rk3588/Makefile
>>> new file mode 100644
>>> index ..95d813596da4
>>> --- /dev/null
>>> +++ b/board/radxa/rock5b-rk3588/Makefile
>>> @@ -0,0 +1,6 @@
>>> +# SPDX-License-Identifier: GPL-2.0+
>>> +#
>>> +# Copyright (c) 2022 Collabora Ltd.
>>> +#
>>> +
>>> +obj-y += rock5b-rk3588.o
>>> diff --git a/board/radxa/rock5b-rk3588/rock5b-rk3588.c 
>>> b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
>>> new file mode 100644
>>> index ..1c17ae93c76c
>>> --- /dev/null
>>> +++ b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
>>> @@ -0,0 +1,35 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (c) 2023-2024 Collabora Ltd.
>>> + */
>>> +
>>> +#include 
>>> +
>>> +#ifdef CONFIG_MISC_INIT_R
>>> +int misc_init_r(void)
>>
>> You should not override misc_init_r() here as it will override the
>> rockchip board common misc_init_r() function that read cpuid, set serial
>> and ethernet mac address env vars.

This needs to be addressed if you must add this code.

>>
>> I would suggest you instead of tcpm_get() add something similar to
>>
>> int tcpm_probe_all()
>> {
>>  struct udevice *dev;
>>  struct uclass *uc;
>>  int ret;
>>
>>  ret = uclass_get(UCLASS_TCPM, &uc);
>>  if (ret)
>>  return ret;
>>
>>  for (ret = uclass_first_device_check(UCLASS_TCPM, &dev);
>>   dev;
>>   ret = uclass_next_device_check(&dev)) {
>>  if (ret)
>>  printf("Failed to probe Type-C controller '%s' 
>> (ret=%d)\n",
>> dev->name, ret);
>>  }
>>
>>  return 0;
>> }
>>
>> or if we do not care about the error message this could use
>>
>>  uclass_probe_all(UCLASS_TCPM);
>>
>> and call it from the rockchip board common code in mach-rockchip/board.c
>> directly after the call to regulators_enable_boot_on() in board_init().
>>
>> Alternatively you could call following in a tcpm_post_bind()
>>
>>  dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
>>
>> to automatically probe the device as soon as possible after all devices
>> have been bind, this is how the rockchip-io-domain driver does it.
>>
>> Otherwise we need to add custom board code for each board using USB PD,
>> something to avoid.
> 
> All of your suggestions result in any USB-PD controllers being
> probed automatically. I intentionally did not go that way, since
> probing can be quite slow depending on the remote side. For most
> power-supplies it seems to be quite fast, but I've seen a boot
> with one of the supplies being delayed by 2-3 seconds. Seems not
> nice to add this penality for a device not depending on it.

Since you add a cmd you could possible just add a PREBOOT to run that
cmd on boot.

We should try to avoid having to add new code for each board that needs
to negotiate USB PD.

For a more elaborate solution maybe a u-boot specific prop 

Re: [PATCH 0/4] rockchip: Skip serial pinctrl at pre-reloc phase

2024-08-05 Thread Jonas Karlman
Hi Quentin,

On 2024-08-05 12:23, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 8/5/24 10:43 AM, Jonas Karlman wrote:
>> UART pinctrl for serial is typically applied multiple times:
>> - in external TPL or in TPL for DEBUG_UART in board_debug_uart_init()
>> - in SPL for DEBUG_UART in board_debug_uart_init()
>> - in SPL using pinctrl from DT
>> - in pre-reloc phase using pinctrl from DT
>> - after relocation using pinctrl from DT
>>
>> This series change bootph props for the UART pinctrl to not include them
>> in pre-reloc phase to save some boot time:
>>
> 
> NACK. I feel like this is a hack for vendor trees only.

I disagree, this just relaxes the bootph props currently enforced by
-u-boot.dtsi files. For boards that has special need they can
still add bootph-all or the bootph-some-ram prop to restore prior
behavior.

Also please do not associate me with any vendor, I am a hobbyist :-)

> 
> 1) The Device Tree represents the hardware. We need the mux at all times.

I do not think this changes the the description of the hardware in any
way. The bootph props is currently already more of a representation of
how software should behave than hardware.

In general for Rockchip use of the bootph-some-ram prop (pre-relocation
phase) does not fully make any sense, since we already have full SDRAM
in SPL.

If we where to fully follow the dtschema description for the bootph
props, for Rockchip they should probably map to something like:

TPL:
- bootph-pre-sram: Enable this node when SRAM is not available.
- bootph-pre-ram: Enable this node in the phase that sets up SDRAM.

SPL:
- bootph-some-ram: Enable this node in the phase that is run after SDRAM
   is working but before all of it is available.

U-Boot pre-reloc:
- no prop mapping, we have all SDRAM and can use all devices, ideally
  for Rockchip we should just do bare minimum to relocate without
  loading any driver and then move to main post-reloc phase.

Instead they map to the different U-Boot software stages:
- bootph-pre-sram: TPL
- bootph-pre-ram: SPL
- bootph-some-ram: U-Boot pre-reloc

> 2) This breaks users who want to have no serial in TPL/SPL but in proper 
> (where you want it as soon as possible I assume, thus pre-reloc).

Do you know of any such user/board? Adding the bootph-some-ram or
bootph-all prop can easily be done in -u-boot.dtsi for such
user/board to restore current behavior.

> 3) This likely also means if BL31 is configured to output on a different 
> UART mux of the same controller for some reason (I've seen weird stuff), 
> now U-Boot proper pre-reloc will not output anything as well.

Same as for 2), adding the bootph-some-ram or bootph-all can and should
be done at board level for boards that have special, or weird,
requirements.

It is also possible to add board specific code that call
debug_uart_init() early if you want to ensure pinmux without adding the
unnecessary delay that use of pinctrl in pre-reloc brings.

> 
> Adding Lukasz in Cc who's trying to fix U-Boot so that this is possible 
> on PX30 (therefore, not just a theoretical use case I'm bringing up ;) ).
> 
>> - Radxa ROCK Pi S (RK3308): ~80 ms
>> - Radxa ZERO 3W (RK3566): ~120 ms
>> - Radxa ROCK 5B (RK3588): ~150 ms
>>
>> Similar change has already been applied for RK3328 and RK3399 boards.
>>
> 
> Then I believe this was a mistake.

My wording may have been misleading, when we added broad use of pinctrl props
to SPL for rk3328/rk3399 we limited so that the uart pinctrl group was only
enabled for TPL/SPL and not pre-reloc phase, because also including it at
pre-reloc added 200-300 ms in extra boot time.

This series tries to apply same findings on remaining Rockchip aarch64
boards.

> 
>> The change for PX30 has not been runtime tested, and only include change
>> for uart2, not uart0 and uart5 used on two of the supported px30 boards.
>>
> 
> This means we have uart2 pinctrl at all stages even though we make no 
> use of it?

Yes, in my opinion the px30-u-boot.dtsi include lots of nodes that seem
very board specific, some that probably should move to board specific
u-boot.dtsi files.

> 
> I'm starting to wonder if this optimization isn't orthogonal to having 
> as much support as possible via an -u-boot.dtsi which was done to 
> make bring-up and maintenance easier. If you're really after 
> optimization AND we keep the pinctrl for the debug uart (thus, not 
> breaking 2) above), then what we want is cleaning up the default 
> px30-u-boot.dtsi and move bootph properties to the board DTS instead?

Agree, for other aarch64 socs I have already tried to cleanup
-u-boot.dtsi to only contain what more than 70-80% of all supported
boards may need. For rk3399 bob and kevin even use /delete-property/ to
remove some of the common boothp pro

Re: [PATCH] serial: ns16550: Try get serial clock rate from DT before CLK

2024-08-05 Thread Jonas Karlman
Hi Quentin,

On 2024-08-05 09:19, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 8/4/24 5:09 PM, Jonas Karlman wrote:
>> Initializing a clock driver to read a known static clock rate can take
>> some time at U-Boot proper pre-reloc phase.
>>
>> Change to first try and read clock rate from DT to speed up boot time,
>> fall back to getting the clock rate from clock driver.
>>
>> This help reduce boot time by around:
>> - ~35ms on a Radxa ROCK Pi 4 (RK3399)
>> - ~15ms on a Radxa ZERO 3W (RK3566)
>> Time that is wasted getting a static rate known at compile time.
>>
> 
> I guess this also makes some board perform worse as well, the ones 
> without a clock-frequency set?

I do not expect that this change will add anything to existing boot
time, however in some circumstances it may reduce the boot time.

Before this change the rate was retrieved using first successful of:

1. clk_get_rate()
2. clock-frequency prop from DT
3. CFG_SYS_NS16550_CLK

This patch swap 1. and 2. so driver first will try to use any rate that
may have been defined in DT, thus possible skip a probe of the clock.

Boot time is only saved/reduced if the serial driver was the only device
that needed something from clock device in current phase.

As long as the DT contain correct rate in clock-frequency prop or no
such prop this patch is not expected to change anything.

Regards,
Jonas

> 
> The change seems sound to me, therefore
> Reviewed-by: Quentin Schulz 
> 
> Thanks!
> Quentin



[PATCH 3/4] rockchip: rk3588: Skip serial pinctrl at pre-reloc phase

2024-08-05 Thread Jonas Karlman
UART pinctrl for serial is typically applied multiple times:
- in external TPL
- in SPL for DEBUG_UART in board_debug_uart_init()
- in SPL using pinctrl from DT
- in pre-reloc phase using pinctrl from DT
- after relocation using pinctrl from DT

Skip including UART pinctrl for the pre-reloc phase to save time during
boot. On a Radxa ROCK 5B this reduce boot time by ~150 ms.

After this a warning may be shown with LOGLEVEL=5 (or higher), it is
safe to ignore this warning as device probe is successful even when
pinctrl cannot be applied:

  ns16550_serial serial@feb5: pinctrl_select_state_full: 
uclass_get_device_by_phandle_id: err=-19

Signed-off-by: Jonas Karlman 
---
 arch/arm/dts/rk3588-tiger-haikou-u-boot.dtsi | 3 ++-
 arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi   | 3 ++-
 arch/arm/dts/rk3588s-u-boot.dtsi | 3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/rk3588-tiger-haikou-u-boot.dtsi 
b/arch/arm/dts/rk3588-tiger-haikou-u-boot.dtsi
index 275ae6fdaead..08ebb0af4482 100644
--- a/arch/arm/dts/rk3588-tiger-haikou-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-tiger-haikou-u-boot.dtsi
@@ -33,5 +33,6 @@
 };
 
 &uart2m2_xfer {
-   bootph-all;
+   bootph-pre-sram;
+   bootph-pre-ram;
 };
diff --git a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi 
b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi
index a50bcc45f216..59886b9828a4 100644
--- a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi
@@ -17,5 +17,6 @@
 };
 
 &uart9m0_xfer {
-   bootph-all;
+   bootph-pre-sram;
+   bootph-pre-ram;
 };
diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
index 09d8b311cec5..df7e93d19c52 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -154,7 +154,8 @@
 };
 
 &uart2m0_xfer {
-   bootph-all;
+   bootph-pre-sram;
+   bootph-pre-ram;
 };
 
 &xin24m {
-- 
2.45.2



[PATCH 4/4] rockchip: px30: Skip serial pinctrl at pre-reloc phase

2024-08-05 Thread Jonas Karlman
UART pinctrl for serial is typically applied multiple times:
- in TPL for DEBUG_UART in board_debug_uart_init()
- in SPL for DEBUG_UART in board_debug_uart_init()
- in SPL using pinctrl from DT
- in pre-reloc phase using pinctrl from DT
- after relocation using pinctrl from DT

Skip including UART pinctrl for the pre-reloc phase to save time during
boot.

After this a warning may be shown with LOGLEVEL=5 (or higher), it is
safe to ignore this warning as device probe is successful even when
pinctrl cannot be applied:

  ns16550_serial serial@ff16: pinctrl_select_state_full: 
uclass_get_device_by_phandle_id: err=-19

Signed-off-by: Jonas Karlman 
---
 arch/arm/dts/px30-u-boot.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/px30-u-boot.dtsi b/arch/arm/dts/px30-u-boot.dtsi
index 3dc70d4e432b..2a0e85d92a2a 100644
--- a/arch/arm/dts/px30-u-boot.dtsi
+++ b/arch/arm/dts/px30-u-boot.dtsi
@@ -38,7 +38,8 @@
 };
 
 &uart2m0_xfer {
-   bootph-all;
+   bootph-pre-sram;
+   bootph-pre-ram;
 };
 
 &uart5 {
-- 
2.45.2



[PATCH 1/4] rockchip: rk3308: Skip serial pinctrl at pre-reloc phase

2024-08-05 Thread Jonas Karlman
UART pinctrl for serial is typically applied multiple times:
- in external TPL
- in SPL using pinctrl from DT
- in pre-reloc phase using pinctrl from DT
- after relocation using pinctrl from DT

Skip including UART pinctrl for the pre-reloc phase to save time during
boot. On a Radxa ROCK Pi S this reduce boot time by ~80 ms.

After this a warning may be shown with LOGLEVEL=5 (or higher), it is
safe to ignore this warning as device probe is successful even when
pinctrl cannot be applied:

  ns16550_serial serial@ff0a: pinctrl_select_state_full: 
uclass_get_device_by_phandle_id: err=-19

Signed-off-by: Jonas Karlman 
---
 arch/arm/dts/rk3308-evb-u-boot.dtsi   | 3 ++-
 arch/arm/dts/rk3308-roc-cc-u-boot.dtsi| 3 ++-
 arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi | 3 ++-
 arch/arm/dts/rk3308-rock-s0-u-boot.dtsi   | 3 ++-
 4 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/rk3308-evb-u-boot.dtsi 
b/arch/arm/dts/rk3308-evb-u-boot.dtsi
index 007a69f9a60e..ce826667dcc2 100644
--- a/arch/arm/dts/rk3308-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-evb-u-boot.dtsi
@@ -10,5 +10,6 @@
 };
 
 &uart4_xfer {
-   bootph-all;
+   bootph-pre-sram;
+   bootph-pre-ram;
 };
diff --git a/arch/arm/dts/rk3308-roc-cc-u-boot.dtsi 
b/arch/arm/dts/rk3308-roc-cc-u-boot.dtsi
index 3e01e7af6113..72b6f223838b 100644
--- a/arch/arm/dts/rk3308-roc-cc-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-roc-cc-u-boot.dtsi
@@ -29,7 +29,8 @@
 };
 
 &uart2m0_xfer {
-   bootph-all;
+   bootph-pre-sram;
+   bootph-pre-ram;
 };
 
 &vcc_sd {
diff --git a/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi 
b/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
index ff5bab316a34..3059a0246086 100644
--- a/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
@@ -14,7 +14,8 @@
 };
 
 &uart0_xfer {
-   bootph-all;
+   bootph-pre-sram;
+   bootph-pre-ram;
 };
 
 &vcc5v0_otg {
diff --git a/arch/arm/dts/rk3308-rock-s0-u-boot.dtsi 
b/arch/arm/dts/rk3308-rock-s0-u-boot.dtsi
index 84ca2ee0d5fb..dd4cb8660b8d 100644
--- a/arch/arm/dts/rk3308-rock-s0-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-rock-s0-u-boot.dtsi
@@ -13,7 +13,8 @@
 };
 
 &uart0_xfer {
-   bootph-all;
+   bootph-pre-sram;
+   bootph-pre-ram;
 };
 
 &vdd_core {
-- 
2.45.2



[PATCH 2/4] rockchip: rk356x: Skip serial pinctrl at pre-reloc phase

2024-08-05 Thread Jonas Karlman
UART pinctrl for serial is typically applied multiple times:
- in external TPL
- in SPL for DEBUG_UART in board_debug_uart_init()
- in SPL using pinctrl from DT
- in pre-reloc phase using pinctrl from DT
- after relocation using pinctrl from DT

Skip including UART pinctrl for the pre-reloc phase to save time during
boot. On a Radxa ZERO 3W this reduce boot time by ~120 ms.

After this a warning may be shown with LOGLEVEL=5 (or higher), it is
safe to ignore this warning as device probe is successful even when
pinctrl cannot be applied:

  ns16550_serial serial@fe66: pinctrl_select_state_full: 
uclass_get_device_by_phandle_id: err=-19

Signed-off-by: Jonas Karlman 
---
 arch/arm/dts/rk356x-u-boot.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/rk356x-u-boot.dtsi b/arch/arm/dts/rk356x-u-boot.dtsi
index 0a0943b462a9..9e03d2d8eb97 100644
--- a/arch/arm/dts/rk356x-u-boot.dtsi
+++ b/arch/arm/dts/rk356x-u-boot.dtsi
@@ -163,7 +163,8 @@
 };
 
 &uart2m0_xfer {
-   bootph-all;
+   bootph-pre-sram;
+   bootph-pre-ram;
 };
 
 &xin24m {
-- 
2.45.2



[PATCH 0/4] rockchip: Skip serial pinctrl at pre-reloc phase

2024-08-05 Thread Jonas Karlman
UART pinctrl for serial is typically applied multiple times:
- in external TPL or in TPL for DEBUG_UART in board_debug_uart_init()
- in SPL for DEBUG_UART in board_debug_uart_init()
- in SPL using pinctrl from DT
- in pre-reloc phase using pinctrl from DT
- after relocation using pinctrl from DT

This series change bootph props for the UART pinctrl to not include them
in pre-reloc phase to save some boot time:

- Radxa ROCK Pi S (RK3308): ~80 ms
- Radxa ZERO 3W (RK3566): ~120 ms
- Radxa ROCK 5B (RK3588): ~150 ms

Similar change has already been applied for RK3328 and RK3399 boards.

The change for PX30 has not been runtime tested, and only include change
for uart2, not uart0 and uart5 used on two of the supported px30 boards.

Jonas Karlman (4):
  rockchip: rk3308: Skip serial pinctrl at pre-reloc phase
  rockchip: rk356x: Skip serial pinctrl at pre-reloc phase
  rockchip: rk3588: Skip serial pinctrl at pre-reloc phase
  rockchip: px30: Skip serial pinctrl at pre-reloc phase

 arch/arm/dts/px30-u-boot.dtsi| 3 ++-
 arch/arm/dts/rk3308-evb-u-boot.dtsi  | 3 ++-
 arch/arm/dts/rk3308-roc-cc-u-boot.dtsi   | 3 ++-
 arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi| 3 ++-
 arch/arm/dts/rk3308-rock-s0-u-boot.dtsi  | 3 ++-
 arch/arm/dts/rk356x-u-boot.dtsi  | 3 ++-
 arch/arm/dts/rk3588-tiger-haikou-u-boot.dtsi | 3 ++-
 arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi   | 3 ++-
 arch/arm/dts/rk3588s-u-boot.dtsi | 3 ++-
 9 files changed, 18 insertions(+), 9 deletions(-)

-- 
2.45.2



[PATCH] serial: ns16550: Try get serial clock rate from DT before CLK

2024-08-04 Thread Jonas Karlman
Initializing a clock driver to read a known static clock rate can take
some time at U-Boot proper pre-reloc phase.

Change to first try and read clock rate from DT to speed up boot time,
fall back to getting the clock rate from clock driver.

This help reduce boot time by around:
- ~35ms on a Radxa ROCK Pi 4 (RK3399)
- ~15ms on a Radxa ZERO 3W (RK3566)
Time that is wasted getting a static rate known at compile time.

Signed-off-by: Jonas Karlman 
---
 drivers/serial/ns16550.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 6fcb5b523acb..07f9ac00e113 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -565,19 +565,19 @@ int ns16550_serial_of_to_plat(struct udevice *dev)
plat->reg_shift = dev_read_u32_default(dev, "reg-shift", 0);
plat->reg_width = dev_read_u32_default(dev, "reg-io-width", 1);
 
-   err = clk_get_by_index(dev, 0, &clk);
-   if (!err) {
-   err = clk_get_rate(&clk);
-   if (!IS_ERR_VALUE(err))
-   plat->clock = err;
-   } else if (err != -ENOENT && err != -ENODEV && err != -ENOSYS) {
-   debug("ns16550 failed to get clock\n");
-   return err;
-   }
-
if (!plat->clock)
-   plat->clock = dev_read_u32_default(dev, "clock-frequency",
-  CFG_SYS_NS16550_CLK);
+   plat->clock = dev_read_u32_default(dev, "clock-frequency", 0);
+   if (!plat->clock) {
+   err = clk_get_by_index(dev, 0, &clk);
+   if (!err) {
+   err = clk_get_rate(&clk);
+   if (!IS_ERR_VALUE(err))
+   plat->clock = err;
+   } else if (err != -ENOENT && err != -ENODEV && err != -ENOSYS) {
+   debug("ns16550 failed to get clock\n");
+   return err;
+   }
+   }
if (!plat->clock)
plat->clock = CFG_SYS_NS16550_CLK;
if (!plat->clock) {
-- 
2.45.2



[PATCH 3/3] dm: core: regmap: Avoid multiple calls to ofnode_get_parent()

2024-08-04 Thread Jonas Karlman
Until a live tree is used in U-Boot proper after relocation, use of
ofnode_get_parent() will trigger a call to the very expensive
fdt_parent_offset(), as detailed by the function documentation:

  NOTE: This function is expensive, as it must scan the device tree
  structure from the start to nodeoffset, *twice*.

Re-use the returned value from a single call instead of having to make
multiple calls for same node.

Signed-off-by: Jonas Karlman 
---
 drivers/core/regmap.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index 304d5b02bcd5..5cb5fa27343a 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -168,18 +168,21 @@ static int init_range(ofnode node, struct regmap_range 
*range, int addr_len,
 
 int regmap_init_mem_index(ofnode node, struct regmap **mapp, int index)
 {
+   ofnode parent;
struct regmap *map;
int addr_len, size_len;
int ret;
 
-   addr_len = ofnode_read_simple_addr_cells(ofnode_get_parent(node));
+   parent = ofnode_get_parent(node);
+
+   addr_len = ofnode_read_simple_addr_cells(parent);
if (addr_len < 0) {
dm_warn("%s: Error while reading the addr length (ret = %d)\n",
ofnode_get_name(node), addr_len);
return addr_len;
}
 
-   size_len = ofnode_read_simple_size_cells(ofnode_get_parent(node));
+   size_len = ofnode_read_simple_size_cells(parent);
if (size_len < 0) {
dm_warn("%s: Error while reading the size length: (ret = %d)\n",
ofnode_get_name(node), size_len);
@@ -241,6 +244,7 @@ int regmap_init_mem_range(ofnode node, ulong r_start, ulong 
r_size,
 
 int regmap_init_mem(ofnode node, struct regmap **mapp)
 {
+   ofnode parent;
struct regmap_range *range;
struct regmap *map;
int count;
@@ -249,14 +253,16 @@ int regmap_init_mem(ofnode node, struct regmap **mapp)
int index;
int ret;
 
-   addr_len = ofnode_read_simple_addr_cells(ofnode_get_parent(node));
+   parent = ofnode_get_parent(node);
+
+   addr_len = ofnode_read_simple_addr_cells(parent);
if (addr_len < 0) {
dm_warn("%s: Error while reading the addr length (ret = %d)\n",
ofnode_get_name(node), addr_len);
return addr_len;
}
 
-   size_len = ofnode_read_simple_size_cells(ofnode_get_parent(node));
+   size_len = ofnode_read_simple_size_cells(parent);
if (size_len < 0) {
dm_warn("%s: Error while reading the size length: (ret = %d)\n",
ofnode_get_name(node), size_len);
-- 
2.45.2



[PATCH 1/3] dm: core: fdtaddr: Avoid multiple calls to fdt_parent_offset()

2024-08-04 Thread Jonas Karlman
Use of fdt_parent_offset() is very expensive as detailed by the function
documentation:

  NOTE: This function is expensive, as it must scan the device tree
  structure from the start to nodeoffset, *twice*.

Re-use the returned value from a single call instead of having to make
multiple calls for same nodeoffset.

Signed-off-by: Jonas Karlman 
---
 drivers/core/fdtaddr.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
index 9e59968df016..2aa58b006f1a 100644
--- a/drivers/core/fdtaddr.c
+++ b/drivers/core/fdtaddr.c
@@ -19,11 +19,10 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-fdt_addr_t devfdt_get_addr_index(const struct udevice *dev, int index)
+#if CONFIG_IS_ENABLED(OF_REAL) || CONFIG_IS_ENABLED(OF_CONTROL)
+fdt_addr_t devfdt_get_addr_index_parent(const struct udevice *dev, int index,
+   int offset, int parent)
 {
-#if CONFIG_IS_ENABLED(OF_REAL)
-   int offset = dev_of_offset(dev);
-   int parent = fdt_parent_offset(gd->fdt_blob, offset);
fdt_addr_t addr;
 
if (CONFIG_IS_ENABLED(OF_TRANSLATE)) {
@@ -89,6 +88,15 @@ fdt_addr_t devfdt_get_addr_index(const struct udevice *dev, 
int index)
 #endif
 
return addr;
+}
+#endif
+
+fdt_addr_t devfdt_get_addr_index(const struct udevice *dev, int index)
+{
+#if CONFIG_IS_ENABLED(OF_REAL)
+   int offset = dev_of_offset(dev);
+   int parent = fdt_parent_offset(gd->fdt_blob, offset);
+   return devfdt_get_addr_index_parent(dev, index, offset, parent);
 #else
return FDT_ADDR_T_NONE;
 #endif
@@ -113,14 +121,16 @@ fdt_addr_t devfdt_get_addr_size_index(const struct 
udevice *dev, int index,
 * next call to the exisiting dev_get_xxx function which handles
 * all config options.
 */
-   fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, dev_of_offset(dev),
-  "reg", index, size, false);
+   int offset = dev_of_offset(dev);
+   int parent = fdt_parent_offset(gd->fdt_blob, offset);
+   fdtdec_get_addr_size_auto_parent(gd->fdt_blob, parent, offset,
+"reg", index, size, false);
 
/*
 * Get the base address via the existing function which handles
 * all Kconfig cases
 */
-   return devfdt_get_addr_index(dev, index);
+   return devfdt_get_addr_index_parent(dev, index, offset, parent);
 #else
return FDT_ADDR_T_NONE;
 #endif
-- 
2.45.2



[PATCH 2/3] dm: core: ofnode: Avoid multiple calls to ofnode_get_parent()

2024-08-04 Thread Jonas Karlman
Until a live tree is used in U-Boot proper after relocation, use of
ofnode_get_parent() will trigger a call to the very expensive
fdt_parent_offset() as detailed by the function documentation:

  NOTE: This function is expensive, as it must scan the device tree
  structure from the start to nodeoffset, *twice*.

Re-use the returned value from a single call instead of having to make
multiple calls for same node.

Signed-off-by: Jonas Karlman 
---
 drivers/core/ofnode.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 4d563b47a5a3..7e3b3719d18f 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -762,8 +762,9 @@ static fdt_addr_t __ofnode_get_addr_size_index(ofnode node, 
int index,
return of_read_number(prop_val, na);
}
} else {
-   na = ofnode_read_simple_addr_cells(ofnode_get_parent(node));
-   ns = ofnode_read_simple_size_cells(ofnode_get_parent(node));
+   ofnode parent = ofnode_get_parent(node);
+   na = ofnode_read_simple_addr_cells(parent);
+   ns = ofnode_read_simple_size_cells(parent);
return fdtdec_get_addr_size_fixed(ofnode_to_fdt(node),
  ofnode_to_offset(node), "reg",
  index, na, ns, size,
-- 
2.45.2



[PATCH 0/3] dm: core: Avoid multiple calls to fdt_parent_offset()

2024-08-04 Thread Jonas Karlman
Use of fdt_parent_offset() is very expensive as detailed by the function
documentation:

  NOTE: This function is expensive, as it must scan the device tree
  structure from the start to nodeoffset, *twice*.

This series remove multiple calls to fdt_parent_offset() or
ofnode_get_parent() when instead a single call can be made and the
returned value can be reused.

This series help reduce boot time by around:
- ~137ms on a Radxa ROCK Pi 4 (RK3399)
- ~33ms on a Radxa ZERO 3W (RK3566)

Jonas Karlman (3):
  dm: core: fdtaddr: Avoid multiple calls to fdt_parent_offset()
  dm: core: ofnode: Avoid multiple calls to ofnode_get_parent()
  dm: core: regmap: Avoid multiple calls to ofnode_get_parent()

 drivers/core/fdtaddr.c | 24 +---
 drivers/core/ofnode.c  |  5 +++--
 drivers/core/regmap.c  | 14 ++
 3 files changed, 30 insertions(+), 13 deletions(-)

-- 
2.45.2



[PATCH 2/2] bootstage: Do not sort records

2024-08-03 Thread Jonas Karlman
The timer counter on Rockchip SoCs may be reset in TF-A, this may cause
the bootstage records to be printed out of order and with an incorrect
elapsed time.

Fix this by not sorting the bootstage records.

Before on a Radxa ZERO 3W (RK3566) board:

  => bootstage report
  Timer summary in microseconds (12 records):
 MarkElapsed  Stage
0  0  reset
7,436  7,436  board_init_f
  164,826157,390  SPL
  375,392210,566  end phase
  423,909 48,517  board_init_r
  472,973 49,064  eth_common_init
  476,848  3,875  main_loop
  477,003155  cli_loop

  Accumulated time:
   7,181  of_live
  14,739  dm_spl
  15,029  dm_r
 315,150  dm_f

With this the records can be printed in chronological order when the
counter is reset and SPL and board_init_r records show correct elapsed
time.

  => bootstage report
  Timer summary in microseconds (12 records):
 MarkElapsed  Stage
0  0  reset
  164,437164,437  SPL
  375,023210,586  end phase
7,437  7,437  board_init_f
  424,390416,953  board_init_r
  473,515 49,125  eth_common_init
  477,402  3,887  main_loop
  477,571169  cli_loop

  Accumulated time:
  14,734  dm_spl
 315,646  dm_f
   7,339  of_live
  14,977  dm_r

For the tested board external TPL and BROM take ~164 ms to initialize
DRAM and load SPL, SPL take ~210ms to load images from FIT and U-Boot
proper take ~477ms to reach cli prompt.

Signed-off-by: Jonas Karlman 
---
 common/bootstage.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/common/bootstage.c b/common/bootstage.c
index 49acc9078a6d..80168e965b12 100644
--- a/common/bootstage.c
+++ b/common/bootstage.c
@@ -249,6 +249,8 @@ static uint32_t print_time_record(struct bootstage_record 
*rec, uint32_t prev)
printf("%11s", "");
print_grouped_ull(rec->time_us, BOOTSTAGE_DIGITS);
} else {
+   if (prev > rec->time_us)
+   prev = 0;
print_grouped_ull(rec->time_us, BOOTSTAGE_DIGITS);
print_grouped_ull(rec->time_us - prev, BOOTSTAGE_DIGITS);
}
@@ -257,13 +259,6 @@ static uint32_t print_time_record(struct bootstage_record 
*rec, uint32_t prev)
return rec->time_us;
 }
 
-static int h_compare_record(const void *r1, const void *r2)
-{
-   const struct bootstage_record *rec1 = r1, *rec2 = r2;
-
-   return rec1->time_us > rec2->time_us ? 1 : -1;
-}
-
 #ifdef CONFIG_OF_LIBFDT
 /**
  * Add all bootstage timings to a device tree.
@@ -342,9 +337,6 @@ void bootstage_report(void)
 
prev = print_time_record(rec, 0);
 
-   /* Sort records by increasing time */
-   qsort(data->record, data->rec_count, sizeof(*rec), h_compare_record);
-
for (i = 1, rec++; i < data->rec_count; i++, rec++) {
if (rec->id && !rec->start_us)
prev = print_time_record(rec, prev);
-- 
2.45.2



[PATCH 1/2] bootstage: Fix unstash of records from SPL

2024-08-03 Thread Jonas Karlman
The commit b81e31a1e6c5 ("bootstash: Do not provide a default address
for all") changed a bootstage unstash call to bootstage stash, this
has resulted in bootstage records stashed in SPL no longer get unstaged
in U-Boot proper. Fix this by changing back to a unstage call.

Fixes: b81e31a1e6c5 ("bootstash: Do not provide a default address for all")
Signed-off-by: Jonas Karlman 
---
 common/board_f.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/board_f.c b/common/board_f.c
index 21a8944e2b0f..0b017ee12a7c 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -804,7 +804,7 @@ static int initf_bootstage(void)
if (ret)
return ret;
if (from_spl) {
-   ret = bootstage_stash_default();
+   ret = bootstage_unstash_default();
if (ret && ret != -ENOENT) {
debug("Failed to unstash bootstage: err=%d\n", ret);
return ret;
-- 
2.45.2



[PATCH 0/2] bootstage: Fix unstash and sorting of records

2024-08-03 Thread Jonas Karlman
This series fixes two issues with bootstage observed trying to measure
boot times on my Rockchip aarch64 boards.

First patch fixes a regression in v2024.10-rc1 where bootstage records
from SPL no longer is unstashed.

Second patch change to not sort bootstage records in order to show
correct elapsed time when TF-A reset the timer counter.

Tested on a few Rockchip boards with:

  CONFIG_BOOTSTAGE=y
  CONFIG_CMD_BOOTSTAGE=y
  CONFIG_BOOTSTAGE_RECORD_COUNT=20
  CONFIG_SPL_BOOTSTAGE=y
  CONFIG_SPL_BOOTSTAGE_RECORD_COUNT=20
  CONFIG_BOOTSTAGE_STASH_ADDR=0x380
  CONFIG_BOOTSTAGE_STASH_SIZE=0x1
  CONFIG_BOOTSTAGE_STASH=y
  CONFIG_BOOTSTAGE_REPORT=y
  CONFIG_BOOTDELAY=-1

Jonas Karlman (2):
  bootstage: Fix unstash of records from SPL
  bootstage: Do not sort records

 common/board_f.c   |  2 +-
 common/bootstage.c | 12 ++--
 2 files changed, 3 insertions(+), 11 deletions(-)

-- 
2.45.2



[PATCH] rockchip: rk3568-nanopi-r5: Disable SPL_DM_WARN Kconfig option

2024-08-02 Thread Jonas Karlman
With the commit 6afdb1585112 ("dm: core: migrate debug() messages to use
dm_warn") use of DM_WARN/SPL_DM_WARN print a lot of debug messages.

Disable the SPL_DM_WARN Kconfig option to remove verbose logging and
restore normal serial console output during boot.

Signed-off-by: Jonas Karlman 
---
 configs/nanopi-r5c-rk3568_defconfig | 1 -
 configs/nanopi-r5s-rk3568_defconfig | 1 -
 2 files changed, 2 deletions(-)

diff --git a/configs/nanopi-r5c-rk3568_defconfig 
b/configs/nanopi-r5c-rk3568_defconfig
index 4a6c320faf5c..8e30093ed9dc 100644
--- a/configs/nanopi-r5c-rk3568_defconfig
+++ b/configs/nanopi-r5c-rk3568_defconfig
@@ -35,7 +35,6 @@ CONFIG_CMD_REGULATOR=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIVE=y
 CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
-CONFIG_SPL_DM_WARN=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SPL_SYSCON=y
diff --git a/configs/nanopi-r5s-rk3568_defconfig 
b/configs/nanopi-r5s-rk3568_defconfig
index 7ab12e619acf..e1865b2e1714 100644
--- a/configs/nanopi-r5s-rk3568_defconfig
+++ b/configs/nanopi-r5s-rk3568_defconfig
@@ -35,7 +35,6 @@ CONFIG_CMD_REGULATOR=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIVE=y
 CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
-CONFIG_SPL_DM_WARN=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SPL_SYSCON=y
-- 
2.45.2



[PATCH v2 10/10] rockchip: gpio: Add missing gpio aliases

2024-08-02 Thread Jonas Karlman
Add aliases for gpio controllers to soc u-boot dtsi files that are
missing aliases in soc dtsi files to ensure dev_seq() return the
expected number when a gpio controller is included in SPL.

Also drop the aliases from rk3288-u-boot.dtsi, they are already part of
rk3288.dtsi.

Signed-off-by: Jonas Karlman 
---
v2: New patch
---
 arch/arm/dts/px30-u-boot.dtsi| 4 
 arch/arm/dts/rk3066a-u-boot.dtsi | 7 +++
 arch/arm/dts/rk3288-u-boot.dtsi  | 9 -
 arch/arm/dts/rk3xxx-u-boot.dtsi  | 7 +++
 arch/arm/dts/rv1108-u-boot.dtsi  | 9 +
 arch/arm/dts/rv1126-u-boot.dtsi  | 8 
 6 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/px30-u-boot.dtsi b/arch/arm/dts/px30-u-boot.dtsi
index abc6b49e6663..3dc70d4e432b 100644
--- a/arch/arm/dts/px30-u-boot.dtsi
+++ b/arch/arm/dts/px30-u-boot.dtsi
@@ -7,6 +7,10 @@
 
 / {
aliases {
+   gpio0 = &gpio0;
+   gpio1 = &gpio1;
+   gpio2 = &gpio2;
+   gpio3 = &gpio3;
mmc0 = &emmc;
mmc1 = &sdmmc;
};
diff --git a/arch/arm/dts/rk3066a-u-boot.dtsi b/arch/arm/dts/rk3066a-u-boot.dtsi
index 35b52d6fb7f3..60d18d2daeac 100644
--- a/arch/arm/dts/rk3066a-u-boot.dtsi
+++ b/arch/arm/dts/rk3066a-u-boot.dtsi
@@ -3,6 +3,13 @@
 #include "rockchip-u-boot.dtsi"
 #include "rk3xxx-u-boot.dtsi"
 
+/ {
+   aliases {
+   gpio4 = &gpio4;
+   gpio6 = &gpio6;
+   };
+};
+
 &gpio0 {
gpio-ranges = <&pinctrl 0 0 32>;
 };
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 0f8053a8b690..379d9413adee 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -7,15 +7,6 @@
 
 / {
aliases {
-   gpio0 = &gpio0;
-   gpio1 = &gpio1;
-   gpio2 = &gpio2;
-   gpio3 = &gpio3;
-   gpio4 = &gpio4;
-   gpio5 = &gpio5;
-   gpio6 = &gpio6;
-   gpio7 = &gpio7;
-   gpio8 = &gpio8;
mmc0 = &emmc;
mmc1 = &sdmmc;
mmc2 = &sdio0;
diff --git a/arch/arm/dts/rk3xxx-u-boot.dtsi b/arch/arm/dts/rk3xxx-u-boot.dtsi
index 6af6a451ea78..097407ca72dc 100644
--- a/arch/arm/dts/rk3xxx-u-boot.dtsi
+++ b/arch/arm/dts/rk3xxx-u-boot.dtsi
@@ -1,6 +1,13 @@
 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 
 / {
+   aliases {
+   gpio0 = &gpio0;
+   gpio1 = &gpio1;
+   gpio2 = &gpio2;
+   gpio3 = &gpio3;
+   };
+
noc: syscon@10128000 {
compatible = "rockchip,rk3188-noc", "syscon";
reg = <0x10128000 0x2000>;
diff --git a/arch/arm/dts/rv1108-u-boot.dtsi b/arch/arm/dts/rv1108-u-boot.dtsi
index f772d618bd1d..58711e8b2f8a 100644
--- a/arch/arm/dts/rv1108-u-boot.dtsi
+++ b/arch/arm/dts/rv1108-u-boot.dtsi
@@ -5,6 +5,15 @@
 
 #include "rockchip-u-boot.dtsi"
 
+/ {
+   aliases {
+   gpio0 = &gpio0;
+   gpio1 = &gpio1;
+   gpio2 = &gpio2;
+   gpio3 = &gpio3;
+   };
+};
+
 &gpio0 {
gpio-ranges = <&pinctrl 0 0 32>;
 };
diff --git a/arch/arm/dts/rv1126-u-boot.dtsi b/arch/arm/dts/rv1126-u-boot.dtsi
index 3e6df1e433db..05b5f5260dd5 100644
--- a/arch/arm/dts/rv1126-u-boot.dtsi
+++ b/arch/arm/dts/rv1126-u-boot.dtsi
@@ -6,6 +6,14 @@
 #include "rockchip-u-boot.dtsi"
 
 / {
+   aliases {
+   gpio0 = &gpio0;
+   gpio1 = &gpio1;
+   gpio2 = &gpio2;
+   gpio3 = &gpio3;
+   gpio4 = &gpio4;
+   };
+
chosen {
u-boot,spl-boot-order = \
"same-as-spl", &emmc, &sdmmc;
-- 
2.45.2



[PATCH v2 09/10] rockchip: gpio: Add gpio-ranges props

2024-08-02 Thread Jonas Karlman
Add gpio-ranges props to supported SoCs based on the following Linux
patches:

ARM: dts: rockchip: add gpio-ranges property to gpio nodes
https://lore.kernel.org/all/26007385-81dc-9961-05d5-8b9a0969d...@gmail.com/

arm64: dts: rockchip: add gpio-ranges property to gpio nodes
https://lore.kernel.org/all/18c8c89a-9962-40f0-814f-81e2c420c...@gmail.com/

For RK3066 and RK3288 the gpio-ranges props is adjusted to match
https://lore.kernel.org/all/541b7633-af3b-4392-ac29-7ee1f2c6f...@kwiboo.se/

Re-enable gpio6 on RK3066 now that the pinctrl pin offset is used with
get_gpio_mux().

Signed-off-by: Jonas Karlman 
Reviewed-by: Kever Yang 
---
v2: Collect r-b tag

Cc: Johan Jonker 
---
 arch/arm/dts/rk3036-u-boot.dtsi  | 12 
 arch/arm/dts/rk3066a-u-boot.dtsi |  3 +--
 arch/arm/dts/rk3128-u-boot.dtsi  | 16 
 arch/arm/dts/rk322x-u-boot.dtsi  | 16 
 arch/arm/dts/rk3288-u-boot.dtsi  | 33 
 arch/arm/dts/rk3308-u-boot.dtsi  | 20 +++
 arch/arm/dts/rk3328-u-boot.dtsi  | 13 +
 arch/arm/dts/rk3368-u-boot.dtsi  | 16 
 arch/arm/dts/rk3399-u-boot.dtsi  | 20 +++
 arch/arm/dts/rv1108-u-boot.dtsi  | 16 
 arch/arm/dts/rv1126-u-boot.dtsi  | 14 ++
 11 files changed, 177 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rk3036-u-boot.dtsi b/arch/arm/dts/rk3036-u-boot.dtsi
index 41ac054b81e8..3e788187f630 100644
--- a/arch/arm/dts/rk3036-u-boot.dtsi
+++ b/arch/arm/dts/rk3036-u-boot.dtsi
@@ -4,3 +4,15 @@
  */
 
 #include "rockchip-u-boot.dtsi"
+
+&gpio0 {
+   gpio-ranges = <&pinctrl 0 0 32>;
+};
+
+&gpio1 {
+   gpio-ranges = <&pinctrl 0 32 32>;
+};
+
+&gpio2 {
+   gpio-ranges = <&pinctrl 0 64 32>;
+};
diff --git a/arch/arm/dts/rk3066a-u-boot.dtsi b/arch/arm/dts/rk3066a-u-boot.dtsi
index 06f405ca2c5e..35b52d6fb7f3 100644
--- a/arch/arm/dts/rk3066a-u-boot.dtsi
+++ b/arch/arm/dts/rk3066a-u-boot.dtsi
@@ -24,6 +24,5 @@
 };
 
 &gpio6 {
-   status = "disabled";
+   gpio-ranges = <&pinctrl 0 160 16>;
 };
-
diff --git a/arch/arm/dts/rk3128-u-boot.dtsi b/arch/arm/dts/rk3128-u-boot.dtsi
index 6d1965e6b520..dd1208e7cf40 100644
--- a/arch/arm/dts/rk3128-u-boot.dtsi
+++ b/arch/arm/dts/rk3128-u-boot.dtsi
@@ -14,6 +14,22 @@
bootph-all;
 };
 
+&gpio0 {
+   gpio-ranges = <&pinctrl 0 0 32>;
+};
+
+&gpio1 {
+   gpio-ranges = <&pinctrl 0 32 32>;
+};
+
+&gpio2 {
+   gpio-ranges = <&pinctrl 0 64 32>;
+};
+
+&gpio3 {
+   gpio-ranges = <&pinctrl 0 96 32>;
+};
+
 &grf {
bootph-all;
 };
diff --git a/arch/arm/dts/rk322x-u-boot.dtsi b/arch/arm/dts/rk322x-u-boot.dtsi
index aea917544b1c..f0e2a1f95aa0 100644
--- a/arch/arm/dts/rk322x-u-boot.dtsi
+++ b/arch/arm/dts/rk322x-u-boot.dtsi
@@ -47,6 +47,22 @@
max-frequency = <15000>;
 };
 
+&gpio0 {
+   gpio-ranges = <&pinctrl 0 0 32>;
+};
+
+&gpio1 {
+   gpio-ranges = <&pinctrl 0 32 32>;
+};
+
+&gpio2 {
+   gpio-ranges = <&pinctrl 0 64 32>;
+};
+
+&gpio3 {
+   gpio-ranges = <&pinctrl 0 96 32>;
+};
+
 &grf {
bootph-all;
 };
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index a43d320ade7b..0f8053a8b690 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -95,8 +95,41 @@
clock-names = "clk_edp", "clk_edp_24m", "pclk_edp";
 };
 
+&gpio0 {
+   gpio-ranges = <&pinctrl 0 0 24>;
+};
+
+&gpio1 {
+   gpio-ranges = <&pinctrl 0 24 32>;
+};
+
+&gpio2 {
+   gpio-ranges = <&pinctrl 0 56 32>;
+};
+
+&gpio3 {
+   gpio-ranges = <&pinctrl 0 88 32>;
+};
+
+&gpio4 {
+   gpio-ranges = <&pinctrl 0 120 32>;
+};
+
+&gpio5 {
+   gpio-ranges = <&pinctrl 0 152 32>;
+};
+
+&gpio6 {
+   gpio-ranges = <&pinctrl 0 184 32>;
+};
+
 &gpio7 {
bootph-all;
+   gpio-ranges = <&pinctrl 0 216 32>;
+};
+
+&gpio8 {
+   gpio-ranges = <&pinctrl 0 248 16>;
 };
 
 &grf {
diff --git a/arch/arm/dts/rk3308-u-boot.dtsi b/arch/arm/dts/rk3308-u-boot.dtsi
index b7964e2756f3..c2d56b532f80 100644
--- a/arch/arm/dts/rk3308-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-u-boot.dtsi
@@ -54,6 +54,26 @@
bootph-some-ram;
 };
 
+&gpio0 {
+   gpio-ranges = <&pinctrl 0 0 32>;
+};
+
+&gpio1 {
+   gpio-ranges = <&pinctrl 0 32 32>;
+};
+
+&gpio2 {
+   gpio-ranges = <&pinctrl 0 64 32>;
+};
+
+&gpio3 {
+   gpio-ranges = <&pinctrl 0 96 32>;
+};
+
+&gpio4 {
+   gpio-ranges = <&pinctrl 0 128 32>;
+};
+
 &grf {
bootph-all;
 };
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/

[PATCH v2 07/10] gpio: rockchip: Use pinctrl pin offset to get_gpio_mux()

2024-08-02 Thread Jonas Karlman
Use the pinctrl pin offset to get_gpio_mux() to remove the bank num
dependency and instead only use the bank num to assign a bank name.

Most Rockchip SoCs use all 32 pins of each gpio controller, meaning the
pinctrl pin offset typically is aligned to 32.

However, for gpio0 on RK3288 only 24 pins are used meaning the pinctrl
pin offset start at pin 24 for gpio1. Use DIV_ROUND_UP to get the 32 pin
aligned bank num.

Signed-off-by: Jonas Karlman 
Reviewed-by: Kever Yang 
---
v2: Collect r-b tag
---
 drivers/gpio/rk_gpio.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/rk_gpio.c b/drivers/gpio/rk_gpio.c
index abece6409ae0..5972f7f8612d 100644
--- a/drivers/gpio/rk_gpio.c
+++ b/drivers/gpio/rk_gpio.c
@@ -34,7 +34,7 @@ enum {
 struct rockchip_gpio_priv {
void __iomem *regs;
struct udevice *pinctrl;
-   int bank;
+   int pfc_offset;
char name[2];
u32 version;
 };
@@ -108,7 +108,8 @@ static int rockchip_gpio_get_function(struct udevice *dev, 
unsigned offset)
int ret;
 
if (CONFIG_IS_ENABLED(PINCTRL)) {
-   ret = pinctrl_get_gpio_mux(priv->pinctrl, priv->bank, offset);
+   ret = pinctrl_get_gpio_mux(priv->pinctrl, -1,
+  priv->pfc_offset + offset);
if (ret < 0)
return ret;
else if (ret != RK_FUNC_GPIO)
@@ -177,7 +178,7 @@ static int rockchip_gpio_probe(struct udevice *dev)
struct rockchip_gpio_priv *priv = dev_get_priv(dev);
struct ofnode_phandle_args args;
char *end;
-   int ret;
+   int bank, ret;
 
priv->regs = dev_read_addr_ptr(dev);
 
@@ -190,7 +191,8 @@ static int rockchip_gpio_probe(struct udevice *dev)
 0, &args);
if (!ret) {
uc_priv->gpio_count = args.args[2];
-   priv->bank = args.args[1] / ROCKCHIP_GPIOS_PER_BANK;
+   bank = DIV_ROUND_UP(args.args[1], ROCKCHIP_GPIOS_PER_BANK);
+   priv->pfc_offset = args.args[1];
 
if (CONFIG_IS_ENABLED(PINCTRL)) {
ret = uclass_get_device_by_ofnode(UCLASS_PINCTRL,
@@ -201,11 +203,12 @@ static int rockchip_gpio_probe(struct udevice *dev)
}
} else if (ret == -ENOENT || !CONFIG_IS_ENABLED(PINCTRL)) {
uc_priv->gpio_count = ROCKCHIP_GPIOS_PER_BANK;
-   ret = dev_read_alias_seq(dev, &priv->bank);
+   ret = dev_read_alias_seq(dev, &bank);
if (ret) {
end = strrchr(dev->name, '@');
-   priv->bank = trailing_strtoln(dev->name, end);
+   bank = trailing_strtoln(dev->name, end);
}
+   priv->pfc_offset = bank * ROCKCHIP_GPIOS_PER_BANK;
 
if (CONFIG_IS_ENABLED(PINCTRL)) {
ret = uclass_first_device_err(UCLASS_PINCTRL,
@@ -217,7 +220,7 @@ static int rockchip_gpio_probe(struct udevice *dev)
return ret;
}
 
-   priv->name[0] = 'A' + priv->bank;
+   priv->name[0] = 'A' + bank;
uc_priv->bank_name = priv->name;
 
priv->version = readl(priv->regs + VER_ID_V2);
-- 
2.45.2



[PATCH v2 08/10] gpio: rockchip: Add request() ops

2024-08-02 Thread Jonas Karlman
Add a request() ops that call pinctrl_gpio_request() when the required
gpio-ranges prop has been defined to signal pinctrl driver to use gpio
pinmux.

Signed-off-by: Jonas Karlman 
---
v2: New patch from "rockchip: Add gpio request() ops" series
---
 drivers/gpio/rk_gpio.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpio/rk_gpio.c b/drivers/gpio/rk_gpio.c
index 5972f7f8612d..65811dbc78d6 100644
--- a/drivers/gpio/rk_gpio.c
+++ b/drivers/gpio/rk_gpio.c
@@ -126,6 +126,15 @@ static int rockchip_gpio_get_function(struct udevice *dev, 
unsigned offset)
return (data & mask) ? GPIOF_OUTPUT : GPIOF_INPUT;
 }
 
+static int rockchip_gpio_request(struct udevice *dev, unsigned offset,
+const char *label)
+{
+   if (CONFIG_IS_ENABLED(PINCTRL) && dev_read_bool(dev, "gpio-ranges"))
+   return pinctrl_gpio_request(dev, offset, label);
+
+   return 0;
+}
+
 /* Simple SPL interface to GPIOs */
 #ifdef CONFIG_SPL_BUILD
 
@@ -229,6 +238,7 @@ static int rockchip_gpio_probe(struct udevice *dev)
 }
 
 static const struct dm_gpio_ops gpio_rockchip_ops = {
+   .request= rockchip_gpio_request,
.direction_input= rockchip_gpio_direction_input,
.direction_output   = rockchip_gpio_direction_output,
.get_value  = rockchip_gpio_get_value,
-- 
2.45.2



[PATCH v2 05/10] pinctrl: rockchip: Add gpio_request_enable() ops

2024-08-02 Thread Jonas Karlman
Implement gpio_request_enable() ops so that the gpio request() ops can
be implemented and a gpio requested pin automatically is pinmuxed for
gpio use, similar to Linux kernel.

Signed-off-by: Jonas Karlman 
---
v2: New patch from "rockchip: Add gpio request() ops" series
---
 drivers/pinctrl/rockchip/pinctrl-rockchip-core.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c 
b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
index 345e0abdf5d1..e164af0d8f61 100644
--- a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
+++ b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
@@ -358,6 +358,18 @@ static int rockchip_set_mux(struct rockchip_pin_bank 
*bank, int pin, int mux)
return 0;
 }
 
+static int rockchip_pinctrl_gpio_request_enable(struct udevice *dev,
+   unsigned int selector)
+{
+   struct rockchip_pin_bank *bank;
+
+   bank = rockchip_pin_to_bank(dev, selector);
+   if (!bank)
+   return -EINVAL;
+
+   return rockchip_set_mux(bank, selector - bank->pin_base, RK_FUNC_GPIO);
+}
+
 static int rockchip_perpin_drv_list[DRV_TYPE_MAX][8] = {
{ 2, 4, 8, 12, -1, -1, -1, -1 },
{ 3, 6, 9, 12, -1, -1, -1, -1 },
@@ -608,6 +620,7 @@ const struct pinctrl_ops rockchip_pinctrl_ops = {
.set_state  = rockchip_pinctrl_set_state,
.get_gpio_mux   = rockchip_pinctrl_get_gpio_mux,
.get_pin_muxing = rockchip_pinctrl_get_pin_muxing,
+   .gpio_request_enable= rockchip_pinctrl_gpio_request_enable,
 };
 
 /* retrieve the soc specific data */
-- 
2.45.2



[PATCH v2 06/10] gpio: rockchip: Get pinctrl device from gpio-ranges prop

2024-08-02 Thread Jonas Karlman
Get pinctrl device from gpio-ranges phandle when the property exists,
fallback to get the first pinctrl device.

Signed-off-by: Jonas Karlman 
Reviewed-by: Kever Yang 
---
v2: Collect r-b tag
---
 drivers/gpio/rk_gpio.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/gpio/rk_gpio.c b/drivers/gpio/rk_gpio.c
index 24ba12dd820e..abece6409ae0 100644
--- a/drivers/gpio/rk_gpio.c
+++ b/drivers/gpio/rk_gpio.c
@@ -181,12 +181,6 @@ static int rockchip_gpio_probe(struct udevice *dev)
 
priv->regs = dev_read_addr_ptr(dev);
 
-   if (CONFIG_IS_ENABLED(PINCTRL)) {
-   ret = uclass_first_device_err(UCLASS_PINCTRL, &priv->pinctrl);
-   if (ret)
-   return ret;
-   }
-
/*
 * If "gpio-ranges" is present in the devicetree use it to parse
 * the GPIO bank ID, otherwise use the legacy method.
@@ -194,16 +188,33 @@ static int rockchip_gpio_probe(struct udevice *dev)
ret = ofnode_parse_phandle_with_args(dev_ofnode(dev),
 "gpio-ranges", NULL, 3,
 0, &args);
-   if (!ret || ret != -ENOENT) {
+   if (!ret) {
uc_priv->gpio_count = args.args[2];
priv->bank = args.args[1] / ROCKCHIP_GPIOS_PER_BANK;
-   } else {
+
+   if (CONFIG_IS_ENABLED(PINCTRL)) {
+   ret = uclass_get_device_by_ofnode(UCLASS_PINCTRL,
+ args.node,
+ &priv->pinctrl);
+   if (ret)
+   return ret;
+   }
+   } else if (ret == -ENOENT || !CONFIG_IS_ENABLED(PINCTRL)) {
uc_priv->gpio_count = ROCKCHIP_GPIOS_PER_BANK;
ret = dev_read_alias_seq(dev, &priv->bank);
if (ret) {
end = strrchr(dev->name, '@');
priv->bank = trailing_strtoln(dev->name, end);
}
+
+   if (CONFIG_IS_ENABLED(PINCTRL)) {
+   ret = uclass_first_device_err(UCLASS_PINCTRL,
+ &priv->pinctrl);
+   if (ret)
+   return ret;
+   }
+   } else {
+   return ret;
}
 
priv->name[0] = 'A' + priv->bank;
-- 
2.45.2



[PATCH v2 03/10] pinctrl: rockchip: Update get_gpio_mux() ops

2024-08-02 Thread Jonas Karlman
Add a way to get_gpio_mux() based on the pinctrl pin offset, use -1 as
banknum to use the pinctrl pin offset mode instead of bank pin offset.

This mode will be used by the gpio driver to ensure a pin used by gpio
request() and get_function() ops always refer to the same pinctrl pin.

Also add verify_config() of banknum and index to avoid an out of range
access of the pin_banks array, i.e. with gpio6 on rk3066a.

Signed-off-by: Jonas Karlman 
Reviewed-by: Kever Yang 
---
v2: Collect r-b tag

The pin_to_mux() helper will also be used in the get_pin_muxing() ops
added in next patch to support the pinmux status cmd.
---
 .../pinctrl/rockchip/pinctrl-rockchip-core.c  | 22 ++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c 
b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
index 894ff74aee98..8ede74da40c9 100644
--- a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
+++ b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
@@ -193,10 +193,30 @@ static struct rockchip_pin_bank 
*rockchip_pin_to_bank(struct udevice *dev,
return NULL;
 }
 
+static int rockchip_pin_to_mux(struct udevice *dev, unsigned int pin)
+{
+   struct rockchip_pin_bank *bank;
+
+   bank = rockchip_pin_to_bank(dev, pin);
+   if (!bank)
+   return -EINVAL;
+
+   return rockchip_get_mux(bank, pin - bank->pin_base);
+}
+
 static int rockchip_pinctrl_get_gpio_mux(struct udevice *dev, int banknum,
 int index)
-{  struct rockchip_pinctrl_priv *priv = dev_get_priv(dev);
+{
+   struct rockchip_pinctrl_priv *priv = dev_get_priv(dev);
struct rockchip_pin_ctrl *ctrl = priv->ctrl;
+   int ret;
+
+   if (banknum == -1)
+   return rockchip_pin_to_mux(dev, index);
+
+   ret = rockchip_verify_config(dev, banknum, index);
+   if (ret)
+   return ret;
 
return rockchip_get_mux(&ctrl->pin_banks[banknum], index);
 }
-- 
2.45.2



[PATCH v2 04/10] pinctrl: rockchip: Add pinmux status related ops

2024-08-02 Thread Jonas Karlman
Add get_pins_count(), get_pin_name() and get_pin_muxing() ops to support
the pinmux status cmd.

  => pinmux dev pinctrl
  dev: pinctrl
  => pinmux status
  GPIO0_A0  : gpio
  GPIO0_A1  : func-1
  GPIO0_A2  : gpio
  GPIO0_A3  : gpio
  GPIO0_A4  : func-1
  GPIO0_A5  : gpio
  GPIO0_A6  : gpio
  GPIO0_A7  : func-1
  GPIO0_B0  : gpio
  GPIO0_B1  : func-1
  GPIO0_B2  : func-1
  GPIO0_B3  : gpio
  [...]

The change to use ENOENT for unrouted pins also help hide a "Error -22"
message for unrouted pins using the gpio status -a cmd.

Signed-off-by: Jonas Karlman 
Reviewed-by: Kever Yang 
---
v2: Collect r-b tag
---
 .../pinctrl/rockchip/pinctrl-rockchip-core.c  | 50 ++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c 
b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
index 8ede74da40c9..345e0abdf5d1 100644
--- a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
+++ b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
@@ -126,7 +126,7 @@ static int rockchip_get_mux(struct rockchip_pin_bank *bank, 
int pin)
 
if (bank->iomux[iomux_num].type & IOMUX_UNROUTED) {
debug("pin %d is unrouted\n", pin);
-   return -EINVAL;
+   return -ENOENT;
}
 
if (bank->iomux[iomux_num].type & IOMUX_GPIO_ONLY)
@@ -193,6 +193,32 @@ static struct rockchip_pin_bank 
*rockchip_pin_to_bank(struct udevice *dev,
return NULL;
 }
 
+static int rockchip_pinctrl_get_pins_count(struct udevice *dev)
+{
+   struct rockchip_pinctrl_priv *priv = dev_get_priv(dev);
+   struct rockchip_pin_ctrl *ctrl = priv->ctrl;
+
+   return ctrl->nr_pins;
+}
+
+static const char *rockchip_pinctrl_get_pin_name(struct udevice *dev,
+unsigned int selector)
+{
+   static char name[PINNAME_SIZE];
+   struct rockchip_pin_bank *bank;
+   unsigned int index;
+
+   bank = rockchip_pin_to_bank(dev, selector);
+   if (!bank)
+   return NULL;
+
+   index = selector - bank->pin_base;
+   snprintf(name, sizeof(name), "GPIO%u_%c%u",
+bank->bank_num, 'A' + (index / 8), index % 8);
+
+   return name;
+}
+
 static int rockchip_pin_to_mux(struct udevice *dev, unsigned int pin)
 {
struct rockchip_pin_bank *bank;
@@ -221,6 +247,25 @@ static int rockchip_pinctrl_get_gpio_mux(struct udevice 
*dev, int banknum,
return rockchip_get_mux(&ctrl->pin_banks[banknum], index);
 }
 
+static int rockchip_pinctrl_get_pin_muxing(struct udevice *dev,
+  unsigned int selector,
+  char *buf, int size)
+{
+   int mux;
+
+   mux = rockchip_pin_to_mux(dev, selector);
+   if (mux == -ENOENT)
+   strlcpy(buf, "unrouted", size);
+   else if (mux < 0)
+   return mux;
+   else if (mux)
+   snprintf(buf, size, "func-%d", mux);
+   else
+   strlcpy(buf, "gpio", size);
+
+   return 0;
+}
+
 static int rockchip_verify_mux(struct rockchip_pin_bank *bank,
   int pin, int mux)
 {
@@ -558,8 +603,11 @@ static int rockchip_pinctrl_set_state(struct udevice *dev,
 }
 
 const struct pinctrl_ops rockchip_pinctrl_ops = {
+   .get_pins_count = rockchip_pinctrl_get_pins_count,
+   .get_pin_name   = rockchip_pinctrl_get_pin_name,
.set_state  = rockchip_pinctrl_set_state,
.get_gpio_mux   = rockchip_pinctrl_get_gpio_mux,
+   .get_pin_muxing = rockchip_pinctrl_get_pin_muxing,
 };
 
 /* retrieve the soc specific data */
-- 
2.45.2



[PATCH v2 02/10] pinctrl: rockchip: Add a pin_to_bank() helper

2024-08-02 Thread Jonas Karlman
Add a pin_to_bank() helper that can locate a pin bank based on the pin
offset, to be used in get_gpio_mux() and gpio_request_enable() ops.

Reset ctrl->nr_pins to 0 so that pin_to_bank() can locate a bank after
the second probe in U-Boot proper.

Signed-off-by: Jonas Karlman 
---
v2: New patch split from "pinctrl: rockchip: Add gpio_request_enable()
ops" of "rockchip: Add gpio request() ops" series
---
 .../pinctrl/rockchip/pinctrl-rockchip-core.c   | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c 
b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
index f6af22501c36..894ff74aee98 100644
--- a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
+++ b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
@@ -176,6 +176,23 @@ static int rockchip_get_mux(struct rockchip_pin_bank 
*bank, int pin)
return ((val >> bit) & mask);
 }
 
+static struct rockchip_pin_bank *rockchip_pin_to_bank(struct udevice *dev,
+ unsigned int pin)
+{
+   struct rockchip_pinctrl_priv *priv = dev_get_priv(dev);
+   struct rockchip_pin_ctrl *ctrl = priv->ctrl;
+   struct rockchip_pin_bank *bank = ctrl->pin_banks;
+   int i;
+
+   for (i = 0; i < ctrl->nr_banks; ++i, ++bank) {
+   if (pin >= bank->pin_base &&
+   pin < bank->pin_base + bank->nr_pins)
+   return bank;
+   }
+
+   return NULL;
+}
+
 static int rockchip_pinctrl_get_gpio_mux(struct udevice *dev, int banknum,
 int index)
 {  struct rockchip_pinctrl_priv *priv = dev_get_priv(dev);
@@ -539,6 +556,7 @@ static struct rockchip_pin_ctrl 
*rockchip_pinctrl_get_soc_data(struct udevice *d
drv_pmu_offs = ctrl->pmu_drv_offset;
drv_grf_offs = ctrl->grf_drv_offset;
bank = ctrl->pin_banks;
+   ctrl->nr_pins = 0;
 
for (i = 0; i < ctrl->nr_banks; ++i, ++bank) {
int bank_pins = 0;
-- 
2.45.2



[PATCH v2 00/10] rockchip: pinctrl: Add support for pinmux status cmd

2024-08-02 Thread Jonas Karlman
This series includes some cleanup, add support for using the pinmux
status cmd and add support for the gpio request ops.

Following is an example on a Radxa ROCK 5A (RK3588S):

  => pinmux dev pinctrl
  dev: pinctrl
  => pinmux status
  GPIO0_A0  : gpio
  GPIO0_A1  : func-2
  GPIO0_A2  : gpio
  GPIO0_A3  : gpio
  GPIO0_A4  : func-1
  GPIO0_A5  : func-2
  GPIO0_A6  : gpio
  GPIO0_A7  : gpio
  GPIO0_B0  : gpio
  GPIO0_B1  : gpio
  GPIO0_B2  : gpio
  GPIO0_B3  : gpio
  GPIO0_B4  : gpio
  GPIO0_B5  : func-10
  GPIO0_B6  : func-10
  GPIO0_B7  : gpio
  [...]

and on a ASUS TinkerBoard R2.0 (RK3288W):

  => pinmux dev pinctrl
  dev: pinctrl
  => pinmux status
  [...]
  GPIO2_C6  : gpio
  GPIO2_C7  : gpio
  GPIO2_D0  : unrouted
  GPIO2_D1  : unrouted
  GPIO2_D2  : unrouted
  GPIO2_D3  : unrouted
  GPIO2_D4  : unrouted
  GPIO2_D5  : unrouted
  GPIO2_D6  : unrouted
  GPIO2_D7  : unrouted
  GPIO3_A0  : func-2
  GPIO3_A1  : func-2
  [...]

Patch 1 refactor to use syscon_regmap_lookup_by_phandle() helper.
Patch 6 refactor to get pinctrl device from gpio-ranges prop.

Patch 2, 3 and 7 change to use pinctrl pin offset instead of bank num to
get current pinmux.
Patch 4 add required ops for use of the pinmux status cmd.

Patch 5 and 8 add gpio_request_enable() and request() ops.

Patch 9 add gpio-ranges props for remaining RK SoCs, this is strictly
not needed for pinmux status cmd to function. However, the change to not
require the pin controller offset to be 32 aligned was required to add
gpio-ranges props for RK3288.

Patch 10 add gpio aliases for RK SoCs that is missing alias for gpio
controllers.

Changes in v2:
- Drop fixes patches already applied
- Split adding pin_to_bank() helper into own patch
- Add gpio_request_enable() and request() ops patch from the "rockchip:
  Add gpio request() ops" series
- Add missing gpio aliases
- Collect r-b tags

Jonas Karlman (10):
  pinctrl: rockchip: Use syscon_regmap_lookup_by_phandle()
  pinctrl: rockchip: Add a pin_to_bank() helper
  pinctrl: rockchip: Update get_gpio_mux() ops
  pinctrl: rockchip: Add pinmux status related ops
  pinctrl: rockchip: Add gpio_request_enable() ops
  gpio: rockchip: Get pinctrl device from gpio-ranges prop
  gpio: rockchip: Use pinctrl pin offset to get_gpio_mux()
  gpio: rockchip: Add request() ops
  rockchip: gpio: Add gpio-ranges props
  rockchip: gpio: Add missing gpio aliases

 arch/arm/dts/px30-u-boot.dtsi |   4 +
 arch/arm/dts/rk3036-u-boot.dtsi   |  12 ++
 arch/arm/dts/rk3066a-u-boot.dtsi  |  10 +-
 arch/arm/dts/rk3128-u-boot.dtsi   |  16 ++
 arch/arm/dts/rk322x-u-boot.dtsi   |  16 ++
 arch/arm/dts/rk3288-u-boot.dtsi   |  42 --
 arch/arm/dts/rk3308-u-boot.dtsi   |  20 +++
 arch/arm/dts/rk3328-u-boot.dtsi   |  13 ++
 arch/arm/dts/rk3368-u-boot.dtsi   |  16 ++
 arch/arm/dts/rk3399-u-boot.dtsi   |  20 +++
 arch/arm/dts/rk3xxx-u-boot.dtsi   |   7 +
 arch/arm/dts/rv1108-u-boot.dtsi   |  25 +++
 arch/arm/dts/rv1126-u-boot.dtsi   |  22 +++
 drivers/gpio/rk_gpio.c|  54 +--
 .../pinctrl/rockchip/pinctrl-rockchip-core.c  | 142 ++
 15 files changed, 364 insertions(+), 55 deletions(-)

-- 
2.45.2



[PATCH v2 01/10] pinctrl: rockchip: Use syscon_regmap_lookup_by_phandle()

2024-08-02 Thread Jonas Karlman
Use syscon_regmap_lookup_by_phandle() to simplify the code.

Signed-off-by: Jonas Karlman 
Reviewed-by: Kever Yang 
---
v2: Collect r-b tag
---
 .../pinctrl/rockchip/pinctrl-rockchip-core.c  | 39 ++-
 1 file changed, 12 insertions(+), 27 deletions(-)

diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c 
b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
index d449d07d32e7..f6af22501c36 100644
--- a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
+++ b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "pinctrl-rockchip.h"
@@ -640,37 +641,21 @@ int rockchip_pinctrl_probe(struct udevice *dev)
 {
struct rockchip_pinctrl_priv *priv = dev_get_priv(dev);
struct rockchip_pin_ctrl *ctrl;
-   struct udevice *syscon;
-   struct regmap *regmap;
-   int ret = 0;
 
-   /* get rockchip grf syscon phandle */
-   ret = uclass_get_device_by_phandle(UCLASS_SYSCON, dev, "rockchip,grf",
-  &syscon);
-   if (ret) {
-   debug("unable to find rockchip,grf syscon device (%d)\n", ret);
-   return ret;
+   priv->regmap_base =
+   syscon_regmap_lookup_by_phandle(dev, "rockchip,grf");
+   if (IS_ERR(priv->regmap_base)) {
+   debug("unable to find rockchip,grf regmap\n");
+   return PTR_ERR(priv->regmap_base);
}
 
-   /* get grf-reg base address */
-   regmap = syscon_get_regmap(syscon);
-   if (!regmap) {
-   debug("unable to find rockchip grf regmap\n");
-   return -ENODEV;
-   }
-   priv->regmap_base = regmap;
-
-   /* option: get pmu-reg base address */
-   ret = uclass_get_device_by_phandle(UCLASS_SYSCON, dev, "rockchip,pmu",
-  &syscon);
-   if (!ret) {
-   /* get pmugrf-reg base address */
-   regmap = syscon_get_regmap(syscon);
-   if (!regmap) {
-   debug("unable to find rockchip pmu regmap\n");
-   return -ENODEV;
+   if (dev_read_bool(dev, "rockchip,pmu")) {
+   priv->regmap_pmu =
+   syscon_regmap_lookup_by_phandle(dev, "rockchip,pmu");
+   if (IS_ERR(priv->regmap_pmu)) {
+   debug("unable to find rockchip,pmu regmap\n");
+   return PTR_ERR(priv->regmap_pmu);
}
-   priv->regmap_pmu = regmap;
}
 
ctrl = rockchip_pinctrl_get_soc_data(dev);
-- 
2.45.2



[PATCH v2 5/5] board: rockchip: Add Radxa ZERO 3W/3E

2024-08-02 Thread Jonas Karlman
The Radxa ZERO 3W/3E is an ultra-small, high-performance single board
computer based on the Rockchip RK3566, with a compact form factor and
rich interfaces.

Implement rk_board_late_init() to set correct fdtfile env var and
board_fit_config_name_match() to load correct FIT config based on what
board is detected at runtime so a single board target can be used for
both board models.

Features tested on a ZERO 3W 8GB v1.11:
- SD-card boot
- eMMC boot
- USB gadget
- USB host

Features tested on a ZERO 3E 4GB v1.2:
- SD-card boot
- Ethernet
- USB gadget
- USB host

Signed-off-by: Jonas Karlman 
Tested-by: FUKAUMI Naoki 
---
v2:
- Add override for dr_mode in usb_host0_xhci node
  https://lore.kernel.org/linux-rockchip/20240802051508.498-1-na...@radxa.com/
- Collect t-b tag
---
 arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi | 15 
 arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi | 15 
 arch/arm/mach-rockchip/rk3568/Kconfig |  6 ++
 board/radxa/zero3-rk3566/Kconfig  | 12 +++
 board/radxa/zero3-rk3566/MAINTAINERS  |  6 ++
 board/radxa/zero3-rk3566/Makefile |  3 +
 board/radxa/zero3-rk3566/zero3-rk3566.c   | 59 +
 configs/radxa-zero-3-rk3566_defconfig | 85 +++
 doc/board/rockchip/rockchip.rst   |  1 +
 9 files changed, 202 insertions(+)
 create mode 100644 arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi
 create mode 100644 board/radxa/zero3-rk3566/Kconfig
 create mode 100644 board/radxa/zero3-rk3566/MAINTAINERS
 create mode 100644 board/radxa/zero3-rk3566/Makefile
 create mode 100644 board/radxa/zero3-rk3566/zero3-rk3566.c
 create mode 100644 configs/radxa-zero-3-rk3566_defconfig

diff --git a/arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi 
b/arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi
new file mode 100644
index ..8af2581163be
--- /dev/null
+++ b/arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+&saradc {
+   bootph-pre-ram;
+};
+
+&usb_host0_xhci {
+   dr_mode = "otg";
+};
+
+&vcca_1v8 {
+   bootph-pre-ram;
+};
diff --git a/arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi 
b/arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi
new file mode 100644
index ..8af2581163be
--- /dev/null
+++ b/arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+&saradc {
+   bootph-pre-ram;
+};
+
+&usb_host0_xhci {
+   dr_mode = "otg";
+};
+
+&vcca_1v8 {
+   bootph-pre-ram;
+};
diff --git a/arch/arm/mach-rockchip/rk3568/Kconfig 
b/arch/arm/mach-rockchip/rk3568/Kconfig
index 014ebf9f0ba7..0f32f243be4e 100644
--- a/arch/arm/mach-rockchip/rk3568/Kconfig
+++ b/arch/arm/mach-rockchip/rk3568/Kconfig
@@ -32,6 +32,11 @@ config TARGET_QUARTZ64_RK3566
help
  Pine64 Quartz64 single board computer with a RK3566 SoC.
 
+config TARGET_RADXA_ZERO_3_RK3566
+   bool "Radxa ZERO 3W/3E"
+   help
+ Radxa ZERO 3W/3E single board computers with a RK3566 SoC.
+
 endchoice
 
 config ROCKCHIP_BOOT_MODE_REG
@@ -54,5 +59,6 @@ source "board/anbernic/rgxx3_rk3566/Kconfig"
 source "board/hardkernel/odroid_m1/Kconfig"
 source "board/pine64/quartz64_rk3566/Kconfig"
 source "board/powkiddy/x55/Kconfig"
+source "board/radxa/zero3-rk3566/Kconfig"
 
 endif
diff --git a/board/radxa/zero3-rk3566/Kconfig b/board/radxa/zero3-rk3566/Kconfig
new file mode 100644
index ..7d46efc9c40f
--- /dev/null
+++ b/board/radxa/zero3-rk3566/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_RADXA_ZERO_3_RK3566
+
+config SYS_BOARD
+   default "zero3-rk3566"
+
+config SYS_VENDOR
+   default "radxa"
+
+config SYS_CONFIG_NAME
+   default "evb_rk3568"
+
+endif
diff --git a/board/radxa/zero3-rk3566/MAINTAINERS 
b/board/radxa/zero3-rk3566/MAINTAINERS
new file mode 100644
index ..e5a5d856113d
--- /dev/null
+++ b/board/radxa/zero3-rk3566/MAINTAINERS
@@ -0,0 +1,6 @@
+RADXA-ZERO-3-RK3566
+M: Jonas Karlman 
+S: Maintained
+F: board/radxa/zero3-rk3566
+F: configs/radxa-zero-3-rk3566_defconfig
+F: arch/arm/dts/rk3566-radxa-zero-3*
diff --git a/board/radxa/zero3-rk3566/Makefile 
b/board/radxa/zero3-rk3566/Makefile
new file mode 100644
index ..b28b58ed5d87
--- /dev/null
+++ b/board/radxa/zero3-rk3566/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += zero3-rk3566.o
diff --git a/board/radxa/zero3-rk3566/zero3-rk3566.c 
b/board/radxa/zero3-rk3566/zero3-rk3566.c
new file mode 100644
index ..cf30c4e38987
--- /dev/null
+++ b/board/radxa/zero3-rk3566/zero3-rk3566.c
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#in

[PATCH v2 4/5] dm: adc: Add SPL_ADC Kconfig symbol for use of ADC in SPL

2024-08-02 Thread Jonas Karlman
What model of Radxa ZERO 3W/3E board can be identified using ADC at
runtime, add a Kconfig symbol to allow use of ADC in SPL.

This will be used to identify board model in SPL to allow loading
correct FIT configuration and FDT for U-Boot proper at SPL phase.

Signed-off-by: Jonas Karlman 
---
v2:
- Drop depends on ADC and instead use $(SPL_TPL_) for adc-uclass.o
- Add depends on DM/SPL_DM to ADC/SPL_ADC
---
 drivers/Makefile | 2 +-
 drivers/adc/Kconfig  | 5 +
 drivers/adc/Makefile | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 9195dafd37e0..1acd94f3c17e 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0+
 
+obj-$(CONFIG_$(SPL_TPL_)ADC) += adc/
 obj-$(CONFIG_$(SPL_TPL_)BIOSEMU) += bios_emulator/
 obj-$(CONFIG_$(SPL_TPL_)BLK) += block/
 obj-$(CONFIG_$(SPL_TPL_)BOOTCOUNT_LIMIT) += bootcount/
@@ -81,7 +82,6 @@ endif
 
 ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
 
-obj-y += adc/
 obj-y += ata/
 obj-$(CONFIG_DM_DEMO) += demo/
 obj-y += block/
diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
index c9cdbe6942de..37235f557a3c 100644
--- a/drivers/adc/Kconfig
+++ b/drivers/adc/Kconfig
@@ -1,5 +1,6 @@
 config ADC
bool "Enable ADC drivers using Driver Model"
+   depends on DM
help
  This enables ADC API for drivers, which allows driving ADC features
  by single and multi-channel methods for:
@@ -11,6 +12,10 @@ config ADC
  - support supply's phandle with auto-enable
  - supply polarity setting in fdt
 
+config SPL_ADC
+   bool "Enable ADC drivers using Driver Model in SPL"
+   depends on SPL_DM
+
 config ADC_EXYNOS
bool "Enable Exynos 54xx ADC driver"
depends on ADC
diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile
index 5336c820973a..dca0b39c2e27 100644
--- a/drivers/adc/Makefile
+++ b/drivers/adc/Makefile
@@ -4,7 +4,7 @@
 # Przemyslaw Marczak 
 #
 
-obj-$(CONFIG_ADC) += adc-uclass.o
+obj-$(CONFIG_$(SPL_TPL_)ADC) += adc-uclass.o
 obj-$(CONFIG_ADC_EXYNOS) += exynos-adc.o
 obj-$(CONFIG_ADC_SANDBOX) += sandbox.o
 obj-$(CONFIG_SARADC_ROCKCHIP) += rockchip-saradc.o
-- 
2.45.2



[PATCH v2 3/5] arm64: dts: rockchip: add gpio-line-names to radxa-zero-3

2024-08-02 Thread Jonas Karlman
From: Trevor Woerner 

Add names to the pins of the general-purpose expansion header as given
in the Radxa documentation[1] following the conventions in the kernel[2]
to make it easier for users to correlate pins with functions when using
utilities such as 'gpioinfo'.

[1] https://docs.radxa.com/en/zero/zero3/hardware-design/hardware-interface
[2] https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt

Signed-off-by: Trevor Woerner 
Link: https://lore.kernel.org/r/20240620013301.33653-1-twoer...@gmail.com
Signed-off-by: Heiko Stuebner 

[ upstream commit: f7c742cbe664ebdedc075945e75443683d1175f7 ]

(cherry picked from commit 8b26cf42ba0c74a9c86cebe591a9195f75151d97)
Signed-off-by: Jonas Karlman 
---
v2: Add Signed-off-by tag
---
 .../arm64/rockchip/rk3566-radxa-zero-3.dtsi   | 72 +++
 1 file changed, 72 insertions(+)

diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
index 081be841b286..9cc7aa3298d0 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
@@ -105,6 +105,78 @@
cpu-supply = <&vdd_cpu>;
 };
 
+&gpio0 {
+   gpio-line-names =
+   /* GPIO0_A0 - A7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO0_B0 - B7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO0_C0 - C7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO0_D0 - D7 */
+   "pin-10 [GPIO0_D0]", "pin-08 [GPIO0_D1]", "",
+   "", "", "", "", "";
+};
+
+&gpio1 {
+   gpio-line-names =
+   /* GPIO1_A0 - A7 */
+   "pin-03 [GPIO1_A0]", "pin-05 [GPIO1_A1]", "",
+   "",  "pin-37 [GPIO1_A4]", "",
+   "",  "",
+   /* GPIO1_B0 - B7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO1_C0 - C7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO1_D0 - D7 */
+   "", "", "", "", "", "", "", "";
+};
+
+&gpio2 {
+   gpio-line-names =
+   /* GPIO2_A0 - A7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO2_B0 - B7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO2_C0 - C7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO2_D0 - D7 */
+   "", "", "", "", "", "", "", "";
+};
+
+&gpio3 {
+   gpio-line-names =
+   /* GPIO3_A0 - A7 */
+   "",  "pin-11 [GPIO3_A1]", "pin-13 [GPIO3_A2]",
+   "pin-12 [GPIO3_A3]", "pin-35 [GPIO3_A4]", "pin-40 [GPIO3_A5]",
+   "pin-38 [GPIO3_A6]", "pin-36 [GPIO3_A7]",
+   /* GPIO3_B0 - B7 */
+   "pin-15 [GPIO3_B0]", "pin-16 [GPIO3_B1]", "pin-18 [GPIO3_B2]",
+   "pin-29 [GPIO3_B3]", "pin-31 [GPIO3_B4]", "",
+   "", "",
+   /* GPIO3_C0 - C7 */
+   "",  "pin-22 [GPIO3_C1]", "pin-32 [GPIO3_C2]",
+   "pin-33 [GPIO3_C3]", "pin-07 [GPIO3_C4]", "",
+   "", "",
+   /* GPIO3_D0 - D7 */
+   "", "", "", "", "", "", "", "";
+};
+
+&gpio4 {
+   gpio-line-names =
+   /* GPIO4_A0 - A7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO4_B0 - B7 */
+   "",  "",  "pin-27 [GPIO4_B2]",
+   "pin-28 [GPIO4_B3]", "", "", "", "",
+   /* GPIO4_C0 - C7 */
+   "",  "",  "pin-23 [GPIO4_C2]",
+   "pin-19 [GPIO4_C3]", "",  "pin-21 [GPIO4_C5]",
+   "pin-24 [GPIO4_C6]", "",
+   /* GPIO4_D0 - D7 */
+   "", "", "", "", "", "", "", "";
+};
+
 &gpu {
mali-supply = <&vdd_gpu_npu>;
status = "okay";
-- 
2.45.2



[PATCH v2 2/5] arm64: dts: rockchip: fix mmc aliases for Radxa ZERO 3E/3W

2024-08-02 Thread Jonas Karlman
From: FUKAUMI Naoki 

align with other Radxa products.

- mmc0 is eMMC
- mmc1 is microSD

for ZERO 3E, there is no eMMC, but aliases should start at 0, so mmc0
is microSD as exception.

Fixes: 1a5c8d307c83 ("arm64: dts: rockchip: Add Radxa ZERO 3W/3E")
Signed-off-by: FUKAUMI Naoki 

Changes in v3:
- fix syntax error in rk3566-radxa-zero-3e.dts
Changes in v2:
- microSD is mmc0 instead of mmc1 for ZERO 3E

Link: https://lore.kernel.org/r/20240620224435.2752-1-na...@radxa.com
Signed-off-by: Heiko Stuebner 

[ upstream commit: 060c1950037e4c54ca4d8186a8f46269e35db901 ]

(cherry picked from commit 8324bc7493e4088013c62bc41f49d6d181575493)
Signed-off-by: Jonas Karlman 
---
v2: Add Signed-off-by tag
---
 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi | 4 
 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts | 1 +
 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts | 3 ++-
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
index 623d5939d194..081be841b286 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
@@ -6,10 +6,6 @@
 #include "rk3566.dtsi"
 
 / {
-   aliases {
-   mmc0 = &sdmmc0;
-   };
-
chosen {
stdout-path = "serial2:150n8";
};
diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
index e166d66990b9..4a830eb09f0b 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
@@ -10,6 +10,7 @@
 
aliases {
ethernet0 = &gmac1;
+   mmc0 = &sdmmc0;
};
 };
 
diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts
index 9bf4f464915f..f92475c59deb 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts
@@ -9,7 +9,8 @@
compatible = "radxa,zero-3w", "rockchip,rk3566";
 
aliases {
-   mmc1 = &sdhci;
+   mmc0 = &sdhci;
+   mmc1 = &sdmmc0;
mmc2 = &sdmmc1;
};
 
-- 
2.45.2



[PATCH v2 1/5] arm64: dts: rockchip: Add Radxa ZERO 3W/3E

2024-08-02 Thread Jonas Karlman
The Radxa ZERO 3W/3E is an ultra-small, high-performance single board
computer based on the Rockchip RK3566, with a compact form factor and
rich interfaces.

The ZERO 3W and ZERO 3E are basically the same size and model, but
differ only in storage and network interfaces.

- eMMC (3W)
- SD-card (both)
- Ethernet (3E)
- WiFi/BT (3W)

Add initial support for eMMC, SD-card, Ethernet, HDMI and USB.

Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240521202810.1225636-3-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: 1a5c8d307c83c808a32686ed51afb4bac2092d39 ]

(cherry picked from commit 1476c5882f8a47b6f0f895c6424dacf6334487ae)
Signed-off-by: Jonas Karlman 
---
v2: Add Signed-off-by tag
---
 .../arm64/rockchip/rk3566-radxa-zero-3.dtsi   | 463 ++
 .../arm64/rockchip/rk3566-radxa-zero-3e.dts   |  51 ++
 .../arm64/rockchip/rk3566-radxa-zero-3w.dts   |  91 
 3 files changed, 605 insertions(+)
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts

diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
new file mode 100644
index ..623d5939d194
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
@@ -0,0 +1,463 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include 
+#include 
+#include 
+#include "rk3566.dtsi"
+
+/ {
+   aliases {
+   mmc0 = &sdmmc0;
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   hdmi-con {
+   compatible = "hdmi-connector";
+   type = "d";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&user_led2>;
+
+   led-green {
+   color = ;
+   default-state = "on";
+   function = LED_FUNCTION_HEARTBEAT;
+   gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   vcc_1v8: regulator-1v8-vcc {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_1v8";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <&vcc_1v8_p>;
+   };
+
+   vcca_1v8: regulator-1v8-vcca {
+   compatible = "regulator-fixed";
+   regulator-name = "vcca_1v8";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <&vcc_1v8_p>;
+   };
+
+   vcca1v8_image: regulator-1v8-vcca-image {
+   compatible = "regulator-fixed";
+   regulator-name = "vcca1v8_image";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <&vcc_1v8_p>;
+   };
+
+   vcc_3v3: regulator-3v3-vcc {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_3v3";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc3v3_sys>;
+   };
+
+   vcc_sys: regulator-5v0-vcc-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
+&combphy1 {
+   status = "okay";
+};
+
+&cpu0 {
+   cpu-supply = <&vdd_cpu>;
+};
+
+&cpu1 {
+   cpu-supply = <&vdd_cpu>;
+};
+
+&cpu2 {
+   cpu-supply = <&vdd_cpu>;
+};
+
+&cpu3 {
+   cpu-supply = <&vdd_cpu>;
+};
+
+&gpu {
+   mali-supply = <&vdd_gpu_npu>;
+   status = "okay"

[PATCH v2 0/5] board: rockchip: Add Radxa ZERO 3W/3E

2024-08-02 Thread Jonas Karlman
This series add support for the RK3566 based Radxa ZERO 3W/3E boards.

rk_board_late_init() and board_fit_config_name_match() has been
implemented to set fdtfile env var and load correct FIT config based
on what board is detected at runtime.

Features tested on a ZERO 3W 8GB v1.11:
- SD-card boot
- eMMC boot
- USB gadget
- USB host

Features tested on a ZERO 3E 4GB v1.2:
- SD-card boot
- Ethernet
- USB gadget
- USB host

Changes in v2:
- Add Signed-off-by tags to cherry-picked dts/upstream commits
- Drop depends on ADC and instead use $(SPL_TPL_) for adc-uclass.o
- Add depends on DM/SPL_DM to ADC/SPL_ADC
- Add override for dr_mode in usb_host0_xhci node
  https://lore.kernel.org/linux-rockchip/20240802051508.498-1-na...@radxa.com/
- Collect t-b tag

This series depends on the following patch for a clean apply:
- board: rockchip: add Radxa ROCK 3 Model C [1]

[1] https://patchwork.ozlabs.org/patch/1963177/

FUKAUMI Naoki (1):
  arm64: dts: rockchip: fix mmc aliases for Radxa ZERO 3E/3W

Jonas Karlman (3):
  arm64: dts: rockchip: Add Radxa ZERO 3W/3E
  dm: adc: Add SPL_ADC Kconfig symbol for use of ADC in SPL
  board: rockchip: Add Radxa ZERO 3W/3E

Trevor Woerner (1):
  arm64: dts: rockchip: add gpio-line-names to radxa-zero-3

 arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi |  15 +
 arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi |  15 +
 arch/arm/mach-rockchip/rk3568/Kconfig |   6 +
 board/radxa/zero3-rk3566/Kconfig  |  12 +
 board/radxa/zero3-rk3566/MAINTAINERS  |   6 +
 board/radxa/zero3-rk3566/Makefile |   3 +
 board/radxa/zero3-rk3566/zero3-rk3566.c   |  59 ++
 configs/radxa-zero-3-rk3566_defconfig |  85 +++
 doc/board/rockchip/rockchip.rst   |   1 +
 drivers/Makefile  |   2 +-
 drivers/adc/Kconfig   |   5 +
 drivers/adc/Makefile  |   2 +-
 .../arm64/rockchip/rk3566-radxa-zero-3.dtsi   | 531 ++
 .../arm64/rockchip/rk3566-radxa-zero-3e.dts   |  52 ++
 .../arm64/rockchip/rk3566-radxa-zero-3w.dts   |  92 +++
 15 files changed, 884 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi
 create mode 100644 board/radxa/zero3-rk3566/Kconfig
 create mode 100644 board/radxa/zero3-rk3566/MAINTAINERS
 create mode 100644 board/radxa/zero3-rk3566/Makefile
 create mode 100644 board/radxa/zero3-rk3566/zero3-rk3566.c
 create mode 100644 configs/radxa-zero-3-rk3566_defconfig
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts

-- 
2.45.2



Re: [PATCH v3 4/7] board: rock5b-rk3588: enable USB-C in operating system

2024-08-02 Thread Jonas Karlman
Hi Sebastian,

On 2024-08-02 19:59, Sebastian Reichel wrote:
> Since older U-Boot releases do not negotiate USB PD, the kernel
> DT may not enable the USB-C controller by default to avoid a
> regression. The plan is to upstream it with 'status = "fail";'
> instead. U-Boot should then mark it as 'status = "okay";' if
> it negotiated USB PD. Currently existing upstream kernel DTs do
> not yet have the USB-C controller at all, so we ignore any
> failures.

I do not really understand why you need to upstream it this way, there
are plenty of other rk3588 boards with fcs,fusb302 already having status
"okay" that possible are affected by same USB PD issue that ROCK 5B
have.

I guess you want to try and protect users that upgrade kernel DT and
ignore upgrading to a newer U-Boot, use vendor U-Boot or any other
bootloader from having possible issues with those USB PD power supplies
that have issues?

> 
> Signed-off-by: Sebastian Reichel 
> ---
>  board/radxa/rock5b-rk3588/rock5b-rk3588.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/board/radxa/rock5b-rk3588/rock5b-rk3588.c 
> b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
> index 1c17ae93c76c..4e926ebf2cb0 100644
> --- a/board/radxa/rock5b-rk3588/rock5b-rk3588.c
> +++ b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
> @@ -3,6 +3,8 @@
>   * Copyright (c) 2023-2024 Collabora Ltd.
>   */
>  
> +#include 
> +#include 
>  #include 
>  
>  #ifdef CONFIG_MISC_INIT_R
> @@ -33,3 +35,12 @@ int misc_init_r(void)
>   return 0;
>  }
>  #endif
> +
> +#ifdef CONFIG_OF_BOARD_SETUP
> +int ft_board_setup(void *blob, struct bd_info *bd)
> +{
> + if (IS_ENABLED(CONFIG_MISC_INIT_R))

It make very little sense to check for this, it is implied for almost
all Rockchip boards since it is used in rockchip board common code
to setup serial and Ethernet mac addresses env vars.

Regards,
Jonas

> + fdt_status_okay_by_compatible(blob, "fcs,fusb302");
> + return 0;
> +}
> +#endif



Re: [PATCH v3 3/7] board: rock5b-rk3588: add USB-C controller support

2024-08-02 Thread Jonas Karlman
Hi Sebastian,

On 2024-08-02 19:59, Sebastian Reichel wrote:
> Enable support for the fusb302 USB Type-C controller.
> 
> This will do early USB PD (power deliver) negotiation, which must happen
> within 5 seconds after the USB-C connector has plugged in according to
> the specification. It takes almost 5 seconds to go through the bootchain
> on Rock 5B and jump to the operating system. When the Linux initializes
> the fusb302 usually 20-30 seconds have gone since the device has been
> plugged, which is far too late. The USB PD power source reacts with a
> hard reset, which disables VBUS for some time. This is not a problem for
> a battery driven device, but Rock 5B will loose its power-supply and
> reset. By initializing PD in U-Boot, this can be avoided.
> 
> Signed-off-by: Sebastian Reichel 
> ---
>  board/radxa/rock5b-rk3588/Makefile|  6 
>  board/radxa/rock5b-rk3588/rock5b-rk3588.c | 35 +++
>  2 files changed, 41 insertions(+)
>  create mode 100644 board/radxa/rock5b-rk3588/Makefile
>  create mode 100644 board/radxa/rock5b-rk3588/rock5b-rk3588.c
> 
> diff --git a/board/radxa/rock5b-rk3588/Makefile 
> b/board/radxa/rock5b-rk3588/Makefile
> new file mode 100644
> index ..95d813596da4
> --- /dev/null
> +++ b/board/radxa/rock5b-rk3588/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (c) 2022 Collabora Ltd.
> +#
> +
> +obj-y += rock5b-rk3588.o
> diff --git a/board/radxa/rock5b-rk3588/rock5b-rk3588.c 
> b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
> new file mode 100644
> index ..1c17ae93c76c
> --- /dev/null
> +++ b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2023-2024 Collabora Ltd.
> + */
> +
> +#include 
> +
> +#ifdef CONFIG_MISC_INIT_R
> +int misc_init_r(void)

You should not override misc_init_r() here as it will override the
rockchip board common misc_init_r() function that read cpuid, set serial
and ethernet mac address env vars.

I would suggest you instead of tcpm_get() add something similar to

int tcpm_probe_all()
{
struct udevice *dev;
struct uclass *uc;
int ret;

ret = uclass_get(UCLASS_TCPM, &uc);
if (ret)
return ret;

for (ret = uclass_first_device_check(UCLASS_TCPM, &dev);
 dev;
 ret = uclass_next_device_check(&dev)) {
if (ret)
printf("Failed to probe Type-C controller '%s' 
(ret=%d)\n",
   dev->name, ret);
}

return 0;
}

or if we do not care about the error message this could use

uclass_probe_all(UCLASS_TCPM);

and call it from the rockchip board common code in mach-rockchip/board.c
directly after the call to regulators_enable_boot_on() in board_init().

Alternatively you could call following in a tcpm_post_bind()

dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);

to automatically probe the device as soon as possible after all devices
have been bind, this is how the rockchip-io-domain driver does it.

Otherwise we need to add custom board code for each board using USB PD,
something to avoid.

Regards,
Jonas

> +{
> + struct udevice *dev;
> + int ret;
> +
> + /*
> +  * This will do early USB PD (power deliver) negotiation, which must
> +  * happen within 5 seconds after the USB-C connector has plugged in
> +  * according to the specification. It takes almost 5 seconds to go
> +  * through the bootchain on Rock 5B and jump to the operating system.
> +  * When the Linux initializes the fusb302 usually 20-30 seconds have
> +  * gone since the device has been plugged, which is far too late.
> +  *
> +  * The USB PD power source reacts with a hard reset, which disables
> +  * VBUS for some time. This is not a problem for a battery driven
> +  * device, but Rock 5B will loose its power-supply and reset. By
> +  * initializing PD in U-Boot, this can be avoided.
> +  */
> + ret = tcpm_get("usb-typec@22", &dev);
> + if (ret) {
> + printf("Failed to probe Type-C controller\n");
> + return 0;
> + }
> +
> + return 0;
> +}
> +#endif



Re: [RFC] rockchip: rk3399: Migrate to use TPL on bob and kevin

2024-08-01 Thread Jonas Karlman
Hi Simon,

On 2024-08-01 15:07, Simon Glass wrote:
> Hi Jonas,
> 
> On Thu, 1 Aug 2024 at 02:37, Jonas Karlman  wrote:
>>
>> All Rockchip aarch64 boards, beside bob and kevin, use TPL to initialize
>> DRAM and SPL to load FIT with U-Boot proper and TF-A.
>>
>> Bob and kevin currently does not use TPL and instead initialize DRAM
>> in SPL and directly after tries to load FIT with U-Boot proper and TF-A.
>>
>> This RFC try to migrate bob and kevin to also use TPL to uniform TPL/SPL
>> use for all Rockchip aarch64 boards.
> 
> Thanks for doing this!
> 
>>
>> Notes and questions:
>> - Is u-boot.rom even used for bob/kevin? It use u-boot-img, yet SPL
>>   expect to load FIT and does not permit use of raw imgage.
> 
> Yes it does use u-boot.rom
> 
>>
>>   Q: Can we remove what looks to be a faulty u-boot.rom definition and
>>  just use u-boot-rockchip-spi.bin instead?
> 
> Maybe, but we do need the image to be the correct size.

Maybe just changing the u-boot-img to something like following could
possible work for the u-boot.rom output?

fit {
type = "blob";
filename = "u-boot.itb";
offset = ;
};

Similar to how it is done for the u-boot-rockchip-spi.bin output.

> 
>>
>> - FIT location moved from 0x4 to 0xE in SPI flash to allow for a
>>   larger SPL, up to 256 KiB, same as on other RK3399 boards.
>>
>>   Q: Can we use this location?, or is there something external that
>> expects fit or u-boot-img at this location?
> 
> It should be fine.
> 
>>
>> Features that is now used:
>> - Use of Rockchip aarch64 common bss and stack addresses
>> - Checksum/signature check of FIT images in SPL
>> - Use of dcache to speed up checksum check in SPL
>> - SDMA use for eMMC access to speed up read/write in U-Boot proper
>>
>> Changes that would be good for future:
>> - Include and use pinctrl in SPL
> 
> Yes

Looks like the pinctrl driver is already include in SPL, so we probably
only need to include the pinctrl-0 props and pinctrl nodes in SPL FDT.

Should help fix some of the pinctrl_select_state_full errors seen in
your output log below.

> 
>> - Use dm gpio instead of spl_gpio functions in SPL
> 
> Where are you looking for spl_gpio? I'm not seeing it.

board_debug_uart_init() in rk3399.c contains some special code for
bob and kevin using spl_gpio_output() and spl_gpio_set_pull().

led_setup() in roc-pc-rk3399.c is the only other user of these
functions, so would be nice if we can remove them and use full
dm_gpio variants instead.

Something for a separate series.

> 
>>
>> I do not have any bob or kevin so this has only been compile tested.
>>
>> This should be broken down into smaller logical patches if this is
>> accepted and works on real hardware.
> 
> I forgot that I broke my bob and need to fix it. For kevin (which is
> very similar):
> 
> before:
> 06:57 $ ub-int kevin
> Building U-Boot in sourcedir for chromebook_kevin
> Bootstrapping U-Boot from dir /tmp/b/chromebook_kevin
> Writing U-Boot using method em100
> Channel 0: LPDDR3, 933MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> Channel 1: LPDDR3, 933MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> 256B stride
> 
> U-Boot SPL 2024.07-rc4-9-g0ae095f4664 (Aug 01 2024 - 06:57:12 -0600)
> Bloblist at 10 not found (err=-2)
> Trying to boot from SPI
> ns16550_serial serial@ff1a: pinctrl_select_state_full:
> uclass_get_device_by_phandle_id: err=-19
> 
> 
> U-Boot 2024.07-rc4-9-g0ae095f4664 (Aug 01 2024 - 06:57:12 -0600)
> 
> Model: Google Kevin
> DRAM:  4 GiB (effective 3.9 GiB)
> Core:  329 devices, 33 uclasses, devicetree: separate
> MMC:   mmc@fe32: 1, mmc@fe33: 0
> Loading Environment from MMC... Reading from MMC(0)... *** Warning -
> bad CRC, using default environment
> 
> edp_rockchip dp@ff97: failed to set rate on clock index 0 (362) (error = 
> -2)
> edp_rockchip dp@ff97: failed to set rate on clock index 0 (362) (error = 
> -2)
> In:serial,cros-ec-keyb
> Out:   serial,vidconsole
> Err:   serial,vidconsole
> Model: Google Kevin
> Net:   No ethernet found.
> 
> Hit any key to stop autoboot:  0
> =>
> 
> with your patch:
> 06:53 $ ub-int kevin
> Building U-Boot in sourcedir for chromebook_kevin
> Bootstrapping U-Boot from dir /tmp/b/chromebook_kevin
> Writing U-Boot using method em100
> 
> U-Boot SPL 2024.07-rc4-00010-g14d97804e94 (Aug 01 2024 - 06:53:17 -0600)
> Checksum 0 != 68
> Bloblist at 10 not found (err=-5)
> Trying to 

Re: [PATCH 4/5] dm: adc: Add SPL_ADC Kconfig symbol for use of ADC in SPL

2024-08-01 Thread Jonas Karlman
Hi Quentin,

On 2024-08-01 11:26, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 7/31/24 4:10 PM, Jonas Karlman wrote:
>  > Hi Quentin,
>  >
>  > On 2024-07-31 14:42, Quentin Schulz wrote:
>  >> Hi Jonas,
>  >>
>  >> On 7/31/24 8:50 AM, Jonas Karlman wrote:
>  >>   > What model of Radxa ZERO 3W/3E boards can be identified using ADC at
>  >>   > runtime, add a Kconfig symbol to allow use of ADC in SPL.
>  >>   >
>  >>   > This will be used to identify board model in SPL to allow loading
>  >>   > correct FIT configuration and FDT for U-Boot proper at SPL phase.
>  >>   >
>  >>   > Signed-off-by: Jonas Karlman 
>  >>   > ---
>  >>   >   drivers/Makefile| 2 +-
>  >>   >   drivers/adc/Kconfig | 4 
>  >>   >   2 files changed, 5 insertions(+), 1 deletion(-)
>  >>   >
>  >>   > diff --git a/drivers/Makefile b/drivers/Makefile
>  >>   > index 9195dafd37e0..1acd94f3c17e 100644
>  >>   > --- a/drivers/Makefile
>  >>   > +++ b/drivers/Makefile
>  >>   > @@ -1,5 +1,6 @@
>  >>   >   # SPDX-License-Identifier: GPL-2.0+
>  >>   >
>  >>   > +obj-$(CONFIG_$(SPL_TPL_)ADC) += adc/
>  >>   >   obj-$(CONFIG_$(SPL_TPL_)BIOSEMU) += bios_emulator/
>  >>   >   obj-$(CONFIG_$(SPL_TPL_)BLK) += block/
>  >>   >   obj-$(CONFIG_$(SPL_TPL_)BOOTCOUNT_LIMIT) += bootcount/
>  >>   > @@ -81,7 +82,6 @@ endif
>  >>   >
>  >>   >   ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
>  >>   >
>  >>   > -obj-y += adc/
>  >>   >   obj-y += ata/
>  >>   >   obj-$(CONFIG_DM_DEMO) += demo/
>  >>   >   obj-y += block/
>  >>   > diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
>  >>   > index c9cdbe6942de..eb705f9e0fb8 100644
>  >>   > --- a/drivers/adc/Kconfig
>  >>   > +++ b/drivers/adc/Kconfig
>  >>   > @@ -11,6 +11,10 @@ config ADC
>  >>   >  - support supply's phandle with auto-enable
>  >>   >  - supply polarity setting in fdt
>  >>   >
>  >>   > +config SPL_ADC
>  >>   > + bool "Enable ADC drivers using Driver Model in SPL"
>  >>   > + depends on ADC
>  >>   > +
>  >>
>  >> This is just because you didn't modify the drivers/adc/Makefile to have
>  >> obj-$(CONFIG_$(SPL_TPL_)ADC) += adc-uclass.o
>  >> I assume? It's a bit odd to require a "proper" symbol for an SPL symbol.
>  >>
>  >> Additionally, since you use $(SPL_TPL_) maybe add that TPL symbol too in
>  >> the Kconfig?
>  >
>  > Agree, this could have been done differently, I added the depends on ADC
>  > a few minutes before I send the series to ensure next user of ADC in SPL
>  > does not miss it.
>  >
> 
> I would rather not depend on a hack if we can avoid it. I believe:
> obj-$(CONFIG_$(SPL_TPL_)ADC) += adc-uclass.o
> should be enough of a change here?

I thinks so to, will change to that in a v2.

> 
> I'm actually wondering if we can't simply have
> obj-y += adc-uclass.o
> ? considering that this Makefile is only included if
> $(CONFIG_$(SPL_TPL_)ADC)?

Should be possible, but it is probably better to be explicit in case the
condition in drivers/Makefile ever changes in the future.

Regards,
Jonas

> 
> Cheers,
> Quentin



[RFC] rockchip: rk3399: Migrate to use TPL on bob and kevin

2024-08-01 Thread Jonas Karlman
All Rockchip aarch64 boards, beside bob and kevin, use TPL to initialize
DRAM and SPL to load FIT with U-Boot proper and TF-A.

Bob and kevin currently does not use TPL and instead initialize DRAM
in SPL and directly after tries to load FIT with U-Boot proper and TF-A.

This RFC try to migrate bob and kevin to also use TPL to uniform TPL/SPL
use for all Rockchip aarch64 boards.

Notes and questions:
- Is u-boot.rom even used for bob/kevin? It use u-boot-img, yet SPL
  expect to load FIT and does not permit use of raw imgage.

  Q: Can we remove what looks to be a faulty u-boot.rom definition and
 just use u-boot-rockchip-spi.bin instead?

- FIT location moved from 0x4 to 0xE in SPI flash to allow for a
  larger SPL, up to 256 KiB, same as on other RK3399 boards.

  Q: Can we use this location?, or is there something external that
expects fit or u-boot-img at this location?

Features that is now used:
- Use of Rockchip aarch64 common bss and stack addresses
- Checksum/signature check of FIT images in SPL
- Use of dcache to speed up checksum check in SPL
- SDMA use for eMMC access to speed up read/write in U-Boot proper

Changes that would be good for future:
- Include and use pinctrl in SPL
- Use dm gpio instead of spl_gpio functions in SPL

I do not have any bob or kevin so this has only been compile tested.

This should be broken down into smaller logical patches if this is
accepted and works on real hardware.

Signed-off-by: Jonas Karlman 
---
 arch/arm/dts/rk3399-gru-u-boot.dtsi|  5 +++--
 arch/arm/dts/rk3399-u-boot.dtsi| 10 +-
 arch/arm/mach-rockchip/Kconfig |  1 +
 arch/arm/mach-rockchip/rk3399/Kconfig  | 12 
 arch/arm/mach-rockchip/rk3399/rk3399.c |  2 +-
 configs/chromebook_bob_defconfig   | 20 
 configs/chromebook_kevin_defconfig | 20 
 7 files changed, 22 insertions(+), 48 deletions(-)

diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi 
b/arch/arm/dts/rk3399-gru-u-boot.dtsi
index 6bdc892bd913..1d43e07091f4 100644
--- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
@@ -11,7 +11,7 @@
};
 
config {
-   u-boot,spl-payload-offset = <0x4>;
+   u-boot,spl-payload-offset = <0xE>;
};
 };
 
@@ -80,7 +80,8 @@
 
 &spi1 {
spi_flash: flash@0 {
-   bootph-all;
+   bootph-pre-ram;
+   bootph-some-ram;
};
 };
 
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 2bec139d8338..cb64c5fc3d4b 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -39,11 +39,19 @@
 
mkimage {
args = "-n rk3399 -T rkspi";
+   multiple-data-files;
+#ifdef CONFIG_ROCKCHIP_EXTERNAL_TPL
+   rockchip-tpl {
+   };
+#elif defined(CONFIG_TPL)
+   u-boot-tpl {
+   };
+#endif
u-boot-spl {
};
};
u-boot-img {
-   offset = <0x4>;
+   offset = <0xE>;
};
u-boot {
offset = <0x30>;
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index fc1b638ff01d..c0a8bd929dd7 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -289,6 +289,7 @@ config ROCKCHIP_RK3399
imply SPL_FIT_SIGNATURE
imply SPL_ROCKCHIP_COMMON_BOARD
imply SYS_BOOTCOUNT_SINGLEWORD if BOOTCOUNT_LIMIT
+   imply TPL if !ROCKCHIP_EXTERNAL_TPL
imply TPL_CLK
imply TPL_DM
imply TPL_LIBCOMMON_SUPPORT
diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig 
b/arch/arm/mach-rockchip/rk3399/Kconfig
index 04a84e2f6a04..500cfcd87afd 100644
--- a/arch/arm/mach-rockchip/rk3399/Kconfig
+++ b/arch/arm/mach-rockchip/rk3399/Kconfig
@@ -146,15 +146,6 @@ config SYS_SOC
 config ROCKCHIP_COMMON_STACK_ADDR
default y
 
-config SYS_MALLOC_F_LEN
-   default 0x4000 if !SPL_SHARES_INIT_SP_ADDR
-
-config SPL_LIBCOMMON_SUPPORT
-   default y
-
-config SPL_LIBGENERIC_SUPPORT
-   default y
-
 config TPL_LDSCRIPT
default "arch/arm/mach-rockchip/u-boot-tpl-v8.lds"
 
@@ -164,9 +155,6 @@ config TPL_STACK
 config TPL_TEXT_BASE
 default 0xff8c2000
 
-config SPL_STACK_R_ADDR
-   default 0x0400 if !SPL_SHARES_INIT_SP_ADDR
-
 if BOOTCOUNT_LIMIT
 
 config BOOTCOUNT_BOOTLIMIT
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 2d7d0f82a2f1..3b6a9c7951a6 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -136,7 +136,7 @@ void board_debug_uart_init(void)
struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGR

Re: [PATCH v8 8/8] rockchip: Avoid #ifdefs in RK3399 SPL

2024-07-31 Thread Jonas Karlman
Hi Simon,

On 2024-07-31 23:58, Simon Glass wrote:
> The code here is confusing due to large blocks which are #ifdefed out.
> Add a function phase_sdram_init() which returns whether SDRAM init
> should happen in the current phase, using that as needed to control the
> code flow.
> 
> This increases code size by about 500 bytes in SPL when the cache is on,
> since it must call the rather large rockchip_sdram_size() function.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v8:
> - Include ROCKCHIP_EXTERNAL_TPL in the condition
> - Put the non-dcache change back into patch 5
> 
> Changes in v5:
> - Move setting of pmugrf into the probe() function
> - Drop the non-dcache optimisation, since the cache should normally be on
> - Drop patches previously applied
> 
> Changes in v4:
> - Fix 'stating' typo
> - Move Binman size feature to a separate series
> 
> Changes in v3:
> - Split out the refactoring into a separate patch
> 
> Changes in v2:
> - Drop patch "regulator: rk8xx: Fix incorrect parameter"
> - Rewrite boneblack patch to onstead drop the target and update docs
> 
>  drivers/ram/rockchip/sdram_rk3399.c | 35 +++--
>  1 file changed, 18 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/ram/rockchip/sdram_rk3399.c 
> b/drivers/ram/rockchip/sdram_rk3399.c
> index bc79c034808..611e30cbe52 100644
> --- a/drivers/ram/rockchip/sdram_rk3399.c
> +++ b/drivers/ram/rockchip/sdram_rk3399.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -63,8 +64,6 @@ struct chan_info {
>  };
>  
>  struct dram_info {
> -#if defined(CONFIG_TPL_BUILD) || \
> - (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
>   u32 pwrup_srefresh_exit[2];
>   struct chan_info chan[2];
>   struct clk ddr_clk;
> @@ -75,7 +74,6 @@ struct dram_info {
>   struct rk3399_pmusgrf_regs *pmusgrf;
>   struct rk3399_ddr_cic_regs *cic;
>   const struct sdram_rk3399_ops *ops;
> -#endif
>   struct ram_info info;
>   struct rk3399_pmugrf_regs *pmugrf;
>  };
> @@ -92,9 +90,6 @@ struct sdram_rk3399_ops {
>   struct rk3399_sdram_params *params);
>  };
>  
> -#if defined(CONFIG_TPL_BUILD) || \
> - (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
> -
>  struct rockchip_dmc_plat {
>  #if CONFIG_IS_ENABLED(OF_PLATDATA)
>   struct dtd_rockchip_rk3399_dmc dtplat;
> @@ -191,6 +186,19 @@ struct io_setting {
>   },
>  };
>  
> +/**
> + * phase_sdram_init() - Check if this is the phase where SDRAM init happens
> + *
> + * Returns: true to do SDRAM init in this phase, false to not
> + */
> +static bool phase_sdram_init(void)
> +{
> + return spl_phase() == PHASE_TPL ||
> + (!IS_ENABLED(CONFIG_TPL) &&
> +  !IS_ENABLED(CONFIG_ROCKCHIP_EXTERNAL_TPL) &&
> +  !spl_in_proper());
> +}
> +
>  static struct io_setting *
>  lpddr4_get_io_settings(const struct rk3399_sdram_params *params, u32 mr5)
>  {
> @@ -3024,7 +3032,7 @@ static int rk3399_dmc_of_to_plat(struct udevice *dev)
>   struct rockchip_dmc_plat *plat = dev_get_plat(dev);
>   int ret;
>  
> - if (!CONFIG_IS_ENABLED(OF_REAL))
> + if (!CONFIG_IS_ENABLED(OF_REAL) || !phase_sdram_init())
>   return 0;
>  
>   ret = dev_read_u32_array(dev, "rockchip,sdram-params",
> @@ -3093,7 +3101,6 @@ static int rk3399_dmc_init(struct udevice *dev)
>   priv->cic = syscon_get_first_range(ROCKCHIP_SYSCON_CIC);
>   priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
>   priv->pmu = syscon_get_first_range(ROCKCHIP_SYSCON_PMU);
> - priv->pmugrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
>   priv->pmusgrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUSGRF);
>   priv->pmucru = rockchip_get_pmucru();
>   priv->cru = rockchip_get_cru();
> @@ -3138,19 +3145,16 @@ static int rk3399_dmc_init(struct udevice *dev)
>  
>   return 0;
>  }
> -#endif
>  
>  static int rk3399_dmc_probe(struct udevice *dev)
>  {
>   struct dram_info *priv = dev_get_priv(dev);
>  
> -#if defined(CONFIG_TPL_BUILD) || \
> - (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
> - if (rk3399_dmc_init(dev))
> - return 0;
> -#endif
>   priv->pmugrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
>   debug("%s: pmugrf = %p\n", __func__, priv->pmugrf);
> + if (phase_sdram_init() && rk3399_dmc_init(dev))
> + return 0;
> +

As you pointed out in the other mail thread, this adds ~500 bytes to TPL
because of the added (and unneeded) call to rockchip_sdram_size().

The rockchip_sdram_size() call only make sense to be done in SPL and
later phases, as was done before the changes in this patch.

This RAM driver need to:
- In TPL (or SPL on bob/kevin) initialize DRAM, i.e. rk3399_dmc_init().
- In SPL and later phases report DRAM size, i.e. rockchip_sdram_size().

Please restore the old behavior with something like:

if (IS_ENABLED(CONFIG_TPL_

Re: [PATCH v7 8/8] rockchip: Avoid #ifdefs in RK3399 SPL

2024-07-31 Thread Jonas Karlman
Hi Simon,

On 2024-07-31 23:52, Simon Glass wrote:
> Hi Jonas,
> 
> On Wed, 31 Jul 2024 at 09:03, Jonas Karlman  wrote:
>>
>> Hi Simon,
>>
>> On 2024-07-31 16:49, Simon Glass wrote:
>>> The code here is confusing due to large blocks which are #ifdefed out.
>>> Add a function phase_sdram_init() which returns whether SDRAM init
>>> should happen in the current phase, using that as needed to control the
>>> code flow.
>>>
>>> This increases code size by about 500 bytes in SPL when the cache is on,
>>> since it must call the rather large rockchip_sdram_size() function.
>>
>> I am guessing this size increase only is related to kevin/bob since all
>> other RK3399 boards already use rockchip_sdram_size() in SPL.
> 
> That's not what I am seeing:

Ahh, this is adding the rockchip_sdram_size() call to TPL for all other
RK3399 boards that has no need for it, hence the size increase on all
other boards beside bob and kevin.

This should be adjusted to only be called in SPL, as there is no point
for it to be called/used in TPL, in TPL we only initialize DRAM, write
the DRAM size to the os reg and finally jump back to BROM to load next
stage, SPL.

Regards,
Jonas

> 
> buildman -b bugs8 rk3399 -sS
> Summary of 9 commits for 29 boards (29 threads, 2 jobs per thread)
> 01: Merge patch series "led: implement software blinking"
>aarch64:  w+   roc-pc-mezzanine-rk3399 roc-pc-rk3399 chromebook_bob
> chromebook_kevin pinebook-pro-rk3399 pinephone-pro-rk3399
> rockpro64-rk3399 rock-4c-plus-rk3399 rock-4se-rk3399 rock-pi-4-rk3399
> rock-pi-4c-rk3399 eaidk-610-rk3399 evb-rk3399 firefly-rk3399
> khadas-edge-captain-rk3399 khadas-edge-rk3399 khadas-edge-v-rk3399
> leez-rk3399 nanopc-t4-rk3399 nanopi-m4-2gb-rk3399 nanopi-m4-rk3399
> nanopi-m4b-rk3399 nanopi-neo4-rk3399 nanopi-r4s-rk3399 orangepi-rk3399
> rock-pi-n10-rk3399pro puma-rk3399 ficus-rk3399 rock960-rk3399
> 02: mkeficapsule: Add a --version argument
> 03: binman: Collect the version number for mkeficapsule
> 04: binman: Deal with mkeficapsule being missing
> 05: binman: Return failure when a usage() message is generated
> 06: binman: Keep the efi_capsule input file
> 07: fdt: Correct condition for bloblist existing
> 08: rockchip: Ensure memory size is available in RK3399 SPL
>aarch64: (for 29/29 boards) spl/u-boot-spl:all +33.1
> spl/u-boot-spl:text +33.1 tpl/u-boot-tpl:all +446.9
> tpl/u-boot-tpl:text +446.9
> 09: rockchip: Avoid #ifdefs in RK3399 SPL
>aarch64: (for 29/29 boards) all +69.2 bss +5.2 spl/u-boot-spl:all
> +24.0 spl/u-boot-spl:text +24.0 text +64.0 tpl/u-boot-tpl:all +21.5
> tpl/u-boot-tpl:text +21.5
> ✔ ~/u [bugs8 ↓·18↑·8|…2⚑ 1001]
> 15:48 $ buildman -b bugs8 rk3399 -sSB
> Summary of 9 commits for 29 boards (29 threads, 2 jobs per thread)
> 01: Merge patch series "led: implement software blinking"
>aarch64:  w+   roc-pc-mezzanine-rk3399 roc-pc-rk3399 chromebook_bob
> chromebook_kevin pinebook-pro-rk3399 pinephone-pro-rk3399
> rockpro64-rk3399 rock-4c-plus-rk3399 rock-4se-rk3399 rock-pi-4-rk3399
> rock-pi-4c-rk3399 eaidk-610-rk3399 evb-rk3399 firefly-rk3399
> khadas-edge-captain-rk3399 khadas-edge-rk3399 khadas-edge-v-rk3399
> leez-rk3399 nanopc-t4-rk3399 nanopi-m4-2gb-rk3399 nanopi-m4-rk3399
> nanopi-m4b-rk3399 nanopi-neo4-rk3399 nanopi-r4s-rk3399 orangepi-rk3399
> rock-pi-n10-rk3399pro puma-rk3399 ficus-rk3399 rock960-rk3399
> 02: mkeficapsule: Add a --version argument
> 03: binman: Collect the version number for mkeficapsule
> 04: binman: Deal with mkeficapsule being missing
> 05: binman: Return failure when a usage() message is generated
> 06: binman: Keep the efi_capsule input file
> 07: fdt: Correct condition for bloblist existing
> 08: rockchip: Ensure memory size is available in RK3399 SPL
>aarch64: (for 29/29 boards) spl/u-boot-spl:all +33.1
> spl/u-boot-spl:text +33.1 tpl/u-boot-tpl:all +446.9
> tpl/u-boot-tpl:text +446.9
> roc-pc-mezzanine-rk3399: tpl/u-boot-tpl:all +480
> tpl/u-boot-tpl:text +480
>tpl-u-boot-tpl: add: 1/0, grow: 1/0 bytes: 480/0 (480)
>  function   old new   
> delta
>  rockchip_sdram_size  - 432
> +432
>  rk3399_dmc_probe  41204168 
> +48
> roc-pc-rk3399  : tpl/u-boot-tpl:all +480 tpl/u-boot-tpl:text +480
>tpl-u-boot-tpl: add: 1/0, grow: 1/0 bytes: 480/0 (480)
>  function   old new   
> delta
>  rockchip_sdram_size  - 432
> +432
>  rk33

[PATCH 2/2] board: rockchip: Add FriendlyElec CM3588 NAS

2024-07-31 Thread Jonas Karlman
The CM3588 NAS by FriendlyElec pairs the CM3588 compute module, based
on the Rockchip RK3588 SoC, with the CM3588 NAS Kit carrier board.

Features tested on a CM3588 NAS Kit with 8GB RAM 64GB eMMC module:
- SD-card boot
- eMMC boot
- Ethernet
- PCIe/NVMe
- USB gadget
- USB host

Signed-off-by: Jonas Karlman 
---
 ...rk3588-friendlyelec-cm3588-nas-u-boot.dtsi |  8 ++
 arch/arm/mach-rockchip/rk3588/Kconfig | 24 +
 board/friendlyelec/cm3588-nas-rk3588/Kconfig  | 12 +++
 .../cm3588-nas-rk3588/MAINTAINERS |  6 ++
 configs/cm3588-nas-rk3588_defconfig   | 90 +++
 doc/board/rockchip/rockchip.rst   |  1 +
 6 files changed, 141 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-friendlyelec-cm3588-nas-u-boot.dtsi
 create mode 100644 board/friendlyelec/cm3588-nas-rk3588/Kconfig
 create mode 100644 board/friendlyelec/cm3588-nas-rk3588/MAINTAINERS
 create mode 100644 configs/cm3588-nas-rk3588_defconfig

diff --git a/arch/arm/dts/rk3588-friendlyelec-cm3588-nas-u-boot.dtsi 
b/arch/arm/dts/rk3588-friendlyelec-cm3588-nas-u-boot.dtsi
new file mode 100644
index ..2e60f2dce8f1
--- /dev/null
+++ b/arch/arm/dts/rk3588-friendlyelec-cm3588-nas-u-boot.dtsi
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588-u-boot.dtsi"
+
+&sdhci {
+   cap-mmc-highspeed;
+   mmc-hs200-1_8v;
+};
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig 
b/arch/arm/mach-rockchip/rk3588/Kconfig
index 0dcf2249fb48..a76a470cc981 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -6,6 +6,29 @@ config TARGET_EVB_RK3588
help
  RK3588 EVB is a evaluation board for Rockchp RK3588.
 
+config TARGET_CM3588_NAS_RK3588
+   bool "FriendlyElec CM3588 NAS"
+   select BOARD_LATE_INIT
+   help
+ The CM3588 NAS by FriendlyElec pairs the CM3588 compute module, based
+ on the Rockchip RK3588 SoC, with the CM3588 NAS Kit carrier board.
+
+ Hardware features:
+ - Rockchip RK3588 SoC
+ - 4GB/8GB/16GB LPDDR4x RAM
+ - 0GB/64GB HS400 eMMC
+ - MicroSD card slot
+ - 1x RTL8125B 2.5G Ethernet
+ - 4x M.2 M-Key with PCIe 3.0 x1 (via bifurcation) for NVMe SSDs
+ - 2x USB 3.0 (USB 3.1 Gen1) Type-A, 1x USB 2.0 Type-A
+ - 1x USB 3.0 Type-C with DP AltMode support
+ - 2x HDMI 2.1 out, 1x HDMI in
+ - MIPI-CSI Connector, MIPI-DSI Connector
+ - 40-pin GPIO header
+ - 4 buttons: power, reset, recovery, MASK, user button
+ - 3.5mm Headphone out, 2.0mm PH-2A Mic in
+ - 5V Fan connector, PWM beeper, IR receiver, RTC battery connector
+
 config TARGET_JAGUAR_RK3588
bool "Theobroma Systems SBC-RK3588-AMR (Jaguar)"
select BOARD_LATE_INIT
@@ -339,6 +362,7 @@ config TEXT_BASE
 
 source "board/armsom/sige7-rk3588/Kconfig"
 source "board/edgeble/neural-compute-module-6/Kconfig"
+source "board/friendlyelec/cm3588-nas-rk3588/Kconfig"
 source "board/friendlyelec/nanopc-t6-rk3588/Kconfig"
 source "board/friendlyelec/nanopi-r6c-rk3588s/Kconfig"
 source "board/friendlyelec/nanopi-r6s-rk3588s/Kconfig"
diff --git a/board/friendlyelec/cm3588-nas-rk3588/Kconfig 
b/board/friendlyelec/cm3588-nas-rk3588/Kconfig
new file mode 100644
index ..fdc458a42643
--- /dev/null
+++ b/board/friendlyelec/cm3588-nas-rk3588/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_CM3588_NAS_RK3588
+
+config SYS_BOARD
+   default "cm3588-nas-rk3588"
+
+config SYS_VENDOR
+   default "friendlyelec"
+
+config SYS_CONFIG_NAME
+   default "nanopc-t6-rk3588"
+
+endif
diff --git a/board/friendlyelec/cm3588-nas-rk3588/MAINTAINERS 
b/board/friendlyelec/cm3588-nas-rk3588/MAINTAINERS
new file mode 100644
index ..92b958ada6fa
--- /dev/null
+++ b/board/friendlyelec/cm3588-nas-rk3588/MAINTAINERS
@@ -0,0 +1,6 @@
+CM3588-NAS-RK3588
+M: Jonas Karlman 
+S: Maintained
+F: board/friendlyelec/cm3588-nas-rk3588
+F: configs/cm3588-nas-rk3588_defconfig
+F: arch/arm/dts/rk3588-friendlyelec-cm3588-nas*
diff --git a/configs/cm3588-nas-rk3588_defconfig 
b/configs/cm3588-nas-rk3588_defconfig
new file mode 100644
index ..d6d82757a2de
--- /dev/null
+++ b/configs/cm3588-nas-rk3588_defconfig
@@ -0,0 +1,90 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_SYS_HAS_NONCACHED_MEMORY=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3588-friendlyelec-cm3588-nas"
+CONFIG_ROCKCHIP_RK3588=y
+CONFIG_SPL_SERIAL=y
+CONFIG_TARGET_CM3588_NAS_RK3588=y
+CONFIG_DEBUG_UART_BASE=0xFEB5
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SYS_LOAD_ADDR=0xc00800
+CONFIG_PCI=y
+CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFI

[PATCH 1/2] arm64: dts: rockchip: Add FriendlyElec CM3588 NAS board

2024-07-31 Thread Jonas Karlman
From: Sebastian Kropatsch 

The CM3588 NAS by FriendlyElec pairs the CM3588 compute module, based on
the Rockchip RK3588 SoC, with the CM3588 NAS Kit carrier board.
To reflect the hardware setup, add device tree sources for the SoM and
the NAS daughter board as separate files.

Hardware features:
- Rockchip RK3588 SoC
- 4GB/8GB/16GB LPDDR4x RAM
- 64GB eMMC
- MicroSD card slot
- 1x RTL8125B 2.5G Ethernet
- 4x M.2 M-Key with PCIe 3.0 x1 (via bifurcation) for NVMe SSDs
- 2x USB 3.0 (USB 3.1 Gen1) Type-A, 1x USB 2.0 Type-A
- 1x USB 3.0 Type-C with DP AltMode support
- 2x HDMI 2.1 out, 1x HDMI in
- MIPI-CSI Connector, MIPI-DSI Connector
- 40-pin GPIO header
- 4 buttons: power, reset, recovery, MASK, user button
- 3.5mm Headphone out, 2.0mm PH-2A Mic in
- 5V Fan connector, PWM beeper, IR receiver, RTC battery connector

PCIe bifurcation is used to handle all four M.2 sockets at PCIe 3.0 x1
speed. Data lane mapping in the DT is done like described in commit
f8020dfb311d ("phy: rockchip-snps-pcie3: fix bifurcation on rk3588").

This device tree includes support for eMMC, SD card, ethernet, all USB2
and USB3 ports, all four M.2 slots, GPU, beeper, IR, RTC, UART debugging
as well as the buttons and LEDs.
The GPIOs are labeled according to the schematics.

Reviewed-by: Space Meyer 
Signed-off-by: Sebastian Kropatsch 
Link: https://lore.kernel.org/r/20240616215354.40999-3-seb-...@mail.de
Signed-off-by: Heiko Stuebner 

[ upstream commit: e23819cf273c110662fdc392dcb55a75b3888609 ]

(cherry picked from commit c1a8bf31d96d890dd8328ae452fe62971ac555c2)
Signed-off-by: Jonas Karlman 
---
 .../rk3588-friendlyelec-cm3588-nas.dts| 778 ++
 .../rockchip/rk3588-friendlyelec-cm3588.dtsi  | 653 +++
 2 files changed, 1431 insertions(+)
 create mode 100644 
dts/upstream/src/arm64/rockchip/rk3588-friendlyelec-cm3588-nas.dts
 create mode 100644 
dts/upstream/src/arm64/rockchip/rk3588-friendlyelec-cm3588.dtsi

diff --git a/dts/upstream/src/arm64/rockchip/rk3588-friendlyelec-cm3588-nas.dts 
b/dts/upstream/src/arm64/rockchip/rk3588-friendlyelec-cm3588-nas.dts
new file mode 100644
index ..83103e4c7216
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3588-friendlyelec-cm3588-nas.dts
@@ -0,0 +1,778 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ * Copyright (c) 2023 Thomas McKahan
+ * Copyright (c) 2024 Sebastian Kropatsch
+ *
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include 
+#include "rk3588-friendlyelec-cm3588.dtsi"
+
+/ {
+   model = "FriendlyElec CM3588 NAS";
+   compatible = "friendlyarm,cm3588-nas", "friendlyarm,cm3588", 
"rockchip,rk3588";
+
+   adc_key_recovery: adc-key-recovery {
+   compatible = "adc-keys";
+   io-channels = <&saradc 1>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+   poll-interval = <100>;
+
+   button-recovery {
+   label = "Recovery";
+   linux,code = ;
+   press-threshold-microvolt = <17000>;
+   };
+   };
+
+   analog-sound {
+   compatible = "simple-audio-card";
+   pinctrl-names = "default";
+   pinctrl-0 = <&headphone_detect>;
+
+   simple-audio-card,format = "i2s";
+   simple-audio-card,hp-det-gpio = <&gpio1 RK_PC4 GPIO_ACTIVE_LOW>;
+   simple-audio-card,mclk-fs = <256>;
+   simple-audio-card,name = "realtek,rt5616-codec";
+
+   simple-audio-card,routing =
+   "Headphones", "HPOL",
+   "Headphones", "HPOR",
+   "MIC1", "Microphone Jack",
+   "Microphone Jack", "micbias1";
+   simple-audio-card,widgets =
+   "Headphone", "Headphones",
+   "Microphone", "Microphone Jack";
+
+   simple-audio-card,cpu {
+   sound-dai = <&i2s0_8ch>;
+   };
+
+   simple-audio-card,codec {
+   sound-dai = <&rt5616>;
+   };
+   };
+
+   buzzer: pwm-beeper {
+   compatible = "pwm-beeper";
+   amp-supply = <&vcc_5v0_sys>;
+   beeper-hz = <500>;
+   pwms = <&pwm8 0 50 0>;
+   };
+
+   fan: pwm-fan {
+   compatible = "pwm-fan";
+   #cooling-cells = <2>;
+   

[PATCH 0/2] board: rockchip: Add FriendlyElec CM3588 NAS

2024-07-31 Thread Jonas Karlman
This series add support for the RK3588 based FriendlyElec CM3588 NAS
board.

Features tested on a CM3588 NAS Kit with 8GB RAM 64GB eMMC module:
- SD-card boot
- eMMC boot
- Ethernet
- PCIe/NVMe
- USB gadget
- USB host

Jonas Karlman (1):
  board: rockchip: Add FriendlyElec CM3588 NAS

Sebastian Kropatsch (1):
  arm64: dts: rockchip: Add FriendlyElec CM3588 NAS board

 ...rk3588-friendlyelec-cm3588-nas-u-boot.dtsi |   8 +
 arch/arm/mach-rockchip/rk3588/Kconfig |  24 +
 board/friendlyelec/cm3588-nas-rk3588/Kconfig  |  12 +
 .../cm3588-nas-rk3588/MAINTAINERS |   6 +
 configs/cm3588-nas-rk3588_defconfig   |  90 ++
 doc/board/rockchip/rockchip.rst   |   1 +
 .../rk3588-friendlyelec-cm3588-nas.dts| 778 ++
 .../rockchip/rk3588-friendlyelec-cm3588.dtsi  | 653 +++
 8 files changed, 1572 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-friendlyelec-cm3588-nas-u-boot.dtsi
 create mode 100644 board/friendlyelec/cm3588-nas-rk3588/Kconfig
 create mode 100644 board/friendlyelec/cm3588-nas-rk3588/MAINTAINERS
 create mode 100644 configs/cm3588-nas-rk3588_defconfig
 create mode 100644 
dts/upstream/src/arm64/rockchip/rk3588-friendlyelec-cm3588-nas.dts
 create mode 100644 
dts/upstream/src/arm64/rockchip/rk3588-friendlyelec-cm3588.dtsi

-- 
2.45.2



Re: [PATCH 4/4] board: rockchip: Add Radxa ROCK 5 ITX

2024-07-31 Thread Jonas Karlman
ot;board/theobroma-systems/jaguar_rk3588/Kconfig"
> diff --git a/board/radxa/rock-5-itx-rk3588/Kconfig 
> b/board/radxa/rock-5-itx-rk3588/Kconfig
> new file mode 100644
> index 000..f7a7666d531
> --- /dev/null
> +++ b/board/radxa/rock-5-itx-rk3588/Kconfig
> @@ -0,0 +1,12 @@
> +if TARGET_ROCK_5_ITX_RK3588
> +
> +config SYS_BOARD
> + default "rock-5-itx-rk3588"
> +
> +config SYS_VENDOR
> + default "radxa"
> +
> +config SYS_CONFIG_NAME
> + default "rock-5-itx-rk3588"
> +
> +endif
> diff --git a/board/radxa/rock-5-itx-rk3588/MAINTAINERS 
> b/board/radxa/rock-5-itx-rk3588/MAINTAINERS
> new file mode 100644
> index 000..297b0676ddf
> --- /dev/null
> +++ b/board/radxa/rock-5-itx-rk3588/MAINTAINERS
> @@ -0,0 +1,7 @@
> +ROCK-5-ITX-RK3588
> +M:   Heiko Stuebner 

Feel free to add me as a reviewer of this board:

R:  Jonas Karlman 

> +S:   Maintained
> +F:   board/radxa/rock-5-itx-rk3588
> +F:   include/configs/rock-5-itx-rk3588.h
> +F:   configs/rock-5-itx-rk3588_defconfig
> +F:   arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi
> diff --git a/configs/rock-5-itx-rk3588_defconfig 
> b/configs/rock-5-itx-rk3588_defconfig
> new file mode 100644
> index 000..2a41642245b
> --- /dev/null
> +++ b/configs/rock-5-itx-rk3588_defconfig
> @@ -0,0 +1,104 @@
> +CONFIG_ARM=y
> +CONFIG_SKIP_LOWLEVEL_INIT=y
> +CONFIG_SYS_HAS_NONCACHED_MEMORY=y
> +CONFIG_COUNTER_FREQUENCY=2400
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SF_DEFAULT_SPEED=2400
> +CONFIG_SF_DEFAULT_MODE=0x2000
> +CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3588-rock-5-itx"
> +CONFIG_ROCKCHIP_RK3588=y
> +CONFIG_ROCKCHIP_SPI_IMAGE=y
> +CONFIG_SPL_SERIAL=y
> +CONFIG_TARGET_ROCK5B_RK3588=y
> +CONFIG_DEBUG_UART_BASE=0xFEB5
> +CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_SPL_SPI_FLASH_SUPPORT=y
> +CONFIG_SPL_SPI=y
> +CONFIG_SYS_LOAD_ADDR=0xc00800
> +CONFIG_PCI=y
> +CONFIG_DEBUG_UART=y
> +CONFIG_AHCI=y
> +CONFIG_FIT=y
> +CONFIG_FIT_VERBOSE=y
> +CONFIG_SPL_FIT_SIGNATURE=y
> +CONFIG_SPL_LOAD_FIT=y
> +CONFIG_LEGACY_IMAGE_FORMAT=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-rock-5-itx.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_MAX_SIZE=0x4
> +CONFIG_SPL_PAD_TO=0x7f8000
> +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
> +CONFIG_SPL_SPI_LOAD=y
> +CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
> +CONFIG_SPL_ATF=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_PCI=y
> +CONFIG_CMD_USB=y
> +CONFIG_CMD_ROCKUSB=y

Suggest you also add support for the UMS cmd:

CONFIG_CMD_USB_MASS_STORAGE=y

> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_REGULATOR=y
> +# CONFIG_SPL_DOS_PARTITION is not set
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_OF_LIVE=y
> +CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
> assigned-clock-rates assigned-clock-parents"

Suggest you add following:

CONFIG_SYS_RELOC_GD_ENV_ADDR=y

Still not fully sure what this option really affect but have started
adding it to new boards to closer match older rk33xx boards:


> +CONFIG_SPL_DM_SEQ_ALIAS=y
> +CONFIG_SPL_REGMAP=y
> +CONFIG_SPL_SYSCON=y
> +CONFIG_AHCI_PCI=y
> +CONFIG_DWC_AHCI=y
> +CONFIG_SPL_CLK=y
> +# CONFIG_USB_FUNCTION_FASTBOOT is not set
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y

If we want to control the leds in U-Boot:

CONFIG_LED=y
CONFIG_LED_GPIO=y

> +CONFIG_MISC=y
> +CONFIG_SUPPORT_EMMC_RPMB=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_SDMA=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_SF_DEFAULT_BUS=5
> +CONFIG_SPI_FLASH_SFDP_SUPPORT=y
> +CONFIG_SPI_FLASH_MACRONIX=y
> +CONFIG_SPI_FLASH_XTX=y
> +CONFIG_PHYLIB=y
> +CONFIG_RTL8169=y
> +CONFIG_NVME_PCI=y
> +CONFIG_PCIE_DW_ROCKCHIP=y
> +CONFIG_PHY_ROCKCHIP_INNO_USB2=y
> +CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
> +CONFIG_PHY_ROCKCHIP_USBDP=y
> +CONFIG_SPL_PINCTRL=y

The rk8xx driver support the PMIC used on this board,
suggest you add following:

CONFIG_DM_PMIC=y
CONFIG_PMIC_RK8XX=y
CONFIG_REGULATOR_RK8XX=y

> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_SPL_RAM=y
> +CONFIG_SCSI=y
> +CONFIG_BAUDRATE=150
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYS_NS16550_MEM32=y
> +CONFIG_ROCKCHIP_SFC=y

The PMIC use SPI:

CONFIG_ROCKCHIP_SPI=y

> +CONFIG_SYSRESET=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_OHCI_GENERIC=y
> +CONFIG_USB_DWC3=y
> +CONFIG_USB_DWC3_GENERIC=y
> +CONFIG_SPL_USB_DWC3_GENERIC=y

This can probably be dropped, there is no usb node incl

Re: [PATCH] arm: dts: orangepi: Fix Orange Pi R1 and Plus LTS boot issue

2024-07-31 Thread Jonas Karlman
Hi,

On 2024-07-31 13:49, Pugemon wrote:
> Orange Pi R1 Plus and LTS don't have eMMC
> (default mmc0 in rk3328-u-boot.dtsi).
> The device is equipped with SPI flash memory, which U-Boot tries to use for
> reading configuration. However, the manufacturer has not provided any means
> to utilize SPI flash memory. There is no documentation,
> or software available for this purpose.

The U-Boot documentation contain limited information on how you can
write the generated rockchip-u-boot-spi.bin to SPI flash, after that it
will load U-Boot from the SPI flash instead.

https://docs.u-boot.org/en/latest/board/rockchip/rockchip.html#spi

> 
> As a result, during OpenWRT sysupgrade, the board fails to boot because the
> script that switches the boot_device to an available one does not trigger.

This sounds more like an issue in your script?

> 
> This patch changes the alias of mmc0 from &emmc to &sdmmc,
> ensuring the board boots correctly,
> and sysupgrade completes successfully.

There are aspects of the rockchip U-Boot code that depend on that mmc0
is emmc and mmc1 is sdmmc, so this change may introduce new issues and
should be avoided.

I have no issues booting my OrangePi R1 Plus LTS without this. Please
explain what the issue is and what script you are referring too. Is this
a U-Boot script or linux userspace script? also what version of U-Boot
have you had issue with? Does your SPI flash come with a vendor U-Boot
that is interfering with your sysupdate?

> Additionally, this allows saving the U-Boot environment
> by using saveenv with uboot-envtool.

U-Boot will expect the environment on the mmc device that U-Boot was
loaded from, and fallback on what U-Boot consider is the SD-card (mmc1).

saveenv from U-Boot CLI should work as intended and already save the env
to the sdmmc, unless there is other issues/modifications in your U-Boot.

So this may also be an issue in userspace tool?

> 
> Signed-off-by: Pugemon 
> Cc: Tianling Shen 
> ---
>  arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi | 12 
>  arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi | 12 
>  2 files changed, 24 insertions(+)
> 
> diff --git a/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
> b/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
> index b50c1332b8..7063b188f2 100644
> --- a/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
> +++ b/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
> @@ -2,11 +2,23 @@
>  /*
>   * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
>   * (C) Copyright 2020 David Bauer
> + * (C) Copyright 2024 Pugemon
>   */
> 
>  #include "rk3328-u-boot.dtsi"
>  #include "rk3328-sdram-lpddr3-666.dtsi"
> 
> +/ {
> +   aliases {
> +   mmc0 = &sdmmc;
> +   spi0 = &spi0;

This is already defined in rk3328-u-boot.dtsi, no need to re-define it
here.

> +   };
> +
> +   chosen {
> +   u-boot,spl-boot-order = "same-as-spl", &sdmmc;

It should not be needed to change this, if the emmc node is disabled
U-Boot should just skip it. Also the "same-as-spl" should already
refer to the SPI flash or the SD-card depending on where TPL/SPL
was loaded from.

> +   };
> +};
> +
>  &spi0 {
> flash@0 {
> bootph-pre-ram;
> diff --git a/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
> b/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
> index 8ae003bbef..0374172527 100644
> --- a/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
> +++ b/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
> @@ -2,11 +2,23 @@
>  /*
>   * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
>   * (C) Copyright 2020 David Bauer
> + * (C) Copyright 2024 Pugemon
>   */
> 
>  #include "rk3328-u-boot.dtsi"
>  #include "rk3328-sdram-ddr4-666.dtsi"
> 
> +/ {
> +   aliases {
> +   mmc0 = &sdmmc;
> +   spi0 = &spi0;

Same as above.

> +   };
> +
> +   chosen {
> +   u-boot,spl-boot-order = "same-as-spl", &sdmmc;

Same as above.

Regards,
Jonas

> +   };
> +};
> +
>  &spi0 {
> flash@0 {
> bootph-pre-ram;



Re: [PATCH v7 8/8] rockchip: Avoid #ifdefs in RK3399 SPL

2024-07-31 Thread Jonas Karlman
Hi Simon,

On 2024-07-31 16:49, Simon Glass wrote:
> The code here is confusing due to large blocks which are #ifdefed out.
> Add a function phase_sdram_init() which returns whether SDRAM init
> should happen in the current phase, using that as needed to control the
> code flow.
> 
> This increases code size by about 500 bytes in SPL when the cache is on,
> since it must call the rather large rockchip_sdram_size() function.

I am guessing this size increase only is related to kevin/bob since all
other RK3399 boards already use rockchip_sdram_size() in SPL.

> 
> - Drop the non-dcache optimisation, since the cache should normally be on

Is this referencing to something that is still done in this patch?

> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v5)
> 
> Changes in v5:
> - Move setting of pmugrf into the probe() function
> - Drop patches previously applied
> 
> Changes in v4:
> - Fix 'stating' typo
> - Move Binman size feature to a separate series
> 
> Changes in v3:
> - Split out the refactoring into a separate patch
> 
> Changes in v2:
> - Drop patch "regulator: rk8xx: Fix incorrect parameter"
> - Rewrite boneblack patch to onstead drop the target and update docs
> 
>  drivers/ram/rockchip/sdram_rk3399.c | 33 ++---
>  1 file changed, 16 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/ram/rockchip/sdram_rk3399.c 
> b/drivers/ram/rockchip/sdram_rk3399.c
> index bc79c034808..8a7cbb1849f 100644
> --- a/drivers/ram/rockchip/sdram_rk3399.c
> +++ b/drivers/ram/rockchip/sdram_rk3399.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -63,8 +64,6 @@ struct chan_info {
>  };
>  
>  struct dram_info {
> -#if defined(CONFIG_TPL_BUILD) || \
> - (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
>   u32 pwrup_srefresh_exit[2];
>   struct chan_info chan[2];
>   struct clk ddr_clk;
> @@ -75,7 +74,6 @@ struct dram_info {
>   struct rk3399_pmusgrf_regs *pmusgrf;
>   struct rk3399_ddr_cic_regs *cic;
>   const struct sdram_rk3399_ops *ops;
> -#endif
>   struct ram_info info;
>   struct rk3399_pmugrf_regs *pmugrf;
>  };
> @@ -92,9 +90,6 @@ struct sdram_rk3399_ops {
>   struct rk3399_sdram_params *params);
>  };
>  
> -#if defined(CONFIG_TPL_BUILD) || \
> - (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
> -
>  struct rockchip_dmc_plat {
>  #if CONFIG_IS_ENABLED(OF_PLATDATA)
>   struct dtd_rockchip_rk3399_dmc dtplat;
> @@ -191,6 +186,17 @@ struct io_setting {
>   },
>  };
>  
> +/**
> + * phase_sdram_init() - Check if this is the phase where SDRAM init happens
> + *
> + * Returns: true to do SDRAM init in this phase, false to not
> + */
> +static bool phase_sdram_init(void)
> +{
> + return spl_phase() == PHASE_TPL ||
> + (!IS_ENABLED(CONFIG_TPL) && !spl_in_proper());

This is still wrong, please consider ROCKCHIP_EXTERNAL_TPL or this
function fail to do what you document it to do.

See our prior thread about this:
https://lore.kernel.org/u-boot/caflszthg5xohr-9agsmhvrw5dp_tn39nc7rq1z4zmnqoqqj...@mail.gmail.com/

Regards,
Jonas

> +}
> +
>  static struct io_setting *
>  lpddr4_get_io_settings(const struct rk3399_sdram_params *params, u32 mr5)
>  {
> @@ -3024,7 +3030,7 @@ static int rk3399_dmc_of_to_plat(struct udevice *dev)
>   struct rockchip_dmc_plat *plat = dev_get_plat(dev);
>   int ret;
>  
> - if (!CONFIG_IS_ENABLED(OF_REAL))
> + if (!CONFIG_IS_ENABLED(OF_REAL) || !phase_sdram_init())
>   return 0;
>  
>   ret = dev_read_u32_array(dev, "rockchip,sdram-params",
> @@ -3093,7 +3099,6 @@ static int rk3399_dmc_init(struct udevice *dev)
>   priv->cic = syscon_get_first_range(ROCKCHIP_SYSCON_CIC);
>   priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
>   priv->pmu = syscon_get_first_range(ROCKCHIP_SYSCON_PMU);
> - priv->pmugrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
>   priv->pmusgrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUSGRF);
>   priv->pmucru = rockchip_get_pmucru();
>   priv->cru = rockchip_get_cru();
> @@ -3138,19 +3143,16 @@ static int rk3399_dmc_init(struct udevice *dev)
>  
>   return 0;
>  }
> -#endif
>  
>  static int rk3399_dmc_probe(struct udevice *dev)
>  {
>   struct dram_info *priv = dev_get_priv(dev);
>  
> -#if defined(CONFIG_TPL_BUILD) || \
> - (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
> - if (rk3399_dmc_init(dev))
> - return 0;
> -#endif
>   priv->pmugrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
>   debug("%s: pmugrf = %p\n", __func__, priv->pmugrf);
> + if (phase_sdram_init() && rk3399_dmc_init(dev))
> + return 0;
> +
>   priv->info.base = CFG_SYS_SDRAM_BASE;
>   priv->info.size =
>   rockchip_sdram_size((phys_addr_t)&priv->pmugrf->os_reg2);
> @@ -3181,10 +3183,7 @@ U_BOOT_DRIVER(dmc_rk3399) = {
>   .id = UCLASS_RAM,
>   

Re: [PATCH 2/2] board: rockchip: Add Xunlong Orange Pi 3B

2024-07-31 Thread Jonas Karlman
Hi Quentin,

On 2024-07-31 14:56, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 7/31/24 11:03 AM, Jonas Karlman wrote:
>  > From: Ricardo Pardini 
>  >
>  > The Xunlong Orange Pi 3B is a single-board computer based on the
>  > Rockchip RK3566 SoC.
>  >
>  > The two hw revisions use different io-voltage for Ethernet PHY and can
>  > be identified using GPIO4_C4:
>  > - v1.1.1: x (internal pull-down)
>  > - v2.1:   PHY_RESET (external pull-up)
>  >
>  > Implement rk_board_late_init() to set correct fdtfile env var and
>  > board_fit_config_name_match() to load correct FIT config based on what
>  > board is detected at runtime so a single board target can be used for
>  > both hw revisions.
>  >
>  > Minimal DTs that includ DT from dts/upstream is added to support booting
>  > from both hw revision and only set Ethernet PHY io-voltage when the hw
>  > revision is detected at runtime. A side-affect of this is that defconfig
>  > show OF_UPSTREAM=n, however dts/upstream DTs is used for this board.
>  >
>  > Features tested on Orange Pi 3B 4GB (v1.1.1 and v2.1):
>  > - SD-card boot
>  > - eMMC boot
>  > - SPI Flash boot
>  > - Ethernet
>  > - PCIe/NVMe
>  > - USB host
>  >
>  > Signed-off-by: Ricardo Pardini 
>  > Co-developed-by: Jonas Karlman 
>  > Signed-off-by: Jonas Karlman 
>  > ---
>  >   arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi   | 14 +++
>  >   .../dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi   |  3 +
>  >   arch/arm/dts/rk3566-orangepi-3b-v1.1.dts  |  3 +
>  >   .../dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi   |  3 +
>  >   arch/arm/dts/rk3566-orangepi-3b-v2.1.dts  |  3 +
>  >   arch/arm/dts/rk3566-orangepi-3b.dts   |  5 +
>  >   arch/arm/mach-rockchip/rk3568/Kconfig |  6 ++
>  >   board/xunlong/orangepi-3b-rk3566/Kconfig  | 12 +++
>  >   board/xunlong/orangepi-3b-rk3566/MAINTAINERS  |  6 ++
>  >   board/xunlong/orangepi-3b-rk3566/Makefile |  3 +
>  >   .../orangepi-3b-rk3566/orangepi-3b-rk3566.c   | 77 +++
>  >   configs/orangepi-3b-rk3566_defconfig  | 98 +++
>  >   doc/board/rockchip/rockchip.rst   |  1 +
>  >   13 files changed, 234 insertions(+)
>  >   create mode 100644 arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi
>  >   create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi
>  >   create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v1.1.dts
>  >   create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi
>  >   create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v2.1.dts
>  >   create mode 100644 arch/arm/dts/rk3566-orangepi-3b.dts
>  >   create mode 100644 board/xunlong/orangepi-3b-rk3566/Kconfig
>  >   create mode 100644 board/xunlong/orangepi-3b-rk3566/MAINTAINERS
>  >   create mode 100644 board/xunlong/orangepi-3b-rk3566/Makefile
>  >   create mode 100644 board/xunlong/orangepi-3b-rk3566/orangepi-3b-rk3566.c
>  >   create mode 100644 configs/orangepi-3b-rk3566_defconfig
>  >
>  > diff --git a/arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi 
> b/arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi
>  > new file mode 100644
>  > index ..e44b699af720
>  > --- /dev/null
>  > +++ b/arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi
>  > @@ -0,0 +1,14 @@
>  > +// SPDX-License-Identifier: GPL-2.0+
>  > +
>  > +#include "rk356x-u-boot.dtsi"
>  > +
>  > +&gpio4 {
>  > + bootph-pre-ram;
>  > +};
>  > +
>  > +&sfc {
>  > + flash@0 {
>  > + bootph-pre-ram;
>  > + bootph-some-ram;
>  > + };
>  > +};
>  > diff --git a/arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi 
> b/arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi
>  > new file mode 100644
>  > index ..50ea6ede7285
>  > --- /dev/null
>  > +++ b/arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi
>  > @@ -0,0 +1,3 @@
>  > +// SPDX-License-Identifier: GPL-2.0+
>  > +
>  > +#include "rk3566-orangepi-3b-u-boot.dtsi"
>  > diff --git a/arch/arm/dts/rk3566-orangepi-3b-v1.1.dts 
> b/arch/arm/dts/rk3566-orangepi-3b-v1.1.dts
>  > new file mode 100644
>  > index ..f97e33bd8108
>  > --- /dev/null
>  > +++ b/arch/arm/dts/rk3566-orangepi-3b-v1.1.dts
>  > @@ -0,0 +1,3 @@
>  > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>  > +
>  > +#include 
>  > diff --git a/arch/arm/dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi 
> b/arch/arm/dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi
>  > new file mode 100644
>  > in

Re: [PATCH 4/5] dm: adc: Add SPL_ADC Kconfig symbol for use of ADC in SPL

2024-07-31 Thread Jonas Karlman
Hi Quentin,

On 2024-07-31 14:42, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 7/31/24 8:50 AM, Jonas Karlman wrote:
>  > What model of Radxa ZERO 3W/3E boards can be identified using ADC at
>  > runtime, add a Kconfig symbol to allow use of ADC in SPL.
>  >
>  > This will be used to identify board model in SPL to allow loading
>  > correct FIT configuration and FDT for U-Boot proper at SPL phase.
>  >
>  > Signed-off-by: Jonas Karlman 
>  > ---
>  >   drivers/Makefile| 2 +-
>  >   drivers/adc/Kconfig | 4 
>  >   2 files changed, 5 insertions(+), 1 deletion(-)
>  >
>  > diff --git a/drivers/Makefile b/drivers/Makefile
>  > index 9195dafd37e0..1acd94f3c17e 100644
>  > --- a/drivers/Makefile
>  > +++ b/drivers/Makefile
>  > @@ -1,5 +1,6 @@
>  >   # SPDX-License-Identifier: GPL-2.0+
>  >
>  > +obj-$(CONFIG_$(SPL_TPL_)ADC) += adc/
>  >   obj-$(CONFIG_$(SPL_TPL_)BIOSEMU) += bios_emulator/
>  >   obj-$(CONFIG_$(SPL_TPL_)BLK) += block/
>  >   obj-$(CONFIG_$(SPL_TPL_)BOOTCOUNT_LIMIT) += bootcount/
>  > @@ -81,7 +82,6 @@ endif
>  >
>  >   ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
>  >
>  > -obj-y += adc/
>  >   obj-y += ata/
>  >   obj-$(CONFIG_DM_DEMO) += demo/
>  >   obj-y += block/
>  > diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
>  > index c9cdbe6942de..eb705f9e0fb8 100644
>  > --- a/drivers/adc/Kconfig
>  > +++ b/drivers/adc/Kconfig
>  > @@ -11,6 +11,10 @@ config ADC
>  >  - support supply's phandle with auto-enable
>  >  - supply polarity setting in fdt
>  >
>  > +config SPL_ADC
>  > + bool "Enable ADC drivers using Driver Model in SPL"
>  > + depends on ADC
>  > +
> 
> This is just because you didn't modify the drivers/adc/Makefile to have
> obj-$(CONFIG_$(SPL_TPL_)ADC) += adc-uclass.o
> I assume? It's a bit odd to require a "proper" symbol for an SPL symbol.
> 
> Additionally, since you use $(SPL_TPL_) maybe add that TPL symbol too in
> the Kconfig?

Agree, this could have been done differently, I added the depends on ADC
a few minutes before I send the series to ensure next user of ADC in SPL
does not miss it.

The use of $(SPL_TPL_) was to follow rest of the Makefile, and there
are plenty of other places where this is used and a symbol is missing.
Also this helps when next user would like to use ADC in TPL, only the
Kconfig symbol needs to be added.

> 
> Finally, I think it'd be best to have symbols for SPL and TPL for the
> drivers as well and update the Makefile to use $(SPL_TPL_) for those as
> well. I don't see this as being a big issue for ADC specifically right
> now but it's been a pain for me for a few other subsystems (power, pmic,
> i2c, spi, IIRC). This isn't a blocker though I believe.

Yeah, lots of drivers/subsections could use an update to have more
consistency.

For this series I only wanted to include bare minimum change to make it
possible to use adc_channel_single_shot() in SPL to figure out what FIT
config to use.

Full Makefile and Kconfig cleanup should probably be done in a separate
series.

> 
> On a side note, I'm wondering if we're not missing a depends on DM for
> CONFIG_ADC by any chance? c.f. the config option title: "Enable ADC
> drivers using Driver Model"

Probably, guessing no target is using ADC without DM at the moment.

Regards,
Jonas

> 
> Cheers,
> Quentin



[PATCH 2/2] board: rockchip: Add Xunlong Orange Pi 3B

2024-07-31 Thread Jonas Karlman
From: Ricardo Pardini 

The Xunlong Orange Pi 3B is a single-board computer based on the
Rockchip RK3566 SoC.

The two hw revisions use different io-voltage for Ethernet PHY and can
be identified using GPIO4_C4:
- v1.1.1: x (internal pull-down)
- v2.1:   PHY_RESET (external pull-up)

Implement rk_board_late_init() to set correct fdtfile env var and
board_fit_config_name_match() to load correct FIT config based on what
board is detected at runtime so a single board target can be used for
both hw revisions.

Minimal DTs that includ DT from dts/upstream is added to support booting
from both hw revision and only set Ethernet PHY io-voltage when the hw
revision is detected at runtime. A side-affect of this is that defconfig
show OF_UPSTREAM=n, however dts/upstream DTs is used for this board.

Features tested on Orange Pi 3B 4GB (v1.1.1 and v2.1):
- SD-card boot
- eMMC boot
- SPI Flash boot
- Ethernet
- PCIe/NVMe
- USB host

Signed-off-by: Ricardo Pardini 
Co-developed-by: Jonas Karlman 
Signed-off-by: Jonas Karlman 
---
 arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi   | 14 +++
 .../dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi   |  3 +
 arch/arm/dts/rk3566-orangepi-3b-v1.1.dts  |  3 +
 .../dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi   |  3 +
 arch/arm/dts/rk3566-orangepi-3b-v2.1.dts  |  3 +
 arch/arm/dts/rk3566-orangepi-3b.dts   |  5 +
 arch/arm/mach-rockchip/rk3568/Kconfig |  6 ++
 board/xunlong/orangepi-3b-rk3566/Kconfig  | 12 +++
 board/xunlong/orangepi-3b-rk3566/MAINTAINERS  |  6 ++
 board/xunlong/orangepi-3b-rk3566/Makefile |  3 +
 .../orangepi-3b-rk3566/orangepi-3b-rk3566.c   | 77 +++
 configs/orangepi-3b-rk3566_defconfig  | 98 +++
 doc/board/rockchip/rockchip.rst   |  1 +
 13 files changed, 234 insertions(+)
 create mode 100644 arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v1.1.dts
 create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v2.1.dts
 create mode 100644 arch/arm/dts/rk3566-orangepi-3b.dts
 create mode 100644 board/xunlong/orangepi-3b-rk3566/Kconfig
 create mode 100644 board/xunlong/orangepi-3b-rk3566/MAINTAINERS
 create mode 100644 board/xunlong/orangepi-3b-rk3566/Makefile
 create mode 100644 board/xunlong/orangepi-3b-rk3566/orangepi-3b-rk3566.c
 create mode 100644 configs/orangepi-3b-rk3566_defconfig

diff --git a/arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi 
b/arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi
new file mode 100644
index ..e44b699af720
--- /dev/null
+++ b/arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rk356x-u-boot.dtsi"
+
+&gpio4 {
+   bootph-pre-ram;
+};
+
+&sfc {
+   flash@0 {
+   bootph-pre-ram;
+   bootph-some-ram;
+   };
+};
diff --git a/arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi 
b/arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi
new file mode 100644
index ..50ea6ede7285
--- /dev/null
+++ b/arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rk3566-orangepi-3b-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3566-orangepi-3b-v1.1.dts 
b/arch/arm/dts/rk3566-orangepi-3b-v1.1.dts
new file mode 100644
index ..f97e33bd8108
--- /dev/null
+++ b/arch/arm/dts/rk3566-orangepi-3b-v1.1.dts
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include 
diff --git a/arch/arm/dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi 
b/arch/arm/dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi
new file mode 100644
index ..50ea6ede7285
--- /dev/null
+++ b/arch/arm/dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rk3566-orangepi-3b-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3566-orangepi-3b-v2.1.dts 
b/arch/arm/dts/rk3566-orangepi-3b-v2.1.dts
new file mode 100644
index ..0031e2477abf
--- /dev/null
+++ b/arch/arm/dts/rk3566-orangepi-3b-v2.1.dts
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include 
diff --git a/arch/arm/dts/rk3566-orangepi-3b.dts 
b/arch/arm/dts/rk3566-orangepi-3b.dts
new file mode 100644
index ..44b9a9c89f0b
--- /dev/null
+++ b/arch/arm/dts/rk3566-orangepi-3b.dts
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include 
diff --git a/arch/arm/mach-rockchip/rk3568/Kconfig 
b/arch/arm/mach-rockchip/rk3568/Kconfig
index 0f32f243be4e..899cf909fbb9 100644
--- a/arch/arm/mach-rockchip/rk3568/Kconfig
+++ b/arch/arm/mach-rockchip/rk3568/Kconfig
@@ -37,6 +37,11 @@ config TARGET_RADXA_ZERO_3_RK3566
help
  Radxa ZERO 3W/3E single board computers with a RK3566 SoC.
 
+config TARGET_ORANGEPI_3B_RK3566
+   bool "Xunlong Orange Pi 3B"
+   help
+   

[PATCH 1/2] arm64: dts: rockchip: Add Xunlong Orange Pi 3B

2024-07-31 Thread Jonas Karlman
The Xunlong Orange Pi 3B is a single-board computer based on the
Rockchip RK3566 SoC.

Add initial support for eMMC, SD-card, Ethernet, HDMI, PCIe and USB.

Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240626230319.1425316-3-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: d79d713d602e8b32cf935ddfdf61769cb74ba1dc ]

(cherry picked from commit 9defe71f2674f82c27a8d4593d8c5851ab5d51e7)
---
 .../rockchip/rk3566-orangepi-3b-v1.1.dts  |  29 +
 .../rockchip/rk3566-orangepi-3b-v2.1.dts  |  70 ++
 .../arm64/rockchip/rk3566-orangepi-3b.dtsi| 678 ++
 3 files changed, 777 insertions(+)
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v1.1.dts
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v2.1.dts
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b.dtsi

diff --git a/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v1.1.dts 
b/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v1.1.dts
new file mode 100644
index ..074e93bd4b85
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v1.1.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-orangepi-3b.dtsi"
+
+/ {
+   model = "Xunlong Orange Pi 3B v1.1";
+   compatible = "xunlong,orangepi-3b-v1.1", "xunlong,orangepi-3b", 
"rockchip,rk3566";
+};
+
+&pmu_io_domains {
+   vccio5-supply = <&vcc_3v3>;
+};
+
+&gmac1 {
+   phy-handle = <&rgmii_phy1>;
+   status = "okay";
+};
+
+&mdio1 {
+   rgmii_phy1: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   reset-assert-us = <2>;
+   reset-deassert-us = <5>;
+   reset-gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_LOW>;
+   };
+};
diff --git a/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v2.1.dts 
b/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v2.1.dts
new file mode 100644
index ..d894bff41e61
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v2.1.dts
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-orangepi-3b.dtsi"
+
+/ {
+   model = "Xunlong Orange Pi 3B v2.1";
+   compatible = "xunlong,orangepi-3b-v2.1", "xunlong,orangepi-3b", 
"rockchip,rk3566";
+
+   vccio_phy1: regulator-1v8-vccio-phy {
+   compatible = "regulator-fixed";
+   regulator-name = "vccio_phy1";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-max-microvolt = <180>;
+   regulator-min-microvolt = <180>;
+   };
+};
+
+&pmu_io_domains {
+   vccio5-supply = <&vccio_phy1>;
+};
+
+&gmac1 {
+   phy-handle = <&rgmii_phy1>;
+   status = "okay";
+};
+
+&mdio1 {
+   rgmii_phy1: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   reset-assert-us = <2>;
+   reset-deassert-us = <5>;
+   reset-gpios = <&gpio4 RK_PC4 GPIO_ACTIVE_LOW>;
+   };
+};
+
+&sdmmc1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   brcmf: wifi@1 {
+   compatible = "brcm,bcm43456-fmac", "brcm,bcm4329-fmac";
+   reg = <1>;
+   interrupt-parent = <&gpio0>;
+   interrupts = ;
+   interrupt-names = "host-wake";
+   pinctrl-names = "default";
+   pinctrl-0 = <&wifi_wake_host_h>;
+   };
+};
+
+&uart1 {
+   bluetooth {
+   compatible = "brcm,bcm4345c5";
+   clocks = <&rk809 1>;
+   clock-names = "lpo";
+   interrupt-parent = <&gpio2>;
+   interrupts = ;
+   interrupt-names = "host-wakeup";
+   device-wakeup-gpios = <&gpio2 RK_PC1 GPIO_ACTIVE_HIGH>;
+   shutdown-gpios = <&gpio2 RK_PB7 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&bt_reg_on_h &bt_wake_host_h &host_wake_bt_h>;
+   vbat-supply = <&vcc_3v3>;
+   vddio-supply = <&vcc_1v8>;
+   };
+};
diff --git a/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b.dtsi
new file mode 100644
index ..d539570f531e
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b.dtsi
@@ -0,0 +1

[PATCH 0/2] board: rockchip: Add Xunlong Orange Pi 3B

2024-07-31 Thread Jonas Karlman
This series add support for the RK3566 based Xunlong Orange Pi 3B board.

rk_board_late_init() and board_fit_config_name_match() has been
implemented to set fdtfile env var and load correct FIT config based
on what hw revision is detected at runtime.

It is not possible to build DTs from both arch/arm/dts and dts/upstream
at the same time with OF_UPSTREAM=y, instead minimal DTs that include DT
from dts/upstream is used for this board to work around such issue.

Features tested on Orange Pi 3B 4GB (v1.1.1 and v2.1):
- SD-card boot
- eMMC boot
- SPI Flash boot
- Ethernet
- PCIe/NVMe
- USB host

This series depends on the following patches for a clean apply:
- board: rockchip: add Radxa ROCK 3 Model C [1]
- board: rockchip: Add Radxa ZERO 3W/3E [2]

[1] https://patchwork.ozlabs.org/patch/1963177/
[2] https://patchwork.ozlabs.org/patch/1966895/

Jonas Karlman (1):
  arm64: dts: rockchip: Add Xunlong Orange Pi 3B

Ricardo Pardini (1):
  board: rockchip: Add Xunlong Orange Pi 3B

 arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi   |  14 +
 .../dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi   |   3 +
 arch/arm/dts/rk3566-orangepi-3b-v1.1.dts  |   3 +
 .../dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi   |   3 +
 arch/arm/dts/rk3566-orangepi-3b-v2.1.dts  |   3 +
 arch/arm/dts/rk3566-orangepi-3b.dts   |   5 +
 arch/arm/mach-rockchip/rk3568/Kconfig |   6 +
 board/xunlong/orangepi-3b-rk3566/Kconfig  |  12 +
 board/xunlong/orangepi-3b-rk3566/MAINTAINERS  |   6 +
 board/xunlong/orangepi-3b-rk3566/Makefile |   3 +
 .../orangepi-3b-rk3566/orangepi-3b-rk3566.c   |  77 ++
 configs/orangepi-3b-rk3566_defconfig  |  98 +++
 doc/board/rockchip/rockchip.rst   |   1 +
 .../rockchip/rk3566-orangepi-3b-v1.1.dts  |  29 +
 .../rockchip/rk3566-orangepi-3b-v2.1.dts  |  70 ++
 .../arm64/rockchip/rk3566-orangepi-3b.dtsi| 678 ++
 16 files changed, 1011 insertions(+)
 create mode 100644 arch/arm/dts/rk3566-orangepi-3b-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v1.1-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v1.1.dts
 create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v2.1-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3566-orangepi-3b-v2.1.dts
 create mode 100644 arch/arm/dts/rk3566-orangepi-3b.dts
 create mode 100644 board/xunlong/orangepi-3b-rk3566/Kconfig
 create mode 100644 board/xunlong/orangepi-3b-rk3566/MAINTAINERS
 create mode 100644 board/xunlong/orangepi-3b-rk3566/Makefile
 create mode 100644 board/xunlong/orangepi-3b-rk3566/orangepi-3b-rk3566.c
 create mode 100644 configs/orangepi-3b-rk3566_defconfig
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v1.1.dts
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b-v2.1.dts
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-orangepi-3b.dtsi

-- 
2.45.2



[PATCH 1/2] arm64: dts: rockchip: Add Radxa ROCK 3B

2024-07-31 Thread Jonas Karlman
The Radxa ROCK 3B is a single-board computer based on the Pico-ITX form
factor (100mm x 75mm). Two versions of the ROCK 3B exists, a community
version based on the RK3568 SoC and an industrial version based on the
RK3568J SoC.

Add initial support for eMMC, SD-card, Ethernet, HDMI, PCIe and USB.

Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240627211737.1985549-3-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: 846ef7748fa9124c8eea76e2d5e833fa69b3ef7c ]

(cherry picked from commit 5416329b387d3c13392f84ba35273a402c7010f8)
---
 .../src/arm64/rockchip/rk3568-rock-3b.dts | 781 ++
 1 file changed, 781 insertions(+)
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3568-rock-3b.dts

diff --git a/dts/upstream/src/arm64/rockchip/rk3568-rock-3b.dts 
b/dts/upstream/src/arm64/rockchip/rk3568-rock-3b.dts
new file mode 100644
index ..3d0c1ccfaa79
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3568-rock-3b.dts
@@ -0,0 +1,781 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include 
+#include "rk3568.dtsi"
+
+/ {
+   model = "Radxa ROCK 3B";
+   compatible = "radxa,rock-3b", "rockchip,rk3568";
+
+   aliases {
+   ethernet0 = &gmac0;
+   ethernet1 = &gmac1;
+   mmc0 = &sdhci;
+   mmc1 = &sdmmc0;
+   mmc2 = &sdmmc2;
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   hdmi-con {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
+   ir-receiver {
+   compatible = "gpio-ir-receiver";
+   gpios = <&gpio0 RK_PC2 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pwm3_ir>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&led>;
+
+   led-0 {
+   color = ;
+   default-state = "on";
+   function = LED_FUNCTION_HEARTBEAT;
+   gpios = <&gpio0 RK_PB7 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   /* pi6c pcie clock generator */
+   vcc3v3_pi6c_03: regulator-3v3-vcc-pi6c-03 {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpios = <&gpio0 RK_PD4 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pcie_pwren_h>;
+   regulator-name = "vcc3v3_pi6c_03";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   startup-delay-us = <1>;
+   vin-supply = <&vcc5v0_sys>;
+   };
+
+   vcc3v3_sys: regulator-3v3-vcc-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc5v0_sys>;
+   };
+
+   vcc3v3_sys2: regulator-3v3-vcc-sys2 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys2";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc5v0_sys>;
+   };
+
+   vcc5v0_sys: regulator-5v0-vcc-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   vcc5v0_usb_host: regulator-5v0-vcc-usb-host {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb_host_pwren_h>;
+   regulator-name = "vcc5

[PATCH 2/2] board: rockchip: Add Radxa ROCK 3B

2024-07-31 Thread Jonas Karlman
The Radxa ROCK 3B is a single-board computer based on the Pico-ITX form
factor (100mm x 75mm). Two versions of the ROCK 3B exists, a community
version based on the RK3568 SoC and an industrial version based on the
RK3568J SoC.

Features tested on ROCK 3B 8GB v1.51 (both variants):
- SD-card boot
- eMMC boot
- SPI Flash boot
- Ethernet
- PCIe/NVMe
- USB gadget
- USB host

Signed-off-by: Jonas Karlman 
---
 arch/arm/dts/rk3568-rock-3b-u-boot.dtsi |  15 
 board/rockchip/evb_rk3568/MAINTAINERS   |   6 ++
 configs/rock-3b-rk3568_defconfig| 100 
 doc/board/rockchip/rockchip.rst |   3 +-
 4 files changed, 123 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3568-rock-3b-u-boot.dtsi
 create mode 100644 configs/rock-3b-rk3568_defconfig

diff --git a/arch/arm/dts/rk3568-rock-3b-u-boot.dtsi 
b/arch/arm/dts/rk3568-rock-3b-u-boot.dtsi
new file mode 100644
index ..b1f324282bac
--- /dev/null
+++ b/arch/arm/dts/rk3568-rock-3b-u-boot.dtsi
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+&sdhci {
+   mmc-hs400-1_8v;
+   mmc-hs400-enhanced-strobe;
+};
+
+&sfc {
+   flash@0 {
+   bootph-pre-ram;
+   bootph-some-ram;
+   };
+};
diff --git a/board/rockchip/evb_rk3568/MAINTAINERS 
b/board/rockchip/evb_rk3568/MAINTAINERS
index ba4884db8e12..588134ecb27a 100644
--- a/board/rockchip/evb_rk3568/MAINTAINERS
+++ b/board/rockchip/evb_rk3568/MAINTAINERS
@@ -70,6 +70,12 @@ F:   configs/rock-3a-rk3568_defconfig
 F: arch/arm/dts/rk3568-rock-3a.dts
 F: arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
 
+ROCK-3B
+M: Jonas Karlman 
+S: Maintained
+F: configs/rock-3b-rk3568_defconfig
+F: arch/arm/dts/rk3568-rock-3b*
+
 ROCK-3C
 M: Jonas Karlman 
 M: Maxim Moskalets 
diff --git a/configs/rock-3b-rk3568_defconfig b/configs/rock-3b-rk3568_defconfig
new file mode 100644
index ..937796811a97
--- /dev/null
+++ b/configs/rock-3b-rk3568_defconfig
@@ -0,0 +1,100 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SF_DEFAULT_SPEED=2400
+CONFIG_SF_DEFAULT_MODE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3568-rock-3b"
+CONFIG_ROCKCHIP_RK3568=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
+CONFIG_SPL_SERIAL=y
+CONFIG_DEBUG_UART_BASE=0xFE66
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_SYS_LOAD_ADDR=0xc00800
+CONFIG_PCI=y
+CONFIG_DEBUG_UART=y
+CONFIG_AHCI=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3568-rock-3b.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_PAD_TO=0x7f8000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
+CONFIG_SPL_ATF=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_POWEROFF=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_ROCKUSB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
+# CONFIG_SPL_DOS_PARTITION is not set
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SCSI_AHCI=y
+CONFIG_AHCI_PCI=y
+CONFIG_SPL_CLK=y
+# CONFIG_USB_FUNCTION_FASTBOOT is not set
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_MISC=y
+CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_SF_DEFAULT_BUS=4
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_XTX=y
+CONFIG_PHY_REALTEK=y
+CONFIG_DWC_ETH_QOS=y
+CONFIG_DWC_ETH_QOS_ROCKCHIP=y
+CONFIG_NVME_PCI=y
+CONFIG_PCIE_DW_ROCKCHIP=y
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_FAN53555=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_SPL_RAM=y
+CONFIG_SCSI=y
+CONFIG_BAUDRATE=150
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550_MEM32=y
+CONFIG_ROCKCHIP_SFC=y
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GENERIC=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB_FUNCTION_ROCKUSB=y
+CONFIG_ERRNO_STR=y
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index eadca0ceb2a5..3febebd0b830 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -118,7 +118,8 @@ List of mainline supported Rockchip board

[PATCH 0/2] board: rockchip: Add Radxa ROCK 3B

2024-07-31 Thread Jonas Karlman
This series add support for the RK3568(J) based Radxa ROCK 3B boards.

Features tested on ROCK 3B 8GB v1.51 (both variants):
- SD-card boot
- eMMC boot
- SPI Flash boot
- Ethernet
- PCIe/NVMe
- USB gadget
- USB host

Jonas Karlman (2):
  arm64: dts: rockchip: Add Radxa ROCK 3B
  board: rockchip: Add Radxa ROCK 3B

 arch/arm/dts/rk3568-rock-3b-u-boot.dtsi   |  15 +
 board/rockchip/evb_rk3568/MAINTAINERS |   6 +
 configs/rock-3b-rk3568_defconfig  | 100 +++
 doc/board/rockchip/rockchip.rst   |   3 +-
 .../src/arm64/rockchip/rk3568-rock-3b.dts | 781 ++
 5 files changed, 904 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3568-rock-3b-u-boot.dtsi
 create mode 100644 configs/rock-3b-rk3568_defconfig
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3568-rock-3b.dts

-- 
2.45.2



[PATCH 5/5] board: rockchip: Add Radxa ZERO 3W/3E

2024-07-30 Thread Jonas Karlman
The Radxa ZERO 3W/3E is an ultra-small, high-performance single board
computer based on the Rockchip RK3566, with a compact form factor and
rich interfaces.

Implement rk_board_late_init() to set correct fdtfile env var and
board_fit_config_name_match() to load correct FIT config based on what
board is detected at runtime so a single board target can be used for
both board models.

Features tested on a ZERO 3W 8GB v1.11:
- SD-card boot
- eMMC boot
- USB gadget
- USB host

Features tested on a ZERO 3E 4GB v1.2:
- SD-card boot
- Ethernet
- USB gadget
- USB host

Signed-off-by: Jonas Karlman 
---
 arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi | 11 +++
 arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi | 11 +++
 arch/arm/mach-rockchip/rk3568/Kconfig |  6 ++
 board/radxa/zero3-rk3566/Kconfig  | 12 +++
 board/radxa/zero3-rk3566/MAINTAINERS  |  6 ++
 board/radxa/zero3-rk3566/Makefile |  3 +
 board/radxa/zero3-rk3566/zero3-rk3566.c   | 59 +
 configs/radxa-zero-3-rk3566_defconfig | 85 +++
 doc/board/rockchip/rockchip.rst   |  1 +
 9 files changed, 194 insertions(+)
 create mode 100644 arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi
 create mode 100644 board/radxa/zero3-rk3566/Kconfig
 create mode 100644 board/radxa/zero3-rk3566/MAINTAINERS
 create mode 100644 board/radxa/zero3-rk3566/Makefile
 create mode 100644 board/radxa/zero3-rk3566/zero3-rk3566.c
 create mode 100644 configs/radxa-zero-3-rk3566_defconfig

diff --git a/arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi 
b/arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi
new file mode 100644
index ..4025f5097af5
--- /dev/null
+++ b/arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+&saradc {
+   bootph-pre-ram;
+};
+
+&vcca_1v8 {
+   bootph-pre-ram;
+};
diff --git a/arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi 
b/arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi
new file mode 100644
index ..4025f5097af5
--- /dev/null
+++ b/arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+&saradc {
+   bootph-pre-ram;
+};
+
+&vcca_1v8 {
+   bootph-pre-ram;
+};
diff --git a/arch/arm/mach-rockchip/rk3568/Kconfig 
b/arch/arm/mach-rockchip/rk3568/Kconfig
index 014ebf9f0ba7..0f32f243be4e 100644
--- a/arch/arm/mach-rockchip/rk3568/Kconfig
+++ b/arch/arm/mach-rockchip/rk3568/Kconfig
@@ -32,6 +32,11 @@ config TARGET_QUARTZ64_RK3566
help
  Pine64 Quartz64 single board computer with a RK3566 SoC.
 
+config TARGET_RADXA_ZERO_3_RK3566
+   bool "Radxa ZERO 3W/3E"
+   help
+ Radxa ZERO 3W/3E single board computers with a RK3566 SoC.
+
 endchoice
 
 config ROCKCHIP_BOOT_MODE_REG
@@ -54,5 +59,6 @@ source "board/anbernic/rgxx3_rk3566/Kconfig"
 source "board/hardkernel/odroid_m1/Kconfig"
 source "board/pine64/quartz64_rk3566/Kconfig"
 source "board/powkiddy/x55/Kconfig"
+source "board/radxa/zero3-rk3566/Kconfig"
 
 endif
diff --git a/board/radxa/zero3-rk3566/Kconfig b/board/radxa/zero3-rk3566/Kconfig
new file mode 100644
index ..7d46efc9c40f
--- /dev/null
+++ b/board/radxa/zero3-rk3566/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_RADXA_ZERO_3_RK3566
+
+config SYS_BOARD
+   default "zero3-rk3566"
+
+config SYS_VENDOR
+   default "radxa"
+
+config SYS_CONFIG_NAME
+   default "evb_rk3568"
+
+endif
diff --git a/board/radxa/zero3-rk3566/MAINTAINERS 
b/board/radxa/zero3-rk3566/MAINTAINERS
new file mode 100644
index 00000000..e5a5d856113d
--- /dev/null
+++ b/board/radxa/zero3-rk3566/MAINTAINERS
@@ -0,0 +1,6 @@
+RADXA-ZERO-3-RK3566
+M: Jonas Karlman 
+S: Maintained
+F: board/radxa/zero3-rk3566
+F: configs/radxa-zero-3-rk3566_defconfig
+F: arch/arm/dts/rk3566-radxa-zero-3*
diff --git a/board/radxa/zero3-rk3566/Makefile 
b/board/radxa/zero3-rk3566/Makefile
new file mode 100644
index ..b28b58ed5d87
--- /dev/null
+++ b/board/radxa/zero3-rk3566/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += zero3-rk3566.o
diff --git a/board/radxa/zero3-rk3566/zero3-rk3566.c 
b/board/radxa/zero3-rk3566/zero3-rk3566.c
new file mode 100644
index ..cf30c4e38987
--- /dev/null
+++ b/board/radxa/zero3-rk3566/zero3-rk3566.c
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+
+#define HW_ID_CHANNEL  1
+
+struct board_model {
+   unsigned int low;
+   unsigned int high;
+   const char *fdtfile;
+};
+
+static const struct board_model board_models[] = {
+   { 230, 270, "rockchip/rk3566-radxa-zero-3w.dtb" },
+   { 400, 450, "rockchip/rk3566-radxa

[PATCH 4/5] dm: adc: Add SPL_ADC Kconfig symbol for use of ADC in SPL

2024-07-30 Thread Jonas Karlman
What model of Radxa ZERO 3W/3E boards can be identified using ADC at
runtime, add a Kconfig symbol to allow use of ADC in SPL.

This will be used to identify board model in SPL to allow loading
correct FIT configuration and FDT for U-Boot proper at SPL phase.

Signed-off-by: Jonas Karlman 
---
 drivers/Makefile| 2 +-
 drivers/adc/Kconfig | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 9195dafd37e0..1acd94f3c17e 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0+
 
+obj-$(CONFIG_$(SPL_TPL_)ADC) += adc/
 obj-$(CONFIG_$(SPL_TPL_)BIOSEMU) += bios_emulator/
 obj-$(CONFIG_$(SPL_TPL_)BLK) += block/
 obj-$(CONFIG_$(SPL_TPL_)BOOTCOUNT_LIMIT) += bootcount/
@@ -81,7 +82,6 @@ endif
 
 ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
 
-obj-y += adc/
 obj-y += ata/
 obj-$(CONFIG_DM_DEMO) += demo/
 obj-y += block/
diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
index c9cdbe6942de..eb705f9e0fb8 100644
--- a/drivers/adc/Kconfig
+++ b/drivers/adc/Kconfig
@@ -11,6 +11,10 @@ config ADC
  - support supply's phandle with auto-enable
  - supply polarity setting in fdt
 
+config SPL_ADC
+   bool "Enable ADC drivers using Driver Model in SPL"
+   depends on ADC
+
 config ADC_EXYNOS
bool "Enable Exynos 54xx ADC driver"
depends on ADC
-- 
2.45.2



[PATCH 2/5] arm64: dts: rockchip: fix mmc aliases for Radxa ZERO 3E/3W

2024-07-30 Thread Jonas Karlman
From: FUKAUMI Naoki 

align with other Radxa products.

- mmc0 is eMMC
- mmc1 is microSD

for ZERO 3E, there is no eMMC, but aliases should start at 0, so mmc0
is microSD as exception.

Fixes: 1a5c8d307c83 ("arm64: dts: rockchip: Add Radxa ZERO 3W/3E")
Signed-off-by: FUKAUMI Naoki 

Changes in v3:
- fix syntax error in rk3566-radxa-zero-3e.dts
Changes in v2:
- microSD is mmc0 instead of mmc1 for ZERO 3E

Link: https://lore.kernel.org/r/20240620224435.2752-1-na...@radxa.com
Signed-off-by: Heiko Stuebner 

[ upstream commit: 060c1950037e4c54ca4d8186a8f46269e35db901 ]

(cherry picked from commit 8324bc7493e4088013c62bc41f49d6d181575493)
---
 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi | 4 
 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts | 1 +
 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts | 3 ++-
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
index 623d5939d194..081be841b286 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
@@ -6,10 +6,6 @@
 #include "rk3566.dtsi"
 
 / {
-   aliases {
-   mmc0 = &sdmmc0;
-   };
-
chosen {
stdout-path = "serial2:150n8";
};
diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
index e166d66990b9..4a830eb09f0b 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
@@ -10,6 +10,7 @@
 
aliases {
ethernet0 = &gmac1;
+   mmc0 = &sdmmc0;
};
 };
 
diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts
index 9bf4f464915f..f92475c59deb 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts
@@ -9,7 +9,8 @@
compatible = "radxa,zero-3w", "rockchip,rk3566";
 
aliases {
-   mmc1 = &sdhci;
+   mmc0 = &sdhci;
+   mmc1 = &sdmmc0;
mmc2 = &sdmmc1;
};
 
-- 
2.45.2



[PATCH 1/5] arm64: dts: rockchip: Add Radxa ZERO 3W/3E

2024-07-30 Thread Jonas Karlman
The Radxa ZERO 3W/3E is an ultra-small, high-performance single board
computer based on the Rockchip RK3566, with a compact form factor and
rich interfaces.

The ZERO 3W and ZERO 3E are basically the same size and model, but
differ only in storage and network interfaces.

- eMMC (3W)
- SD-card (both)
- Ethernet (3E)
- WiFi/BT (3W)

Add initial support for eMMC, SD-card, Ethernet, HDMI and USB.

Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240521202810.1225636-3-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: 1a5c8d307c83c808a32686ed51afb4bac2092d39 ]

(cherry picked from commit 1476c5882f8a47b6f0f895c6424dacf6334487ae)
---
 .../arm64/rockchip/rk3566-radxa-zero-3.dtsi   | 463 ++
 .../arm64/rockchip/rk3566-radxa-zero-3e.dts   |  51 ++
 .../arm64/rockchip/rk3566-radxa-zero-3w.dts   |  91 
 3 files changed, 605 insertions(+)
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts

diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
new file mode 100644
index ..623d5939d194
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
@@ -0,0 +1,463 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include 
+#include 
+#include 
+#include "rk3566.dtsi"
+
+/ {
+   aliases {
+   mmc0 = &sdmmc0;
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   hdmi-con {
+   compatible = "hdmi-connector";
+   type = "d";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&user_led2>;
+
+   led-green {
+   color = ;
+   default-state = "on";
+   function = LED_FUNCTION_HEARTBEAT;
+   gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   vcc_1v8: regulator-1v8-vcc {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_1v8";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <&vcc_1v8_p>;
+   };
+
+   vcca_1v8: regulator-1v8-vcca {
+   compatible = "regulator-fixed";
+   regulator-name = "vcca_1v8";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <&vcc_1v8_p>;
+   };
+
+   vcca1v8_image: regulator-1v8-vcca-image {
+   compatible = "regulator-fixed";
+   regulator-name = "vcca1v8_image";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <&vcc_1v8_p>;
+   };
+
+   vcc_3v3: regulator-3v3-vcc {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_3v3";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc3v3_sys>;
+   };
+
+   vcc_sys: regulator-5v0-vcc-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
+&combphy1 {
+   status = "okay";
+};
+
+&cpu0 {
+   cpu-supply = <&vdd_cpu>;
+};
+
+&cpu1 {
+   cpu-supply = <&vdd_cpu>;
+};
+
+&cpu2 {
+   cpu-supply = <&vdd_cpu>;
+};
+
+&cpu3 {
+   cpu-supply = <&vdd_cpu>;
+};
+
+&gpu {
+   mali-supply = <&vdd_gpu_npu>;
+   status = "okay";
+};
+
+&hdmi {
+   avdd-0v9-supply = <&

[PATCH 3/5] arm64: dts: rockchip: add gpio-line-names to radxa-zero-3

2024-07-30 Thread Jonas Karlman
From: Trevor Woerner 

Add names to the pins of the general-purpose expansion header as given
in the Radxa documentation[1] following the conventions in the kernel[2]
to make it easier for users to correlate pins with functions when using
utilities such as 'gpioinfo'.

[1] https://docs.radxa.com/en/zero/zero3/hardware-design/hardware-interface
[2] https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt

Signed-off-by: Trevor Woerner 
Link: https://lore.kernel.org/r/20240620013301.33653-1-twoer...@gmail.com
Signed-off-by: Heiko Stuebner 

[ upstream commit: f7c742cbe664ebdedc075945e75443683d1175f7 ]

(cherry picked from commit 8b26cf42ba0c74a9c86cebe591a9195f75151d97)
---
 .../arm64/rockchip/rk3566-radxa-zero-3.dtsi   | 72 +++
 1 file changed, 72 insertions(+)

diff --git a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
index 081be841b286..9cc7aa3298d0 100644
--- a/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
@@ -105,6 +105,78 @@
cpu-supply = <&vdd_cpu>;
 };
 
+&gpio0 {
+   gpio-line-names =
+   /* GPIO0_A0 - A7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO0_B0 - B7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO0_C0 - C7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO0_D0 - D7 */
+   "pin-10 [GPIO0_D0]", "pin-08 [GPIO0_D1]", "",
+   "", "", "", "", "";
+};
+
+&gpio1 {
+   gpio-line-names =
+   /* GPIO1_A0 - A7 */
+   "pin-03 [GPIO1_A0]", "pin-05 [GPIO1_A1]", "",
+   "",  "pin-37 [GPIO1_A4]", "",
+   "",  "",
+   /* GPIO1_B0 - B7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO1_C0 - C7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO1_D0 - D7 */
+   "", "", "", "", "", "", "", "";
+};
+
+&gpio2 {
+   gpio-line-names =
+   /* GPIO2_A0 - A7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO2_B0 - B7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO2_C0 - C7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO2_D0 - D7 */
+   "", "", "", "", "", "", "", "";
+};
+
+&gpio3 {
+   gpio-line-names =
+   /* GPIO3_A0 - A7 */
+   "",  "pin-11 [GPIO3_A1]", "pin-13 [GPIO3_A2]",
+   "pin-12 [GPIO3_A3]", "pin-35 [GPIO3_A4]", "pin-40 [GPIO3_A5]",
+   "pin-38 [GPIO3_A6]", "pin-36 [GPIO3_A7]",
+   /* GPIO3_B0 - B7 */
+   "pin-15 [GPIO3_B0]", "pin-16 [GPIO3_B1]", "pin-18 [GPIO3_B2]",
+   "pin-29 [GPIO3_B3]", "pin-31 [GPIO3_B4]", "",
+   "", "",
+   /* GPIO3_C0 - C7 */
+   "",  "pin-22 [GPIO3_C1]", "pin-32 [GPIO3_C2]",
+   "pin-33 [GPIO3_C3]", "pin-07 [GPIO3_C4]", "",
+   "", "",
+   /* GPIO3_D0 - D7 */
+   "", "", "", "", "", "", "", "";
+};
+
+&gpio4 {
+   gpio-line-names =
+   /* GPIO4_A0 - A7 */
+   "", "", "", "", "", "", "", "",
+   /* GPIO4_B0 - B7 */
+   "",  "",  "pin-27 [GPIO4_B2]",
+   "pin-28 [GPIO4_B3]", "", "", "", "",
+   /* GPIO4_C0 - C7 */
+   "",  "",  "pin-23 [GPIO4_C2]",
+   "pin-19 [GPIO4_C3]", "",  "pin-21 [GPIO4_C5]",
+   "pin-24 [GPIO4_C6]", "",
+   /* GPIO4_D0 - D7 */
+   "", "", "", "", "", "", "", "";
+};
+
 &gpu {
mali-supply = <&vdd_gpu_npu>;
status = "okay";
-- 
2.45.2



[PATCH 0/5] board: rockchip: Add Radxa ZERO 3W/3E

2024-07-30 Thread Jonas Karlman
This series add support for the RK3566 based Radxa ZERO 3W/3E boards.

rk_board_late_init() and board_fit_config_name_match() has been
implemented to set fdtfile env var and load correct FIT config based
on what board is detected at runtime.

Features tested on a ZERO 3W 8GB v1.11:
- SD-card boot
- eMMC boot
- USB gadget
- USB host

Features tested on a ZERO 3E 4GB v1.2:
- SD-card boot
- Ethernet
- USB gadget
- USB host

This series depends on the following patch for a clean apply:
- board: rockchip: add Radxa ROCK 3 Model C [1]

[1] https://patchwork.ozlabs.org/patch/1963177/

FUKAUMI Naoki (1):
  arm64: dts: rockchip: fix mmc aliases for Radxa ZERO 3E/3W

Jonas Karlman (3):
  arm64: dts: rockchip: Add Radxa ZERO 3W/3E
  dm: adc: Add SPL_ADC Kconfig symbol for use of ADC in SPL
  board: rockchip: Add Radxa ZERO 3W/3E

Trevor Woerner (1):
  arm64: dts: rockchip: add gpio-line-names to radxa-zero-3

 arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi |  11 +
 arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi |  11 +
 arch/arm/mach-rockchip/rk3568/Kconfig |   6 +
 board/radxa/zero3-rk3566/Kconfig  |  12 +
 board/radxa/zero3-rk3566/MAINTAINERS  |   6 +
 board/radxa/zero3-rk3566/Makefile |   3 +
 board/radxa/zero3-rk3566/zero3-rk3566.c   |  59 ++
 configs/radxa-zero-3-rk3566_defconfig |  85 +++
 doc/board/rockchip/rockchip.rst   |   1 +
 drivers/Makefile  |   2 +-
 drivers/adc/Kconfig   |   4 +
 .../arm64/rockchip/rk3566-radxa-zero-3.dtsi   | 531 ++
 .../arm64/rockchip/rk3566-radxa-zero-3e.dts   |  52 ++
 .../arm64/rockchip/rk3566-radxa-zero-3w.dts   |  92 +++
 14 files changed, 874 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3566-radxa-zero-3e-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3566-radxa-zero-3w-u-boot.dtsi
 create mode 100644 board/radxa/zero3-rk3566/Kconfig
 create mode 100644 board/radxa/zero3-rk3566/MAINTAINERS
 create mode 100644 board/radxa/zero3-rk3566/Makefile
 create mode 100644 board/radxa/zero3-rk3566/zero3-rk3566.c
 create mode 100644 configs/radxa-zero-3-rk3566_defconfig
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3.dtsi
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3e.dts
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-radxa-zero-3w.dts

-- 
2.45.2



[PATCH 2/2] board: rockchip: Add Radxa ROCK S0

2024-07-30 Thread Jonas Karlman
Radxa ROCK S0 is a single-board computer based on the Rockchip RK3308B
SoC in an ultra-compact form factor. Add a board target for the board.

Features tested on a ROCK S0 v1.2 with 512 MiB RAM and 8 GiB eMMC:
- SD-card boot
- eMMC boot
- Ethernet
- USB gadget
- USB host

Signed-off-by: Jonas Karlman 
---
 arch/arm/dts/rk3308-rock-s0-u-boot.dtsi | 21 
 board/rockchip/evb_rk3308/MAINTAINERS   |  6 +++
 configs/rock-s0-rk3308_defconfig| 72 +
 doc/board/rockchip/rockchip.rst |  1 +
 4 files changed, 100 insertions(+)
 create mode 100644 arch/arm/dts/rk3308-rock-s0-u-boot.dtsi
 create mode 100644 configs/rock-s0-rk3308_defconfig

diff --git a/arch/arm/dts/rk3308-rock-s0-u-boot.dtsi 
b/arch/arm/dts/rk3308-rock-s0-u-boot.dtsi
new file mode 100644
index ..84ca2ee0d5fb
--- /dev/null
+++ b/arch/arm/dts/rk3308-rock-s0-u-boot.dtsi
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rk3308-u-boot.dtsi"
+
+&emmc_pwren {
+   bootph-pre-ram;
+   bootph-some-ram;
+};
+
+&uart0 {
+   bootph-all;
+   clock-frequency = <2400>;
+};
+
+&uart0_xfer {
+   bootph-all;
+};
+
+&vdd_core {
+   regulator-init-microvolt = <1015000>;
+};
diff --git a/board/rockchip/evb_rk3308/MAINTAINERS 
b/board/rockchip/evb_rk3308/MAINTAINERS
index abffbb1eb0ab..cd219c65f278 100644
--- a/board/rockchip/evb_rk3308/MAINTAINERS
+++ b/board/rockchip/evb_rk3308/MAINTAINERS
@@ -12,3 +12,9 @@ R:  Jonas Karlman 
 S:  Maintained
 F:  configs/rock-pi-s-rk3308_defconfig
 F:  arch/arm/dts/rk3308-rock-pi-s*
+
+ROCK-S0
+M:  Jonas Karlman 
+S:  Maintained
+F:  configs/rock-s0-rk3308_defconfig
+F:  arch/arm/dts/rk3308-rock-s0*
diff --git a/configs/rock-s0-rk3308_defconfig b/configs/rock-s0-rk3308_defconfig
new file mode 100644
index ..074ec4cd66ba
--- /dev/null
+++ b/configs/rock-s0-rk3308_defconfig
@@ -0,0 +1,72 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3308-rock-s0"
+CONFIG_DM_RESET=y
+CONFIG_ROCKCHIP_RK3308=y
+CONFIG_TARGET_EVB_RK3308=y
+CONFIG_DEBUG_UART_BASE=0xFF0A
+CONFIG_DEBUG_UART_CLOCK=2400
+# CONFIG_DEBUG_UART_BOARD_INIT is not set
+CONFIG_SYS_LOAD_ADDR=0xc00800
+CONFIG_DEBUG_UART=y
+CONFIG_ANDROID_BOOT_IMAGE=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3308-rock-s0.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_PAD_TO=0x7f8000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_ROCKUSB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+CONFIG_CMD_RNG=y
+CONFIG_CMD_KASLRSEED=y
+CONFIG_CMD_REGULATOR=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_CLK=y
+# CONFIG_USB_FUNCTION_FASTBOOT is not set
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_ROCKCHIP_IODOMAIN=y
+CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_PHY_REALTEK=y
+CONFIG_DM_MDIO=y
+CONFIG_DM_ETH_PHY=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PINCTRL=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_RAM=y
+CONFIG_BAUDRATE=150
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550_MEM32=y
+CONFIG_SYSINFO=y
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_DM_USB_GADGET=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB_FUNCTION_ROCKUSB=y
+CONFIG_LZO=y
+CONFIG_ERRNO_STR=y
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index bedc52e03e20..82cbc6e3e0db 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -54,6 +54,7 @@ List of mainline supported Rockchip boards:
  - Amarula Vyasa-RK3288 (vyasa-rk3288)
 * rk3308
  - Radxa ROCK Pi S (rock-pi-s-rk3308)
+ - Radxa ROCK S0 (rock-s0-rk3308)
  - Rockchip Evb-RK3308 (evb-rk3308)
  - Roc-cc-RK3308 (roc-cc-rk3308)
 * rk3326
-- 
2.45.2



[PATCH 1/2] arm64: dts: rockchip: Add Radxa ROCK S0

2024-07-30 Thread Jonas Karlman
Radxa ROCK S0 is a single-board computer based on the Rockchip RK3308B
SoC in an ultra-compact form factor.

Add initial support for eMMC, SD-card, Ethernet, WiFi/BT and USB.

Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240521212247.1240226-3-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: adeb5d2a4ba47910238b3c4f5fd960cc0c26a98b ]

(cherry picked from commit e291d457b0378f2cb3d3ebb597032ca862cdb973)
---
 .../src/arm64/rockchip/rk3308-rock-s0.dts | 293 ++
 1 file changed, 293 insertions(+)
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3308-rock-s0.dts

diff --git a/dts/upstream/src/arm64/rockchip/rk3308-rock-s0.dts 
b/dts/upstream/src/arm64/rockchip/rk3308-rock-s0.dts
new file mode 100644
index ..bd6419a5c20a
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3308-rock-s0.dts
@@ -0,0 +1,293 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include 
+#include "rk3308.dtsi"
+
+/ {
+   model = "Radxa ROCK S0";
+   compatible = "radxa,rock-s0", "rockchip,rk3308";
+
+   aliases {
+   ethernet0 = &gmac;
+   mmc0 = &emmc;
+   mmc1 = &sdmmc;
+   mmc2 = &sdio;
+   };
+
+   chosen {
+   stdout-path = "serial0:150n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pwr_led>;
+
+   led-green {
+   color = ;
+   default-state = "on";
+   function = LED_FUNCTION_HEARTBEAT;
+   gpios = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   vdd_log: regulator-1v04-vdd-log {
+   compatible = "regulator-fixed";
+   regulator-name = "vdd_log";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <104>;
+   regulator-max-microvolt = <104>;
+   vin-supply = <&vcc5v0_sys>;
+   };
+
+   vcc_ddr: regulator-1v5-vcc-ddr {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_ddr";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   vin-supply = <&vcc5v0_sys>;
+   };
+
+   vcc_1v8: regulator-1v8-vcc {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_1v8";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <&vcc_io>;
+   };
+
+   vcc_io: regulator-3v3-vcc-io {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_io";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc5v0_sys>;
+   };
+
+   vcc5v0_sys: regulator-5v0-vcc-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   vdd_core: regulator-vdd-core {
+   compatible = "pwm-regulator";
+   pwms = <&pwm0 0 5000 1>;
+   pwm-supply = <&vcc5v0_sys>;
+   regulator-name = "vdd_core";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <827000>;
+   regulator-max-microvolt = <134>;
+   regulator-settling-time-up-us = <250>;
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-names = "default";
+   pinctrl-0 = <&wifi_reg_on>;
+   reset-gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
+   };
+};
+
+&cpu0 {
+   cpu-supply = <&vdd_core>;
+};
+
+&emmc {
+   cap-mmc-highspeed;
+   no-sd;
+   no-sdio;
+   non-removable;
+   pinctrl-names = "default";
+   pinctrl-0 = <&emmc_bus8 &emmc_clk &

[PATCH 0/2] board: rockchip: Add Radxa ROCK S0

2024-07-30 Thread Jonas Karlman
This series add support for the RK3308 based Radxa ROCK S0 board.

Features tested on a ROCK S0 v1.2 with 512 MiB RAM and 8 GiB eMMC:
- SD-card boot
- eMMC boot
- Ethernet
- USB gadget
- USB host

This series depends on the following patch:
- arm64: dts: rockchip: Add rk3308 IO voltage domains [1]

[1] https://patchwork.ozlabs.org/patch/1966593/

Jonas Karlman (2):
  arm64: dts: rockchip: Add Radxa ROCK S0
  board: rockchip: Add Radxa ROCK S0

 arch/arm/dts/rk3308-rock-s0-u-boot.dtsi   |  21 ++
 board/rockchip/evb_rk3308/MAINTAINERS |   6 +
 configs/rock-s0-rk3308_defconfig  |  72 +
 doc/board/rockchip/rockchip.rst   |   1 +
 .../src/arm64/rockchip/rk3308-rock-s0.dts | 293 ++
 5 files changed, 393 insertions(+)
 create mode 100644 arch/arm/dts/rk3308-rock-s0-u-boot.dtsi
 create mode 100644 configs/rock-s0-rk3308_defconfig
 create mode 100644 dts/upstream/src/arm64/rockchip/rk3308-rock-s0.dts

-- 
2.45.2



[PATCH 8/8] rockchip: rk3308-rock-pi-s: Enable LED and IO Domain driver

2024-07-30 Thread Jonas Karlman
Add LED=y and LED_GPIO=y to support the onboard leds.

Add ROCKCHIP_IODOMAIN=y to configure correct io voltage domains.

Add DM_MDIO=y now that the DT contain a Ethernet phy node.

Signed-off-by: Jonas Karlman 
---
 configs/rock-pi-s-rk3308_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/rock-pi-s-rk3308_defconfig 
b/configs/rock-pi-s-rk3308_defconfig
index e450a0618020..54f7744c9895 100644
--- a/configs/rock-pi-s-rk3308_defconfig
+++ b/configs/rock-pi-s-rk3308_defconfig
@@ -38,10 +38,14 @@ CONFIG_CLK=y
 # CONFIG_USB_FUNCTION_FASTBOOT is not set
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_ROCKCHIP_IODOMAIN=y
 CONFIG_SUPPORT_EMMC_RPMB=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_REALTEK=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_ETH_PHY=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-- 
2.45.2



[PATCH 7/8] rockchip: rk3308-rock-pi-s: Remove unnecessary u-boot dtsi overrides

2024-07-30 Thread Jonas Karlman
With the emmc and uart0 DT nodes updated to v6.11-rc1 in dts/upstream
there is no longer any need to keep overrides in board u-boot dtsi.

Signed-off-by: Jonas Karlman 
---
 arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi 
b/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
index a6fb8b12da38..ff5bab316a34 100644
--- a/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
@@ -4,17 +4,6 @@
  */
 #include "rk3308-u-boot.dtsi"
 
-&emmc {
-   cap-sd-highspeed;
-   pinctrl-names = "default";
-   pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_bus4>;
-};
-
-&emmc_bus4 {
-   bootph-pre-ram;
-   bootph-some-ram;
-};
-
 &u2phy_otg {
/delete-property/ phy-supply;
 };
@@ -24,14 +13,6 @@
clock-frequency = <2400>;
 };
 
-&uart0_cts {
-   bootph-all;
-};
-
-&uart0_rts {
-   bootph-all;
-};
-
 &uart0_xfer {
bootph-all;
 };
-- 
2.45.2



[PATCH 5/8] arm64: dts: rockchip: Add io-domains to rk3308-rock-pi-s

2024-07-30 Thread Jonas Karlman
The VCCIO4 io-domain used for WiFi/BT is using 1v8 IO signal voltage.

Add io-domains node with the VCCIO supplies connected on the board.

Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240521211029.1236094-13-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: 100b3bdee6035192f6d4a1847970fe004bb505fb ]

(cherry picked from commit f93b224359278728f01767a4701678ada9c25570)
---
 dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts 
b/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
index f6fb90e13ad0..5c702f00b27f 100644
--- a/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
@@ -231,6 +231,16 @@
status = "okay";
 };
 
+&io_domains {
+   vccio0-supply = <&vcc_io>;
+   vccio1-supply = <&vcc_io>;
+   vccio2-supply = <&vcc_io>;
+   vccio3-supply = <&vcc_io>;
+   vccio4-supply = <&vcc_1v8>;
+   vccio5-supply = <&vcc_io>;
+   status = "okay";
+};
+
 &pinctrl {
pinctrl-names = "default";
pinctrl-0 = <&rtc_32k>;
-- 
2.45.2



[PATCH 6/8] arm64: dts: rockchip: Update WIFi/BT related nodes on rk3308-rock-pi-s

2024-07-30 Thread Jonas Karlman
Update WiFi SDIO and BT UART related props to better reflect details
about the optional onboard RTL8723DS WiFi/BT module.

Also correct the compatible used for bluetooth to match the WiFi/BT
module used on the board.

Fixes: bc3753aed81f ("arm64: dts: rockchip: rock-pi-s add more peripherals")
Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240521211029.1236094-14-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: 12c3ec878cbe3709782e85b88124abecc3bb8617 ]

(cherry picked from commit caba73747c927b4fdccea3aeb16e077b4e6af006)
---
 .../src/arm64/rockchip/rk3308-rock-pi-s.dts   | 40 +--
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts 
b/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
index 5c702f00b27f..62d18ca769a1 100644
--- a/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
@@ -17,6 +17,7 @@
ethernet0 = &gmac;
mmc0 = &emmc;
mmc1 = &sdmmc;
+   mmc2 = &sdio;
};
 
chosen {
@@ -245,6 +246,20 @@
pinctrl-names = "default";
pinctrl-0 = <&rtc_32k>;
 
+   bluetooth {
+   bt_reg_on: bt-reg-on {
+   rockchip,pins = <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
+   };
+
+   bt_wake_host: bt-wake-host {
+   rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_down>;
+   };
+
+   host_wake_bt: host-wake-bt {
+   rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+   };
+   };
+
gmac {
mac_rst: mac-rst {
rockchip,pins = <0 RK_PA7 RK_FUNC_GPIO &pcfg_pull_none>;
@@ -294,11 +309,24 @@
cap-sd-highspeed;
cap-sdio-irq;
keep-power-in-suspend;
-   max-frequency = <100>;
+   max-frequency = <1>;
mmc-pwrseq = <&sdio_pwrseq>;
+   no-mmc;
+   no-sd;
non-removable;
-   sd-uhs-sdr104;
+   sd-uhs-sdr50;
+   vmmc-supply = <&vcc_io>;
+   vqmmc-supply = <&vcc_1v8>;
status = "okay";
+
+   rtl8723ds: wifi@1 {
+   reg = <1>;
+   interrupt-parent = <&gpio0>;
+   interrupts = ;
+   interrupt-names = "host-wake";
+   pinctrl-names = "default";
+   pinctrl-0 = <&wifi_host_wake>;
+   };
 };
 
 &sdmmc {
@@ -330,12 +358,16 @@
 };
 
 &uart4 {
+   uart-has-rtscts;
status = "okay";
 
bluetooth {
-   compatible = "realtek,rtl8723bs-bt";
-   device-wake-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_HIGH>;
+   compatible = "realtek,rtl8723ds-bt";
+   device-wake-gpios = <&gpio4 RK_PB2 GPIO_ACTIVE_HIGH>;
+   enable-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_HIGH>;
host-wake-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&bt_reg_on &bt_wake_host &host_wake_bt>;
};
 };
 
-- 
2.45.2



[PATCH 4/8] arm64: dts: rockchip: Add mdio and ethernet-phy nodes to rk3308-rock-pi-s

2024-07-30 Thread Jonas Karlman
Be explicit about the Ethernet port and define mdio and ethernet-phy
nodes in the device tree for ROCK Pi S.

Fixes: bc3753aed81f ("arm64: dts: rockchip: rock-pi-s add more peripherals")
Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240521211029.1236094-8-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: 4b64ed510ed946a4e4ca6d51d6512bf5361f6a04 ]

(cherry picked from commit 703b8eae20eec5dbb0e52f0e1fb71e712c007dae)
---
 .../src/arm64/rockchip/rk3308-rock-pi-s.dts   | 26 ---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts 
b/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
index d4cf6026241c..f6fb90e13ad0 100644
--- a/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
@@ -144,11 +144,25 @@
 
 &gmac {
clock_in_out = "output";
+   phy-handle = <&rtl8201f>;
phy-supply = <&vcc_io>;
-   snps,reset-gpio = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
-   snps,reset-active-low;
-   snps,reset-delays-us = <0 5 5>;
status = "okay";
+
+   mdio {
+   compatible = "snps,dwmac-mdio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rtl8201f: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&mac_rst>;
+   reset-assert-us = <2>;
+   reset-deassert-us = <5>;
+   reset-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+   };
+   };
 };
 
 &gpio0 {
@@ -221,6 +235,12 @@
pinctrl-names = "default";
pinctrl-0 = <&rtc_32k>;
 
+   gmac {
+   mac_rst: mac-rst {
+   rockchip,pins = <0 RK_PA7 RK_FUNC_GPIO &pcfg_pull_none>;
+   };
+   };
+
leds {
green_led: green-led {
rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
-- 
2.45.2



[PATCH 2/8] arm64: dts: rockchip: Add sdmmc related properties on rk3308-rock-pi-s

2024-07-30 Thread Jonas Karlman
Add cap-mmc-highspeed to allow use of high speed MMC mode using an eMMC
to uSD board. Use disable-wp to signal that no physical write-protect
line is present. Also add vcc_io used for card and IO line power as
vmmc-supply.

Fixes: 2e04c25b1320 ("arm64: dts: rockchip: add ROCK Pi S DTS support")
Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240521211029.1236094-5-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: fc0daeccc384233eadfa9d5ddbd00159653c6bdc ]

(cherry picked from commit 39110e4bec51c9ce6bbd342234b288dbfccb9f80)
---
 dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts 
b/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
index 079101cddd65..8ea984906403 100644
--- a/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
@@ -272,7 +272,10 @@
 };
 
 &sdmmc {
+   cap-mmc-highspeed;
cap-sd-highspeed;
+   disable-wp;
+   vmmc-supply = <&vcc_io>;
status = "okay";
 };
 
-- 
2.45.2



[PATCH 3/8] arm64: dts: rockchip: Add pinctrl for UART0 to rk3308-rock-pi-s

2024-07-30 Thread Jonas Karlman
UAR0 CTS/RTS is not wired to any pin and is not used for the default
serial console use of UART0 on ROCK Pi S.

Override the SoC defined pinctrl props to limit configuration of the
two xfer pins wired to one of the GPIO pin headers.

Fixes: 2e04c25b1320 ("arm64: dts: rockchip: add ROCK Pi S DTS support")
Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240521211029.1236094-6-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: 7affb86ef62581e3475ce3e0a7640da1f2ee29f8 ]

(cherry picked from commit 9c72cd5fa9f971be8ebbc1f43bd74a72e33db2fa)
---
 dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts 
b/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
index 8ea984906403..d4cf6026241c 100644
--- a/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3308-rock-pi-s.dts
@@ -294,6 +294,8 @@
 };
 
 &uart0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uart0_xfer>;
status = "okay";
 };
 
-- 
2.45.2



[PATCH 1/8] arm64: dts: rockchip: Add rk3308 IO voltage domains

2024-07-30 Thread Jonas Karlman
Add a disabled RK3308 IO voltage domains node to SoC DT.

Signed-off-by: Jonas Karlman 
Link: https://lore.kernel.org/r/20240521211029.1236094-12-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner 

[ upstream commit: d1829ba469d5743734e37d59fece73e3668ab084 ]

(cherry picked from commit cebde305971e33a76efc3280e09814499ef89f54)
---
 dts/upstream/src/arm64/rockchip/rk3308.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/dts/upstream/src/arm64/rockchip/rk3308.dtsi 
b/dts/upstream/src/arm64/rockchip/rk3308.dtsi
index 6531ede13af9..31c25de2d689 100644
--- a/dts/upstream/src/arm64/rockchip/rk3308.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3308.dtsi
@@ -173,6 +173,11 @@
compatible = "rockchip,rk3308-grf", "syscon", "simple-mfd";
reg = <0x0 0xff00 0x0 0x08000>;
 
+   io_domains: io-domains {
+   compatible = "rockchip,rk3308-io-voltage-domain";
+   status = "disabled";
+   };
+
reboot-mode {
compatible = "syscon-reboot-mode";
offset = <0x500>;
-- 
2.45.2



[PATCH 0/8] rockchip: rk3308-rock-pi-s: Update DT to v6.11-rc1

2024-07-30 Thread Jonas Karlman
This series cherry picks related rk3308 and rk3308-rock-pi-s commits
from devicetree-rebasing v6.11-rc1-dts tag to improve support for the
new v1.5 hw revision of Radxa Rock Pi S.

This series loosely depends on following patches:
- mmc: rockchip_dw_mmc: Allow 4-bit mode when 8-bit mode is supported [1]
- rockchip: io-domain: Add support for RK3308 [2]

[1] https://patchwork.ozlabs.org/patch/1964169/
[2] https://patchwork.ozlabs.org/patch/1964170/

Jonas Karlman (8):
  arm64: dts: rockchip: Add rk3308 IO voltage domains
  arm64: dts: rockchip: Add sdmmc related properties on rk3308-rock-pi-s
  arm64: dts: rockchip: Add pinctrl for UART0 to rk3308-rock-pi-s
  arm64: dts: rockchip: Add mdio and ethernet-phy nodes to
rk3308-rock-pi-s
  arm64: dts: rockchip: Add io-domains to rk3308-rock-pi-s
  arm64: dts: rockchip: Update WIFi/BT related nodes on rk3308-rock-pi-s
  rockchip: rk3308-rock-pi-s: Remove unnecessary u-boot dtsi overrides
  rockchip: rk3308-rock-pi-s: Enable LED and IO Domain driver

 arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi | 19 -
 configs/rock-pi-s-rk3308_defconfig|  4 +
 .../src/arm64/rockchip/rk3308-rock-pi-s.dts   | 81 +--
 dts/upstream/src/arm64/rockchip/rk3308.dtsi   |  5 ++
 4 files changed, 83 insertions(+), 26 deletions(-)

-- 
2.45.2



  1   2   3   4   5   6   7   8   9   10   >