[PATCH 3/3] timer: riscv_aclint_timer: add timer_get_boot_us for BOOTSTAGE

2023-08-20 Thread Chanho Park
timer_get_boot_us function is required to record the boot stages as
us-based timestamp.

Signed-off-by: Chanho Park 
---
 drivers/timer/riscv_aclint_timer.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/timer/riscv_aclint_timer.c 
b/drivers/timer/riscv_aclint_timer.c
index e29d527c8d77..442b48d55adf 100644
--- a/drivers/timer/riscv_aclint_timer.c
+++ b/drivers/timer/riscv_aclint_timer.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -44,6 +45,27 @@ u64 notrace timer_early_get_count(void)
 }
 #endif
 
+#if CONFIG_IS_ENABLED(BOOTSTAGE)
+ulong timer_get_boot_us(void)
+{
+   int ret;
+   u64 ticks = 0;
+   u32 rate;
+
+   ret = dm_timer_init();
+   if (!ret) {
+   rate = timer_get_rate(gd->timer);
+   timer_get_count(gd->timer, );
+   } else {
+   rate = RISCV_MMODE_TIMER_FREQ;
+   ticks = readq((void __iomem *)MTIME_REG(RISCV_MMODE_TIMERBASE,
+   RISCV_MMODE_TIMEROFF));
+   }
+
+   return lldiv(ticks * 1001, (rate / 1000));
+}
+#endif
+
 static const struct timer_ops riscv_aclint_timer_ops = {
.get_count = riscv_aclint_timer_get_count,
 };
-- 
2.39.2



[PATCH 0/3] bootstage support for risc-v

2023-08-20 Thread Chanho Park
This adds to support bootstage for risc-v. timer_get_boot_us function
is required to record each boot stages with microsecond timestamp.

Chanho Park (3):
  riscv: bootstage: correct bootstage_report guard
  riscv: timer: add timer_get_boot_us for BOOTSTAGE
  timer: riscv_aclint_timer: add timer_get_boot_us for BOOTSTAGE

 arch/riscv/lib/bootm.c |  2 +-
 drivers/timer/riscv_aclint_timer.c | 22 ++
 drivers/timer/riscv_timer.c| 21 +
 3 files changed, 44 insertions(+), 1 deletion(-)

-- 
2.39.2



[PATCH 1/3] riscv: bootstage: correct bootstage_report guard

2023-08-20 Thread Chanho Park
Below warning can be occurred when CONFIG_BOOTSTAGE and
!CONFIG_SPL_BOOTSTAGE. It should be guarded by using CONFIG_IS_ENABLED
for SPL build.

arch/riscv/lib/bootm.c:46:9: warning: implicit declaration of
function 'bootstage_report'
   46 | bootstage_report();
  | ^~~~
  | bootstage_error

Signed-off-by: Chanho Park 
---
 arch/riscv/lib/bootm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index 276677a5e2f9..cc30efc90498 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -42,7 +42,7 @@ static void announce_and_cleanup(int fake)
 #ifdef CONFIG_BOOTSTAGE_FDT
bootstage_fdt_add_report();
 #endif
-#ifdef CONFIG_BOOTSTAGE_REPORT
+#if CONFIG_IS_ENABLED(BOOTSTAGE_REPORT)
bootstage_report();
 #endif
 
-- 
2.39.2



[PATCH 2/3] riscv: timer: add timer_get_boot_us for BOOTSTAGE

2023-08-20 Thread Chanho Park
timer_get_boot_us function is required to record the boot stages as
us-based timestamp.

Signed-off-by: Chanho Park 
---
 drivers/timer/riscv_timer.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c
index 3627ed79b819..f9fc7dae37d0 100644
--- a/drivers/timer/riscv_timer.c
+++ b/drivers/timer/riscv_timer.c
@@ -11,6 +11,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -50,6 +51,26 @@ u64 notrace timer_early_get_count(void)
 }
 #endif
 
+#if CONFIG_IS_ENABLED(BOOTSTAGE)
+ulong timer_get_boot_us(void)
+{
+   int ret;
+   u64 ticks = 0;
+   u32 rate;
+
+   ret = dm_timer_init();
+   if (!ret) {
+   rate = timer_get_rate(gd->timer);
+   timer_get_count(gd->timer, );
+   } else {
+   rate = RISCV_SMODE_TIMER_FREQ;
+   ticks = riscv_timer_get_count(NULL);
+   }
+
+   return lldiv(ticks * 1000, (rate / 1000));
+}
+#endif
+
 static int riscv_timer_probe(struct udevice *dev)
 {
struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
-- 
2.39.2



[PATCH 2/2] ARM64: dts: marvell: cn9310-crb: Remove duplicate pinctrl

2023-08-20 Thread Chris Packham
The cn9130.dtsi defines a pinctrl node for SPI1 (until recently it was
mislabeled as spi0). Use this instead of having a duplicate definition
with a different label.

Signed-off-by: Chris Packham 
---

 arch/arm/dts/cn9130-crb.dtsi | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/dts/cn9130-crb.dtsi b/arch/arm/dts/cn9130-crb.dtsi
index b229725184a9..7dd36cae282b 100644
--- a/arch/arm/dts/cn9130-crb.dtsi
+++ b/arch/arm/dts/cn9130-crb.dtsi
@@ -125,11 +125,6 @@
marvell,function = <0>;
};
 
-   cp0_spi1_pins_crb: cp0-spi-pins-crb {
-   marvell,pins = < 13 14 15 16 >;
-   marvell,function = <3>;
-   };
-
cp0_smi_pins_crb: cp0-smi-pins-crb {
marvell,pins = < 40 41 >;
marvell,function = <8>;
@@ -170,7 +165,7 @@
 
 _spi1 {
pinctrl-names = "default";
-   pinctrl-0 = <_spi1_pins_crb>;
+   pinctrl-0 = <_spi1_pins>;
reg = <0x700680 0x50>,  /* control */
  <0x200 0x100>,/* CS0 */
  <0 0x>,   /* CS1 */
-- 
2.41.0



[PATCH 1/2] ARM64: dts: marvell: cn9310: Use appropriate label for spi1 pins

2023-08-20 Thread Chris Packham
The CN9130-DB uses the SPI1 interface but had the pinctrl node labelled
as "cp0_spi0_pins". Use the label "cp0_spi1_pins" and update the node
name to "cp0-spi-pins-1" to avoid confusion with the pinctrl options for
SPI0.

Signed-off-by: Chris Packham 
---

 arch/arm/dts/cn9130-db.dtsi | 2 +-
 arch/arm/dts/cn9130.dtsi| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/cn9130-db.dtsi b/arch/arm/dts/cn9130-db.dtsi
index 1b28732ee752..4b21ff46d507 100644
--- a/arch/arm/dts/cn9130-db.dtsi
+++ b/arch/arm/dts/cn9130-db.dtsi
@@ -183,7 +183,7 @@
 /* U55 */
 _spi1 {
pinctrl-names = "default";
-   pinctrl-0 = <_spi0_pins>;
+   pinctrl-0 = <_spi1_pins>;
reg = <0x700680 0x50>,  /* control */
  <0x200 0x100>,/* CS0 */
  <0 0x>,   /* CS1 */
diff --git a/arch/arm/dts/cn9130.dtsi b/arch/arm/dts/cn9130.dtsi
index 68b767a70639..efcb2e906b91 100644
--- a/arch/arm/dts/cn9130.dtsi
+++ b/arch/arm/dts/cn9130.dtsi
@@ -66,7 +66,7 @@
marvell,pins = < 56 57 58 59 60 61 >;
marvell,function = <14>;
};
-   cp0_spi0_pins: cp0-spi-pins-0 {
+   cp0_spi1_pins: cp0-spi-pins-1 {
marvell,pins = < 13 14 15 16 >;
marvell,function = <3>;
};
-- 
2.41.0



[PATCH v2] dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation

2023-08-20 Thread Jonas Karlman
Nodes with bootph-pre-sram/ram props are bound in multiple phases:
1. At TPL (bootph-pre-sram) or SPL (bootph-pre-ram) phase
2. At U-Boot proper pre-relocation phase
3. At U-Boot proper normal phase

However the binding and U-Boot Driver Model documentation indicate that
only nodes marked with bootph-all or bootph-some-ram should be bound in
the U-Boot proper pre-relocation phase.

Change ofnode_pre_reloc to report a node with bootph-pre-ram/sram prop
with a pre-reloc status only after U-Boot proper pre-relocation phase.
Also update the ofnode_pre_reloc documentation to closer reflect the
binding and driver model documentation.

This changes behavior of what nodes are bound in the U-Boot proper
pre-relocation phase. Change to bootph-all or add bootph-some-ram prop
to restore prior behavior.

Signed-off-by: Jonas Karlman 
Reviewed-by: Simon Glass 
---
Changes in v2:
- Drop use of !! to convert into bool
- Update documentation for ofnode_pre_reloc
- Rewrite commit message
- Collect r-b tag

 drivers/core/ofnode.c | 2 +-
 include/dm/ofnode.h   | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 8df16e56af5c..b1e94b2d60df 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -1353,7 +1353,7 @@ bool ofnode_pre_reloc(ofnode node)
 */
if (ofnode_read_bool(node, "bootph-pre-ram") ||
ofnode_read_bool(node, "bootph-pre-sram"))
-   return true;
+   return gd->flags & GD_FLG_RELOC;
 
if (IS_ENABLED(CONFIG_OF_TAG_MIGRATE)) {
/* detect and handle old tags */
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index 0f38b3e736de..13700f8266d7 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -1198,15 +1198,15 @@ int ofnode_read_simple_size_cells(ofnode node);
  * determine if a node was bound in one of SPL/TPL stages.
  *
  * There are 4 settings currently in use
- * - bootph-some-ram: U-Boot proper pre-relocation only
+ * - bootph-some-ram: U-Boot proper pre-relocation phase
  * - bootph-all: all phases
  * Existing platforms only use it to indicate nodes needed in
  * SPL. Should probably be replaced by bootph-pre-ram for new platforms.
- * - bootph-pre-ram: SPL and U-Boot pre-relocation
- * - bootph-pre-sram: TPL and U-Boot pre-relocation
+ * - bootph-pre-ram: SPL phase
+ * - bootph-pre-sram: TPL phase
  *
  * @node: node to check
- * Return: true if node is needed in SPL/TL, false otherwise
+ * Return: true if node should be or was bound, false otherwise
  */
 bool ofnode_pre_reloc(ofnode node);
 
-- 
2.41.0



Re: [PATCH 1/2] test: dm: pinmux: Handle %pa in pinctrl-single mux output

2023-08-20 Thread Simon Glass
On Sat, 12 Aug 2023 at 21:32, Marek Vasut
 wrote:
>
> The pinctrl-single driver uses %pa to print register value
> in its single_get_pin_muxing() output. Handle this properly
> in the test based on CONFIG_PHYS_64BIT .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Simon Glass 
> ---
>  test/dm/pinmux.c | 92 +++-
>  1 file changed, 51 insertions(+), 41 deletions(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!


Re: [PATCH] configs: sandbox64: Enable SF bootdev

2023-08-20 Thread Simon Glass
On Sat, 12 Aug 2023 at 18:16, Marek Vasut
 wrote:
>
> Align the sandbox64 defconfig with sandbox defconfig. Enable missing
> SPI NOT bootdev. This fixes ut_bootstd_bootdev_test_cmd_hunt test .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Mario Six 
> Cc: Simon Glass 
> ---
>  configs/sandbox64_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!


Re: [PATCH] configs: sandbox64: Increase console record size to 0x6000

2023-08-20 Thread Simon Glass
On Sat, 12 Aug 2023 at 19:18, Marek Vasut
 wrote:
>
> Align the sandbox64 defconfig with sandbox defconfig. Increase the
> console record size. This fixes ut_bootstd_bootflow_cmd_scan_e .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Mario Six 
> Cc: Simon Glass 
> ---
>  configs/sandbox64_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!


Re: [PATCH] configs: sandbox64: Enable MC34708 driver

2023-08-20 Thread Simon Glass
On Sat, 12 Aug 2023 at 20:57, Marek Vasut
 wrote:
>
> Align the sandbox64 defconfig with sandbox defconfig. Enable missing
> MC34708 PMIC driver. This fixes ut_dm_dm_test_power_pmic_mc34708_get test .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Simon Glass 
> ---
>  configs/sandbox64_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!


Re: [PATCH] configs: sandbox64: Enable BUTTON_ADC driver

2023-08-20 Thread Simon Glass
On Sat, 12 Aug 2023 at 21:06, Marek Vasut
 wrote:
>
> Align the sandbox64 defconfig with sandbox defconfig. Enable missing
> BUTTON ADC driver. This fixes ut_dm_dm_test_button_keys_adc test .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Simon Glass 
> ---
>  configs/sandbox64_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

As Tom mentioned there is likely not that much reason to have as many
differences between the sandbox configs as we do...so you could do a
bulk meld if it is easier.

Applied to u-boot-dm, thanks!


Re: [PATCH 2/2] configs: sandbox64: Enable PINCTRL_SINGLE driver

2023-08-20 Thread Simon Glass
On Sat, 12 Aug 2023 at 21:32, Marek Vasut
 wrote:
>
> Align the sandbox64 defconfig with sandbox defconfig. Enable missing
> PINCTRL single driver. This fixes ut_dm_dm_test_pinctrl_single test .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Simon Glass 
> ---
>  configs/sandbox64_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!


Re: [PATCH 1/2] configs: sandbox64: Enable video 16bpp and 24bpp support

2023-08-20 Thread Simon Glass
On Sat, 12 Aug 2023 at 23:15, Marek Vasut
 wrote:
>
> Align the sandbox64 defconfig with sandbox defconfig. Enable missing
> 16bpp and 24bpp video support. This fixes ut_dm_dm_test_video_bmp16
> and ut_dm_dm_test_video_bmp24 tests .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Simon Glass 
> ---
>  configs/sandbox64_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!


Re: [PATCH 2/2] configs: sandbox64: Enable video 12x22 font support

2023-08-20 Thread Simon Glass
On Sat, 12 Aug 2023 at 23:15, Marek Vasut
 wrote:
>
> Align the sandbox64 defconfig with sandbox defconfig. Enable missing
> 12x22 font support. This fixes ut_dm_dm_test_video_text_12x22 test .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Simon Glass 
> ---
>  configs/sandbox64_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!


Re: [PATCH] configs: sandbox64: Enable clock CCF driver

2023-08-20 Thread Simon Glass
On Sun, 13 Aug 2023 at 13:50, Marek Vasut
 wrote:
>
> Align the sandbox64 defconfig with sandbox defconfig. Enable missing
> CCF and Sandbox CCF drivers. This fixes ut_dm_dm_test_clk_ccf test .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Simon Glass 
> ---
>  configs/sandbox64_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!


Re: [PATCH] configs: sandbox64: Enable PCI register multi-entry support

2023-08-20 Thread Simon Glass
On Sun, 13 Aug 2023 at 13:52, Marek Vasut
 wrote:
>
> Align the sandbox64 defconfig with sandbox defconfig. Enable missing
> PCI register multi-entry support. This fixes ut_dm_dm_test_pci_bus_to_phys
> test .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Simon Glass 
> ---
>  configs/sandbox64_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!


Re: [PATCH] test: cpu: Handle both 32bit and 64bit CPUs

2023-08-20 Thread Simon Glass
On Sun, 13 Aug 2023 at 13:52, Marek Vasut
 wrote:
>
> Handle both 32bit and 64bit systems, i.e. sandbox and sandbox64
> the same way drivers/cpu/cpu_sandbox.c does, that is in case
> CONFIG_PHYS_64BIT is enabled, assume 64bit address width, else
> assume 32bit address width. This fixes ut_dm_dm_test_cpu test
> failure on sandbox64.
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Simon Glass 
> ---
>  test/dm/cpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!


Re: [PATCH v1 1/1] usb: host: tegra: implement dts based xcvr setup

2023-08-20 Thread Marek Vasut

On 8/20/23 21:23, Svyatoslav Ryhel wrote:



20 серпня 2023 р. 22:10:17 GMT+03:00, Marek Vasut  написав(-ла):

On 8/20/23 20:32, Svyatoslav Ryhel wrote:

20 серпня 2023 р. 21:14:15 GMT+03:00, Marek Vasut  написав(-ла):

On 8/20/23 09:13, Svyatoslav Ryhel wrote:

20 серпня 2023 р. 05:23:14 GMT+03:00, Marek Vasut  написав(-ла):

On 8/19/23 17:06, Svyatoslav Ryhel wrote:

Some devices (like ASUS TF201) may not have fuse based xcvr setup
which will result in not working USB line. To fix this situation
allow xcvr setup to be performed from device tree values if
nvidia,xcvr-setup-use-fuses is not defined.

Tested-by: Svyatoslav Ryhel  # ASUS TF201


I would hope so. Usually T-B tags are not added by the patch author, but that's 
a detail, and here it has the added model value, so keep it.


Signed-off-by: Svyatoslav Ryhel 
---
 drivers/usb/host/ehci-tegra.c | 53 +++
 1 file changed, 48 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 2cf1625670..f24baf8f0c 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -81,6 +81,8 @@ struct fdt_usb {
enum periph_id periph_id;/* peripheral id */
struct gpio_desc vbus_gpio; /* GPIO for vbus enable */
struct gpio_desc phy_reset_gpio; /* GPIO to reset ULPI phy */
+bool xcvr_setup_use_fuses; /* Indicates that the value is read from the 
on-chip fuses */
+u32 xcvr_setup; /* Input of XCVR cell, HS driver output control */
 };
   /*
@@ -464,10 +466,21 @@ static int init_utmi_usb_controller(struct fdt_usb 
*config,
/* Recommended PHY settings for EYE diagram */
val = readl(>utmip_xcvr_cfg0);
-clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
-0x4 << UTMIP_XCVR_SETUP_SHIFT);
-clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
-0x3 << UTMIP_XCVR_SETUP_MSB_SHIFT);
+
+if (!config->xcvr_setup_use_fuses) {
+clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
+config->xcvr_setup <<
+UTMIP_XCVR_SETUP_SHIFT);
+clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
+config->xcvr_setup <<
+UTMIP_XCVR_SETUP_MSB_SHIFT);
+} else {
+clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
+0x4 << UTMIP_XCVR_SETUP_SHIFT);


What is this hard-coded value ?



0x4 and 0x3 (not same) but those are not in the device tree. Mainline linux
driver seems not set this at all if use_fuses is enabled but I decided to keep
original setup just to not cause regressions.

https://github.com/clamor-s/linux/blob/transformer/drivers/usb/phy/phy-tegra-usb.c#L587-L590


Why not place this value into config->xcvr_setup in e.g. probe() and drop this 
if/else statement ?



Because config->xcvr_setup should matter only if use_fuses is disabled


Can it matter always instead ?



No, it cannot. You are inversing hw design. Xcvr_setup matters only if 
use_fuses is disabled. If use_fuses is on (which is default state) xcvr values 
are taken from chip fuse.


The way I read this block of code is, some value is written into the register if 
config->xcvr_setup_use_fuses is false, another value if 
config->xcvr_setup_use_fuses is true . Why not do this determination once in probe 
and then just program the appropriate value instead ?


You are correct, I will remove those previous stuff.


+clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
+0x3 << UTMIP_XCVR_SETUP_MSB_SHIFT);
+}
+
clrsetbits_le32(, UTMIP_XCVR_HSSLEW_MSB_MASK,
0x8 << UTMIP_XCVR_HSSLEW_MSB_SHIFT);
writel(val, >utmip_xcvr_cfg0);
@@ -522,7 +535,9 @@ static int init_utmi_usb_controller(struct fdt_usb *config,
setbits_le32(>utmip_bat_chrg_cfg0, UTMIP_PD_CHRG);
clrbits_le32(>utmip_xcvr_cfg0, UTMIP_XCVR_LSBIAS_SE);
-setbits_le32(>utmip_spare_cfg0, FUSE_SETUP_SEL);
+
+if (config->xcvr_setup_use_fuses)
+setbits_le32(>utmip_spare_cfg0, FUSE_SETUP_SEL);
/*
 * Configure the UTMIP_IDLE_WAIT and UTMIP_ELASTIC_LIMIT
@@ -843,6 +858,8 @@ static const struct ehci_ops tegra_ehci_ops = {
 static int ehci_usb_of_to_plat(struct udevice *dev)
 {
struct fdt_usb *priv = dev_get_priv(dev);
+u32 usb_phy_phandle;
+ofnode usb_phy_node;
int ret;
ret = fdt_decode_usb(dev, priv);
@@ -851,6 +868,32 @@ static int ehci_usb_of_to_plat(struct udevice *dev)
priv->type = dev_get_driver_data(dev);
 +  ret = ofnode_read_u32(dev_ofnode(dev), "nvidia,phy", _phy_phandle);
+if (ret) {
+log_debug("%s: required usb phy node isn't provided\n", __func__);
+

Re: [PATCH v1 1/1] usb: host: tegra: implement dts based xcvr setup

2023-08-20 Thread Svyatoslav Ryhel



20 серпня 2023 р. 22:10:17 GMT+03:00, Marek Vasut  написав(-ла):
>On 8/20/23 20:32, Svyatoslav Ryhel wrote:
>> 20 серпня 2023 р. 21:14:15 GMT+03:00, Marek Vasut  
>> написав(-ла):
>>> On 8/20/23 09:13, Svyatoslav Ryhel wrote:
 20 серпня 2023 р. 05:23:14 GMT+03:00, Marek Vasut  
 написав(-ла):
> On 8/19/23 17:06, Svyatoslav Ryhel wrote:
>> Some devices (like ASUS TF201) may not have fuse based xcvr setup
>> which will result in not working USB line. To fix this situation
>> allow xcvr setup to be performed from device tree values if
>> nvidia,xcvr-setup-use-fuses is not defined.
>> 
>> Tested-by: Svyatoslav Ryhel  # ASUS TF201
> 
> I would hope so. Usually T-B tags are not added by the patch author, but 
> that's a detail, and here it has the added model value, so keep it.
> 
>> Signed-off-by: Svyatoslav Ryhel 
>> ---
>> drivers/usb/host/ehci-tegra.c | 53 
>> +++
>> 1 file changed, 48 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/usb/host/ehci-tegra.c 
>> b/drivers/usb/host/ehci-tegra.c
>> index 2cf1625670..f24baf8f0c 100644
>> --- a/drivers/usb/host/ehci-tegra.c
>> +++ b/drivers/usb/host/ehci-tegra.c
>> @@ -81,6 +81,8 @@ struct fdt_usb {
>>enum periph_id periph_id;/* peripheral id */
>>struct gpio_desc vbus_gpio; /* GPIO for vbus enable */
>>struct gpio_desc phy_reset_gpio; /* GPIO to reset ULPI phy */
>> +bool xcvr_setup_use_fuses; /* Indicates that the value is read from 
>> the on-chip fuses */
>> +u32 xcvr_setup; /* Input of XCVR cell, HS driver output control */
>> };
>>   /*
>> @@ -464,10 +466,21 @@ static int init_utmi_usb_controller(struct fdt_usb 
>> *config,
>>/* Recommended PHY settings for EYE diagram */
>>val = readl(>utmip_xcvr_cfg0);
>> -clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
>> -0x4 << UTMIP_XCVR_SETUP_SHIFT);
>> -clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
>> -0x3 << UTMIP_XCVR_SETUP_MSB_SHIFT);
>> +
>> +if (!config->xcvr_setup_use_fuses) {
>> +clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
>> +config->xcvr_setup <<
>> +UTMIP_XCVR_SETUP_SHIFT);
>> +clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
>> +config->xcvr_setup <<
>> +UTMIP_XCVR_SETUP_MSB_SHIFT);
>> +} else {
>> +clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
>> +0x4 << UTMIP_XCVR_SETUP_SHIFT);
> 
> What is this hard-coded value ?
> 
 
 0x4 and 0x3 (not same) but those are not in the device tree. Mainline linux
 driver seems not set this at all if use_fuses is enabled but I decided to 
 keep
 original setup just to not cause regressions.
 
 https://github.com/clamor-s/linux/blob/transformer/drivers/usb/phy/phy-tegra-usb.c#L587-L590
 
> Why not place this value into config->xcvr_setup in e.g. probe() and drop 
> this if/else statement ?
> 
 
 Because config->xcvr_setup should matter only if use_fuses is disabled
>>> 
>>> Can it matter always instead ?
>>> 
>> 
>> No, it cannot. You are inversing hw design. Xcvr_setup matters only if 
>> use_fuses is disabled. If use_fuses is on (which is default state) xcvr 
>> values are taken from chip fuse.
>
>The way I read this block of code is, some value is written into the register 
>if config->xcvr_setup_use_fuses is false, another value if 
>config->xcvr_setup_use_fuses is true . Why not do this determination once in 
>probe and then just program the appropriate value instead ?

You are correct, I will remove those previous stuff.

>> +clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
>> +0x3 << UTMIP_XCVR_SETUP_MSB_SHIFT);
>> +}
>> +
>>clrsetbits_le32(, UTMIP_XCVR_HSSLEW_MSB_MASK,
>>0x8 << UTMIP_XCVR_HSSLEW_MSB_SHIFT);
>>writel(val, >utmip_xcvr_cfg0);
>> @@ -522,7 +535,9 @@ static int init_utmi_usb_controller(struct fdt_usb 
>> *config,
>>setbits_le32(>utmip_bat_chrg_cfg0, UTMIP_PD_CHRG);
>>clrbits_le32(>utmip_xcvr_cfg0, UTMIP_XCVR_LSBIAS_SE);
>> -setbits_le32(>utmip_spare_cfg0, FUSE_SETUP_SEL);
>> +
>> +if (config->xcvr_setup_use_fuses)
>> +setbits_le32(>utmip_spare_cfg0, FUSE_SETUP_SEL);
>>/*
>> * Configure the UTMIP_IDLE_WAIT and UTMIP_ELASTIC_LIMIT
>> @@ -843,6 +858,8 @@ static const struct ehci_ops tegra_ehci_ops = {

Re: [PATCH v1 1/1] usb: host: tegra: implement dts based xcvr setup

2023-08-20 Thread Marek Vasut

On 8/20/23 20:32, Svyatoslav Ryhel wrote:

20 серпня 2023 р. 21:14:15 GMT+03:00, Marek Vasut  написав(-ла):

On 8/20/23 09:13, Svyatoslav Ryhel wrote:

20 серпня 2023 р. 05:23:14 GMT+03:00, Marek Vasut  написав(-ла):

On 8/19/23 17:06, Svyatoslav Ryhel wrote:

Some devices (like ASUS TF201) may not have fuse based xcvr setup
which will result in not working USB line. To fix this situation
allow xcvr setup to be performed from device tree values if
nvidia,xcvr-setup-use-fuses is not defined.

Tested-by: Svyatoslav Ryhel  # ASUS TF201


I would hope so. Usually T-B tags are not added by the patch author, but that's 
a detail, and here it has the added model value, so keep it.


Signed-off-by: Svyatoslav Ryhel 
---
drivers/usb/host/ehci-tegra.c | 53 +++
1 file changed, 48 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 2cf1625670..f24baf8f0c 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -81,6 +81,8 @@ struct fdt_usb {
   enum periph_id periph_id;/* peripheral id */
   struct gpio_desc vbus_gpio; /* GPIO for vbus enable */
   struct gpio_desc phy_reset_gpio; /* GPIO to reset ULPI phy */
+bool xcvr_setup_use_fuses; /* Indicates that the value is read from the 
on-chip fuses */
+u32 xcvr_setup; /* Input of XCVR cell, HS driver output control */
};
  /*
@@ -464,10 +466,21 @@ static int init_utmi_usb_controller(struct fdt_usb 
*config,
   /* Recommended PHY settings for EYE diagram */
   val = readl(>utmip_xcvr_cfg0);
-clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
-0x4 << UTMIP_XCVR_SETUP_SHIFT);
-clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
-0x3 << UTMIP_XCVR_SETUP_MSB_SHIFT);
+
+if (!config->xcvr_setup_use_fuses) {
+clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
+config->xcvr_setup <<
+UTMIP_XCVR_SETUP_SHIFT);
+clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
+config->xcvr_setup <<
+UTMIP_XCVR_SETUP_MSB_SHIFT);
+} else {
+clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
+0x4 << UTMIP_XCVR_SETUP_SHIFT);


What is this hard-coded value ?



0x4 and 0x3 (not same) but those are not in the device tree. Mainline linux
driver seems not set this at all if use_fuses is enabled but I decided to keep
original setup just to not cause regressions.

https://github.com/clamor-s/linux/blob/transformer/drivers/usb/phy/phy-tegra-usb.c#L587-L590


Why not place this value into config->xcvr_setup in e.g. probe() and drop this 
if/else statement ?



Because config->xcvr_setup should matter only if use_fuses is disabled


Can it matter always instead ?



No, it cannot. You are inversing hw design. Xcvr_setup matters only if 
use_fuses is disabled. If use_fuses is on (which is default state) xcvr values 
are taken from chip fuse.


The way I read this block of code is, some value is written into the 
register if config->xcvr_setup_use_fuses is false, another value if 
config->xcvr_setup_use_fuses is true . Why not do this determination 
once in probe and then just program the appropriate value instead ?



+clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
+0x3 << UTMIP_XCVR_SETUP_MSB_SHIFT);
+}
+
   clrsetbits_le32(, UTMIP_XCVR_HSSLEW_MSB_MASK,
   0x8 << UTMIP_XCVR_HSSLEW_MSB_SHIFT);
   writel(val, >utmip_xcvr_cfg0);
@@ -522,7 +535,9 @@ static int init_utmi_usb_controller(struct fdt_usb *config,
   setbits_le32(>utmip_bat_chrg_cfg0, UTMIP_PD_CHRG);
   clrbits_le32(>utmip_xcvr_cfg0, UTMIP_XCVR_LSBIAS_SE);
-setbits_le32(>utmip_spare_cfg0, FUSE_SETUP_SEL);
+
+if (config->xcvr_setup_use_fuses)
+setbits_le32(>utmip_spare_cfg0, FUSE_SETUP_SEL);
   /*
* Configure the UTMIP_IDLE_WAIT and UTMIP_ELASTIC_LIMIT
@@ -843,6 +858,8 @@ static const struct ehci_ops tegra_ehci_ops = {
static int ehci_usb_of_to_plat(struct udevice *dev)
{
   struct fdt_usb *priv = dev_get_priv(dev);
+u32 usb_phy_phandle;
+ofnode usb_phy_node;
   int ret;
   ret = fdt_decode_usb(dev, priv);
@@ -851,6 +868,32 @@ static int ehci_usb_of_to_plat(struct udevice *dev)
   priv->type = dev_get_driver_data(dev);
+  ret = ofnode_read_u32(dev_ofnode(dev), "nvidia,phy", _phy_phandle);
+if (ret) {
+log_debug("%s: required usb phy node isn't provided\n", __func__);
+priv->xcvr_setup_use_fuses = true;
+return 0;
+}
+
+usb_phy_node = ofnode_get_by_phandle(usb_phy_phandle);
+if (!ofnode_valid(usb_phy_node)) {
+log_err("%s: 

[PATCH v1 4/4] scripts/gen_compile_commands.py: add acknowledgments

2023-08-20 Thread Joao Marcos Costa
Add acknowledgments for porting and modifying the script. Of course, the
license, author, and copyright notice remain the same as in the original
script.

Signed-off-by: Joao Marcos Costa 
---
 scripts/gen_compile_commands.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/gen_compile_commands.py b/scripts/gen_compile_commands.py
index 63d036a773..1a9c49b34a 100755
--- a/scripts/gen_compile_commands.py
+++ b/scripts/gen_compile_commands.py
@@ -4,6 +4,7 @@
 # Copyright (C) Google LLC, 2018
 #
 # Author: Tom Roeder 
+# Ported and modified for U-Boot by Joao Marcos Costa 
 #
 """A tool for generating compile_commands.json in U-Boot."""
 
-- 
2.41.0



[PATCH v1 3/4] scripts/gen_compile_commands.py: fix docstring

2023-08-20 Thread Joao Marcos Costa
The referred tool is now in U-Boot. Replace "the Linux kernel" by
"U-Boot" to make the docstring coherent.

Signed-off-by: Joao Marcos Costa 
---
 scripts/gen_compile_commands.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gen_compile_commands.py b/scripts/gen_compile_commands.py
index 0227522959..63d036a773 100755
--- a/scripts/gen_compile_commands.py
+++ b/scripts/gen_compile_commands.py
@@ -5,7 +5,7 @@
 #
 # Author: Tom Roeder 
 #
-"""A tool for generating compile_commands.json in the Linux kernel."""
+"""A tool for generating compile_commands.json in U-Boot."""
 
 import argparse
 import json
-- 
2.41.0



[PATCH v1 2/4] scripts/gen_compile_commands.py: adapt _LINE_PATTERN

2023-08-20 Thread Joao Marcos Costa
For U-Boot's context, the regular expression defined by _LINE_PATTERN
should be adapted. Replace 'savedcmd' by 'cmd'.

Signed-off-by: Joao Marcos Costa 
---
 scripts/gen_compile_commands.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gen_compile_commands.py b/scripts/gen_compile_commands.py
index 15ba56527a..0227522959 100755
--- a/scripts/gen_compile_commands.py
+++ b/scripts/gen_compile_commands.py
@@ -19,7 +19,7 @@ _DEFAULT_OUTPUT = 'compile_commands.json'
 _DEFAULT_LOG_LEVEL = 'WARNING'
 
 _FILENAME_PATTERN = r'^\..*\.cmd$'
-_LINE_PATTERN = r'^savedcmd_[^ ]*\.o := (.* )([^ ]*\.c) *(;|$)'
+_LINE_PATTERN = r'^cmd_[^ ]*\.o := (.* )([^ ]*\.c) *(;|$)'
 _VALID_LOG_LEVELS = ['DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL']
 # The tools/ directory adopts a different build system, and produces .cmd
 # files in a different format. Do not support it.
-- 
2.41.0



[PATCH v1 1/4] scripts: Port Linux's gen_compile_commands.py to U-Boot

2023-08-20 Thread Joao Marcos Costa
This script generates a database of compiler flags, namely
compile_commands.json. It is quite useful for text editors that use
clangd LSP (e.g. Vim, Neovim).

It was ported from Linux's sources:
- tag: v6.4
- revision 6995e2de6891c724bfeb2db33d7b87775f913ad1

Modifications for U-Boot compatibility will be added in a follow-up
commit.

Signed-off-by: Joao Marcos Costa 
---
 scripts/gen_compile_commands.py | 228 
 1 file changed, 228 insertions(+)
 create mode 100755 scripts/gen_compile_commands.py

diff --git a/scripts/gen_compile_commands.py b/scripts/gen_compile_commands.py
new file mode 100755
index 00..15ba56527a
--- /dev/null
+++ b/scripts/gen_compile_commands.py
@@ -0,0 +1,228 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (C) Google LLC, 2018
+#
+# Author: Tom Roeder 
+#
+"""A tool for generating compile_commands.json in the Linux kernel."""
+
+import argparse
+import json
+import logging
+import os
+import re
+import subprocess
+import sys
+
+_DEFAULT_OUTPUT = 'compile_commands.json'
+_DEFAULT_LOG_LEVEL = 'WARNING'
+
+_FILENAME_PATTERN = r'^\..*\.cmd$'
+_LINE_PATTERN = r'^savedcmd_[^ ]*\.o := (.* )([^ ]*\.c) *(;|$)'
+_VALID_LOG_LEVELS = ['DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL']
+# The tools/ directory adopts a different build system, and produces .cmd
+# files in a different format. Do not support it.
+_EXCLUDE_DIRS = ['.git', 'Documentation', 'include', 'tools']
+
+def parse_arguments():
+"""Sets up and parses command-line arguments.
+
+Returns:
+log_level: A logging level to filter log output.
+directory: The work directory where the objects were built.
+ar: Command used for parsing .a archives.
+output: Where to write the compile-commands JSON file.
+paths: The list of files/directories to handle to find .cmd files.
+"""
+usage = 'Creates a compile_commands.json database from kernel .cmd files'
+parser = argparse.ArgumentParser(description=usage)
+
+directory_help = ('specify the output directory used for the kernel build '
+  '(defaults to the working directory)')
+parser.add_argument('-d', '--directory', type=str, default='.',
+help=directory_help)
+
+output_help = ('path to the output command database (defaults to ' +
+   _DEFAULT_OUTPUT + ')')
+parser.add_argument('-o', '--output', type=str, default=_DEFAULT_OUTPUT,
+help=output_help)
+
+log_level_help = ('the level of log messages to produce (defaults to ' +
+  _DEFAULT_LOG_LEVEL + ')')
+parser.add_argument('--log_level', choices=_VALID_LOG_LEVELS,
+default=_DEFAULT_LOG_LEVEL, help=log_level_help)
+
+ar_help = 'command used for parsing .a archives'
+parser.add_argument('-a', '--ar', type=str, default='llvm-ar', 
help=ar_help)
+
+paths_help = ('directories to search or files to parse '
+  '(files should be *.o, *.a, or modules.order). '
+  'If nothing is specified, the current directory is searched')
+parser.add_argument('paths', type=str, nargs='*', help=paths_help)
+
+args = parser.parse_args()
+
+return (args.log_level,
+os.path.abspath(args.directory),
+args.output,
+args.ar,
+args.paths if len(args.paths) > 0 else [args.directory])
+
+
+def cmdfiles_in_dir(directory):
+"""Generate the iterator of .cmd files found under the directory.
+
+Walk under the given directory, and yield every .cmd file found.
+
+Args:
+directory: The directory to search for .cmd files.
+
+Yields:
+The path to a .cmd file.
+"""
+
+filename_matcher = re.compile(_FILENAME_PATTERN)
+exclude_dirs = [ os.path.join(directory, d) for d in _EXCLUDE_DIRS ]
+
+for dirpath, dirnames, filenames in os.walk(directory, topdown=True):
+# Prune unwanted directories.
+if dirpath in exclude_dirs:
+dirnames[:] = []
+continue
+
+for filename in filenames:
+if filename_matcher.match(filename):
+yield os.path.join(dirpath, filename)
+
+
+def to_cmdfile(path):
+"""Return the path of .cmd file used for the given build artifact
+
+Args:
+Path: file path
+
+Returns:
+The path to .cmd file
+"""
+dir, base = os.path.split(path)
+return os.path.join(dir, '.' + base + '.cmd')
+
+
+def cmdfiles_for_a(archive, ar):
+"""Generate the iterator of .cmd files associated with the archive.
+
+Parse the given archive, and yield every .cmd file used to build it.
+
+Args:
+archive: The archive to parse
+
+Yields:
+The path to every .cmd file found
+"""
+for obj in subprocess.check_output([ar, '-t', archive]).decode().split():
+yield to_cmdfile(obj)
+
+
+def cmdfiles_for_modorder(modorder):
+"""Generate 

[PATCH v1 0/4] Port gen_compile_commands.py from Linux to U-Boot

2023-08-20 Thread Joao Marcos Costa
Hello U-Boot community,

I'm submitting a patch series that ports the gen_compile_commands.py
script from the Linux kernel's sources to U-Boot. This script, originally
located in scripts/clang-tools/gen_compile_commands.py, enables the
generation of compile_commands.json files for improved code navigation
and analysis. The series consists of four patches: the initial script
import and the necessary modifications for U-Boot compatibility.

Your feedback on these contributions would be greatly appreciated.

Best regards,

Joao Marcos Costa (4):
  scripts: Port Linux's gen_compile_commands.py to U-Boot
  scripts/gen_compile_commands.py: adapt _LINE_PATTERN
  scripts/gen_compile_commands.py: fix docstring
  scripts/gen_compile_commands.py: add acknowledgments

 scripts/gen_compile_commands.py | 229 
 1 file changed, 229 insertions(+)
 create mode 100755 scripts/gen_compile_commands.py

-- 
2.41.0



Re: [PATCH v1 1/1] usb: host: tegra: implement dts based xcvr setup

2023-08-20 Thread Svyatoslav Ryhel
20 серпня 2023 р. 21:14:15 GMT+03:00, Marek Vasut  написав(-ла):
>On 8/20/23 09:13, Svyatoslav Ryhel wrote:
>> 20 серпня 2023 р. 05:23:14 GMT+03:00, Marek Vasut  
>> написав(-ла):
>>> On 8/19/23 17:06, Svyatoslav Ryhel wrote:
 Some devices (like ASUS TF201) may not have fuse based xcvr setup
 which will result in not working USB line. To fix this situation
 allow xcvr setup to be performed from device tree values if
 nvidia,xcvr-setup-use-fuses is not defined.
 
 Tested-by: Svyatoslav Ryhel  # ASUS TF201
>>> 
>>> I would hope so. Usually T-B tags are not added by the patch author, but 
>>> that's a detail, and here it has the added model value, so keep it.
>>> 
 Signed-off-by: Svyatoslav Ryhel 
 ---
drivers/usb/host/ehci-tegra.c | 53 +++
1 file changed, 48 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
 index 2cf1625670..f24baf8f0c 100644
 --- a/drivers/usb/host/ehci-tegra.c
 +++ b/drivers/usb/host/ehci-tegra.c
 @@ -81,6 +81,8 @@ struct fdt_usb {
   enum periph_id periph_id;/* peripheral id */
   struct gpio_desc vbus_gpio; /* GPIO for vbus enable */
   struct gpio_desc phy_reset_gpio; /* GPIO to reset ULPI phy */
 +bool xcvr_setup_use_fuses; /* Indicates that the value is read from 
 the on-chip fuses */
 +u32 xcvr_setup; /* Input of XCVR cell, HS driver output control */
};
  /*
 @@ -464,10 +466,21 @@ static int init_utmi_usb_controller(struct fdt_usb 
 *config,
   /* Recommended PHY settings for EYE diagram */
   val = readl(>utmip_xcvr_cfg0);
 -clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
 -0x4 << UTMIP_XCVR_SETUP_SHIFT);
 -clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
 -0x3 << UTMIP_XCVR_SETUP_MSB_SHIFT);
 +
 +if (!config->xcvr_setup_use_fuses) {
 +clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
 +config->xcvr_setup <<
 +UTMIP_XCVR_SETUP_SHIFT);
 +clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
 +config->xcvr_setup <<
 +UTMIP_XCVR_SETUP_MSB_SHIFT);
 +} else {
 +clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
 +0x4 << UTMIP_XCVR_SETUP_SHIFT);
>>> 
>>> What is this hard-coded value ?
>>> 
>> 
>> 0x4 and 0x3 (not same) but those are not in the device tree. Mainline linux
>> driver seems not set this at all if use_fuses is enabled but I decided to 
>> keep
>> original setup just to not cause regressions.
>> 
>> https://github.com/clamor-s/linux/blob/transformer/drivers/usb/phy/phy-tegra-usb.c#L587-L590
>> 
>>> Why not place this value into config->xcvr_setup in e.g. probe() and drop 
>>> this if/else statement ?
>>> 
>> 
>> Because config->xcvr_setup should matter only if use_fuses is disabled
>
>Can it matter always instead ?
>

No, it cannot. You are inversing hw design. Xcvr_setup matters only if 
use_fuses is disabled. If use_fuses is on (which is default state) xcvr values 
are taken from chip fuse.

 +clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
 +0x3 << UTMIP_XCVR_SETUP_MSB_SHIFT);
 +}
 +
   clrsetbits_le32(, UTMIP_XCVR_HSSLEW_MSB_MASK,
   0x8 << UTMIP_XCVR_HSSLEW_MSB_SHIFT);
   writel(val, >utmip_xcvr_cfg0);
 @@ -522,7 +535,9 @@ static int init_utmi_usb_controller(struct fdt_usb 
 *config,
   setbits_le32(>utmip_bat_chrg_cfg0, UTMIP_PD_CHRG);
   clrbits_le32(>utmip_xcvr_cfg0, UTMIP_XCVR_LSBIAS_SE);
 -setbits_le32(>utmip_spare_cfg0, FUSE_SETUP_SEL);
 +
 +if (config->xcvr_setup_use_fuses)
 +setbits_le32(>utmip_spare_cfg0, FUSE_SETUP_SEL);
   /*
* Configure the UTMIP_IDLE_WAIT and UTMIP_ELASTIC_LIMIT
 @@ -843,6 +858,8 @@ static const struct ehci_ops tegra_ehci_ops = {
static int ehci_usb_of_to_plat(struct udevice *dev)
{
   struct fdt_usb *priv = dev_get_priv(dev);
 +u32 usb_phy_phandle;
 +ofnode usb_phy_node;
   int ret;
   ret = fdt_decode_usb(dev, priv);
 @@ -851,6 +868,32 @@ static int ehci_usb_of_to_plat(struct udevice *dev)
   priv->type = dev_get_driver_data(dev);
+  ret = ofnode_read_u32(dev_ofnode(dev), "nvidia,phy", 
 _phy_phandle);
 +if (ret) {
 +log_debug("%s: required usb phy node isn't provided\n", 
 __func__);
 +priv->xcvr_setup_use_fuses = true;
 +return 0;
 +}
 +
 

Re: [PATCH v1 1/1] usb: host: tegra: implement dts based xcvr setup

2023-08-20 Thread Marek Vasut

On 8/20/23 09:13, Svyatoslav Ryhel wrote:

20 серпня 2023 р. 05:23:14 GMT+03:00, Marek Vasut  написав(-ла):

On 8/19/23 17:06, Svyatoslav Ryhel wrote:

Some devices (like ASUS TF201) may not have fuse based xcvr setup
which will result in not working USB line. To fix this situation
allow xcvr setup to be performed from device tree values if
nvidia,xcvr-setup-use-fuses is not defined.

Tested-by: Svyatoslav Ryhel  # ASUS TF201


I would hope so. Usually T-B tags are not added by the patch author, but that's 
a detail, and here it has the added model value, so keep it.


Signed-off-by: Svyatoslav Ryhel 
---
   drivers/usb/host/ehci-tegra.c | 53 +++
   1 file changed, 48 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 2cf1625670..f24baf8f0c 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -81,6 +81,8 @@ struct fdt_usb {
  enum periph_id periph_id;/* peripheral id */
  struct gpio_desc vbus_gpio; /* GPIO for vbus enable */
  struct gpio_desc phy_reset_gpio; /* GPIO to reset ULPI phy */
+bool xcvr_setup_use_fuses; /* Indicates that the value is read from the 
on-chip fuses */
+u32 xcvr_setup; /* Input of XCVR cell, HS driver output control */
   };
 /*
@@ -464,10 +466,21 @@ static int init_utmi_usb_controller(struct fdt_usb 
*config,
  /* Recommended PHY settings for EYE diagram */
  val = readl(>utmip_xcvr_cfg0);
-clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
-0x4 << UTMIP_XCVR_SETUP_SHIFT);
-clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
-0x3 << UTMIP_XCVR_SETUP_MSB_SHIFT);
+
+if (!config->xcvr_setup_use_fuses) {
+clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
+config->xcvr_setup <<
+UTMIP_XCVR_SETUP_SHIFT);
+clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
+config->xcvr_setup <<
+UTMIP_XCVR_SETUP_MSB_SHIFT);
+} else {
+clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
+0x4 << UTMIP_XCVR_SETUP_SHIFT);


What is this hard-coded value ?



0x4 and 0x3 (not same) but those are not in the device tree. Mainline linux
driver seems not set this at all if use_fuses is enabled but I decided to keep
original setup just to not cause regressions.

https://github.com/clamor-s/linux/blob/transformer/drivers/usb/phy/phy-tegra-usb.c#L587-L590


Why not place this value into config->xcvr_setup in e.g. probe() and drop this 
if/else statement ?



Because config->xcvr_setup should matter only if use_fuses is disabled


Can it matter always instead ?


+clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
+0x3 << UTMIP_XCVR_SETUP_MSB_SHIFT);
+}
+
  clrsetbits_le32(, UTMIP_XCVR_HSSLEW_MSB_MASK,
  0x8 << UTMIP_XCVR_HSSLEW_MSB_SHIFT);
  writel(val, >utmip_xcvr_cfg0);
@@ -522,7 +535,9 @@ static int init_utmi_usb_controller(struct fdt_usb *config,
  setbits_le32(>utmip_bat_chrg_cfg0, UTMIP_PD_CHRG);
  clrbits_le32(>utmip_xcvr_cfg0, UTMIP_XCVR_LSBIAS_SE);
-setbits_le32(>utmip_spare_cfg0, FUSE_SETUP_SEL);
+
+if (config->xcvr_setup_use_fuses)
+setbits_le32(>utmip_spare_cfg0, FUSE_SETUP_SEL);
  /*
   * Configure the UTMIP_IDLE_WAIT and UTMIP_ELASTIC_LIMIT
@@ -843,6 +858,8 @@ static const struct ehci_ops tegra_ehci_ops = {
   static int ehci_usb_of_to_plat(struct udevice *dev)
   {
  struct fdt_usb *priv = dev_get_priv(dev);
+u32 usb_phy_phandle;
+ofnode usb_phy_node;
  int ret;
  ret = fdt_decode_usb(dev, priv);
@@ -851,6 +868,32 @@ static int ehci_usb_of_to_plat(struct udevice *dev)
  priv->type = dev_get_driver_data(dev);
   +  ret = ofnode_read_u32(dev_ofnode(dev), "nvidia,phy", _phy_phandle);
+if (ret) {
+log_debug("%s: required usb phy node isn't provided\n", __func__);
+priv->xcvr_setup_use_fuses = true;
+return 0;
+}
+
+usb_phy_node = ofnode_get_by_phandle(usb_phy_phandle);
+if (!ofnode_valid(usb_phy_node)) {
+log_err("%s: failed to find usb phy node\n", __func__);
+return -EINVAL;
+}


dev_read_phandle() should replace the above



Goal of this piece is to get phy of_node by the phandle provided in the
controller node. Controller node has not only single nvidia,phy phandle
reference but also clock and reset reference. How will dev_read_phandle
return me a phandle of "nvidia,phy"?

https://github.com/clamor-s/u-boot/blob/master/arch/arm/dts/tegra30.dtsi#L798-L834


+priv->xcvr_setup_use_fuses = ofnode_read_bool(
+usb_phy_node, "nvidia,xcvr-setup-use-fuses");


dev_read_bool()

Re: Dropping CONFIG_SCSI

2023-08-20 Thread Tom Rini
On Sun, Aug 20, 2023 at 11:49:21AM -0600, Simon Glass wrote:
> Hi,
> 
> The deadline has passed for the non-driver model SCSI code. The boards
> below still have this enabled:
> 
> $ ./tools/moveconfig.py -f SCSI ~DM_SCSI
> controlcenterdc am57xx_hs_evm_usb ls1088ardb_sdcard_qspi_SECURE_BOOT
> ls1046ardb_sdcard_SECURE_BOOT ls1021atsn_qspi ls1021atsn_sdcard
> highbank ls1021atwr_sdcard_ifc_SECURE_BOOT
> 
> Please can you take a look at migration?

For the layerscape configs that aren't to be removed by:
https://patchwork.ozlabs.org/project/uboot/patch/20230818134330.12509-2-laurentiu.tu...@nxp.com/
they're just out of sync with the other configs, and so can just be
enabled.

-- 
Tom


signature.asc
Description: PGP signature


Re: Dropping CONFIG_SCSI

2023-08-20 Thread Tom Rini
On Sun, Aug 20, 2023 at 11:49:21AM -0600, Simon Glass wrote:
> Hi,
> 
> The deadline has passed for the non-driver model SCSI code. The boards
> below still have this enabled:
> 
> $ ./tools/moveconfig.py -f SCSI ~DM_SCSI
> controlcenterdc am57xx_hs_evm_usb ls1088ardb_sdcard_qspi_SECURE_BOOT
> ls1046ardb_sdcard_SECURE_BOOT ls1021atsn_qspi ls1021atsn_sdcard
> highbank ls1021atwr_sdcard_ifc_SECURE_BOOT
> 
> Please can you take a look at migration?

Looking at am57xx_hs_evm_usb this is just a case where one of the
configs is out of sync with the rest as am57xx_evm and am57xx_hs_evm set
DM_SCSI.  Andrew, it might be worth looking at dropping
am57xx_hs_evm_usb specifically and adding a config fragment under
board/ti/am57xx/ for just the (I assume) SPL via USB case. And
dra7xx_evm can mirror that as well.

-- 
Tom


signature.asc
Description: PGP signature


Dropping CONFIG_SCSI

2023-08-20 Thread Simon Glass
Hi,

The deadline has passed for the non-driver model SCSI code. The boards
below still have this enabled:

$ ./tools/moveconfig.py -f SCSI ~DM_SCSI
controlcenterdc am57xx_hs_evm_usb ls1088ardb_sdcard_qspi_SECURE_BOOT
ls1046ardb_sdcard_SECURE_BOOT ls1021atsn_qspi ls1021atsn_sdcard
highbank ls1021atwr_sdcard_ifc_SECURE_BOOT

Please can you take a look at migration?

Thank you,
Simon


Re: [PATCH v3 12/19] x86: smbios: Add a Kconfig indicating SMBIOS-table presence

2023-08-20 Thread Simon Glass
Hi Heinrich,

On Sun, 20 Aug 2023 at 04:00, Heinrich Schuchardt  wrote:
>
> On 8/19/23 23:22, Simon Glass wrote:
> > When booted from coreboot, U-Boot does not build the SMBIOS tables, but
> > it should still pass them on to the OS. Add a new option which indicates
> > whether SMBIOS tables are present, however they were built.
> >
> > Flip the ordering so that the dependency is listed first, which is less
> > confusing.
> >
> > Adjust GENERATE_SMBIOS_TABLE to depend on this new symbol.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v3:
> > - Allow SMBIOS if EFI_LOADER is enabled
> > - Reword the help
> >
> > Changes in v2:
> > - Add new patch
> >
> >   lib/Kconfig | 15 ++-
> >   1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/Kconfig b/lib/Kconfig
> > index a9dca5f52b5a..8901b3a87fc2 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -984,8 +984,8 @@ config BLOBLIST_TABLES
> >
> >   config GENERATE_SMBIOS_TABLE
> >   bool "Generate an SMBIOS (System Management BIOS) table"
> > + depends on SMBIOS
> >   default y
> > - depends on X86 || EFI_LOADER
> >   help
> > The System Management BIOS (SMBIOS) specification addresses how
> > motherboard and system vendors present management information about
> > @@ -1054,6 +1054,19 @@ config SPL_OID_REGISTRY
> > unambiguous persistent name 
> > (https://en.wikipedia.org/wiki/Object_identifier).
> > Enable fast lookup object identifier registry in the SPL.
> >
> > +config SMBIOS
> > + bool "SMBIOS support"
> > + depends on X86 || EFI_LOADER
>
> Is there a calling convention for the legacy entry point of Linux to
> pass SMBIOS tables on arm64 and riscv64?
>
> > + default y
> > + help
> > +   Indicates that this platform can support System Management BIOS
> > +   (SMBIOS) tables. These provide various pieces of information about
> > +   the board, such as the manufacturer and the model name.
> > +
> > +   See GENERATE_SMBIOS_TABLE which controls whether U-Boot actually
> > +   creates these tables, rather than them coming from a previous 
> > firmware
>
> Thanks for updating the help text.
>
> This implies that CONFIG_SMBIOS must be used to decide if
> efi_smbios_register() is called in efi_init_obj_list(). This change is
> in patch 14/19.

Yes that's right, since we still need to install it if the platform uses SMBIOS.

>
>
> Reviewed-by: Heinrich Schuchardt 

Thanks for the review..unfortunately I found that on ARM (and probably
RISC-V) U-Boot does not create this table. On x86 last_state_init()
calls write_tables() to do this.

So I will have to adjust this...

Regards,
Simon


Re: [PATCH 03/17] configs: sandbox: Enable DM_USB_GADGET

2023-08-20 Thread Simon Glass
On Sat, 19 Aug 2023 at 08:24, Marek Vasut  wrote:
>
> Switch sandbox to DM_USB_GADGET, DM is the future.
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Angus Ainslie 
> Cc: Dmitrii Merkurev 
> Cc: Eddie Cai 
> Cc: Kever Yang 
> Cc: Lukasz Majewski 
> Cc: Miquel Raynal 
> Cc: Mattijs Korpershoek 
> Cc: Nishanth Menon 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Philipp Tomsich 
> Cc: Simon Glass 
> Cc: Stefan Roese 
> Cc: ker...@puri.sm
> ---
>  configs/sandbox64_defconfig| 1 +
>  configs/sandbox_defconfig  | 1 +
>  configs/sandbox_flattree_defconfig | 1 +
>  configs/sandbox_noinst_defconfig   | 1 +
>  configs/sandbox_spl_defconfig  | 1 +
>  configs/sandbox_vpl_defconfig  | 1 +
>  6 files changed, 6 insertions(+)

Reviewed-by: Simon Glass 


Re: [PATCH 02/17] usb: sandbox: Add DM_USB_GADGET support

2023-08-20 Thread Simon Glass
On Sat, 19 Aug 2023 at 08:24, Marek Vasut  wrote:
>
> Remove local usb_gadget_register_driver()/usb_gadget_unregister_driver()
> implementation which is implemented in udc-core.c instead if DM_USB_GADGET
> is enabled. Add no-op dm_usb_gadget_handle_interrupts() implementation.
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Angus Ainslie 
> Cc: Dmitrii Merkurev 
> Cc: Eddie Cai 
> Cc: Kever Yang 
> Cc: Lukasz Majewski 
> Cc: Miquel Raynal 
> Cc: Mattijs Korpershoek 
> Cc: Nishanth Menon 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Philipp Tomsich 
> Cc: Simon Glass 
> Cc: Stefan Roese 
> Cc: ker...@puri.sm
> ---
>  drivers/usb/host/usb-sandbox.c | 7 +++
>  1 file changed, 7 insertions(+)

Reviewed-by: Simon Glass 


Re: [PULL] u-boot-sh/master

2023-08-20 Thread Tom Rini
On Sun, Aug 20, 2023 at 03:43:28AM +0200, Marek Vasut wrote:

> The following changes since commit a5899cc69a99379f01e8e2f9f98e0e09b24f1656:
> 
>   Merge https://source.denx.de/u-boot/custodians/u-boot-watchdog (2023-08-10 
> 11:40:09 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-sh.git master
> 
> for you to fetch changes up to dbada49554edd16da39134815635fd0015725c9e:
> 
>   arm: rmobile: Fix off-by-one error in cpuinfo (2023-08-19 16:34:41 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: Pull request doc-2023-10-rc3-2

2023-08-20 Thread Tom Rini
On Sat, Aug 19, 2023 at 05:54:25AM +0200, Heinrich Schuchardt wrote:

> Dear Tom,
> 
> The following changes since commit e34efcf51df86eb2b07d9deb171596940586c666:
> 
>   rockchip: rk3566-anbernic-rgxx3: Rename defconfig to include SoC name
> (2023-08-18 10:25:03 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/doc-2023-10-rc3-2
> 
> for you to fetch changes up to 951d63000e2daf8b128139cfed343fe2b2da5a93:
> 
>   doc: csf_examples: csf.sh: Remove unneeded export ATF_LOAD_ADDR line
> (2023-08-19 04:12:53 +0200)
> 
> Gitlab CI showed no issues:
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/17431
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 4/4] CI: Drop some jobs we didn't really utilize

2023-08-20 Thread Tom Rini
- We have added more TODO/etc comments since this task was created and
  never focused on removing them.
- The output of sloccount isn't preserved or looked at, and if desired
  should be in the release stats pages instead somehow.
- The results of cppcheck aren't investigated and require modeling work
  to be useful to start with.

Signed-off-by: Tom Rini 
---
 .azure-pipelines.yml| 32 
 .gitlab-ci.yml  | 22 --
 tools/docker/Dockerfile |  2 --
 3 files changed, 56 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index e0ac7166d653..ad04f43b4339 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -67,16 +67,6 @@ stages:
   :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
   :^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
 
-  - job: cppcheck
-displayName: 'Static code analysis with cppcheck'
-pool:
-  vmImage: $(ubuntu_vm)
-container:
-  image: $(ci_runner_image)
-  options: $(container_option)
-steps:
-  - script: cppcheck -j$(nproc) --force --quiet --inline-suppr .
-
   - job: docs
 displayName: 'Build documentation'
 pool:
@@ -92,28 +82,6 @@ stages:
   make htmldocs KDOC_WERROR=1
   make infodocs
 
-  - job: todo
-displayName: 'Search for TODO within source tree'
-pool:
-  vmImage: $(ubuntu_vm)
-container:
-  image: $(ci_runner_image)
-  options: $(container_option)
-steps:
-  - script: grep -r TODO .
-  - script: grep -r FIXME .
-  - script: grep -r HACK . | grep -v HACKKIT
-
-  - job: sloccount
-displayName: 'Some statistics about the code base'
-pool:
-  vmImage: $(ubuntu_vm)
-container:
-  image: $(ci_runner_image)
-  options: $(container_option)
-steps:
-  - script: sloccount .
-
   - job: maintainers
 displayName: 'Ensure all configs have MAINTAINERS entries'
 pool:
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 7400d1225d9e..7f3ad40eae8d 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -151,22 +151,6 @@ check for new CONFIG symbols outside Kconfig:
 :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
 :^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
 
-# QA jobs for code analytics
-# static code analysis with cppcheck (we can add --enable=all later)
-cppcheck:
-  stage: testsuites
-  script:
-- cppcheck -j$(nproc) --force --quiet --inline-suppr .
-
-# search for TODO within source tree
-grep TODO/FIXME/HACK:
-  stage: testsuites
-  script:
-- grep -r TODO .
-- grep -r FIXME .
-# search for HACK within source tree and ignore HACKKIT board
-- grep -r HACK . | grep -v HACKKIT
-
 # build documentation
 docs:
   stage: testsuites
@@ -177,12 +161,6 @@ docs:
 - make htmldocs KDOC_WERROR=1
 - make infodocs
 
-# some statistics about the code base
-sloccount:
-  stage: testsuites
-  script:
-- sloccount .
-
 # ensure all configs have MAINTAINERS entries
 Check for configs without MAINTAINERS entry:
   stage: testsuites
diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
index 3d2b64a355f3..4d496700f1fd 100644
--- a/tools/docker/Dockerfile
+++ b/tools/docker/Dockerfile
@@ -42,7 +42,6 @@ RUN apt-get update && apt-get install -y \
clang-16 \
coreutils \
cpio \
-   cppcheck \
curl \
device-tree-compiler \
dosfstools \
@@ -104,7 +103,6 @@ RUN apt-get update && apt-get install -y \
python3-virtualenv \
rpm2cpio \
sbsigntool \
-   sloccount \
socat \
softhsm2 \
sparse \
-- 
2.34.1



[PATCH 3/4] CI: Combine tools-only and envtools jobs

2023-08-20 Thread Tom Rini
These jobs are to confirm specific build targets, on a Linux host.  We
can safely combine these two build tests, with a make mrproper in
between.

Signed-off-by: Tom Rini 
---
 .azure-pipelines.yml | 13 ++---
 .gitlab-ci.yml   | 12 
 2 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index ab3f961e01ee..e0ac7166d653 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -126,7 +126,7 @@ stages:
   ./tools/buildman/buildman --maintainer-check || exit 0
 
   - job: tools_only
-displayName: 'Ensure host tools build'
+displayName: 'Ensure host tools and env tools build'
 pool:
   vmImage: $(ubuntu_vm)
 container:
@@ -135,16 +135,7 @@ stages:
 steps:
   - script: |
   make tools-only_config tools-only -j$(nproc)
-
-  - job: envtools
-displayName: 'Ensure env tools build'
-pool:
-  vmImage: $(ubuntu_vm)
-container:
-  image: $(ci_runner_image)
-  options: $(container_option)
-steps:
-  - script: |
+  make mrproper
   make tools-only_config envtools -j$(nproc)
 
   - job: utils
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index d9f6b31792f3..7400d1225d9e 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -190,16 +190,12 @@ Check for configs without MAINTAINERS entry:
 - ./tools/buildman/buildman --maintainer-check || exit 0
 
 # Ensure host tools build
-Build tools-only:
+Build tools-only and envtools:
   stage: testsuites
   script:
-- make tools-only_config tools-only -j$(nproc)
-
-# Ensure env tools build
-Build envtools:
-  stage: testsuites
-  script:
-- make tools-only_config envtools -j$(nproc)
+- make tools-only_config tools-only -j$(nproc);
+  make mrproper;
+  make tools-only_config envtools -j$(nproc)
 
 Run binman, buildman, dtoc, Kconfig and patman testsuites:
   stage: testsuites
-- 
2.34.1



[PATCH 2/4] Azure: Rework build the world jobs

2023-08-20 Thread Tom Rini
Now that we have 3600 minutes per build job, condense and rework things
such that our overall time largely doesn't change, but we can also
largely avoid having to re-tweak this job to avoid timeouts.  Given that
we have 10 threads, we also move a few of the specific sandbox test
builds to a prior stage.

Note that while sandbox builds with address sanitization enabled (ASAN)
not all tests pass, so we limit ourselves to just checking that the
version test passes for now.

Link: 
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops=yaml#timeouts
Signed-off-by: Tom Rini 
---
Cc: Simon Glass 

I believe we merged ASAN with the intention of fixing some of the found
issues later, so this isn't really a functional change.
---
 .azure-pipelines.yml | 100 +++
 1 file changed, 25 insertions(+), 75 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index fc3188a806f4..ab3f961e01ee 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -254,9 +254,17 @@ stages:
   matrix:
 sandbox:
   TEST_PY_BD: "sandbox"
+sandbox_asan:
+  TEST_PY_BD: "sandbox"
+  OVERRIDE: "-a ASAN"
+  TEST_PY_TEST_SPEC: "version"
 sandbox_clang:
   TEST_PY_BD: "sandbox"
   OVERRIDE: "-O clang-16"
+sandbox_clang_asan:
+  TEST_PY_BD: "sandbox"
+  OVERRIDE: "-O clang-16 -a ASAN"
+  TEST_PY_TEST_SPEC: "version"
 sandbox_nolto:
   TEST_PY_BD: "sandbox"
   BUILD_ENV: "NO_LTO=1"
@@ -476,84 +484,26 @@ stages:
   # Use almost the same target division in .travis.yml, only merged
   # 3 small build jobs (arc/microblaze/xtensa) into one.
   matrix:
-arc_nios2_m68k_microblaze_xtensa:
-  BUILDMAN: "arc nios2 microblaze m68k xtensa"
-amlogic:
-  BUILDMAN: "amlogic"
-arm11_arm7_arm920t_arm946es:
-  BUILDMAN: "arm11 arm7 arm920t arm946es"
-arm926ejs:
-  BUILDMAN: "arm926ejs -x freescale,siemens,at91,kirkwood,omap"
-at91_non_armv7:
-  BUILDMAN: "at91 -x armv7"
-at91_non_arm926ejs:
-  BUILDMAN: "at91 -x arm926ejs"
-boundary_engicam_toradex:
-  BUILDMAN: "boundary engicam toradex"
-arm_bcm:
-  BUILDMAN: "bcm -x mips"
-nxp_arm32:
-  BUILDMAN: "freescale -x 
powerpc,m68k,aarch64,ls101,ls102,ls104,ls108,ls20,lx216"
-nxp_ls101x_ls108x:
-  BUILDMAN: "freescale freescale"
-nxp_ls102x:
-  BUILDMAN: "freescale -x keymile"
-nxp_ls104x:
-  BUILDMAN: "freescale"
-nxp_ls20xx_lx216x:
-  BUILDMAN: "freescale freescale"
-imx6:
-  BUILDMAN: "mx6 -x boundary,engicam,freescale,technexion,toradex"
+am33xx_at91_kirkwood_mvebu_omap:
+  BUILDMAN: "am33xx at91_kirkwood mvebu omap -x siemens"
+amlogic_bcm_boundary_engicam_siemens_technexion_oradex:
+  BUILDMAN: "amlogic bcm boundary engicam siemens technexion toradex 
-x mips"
+arm_nxp_minus_imx:
+  BUILDMAN: "freescale -x powerpc,m68k,imx,mx"
 imx:
-  BUILDMAN: "mx -x mx6,imx8,freescale,technexion,toradex"
-imx8_imx9:
-  BUILDMAN: "imx8 imx9 -x engicam,technexion,toradex"
-keymiles_siemens_technexion:
-  BUILDMAN: "keymile siemens technexion"
-keystone2_keystone3:
-  BUILDMAN: "k2 k3 -x siemens,toradex"
-sandbox_asan:
-  BUILDMAN: "sandbox"
-  OVERRIDE: "-a ASAN"
-sandbox_clang_asan:
-  BUILDMAN: "sandbox"
-  OVERRIDE: "-O clang-16 -a ASAN"
-samsung_socfpga_renesas:
-  BUILDMAN: "samsung socfpga renesas"
-sun4i_sun9i:
-  BUILDMAN: "sun4i sun9i"
-sun5i_sun6i:
-  BUILDMAN: "sun5i sun6i"
-sun7i:
-  BUILDMAN: "sun7i"
-sun8i:
-  BUILDMAN: "sun8i"
-sun50i:
-  BUILDMAN: "sun50i"
-arm_catch_all:
-  BUILDMAN: "arm -x 
arm11,arm7,arm9,aarch64,at91,bcm,freescale,kirkwood,mvebu,renesas,siemens,tegra,uniphier,mx,samsung,sunxi,am33xx,omap,toradex,socfpga,k2,k3,zynq"
-sandbox_x86:
-  BUILDMAN: "sandbox x86"
-kirkwood_mvebu_uniphier:
-  BUILDMAN: "kirkwood mvebu uniphier"
-mips:
-  BUILDMAN: "mips"
+  BUILDMAN: "mx imx -x boundary,engicam,technexion,toradex"
+rk:
+  BUILDMAN: "rk"
+sunxi:
+  BUILDMAN: "sunxi"
 powerpc:
-  BUILDMAN: "powerpc -x keymile"
-tegra:
-  BUILDMAN: "tegra -x toradex"
-am33xx_omap:
-  BUILDMAN: "am33xx omap -x siemens"
+  BUILDMAN: "powerpc"
+arm_catch_all:
+  BUILDMAN: "arm -x 
aarch64,am33xx,at91,bcm,ls1,kirkwood,mvebu,omap,rk,siemens,mx,sunxi,technexion,toradex"
 aarch64_catch_all:
-  BUILDMAN: "aarch64 -x 

[PATCH 1/4] Azure: Set the timeout for jobs to the maximum

2023-08-20 Thread Tom Rini
As per current Azure Pipelines documentation we qualify for 3600 minutes
per job, if specified, as the timeout. The default unspecified timeout
is 60 minutes. Rework things to specify 0 as the timeout (and so maximum
allowed) so that we don't have failures due to running slightly past 60
minutes total.

Link: 
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops=yaml#timeouts
Signed-off-by: Tom Rini 
---
 .azure-pipelines.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 61d4bf8c8e5f..fc3188a806f4 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -468,6 +468,7 @@ stages:
 - stage: world_build
   jobs:
   - job: build_the_world
+timeoutInMinutes: 0 # Use the maximum allowed
 displayName: 'Build the World'
 pool:
   vmImage: $(ubuntu_vm)
-- 
2.34.1



[PATCH 2/3] board: stm32f746-disco: refactor the display of the ST logo

2023-08-20 Thread Dario Binacchi
The patch removes the legacy mode of displaying the ST logo and adopts
the approach introduced by the commit 284b08fb51b6 ("board: stm32mp1: add
splash screen with stmicroelectronics logo"). It was necessary to use a
specific logo for the stm32f746-disco board.

Furthermore, the previous version didn't properly center the logo, hiding
its upper part.

Signed-off-by: Dario Binacchi 
---

 board/st/stm32f746-disco/stm32f746-disco.c |   6 --
 configs/stm32f746-disco_defconfig  |   2 +-
 configs/stm32f746-disco_spl_defconfig  |   2 +-
 include/configs/stm32f746-disco.h  |   7 ++-
 tools/logos/stm32f746-disco.bmp| Bin 0 -> 18052 bytes
 5 files changed, 8 insertions(+), 9 deletions(-)
 create mode 100644 tools/logos/stm32f746-disco.bmp

diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
b/board/st/stm32f746-disco/stm32f746-disco.c
index 4cfb29ef428b..0f9666008430 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -134,10 +133,5 @@ int board_init(void)
}
 #endif
 
-#if defined(CONFIG_CMD_BMP)
-   bmp_display((ulong)stmicroelectronics_uboot_logo_8bit_rle,
-   BMP_ALIGN_CENTER, BMP_ALIGN_CENTER);
-#endif /* CONFIG_CMD_BMP */
-
return 0;
 }
diff --git a/configs/stm32f746-disco_defconfig 
b/configs/stm32f746-disco_defconfig
index 8403679d7fa6..2ca4aaf96eb6 100644
--- a/configs/stm32f746-disco_defconfig
+++ b/configs/stm32f746-disco_defconfig
@@ -56,13 +56,13 @@ CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_STM32_QSPI=y
 CONFIG_VIDEO=y
+CONFIG_VIDEO_LOGO=y
 CONFIG_BACKLIGHT_GPIO=y
 CONFIG_VIDEO_STM32=y
 CONFIG_VIDEO_STM32_MAX_XRES=480
 CONFIG_VIDEO_STM32_MAX_YRES=272
 CONFIG_SPLASH_SCREEN=y
 CONFIG_SPLASH_SCREEN_ALIGN=y
-CONFIG_VIDEO_BMP_RLE8=y
 CONFIG_BMP_16BPP=y
 CONFIG_BMP_24BPP=y
 CONFIG_BMP_32BPP=y
diff --git a/configs/stm32f746-disco_spl_defconfig 
b/configs/stm32f746-disco_spl_defconfig
index 50c2a36784af..b0afe42433a4 100644
--- a/configs/stm32f746-disco_spl_defconfig
+++ b/configs/stm32f746-disco_spl_defconfig
@@ -82,13 +82,13 @@ CONFIG_DM_SPI=y
 CONFIG_STM32_QSPI=y
 CONFIG_SPL_TIMER=y
 CONFIG_VIDEO=y
+CONFIG_VIDEO_LOGO=y
 CONFIG_BACKLIGHT_GPIO=y
 CONFIG_VIDEO_STM32=y
 CONFIG_VIDEO_STM32_MAX_XRES=480
 CONFIG_VIDEO_STM32_MAX_YRES=272
 CONFIG_SPLASH_SCREEN=y
 CONFIG_SPLASH_SCREEN_ALIGN=y
-CONFIG_VIDEO_BMP_RLE8=y
 CONFIG_BMP_16BPP=y
 CONFIG_BMP_24BPP=y
 CONFIG_BMP_32BPP=y
diff --git a/include/configs/stm32f746-disco.h 
b/include/configs/stm32f746-disco.h
index 9bf01cac47a4..00ec9efba577 100644
--- a/include/configs/stm32f746-disco.h
+++ b/include/configs/stm32f746-disco.h
@@ -23,6 +23,10 @@
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0)
 
+#define STM32F746_BOARD_EXTRA_ENV \
+   "splashimage=0xC0448000\0" \
+   "splashpos=m,m\0"
+
 #include 
 #define CFG_EXTRA_ENV_SETTINGS \
"kernel_addr_r=0xC0008000\0"\
@@ -31,7 +35,8 @@
"scriptaddr=0xC0418000\0"   \
"pxefile_addr_r=0xC0428000\0" \
"ramdisk_addr_r=0xC0438000\0"   \
-   BOOTENV
+   BOOTENV \
+   STM32F746_BOARD_EXTRA_ENV
 
 #define CFG_SYS_UBOOT_BASE (CFG_SYS_FLASH_BASE + \
 CONFIG_SPL_PAD_TO)
diff --git a/tools/logos/stm32f746-disco.bmp b/tools/logos/stm32f746-disco.bmp
new file mode 100644
index 
..c1ef4fb035c0833ea22aaa7d8aef1f0f4129d7fa
GIT binary patch
literal 18052
zcmchf2Y8iL*6;T^5poi8NK8n81VT+AV1$GgNFV_r0)~)KrH0;nZ_;~}-g_6RN*9q{
zRg^AB2SLR$ws8vgxAr+O=yhg3yw7)i29kI0wbowyzv|xa%T!4lUESFKCca?I5PrKM
z#su(3jFUgc{F-9SybA6=c0dQs<0t>K4^>h#drv#~V|2!@@Zj(XqhK=(;wkXC6NI
z!u;^V4`#)}dFJ!0pPA1tUox#~rkF=xe{FiUXk@1_HD6@ahF4LuPrdc*`j%iUX(fs`L_=1j^@jU56!@iZOoPp>?K6!MW6jrJ
zerdjW^vJZUlWP9{_rIBsPoFZY7cVqt$D@@8;{TzA}quPB$ly9x*pQzh-)6H8yQ(
zS2JfnJYzPjTy8qlOEX!imCUh22f^SMvuWKL)B3fl=GteUnWiaaSo!(Jow@ZGk3~FGo)(=vv21P)2V*Cd2iQFbLG-Svu)!B^Amgf?%Qw8
zq4)QjPe1<1Oc*-Q4C~p&{0JuBefO<7bMl1QyW?GR`Qin0^xy|(K>Jo^)uIKaaiuu0
zy=rdXx@qp-xor*~*l$i9J8GI$Esy@6o7t1bn>)8|nT0c^neV^<+;nbO$9x4g
zKmGWl88fi288^7Ud82!0)2DSa^Tqvp=KkHgX8YT3nFsgpo9@jTfcIsy=bi0l>Zsx7
z?XtyY#e%u!$Oi|^^7(Vv+kLZc*%I^Nsgvg7`E%wgFn)LQCbN3UB6IHS$7WQ&
zUgp+~>*m6zpP0d&+nIMZzirm9SZ3BNU1Y`&8DLI;^^fSXjWwr_9ck{}y<=|QykQ<;
zixWo5sgv-Tt7hq(S!ThTQ_bn)
z$IOl`o6O?bGr;T}Z1sWJuxh!PF@Cf;uy>D{KYfZhxPPD7ynZcsy>GU@wcbp8V-WhE
zF!%1RdjPbg7%6LhqRZeP{+z`IqG9%q%2|=-V!1w
zq><9hQyOO}`?om!3b*U9cg4{m2Bk#!j(n4O4w`7J?U>!fk-SX?N5>>c|>t#(t(_qbBmQd?Ta8LCtky;~7YK32FXt`m@Im
zpGbW{_gqZ!u#;EOH4r;gfbuOQwUCYMx*6!t$6ii(O615+Dd8sx{JIgeW99zALqtjb$mD;-9^rUfD@}+lM+0YW>jZN
zLsNiNST(yryB@M%)=4^1;wx{+ENnN>;t|C9CGp%ic3nsuAQUJSL2I-;%
z775p2q9a-Sz-p+h1#zWFAR>=}_;z$Dz*vm6kSi3%Pc~wfuS}^X(4#vu4kPBo7e(a!?RF!ljl>m$4NKRth#rP#8

[PATCH 1/3] configs: stm32f746-disco: limit resolution to 480x272

2023-08-20 Thread Dario Binacchi
The patch fixes the y-resolution, which was causing the creation of a
framebuffer larger than actually needed, resulting in memory waste.

Fixes: cc1b0e7b8e55b ("board: Add display to STM32F746 SoC discovery board")
Signed-off-by: Dario Binacchi 
---

 configs/stm32f746-disco_defconfig | 2 +-
 configs/stm32f746-disco_spl_defconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configs/stm32f746-disco_defconfig 
b/configs/stm32f746-disco_defconfig
index bb98ee307a6e..8403679d7fa6 100644
--- a/configs/stm32f746-disco_defconfig
+++ b/configs/stm32f746-disco_defconfig
@@ -59,7 +59,7 @@ CONFIG_VIDEO=y
 CONFIG_BACKLIGHT_GPIO=y
 CONFIG_VIDEO_STM32=y
 CONFIG_VIDEO_STM32_MAX_XRES=480
-CONFIG_VIDEO_STM32_MAX_YRES=640
+CONFIG_VIDEO_STM32_MAX_YRES=272
 CONFIG_SPLASH_SCREEN=y
 CONFIG_SPLASH_SCREEN_ALIGN=y
 CONFIG_VIDEO_BMP_RLE8=y
diff --git a/configs/stm32f746-disco_spl_defconfig 
b/configs/stm32f746-disco_spl_defconfig
index 84aaec1e3390..50c2a36784af 100644
--- a/configs/stm32f746-disco_spl_defconfig
+++ b/configs/stm32f746-disco_spl_defconfig
@@ -85,7 +85,7 @@ CONFIG_VIDEO=y
 CONFIG_BACKLIGHT_GPIO=y
 CONFIG_VIDEO_STM32=y
 CONFIG_VIDEO_STM32_MAX_XRES=480
-CONFIG_VIDEO_STM32_MAX_YRES=640
+CONFIG_VIDEO_STM32_MAX_YRES=272
 CONFIG_SPLASH_SCREEN=y
 CONFIG_SPLASH_SCREEN_ALIGN=y
 CONFIG_VIDEO_BMP_RLE8=y
-- 
2.34.1



[PATCH v3] board: rockchip: Add Bananapi R2Pro Board

2023-08-20 Thread Frank Wunderlich
From: Frank Wunderlich 

Add Bananapi R2 Pro board.

Till now evb dts could be used, but iodomain is different
(evb has 1v8 on vccio2 and vccio4 which are 3v3 on r2pro)
and with iodomain driver this can cause hardware fault.

Devicetree in mainline-Linux:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts

Signed-off-by: Frank Wunderlich 
---
v3:
- disable gmac0 as switch-driver is not yet ready to attach to the mac
v2:
- drop switch-node for now as u-boot driver works differently to linux
---
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi |  23 +
 arch/arm/dts/rk3568-bpi-r2pro.dts | 549 ++
 configs/bpi-r2pro-rk3568_defconfig| 101 
 4 files changed, 675 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts
 create mode 100644 configs/bpi-r2pro-rk3568_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bd518064f35f..767bf9db39fb 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -182,7 +182,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3568-nanopi-r5s.dtb \
rk3568-odroid-m1.dtb \
rk3568-radxa-e25.dtb \
-   rk3568-rock-3a.dtb
+   rk3568-rock-3a.dtb \
+   rk3568-bpi-r2pro.dtb
 
 dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
diff --git a/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi 
b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
new file mode 100644
index ..382a52a28b10
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+   chosen {
+   stdout-path = 
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   clock-frequency = <2400>;
+   bootph-pre-ram;
+   status = "okay";
+};
diff --git a/arch/arm/dts/rk3568-bpi-r2pro.dts 
b/arch/arm/dts/rk3568-bpi-r2pro.dts
new file mode 100644
index ..e4fcbb8a1174
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2pro.dts
@@ -0,0 +1,549 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Author: Frank Wunderlich 
+ *
+ */
+
+/dts-v1/;
+#include 
+#include 
+#include 
+#include "rk3568.dtsi"
+
+/ {
+   model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
+   compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568";
+
+   aliases {
+   ethernet0 = 
+   ethernet1 = 
+   mmc0 = 
+   mmc1 = 
+   };
+
+   chosen: chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_led_pin _led_pin>;
+
+   blue_led: led-0 {
+   color = ;
+   default-state = "off";
+   function = LED_FUNCTION_STATUS;
+   gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
+   };
+
+   green_led: led-1 {
+   color = ;
+   default-state = "on";
+   function = LED_FUNCTION_POWER;
+   gpios = < RK_PD5 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   dc_12v: dc-12v-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "dc_12v";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   vcc3v3_sys: vcc3v3-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_12v>;
+   };
+
+   vcc5v0_sys: vcc5v0-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_12v>;
+   };
+
+   vcc5v0_usb: vcc5v0-usb-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_usb";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_12v>;
+   };
+
+   vcc5v0_usb_host: vcc5v0-usb-host-regulator {
+   

Re: [PATCH v3 12/19] x86: smbios: Add a Kconfig indicating SMBIOS-table presence

2023-08-20 Thread Heinrich Schuchardt

On 8/19/23 23:22, Simon Glass wrote:

When booted from coreboot, U-Boot does not build the SMBIOS tables, but
it should still pass them on to the OS. Add a new option which indicates
whether SMBIOS tables are present, however they were built.

Flip the ordering so that the dependency is listed first, which is less
confusing.

Adjust GENERATE_SMBIOS_TABLE to depend on this new symbol.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Allow SMBIOS if EFI_LOADER is enabled
- Reword the help

Changes in v2:
- Add new patch

  lib/Kconfig | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/lib/Kconfig b/lib/Kconfig
index a9dca5f52b5a..8901b3a87fc2 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -984,8 +984,8 @@ config BLOBLIST_TABLES

  config GENERATE_SMBIOS_TABLE
bool "Generate an SMBIOS (System Management BIOS) table"
+   depends on SMBIOS
default y
-   depends on X86 || EFI_LOADER
help
  The System Management BIOS (SMBIOS) specification addresses how
  motherboard and system vendors present management information about
@@ -1054,6 +1054,19 @@ config SPL_OID_REGISTRY
  unambiguous persistent name 
(https://en.wikipedia.org/wiki/Object_identifier).
  Enable fast lookup object identifier registry in the SPL.

+config SMBIOS
+   bool "SMBIOS support"
+   depends on X86 || EFI_LOADER


Is there a calling convention for the legacy entry point of Linux to
pass SMBIOS tables on arm64 and riscv64?


+   default y
+   help
+ Indicates that this platform can support System Management BIOS
+ (SMBIOS) tables. These provide various pieces of information about
+ the board, such as the manufacturer and the model name.
+
+ See GENERATE_SMBIOS_TABLE which controls whether U-Boot actually
+ creates these tables, rather than them coming from a previous firmware


Thanks for updating the help text.

This implies that CONFIG_SMBIOS must be used to decide if
efi_smbios_register() is called in efi_init_obj_list(). This change is
in patch 14/19.

Reviewed-by: Heinrich Schuchardt 


+ stage.
+
  config SMBIOS_PARSER
bool "SMBIOS parser"
hel


Re: [PATCH] ARM: rmobile: Clean up rmobile_cpuinfo_idx()

2023-08-20 Thread Paul Barker
On 19/08/2023 15:39, Marek Vasut wrote:
> Clean the function up a bit further. Return immediatelly on match
> and return ARRAY_SIZE() - 1 on failure. Add proper comment in that
> case.
> 
> Signed-off-by: Marek Vasut 
> ---
> Cc: Biju Das 
> Cc: Paul Barker 
> ---
>  arch/arm/mach-rmobile/cpu_info.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-rmobile/cpu_info.c 
> b/arch/arm/mach-rmobile/cpu_info.c
> index 7651e43bd0f..6804b1da2cd 100644
> --- a/arch/arm/mach-rmobile/cpu_info.c
> +++ b/arch/arm/mach-rmobile/cpu_info.c
> @@ -83,14 +83,15 @@ static const struct {
>  
>  static int rmobile_cpuinfo_idx(void)
>  {
> - int i = 0;
>   u32 cpu_type = rmobile_get_cpu_type();
> + int i;
>  
> - for (; i < ARRAY_SIZE(rmobile_cpuinfo) - 1; i++)
> + for (i = 0; i < ARRAY_SIZE(rmobile_cpuinfo) - 1; i++)
>   if (rmobile_cpuinfo[i].cpu_type == cpu_type)
> - break;
> + return i;
>  
> - return i;
> + /* Unknown "CPU" entry */
> + return ARRAY_SIZE(rmobile_cpuinfo) - 1;
>  }
>  
>  static const u8 *get_cpu_name(int idx)

Reviewed-by: Paul Barker 

OpenPGP_0x27F4B3459F002257.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH v1 1/1] usb: host: tegra: implement dts based xcvr setup

2023-08-20 Thread Svyatoslav Ryhel
20 серпня 2023 р. 05:23:14 GMT+03:00, Marek Vasut  написав(-ла):
>On 8/19/23 17:06, Svyatoslav Ryhel wrote:
>> Some devices (like ASUS TF201) may not have fuse based xcvr setup
>> which will result in not working USB line. To fix this situation
>> allow xcvr setup to be performed from device tree values if
>> nvidia,xcvr-setup-use-fuses is not defined.
>>
>> Tested-by: Svyatoslav Ryhel  # ASUS TF201
>
>I would hope so. Usually T-B tags are not added by the patch author, but 
>that's a detail, and here it has the added model value, so keep it.
>
>> Signed-off-by: Svyatoslav Ryhel 
>> ---
>>   drivers/usb/host/ehci-tegra.c | 53 +++
>>   1 file changed, 48 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
>> index 2cf1625670..f24baf8f0c 100644
>> --- a/drivers/usb/host/ehci-tegra.c
>> +++ b/drivers/usb/host/ehci-tegra.c
>> @@ -81,6 +81,8 @@ struct fdt_usb {
>>  enum periph_id periph_id;/* peripheral id */
>>  struct gpio_desc vbus_gpio; /* GPIO for vbus enable */
>>  struct gpio_desc phy_reset_gpio; /* GPIO to reset ULPI phy */
>> +bool xcvr_setup_use_fuses; /* Indicates that the value is read from the 
>> on-chip fuses */
>> +u32 xcvr_setup; /* Input of XCVR cell, HS driver output control */
>>   };
>> /*
>> @@ -464,10 +466,21 @@ static int init_utmi_usb_controller(struct fdt_usb 
>> *config,
>>  /* Recommended PHY settings for EYE diagram */
>>  val = readl(>utmip_xcvr_cfg0);
>> -clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
>> -0x4 << UTMIP_XCVR_SETUP_SHIFT);
>> -clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
>> -0x3 << UTMIP_XCVR_SETUP_MSB_SHIFT);
>> +
>> +if (!config->xcvr_setup_use_fuses) {
>> +clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
>> +config->xcvr_setup <<
>> +UTMIP_XCVR_SETUP_SHIFT);
>> +clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
>> +config->xcvr_setup <<
>> +UTMIP_XCVR_SETUP_MSB_SHIFT);
>> +} else {
>> +clrsetbits_le32(, UTMIP_XCVR_SETUP_MASK,
>> +0x4 << UTMIP_XCVR_SETUP_SHIFT);
>
>What is this hard-coded value ?
>

0x4 and 0x3 (not same) but those are not in the device tree. Mainline linux
driver seems not set this at all if use_fuses is enabled but I decided to keep
original setup just to not cause regressions.

https://github.com/clamor-s/linux/blob/transformer/drivers/usb/phy/phy-tegra-usb.c#L587-L590

>Why not place this value into config->xcvr_setup in e.g. probe() and drop this 
>if/else statement ?
>

Because config->xcvr_setup should matter only if use_fuses is disabled

>> +clrsetbits_le32(, UTMIP_XCVR_SETUP_MSB_MASK,
>> +0x3 << UTMIP_XCVR_SETUP_MSB_SHIFT);
>> +}
>> +
>>  clrsetbits_le32(, UTMIP_XCVR_HSSLEW_MSB_MASK,
>>  0x8 << UTMIP_XCVR_HSSLEW_MSB_SHIFT);
>>  writel(val, >utmip_xcvr_cfg0);
>> @@ -522,7 +535,9 @@ static int init_utmi_usb_controller(struct fdt_usb 
>> *config,
>>  setbits_le32(>utmip_bat_chrg_cfg0, UTMIP_PD_CHRG);
>>  clrbits_le32(>utmip_xcvr_cfg0, UTMIP_XCVR_LSBIAS_SE);
>> -setbits_le32(>utmip_spare_cfg0, FUSE_SETUP_SEL);
>> +
>> +if (config->xcvr_setup_use_fuses)
>> +setbits_le32(>utmip_spare_cfg0, FUSE_SETUP_SEL);
>>  /*
>>   * Configure the UTMIP_IDLE_WAIT and UTMIP_ELASTIC_LIMIT
>> @@ -843,6 +858,8 @@ static const struct ehci_ops tegra_ehci_ops = {
>>   static int ehci_usb_of_to_plat(struct udevice *dev)
>>   {
>>  struct fdt_usb *priv = dev_get_priv(dev);
>> +u32 usb_phy_phandle;
>> +ofnode usb_phy_node;
>>  int ret;
>>  ret = fdt_decode_usb(dev, priv);
>> @@ -851,6 +868,32 @@ static int ehci_usb_of_to_plat(struct udevice *dev)
>>  priv->type = dev_get_driver_data(dev);
>>   +  ret = ofnode_read_u32(dev_ofnode(dev), "nvidia,phy", _phy_phandle);
>> +if (ret) {
>> +log_debug("%s: required usb phy node isn't provided\n", 
>> __func__);
>> +priv->xcvr_setup_use_fuses = true;
>> +return 0;
>> +}
>> +
>> +usb_phy_node = ofnode_get_by_phandle(usb_phy_phandle);
>> +if (!ofnode_valid(usb_phy_node)) {
>> +log_err("%s: failed to find usb phy node\n", __func__);
>> +return -EINVAL;
>> +}
>
>dev_read_phandle() should replace the above
>

Goal of this piece is to get phy of_node by the phandle provided in the
controller node. Controller node has not only single nvidia,phy phandle
reference but also clock and reset reference. How will dev_read_phandle
return me a phandle of "nvidia,phy"?