Re: [PATCH] arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on DHCOM

2022-06-30 Thread Marek Vasut

On 6/30/22 16:19, Johann Neuhauser wrote:

PA13 and PA14 are used for USB power control and can't be used
to enforce fastboot or stm32prog mode by pressing a button.

Defining CONFIG_FASTBOOT/CONFIG_CMD_STM32PROG without this patch applied
results in fastboot/stm32prog always starting, because PA13/PA14 are always
low during boot. So drop the wrong trigger gpios definitions.

Signed-off-by: Johann Neuhauser 


Those GPIOs also likely make no sense on DHCOM , right ?

Reviewed-by: Marek Vasut 


[PATCH] tools: imx8mimage: Keep IVT reserved1 field zero always

2022-06-29 Thread Marek Vasut
Since fe8acf556c3 ("imx: HAB: Validate IVT before authenticating image")
the U-Boot HAB implementation is checking whether reserved1 field in IVT
is zero or not. In case the field is not zero, IVT validation fails. Stop
setting IVT reserved1 field to non-zero in mkimage imx8m plugin, otherwise
the validation cannot ever work.

Note that this only affects legacy boards which do not use binman.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 tools/imx8mimage.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/tools/imx8mimage.c b/tools/imx8mimage.c
index 4eed683396f..52baf4c9903 100644
--- a/tools/imx8mimage.c
+++ b/tools/imx8mimage.c
@@ -505,14 +505,6 @@ void build_image(int ofd)
exit(EXIT_FAILURE);
} else {
sld_header_off = sld_src_off - rom_image_offset;
-   /*
-* Record the second bootloader relative offset in
-* image's IVT reserved1
-*/
-   if (rom_version == ROM_V1) {
-   imx_header[IMAGE_IVT_ID].fhdr.reserved1 =
-   sld_header_off - header_image_off;
-   }
sld_fd = open(sld_img, O_RDONLY | O_BINARY);
if (sld_fd < 0) {
fprintf(stderr, "%s: Can't open: %s\n",
-- 
2.35.1



Re: [PATCH v1] usb: host: nuvoton: Add nuvoton NPCM7xx ehci/ohci driver

2022-06-29 Thread Marek Vasut

On 6/29/22 03:31, Jim Liu wrote:

Hi Marek


Hi,


no, not yet.

I will add i2c otp aes sha pinctrl usb spi mmc feature to
poleg_evb_defconfig  in the last commit.

about the usb patch if you have any suggestion or need modify please
let me know.


The usb patch is already in usb/next , thanks.


Re: [PATCH v2] usb: dwc3: Add support to reset usb ULPI phy

2022-06-29 Thread Marek Vasut

On 3/4/22 13:47, Michal Simek wrote:

From: T Karthik Reddy 

When usb PHY initialization is done, the PHY need to be reset.


The CI is failing on this one:

https://source.denx.de/u-boot/custodians/u-boot-usb/-/jobs/457563


Re: [PATCH v4 1/3] usb: common: move urb code to common

2022-06-29 Thread Marek Vasut

On 6/28/22 19:42, Rui Miguel Silva wrote:

Move urb code from musb only use to a more common scope, so other
drivers in the future can use the handling of urb in usb.


I'm afraid this broke at least one driver, see:

https://source.denx.de/u-boot/custodians/u-boot-usb/-/jobs/457939

Either send a smaller patch and I can squash it, or send V5 of the 
series, as you wish.


Re: [PATCH 2/2] pmic: pca9450: clear PRESET_EN bit for BUCK1/2/3 voltage settings

2022-06-28 Thread Marek Vasut

On 6/28/22 22:02, Fabio Estevam wrote:

On 28/06/2022 11:06, Heiko Thiery wrote:

The regulator driver uses the DVS registers PCA9450_REG_BUCKxOUT_DVS0 to
set the voltage for the buck regulators 1, 2 and 3. This has no effect 
as the

PRESET_EN bit is set by default and therefore the preset values are used
instead, which are set to 850 mV.

This is a port of the same change in the Linux kernel:
98b94b6e38ca0 ("regulator: pca9450: Clear PRESET_EN bit to fix
BUCK1/2/3 voltage setting")

Cc: Frieder Schrempf 
Signed-off-by: Heiko Thiery 
---
 drivers/power/pmic/pca9450.c | 6 ++
 include/power/pca9450.h  | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/power/pmic/pca9450.c b/drivers/power/pmic/pca9450.c
index fecab0496f..1c59362ab4 100644
--- a/drivers/power/pmic/pca9450.c
+++ b/drivers/power/pmic/pca9450.c
@@ -94,6 +94,12 @@ static int pca9450_probe(struct udevice *dev)

 priv->regmap = syscon_node_to_regmap(dev_ofnode(dev));

+    /* Clear PRESET_EN bit in BUCK123_DVS to use DVS registers */
+    if (CONFIG_IS_ENABLED(DM_REGULATOR_PCA9450)) {
+    ret = regmap_update_bits(priv->regmap, PCA9450_BUCK123_DVS,
+ BUCK123_PRESET_EN, 0);
+    }


Nit: the braces could be dropped.


IIRC they were recommended on multi-line code in conditional. I think 
checkpatch --strict might even warn about them missing.


Re: [PATCH v4 3/3] corstone1000: enable isp1763 usb controller and mmc

2022-06-28 Thread Marek Vasut

On 6/28/22 19:42, Rui Miguel Silva wrote:

MPS3 board have a ISP1763 usb controller, enable it to be used
for mass storage access for example. Enable the usb command
also and for the FVP support for mass storage enable the mmc
command.


This one does not apply to u-boot/master , do you have some other patch 
somewhere ? I applied the first two to usb/next in the meantime.


Re: [PATCH v3 0/3] usb: add isp1760 hcd support

2022-06-28 Thread Marek Vasut

On 6/28/22 16:59, Rui Miguel Silva wrote:

Hi,
On Mon, Jun 20, 2022 at 01:44:02PM -0400, Tom Rini wrote:

On Mon, Jun 20, 2022 at 05:00:56PM +0100, Rui Miguel Silva wrote:

Hi Tom, On Tue Jun 14, 2022 at 6:45 PM WEST, Rui Miguel Silva
wrote:

Hi *, On Wed, May 25, 2022 at 02:22:48PM +0100, Rui Miguel Silva
wrote:

Add support for the usb isp1760 host controller family, which
for example is present in MPS3 FPGA board from Arm (isp1763).

First we move some helper functions and defines to a more
common place to be shared by several urb users. (patch 1/3)

Then add the driver itself, is a ported version of the kernel
actual driver, which I am also the maintainer. (patch 2/3)

And last, enable it for the corstone1000 platform that uses
that MPS3 board for its implementation (patch 3/3).



Any chance this series get some feedback?


Am I missing something here? to get some comments on this series?


Marex?  Thanks.


Oh well, the weekly ping. Any comments on this series?


Can you rebase/resend and please CC me on the entire series ?

Thanks


Re: [PATCH v1] usb: host: nuvoton: Add nuvoton NPCM7xx ehci/ohci driver

2022-06-28 Thread Marek Vasut

On 6/28/22 05:49, Jim Liu wrote:

Hi Marek


Hi,


Thank you for your reminder.
Dell is use novuton uboot git repo now.
and request us upstream it.

npcm7xx normal defconfig is poleg_evb_defconfig, so all people use
this config to build uboot.
and poleg_evb_defconfig is in uboot master now.

I separate all the drivers to several commits,after I modify each
driver coding style.
and the poleg_evb_defconfig will be updated in the last commit

When the upstream task is finished , Dell or others will use upstream uboot.

If you have any suggestions please let me know.


All right, one last question, was the poleg_evb_defconfig patch posted 
to enable this driver yet ?


Re: [PATCH] usb: kbd: allow probing even if usbkbd not in stdin

2022-06-27 Thread Marek Vasut

On 6/27/22 12:03, Köry Maincent wrote:

Hello Marek,

On Fri, 24 Jun 2022 20:12:31 +0200
Marek Vasut  wrote:


On 6/22/22 10:59, kory.mainc...@bootlin.com wrote:

From: Kory Maincent 

For now the driver does not probe if usbkbd was not present in stdin.
This presents two issues, we can not probe the driver before setting stdin


Environment should be up and running before USB, so this is likely not a
problem.


Having a driver probing only in this specific state is weird?
It should probe whatever the state of stdin.




and we can not use this driver in other manner than stdin console.

This patch fixes this by adding an else statement. It simply probes the
driver without console management in the case "usbkbd" is not in stdin.


Can you document the usecase in a bit more detail ?


My usecase is to get a key press from the USB keyboard and do some thing about
it in board_init. I do not want to multiplex the keyboard input to stdin but I
still want to read character from it.


All right, understood, both. Thanks for clarification.

I applied this to usb/next , I hope that's OK ?


Re: [PATCH v1] usb: host: nuvoton: Add nuvoton NPCM7xx ehci/ohci driver

2022-06-27 Thread Marek Vasut

On 6/27/22 07:30, Jim Liu wrote:

Hi Marek


Hello all,


Thanks for your reply.
The answer is yes.
Our customer Dell is using our driver now.
so need upstream uboot source to uboot master.


All right, so this Dell device is also going to be upstreamed then ?

If the driver is just going to be upstream and never enabled, it would 
bitrot and be useless -- that's my concern.


[PATCH] board_init: Do not reserve MALLOC_F area on stack if non-zero MALLOC_F_ADDR

2022-06-25 Thread Marek Vasut
In case the MALLOC_F_ADDR is set to non-zero value, the early malloc area is
not going to be placed just below stack top, but elsewhere. Do not reserve
MALLOC_F bytes in this case, as that wastes stack space and may even cause
insufficient stack space in SPL.

This functionality is particularly useful on i.MX8M, where the insufficient
stack space can be triggered.

Signed-off-by: Marek Vasut 
Cc: Albert ARIBAUD 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Simon Glass 
Cc: Stefano Babic 
Cc: Thomas Chou 
Cc: Tom Rini 
---
 common/init/board_init.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/common/init/board_init.c b/common/init/board_init.c
index eab5ee13953..6a550261778 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -78,8 +78,10 @@ __weak void board_init_f_init_stack_protection(void)
 ulong board_init_f_alloc_reserve(ulong top)
 {
/* Reserve early malloc arena */
+#ifndef CONFIG_MALLOC_F_ADDR
 #if CONFIG_VAL(SYS_MALLOC_F_LEN)
top -= CONFIG_VAL(SYS_MALLOC_F_LEN);
+#endif
 #endif
/* LAST : reserve GD (rounded up to a multiple of 16 bytes) */
top = rounddown(top-sizeof(struct global_data), 16);
-- 
2.35.1



Re: [PATCH v1] usb: host: nuvoton: Add nuvoton NPCM7xx ehci/ohci driver

2022-06-24 Thread Marek Vasut

On 6/21/22 11:09, Jim Liu wrote:

Add nuvoton BMC NPCM750 ehci/ohci driver


Is there going to be any user of this driver (soon) ?


Re: [PATCH] usb: kbd: allow probing even if usbkbd not in stdin

2022-06-24 Thread Marek Vasut

On 6/22/22 10:59, kory.mainc...@bootlin.com wrote:

From: Kory Maincent 

For now the driver does not probe if usbkbd was not present in stdin.
This presents two issues, we can not probe the driver before setting stdin


Environment should be up and running before USB, so this is likely not a 
problem.



and we can not use this driver in other manner than stdin console.

This patch fixes this by adding an else statement. It simply probes the
driver without console management in the case "usbkbd" is not in stdin.


Can you document the usecase in a bit more detail ?
What exactly is the problem you are solving here ?


stdinname = env_get("stdin");
  #if CONFIG_IS_ENABLED(CONSOLE_MUX)
-   error = iomux_doenv(stdin, stdinname);
-   if (error)
-   return error;
+   if (strstr(stdinname, DEVNAME) != NULL) {
+   error = iomux_doenv(stdin, stdinname);
+   if (error)
+   return error;
+   }
  #else
/* Check if this is the standard input device. */
-   if (strcmp(stdinname, DEVNAME))
-   return 1;
-
-   /* Reassign the console */
-   if (overwrite_console())
-   return 1;
+   if (!strcmp(stdinname, DEVNAME)) {


Maybe use strcmp() == NULL to be consistent with the != NULL check above ?


Re: [PATCH 1/3] mmc: stm32_sdmmc2: cosmetic: rename stm32_sdmmc_bind

2022-06-23 Thread Marek Vasut

On 6/20/22 18:13, Patrick Delaunay wrote:

Rename stm32_sdmmc_bind to stm32_sdmmc2_bind as all oter function


s@oter@other@ typo


Re: [PATCH v3 2/2] pmic: pca9450: Add regulator driver

2022-06-19 Thread Marek Vasut

On 6/19/22 18:01, Heiko Thiery wrote:

[...]


+static int pca9450_set_value(struct udevice *dev, int uvolt)
+{
+   struct pca9450_plat *plat = dev_get_plat(dev);
+   unsigned int sel;
+   int i, found = 0;
+
+   /*
+* An under/overshooting may occur if voltage is changed for other
+* regulators but buck 1,2,3 or 4 when regulator is enabled. Prevent
+* change to protect the HW
+*/


To be able to configure the pmic/regulators during startup by the dm
(regulators_enable_boot_on) I think we have to
remove the checks for the permit. Otherwise the automatic configuration on hand
of the dtb settings won't work.



I tried to find the root of the comment above. Since the driver is
probably based
on the ROHM BD71837 and this comment can be found there as well, the
limitation probably comes from this type.

Can this be?


Most likely this comment is bogus copy-paste from the ROHM PMIC driver.

[...]


[PATCH 3/3] mtd: spi: renesas: Add R8A77980 support

2022-06-15 Thread Marek Vasut
From: Valentine Barshak 

This adds "renesas,rpc-r8a77980" to the compatible device list.

Signed-off-by: Valentine Barshak 
---
 drivers/spi/renesas_rpc_spi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/renesas_rpc_spi.c b/drivers/spi/renesas_rpc_spi.c
index 26b6aa85c9..9cd9a410b7 100644
--- a/drivers/spi/renesas_rpc_spi.c
+++ b/drivers/spi/renesas_rpc_spi.c
@@ -454,6 +454,7 @@ static const struct udevice_id rpc_spi_ids[] = {
{ .compatible = "renesas,rpc-r8a7796" },
{ .compatible = "renesas,rpc-r8a77965" },
{ .compatible = "renesas,rpc-r8a77970" },
+   { .compatible = "renesas,rpc-r8a77980" },
{ .compatible = "renesas,rpc-r8a77995" },
{ .compatible = "renesas,rcar-gen3-rpc" },
{ }
-- 
2.35.1



[PATCH 2/3] configs: r8a77980: Condor: Enable MMC support by default

2022-06-15 Thread Marek Vasut
From: Andrey Dolnikov 

This enables MMC support, which is available
on Condor board, by default.

Signed-off-by: Andrey Dolnikov 
Signed-off-by: Valentine Barshak 
Signed-off-by: Hai Pham 
---
 configs/r8a77980_condor_defconfig | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/configs/r8a77980_condor_defconfig 
b/configs/r8a77980_condor_defconfig
index 7be8bc204a..856d0c8e6b 100644
--- a/configs/r8a77980_condor_defconfig
+++ b/configs/r8a77980_condor_defconfig
@@ -27,6 +27,7 @@ CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_DFU=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_DHCP=y
@@ -54,7 +55,11 @@ CONFIG_DFU_SF=y
 CONFIG_RCAR_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_RCAR_I2C=y
-# CONFIG_MMC is not set
+CONFIG_DM_MMC=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
-- 
2.35.1



[PATCH 1/3] ARM: renesas: condor: switch eMMC bus to 1V8

2022-06-15 Thread Marek Vasut
From: Hai Pham 

The eMMC card has two supplies, VCC and VCCQ. The VCC supplies the NAND
array and the VCCQ supplies the bus. On Condor, the VCC is connected to
3.3V rail, while the VCCQ is connected to 1.8V rail. Adjust the pinmux
to match the bus, which is always operating in 1.8V mode.

Based on Linux commit 69efe4bbeda50745 ("arm64: dts: renesas: condor:
Switch eMMC bus to 1V8") from Wolfram Sang

Signed-off-by: Hai Pham 
---
 arch/arm/dts/r8a77980-condor.dts | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/arm/dts/r8a77980-condor.dts b/arch/arm/dts/r8a77980-condor.dts
index 3dde028e22..f0a0a51d73 100644
--- a/arch/arm/dts/r8a77980-condor.dts
+++ b/arch/arm/dts/r8a77980-condor.dts
@@ -212,7 +212,7 @@
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-1 = <_pins_uhs>;
+   pinctrl-1 = <_pins>;
pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_3v>;
@@ -253,12 +253,6 @@
};
 
mmc_pins: mmc {
-   groups = "mmc_data8", "mmc_ctrl", "mmc_ds";
-   function = "mmc";
-   power-source = <3300>;
-   };
-
-   mmc_pins_uhs: mmc_uhs {
groups = "mmc_data8", "mmc_ctrl", "mmc_ds";
function = "mmc";
power-source = <1800>;
-- 
2.35.1



[PATCH] ARM: dts: renesas: condor: Enable SPI NOR fast-read

2022-06-15 Thread marek . vasut
From: Marek Vasut 

This board requires SPI NOR fast-read, otherwise the SPI NOR
access returns corrupted data. Enable the fast-read explicitly
in DT as it has been disabled in the MTD subsystem by commit
d008190920 ("mtd: spi-nor: Mask out fast read if not requested in DT")

Signed-off-by: Marek Vasut 
---
 arch/arm/dts/r8a77980-condor-u-boot.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/r8a77980-condor-u-boot.dts 
b/arch/arm/dts/r8a77980-condor-u-boot.dts
index 1b22c7f0b9..576a74e603 100644
--- a/arch/arm/dts/r8a77980-condor-u-boot.dts
+++ b/arch/arm/dts/r8a77980-condor-u-boot.dts
@@ -25,6 +25,7 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "s25fs512s", "jedec,spi-nor";
+   m25p,fast-read;
spi-max-frequency = <5000>;
spi-tx-bus-width = <1>;
spi-rx-bus-width = <1>;
-- 
2.35.1



[PATCH v4] ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver

2022-06-15 Thread Marek Vasut
Replace the ad-hoc I2C register programming scripted in board
environment with U-Boot DM driver.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
V2: Use uclass_get_device_by_name()
V3: Reinstate the device-internal.h, needed for device_probe()
V4: Drop the device_probe() too
---
 .../imx8mm_data_modul_edm_sbc.c   |  9 +
 configs/imx8mm_data_modul_edm_sbc_defconfig   |  1 +
 include/configs/imx8mm_data_modul_edm_sbc.h   | 20 ---
 3 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c 
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index 46cb6f77b59..6dc4e6a9a2b 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -104,7 +105,15 @@ int board_init(void)
 
 int board_late_init(void)
 {
+   struct udevice *dev;
+   int ret;
+
setup_boot_device();
setup_mac_address();
+
+   ret = uclass_get_device_by_name(UCLASS_MISC, "usb-hub@2c", );
+   if (ret)
+   printf("Error bringing up USB hub (%d)\n", ret);
+
return 0;
 }
diff --git a/configs/imx8mm_data_modul_edm_sbc_defconfig 
b/configs/imx8mm_data_modul_edm_sbc_defconfig
index d55efa6d00e..99a1f862200 100644
--- a/configs/imx8mm_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mm_data_modul_edm_sbc_defconfig
@@ -156,6 +156,7 @@ CONFIG_MXC_GPIO=y
 CONFIG_DM_I2C=y
 # CONFIG_INPUT is not set
 CONFIG_MISC=y
+CONFIG_USB_HUB_USB251XB=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SYS_I2C_EEPROM_ADDR=0x50
 CONFIG_SUPPORT_EMMC_BOOT=y
diff --git a/include/configs/imx8mm_data_modul_edm_sbc.h 
b/include/configs/imx8mm_data_modul_edm_sbc.h
index 67667dd523d..419258f949a 100644
--- a/include/configs/imx8mm_data_modul_edm_sbc.h
+++ b/include/configs/imx8mm_data_modul_edm_sbc.h
@@ -71,7 +71,6 @@
"mtd nor0=sf raw 0x0 0x100\0"   \
"dmo_preboot="  \
"sf probe ; " /* Scan for SPI NOR, needed by DFU */ \
-   "run dmo_usb_start_hub ; "  \
/* Attempt to start USB and Network console */  \
"run dmo_usb_cdc_acm_start ; "  \
"run dmo_netconsole_start\0"\
@@ -91,25 +90,6 @@
"setenv stdin ${stdin},usbacm ; "   \
"fi ; " \
"fi\0"  \
-   "dmo_usb_start_hub="\
-   "i2c dev 1 ; "  \
-   /* Reset the USB USB */ \
-   "gpio clear GPIO5_2 ; sleep 0.01 ; " /* t1 > 1us */ \
-   "gpio set GPIO5_2 ; sleep 0.01 ; " /* t5 > 3us */   \
-   /* Write chunks of descriptor into the USB HUB */   \
-   "mw.l 0x7e1000 0x14042417 ; mw.l 0x7e1004 0x9b0bb325 ; "\
-   "mw.l 0x7e1008 0x0220 ; mw.l 0x7e100c 0x01320100 ; "\
-   "mw.l 0x7e1010 0x3232 ; mw.l 0x7e1014 0x4d000909 ; "\
-   "i2c write 0x7e1000 0x2c 0x00 0x18 -s ; "   \
-   "mw.l 0x7e1000 0x6300690f ; mw.l 0x7e1004 0x6f007200 ; "\
-   "mw.l 0x7e1008 0x68006300 ; mw.l 0x7e100c 0x70006900 ; "\
-   "i2c write 0x7e1000 0x2c 0x18 0x10 -s ; "   \
-   "mw.l 0x7e1000 0x53005511 ; mw.l 0x7e1004 0x32004200 ; "\
-   "mw.l 0x7e1008 0x31003500 ; mw.l 0x7e100c 0x42003400 ; "\
-   "mw.l 0x7e1010 0x6900 ; "   \
-   "i2c write 0x7e1000 0x2c 0x54 0x12 -s ; "   \
-   "mw.l 0x7e1000 0x0101 ; "   \
-   "i2c write 0x7e1000 0x2c 0xff 0x2 -s\0" \
"dmo_netconsole_start=" \
"if test \"${dmo_netconsole_enabled}\" = \"true\" ; then "\
"setenv autoload false && " \
-- 
2.35.1



[PATCH] ARM: renesas: condor: Set CONFIG_SYS_TEXT_BASE=0x0 on R-Car Gen3 Condor

2022-06-15 Thread marek . vasut
From: Marek Vasut 

Since R-Car Gen3 already enables position independent build, also set
CONFIG_SYS_TEXT_BASE=0x0 to finalize the switch. This is possible since
534f0fbd65 ("arm64: Fix relocation of env_addr if POSITION_INDEPENDENT=y")
fixed current env_get_char() crash with CONFIG_SYS_TEXT_BASE=0x0 .

This change permits us to start U-Boot from any location in DRAM instead
of specific TEXT_BASE.

Signed-off-by: Marek Vasut 
---
 configs/r8a77980_condor_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/r8a77980_condor_defconfig 
b/configs/r8a77980_condor_defconfig
index c3b6e99ae7..7be8bc204a 100644
--- a/configs/r8a77980_condor_defconfig
+++ b/configs/r8a77980_condor_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_COUNTER_FREQUENCY=1666
 CONFIG_ARCH_CPU_INIT=y
 CONFIG_ARCH_RMOBILE=y
-CONFIG_SYS_TEXT_BASE=0x5000
+CONFIG_SYS_TEXT_BASE=0x0
 CONFIG_SYS_MALLOC_LEN=0x400
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_ENV_SIZE=0x4
-- 
2.35.1



[PATCH v3] ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver

2022-06-14 Thread Marek Vasut
Replace the ad-hoc I2C register programming scripted in board
environment with U-Boot DM driver.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
V2: Use uclass_get_device_by_name()
V3: Reinstate the device-internal.h, needed for device_probe()
---
 .../imx8mm_data_modul_edm_sbc.c   |  9 +
 configs/imx8mm_data_modul_edm_sbc_defconfig   |  1 +
 include/configs/imx8mm_data_modul_edm_sbc.h   | 20 ---
 3 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c 
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index 46cb6f77b59..07d9effbbb9 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -104,7 +105,15 @@ int board_init(void)
 
 int board_late_init(void)
 {
+   struct udevice *dev;
+   int ret;
+
setup_boot_device();
setup_mac_address();
+
+   ret = uclass_get_device_by_name(UCLASS_MISC, "usb-hub@2c", );
+   if (!ret)
+   device_probe(dev);
+
return 0;
 }
diff --git a/configs/imx8mm_data_modul_edm_sbc_defconfig 
b/configs/imx8mm_data_modul_edm_sbc_defconfig
index d55efa6d00e..99a1f862200 100644
--- a/configs/imx8mm_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mm_data_modul_edm_sbc_defconfig
@@ -156,6 +156,7 @@ CONFIG_MXC_GPIO=y
 CONFIG_DM_I2C=y
 # CONFIG_INPUT is not set
 CONFIG_MISC=y
+CONFIG_USB_HUB_USB251XB=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SYS_I2C_EEPROM_ADDR=0x50
 CONFIG_SUPPORT_EMMC_BOOT=y
diff --git a/include/configs/imx8mm_data_modul_edm_sbc.h 
b/include/configs/imx8mm_data_modul_edm_sbc.h
index 67667dd523d..419258f949a 100644
--- a/include/configs/imx8mm_data_modul_edm_sbc.h
+++ b/include/configs/imx8mm_data_modul_edm_sbc.h
@@ -71,7 +71,6 @@
"mtd nor0=sf raw 0x0 0x100\0"   \
"dmo_preboot="  \
"sf probe ; " /* Scan for SPI NOR, needed by DFU */ \
-   "run dmo_usb_start_hub ; "  \
/* Attempt to start USB and Network console */  \
"run dmo_usb_cdc_acm_start ; "  \
"run dmo_netconsole_start\0"\
@@ -91,25 +90,6 @@
"setenv stdin ${stdin},usbacm ; "   \
"fi ; " \
"fi\0"  \
-   "dmo_usb_start_hub="\
-   "i2c dev 1 ; "  \
-   /* Reset the USB USB */ \
-   "gpio clear GPIO5_2 ; sleep 0.01 ; " /* t1 > 1us */ \
-   "gpio set GPIO5_2 ; sleep 0.01 ; " /* t5 > 3us */   \
-   /* Write chunks of descriptor into the USB HUB */   \
-   "mw.l 0x7e1000 0x14042417 ; mw.l 0x7e1004 0x9b0bb325 ; "\
-   "mw.l 0x7e1008 0x0220 ; mw.l 0x7e100c 0x01320100 ; "\
-   "mw.l 0x7e1010 0x3232 ; mw.l 0x7e1014 0x4d000909 ; "\
-   "i2c write 0x7e1000 0x2c 0x00 0x18 -s ; "   \
-   "mw.l 0x7e1000 0x6300690f ; mw.l 0x7e1004 0x6f007200 ; "\
-   "mw.l 0x7e1008 0x68006300 ; mw.l 0x7e100c 0x70006900 ; "\
-   "i2c write 0x7e1000 0x2c 0x18 0x10 -s ; "   \
-   "mw.l 0x7e1000 0x53005511 ; mw.l 0x7e1004 0x32004200 ; "\
-   "mw.l 0x7e1008 0x31003500 ; mw.l 0x7e100c 0x42003400 ; "\
-   "mw.l 0x7e1010 0x6900 ; "   \
-   "i2c write 0x7e1000 0x2c 0x54 0x12 -s ; "   \
-   "mw.l 0x7e1000 0x0101 ; "   \
-   "i2c write 0x7e1000 0x2c 0xff 0x2 -s\0" \
"dmo_netconsole_start=" \
"if test \"${dmo_netconsole_enabled}\" = \"true\" ; then "\
"setenv autoload false && " \
-- 
2.35.1



[PATCH v2] ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver

2022-06-14 Thread Marek Vasut
Replace the ad-hoc I2C register programming scripted in board
environment with U-Boot DM driver.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
V2: Use uclass_get_device_by_name()
---
 .../imx8mm_data_modul_edm_sbc.c   |  8 
 configs/imx8mm_data_modul_edm_sbc_defconfig   |  1 +
 include/configs/imx8mm_data_modul_edm_sbc.h   | 20 ---
 3 files changed, 9 insertions(+), 20 deletions(-)

diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c 
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index 46cb6f77b59..1e20fb46fef 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -104,7 +104,15 @@ int board_init(void)
 
 int board_late_init(void)
 {
+   struct udevice *dev;
+   int ret;
+
setup_boot_device();
setup_mac_address();
+
+   ret = uclass_get_device_by_name(UCLASS_MISC, "usb-hub@2c", );
+   if (!ret)
+   device_probe(dev);
+
return 0;
 }
diff --git a/configs/imx8mm_data_modul_edm_sbc_defconfig 
b/configs/imx8mm_data_modul_edm_sbc_defconfig
index d55efa6d00e..99a1f862200 100644
--- a/configs/imx8mm_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mm_data_modul_edm_sbc_defconfig
@@ -156,6 +156,7 @@ CONFIG_MXC_GPIO=y
 CONFIG_DM_I2C=y
 # CONFIG_INPUT is not set
 CONFIG_MISC=y
+CONFIG_USB_HUB_USB251XB=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SYS_I2C_EEPROM_ADDR=0x50
 CONFIG_SUPPORT_EMMC_BOOT=y
diff --git a/include/configs/imx8mm_data_modul_edm_sbc.h 
b/include/configs/imx8mm_data_modul_edm_sbc.h
index 67667dd523d..419258f949a 100644
--- a/include/configs/imx8mm_data_modul_edm_sbc.h
+++ b/include/configs/imx8mm_data_modul_edm_sbc.h
@@ -71,7 +71,6 @@
"mtd nor0=sf raw 0x0 0x100\0"   \
"dmo_preboot="  \
"sf probe ; " /* Scan for SPI NOR, needed by DFU */ \
-   "run dmo_usb_start_hub ; "  \
/* Attempt to start USB and Network console */  \
"run dmo_usb_cdc_acm_start ; "  \
"run dmo_netconsole_start\0"\
@@ -91,25 +90,6 @@
"setenv stdin ${stdin},usbacm ; "   \
"fi ; " \
"fi\0"  \
-   "dmo_usb_start_hub="\
-   "i2c dev 1 ; "  \
-   /* Reset the USB USB */ \
-   "gpio clear GPIO5_2 ; sleep 0.01 ; " /* t1 > 1us */ \
-   "gpio set GPIO5_2 ; sleep 0.01 ; " /* t5 > 3us */   \
-   /* Write chunks of descriptor into the USB HUB */   \
-   "mw.l 0x7e1000 0x14042417 ; mw.l 0x7e1004 0x9b0bb325 ; "\
-   "mw.l 0x7e1008 0x0220 ; mw.l 0x7e100c 0x01320100 ; "\
-   "mw.l 0x7e1010 0x3232 ; mw.l 0x7e1014 0x4d000909 ; "\
-   "i2c write 0x7e1000 0x2c 0x00 0x18 -s ; "   \
-   "mw.l 0x7e1000 0x6300690f ; mw.l 0x7e1004 0x6f007200 ; "\
-   "mw.l 0x7e1008 0x68006300 ; mw.l 0x7e100c 0x70006900 ; "\
-   "i2c write 0x7e1000 0x2c 0x18 0x10 -s ; "   \
-   "mw.l 0x7e1000 0x53005511 ; mw.l 0x7e1004 0x32004200 ; "\
-   "mw.l 0x7e1008 0x31003500 ; mw.l 0x7e100c 0x42003400 ; "\
-   "mw.l 0x7e1010 0x6900 ; "   \
-   "i2c write 0x7e1000 0x2c 0x54 0x12 -s ; "   \
-   "mw.l 0x7e1000 0x0101 ; "   \
-   "i2c write 0x7e1000 0x2c 0xff 0x2 -s\0" \
"dmo_netconsole_start=" \
"if test \"${dmo_netconsole_enabled}\" = \"true\" ; then "\
"setenv autoload false && " \
-- 
2.35.1



[PATCH] ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver

2022-06-14 Thread Marek Vasut
Replace the ad-hoc I2C register programming scripted in board
environment with U-Boot DM driver.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 .../imx8mm_data_modul_edm_sbc.c   | 10 ++
 configs/imx8mm_data_modul_edm_sbc_defconfig   |  1 +
 include/configs/imx8mm_data_modul_edm_sbc.h   | 20 ---
 3 files changed, 11 insertions(+), 20 deletions(-)

diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c 
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index 46cb6f77b59..56202ca2fc8 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -9,6 +9,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -104,7 +106,15 @@ int board_init(void)
 
 int board_late_init(void)
 {
+   struct udevice *dev;
+   int ret;
+
setup_boot_device();
setup_mac_address();
+
+   ret = uclass_find_device_by_name(UCLASS_MISC, "usb-hub@2c", );
+   if (!ret)
+   device_probe(dev);
+
return 0;
 }
diff --git a/configs/imx8mm_data_modul_edm_sbc_defconfig 
b/configs/imx8mm_data_modul_edm_sbc_defconfig
index d55efa6d00e..99a1f862200 100644
--- a/configs/imx8mm_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mm_data_modul_edm_sbc_defconfig
@@ -156,6 +156,7 @@ CONFIG_MXC_GPIO=y
 CONFIG_DM_I2C=y
 # CONFIG_INPUT is not set
 CONFIG_MISC=y
+CONFIG_USB_HUB_USB251XB=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SYS_I2C_EEPROM_ADDR=0x50
 CONFIG_SUPPORT_EMMC_BOOT=y
diff --git a/include/configs/imx8mm_data_modul_edm_sbc.h 
b/include/configs/imx8mm_data_modul_edm_sbc.h
index 67667dd523d..419258f949a 100644
--- a/include/configs/imx8mm_data_modul_edm_sbc.h
+++ b/include/configs/imx8mm_data_modul_edm_sbc.h
@@ -71,7 +71,6 @@
"mtd nor0=sf raw 0x0 0x100\0"   \
"dmo_preboot="  \
"sf probe ; " /* Scan for SPI NOR, needed by DFU */ \
-   "run dmo_usb_start_hub ; "  \
/* Attempt to start USB and Network console */  \
"run dmo_usb_cdc_acm_start ; "  \
"run dmo_netconsole_start\0"\
@@ -91,25 +90,6 @@
"setenv stdin ${stdin},usbacm ; "   \
"fi ; " \
"fi\0"  \
-   "dmo_usb_start_hub="\
-   "i2c dev 1 ; "  \
-   /* Reset the USB USB */ \
-   "gpio clear GPIO5_2 ; sleep 0.01 ; " /* t1 > 1us */ \
-   "gpio set GPIO5_2 ; sleep 0.01 ; " /* t5 > 3us */   \
-   /* Write chunks of descriptor into the USB HUB */   \
-   "mw.l 0x7e1000 0x14042417 ; mw.l 0x7e1004 0x9b0bb325 ; "\
-   "mw.l 0x7e1008 0x0220 ; mw.l 0x7e100c 0x01320100 ; "\
-   "mw.l 0x7e1010 0x3232 ; mw.l 0x7e1014 0x4d000909 ; "\
-   "i2c write 0x7e1000 0x2c 0x00 0x18 -s ; "   \
-   "mw.l 0x7e1000 0x6300690f ; mw.l 0x7e1004 0x6f007200 ; "\
-   "mw.l 0x7e1008 0x68006300 ; mw.l 0x7e100c 0x70006900 ; "\
-   "i2c write 0x7e1000 0x2c 0x18 0x10 -s ; "   \
-   "mw.l 0x7e1000 0x53005511 ; mw.l 0x7e1004 0x32004200 ; "\
-   "mw.l 0x7e1008 0x31003500 ; mw.l 0x7e100c 0x42003400 ; "\
-   "mw.l 0x7e1010 0x6900 ; "   \
-   "i2c write 0x7e1000 0x2c 0x54 0x12 -s ; "   \
-   "mw.l 0x7e1000 0x0101 ; "   \
-   "i2c write 0x7e1000 0x2c 0xff 0x2 -s\0" \
"dmo_netconsole_start=" \
"if test \"${dmo_netconsole_enabled}\" = \"true\" ; then "\
"setenv autoload false && " \
-- 
2.35.1



Re: [PATCH] misc: Port USB251xB/xBi Hi-Speed Hub Controller Driver from Linux

2022-06-14 Thread Marek Vasut

On 6/14/22 09:08, Stefan Herbrechtsmeier wrote:

Am 13.06.2022 um 22:26 schrieb Marek Vasut:

On 6/13/22 19:23, Stefan Herbrechtsmeier wrote:


[snip]


+    if (dev_read_u32(dev, "vendor-id", >vendor_id))
+    hub->vendor_id = USB251XB_DEF_VENDOR_ID;
+
+    if (dev_read_u32(dev, "product-id", >product_id))
+    hub->product_id = data->product_id;
+
+    if (dev_read_u32(dev, "device-id", >device_id))
+    hub->device_id = USB251XB_DEF_DEVICE_ID;
+


[snip]


+    if (dev_read_u32(dev, "language-id", >lang_id))
+    hub->lang_id = USB251XB_DEF_LANGUAGE_ID;
+


This doesn't work because the ids are 16 bit [1,2] and the 
dev_read_u32 function checks the size.



+    if (!dev_read_u32(dev, "boost-up", >boost_up))
+    hub->boost_up = USB251XB_DEF_BOOST_UP;


This looks like a 8 bit value [1].


The dev_read_u32() is also capable of reading 0x 16bit value 
from DT.


What kind of problem are you running into exactly ?


Have you test the values from device tree binding documentation:

vendor-id = /bits/ 16 <0x>;
product-id = /bits/ 16 <0x>;

I get an EOVERFLOW error.


No, I only tested foo = <0x>; .

Can you send a fix ?


Should I add a function to the driver or a dev_read_u8/16, 
ofnode_read_u8/16 and friends function?


It seems more like you would have to add the _u8 and _u16 variants into 
common code, alongside the _u32 variant (should be easy) and then use 
them in this driver (should also be easy), so two patches.


Re: [PATCH 01/12] env: Complete generic support for writable list

2022-06-13 Thread Marek Vasut

On 6/8/22 16:39, Jan Kiszka wrote:

[...]


If you want to make this into a generic patch, can you somehow reduce
the ever-growing ifdeffery, so that the patch won't add to it so much ?
I suspect the code above can help with that, maybe it can be used to
remove at least the env_locations[] reordering ifdeffery ?


Your code is not generic enough as it ignores the config-selected
storage device. It would only happen to cover all our boards, but we are
not the world. That's why I had to add some ifdeffery.


That storage device part is trivial to fix, right.


I could try write an alternative arch_env_get_location that does the
required logic with a single ifdef. The prize might be some code
duplication, though.


Can you use CONFIG_IS_ENABLED()/IS_ENABLED() in arch_env_get_location() 
to avoid the #if ... and outright return ENVL_NOWHERE or whatever to 
avoid adding ifdefs to env_locations[] array ?


That should likely be possible.

[...]


Re: [PATCH] misc: Port USB251xB/xBi Hi-Speed Hub Controller Driver from Linux

2022-06-13 Thread Marek Vasut

On 6/13/22 19:23, Stefan Herbrechtsmeier wrote:

Hi Marek,


Hi,

[...]


+
+    if (IS_ENABLED(CONFIG_DM_REGULATOR)) {
+    err = device_get_supply_regulator(dev, "vdd-supply",
+  >vdd);
+    if (err && err != -ENOENT) {
+    dev_err(dev, "Warning: cannot get power supply\n");
+    return err;
+    }
+    }


Shouldn't the gpio and regulator request be part of the probe?


What makes you think that ?


It's more a question regarding the device model design:

of_to_plat - convert device tree data to plat


As far as I can tell, you should be able to obtain reference to a 
regulator here, but not probe the regulator.



+    if (dev_read_u32(dev, "vendor-id", >vendor_id))
+    hub->vendor_id = USB251XB_DEF_VENDOR_ID;
+
+    if (dev_read_u32(dev, "product-id", >product_id))
+    hub->product_id = data->product_id;
+
+    if (dev_read_u32(dev, "device-id", >device_id))
+    hub->device_id = USB251XB_DEF_DEVICE_ID;
+


[snip]


+    if (dev_read_u32(dev, "language-id", >lang_id))
+    hub->lang_id = USB251XB_DEF_LANGUAGE_ID;
+


This doesn't work because the ids are 16 bit [1,2] and the 
dev_read_u32 function checks the size.



+    if (!dev_read_u32(dev, "boost-up", >boost_up))
+    hub->boost_up = USB251XB_DEF_BOOST_UP;


This looks like a 8 bit value [1].


The dev_read_u32() is also capable of reading 0x 16bit value from DT.

What kind of problem are you running into exactly ?


Have you test the values from device tree binding documentation:

vendor-id = /bits/ 16 <0x>;
product-id = /bits/ 16 <0x>;

I get an EOVERFLOW error.


No, I only tested foo = <0x>; .

Can you send a fix ?


Re: [PATCH] misc: Port USB251xB/xBi Hi-Speed Hub Controller Driver from Linux

2022-06-13 Thread Marek Vasut

On 6/13/22 17:39, Stefan Herbrechtsmeier wrote:

Hi Marek,


Hi,

sorry for the late comments but I think the driver doesn't work as 
expected.


How come ? It works on my board.

[...]


+
+    if (IS_ENABLED(CONFIG_DM_REGULATOR)) {
+    err = device_get_supply_regulator(dev, "vdd-supply",
+  >vdd);
+    if (err && err != -ENOENT) {
+    dev_err(dev, "Warning: cannot get power supply\n");
+    return err;
+    }
+    }


Shouldn't the gpio and regulator request be part of the probe?


What makes you think that ?


+    if (dev_read_u32(dev, "vendor-id", >vendor_id))
+    hub->vendor_id = USB251XB_DEF_VENDOR_ID;
+
+    if (dev_read_u32(dev, "product-id", >product_id))
+    hub->product_id = data->product_id;
+
+    if (dev_read_u32(dev, "device-id", >device_id))
+    hub->device_id = USB251XB_DEF_DEVICE_ID;
+


[snip]


+    if (dev_read_u32(dev, "language-id", >lang_id))
+    hub->lang_id = USB251XB_DEF_LANGUAGE_ID;
+


This doesn't work because the ids are 16 bit [1,2] and the dev_read_u32 
function checks the size.



+    if (!dev_read_u32(dev, "boost-up", >boost_up))
+    hub->boost_up = USB251XB_DEF_BOOST_UP;


This looks like a 8 bit value [1].


The dev_read_u32() is also capable of reading 0x 16bit value from DT.

What kind of problem are you running into exactly ?


Re: [PATCH] clk: imx8mp: Fix 32k clock name

2022-06-13 Thread Marek Vasut

On 6/13/22 15:41, ZHIZHIKIN Andrey wrote:

Hello Marek,


-Original Message-
From: U-Boot  On Behalf Of Marek Vasut
Sent: Monday, June 13, 2022 3:22 PM
To: u-boot@lists.denx.de
Cc: Marek Vasut ; Fabio Estevam ; Peng Fan
; Stefano Babic 
Subject: [PATCH] clk: imx8mp: Fix 32k clock name

The 32 kHz oscillator clock name is 'clock-osc-32k' instead of 'osc_32k'.
Fix the name to prevent the following warning:

"
clk_register: failed to get osc_32k device (parent of usb_root_clk)
"

Fixes: 7a2c3be95a5 ("clk: imx8mp: Fill in DWC3 USB, USB PHY, HSIOMIX clock")
Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 


I've already submitted a series to address this issue and the one for
ECSPI clocks, see [1].

You're also on Cc: to that series, so you can take a look at it and
decide whether it is suitable or not.


Even better, thanks.


[PATCH] clk: imx8mp: Fix ECSPI clock selects

2022-06-13 Thread Marek Vasut
The 24 MHz oscillator clock name is 'clock-osc-24m' with all dashes
instead of 'clock-osc_24m' with underscore. Fix the name.

Fixes: 87f958810fc ("clk: imx8mp: Add ECSPI clocks")
Signed-off-by: Marek Vasut 
Cc: Elmar Albert 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 drivers/clk/imx/clk-imx8mp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index ac727b7e404..cbed86a6843 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -122,15 +122,15 @@ static const char *imx8mp_gic_sels[] = {"clock-osc-24m", 
"sys_pll2_200m", "sys_p
"sys_pll2_100m", "sys_pll1_800m",
"sys_pll2_500m", "clk_ext4", 
"audio_pll2_out" };
 
-static const char *imx8mp_ecspi1_sels[] = {"clock-osc_24m", "sys_pll2_200m", 
"sys_pll1_40m",
+static const char *imx8mp_ecspi1_sels[] = {"clock-osc-24m", "sys_pll2_200m", 
"sys_pll1_40m",
  "sys_pll1_160m", 
"sys_pll1_800m", "sys_pll3_out",
  "sys_pll2_250m", 
"audio_pll2_out", };
 
-static const char *imx8mp_ecspi2_sels[] = {"clock-osc_24m", "sys_pll2_200m", 
"sys_pll1_40m",
+static const char *imx8mp_ecspi2_sels[] = {"clock-osc-24m", "sys_pll2_200m", 
"sys_pll1_40m",
  "sys_pll1_160m", 
"sys_pll1_800m", "sys_pll3_out",
  "sys_pll2_250m", 
"audio_pll2_out", };
 
-static const char *imx8mp_ecspi3_sels[] = {"clock-osc_24m", "sys_pll2_200m", 
"sys_pll1_40m",
+static const char *imx8mp_ecspi3_sels[] = {"clock-osc-24m", "sys_pll2_200m", 
"sys_pll1_40m",
  "sys_pll1_160m", 
"sys_pll1_800m", "sys_pll3_out",
  "sys_pll2_250m", 
"audio_pll2_out", };
 
-- 
2.35.1



[PATCH] clk: imx8mp: Fix 32k clock name

2022-06-13 Thread Marek Vasut
The 32 kHz oscillator clock name is 'clock-osc-32k' instead of 'osc_32k'.
Fix the name to prevent the following warning:

"
clk_register: failed to get osc_32k device (parent of usb_root_clk)
"

Fixes: 7a2c3be95a5 ("clk: imx8mp: Fill in DWC3 USB, USB PHY, HSIOMIX clock")
Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 drivers/clk/imx/clk-imx8mp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index cbed86a6843..9c7857bbb3a 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -300,7 +300,7 @@ static int imx8mp_clk_probe(struct udevice *dev)
clk_dm(IMX8MP_CLK_UART2_ROOT, imx_clk_gate4("uart2_root_clk", "uart2", 
base + 0x44a0, 0));
clk_dm(IMX8MP_CLK_UART3_ROOT, imx_clk_gate4("uart3_root_clk", "uart3", 
base + 0x44b0, 0));
clk_dm(IMX8MP_CLK_UART4_ROOT, imx_clk_gate4("uart4_root_clk", "uart4", 
base + 0x44c0, 0));
-   clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate4("usb_root_clk", "osc_32k", 
base + 0x44d0, 0));
+   clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate4("usb_root_clk", 
"clock-osc-32k", base + 0x44d0, 0));
clk_dm(IMX8MP_CLK_USB_PHY_ROOT, imx_clk_gate4("usb_phy_root_clk", 
"usb_phy_ref", base + 0x44f0, 0));
clk_dm(IMX8MP_CLK_USDHC1_ROOT, imx_clk_gate4("usdhc1_root_clk", 
"usdhc1", base + 0x4510, 0));
clk_dm(IMX8MP_CLK_USDHC2_ROOT, imx_clk_gate4("usdhc2_root_clk", 
"usdhc2", base + 0x4520, 0));
-- 
2.35.1



[PATCH] spi: nxp_fspi: Fix clock imbalance

2022-06-13 Thread Marek Vasut
The nxp_fspi_default_setup() is only ever called from nxp_fspi_probe(),
where the IP clock are initially disabled. Drop the second disabling of
clock to prevent clock enable/disable imbalance reported by clock core:

"
clk qspi_root_clk already disabled
"

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 drivers/spi/nxp_fspi.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/spi/nxp_fspi.c b/drivers/spi/nxp_fspi.c
index 607c953987b..579d6bac9b1 100644
--- a/drivers/spi/nxp_fspi.c
+++ b/drivers/spi/nxp_fspi.c
@@ -866,9 +866,6 @@ static int nxp_fspi_default_setup(struct nxp_fspi *f)
u32 reg;
 
 #if CONFIG_IS_ENABLED(CLK)
-   /* disable and unprepare clock to avoid glitch pass to controller */
-   nxp_fspi_clk_disable_unprep(f);
-
/* the default frequency, we will change it later if necessary. */
ret = clk_set_rate(>clk, 2000);
if (ret < 0)
-- 
2.35.1



[PATCH 6/6] ARM: dts: stm32: Add DHCOR based DRC Compact board

2022-06-13 Thread Marek Vasut
Add DT for DH DRC Compact unit, which is a universal controller device.
The system has two ethernet ports, one CAN, RS485 and RS232, USB, uSD
card slot, eMMC and SDIO Wi-Fi.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 arch/arm/dts/Makefile |   3 +-
 .../arm/dts/stm32mp153c-dhcor-drc-compact.dts |  30 ++
 .../stm32mp15xx-dhcor-drc-compact-u-boot.dtsi | 120 +++
 .../arm/dts/stm32mp15xx-dhcor-drc-compact.dts |  16 +
 .../dts/stm32mp15xx-dhcor-drc-compact.dtsi| 326 ++
 .../dh_stm32mp1/u-boot-dhcor.its  |  15 +
 configs/stm32mp15_dhcor_basic_defconfig   |   1 +
 7 files changed, 510 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/stm32mp153c-dhcor-drc-compact.dts
 create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-drc-compact-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-drc-compact.dts
 create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-drc-compact.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0a2713c06a3..8a314210da6 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1172,7 +1172,8 @@ dtb-$(CONFIG_STM32MP15x) += \
stm32mp15xx-dhcom-drc02.dtb \
stm32mp15xx-dhcom-pdk2.dtb \
stm32mp15xx-dhcom-picoitx.dtb \
-   stm32mp15xx-dhcor-avenger96.dtb
+   stm32mp15xx-dhcor-avenger96.dtb \
+   stm32mp15xx-dhcor-drc-compact.dtb
 
 dtb-$(CONFIG_SOC_K3_AM6) += \
k3-am654-base-board.dtb \
diff --git a/arch/arm/dts/stm32mp153c-dhcor-drc-compact.dts 
b/arch/arm/dts/stm32mp153c-dhcor-drc-compact.dts
new file mode 100644
index 000..c8b9818499e
--- /dev/null
+++ b/arch/arm/dts/stm32mp153c-dhcor-drc-compact.dts
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+/*
+ * Copyright (C) 2022 Marek Vasut 
+ *
+ * DHCOR STM32MP1 variant:
+ * DHCR-STM32MP153C-C065-R051-V33-SPI-I-01LG
+ * DHCOR PCB number: 586-100 or newer
+ * DRC Compact PCB number: 627-100 or newer
+ */
+
+/dts-v1/;
+
+#include "stm32mp153.dtsi"
+#include "stm32mp15xc.dtsi"
+#include "stm32mp15xx-dhcor-som.dtsi"
+#include "stm32mp15xx-dhcor-drc-compact.dtsi"
+
+/ {
+   model = "DH electronics STM32MP153C DHCOR DRC Compact";
+   compatible = "dh,stm32mp153c-dhcor-drc-compact",
+"dh,stm32mp153c-dhcor-som",
+"st,stm32mp153";
+};
+
+_can1 {
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_can1_pins_c>;
+   pinctrl-1 = <_can1_sleep_pins_c>;
+   status = "okay";
+};
diff --git a/arch/arm/dts/stm32mp15xx-dhcor-drc-compact-u-boot.dtsi 
b/arch/arm/dts/stm32mp15xx-dhcor-drc-compact-u-boot.dtsi
new file mode 100644
index 000..407fed56167
--- /dev/null
+++ b/arch/arm/dts/stm32mp15xx-dhcor-drc-compact-u-boot.dtsi
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * Copyright (C) 2022 Marek Vasut 
+ */
+
+#include "stm32mp15xx-dhcor-u-boot.dtsi"
+
+/delete-node/ 
+
+/ {
+   aliases {
+   mmc0 = 
+   mmc1 = 
+   usb0 = _hs;
+   ethernet1 = 
+   };
+
+   config {
+   dh,board-coding-gpios = < 9 0>, < 8 0>, < 3 
0>;
+   };
+
+   /* This is actually on FMC2, but we do not have bus driver for that */
+   ks8851: ks8851mll@6400 {
+   compatible = "micrel,ks8851-mll";
+   reg = <0x6400 0x2>;
+   };
+};
+
+ {
+   phy-reset-gpios = < 2 GPIO_ACTIVE_LOW>;
+
+   mdio0 {
+   ethernet-phy@7 {
+   reset-gpios = < 2 GPIO_ACTIVE_LOW>;
+   reset-assert-us = <11000>;
+   reset-deassert-us = <1000>;
+   };
+   };
+};
+
+ {
+   /* These should bound to FMC2 bus driver, but we do not have one */
+   pinctrl-0 = <_pins_b>;
+   pinctrl-1 = <_sleep_pins_b>;
+   pinctrl-names = "default", "sleep";
+};
+
+ {
+   u-boot,dm-spl;
+   st,use-ckin;
+   st,cmd-gpios = < 2 0>;
+   st,ck-gpios = < 12 0>;
+   st,ckin-gpios = < 4 0>;
+};
+
+_b4_pins_a {
+   u-boot,dm-spl;
+   pins1 {
+   u-boot,dm-spl;
+   };
+   pins2 {
+   u-boot,dm-spl;
+   };
+};
+
+_dir_pins_b {
+   u-boot,dm-spl;
+   pins1 {
+   u-boot,dm-spl;
+   };
+   pins2 {
+   u-boot,dm-spl;
+   };
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_b4_pins_a {
+   u-boot,dm-spl;
+   pins1 {
+   u-boot,dm-spl;
+   };
+   pins2 {
+   u-boot,dm-spl;
+   };
+};
+
+_d47_pins_c {
+   u-boot,dm-spl;
+   pins {
+   u-boot,dm-spl;
+   };
+};
+
+ {  /* SDIO Wi-Fi */
+   status = "

[PATCH 5/6] ARM: dts: stm32: Add alternate pinmux for SPI2 pins

2022-06-13 Thread Marek Vasut
Add another mux option for SPI2 pins, this is used on DRC Compact board.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 arch/arm/dts/stm32mp15-pinctrl.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
b/arch/arm/dts/stm32mp15-pinctrl.dtsi
index e0965c5936e..b92a149a186 100644
--- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
@@ -1778,6 +1778,21 @@
};
};
 
+   spi2_pins_b: spi2-1 {
+   pins1 {
+   pinmux = , /* SPI1_SCK */
+; /* SPI1_MOSI */
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <1>;
+   };
+
+   pins2 {
+   pinmux = ; /* SPI1_MISO */
+   bias-disable;
+   };
+   };
+
spi4_pins_a: spi4-0 {
pins {
pinmux = , /* SPI4_SCK */
-- 
2.35.1



[PATCH 4/6] ARM: dts: stm32: Add alternate pinmux for CAN1 pins

2022-06-13 Thread Marek Vasut
Add another mux option for CAN1 pins, this is used on DRC Compact board.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 arch/arm/dts/stm32mp15-pinctrl.dtsi | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
b/arch/arm/dts/stm32mp15-pinctrl.dtsi
index 6a5b4016f66..e0965c5936e 100644
--- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
@@ -929,6 +929,26 @@
};
};
 
+   m_can1_pins_c: m-can1-2 {
+   pins1 {
+   pinmux = ; /* CAN1_TX */
+   slew-rate = <1>;
+   drive-push-pull;
+   bias-disable;
+   };
+   pins2 {
+   pinmux = ; /* CAN1_RX */
+   bias-disable;
+   };
+   };
+
+   m_can1_sleep_pins_c: m_can1-sleep-2 {
+   pins {
+   pinmux = , /* CAN1_TX */
+; /* CAN1_RX */
+   };
+   };
+
m_can2_pins_a: m-can2-0 {
pins1 {
pinmux = ; /* CAN2_TX */
-- 
2.35.1



[PATCH 3/6] ARM: dts: stm32: Add alternate pinmux for UART5 pins

2022-06-13 Thread Marek Vasut
Add another mux option for UART5 pins, this is used on DRC Compact board.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 arch/arm/dts/stm32mp15-pinctrl.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
b/arch/arm/dts/stm32mp15-pinctrl.dtsi
index dc329bf531e..6a5b4016f66 100644
--- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
@@ -1865,6 +1865,19 @@
};
};
 
+   uart5_pins_a: uart5-0 {
+   pins1 {
+   pinmux = ; /* UART5_TX */
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <0>;
+   };
+   pins2 {
+   pinmux = ; /* UART5_RX */
+   bias-disable;
+   };
+   };
+
uart7_pins_a: uart7-0 {
pins1 {
pinmux = ; /* UART7_TX */
-- 
2.35.1



[PATCH 2/6] ARM: dts: stm32: Add alternate pinmux for UART4 pins

2022-06-13 Thread Marek Vasut
Add another mux option for UART4 pins, this is used on DRC Compact board.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 arch/arm/dts/stm32mp15-pinctrl.dtsi | 30 +
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
b/arch/arm/dts/stm32mp15-pinctrl.dtsi
index 823ef2e2aab..dc329bf531e 100644
--- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
@@ -1835,6 +1835,36 @@
};
};
 
+   uart4_pins_d: uart4-3 {
+   pins1 {
+   pinmux = ; /* UART4_TX */
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <0>;
+   };
+   pins2 {
+   pinmux = ; /* UART4_RX */
+   bias-disable;
+   };
+   };
+
+   uart4_idle_pins_d: uart4-idle-3 {
+   pins1 {
+   pinmux = ; /* UART4_TX */
+   };
+   pins2 {
+   pinmux = ; /* UART4_RX */
+   bias-disable;
+   };
+   };
+
+   uart4_sleep_pins_d: uart4-sleep-3 {
+   pins {
+   pinmux = , /* UART4_TX */
+; /* UART4_RX */
+   };
+   };
+
uart7_pins_a: uart7-0 {
pins1 {
pinmux = ; /* UART7_TX */
-- 
2.35.1



[PATCH 1/6] ARM: dts: stm32: Add alternate pinmux for UART3 pins

2022-06-13 Thread Marek Vasut
Add another mux option for UART3 pins, this is used on DRC Compact board.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 arch/arm/dts/stm32mp15-pinctrl.dtsi | 41 +
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
b/arch/arm/dts/stm32mp15-pinctrl.dtsi
index f0d66d8c6e3..823ef2e2aab 100644
--- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
@@ -2134,6 +2134,47 @@
};
};
 
+   usart3_pins_e: usart3-4 {
+   pins1 {
+   pinmux = , /* USART3_TX */
+; /* USART3_RTS */
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <0>;
+   };
+   pins2 {
+   pinmux = , /* USART3_RX */
+; /* 
USART3_CTS_NSS */
+   bias-pull-up;
+   };
+   };
+
+   usart3_idle_pins_e: usart3-idle-4 {
+   pins1 {
+   pinmux = , /* USART3_TX 
*/
+; /* 
USART3_CTS_NSS */
+   };
+   pins2 {
+   pinmux = ; /* USART3_RTS */
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <0>;
+   };
+   pins3 {
+   pinmux = ; /* USART3_RX */
+   bias-pull-up;
+   };
+   };
+
+   usart3_sleep_pins_e: usart3-sleep-4 {
+   pins {
+   pinmux = , /* USART3_TX 
*/
+, /* USART3_RTS 
*/
+, /* 
USART3_CTS_NSS */
+; /* USART3_RX 
*/
+   };
+   };
+
usbotg_hs_pins_a: usbotg-hs-0 {
pins {
pinmux = ; /* OTG_ID */
-- 
2.35.1



Re: [PATCH] intel: n5x: ddr: update license

2022-06-13 Thread Marek Vasut

On 6/13/22 03:35, Chee, Tien Fong wrote:
[...]

On 6/10/22 13:23, tien.fong.c...@intel.com wrote:

From: Tien Fong Chee 

All the source code of sdram_n5x.c are from Intel, update the license
to use both GPL2.0 and BSD-3 Clause because this copy of code may used
for open source and internal project.

Signed-off-by: Tien Fong Chee 


That's still fine, since nobody did any other changes to this driver yet.

Do you plan to collect those socfpga patches yourself and send a PR for next ?


Yes, that's my next plan after submitting this patch for review.


Excellent, thanks!


Re: [PATCH] arm64: dts: imx8mq-kontron-pitx-imx8m-u-boot.dtsi: disable assigned clocks

2022-06-11 Thread Marek Vasut

On 6/11/22 08:09, Heiko Thiery wrote:

With the move to use DM_CLK the boards uart stops working. The used
properties are not supported by the imx8mq clock driver. Thus
the correct baudrate cannot be selected. Remove this properties here and
the board can start with working uart. Keep it in the main dts because
linux handles these porperties fine.


Is this yet another

75f080df46f ("Revert "clk: Detect failure to set defaults"")

kind of failure, where the clock uclass returns error code on something?

Maybe the clock uclass should rather warn than fail outright, so we 
won't need these workarounds in DT files ?


Re: [PATCH 2/8] configs: imx8mm_data_modul_edm_sbc: not select SPL_RAM_DEVICE

2022-06-11 Thread Marek Vasut

On 6/10/22 17:51, Alper Nebi Yasak wrote:

On 08/06/2022 01:54, Marek Vasut wrote:

I still don't see why we should randomly damage board configs to work
around what looks like a bug in binman -- are we now implementing
workarounds instead of trying to fully understand issues and implement
proper fixes for those ?

Why can't we fix binman instead ?


There aren't many people who understand binman internals enough to fix
things properly. Simon is less active recently, I'm not as productive as
I'd like (even then I don't know the C parts), and my availability will
get way worse in a few weeks. I wanted to prioritize reviews so that
others' work don't stall, didn't know when this could be fixed, thus a
clean workaround until then (not 'instead of') seemed OK.

Anyway, doesn't matter now that I managed to send a fix, but I didn't
want to keep the question unanswered.


Thanks, I appreciate the proper fix.


Re: [PATCH] intel: n5x: ddr: update license

2022-06-11 Thread Marek Vasut

On 6/10/22 13:23, tien.fong.c...@intel.com wrote:

From: Tien Fong Chee 

All the source code of sdram_n5x.c are from Intel, update the license to
use both GPL2.0 and BSD-3 Clause because this copy of code may used for
open source and internal project.

Signed-off-by: Tien Fong Chee 


That's still fine, since nobody did any other changes to this driver yet.

Do you plan to collect those socfpga patches yourself and send a PR for 
next ?


Re: [PATCH 0/5] spl: binman: Fixes for BINMAN_SYMBOLS

2022-06-10 Thread Marek Vasut

On 6/10/22 12:58, Alper Nebi Yasak wrote:

There's some trouble with an i.MX8M series [1] trying to use binman
symbols. The crux of it is the 'u_boot_any' symbols BINMAN_SYMBOLS
configs declare, and the boards creating partial binman images including
an SPL without a U-Boot the symbol is referring to.


Nice ! Thanks !


Re: [PATCH 2/8] configs: imx8mm_data_modul_edm_sbc: not select SPL_RAM_DEVICE

2022-06-07 Thread Marek Vasut

On 6/7/22 22:54, Alper Nebi Yasak wrote:

On 07/06/2022 21:11, Marek Vasut wrote:

On 6/7/22 19:26, Alper Nebi Yasak wrote:

On 06/06/2022 17:07, Marek Vasut wrote:

On 6/3/22 09:17, Peng Fan (OSS) wrote:

From: Peng Fan 

i.MX8M use FIT image, not RAW image. And to support binman symbols,
u_boot_any could be optimized if RAW image is not selected, otherwise
there will be build failure. So not select SPL_RAW_DEVICE


Is it RAW device/image or RAM device/image ? There seem to be some
confusion here. It also seems this might break start of U-Boot by JTAG
upload, right ?


The previous patch disables SPL_RAW_IMAGE_SUPPORT for i.MX8M boards
(already disabled for this), this one disables SPL_RAM_DEVICE (was only
enabled for this). Both need to be disabled for this series in its
current form to avoid a binman symbol-related error, but this commit
message suffers from being copy-paste of the previous one.


OK, I am really confused now. What binman symbol error ?


When BINMAN_SYMBOLS is enabled, some binman 'u_boot_any' symbols are
declared in common/spl/spl.c. They are marked as 'unused', but if
anything actually uses them they survive optimization and show up in the
spl/u-boot-spl ELF file. When binman is building an image including a
'u-boot-spl' entry, it sees these symbols and tries to fill them in with
appropriate values about 'u-boot'-like entries. If there is no such
entry in the same image as the 'u-boot-spl', binman raises an error
about this.

In this case, SPL_RAW_IMAGE_SUPPORT and SPL_RAM_DEVICE both enable code
that uses the 'u_boot_any' symbols. However, the i.MX8M binman image
descriptions try to specify the binman images in a modular way, and one
of the images has a 'u-boot-spl' without any 'u-boot'-like entries.
Which means enabling the configs ends up triggering the error above.

See my reply to an earlier version [1] (this is actually v6 of this
series) about what could be done to solve this properly. Also see
previous discussions [2][3] for more info.

[1] Re: [PATCH V4 1/8] spl: guard u_boot_any with X86
https://lore.kernel.org/u-boot/334898af-f495-acb5-0c5a-1f4a9acce...@gmail.com/

[2] using binman fails boot
https://lore.kernel.org/u-boot/CAJ+vNU0BZDr2q0ZPQkoQBP1eBhbYmQfJMYraSgOvWXwZ=yf...@mail.gmail.com/T/#u

[3] imx8: ls1028a: Drop raw image support
https://lore.kernel.org/u-boot/20210801205951.2202789-1-...@chromium.org/T/#u


Is this some attempt at papering over a bug ?

Simon recommended disabling SPL_RAW_IMAGE_SUPPORT to resolve this error
in the previous discussions [3]. But I'm leaning towards saying yes
here, I think it's a workaround to something that should change on the
binman side. I'm not exactly sure what or how. Just now I thought maybe
we could add a BINMAN_SYMBOLS_FOR_NEXT_PHASE config or so, which would
enable the 'u_boot_any' etc. symbols instead of BINMAN_SYMBOLS.

Regardless, I think this version is a good enough step in the right
direction and more changes can still be done afterwards, so I'm not
asking for a new version.


I still don't see why we should randomly damage board configs to work 
around what looks like a bug in binman -- are we now implementing 
workarounds instead of trying to fully understand issues and implement 
proper fixes for those ?


Why can't we fix binman instead ?


[PULL] u-boot-usb/master

2022-06-07 Thread Marek Vasut

The following changes since commit 8f527342db4160a1f030de6fe4a1591787cce65a:

  Prepare v2022.07-rc4 (2022-06-06 10:25:13 -0400)

are available in the Git repository at:

  git://source.denx.de/u-boot-usb.git master

for you to fetch changes up to 02544db9a7ffd352129f51c8987fc5a6e2b31a8b:

  misc: Port USB251xB/xBi Hi-Speed Hub Controller Driver from Linux 
(2022-06-07 16:14:20 +0200)



Chunfeng Yun (1):
  usb: xhci-mtk: disable all ports when disable host controller

Marek Vasut (1):
  misc: Port USB251xB/xBi Hi-Speed Hub Controller Driver from Linux

 drivers/misc/Kconfig|   9 ++
 drivers/misc/Makefile   |   1 +
 drivers/misc/usb251xb.c | 605 
+

 drivers/usb/host/xhci-mtk.c |   6 +-
 4 files changed, 619 insertions(+), 2 deletions(-)
 create mode 100644 drivers/misc/usb251xb.c


Re: [PATCH 2/8] configs: imx8mm_data_modul_edm_sbc: not select SPL_RAM_DEVICE

2022-06-07 Thread Marek Vasut

On 6/7/22 19:26, Alper Nebi Yasak wrote:

On 06/06/2022 17:07, Marek Vasut wrote:

On 6/3/22 09:17, Peng Fan (OSS) wrote:

From: Peng Fan 

i.MX8M use FIT image, not RAW image. And to support binman symbols,
u_boot_any could be optimized if RAW image is not selected, otherwise
there will be build failure. So not select SPL_RAW_DEVICE


Is it RAW device/image or RAM device/image ? There seem to be some
confusion here. It also seems this might break start of U-Boot by JTAG
upload, right ?


The previous patch disables SPL_RAW_IMAGE_SUPPORT for i.MX8M boards
(already disabled for this), this one disables SPL_RAM_DEVICE (was only
enabled for this). Both need to be disabled for this series in its
current form to avoid a binman symbol-related error, but this commit
message suffers from being copy-paste of the previous one.


OK, I am really confused now. What binman symbol error ?

Is this some attempt at papering over a bug ?

[...]


Re: [PATCH 2/8] configs: imx8mm_data_modul_edm_sbc: not select SPL_RAM_DEVICE

2022-06-06 Thread Marek Vasut

On 6/3/22 09:17, Peng Fan (OSS) wrote:

From: Peng Fan 

i.MX8M use FIT image, not RAW image. And to support binman symbols,
u_boot_any could be optimized if RAW image is not selected, otherwise
there will be build failure. So not select SPL_RAW_DEVICE


Is it RAW device/image or RAM device/image ? There seem to be some 
confusion here. It also seems this might break start of U-Boot by JTAG 
upload, right ?


Re: [PATCH 01/12] env: Complete generic support for writable list

2022-06-06 Thread Marek Vasut

On 5/29/22 17:37, Jan Kiszka wrote:

On 29.05.22 03:46, Marek Vasut wrote:

On 5/28/22 15:02, Jan Kiszka wrote:

From: Jan Kiszka 

This completes what 890feecaab72 started by selecting ENV_APPEND and
ENV_IS_NOWHERE and by moving this driver to top if the list. This


s@if the list@of the list@


ensures that load operations pick up both the default env and the
permitted parts of the next-prio location. When writing though, we must
not use NOWHERE and rather need to forward directly to the first
external location.


Isn't the env load order a board-specific setting ?



There can always be special cases, but I don't see why it should be
_always_ board-specific.


Because this is a special case, right ?


With this change, boards only need to define the list of writable
variables but no longer have to provide a custom env_get_location
implementation.


This also brings in a lot of ifdeffery and extra complexity. If you
implement this as a board-specific env_get_location() override, you can
avoid that. Try:

enum env_location env_get_location(enum env_operation op, int prio)
{
  if (op == ENVOP_SAVE) {
  if (prio == 0)
  return ENVL_SPI_FLASH;
  } else {
  if (prio == 0)
  return ENVL_NOWHERE;
  if (prio == 1)
  return ENVL_SPI_FLASH;
  }

  return ENVL_UNKNOWN;
}


This is exactly what I would like to avoid, having to carry such a
generic function (minus that hard-coded the choice of storage - this can
be controlled via .config) in every board.


Just for a quick statistics -- how many boards would make use of this 
generic function ?


If you want to make this into a generic patch, can you somehow reduce 
the ever-growing ifdeffery, so that the patch won't add to it so much ? 
I suspect the code above can help with that, maybe it can be used to 
remove at least the env_locations[] reordering ifdeffery ?


Re: [PATCH 01/12] env: Complete generic support for writable list

2022-05-28 Thread Marek Vasut

On 5/28/22 15:02, Jan Kiszka wrote:

From: Jan Kiszka 

This completes what 890feecaab72 started by selecting ENV_APPEND and
ENV_IS_NOWHERE and by moving this driver to top if the list. This


s@if the list@of the list@


ensures that load operations pick up both the default env and the
permitted parts of the next-prio location. When writing though, we must
not use NOWHERE and rather need to forward directly to the first
external location.


Isn't the env load order a board-specific setting ?


With this change, boards only need to define the list of writable
variables but no longer have to provide a custom env_get_location
implementation.


This also brings in a lot of ifdeffery and extra complexity. If you 
implement this as a board-specific env_get_location() override, you can 
avoid that. Try:


enum env_location env_get_location(enum env_operation op, int prio)
{
 if (op == ENVOP_SAVE) {
 if (prio == 0)
 return ENVL_SPI_FLASH;
 } else {
 if (prio == 0)
 return ENVL_NOWHERE;
 if (prio == 1)
 return ENVL_SPI_FLASH;
 }

 return ENVL_UNKNOWN;
}


Re: [PATCH v2] arm: socfpga: Add the terasic de10-standard board

2022-05-25 Thread Marek Vasut

On 5/23/22 03:54, Humberto Naves wrote:

Use the de10-nano files as templates for the de10-standard board.
The files in qts directory are generated by quartus from the GHRD
design.


Applied, thanks.


[PULL] u-boot-socfpga/master

2022-05-23 Thread Marek Vasut

The following changes since commit c0a1409d21e7b342566dccb9cc1d38209aabc5ff:

  configs: Resync with savedefconfig (2022-05-23 13:56:21 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-socfpga.git master

for you to fetch changes up to 1b05136a6ca8387175ca7bf1aa66a9c40a153cc2:

  arm: socfpga: Add the terasic de10-standard board (2022-05-23 
21:28:07 +0200)



Humberto Naves (1):
  arm: socfpga: Add the terasic de10-standard board

 arch/arm/dts/socfpga_cyclone5_de10_standard.dts |  86 +++
 arch/arm/mach-socfpga/Kconfig   |   7 +
 board/terasic/de10-standard/MAINTAINERS |   5 +
 board/terasic/de10-standard/Makefile|   6 +
 board/terasic/de10-standard/qts/iocsr_config.h  | 659 
+
 board/terasic/de10-standard/qts/pinmux_config.h | 218 


 board/terasic/de10-standard/qts/pll_config.h|  84 +++
 board/terasic/de10-standard/qts/sdram_config.h  | 344 


 board/terasic/de10-standard/socfpga.c   |   5 +
 configs/socfpga_de10_standard_defconfig |  66 +
 include/configs/socfpga_de10_standard.h |  18 +++
 11 files changed, 1498 insertions(+)
 create mode 100644 arch/arm/dts/socfpga_cyclone5_de10_standard.dts
 create mode 100644 board/terasic/de10-standard/MAINTAINERS
 create mode 100644 board/terasic/de10-standard/Makefile
 create mode 100644 board/terasic/de10-standard/qts/iocsr_config.h
 create mode 100644 board/terasic/de10-standard/qts/pinmux_config.h
 create mode 100644 board/terasic/de10-standard/qts/pll_config.h
 create mode 100644 board/terasic/de10-standard/qts/sdram_config.h
 create mode 100644 board/terasic/de10-standard/socfpga.c
 create mode 100644 configs/socfpga_de10_standard_defconfig
 create mode 100644 include/configs/socfpga_de10_standard.h


Re: dwc_eth_qos driver for tegra

2022-05-23 Thread Marek Vasut

On 5/23/22 13:46, Rasmus Villemoes wrote:

On 23/05/2022 12.57, Marek Vasut wrote:

On 5/23/22 11:17, Rasmus Villemoes wrote:

Hi


Hi,


I'm looking at switching the dwc_eth_qos driver over to use
dm_eth_phy_connect(). However, I'm a little puzzled by the code for the
tegra variant. The comment at the top of the file, as well as
tegra186.dtsi, says

    phy-mode = "rgmii";

But eqos_get_interface_tegra186() returns a hard-coded
PHY_INTERFACE_MODE_MII. Now the commit which introduced the ->interface
abstraction, ac2d4efb16e (net: dwc_eth_qos: add Ethernet stm32mp1
support), and that eqos_get_interface_tegra186() function, changed

-   eqos->phy = phy_connect(eqos->mii, 0, dev, 0);

to

+   eqos->phy = phy_connect(eqos->mii, 0, dev,
+   eqos->config->interface(dev));

and that last hard-coded 0 in the former phy_connect() is indeed
equivalent to PHY_INTERFACE_MODE_MII.

So which is it? It would be nice if one could just rely on
dm_eth_phy_connect() picking up the correct value from device tree, and
drop all the code which duplicates parsing of phy-mode from the ethernet
driver.


linux-2.6$ git grep mii arch/arm64/boot/dts/nvidia/tegra186*
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi: phy-mode = "rgmii";
arch/arm64/boot/dts/nvidia/tegra186-p3509-+p3636-0001.dts: phy-mode
= "rgmii-id";

So probably RGMII ?


Well, yes, I also did check the linux device tree files which also says
rgmii, but that doesn't explain why the U-Boot driver code seems to
ignore that entirely and use mii hardcoded, both before and after
ac2d4efb16e.

So another way of asking: does this driver actually work today, and/or
has it worked at some point? I assume the answer is yes - after all, the
very first commit "supports the specific configuration used in NVIDIA's
Tegra186 chip", but that commit also did that phy_connect() with a last
argument of 0 aka PHY_INTERFACE_MODE_MII.

And would it break if one started taking the phy-mode from device tree?
If so, should device tree be updated to say "mii"?


I think we wait for nvidia to answer all this, I don't have that SoC 
available.


Re: dwc_eth_qos driver for tegra

2022-05-23 Thread Marek Vasut

On 5/23/22 11:17, Rasmus Villemoes wrote:

Hi


Hi,


I'm looking at switching the dwc_eth_qos driver over to use
dm_eth_phy_connect(). However, I'm a little puzzled by the code for the
tegra variant. The comment at the top of the file, as well as
tegra186.dtsi, says

   phy-mode = "rgmii";

But eqos_get_interface_tegra186() returns a hard-coded
PHY_INTERFACE_MODE_MII. Now the commit which introduced the ->interface
abstraction, ac2d4efb16e (net: dwc_eth_qos: add Ethernet stm32mp1
support), and that eqos_get_interface_tegra186() function, changed

-   eqos->phy = phy_connect(eqos->mii, 0, dev, 0);

to

+   eqos->phy = phy_connect(eqos->mii, 0, dev,
+   eqos->config->interface(dev));

and that last hard-coded 0 in the former phy_connect() is indeed
equivalent to PHY_INTERFACE_MODE_MII.

So which is it? It would be nice if one could just rely on
dm_eth_phy_connect() picking up the correct value from device tree, and
drop all the code which duplicates parsing of phy-mode from the ethernet
driver.


linux-2.6$ git grep mii arch/arm64/boot/dts/nvidia/tegra186*
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi: phy-mode = "rgmii";
arch/arm64/boot/dts/nvidia/tegra186-p3509-+p3636-0001.dts: 
phy-mode = "rgmii-id";


So probably RGMII ?


Re: [PATCH] arm: socfpga: Add the terasic de10-standard board

2022-05-22 Thread Marek Vasut

On 5/22/22 17:53, Humberto Naves wrote:

Hi Marek,


Hi,


Thanks for the quick review!


Doesn't the PLL config also come from quartus ? It should all come from
it. See doc/README.socfpga


My mistake, I will update the patch using all the files created by the
bsp-create-settings.


Thanks


I think a lot of those board/config-specific copyright messages could
use an update, I think they should be assigned to you. Please do a quick
V2 with that change. Besides that:


Please advise what I should do there. For this particular board I adapted
the code from the de10-nano board, which already had these copyright
messages.


I'm not a lawyer. Maybe the most safe approach is to keep the original 
copyright and add your own in addition to it ?


Re: [PATCH] arm: socfpga: Add the terasic de10-standard board

2022-05-21 Thread Marek Vasut

On 5/21/22 19:32, Humberto Naves wrote:

Used the de10-nano files as templates for the de10-standard board.
Changed the iocsr_config.h and pinmux_config.h based on the handoff
files generated by quartus. Finally, the pll_config.h was copied
from the altera cyclone5-socdk board.


Doesn't the PLL config also come from quartus ? It should all come from 
it. See doc/README.socfpga



Signed-off-by: Humberto Naves 
Cc: Marek Vasut 


I think a lot of those board/config-specific copyright messages could 
use an update, I think they should be assigned to you. Please do a quick 
V2 with that change. Besides that:


Reviewed-by: Marek Vasut 


[PATCH v2] ARM: dts: imx: Add support for DH electronics i.MX8M Plus DHCOM and PDK2

2022-05-21 Thread Marek Vasut
Add support for DH electronics i.MX8M Plus DHCOM SoM on PDK2 carrier board.
Currently supported are serial console, EQoS and FEC ethernets, eMMC, SD,
SPI NOR and USB 3.0 host.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
--
V2: - Drop CONFIG_SYS_I2C_SPEED and CONFIG_SYS_PROMPT_HUSH_PS2 from
  include/configs/imx8mp_dhcom_pdk2.h
---
 arch/arm/dts/Makefile |1 +
 arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi|  141 ++
 arch/arm/dts/imx8mp-dhcom-pdk2.dts|  152 ++
 arch/arm/dts/imx8mp-dhcom-som.dtsi| 1042 ++
 arch/arm/mach-imx/imx8m/Kconfig   |8 +
 board/dhelectronics/dh_imx8mp/Kconfig |   15 +
 board/dhelectronics/dh_imx8mp/MAINTAINERS |8 +
 board/dhelectronics/dh_imx8mp/Makefile|   13 +
 board/dhelectronics/dh_imx8mp/common.c|   37 +
 .../dh_imx8mp/imx8mp_dhcom_pdk2.c |  186 ++
 .../dh_imx8mp/imximage-lpddr4.cfg |8 +
 board/dhelectronics/dh_imx8mp/lpddr4_timing.h |   13 +
 .../dh_imx8mp/lpddr4_timing_4G_32.c   | 1844 +
 board/dhelectronics/dh_imx8mp/spl.c   |  187 ++
 configs/imx8mp_dhcom_pdk2_defconfig   |  244 +++
 include/configs/imx8mp_dhcom_pdk2.h   |  113 +
 16 files changed, 4012 insertions(+)
 create mode 100644 arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mp-dhcom-pdk2.dts
 create mode 100644 arch/arm/dts/imx8mp-dhcom-som.dtsi
 create mode 100644 board/dhelectronics/dh_imx8mp/Kconfig
 create mode 100644 board/dhelectronics/dh_imx8mp/MAINTAINERS
 create mode 100644 board/dhelectronics/dh_imx8mp/Makefile
 create mode 100644 board/dhelectronics/dh_imx8mp/common.c
 create mode 100644 board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
 create mode 100644 board/dhelectronics/dh_imx8mp/imximage-lpddr4.cfg
 create mode 100644 board/dhelectronics/dh_imx8mp/lpddr4_timing.h
 create mode 100644 board/dhelectronics/dh_imx8mp/lpddr4_timing_4G_32.c
 create mode 100644 board/dhelectronics/dh_imx8mp/spl.c
 create mode 100644 configs/imx8mp_dhcom_pdk2_defconfig
 create mode 100644 include/configs/imx8mp_dhcom_pdk2.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 83630af4f67..576206cb4b0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -936,6 +936,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mn-beacon-kit.dtb \
imx8mq-mnt-reform2.dtb \
imx8mq-phanbell.dtb \
+   imx8mp-dhcom-pdk2.dtb \
imx8mp-evk.dtb \
imx8mp-phyboard-pollux-rdk.dtb \
imx8mp-venice.dtb \
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi 
b/arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi
new file mode 100644
index 000..ae838caebcf
--- /dev/null
+++ b/arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2022 Marek Vasut 
+ */
+
+#include "imx8mp-u-boot.dtsi"
+
+/ {
+   aliases {
+   eeprom0 = 
+   eeprom1 = 
+   mmc0 =  /* MicroSD */
+   mmc1 =  /* eMMC */
+   mmc2 =  /* SDIO */
+   };
+
+   config {
+   dh,ram-coding-gpios = < 22 0>, < 23 0>, < 24 
0>;
+   };
+
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <>;
+   u-boot,dm-spl;
+   };
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   /delete-property/ assigned-clocks;
+   /delete-property/ assigned-clock-parents;
+   /delete-property/ assigned-clock-rates;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_i2c3 {
+   u-boot,dm-spl;
+};
+
+_i2c3_gpio {
+   u-boot,dm-spl;
+};
+
+_pmic {
+   u-boot,dm-spl;
+};
+
+_uart1 {
+   u-boot,dm-spl;
+};
+
+_usdhc2 {
+   u-boot,dm-spl;
+};
+
+_usdhc2_100mhz {
+   u-boot,dm-spl;
+};
+
+_usdhc2_200mhz {
+   u-boot,dm-spl;
+};
+
+_usdhc2_vmmc {
+   u-boot,dm-spl;
+};
+
+_usdhc3 {
+   u-boot,dm-spl;
+};
+
+_usdhc3_100mhz {
+   u-boot,dm-spl;
+};
+
+_usdhc3_100mhz {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+
+   regulators {
+   u-boot,dm-spl;
+   };
+};
+
+_usdhc2_vmmc {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+/* SDIO WiFi */
+ {
+   status = "disabled";
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk2.dts 
b/arch/arm/dts/imx8mp-dhcom-pdk2.dts
new file mode 100644
index 000..e95abfb3e89
--- /dev/null
+++ b/arch/arm/dts/imx8mp-dhcom-pdk2.dts
@@ -0,0 +1,152 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2022 Marek Vasut 
+ */
+
+/dts-v1/

Re: [RFC PATCH 2/2] ARM: stm32: activate OF_LIVE for DHSOM

2022-05-20 Thread Marek Vasut

On 5/19/22 18:46, Patrick Delaunay wrote:

Activate the live DT with CONFIG_OF_LIVE to reduce the DT parsing
time.

Signed-off-by: Patrick Delaunay 


Tested-by: Marek Vasut 


Re: [RFC PATCH 1/2] board: dhelectronics: stm32mp1: convert to livetree

2022-05-20 Thread Marek Vasut

On 5/19/22 18:46, Patrick Delaunay wrote:

Replace call to fdt_*() functions and access to gd->fdt_blob
with call to ofnode_*() functions to support a live tree.

Signed-off-by: Patrick Delaunay 


I see your point regarding the speed up, wow.

Tested-by: Marek Vasut 


[PULL] u-boot-usb/master

2022-05-20 Thread Marek Vasut

The following changes since commit f83bd23e2a0e9861969c9d43395299a14f25ddda:

  Merge https://source.denx.de/u-boot/custodians/u-boot-marvell 
(2022-05-18 08:41:13 -0400)


are available in the Git repository at:

  git://source.denx.de/u-boot-usb.git master

for you to fetch changes up to 868d58f69c7ceda5c886293cf15f4e39493517a2:

  usb: dwc3: Fix non-usb3 configurations (2022-05-20 23:30:36 +0200)


Jan Kiszka (1):
  usb: dwc3: Fix non-usb3 configurations

Mark Kettenis (1):
  usb: xhci-dwc3: Support role switch default role

 drivers/usb/common/common.c | 16 
 drivers/usb/dwc3/dwc3-generic.c |  4 +++-
 drivers/usb/host/xhci-dwc3.c|  6 ++
 include/linux/usb/otg.h | 10 ++
 4 files changed, 35 insertions(+), 1 deletion(-)



Re: i.MX8MP usb status

2022-05-20 Thread Marek Vasut

On 5/20/22 20:21, Tim Harvey wrote:

On Fri, May 20, 2022 at 10:08 AM Tim Harvey  wrote:


On Wed, May 4, 2022 at 5:53 AM Marek Vasut  wrote:


On 5/4/22 14:26, Peng Fan wrote:

Hi Marek,


Hi,


Since you did some work on i.MX8MP USB, may I know the status?
Does host/device mode both supported in upstream?


I only have HOST option available, so for me this is only HOST.

I did not test GADGET or OTG .



Marek,

Do you still have IMX8MP USB host working on top of v2022.07-rc2,
master, or imx-master? It worked for me previously at some point
applying your dwc3 glue series [1] from a repo you pointed me to that
I can no longer find but now I see an issue where device_probe fails:

u-boot=> usb start
starting USB...
Bus usb@3810: probe failed, error -61
Bus usb@3820: probe failed, error -61
No working controllers found

The failure is that dwc3_glue_probe fails to find 'usb3-phy' due to
that being in the phy-names node of usb@3810 and not its parent
usb@32f10100

Am I missing a patch perhaps to dwc3_glue_probe in dwc3-generic.c?

Tim
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=293112


Marek,

I didn't explain that right. The failure is that dwc3_glue_probe gets
passed usb3_0:usb@32f10100 USB (controller dev) and tries to find
usb3-phy in the phy-names prop of that dev where-as the phy-name node
is in the usb_dwc3_0:usb@3810 phy child of the controller instead

However, I still wonder if I'm missing a patch that deals with this or
if something just changed between testing your patch series and now.


There's already fix in u-boot-usb/master , see the topmost patch there.


Re: [PATCH v2 8/8] ARM: imx6: Adapt device tree selection in DH board file

2022-05-20 Thread Marek Vasut

On 5/20/22 10:46, Philip Oberfichtner wrote:

Before this commit device tree selection could rely solely on
differentiating the iMX6 processor variant Q and DL. After adding two new
carrier boards, the DRC02 and the picoITX, the interchangeability of SoMs
makes this approach infeasible.

It is now required to specify the carrier board (dhcom-drc02,
dhcom-picoitx or dhcom-pdk2) at compile time using
CONFIG_DEFAULT_DEVICETREE. The SoM is determined at runtime as before.

Signed-off-by: Philip Oberfichtner 


Reviewed-by: Marek Vasut 


Re: [PATCH v2] usb: dwc3: add a SPL_USB_DWC3_GENERIC option for the dwc3 driver

2022-05-20 Thread Marek Vasut

On 5/20/22 11:08, Stefano Babic wrote:

Hi Marek,

don't you mind if I apply to my u-booz-imx this (that really belongs to 
your competence area) ?


It fixes warnings for the librem5, and it is a pity if I cannot merge it.


Just pick it via imx, that's fine, I don't expect conflict.

Reviewed-by: Marek Vasut 


Re: [PATCH 4/4] ARM: imx: imx5: Introduce and use UART_BASE_ADDR(n)

2022-05-20 Thread Marek Vasut

On 5/20/22 09:30, Stefano Babic wrote:

Hi Marek,

On 24.04.22 23:44, Marek Vasut wrote:

Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base
address. Convert all board configurations to this new macro. This is the
first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a
clean up, no functional change.

The new macro contains compile-time test to verify N is in suitable
range. The test works such that it multiplies constant N by constant
double-negation of size of a non-empty structure, i.e. it multiplies
constant N by constant 1 in each successful compilation case.

The non-empty structure may contain C11 _Static_assert(), make use of
this and place the kernel variant of static assert in there, so that
it performs the compile-time check for N in the correct range. Note
that it is not possible to directly use static_assert in compound
statements, hence this convoluted construct.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---


I have not found the reason, but this breaks MX51:


All this UART_BASE_ADDR stuff is postponed, just drop for now.


Re: [Uboot-stm32] [PATCH 08/16] arm: stm32mp: add support of STM32MP13x

2022-05-20 Thread Marek Vasut

On 5/20/22 09:24, Patrice CHOTARD wrote:

[...]


@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
+/*
+ * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+ *
+ * Configuration settings for the STMicroelectonics STM32MP15x boards


s/STMicroelectonics/STMicroelectronics


s@STM32MP15x@STM32MP13x@ too ;-)

[...]

btw. as a general comment, please do use these [...] to reduce the patch 
content you comment on. Searching for that one line in a wall of quoted 
text can be not fun.


Re: [PATCH v2 2/2] pmic: pca9450: Add regulator driver

2022-05-20 Thread Marek Vasut

On 5/20/22 09:00, Stefano Babic wrote:

Hi Tim, Marek,


Hi,


It's defined differently in include/power/bd71837.h (where it should
also likely be changed to something that doesn't collide)
$ git grep DVS_BUCK_RUN_MASK include/
include/power/bd71837.h:#define DVS_BUCK_RUN_MASK   0x3f
include/power/pca9450.h:#define DVS_BUCK_RUN_MASK   0x7f

Granted, board/gateworks/venice/spl.c is the only file I see that
includes both of those.

Is this merged yet?


No, I set in patchworks that a new version is needed.


Just to be sure this won't miss another MR, there is already V3 posted 
and you are explicitly in To:


[PATCH v3 1/2] pmic: pca9450: Add upstream regulators subnode match
[PATCH v3 2/2] pmic: pca9450: Add regulator driver


Re: [PATCH v2 2/2] pmic: pca9450: Add regulator driver

2022-05-19 Thread Marek Vasut

On 5/20/22 00:24, Tim Harvey wrote:

[...]


diff --git a/include/power/pca9450.h b/include/power/pca9450.h
index 27703bb1f91..b714fc3477d 100644
--- a/include/power/pca9450.h
+++ b/include/power/pca9450.h
@@ -56,4 +56,15 @@ enum {

  int power_pca9450_init(unsigned char bus, unsigned char addr);

+enum {
+   NXP_CHIP_TYPE_PCA9450A = 0,
+   NXP_CHIP_TYPE_PCA9450BC,
+   NXP_CHIP_TYPE_AMOUNT
+};
+
+#define DVS_BUCK_RUN_MASK  0x7f


Marek,

Looks like DVS_BUCK_RUN_MASK is a bad choice of names and should be
something like PCA9450_DVS_BUCK_RUN_MASK.

It's defined differently in include/power/bd71837.h (where it should
also likely be changed to something that doesn't collide)
$ git grep DVS_BUCK_RUN_MASK include/
include/power/bd71837.h:#define DVS_BUCK_RUN_MASK   0x3f
include/power/pca9450.h:#define DVS_BUCK_RUN_MASK   0x7f

Granted, board/gateworks/venice/spl.c is the only file I see that
includes both of those.

Is this merged yet?


No, I am eagerly waiting for this to be merged.

I sent V3, that should address the ventana .


[PATCH v3 2/2] pmic: pca9450: Add regulator driver

2022-05-19 Thread Marek Vasut
Add PCA9450 regulator driver. This is complementary driver for the BUCKn
and LDOn regulators provided by the PCA9450 PMIC driver. Currently the
driver permits reading the settngs and configuring the BUCKn and LDOn
regulators.

Reviewed-by: Fabio Estevam 
Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
V2: Add RB by Fabio
V3: Rename DVS_BUCK_RUN_MASK to PCA9450_DVS_BUCK_RUN_MASK
---
 drivers/power/pmic/pca9450.c  |   6 +-
 drivers/power/regulator/Kconfig   |  15 ++
 drivers/power/regulator/Makefile  |   1 +
 drivers/power/regulator/pca9450.c | 333 ++
 include/power/pca9450.h   |  11 +
 5 files changed, 363 insertions(+), 3 deletions(-)
 create mode 100644 drivers/power/regulator/pca9450.c

diff --git a/drivers/power/pmic/pca9450.c b/drivers/power/pmic/pca9450.c
index 26c876c9c45..116ac49a8db 100644
--- a/drivers/power/pmic/pca9450.c
+++ b/drivers/power/pmic/pca9450.c
@@ -83,9 +83,9 @@ static struct dm_pmic_ops pca9450_ops = {
 };
 
 static const struct udevice_id pca9450_ids[] = {
-   { .compatible = "nxp,pca9450a", .data = 0x25, },
-   { .compatible = "nxp,pca9450b", .data = 0x25, },
-   { .compatible = "nxp,pca9450c", .data = 0x25, },
+   { .compatible = "nxp,pca9450a", .data = NXP_CHIP_TYPE_PCA9450A, },
+   { .compatible = "nxp,pca9450b", .data = NXP_CHIP_TYPE_PCA9450BC, },
+   { .compatible = "nxp,pca9450c", .data = NXP_CHIP_TYPE_PCA9450BC, },
{ }
 };
 
diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index 9145408b3c9..d6cea8ec666 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -60,6 +60,21 @@ config SPL_DM_REGULATOR_BD71837
This config enables implementation of driver-model regulator uclass
features for regulators on ROHM BD71837 and BD71847 in SPL.
 
+config DM_REGULATOR_PCA9450
+   bool "Enable Driver Model for NXP PCA9450 regulators"
+   depends on DM_REGULATOR && DM_PMIC_PCA9450
+   help
+   This config enables implementation of driver-model regulator uclass
+   features for regulators on NXP PCA9450 PMICs. PCA9450 contains 6 bucks
+   and 5 LDOS. The driver implements get/set api for value and enable.
+
+config SPL_DM_REGULATOR_PCA9450
+   bool "Enable Driver Model for NXP PCA9450 regulators in SPL"
+   depends on DM_REGULATOR_PCA9450
+   help
+   This config enables implementation of driver-model regulator uclass
+   features for regulators on ROHM PCA9450 in SPL.
+
 config DM_REGULATOR_DA9063
bool "Enable Driver Model for REGULATOR DA9063"
depends on DM_REGULATOR && DM_PMIC_DA9063
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index b9883df9281..bc736068bca 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_$(SPL_)DM_REGULATOR_DA9063) += da9063.o
 obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
 obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_BD71837) += bd71837.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_PCA9450) += pca9450.o
 obj-$(CONFIG_$(SPL_)REGULATOR_PWM) += pwm_regulator.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_FAN53555) += fan53555.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_COMMON) += regulator_common.o
diff --git a/drivers/power/regulator/pca9450.c 
b/drivers/power/regulator/pca9450.c
new file mode 100644
index 000..23badaa3326
--- /dev/null
+++ b/drivers/power/regulator/pca9450.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * NXP PCA9450 regulator driver
+ * Copyright (C) 2022 Marek Vasut 
+ *
+ * Largely based on:
+ * ROHM BD71837 regulator driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HW_STATE_CONTROL 0
+#define DEBUG
+
+/**
+ * struct pca9450_vrange - describe linear range of voltages
+ *
+ * @min_volt:  smallest voltage in range
+ * @step:  how much voltage changes at each selector step
+ * @min_sel:   smallest selector in the range
+ * @max_sel:   maximum selector in the range
+ */
+struct pca9450_vrange {
+   unsigned intmin_volt;
+   unsigned intstep;
+   u8  min_sel;
+   u8  max_sel;
+};
+
+/**
+ * struct pca9450_plat - describe regulator control registers
+ *
+ * @name:  name of the regulator. Used for matching the dt-entry
+ * @enable_reg:register address used to enable/disable regulator
+ * @enablemask:register mask used to enable/disable regulator
+ * @volt_reg:  register address used to configure regulator voltage
+ * @volt_mask: register mask used to configure regulator voltage
+ * @ranges:pointer to ranges of regulator voltages and matching register
+ * values
+ * @numranges: number of voltage ranges pointed by ran

[PATCH v3 1/2] pmic: pca9450: Add upstream regulators subnode match

2022-05-19 Thread Marek Vasut
The upstream DT regulators node subnodes are named BUCKn and LDOn,
the downstream DT regulators node subnodes are named buckn and ldon,
add the upstream match.

Reviewed-by: Fabio Estevam 
Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
V2: Add RB by Fabio
V3: No change
---
 drivers/power/pmic/pca9450.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/power/pmic/pca9450.c b/drivers/power/pmic/pca9450.c
index 2394b196c56..26c876c9c45 100644
--- a/drivers/power/pmic/pca9450.c
+++ b/drivers/power/pmic/pca9450.c
@@ -19,8 +19,10 @@ DECLARE_GLOBAL_DATA_PTR;
 static const struct pmic_child_info pmic_children_info[] = {
/* buck */
{ .prefix = "b", .driver = PCA9450_REGULATOR_DRIVER},
+   { .prefix = "B", .driver = PCA9450_REGULATOR_DRIVER},
/* ldo */
{ .prefix = "l", .driver = PCA9450_REGULATOR_DRIVER},
+   { .prefix = "L", .driver = PCA9450_REGULATOR_DRIVER},
{ },
 };
 
-- 
2.35.1



[PATCH] ARM: dts: imx: Add support for DH electronics i.MX8M Plus DHCOM and PDK2

2022-05-19 Thread Marek Vasut
Add support for DH electronics i.MX8M Plus DHCOM SoM on PDK2 carrier board.
Currently supported are serial console, EQoS and FEC ethernets, eMMC, SD,
SPI NOR and USB 3.0 host.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 arch/arm/dts/Makefile |1 +
 arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi|  141 ++
 arch/arm/dts/imx8mp-dhcom-pdk2.dts|  152 ++
 arch/arm/dts/imx8mp-dhcom-som.dtsi| 1042 ++
 arch/arm/mach-imx/imx8m/Kconfig   |8 +
 board/dhelectronics/dh_imx8mp/Kconfig |   15 +
 board/dhelectronics/dh_imx8mp/MAINTAINERS |8 +
 board/dhelectronics/dh_imx8mp/Makefile|   13 +
 board/dhelectronics/dh_imx8mp/common.c|   37 +
 .../dh_imx8mp/imx8mp_dhcom_pdk2.c |  186 ++
 .../dh_imx8mp/imximage-lpddr4.cfg |8 +
 board/dhelectronics/dh_imx8mp/lpddr4_timing.h |   13 +
 .../dh_imx8mp/lpddr4_timing_4G_32.c   | 1844 +
 board/dhelectronics/dh_imx8mp/spl.c   |  187 ++
 configs/imx8mp_dhcom_pdk2_defconfig   |  246 +++
 include/configs/imx8mp_dhcom_pdk2.h   |  116 ++
 16 files changed, 4017 insertions(+)
 create mode 100644 arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mp-dhcom-pdk2.dts
 create mode 100644 arch/arm/dts/imx8mp-dhcom-som.dtsi
 create mode 100644 board/dhelectronics/dh_imx8mp/Kconfig
 create mode 100644 board/dhelectronics/dh_imx8mp/MAINTAINERS
 create mode 100644 board/dhelectronics/dh_imx8mp/Makefile
 create mode 100644 board/dhelectronics/dh_imx8mp/common.c
 create mode 100644 board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
 create mode 100644 board/dhelectronics/dh_imx8mp/imximage-lpddr4.cfg
 create mode 100644 board/dhelectronics/dh_imx8mp/lpddr4_timing.h
 create mode 100644 board/dhelectronics/dh_imx8mp/lpddr4_timing_4G_32.c
 create mode 100644 board/dhelectronics/dh_imx8mp/spl.c
 create mode 100644 configs/imx8mp_dhcom_pdk2_defconfig
 create mode 100644 include/configs/imx8mp_dhcom_pdk2.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 83630af4f67..576206cb4b0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -936,6 +936,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mn-beacon-kit.dtb \
imx8mq-mnt-reform2.dtb \
imx8mq-phanbell.dtb \
+   imx8mp-dhcom-pdk2.dtb \
imx8mp-evk.dtb \
imx8mp-phyboard-pollux-rdk.dtb \
imx8mp-venice.dtb \
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi 
b/arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi
new file mode 100644
index 000..ae838caebcf
--- /dev/null
+++ b/arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2022 Marek Vasut 
+ */
+
+#include "imx8mp-u-boot.dtsi"
+
+/ {
+   aliases {
+   eeprom0 = 
+   eeprom1 = 
+   mmc0 =  /* MicroSD */
+   mmc1 =  /* eMMC */
+   mmc2 =  /* SDIO */
+   };
+
+   config {
+   dh,ram-coding-gpios = < 22 0>, < 23 0>, < 24 
0>;
+   };
+
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <>;
+   u-boot,dm-spl;
+   };
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   /delete-property/ assigned-clocks;
+   /delete-property/ assigned-clock-parents;
+   /delete-property/ assigned-clock-rates;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_i2c3 {
+   u-boot,dm-spl;
+};
+
+_i2c3_gpio {
+   u-boot,dm-spl;
+};
+
+_pmic {
+   u-boot,dm-spl;
+};
+
+_uart1 {
+   u-boot,dm-spl;
+};
+
+_usdhc2 {
+   u-boot,dm-spl;
+};
+
+_usdhc2_100mhz {
+   u-boot,dm-spl;
+};
+
+_usdhc2_200mhz {
+   u-boot,dm-spl;
+};
+
+_usdhc2_vmmc {
+   u-boot,dm-spl;
+};
+
+_usdhc3 {
+   u-boot,dm-spl;
+};
+
+_usdhc3_100mhz {
+   u-boot,dm-spl;
+};
+
+_usdhc3_100mhz {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+
+   regulators {
+   u-boot,dm-spl;
+   };
+};
+
+_usdhc2_vmmc {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+/* SDIO WiFi */
+ {
+   status = "disabled";
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk2.dts 
b/arch/arm/dts/imx8mp-dhcom-pdk2.dts
new file mode 100644
index 000..e95abfb3e89
--- /dev/null
+++ b/arch/arm/dts/imx8mp-dhcom-pdk2.dts
@@ -0,0 +1,152 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2022 Marek Vasut 
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include "imx8mp-dhcom-som.dtsi"
+
+/ {
+   mo

[PATCH] usb: dwc3: Fix support for usb3-phy PHY configuration

2022-05-19 Thread Marek Vasut
The dev_read_stringlist_search() in generic_phy_get_by_name()
returns -ENODATA in case of missing "phy-names", which is the
case on everything except ZynqMP. Handle this -ENODATA instead
of failing outright, which fixes the glue on everything else.

Fixes: 142d50fbce7 ("usb: dwc3: Add support for usb3-phy PHY configuration")
Signed-off-by: Marek Vasut 
Cc: Michal Simek 
---
 drivers/usb/dwc3/dwc3-generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 6e1a1d066b4..9608c5c599a 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -468,7 +468,7 @@ static int dwc3_glue_probe(struct udevice *dev)
ret = generic_phy_init();
if (ret)
return ret;
-   } else if (ret != -ENOENT) {
+   } else if (ret != -ENOENT && ret != -ENODATA) {
debug("could not get phy (err %d)\n", ret);
return ret;
}
-- 
2.35.1



Re: [PATCH 8/8] ARM: imx6: Adapt device tree selection in DH board file

2022-05-19 Thread Marek Vasut

On 5/19/22 13:08, Philip Oberfichtner wrote:

Before this commit device tree selection could rely solely on
differentiating the iMX6 processor variant Q and DL. After adding two new
carrier boards, the DRC02 and the picoITX, the interchangeability of SoMs
makes this approach infeasible.

It is now required to specify the carrier board (dhcom-drc02,
dhcom-picoitx or dhcom-pdk2) at compile time using
CONFIG_DEFAULT_DEVICETREE. The SoM is determined at runtime as before.

Signed-off-by: Philip Oberfichtner 
---

  board/dhelectronics/dh_imx6/dh_imx6.c | 22 ++
  1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c 
b/board/dhelectronics/dh_imx6/dh_imx6.c
index 6059f96e80..c63fc1dd8a 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6.c
@@ -227,14 +227,20 @@ int checkboard(void)
  #ifdef CONFIG_MULTI_DTB_FIT
  int board_fit_config_name_match(const char *name)
  {
-   if (is_mx6dq()) {
-   if (!strcmp(name, "imx6q-dhcom-pdk2"))
-   return 0;
-   } else if (is_mx6sdl()) {


Careful here ^ is_mx6sdl() matches on Solo and DualLite.


-   if (!strcmp(name, "imx6dl-dhcom-pdk2"))
-   return 0;
-   }
+   /* Determine carrier board at compile time and SoM at runtime */
+   const size_t size = 32;
+   char *car, *som, dt[size];
+
+   car = strchr(CONFIG_DEFAULT_DEVICE_TREE, '-'); /* i.e. -dhcom-drc02 */
+
+   som = is_mx6dq()   ? "imx6q"  :
+ is_mx6dl()   ? "imx6dl" :
+ is_mx6solo() ? "imx6s"  : NULL;
+
+   if (!(car && som))
+   return -1;
  
-	return -1;

+   snprintf(dt, size, "%s%s", som, car);
+   return strcmp(name, dt);


This will break imx6s-dhcom-pdk2 , which used the imx6dl-dhcom-pdk2 DT 
which was fine, because U-Boot is single core anyway.


Try something like this:

/* Test SoC prefix */
if (is_mx6dq()) {
if (strncmp(name, "imx6q-"))
return -1;
} else if (is_mx6sdl()) {
if (strncmp(name, "imx6s-") && strncmp(name, "imx6dl-"))
return -1;
}

/* Test board suffix */
a = strchr(CONFIG_DEFAULT_DEVICE_TREE, '-'); /* i.e. -dhcom-drc02 */
b = strchr(name, '-'); /* i.e. -dhcom-drc02 */

return strcmp(a, b) ? -1 : 0;

I _think_ that should work and cover all combinations. (and of course, 
pick better variable names than a,b)


Re: [PATCH 7/8] ARM: dts: imx: Configure FEC for iMX6QDL DRC02

2022-05-19 Thread Marek Vasut

On 5/19/22 13:08, Philip Oberfichtner wrote:

Add a u-boot dtsi for configuring the fec node of the DH DRC02.


nit: FEC (in caps), means Freescale Ethernet Controller or some such.

Reviewed-by: Marek Vasut 


Re: [PATCH 6/8] ARM: dts: imx: Configure FEC for iMX6QDL picoITX

2022-05-19 Thread Marek Vasut

On 5/19/22 13:08, Philip Oberfichtner wrote:

Add a u-boot dtsi for configuring the fec node of the DH picoITX.


Reviewed-by: Marek Vasut 


Re: [PATCH 5/8] ARM: dts: imx: Simplify fec node for iMX6QDL DHCOM boards

2022-05-19 Thread Marek Vasut

On 5/19/22 13:08, Philip Oberfichtner wrote:

Firstly the fec can now use the regulator reg_eth_vio from
imx6qdl-dhcom-som.dtsi instead of defining its own.

Secondly the  node is moved to the more generic SoM device tree
file, because it can be used by multiple boards.


Reviewed-by: Marek Vasut 


Re: [PATCH 1/8] ARM: imx6: Fix broken DT path in DH board file

2022-05-19 Thread Marek Vasut

On 5/19/22 13:08, Philip Oberfichtner wrote:

In the dhelectronics iMX6 board file fix the outdated eeprom path by


nit: DH electronics


using a DT label instead.

The label has been newly created for all iMX6QDL DHCOM boards.

Signed-off-by: Philip Oberfichtner 


Reviewed-by: Marek Vasut 


Re: [PATCH] ARM: dts: stm32: Configure Buck3 voltage per PMIC NVM on Avenger96

2022-05-18 Thread Marek Vasut

On 5/18/22 18:53, Patrick DELAUNAY wrote:

Hi,


Hi,

[...]


I let you handle OF_LIVE  for your boards (code & defconfig),

FYI: it is already enable for STMicroelectronics boards (defconfig 
and in driver, mach-stm32mp and board code).


But look:

c387e626147 ("Merge branch '2022-05-11-Kconfig-cleanups-etc'")
with this patch:

u-boot$ git grep fdt_getprop.*comp board/dhelectronics/dh_stm32mp1/*c 
board/st/stm32mp1/*c
board/dhelectronics/dh_stm32mp1/board.c:    fdt_compat = 
fdt_getprop(gd->fdt_blob, 0, "compatible",
board/dhelectronics/dh_stm32mp1/board.c:    compat = 
fdt_getprop(gd->fdt_blob, 0, "compatible", NULL);
board/dhelectronics/dh_stm32mp1/board.c:    fdt_compat = 
fdt_getprop(gd->fdt_blob, 0, "compatible",


board/st/stm32mp1/stm32mp1.c:   fdt_compat = fdt_getprop(gd->fdt_blob, 
0, "compatible",
board/st/stm32mp1/stm32mp1.c:   fdt_compat = 
fdt_getprop(gd->fdt_blob, 0, "compatible",


Am I missing a patch or something ?



No, it is my fault, I forget these references

I prepare a serie to solve this issue in STMicroelectronics Boards code.


Hehe, glad I could help you spot it.

You can prepare very much identical series for DH and CC me on it, the 
changes will be very much the same and I can test the result just fine.


[...]


Re: [PATCH] ARM: dts: stm32: Configure Buck3 voltage per PMIC NVM on Avenger96

2022-05-17 Thread Marek Vasut

On 5/17/22 17:32, Patrick DELAUNAY wrote:

Hi,


+static int board_get_regulator_buck3_nvm_uv_av96(int *uv)
+{
+    const void *fdt = gd->fdt_blob;
+    struct udevice *dev;
+    u8 bucks_vout = 0;
+    const char *prop;
+    int len, ret;
+
+    /* Check whether this is Avenger96 board. */
+    prop = fdt_getprop(fdt, 0, "compatible", );



This API is not compatible with CONFIG_OF_LIVE

consider replacement with ofnode_read_prop or with 
of_machine_is_compatible, for example


if (!of_machine_is_compatible(prop, "arrow,stm32mp15xx-avenger96"))
 return -EINVAL;


I explicitly don't want to use of_machine_is_compatible, I need to 
search for the avenger96 substring in the machine compatible, since 
the stm32mp15xx can be anything (15{1,3,7}{a,d}) and it might not 
even have the arrow prefix.



Ok, I check on existing DT and I found only on compatible with 
"avenger96" string.


arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts:15:

 compatible = "arrow,stm32mp15xx-avenger96", "st,stm32mp15x";

But you can forget my proposal with of_machine_is_compatible, consider:

    prop = ofnode_read_prop(ofnode_root(), "compatible", );


But it is just minor remark.


There are multiple other fdt_getprop() calls in both board/st/ and 
board/dh , maybe if you want to do OF_LIVE enablement (do you?), let's 
convert them all at once ?



Ok. It is more a minor remark linked to checkpatch warning for all the 
added code:


"Use the livetree API (dev_read_...)"


I let you handle OF_LIVE  for your boards (code & defconfig),

FYI: it is already enable for STMicroelectronics boards (defconfig and 
in driver, mach-stm32mp and board code).


But look:

c387e626147 ("Merge branch '2022-05-11-Kconfig-cleanups-etc'")
with this patch:

u-boot$ git grep fdt_getprop.*comp board/dhelectronics/dh_stm32mp1/*c 
board/st/stm32mp1/*c
board/dhelectronics/dh_stm32mp1/board.c:fdt_compat = 
fdt_getprop(gd->fdt_blob, 0, "compatible",
board/dhelectronics/dh_stm32mp1/board.c:compat = 
fdt_getprop(gd->fdt_blob, 0, "compatible", NULL);
board/dhelectronics/dh_stm32mp1/board.c:fdt_compat = 
fdt_getprop(gd->fdt_blob, 0, "compatible",


board/st/stm32mp1/stm32mp1.c:   fdt_compat = fdt_getprop(gd->fdt_blob, 
0, "compatible",
board/st/stm32mp1/stm32mp1.c:   fdt_compat = 
fdt_getprop(gd->fdt_blob, 0, "compatible",


Am I missing a patch or something ?

Do you expect this patch for next pull-request for v2022.07 or for 
next ?


Ideally 2022.07.



Ok, I plan that.


Thank you


Re: [PATCH] ARM: dts: stm32: Configure Buck3 voltage per PMIC NVM on Avenger96

2022-05-17 Thread Marek Vasut

On 5/17/22 15:43, Patrick DELAUNAY wrote:

Hi,


Hi,


+static int board_get_regulator_buck3_nvm_uv_av96(int *uv)
+{
+    const void *fdt = gd->fdt_blob;
+    struct udevice *dev;
+    u8 bucks_vout = 0;
+    const char *prop;
+    int len, ret;
+
+    /* Check whether this is Avenger96 board. */
+    prop = fdt_getprop(fdt, 0, "compatible", );



This API is not compatible with CONFIG_OF_LIVE

consider replacement with ofnode_read_prop or with 
of_machine_is_compatible, for example


if (!of_machine_is_compatible(prop, "arrow,stm32mp15xx-avenger96"))
 return -EINVAL;


I explicitly don't want to use of_machine_is_compatible, I need to 
search for the avenger96 substring in the machine compatible, since 
the stm32mp15xx can be anything (15{1,3,7}{a,d}) and it might not even 
have the arrow prefix.



Ok, I check on existing DT and I found only on compatible with 
"avenger96" string.


arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts:15:

     compatible = "arrow,stm32mp15xx-avenger96", "st,stm32mp15x";

But you can forget my proposal with of_machine_is_compatible, consider:

    prop = ofnode_read_prop(ofnode_root(), "compatible", );


But it is just minor remark.


There are multiple other fdt_getprop() calls in both board/st/ and 
board/dh , maybe if you want to do OF_LIVE enablement (do you?), let's 
convert them all at once ?



Do you expect this patch for next pull-request for v2022.07 or for next ?


Ideally 2022.07.


Re: [PATCH] ARM: dts: stm32: Configure Buck3 voltage per PMIC NVM on Avenger96

2022-05-17 Thread Marek Vasut

On 5/17/22 14:39, Patrick DELAUNAY wrote:

Hi,

[...]


+static int board_get_regulator_buck3_nvm_uv_av96(int *uv)
+{
+    const void *fdt = gd->fdt_blob;
+    struct udevice *dev;
+    u8 bucks_vout = 0;
+    const char *prop;
+    int len, ret;
+
+    /* Check whether this is Avenger96 board. */
+    prop = fdt_getprop(fdt, 0, "compatible", );



This API is not compatible with CONFIG_OF_LIVE

consider replacement with ofnode_read_prop or with 
of_machine_is_compatible, for example


if (!of_machine_is_compatible(prop, "arrow,stm32mp15xx-avenger96"))
 return -EINVAL;


I explicitly don't want to use of_machine_is_compatible, I need to 
search for the avenger96 substring in the machine compatible, since the 
stm32mp15xx can be anything (15{1,3,7}{a,d}) and it might not even have 
the arrow prefix.


Re: [PATCH][RESEND] mtd: spi-nor-ids: Add Winbond W25Q128JW ID

2022-05-16 Thread Marek Vasut

On 5/9/22 14:40, Marek Vasut wrote:

On 4/25/22 06:39, Stefan Roese wrote:

On 4/24/22 23:39, Marek Vasut wrote:

Add ID for Winbond W25Q128JW device. This is a 128 Mbit QSPI NOR.
Tested on W25Q128JWPIM part.

Signed-off-by: Marek Vasut 
Cc: Horatiu Vultur 
Cc: Jagan Teki 
Cc: Simon Goldschmidt 
Cc: Stefan Roese 
Cc: Vignesh R 


Reviewed-by: Stefan Roese 


Can this be applied soon ?


+CC Tom , can you pick this ?


[PATCH] ARM: dts: stm32: Configure Buck3 voltage per PMIC NVM on Avenger96

2022-05-11 Thread Marek Vasut
The Avenger96 board comes in multiple regulator configurations.
 - rev.100 or rev.200 have Buck3 preconfigured to 3V3 operation on
   boot and contains extra Enpirion EP53A8LQI DCDC converter which
   supplies the IO. Reduce Buck3 voltage to 2V9 to not waste power.
 - rev.200L have Buck3 preconfigured to 1V8 operation and have no
   Enpirion EP53A8LQI DCDC anymore, the IO is supplied from Buck3.

Configure the Buck3 voltage on this board per PMIC NVM settings and
update buck3 voltage limits in DT passed to OS before booting OS to
prevent potential hardware damage.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 arch/arm/dts/stm32mp15xx-dhcor-io1v8.dtsi |   2 +-
 board/dhelectronics/dh_stm32mp1/board.c   | 109 +-
 2 files changed, 107 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/stm32mp15xx-dhcor-io1v8.dtsi 
b/arch/arm/dts/stm32mp15xx-dhcor-io1v8.dtsi
index 9937b28548c..e20917824bf 100644
--- a/arch/arm/dts/stm32mp15xx-dhcor-io1v8.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcor-io1v8.dtsi
@@ -19,7 +19,7 @@
 };
 
  {
-   regulator-min-microvolt = <290>;
+   regulator-min-microvolt = <180>;
regulator-max-microvolt = <290>;
 };
 
diff --git a/board/dhelectronics/dh_stm32mp1/board.c 
b/board/dhelectronics/dh_stm32mp1/board.c
index 67273f90992..d407f0bf592 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -594,14 +594,98 @@ static void board_init_fmc2(void)
setbits_le32(STM32_FMC2_BASE + STM32_FMC2_BCR1, STM32_FMC2_BCRx_FMCEN);
 }
 
+#ifdef CONFIG_DM_REGULATOR
+#define STPMIC_NVM_BUCKS_VOUT_SHR  0xfc
+#define STPMIC_NVM_BUCKS_VOUT_SHR_BUCK_1V2 0
+#define STPMIC_NVM_BUCKS_VOUT_SHR_BUCK_1V8 1
+#define STPMIC_NVM_BUCKS_VOUT_SHR_BUCK_3V0 2
+#define STPMIC_NVM_BUCKS_VOUT_SHR_BUCK_3V3 3
+#define STPMIC_NVM_BUCKS_VOUT_SHR_BUCK_MASKGENMASK(1, 0)
+#define STPMIC_NVM_BUCKS_VOUT_SHR_BUCK_OFFSET(n)   n) - 1) & 3) * 2)
+static int board_get_regulator_buck3_nvm_uv_av96(int *uv)
+{
+   const void *fdt = gd->fdt_blob;
+   struct udevice *dev;
+   u8 bucks_vout = 0;
+   const char *prop;
+   int len, ret;
+
+   /* Check whether this is Avenger96 board. */
+   prop = fdt_getprop(fdt, 0, "compatible", );
+   if (!prop || !len)
+   return -ENODEV;
+
+   if (!strstr(prop, "avenger96"))
+   return -EINVAL;
+
+   /* Read out STPMIC1 NVM and determine default Buck3 voltage. */
+   ret = uclass_get_device_by_driver(UCLASS_MISC,
+ DM_DRIVER_GET(stpmic1_nvm),
+ );
+   if (ret)
+   return ret;
+
+   ret = misc_read(dev, STPMIC_NVM_BUCKS_VOUT_SHR, _vout, 1);
+   if (ret != 1)
+   return -EINVAL;
+
+   bucks_vout >>= STPMIC_NVM_BUCKS_VOUT_SHR_BUCK_OFFSET(3);
+   bucks_vout &= STPMIC_NVM_BUCKS_VOUT_SHR_BUCK_MASK;
+
+   /*
+* Avenger96 board comes in multiple regulator configurations:
+* - rev.100 or rev.200 have Buck3 preconfigured to 3V3 operation on
+*   boot and contains extra Enpirion EP53A8LQI DCDC converter which
+*   supplies the IO. Reduce Buck3 voltage to 2V9 to not waste power.
+* - rev.200L have Buck3 preconfigured to 1V8 operation and have no
+*   Enpirion EP53A8LQI DCDC anymore, the IO is supplied from Buck3.
+*/
+   if (bucks_vout == STPMIC_NVM_BUCKS_VOUT_SHR_BUCK_3V3)
+   *uv = 290;
+   else
+   *uv = 180;
+
+   return 0;
+}
+
+static void board_init_regulator_av96(void)
+{
+   struct udevice *rdev;
+   int ret, uv;
+
+   ret = board_get_regulator_buck3_nvm_uv_av96();
+   if (ret)/* Not Avenger96 board. */
+   return;
+
+   ret = regulator_get_by_devname("buck3", );
+   if (ret)
+   return;
+
+   /* Adjust Buck3 per preconfigured PMIC voltage from NVM. */
+   regulator_set_value(rdev, uv);
+}
+
+static void board_init_regulator(void)
+{
+   board_init_regulator_av96();
+
+   regulators_enable_boot_on(_DEBUG);
+}
+#else
+static inline int board_get_regulator_buck3_nvm_uv_av96(int *uv)
+{
+   return -EINVAL;
+}
+
+static inline void board_init_regulator(void) {}
+#endif
+
 /* board dependent setup after realloc */
 int board_init(void)
 {
board_key_check();
 
-#ifdef CONFIG_DM_REGULATOR
-   regulators_enable_boot_on(_DEBUG);
-#endif
+   board_init_regulator();
 
sysconf_init();
 
@@ -721,6 +805,25 @@ int board_interface_eth_init(struct udevice *dev,
 #if defined(CONFIG_OF_BOARD_SETUP)
 int ft_board_setup(void *blob, struct bd_info *bd)
 {
+   const char *buck3path = "/soc/i2c@5c002000/stpmic@33/regulators/buck3";
+   i

Re: [PATCH] misc: Port USB251xB/xBi Hi-Speed Hub Controller Driver from Linux

2022-05-09 Thread Marek Vasut

On 4/10/22 06:27, Marek Vasut wrote:

This patch adds a driver for configuration of the Microchip USB251xB/xBi
USB 2.0 hub controller series with USB 2.0 upstream connectivity, SMBus
configuration interface and two to four USB 2.0 downstream ports.

This is ported from Linux as of Linux kernel commit
5c2b9c61ae5d8 ("usb: usb251xb: add boost-up property support")

Signed-off-by: Marek Vasut 
Cc: Bin Meng 
Cc: Michal Simek 
Cc: Simon Glass 


If there are no comments, I will apply this soon.


Re: [PATCH][RESEND] mtd: spi-nor-ids: Add Winbond W25Q128JW ID

2022-05-09 Thread Marek Vasut

On 4/25/22 06:39, Stefan Roese wrote:

On 4/24/22 23:39, Marek Vasut wrote:

Add ID for Winbond W25Q128JW device. This is a 128 Mbit QSPI NOR.
Tested on W25Q128JWPIM part.

Signed-off-by: Marek Vasut 
Cc: Horatiu Vultur 
Cc: Jagan Teki 
Cc: Simon Goldschmidt 
Cc: Stefan Roese 
Cc: Vignesh R 


Reviewed-by: Stefan Roese 


Can this be applied soon ?


Re: [PATCH v2 1/2] pmic: pca9450: Add upstream regulators subnode match

2022-05-09 Thread Marek Vasut

On 4/24/22 23:40, Marek Vasut wrote:

The upstream DT regulators node subnodes are named BUCKn and LDOn,
the downstream DT regulators node subnodes are named buckn and ldon,
add the upstream match.

Reviewed-by: Fabio Estevam 
Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
V2: Add RB by Fabio
---
  drivers/power/pmic/pca9450.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/power/pmic/pca9450.c b/drivers/power/pmic/pca9450.c
index 2394b196c56..26c876c9c45 100644
--- a/drivers/power/pmic/pca9450.c
+++ b/drivers/power/pmic/pca9450.c
@@ -19,8 +19,10 @@ DECLARE_GLOBAL_DATA_PTR;
  static const struct pmic_child_info pmic_children_info[] = {
/* buck */
{ .prefix = "b", .driver = PCA9450_REGULATOR_DRIVER},
+   { .prefix = "B", .driver = PCA9450_REGULATOR_DRIVER},
/* ldo */
{ .prefix = "l", .driver = PCA9450_REGULATOR_DRIVER},
+   { .prefix = "L", .driver = PCA9450_REGULATOR_DRIVER},
{ },
  };


Can this be applied soon ?


Re: [PATCH] HSD #1508031235-1: Override udelay for secure section

2022-05-09 Thread Marek Vasut

On 5/9/22 06:59, dinesh.mani...@intel.com wrote:

Drop the HSD from subject, use ARM: socfpga: tags .

[...]


+__always_inline void __udelay(unsigned long usec)
+{
+   /* get current timestamp */
+   u64 tmp = __get_time_stamp() + __usec_to_tick(usec);
+
+   while (__get_time_stamp() < tmp + 1) /* loop till event */
+   ;


Please handle wrap-around here.


Re: [PATCH V2] ARM: imx: imx8m: Adjust thermal trip points for Industrial parts

2022-05-08 Thread Marek Vasut

On 5/8/22 04:59, Adam Ford wrote:

On Sat, May 7, 2022 at 5:00 PM Marek Vasut  wrote:


On 5/7/22 14:04, Adam Ford wrote:

If the thermal sensor is enabled in U-Boot, adjust the cpu-thermal
trip points for industrial rated parts.  This should apply to 8MQ,
8MM, 8MN, and 8MP.

Signed-off-by: Adam Ford 
Reviewed-by: Tim Harvey 
---
V2:  Switch the check from looking for industrial or checkoing for
   anything but commerical.  This expands the trip point updates
   other grades as well.


Are the industrial and automotive trip points identical ?


I do not know nor do I have any to test, but Francisco asked for the
change.  I would expect the corresponding values would be fetched with
get_cpu_temp_grade()


Ah, I see. But then I have to wonder, why are we updating only 
non-commercial trip points ? Why not update them always ?


[PATCH] ARM: imx: mx5: Convert MX53 Menlo board to DM I2C and DM RTC

2022-05-07 Thread Marek Vasut
Convert the board to DM I2C and DM RTC. This leads to removal of board
side iomuxc configuration, which is now done using pin control driver,
and conversion of board side legacy I2C accessors to DM ones.

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
 board/menlo/m53menlo/m53menlo.c | 27 +++
 configs/m53menlo_defconfig  |  8 ++--
 2 files changed, 9 insertions(+), 26 deletions(-)

diff --git a/board/menlo/m53menlo/m53menlo.c b/board/menlo/m53menlo/m53menlo.c
index 9545e633a3d..61ab3844b87 100644
--- a/board/menlo/m53menlo/m53menlo.c
+++ b/board/menlo/m53menlo/m53menlo.c
@@ -226,16 +226,21 @@ static const char *lvds_compat_string;
 
 static int detect_lvds(struct display_info_t const *dev)
 {
+   struct udevice *idev, *ibus;
u8 touchid[23];
u8 *touchptr = [0];
int ret;
 
-   ret = i2c_set_bus_num(0);
+   ret = uclass_get_device_by_seq(UCLASS_I2C, 0, );
+   if (ret)
+   return 0;
+
+   ret = dm_i2c_probe(ibus, 0x38, 0, );
if (ret)
return 0;
 
/* Touchscreen is at address 0x38, ID register is 0xbb. */
-   ret = i2c_read(0x38, 0xbb, 1, touchid, sizeof(touchid));
+   ret = dm_i2c_read(idev, 0xbb, touchid, sizeof(touchid));
if (ret)
return 0;
 
@@ -385,23 +390,6 @@ splasherr:
return 0;
 }
 
-#define I2C_PAD_CTRL   (PAD_CTL_SRE_FAST | PAD_CTL_DSE_HIGH | \
-PAD_CTL_PUS_100K_UP | PAD_CTL_ODE)
-
-static void setup_iomux_i2c(void)
-{
-   static const iomux_v3_cfg_t i2c_pads[] = {
-   /* I2C1 */
-   NEW_PAD_CTRL(MX53_PAD_EIM_D28__I2C1_SDA, I2C_PAD_CTRL),
-   NEW_PAD_CTRL(MX53_PAD_EIM_D21__I2C1_SCL, I2C_PAD_CTRL),
-   /* I2C2 */
-   NEW_PAD_CTRL(MX53_PAD_EIM_D16__I2C2_SDA, I2C_PAD_CTRL),
-   NEW_PAD_CTRL(MX53_PAD_EIM_EB2__I2C2_SCL, I2C_PAD_CTRL),
-   };
-
-   imx_iomux_v3_setup_multiple_pads(i2c_pads, ARRAY_SIZE(i2c_pads));
-}
-
 static void setup_iomux_video(void)
 {
static const iomux_v3_cfg_t lcd_pads[] = {
@@ -505,7 +493,6 @@ int board_early_init_f(void)
 {
setup_iomux_uart();
setup_iomux_fec();
-   setup_iomux_i2c();
setup_iomux_nand();
setup_iomux_video();
 
diff --git a/configs/m53menlo_defconfig b/configs/m53menlo_defconfig
index df4907a8263..90d3e59e57d 100644
--- a/configs/m53menlo_defconfig
+++ b/configs/m53menlo_defconfig
@@ -11,9 +11,6 @@ CONFIG_NR_DRAM_BANKS=2
 CONFIG_ENV_SIZE=0x4000
 CONFIG_ENV_OFFSET=0x10
 CONFIG_TARGET_M53MENLO=y
-CONFIG_SYS_I2C_MXC_I2C1=y
-CONFIG_SYS_I2C_MXC_I2C2=y
-CONFIG_SYS_I2C_MXC_I2C3=y
 CONFIG_DM_GPIO=y
 CONFIG_DEFAULT_DEVICE_TREE="imx53-m53menlo"
 CONFIG_SPL_TEXT_BASE=0x70008000
@@ -53,7 +50,6 @@ CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_BOOTCOUNT=y
-CONFIG_CMD_DATE=y
 CONFIG_CMD_BTRFS=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
@@ -75,8 +71,7 @@ CONFIG_VERSION_VARIABLE=y
 CONFIG_DM=y
 CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_SYS_BOOTCOUNT_MAGIC=0x0B01C041
-CONFIG_SYS_I2C_LEGACY=y
-CONFIG_SPL_SYS_I2C_LEGACY=y
+CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_MXC=y
 CONFIG_FSL_ESDHC_IMX=y
 CONFIG_MTD=y
@@ -102,6 +97,7 @@ CONFIG_PINCTRL_IMX5=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_RTC=y
 CONFIG_RTC_M41T62=y
 CONFIG_MXC_UART=y
 CONFIG_SYSRESET=y
-- 
2.35.1



Re: [PATCH V2] ARM: imx: imx8m: Adjust thermal trip points for Industrial parts

2022-05-07 Thread Marek Vasut

On 5/7/22 14:04, Adam Ford wrote:

If the thermal sensor is enabled in U-Boot, adjust the cpu-thermal
trip points for industrial rated parts.  This should apply to 8MQ,
8MM, 8MN, and 8MP.

Signed-off-by: Adam Ford 
Reviewed-by: Tim Harvey 
---
V2:  Switch the check from looking for industrial or checkoing for
  anything but commerical.  This expands the trip point updates
  other grades as well.


Are the industrial and automotive trip points identical ?


[PULL] u-boot-usb/master

2022-05-06 Thread Marek Vasut

The following changes since commit 03b873b4f41010e4f85a72dd59016bb0b123dde1:

  Merge branch '2022-05-05-assorted-cleanups-and-fixes' (2022-05-05 
19:37:22 -0400)


are available in the Git repository at:

  git://source.denx.de/u-boot-usb.git master

for you to fetch changes up to 6aa8bde8786d7bd8077b1a4708fc4bffd4861baa:

  usb: host: ehci-generic: Remove DM_REGULATOR flag (2022-05-06 
10:38:39 +0200)



Patrice Chotard (2):
  usb: host: ehci-generic: Make usage of clock/reset bulk() API
  usb: host: ehci-generic: Remove DM_REGULATOR flag

 drivers/usb/host/ehci-generic.c | 117 
-

 1 file changed, 32 insertions(+), 85 deletions(-)



Re: i.MX8MP usb status

2022-05-05 Thread Marek Vasut

On 5/5/22 03:54, Peng Fan (OSS) wrote:



On 2022/5/4 20:53, Marek Vasut wrote:

On 5/4/22 14:26, Peng Fan wrote:

Hi Marek,


Hi,


Since you did some work on i.MX8MP USB, may I know the status?
Does host/device mode both supported in upstream?


I only have HOST option available, so for me this is only HOST.

I did not test GADGET or OTG .


Any plan on PTN5110 support?


I currently don't have hardware with USB-C , so not right now.

Do you plan to work on GADGET/OTG/USB-C ?


Typec interface exists in almost all i.MX8M EVK boards. So
I am thinking to enable gadget together with PTN5110 for uuu, but
seems typec requires quite lot work if porting linux code or we
reuse NXP U-Boot downstream ptn5110 code.


What's the problem with porting mainline Linux code ? (that would be the 
preferred approach, because then we could synchronize fixes from Linux)


If all you care about is mode switching between host/gadget, then a 
simpler driver might be preferred though.


Re: [PATCH 2/2] usb: host: ehci-generic: Remove DM_REGULATOR flag

2022-05-05 Thread Marek Vasut

On 5/5/22 16:58, Patrice CHOTARD wrote:

HI Marek

On 5/5/22 15:45, Marek Vasut wrote:

On 5/5/22 15:17, Patrice Chotard wrote:

Currently, DM_REGULATOR flag is no more needed to protect no DM core,
remove it.


DM_REGULATOR flag is actually Kconfig symbol.

Why is it no longer needed ? (answer should be in the commit message)


Ok, i will update the commit message as following :

Since commit 16cc5ad0b439 ("power: regulator: add dummy helper")
regulator dummy helper are always available even if DM_REGULATOR
is not set.
DM_REGULATOR flag is no more needed to protect no DM core,
remove it.

Is it OK for you ?


Yes please


Re: [PATCH 2/2] usb: host: ehci-generic: Remove DM_REGULATOR flag

2022-05-05 Thread Marek Vasut

On 5/5/22 15:17, Patrice Chotard wrote:

Currently, DM_REGULATOR flag is no more needed to protect no DM core,
remove it.


DM_REGULATOR flag is actually Kconfig symbol.

Why is it no longer needed ? (answer should be in the commit message)


Re: [PATCH 1/2] usb: host: ehci-generic: Make usage of clock/reset bulk() API

2022-05-05 Thread Marek Vasut

On 5/5/22 15:17, Patrice Chotard wrote:

[...]


@@ -81,68 +79,31 @@ static int ehci_usb_probe(struct udevice *dev)
struct generic_ehci *priv = dev_get_priv(dev);
struct ehci_hccr *hccr;
struct ehci_hcor *hcor;
-   int i, err, ret, clock_nb, reset_nb;
+   int err, ret;
  
  	err = 0;

-   priv->clock_count = 0;
-   clock_nb = ofnode_count_phandle_with_args(dev_ofnode(dev), "clocks",
- "#clock-cells", 0);
-   if (clock_nb > 0) {
-   priv->clocks = devm_kcalloc(dev, clock_nb, sizeof(struct clk),
-   GFP_KERNEL);
-   if (!priv->clocks)
-   return -ENOMEM;
-
-   for (i = 0; i < clock_nb; i++) {
-   err = clk_get_by_index(dev, i, >clocks[i]);
-
-   if (err < 0)
-   break;
-   err = clk_enable(>clocks[i]);
-   if (err && err != -ENOSYS) {
-   dev_err(dev, "failed to enable clock %d\n", i);
-   clk_free(>clocks[i]);
-   goto clk_err;
-   }
-   priv->clock_count++;
-   }
-   } else {
-   if (clock_nb != -ENOENT) {
-   dev_err(dev, "failed to get clock phandle(%d)\n",
-   clock_nb);
-   return clock_nb;
-   }
+   ret = clk_get_bulk(dev, >clocks);
+   if (ret) {
+   dev_err(dev, "Failed to get clocks\n");


Print the error code in the error message, so the user can immediately 
determine what went wrong without rebuilding the code with extra debug 
prints (and that goes for other messages and other drivers too, the 
error code is useful there).


dev_err(dev, "Failed to get clocks (ret=%d)\n", ret);

[...]


Re: [PATCH V2 07/16] imx: imx8mm-mx8menlo: drop unneeded watchdog settings

2022-05-05 Thread Marek Vasut

On 5/5/22 13:06, Peng Fan (OSS) wrote:

From: Peng Fan 

pinctrl_wdog as u-boot,dm-spl already marked in imx8mm-verdin-u-boot.dtsi,

The set_wdog_reset() function is not necessary as this is handled by
the imx_watchdog.c driver due to the 'fsl,ext-reset-output' property
being set.

Signed-off-by: Peng Fan 


Reviewed-by: Marek Vasut 

Thanks


Re: i.MX8MP usb status

2022-05-04 Thread Marek Vasut

On 5/4/22 14:26, Peng Fan wrote:

Hi Marek,


Hi,


Since you did some work on i.MX8MP USB, may I know the status?
Does host/device mode both supported in upstream?


I only have HOST option available, so for me this is only HOST.

I did not test GADGET or OTG .


Any plan on PTN5110 support?


I currently don't have hardware with USB-C , so not right now.

Do you plan to work on GADGET/OTG/USB-C ?


[PATCH] ARM: dts: stm32: Move DHCOR BUCK3 VDD 2V9 adjustment to 1V8 DTSI

2022-05-04 Thread Marek Vasut
The Buck3 on DHCOR is used to supply IO voltage. It can output either 3V3
in the default DHCOR configuration, or 2V9 in case of AV96 DHCOR variant
which has extra Empirion DCDC converter in front of the 1V8 IO supply, or
outright 1V8 in case of 1V8 IO DHCOR without the Empirion DCDC converter.

The 2V9 mode in case of AV96 DHCOR variant is used to reduce unnecessarily
high input voltage to the Empirion DCDC converter, so move it into matching
DTSI to stop confusing users.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 arch/arm/dts/stm32mp15xx-dhcor-io1v8.dtsi | 5 +
 arch/arm/dts/stm32mp15xx-dhcor-som.dtsi   | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/stm32mp15xx-dhcor-io1v8.dtsi 
b/arch/arm/dts/stm32mp15xx-dhcor-io1v8.dtsi
index 75172314d7a..9937b28548c 100644
--- a/arch/arm/dts/stm32mp15xx-dhcor-io1v8.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcor-io1v8.dtsi
@@ -18,6 +18,11 @@
};
 };
 
+ {
+   regulator-min-microvolt = <290>;
+   regulator-max-microvolt = <290>;
+};
+
 _regulators {
vdd-supply = <_io>;
 };
diff --git a/arch/arm/dts/stm32mp15xx-dhcor-som.dtsi 
b/arch/arm/dts/stm32mp15xx-dhcor-som.dtsi
index 44ecc470858..98033b51479 100644
--- a/arch/arm/dts/stm32mp15xx-dhcor-som.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcor-som.dtsi
@@ -77,8 +77,8 @@
 
vdd: buck3 {
regulator-name = "vdd";
-   regulator-min-microvolt = <290>;
-   regulator-max-microvolt = <290>;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
regulator-always-on;
regulator-initial-mode = <0>;
regulator-over-current-protection;
-- 
2.35.1



Re: [PATCH 06/17] imx: imx8mm-data-modul-edm-sbc: enable pinctrl_wdog in SPL

2022-05-03 Thread Marek Vasut

On 5/3/22 14:24, Peng Fan (OSS) wrote:

From: Peng Fan 

Add pinctrl_wdog.
Mark pinctrl_wdog as u-boot,dm-spl to clean up board code,
set_wdog_reset function could be handled by imx_watchdog.c driver.


There is already pinctrl_watchdog_gpio .

Any changes to the main DT should really be submitted to Linux first, 
else the U-Boot and Linux DT will be out of sync.


[PATCH] net: Fix discuss discard typo

2022-05-01 Thread Marek Vasut
Replace discuss with discard, that is what happens with packet with
incorrect checksum. Fix the typo.

Fixes: 4b37fd146bb ("Convert CONFIG_UDP_CHECKSUM to Kconfig")
Signed-off-by: Marek Vasut 
Cc: Ramon Fried 
Cc: Simon Glass 
---
 net/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/Kconfig b/net/Kconfig
index 964a4fe4999..564ea8b2d28 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -158,7 +158,7 @@ config UDP_CHECKSUM
default y if SANDBOX
help
  Enable this to verify the checksum on UDP packets. If the checksum
- is wrong then the packet is discussed and an error is shown, like
+ is wrong then the packet is discarded and an error is shown, like
  "UDP wrong checksum 29374a23 30ff3826"
 
 config BOOTP_SERVERIP
-- 
2.35.1



[PATCH 2/2] ARM: stm32: Use CONFIG_TFTP_TSIZE on DHSOM

2022-05-01 Thread Marek Vasut
Long TFTP transfers lead to a wall of # characters on UART, which in
the end may slow down the transfer itself. Use CONFIG_TFTP_TSIZE to
print progress in fewer # characters.

Signed-off-by: Marek Vasut 
Cc: Patrick Delaunay 
Cc: Patrice Chotard 
Cc: Ramon Fried 
---
 configs/stm32mp15_dhcom_basic_defconfig | 1 +
 configs/stm32mp15_dhcor_basic_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/stm32mp15_dhcom_basic_defconfig 
b/configs/stm32mp15_dhcom_basic_defconfig
index 0ff015cae49..7f7aecf2510 100644
--- a/configs/stm32mp15_dhcom_basic_defconfig
+++ b/configs/stm32mp15_dhcom_basic_defconfig
@@ -80,6 +80,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_SPL_ENV_IS_NOWHERE=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_IP_DEFRAG=y
+CONFIG_TFTP_TSIZE=y
 CONFIG_STM32_ADC=y
 CONFIG_SPL_BLOCK_CACHE=y
 CONFIG_DFU_MMC=y
diff --git a/configs/stm32mp15_dhcor_basic_defconfig 
b/configs/stm32mp15_dhcor_basic_defconfig
index 83614b9fc8e..35e43a9a2fc 100644
--- a/configs/stm32mp15_dhcor_basic_defconfig
+++ b/configs/stm32mp15_dhcor_basic_defconfig
@@ -77,6 +77,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_SPL_ENV_IS_NOWHERE=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_IP_DEFRAG=y
+CONFIG_TFTP_TSIZE=y
 CONFIG_STM32_ADC=y
 CONFIG_SPL_BLOCK_CACHE=y
 CONFIG_DFU_MMC=y
-- 
2.35.1



  1   2   3   4   5   6   7   8   9   10   >