March 2023 - U-Boot

[PATCH] spi: renesas: Make driver available on R-Car Gen4
by Marek Vasut 01 Mar '23

01 Mar '23

Use CONFIG_RCAR_64 to make the driver available on both R-Car Gen3 and R-Car Gen4. Signed-off-by: Marek Vasut <marek.vasut+renesas(a)mailbox.org> --- Cc: Geert Uytterhoeven <geert+renesas(a)glider.be> Cc: Jagan Teki <jagan(a)amarulasolutions.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: Tom Rini <trini(a)konsulko.com> --- drivers/spi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index cdd2304aeb1..b1d4b6c5f89 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -381,7 +381,7 @@ config SPI_QUP config RENESAS_RPC_SPI bool "Renesas RPC SPI driver" - depends on RCAR_GEN3 || RZA1 + depends on RCAR_64 || RZA1 imply SPI_FLASH_BAR help Enable the Renesas RPC SPI driver, used to access SPI NOR flash -- 2.39.2

2 1

[PATCH 0/2] spi: spi-mem: odd byte condition changes in dtr_supports_op
by Nikhil M Jain 01 Mar '23

01 Mar '23

From: Dhruva Gole <d-gole(a)ti.com> Currently if one tries to read an odd filesize from a flash in OSPI DTR Mode then the transaction just straightaway returns failure without even attempting a read. Base on comments from a series a while back: https://lore.kernel.org/u-boot/20221025062036.383460-1-d-gole@ti.com/ where Pratyush highlights the risk of on writes an extra byte goes to the flash. Hence this series makes sure that we perform this ODD Byte check only if the transactions are "non-read" related ie. only write related. An alternative solution was suggested here: https://patchwork.ozlabs.org/project/linux-mtd/patch/20210531181757.19458-6… However the code is in linux kernel where it's a full fledge OS running with presumambly enough DDR RAM and we dont really have memory contraints as tight as in a bootloader. The part where the above solution does ... tmp_buf = kmalloc(PAGE_SIZE, GFP_KERNEL); ... This is something we do not have the luxury of doing at bootloader stage where the RAM is very limited. In TI K3 AM625 SOC's case we have the same code running on R5 SPL Stage where memory is extremely limited and we can't really afford to allocate some at runtime as and when we want. These patches have been tested on AM625 SK EVM platform and check for odd and even byte reads, updates and also full bootup from OSPI Flash till U-Boot prompt: ... U-Boot SPL 2023.04-rc2-00040-gbe9fd01af6 (Mar 01 2023 - 11:30:52 +0530) SYSFW ABI: 3.1 (firmware rev 0x0008 '8.5.3--v08.05.03 (Chill Capybar') Trying to boot from SPI Starting ATF on ARM64 core... NOTICE: BL31: v2.7(release):v2.7.0-359-g1309c6c805-dirty NOTICE: BL31: Built : 11:48:12, Dec 14 2022 I/TC: I/TC: OP-TEE version: 3.19.0-15-gd6c5d0037 (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #1 Wed Dec 14 11:52:03 UTC 2022 aarch64 I/TC: WARNING: This OP-TEE configuration might be insecure! I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html I/TC: Primary CPU initializing I/TC: SYSFW ABI: 3.1 (firmware rev 0x0008 '8.5.3--v08.05.03 (Chill Capybar') I/TC: HUK Initialized I/TC: Activated SA2UL device I/TC: Fixing SA2UL firewall owner for GP device I/TC: Enabled firewalls for SA2UL TRNG device I/TC: SA2UL TRNG initialized I/TC: SA2UL Drivers initialized I/TC: Primary CPU switching to normal world boot U-Boot SPL 2023.04-rc2-00040-gbe9fd01af6 (Mar 01 2023 - 11:31:30 +0530) SYSFW ABI: 3.1 (firmware rev 0x0008 '8.5.3--v08.05.03 (Chill Capybar') Trying to boot from SPI U-Boot 2023.04-rc2-00040-gbe9fd01af6 (Mar 01 2023 - 11:31:30 +0530) SoC: AM62X SR1.0 GP Model: Texas Instruments AM625 SK DRAM: 2 GiB Core: 50 devices, 20 uclasses, devicetree: separate MMC: mmc@fa10000: 0, mmc@fa00000: 1, mmc@fa20000: 2 Loading Environment from nowhere... OK In: serial@2800000 Out: serial@2800000 Err: serial@2800000 Net: eth0: ethernet@8000000port@1 Hit any key to stop autoboot: 0 => ... Odd length reads: ... => sf probe SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB => fatload mmc 1 $loadaddr ti.gz 12285 bytes read in 8 ms (1.5 MiB/s) => sf update $loadaddr 0x700000 $filesize device 0 offset 0x700000, size 0x2ffd 12285 bytes written, 0 bytes skipped in 1.478s, speed 8494 B/s sf read 0x90000000 0x700000 $filesize device 0 offset 0x700000, size 0x2ffd SF: 12285 bytes @ 0x700000 Read: OK => cmp.b $loadaddr 0x90000000 $filesize # all bytes were same # ... Cc: Vignesh Raghavendra <vigneshr(a)ti.com> Cc: Pratyush Yadav <ptyadav(a)amazon.de> Cc: Vaishnav Achath <vaishnav.a(a)ti.com> Cc: Nikhil M Jain <n-jain1(a)ti.com> Dhruva Gole (2): spi: spi-mem: s/dummy/data buswidth check in dtr_supports_op() spi: spi-mem: perform odd len check only while writing data drivers/spi/spi-mem.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) -- 2.39.2

1 2

[PATCH] i2c: rcar_i2c: Add R-Car Gen4 support
by Marek Vasut 01 Mar '23

01 Mar '23

From: Hai Pham <hai.pham.ud(a)renesas.com> Add support for R-Car Gen4 SoCs into the driver. While I2C on R-Car Gen4 does support some extra features (Slave Clock Stretch Select), for now it is treated the same as I2C on R-Car Gen3, which let us share the same driver. Reviewed-by: Marek Vasut <marek.vasut+renesas(a)mailbox.org> Signed-off-by: Hai Pham <hai.pham.ud(a)renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas(a)mailbox.org> # Use RCAR_64 Kconfig --- Cc: Heiko Schocher <hs(a)denx.de> --- drivers/i2c/Kconfig | 2 +- drivers/i2c/rcar_i2c.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 1d998d14732..c32659b55a9 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -486,7 +486,7 @@ config SYS_I2C_OMAP24XX config SYS_I2C_RCAR_I2C bool "Renesas RCar I2C driver" - depends on (RCAR_GEN2 || RCAR_GEN3) && DM_I2C + depends on (RCAR_GEN2 || RCAR_64) && DM_I2C help Support for Renesas RCar I2C controller. diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c index d9ece5e3a80..ff9a2d80dda 100644 --- a/drivers/i2c/rcar_i2c.c +++ b/drivers/i2c/rcar_i2c.c @@ -369,6 +369,7 @@ static const struct dm_i2c_ops rcar_i2c_ops = { static const struct udevice_id rcar_i2c_ids[] = { { .compatible = "renesas,rcar-gen2-i2c", .data = RCAR_I2C_TYPE_GEN2 }, { .compatible = "renesas,rcar-gen3-i2c", .data = RCAR_I2C_TYPE_GEN3 }, + { .compatible = "renesas,rcar-gen4-i2c", .data = RCAR_I2C_TYPE_GEN3 }, { } }; -- 2.39.2

2 1

[PATCH 1/2] i2c: rcar_iic: Sort Kconfig depends list ascending
by Marek Vasut 01 Mar '23

01 Mar '23

Sort the list of "depends" symbols in ascending order. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas(a)mailbox.org> --- Cc: Heiko Schocher <hs(a)denx.de> --- drivers/i2c/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 3279fef1eb0..aa51f0c869e 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -492,7 +492,7 @@ config SYS_I2C_RCAR_I2C config SYS_I2C_RCAR_IIC bool "Renesas RCar Gen3 IIC driver" - depends on (RCAR_GEN3 || RCAR_GEN2) && DM_I2C + depends on (RCAR_GEN2 || RCAR_GEN3) && DM_I2C help Support for Renesas RCar Gen3 IIC controller. -- 2.39.2

2 3

[PATCH] usb: dwc3: core: improve reset sequence
by Venkatesh Yadav Abbarapu 01 Mar '23

01 Mar '23

[ Felipe: Ported from Linux kernel commit f59dcab17629 ("usb: dwc3: core: improve reset sequence") ] According to Synopsys Databook, we shouldn't be relying on GCTL.CORESOFTRESET bit as that's only for debugging purposes. Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode. Host side block will be reset by XHCI driver if necessary. Note that this reduces amount of time spent on dwc3_probe() by a long margin. We're still gonna wait for reset to finish for a long time (default to 1ms max), but tests show that the reset polling loop executed at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000 times in a row). Without proper core reset, observing random issues like when the USB(DWC3) is in device mode, the host device is not able to detect the USB device. Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu(a)amd.com> --- drivers/usb/dwc3/core.c | 49 +++++++++++++++-------------------------- 1 file changed, 18 insertions(+), 31 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 49f6a1900b..6cd0ad4746 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -60,42 +60,29 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode) static int dwc3_core_soft_reset(struct dwc3 *dwc) { u32 reg; + int retries = 1000; - /* Before Resetting PHY, put Core in Reset */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg |= DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); - - /* Assert USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Assert USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); - - mdelay(100); - - /* Clear USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); + /* + * We're resetting only the device side because, if we're in host mode, + * XHCI driver will reset the host block. If dwc3 was configured for + * host-only mode, then we can return early. + */ + if (dwc->dr_mode == USB_DR_MODE_HOST) + return 0; - /* Clear USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + reg |= DWC3_DCTL_CSFTRST; + dwc3_writel(dwc->regs, DWC3_DCTL, reg); - mdelay(100); + do { + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + if (!(reg & DWC3_DCTL_CSFTRST)) + return 0; - /* After PHYs are stable we can take Core out of reset state */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg &= ~DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); + udelay(1); + } while (--retries); - return 0; + return -ETIMEDOUT; } /* -- 2.17.1

1 0

[PATCH v3 0/3] imx93: add ADC support
by Luca Ellero 01 Mar '23

01 Mar '23

Add ADC support for NXP iMX93 Changes for v2: - add "static" to functions - enable ADC in iMX93 EVK Changes for v3: - split in 3 commits - keep dts file in sync with Linux devicetree - add comments to commits Luca Ellero (3): dm: adc: add iMX93 ADC support imx93_evk: add adc node to dts file imx93_evk: defconfig: add adc support arch/arm/dts/imx93-11x11-evk.dts | 4 + configs/imx93_11x11_evk_defconfig | 1 + drivers/adc/Kconfig | 8 + drivers/adc/Makefile | 1 + drivers/adc/imx93-adc.c | 284 ++++++++++++++++++++++++++++++ 5 files changed, 298 insertions(+) create mode 100644 drivers/adc/imx93-adc.c -- 2.25.1

2 4