RE: [PATCH v12 01/18] misc: add driver for the SiFive otp controller
Hi Simon, >-Original Message- >From: Simon Glass >Sent: 26 May 2020 03:15 >To: Pragnesh Patel >Cc: U-Boot Mailing List ; Atish Patra >; Palmer Dabbelt ; Bin >Meng ; Paul Walmsley ; >Jagan Teki ; Anup Patel >; Sagar Kadam ; rick >; Tero Kristo ; Heiko Stuebner >; Finley Xiao chips.com>; Adam Ford ; Peng Fan >; Eugen Hristev >Subject: Re: [PATCH v12 01/18] misc: add driver for the SiFive otp controller > >[External Email] Do not click links or attachments unless you recognize the >sender and know the content is safe > >Hi Pragnesh, > >On Mon, 25 May 2020 at 01:34, Pragnesh Patel >wrote: >> >> Added a misc driver to handle OTP memory in SiFive SoCs. >> >> Signed-off-by: Pragnesh Patel >> Reviewed-by: Bin Meng >> Tested-by: Bin Meng >> Reviewed-by: Jagan Teki >> Tested-by: Jagan Teki >> --- >> drivers/misc/Kconfig | 7 + >> drivers/misc/Makefile | 1 + >> drivers/misc/sifive-otp.c | 275 >++ >> 3 files changed, 283 insertions(+) >> create mode 100644 drivers/misc/sifive-otp.c > >Did you miss the change log here? For this series I am just updating the cover letter for change log. My apology for not updating the change log in every patch but I will definitely take care this in future. For your reference, Changes in v12 for this patch: - Added necessary include files which are not part of common header now drivers/misc/sifive-otp.c +#include +#include > >Regards, >Simon
Re: [PATCH v6 00/16] Add Rockchip RK3399 USB3.0 Host support
On Tue, May 26, 2020 at 9:02 AM Frank Wang wrote: > > This series add quirks for DWC3 and add Rockchip RK3399 USB3.0 host support. > > The function has been tested pass on rk3399-evb and roc-rk3399-pc board. > > For V6 update: > - Use [PATCH v6 04/16] instead of [PATCH v5 05/16] to fix that the current >Generic PHY subsystem is unable to find PHY if the PHY node is not part of >the root structure. > - Add 'Reviewed-by' tag for all patches except [PATCH v6 04/16]. > > For V5 update: > - Fix dwc3-generic driver followed Marek's comments for [PATCH v4 12/16]. > - Add 'Reviewed-by' and 'Tested-by' tag for [PATCH v4 07/16] and [PATCH v4 > 08/16]. > > For V4 update: > - Collect Jagan's all fixed patches [1]. > - Amend specific u-boot changes from dts to dtsi for [PATCH v3 6/7]. > > For V3 update: > - Fix compile error for [PATCH v2 1/9]. > - Use Jagan's Type-C driver instead of [PATCH v2 5/9]. > - Cleanup dts changes for [PATCH v2 7/9]. > - Cleanup config changes for [PATCH v2 8/9] and [PATCH v2 9/9]. > > For V2 update: > - Amend type-c driver followed Jagan's comments for [PATCH 5/8]. > - Fix dts commit for [PATCH 7/8]. > - Split RK3399 default config for [PATCH 8/8]. > - Add 'Reviewed-by' tag for [PATCH 1/8], [PATCH 2/8] and [PATCH 3/8]. > > [1] > https://patchwork.ozlabs.org/project/uboot/cover/20200506075025.1677-1-ja...@amarulasolutions.com > > BR, > Frank > > Frank Wang (8): > arm: mach-rockchip: bind sub-nodes for rk3399_syscon > usb: dwc3: add dis_enblslpm_quirk > usb: dwc3: add dis_u2_freeclk_exists_quirk > usb: dwc3: amend UTMI/UTMIW phy interface setup > usb: dwc3: add make compatible for rockchip platform > driver: usb: drop legacy rockchip xhci driver > ARM: dts: rk3399-evb: usb3.0 host support > configs: evb-rk3399: update support usb3.0 host I have a new sandisk Type C and A storage disk. Here are the tests in roc-rk3399-pc. => usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Hub (480 Mb/s, 100mA) USB 2.0 Hub [MTT] 1 Hub (5 Gb/s, 0mA) U-Boot XHCI Host Controller => usb reset resetting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3c: USB EHCI 1.00 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 2 USB Device(s) found scanning bus dwc3 for devices... cannot reset port 1!? 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Hub (480 Mb/s, 100mA) USB 2.0 Hub [MTT] 1 Hub (5 Gb/s, 0mA) | U-Boot XHCI Host Controller | +-2 Mass Storage (5 Gb/s, 224mA) SanDisk Dual Drive 040130e3ee554b7078843f4eb331646 => usb reset resetting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3c: USB EHCI 1.00 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 2 USB Device(s) found scanning bus usb@fe3c for devices... 2 USB Device(s) found scanning bus dwc3 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 224mA) SanDisk Dual Drive 040130e3ee554b7078843f4eb331646 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Hub (480 Mb/s, 100mA) USB 2.0 Hub [MTT] 1 Hub (5 Gb/s, 0mA) U-Boot XHCI Host Controller => usb reset resetting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3c: USB EHCI 1.00 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... EHCI timed out on TD - token=0x80008d80 USB device not accepting new address (error=22) 2 USB Device(s) found scanning bus dwc3 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found => resetting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3c: USB EHCI 1.00 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 3 USB Device(s) found scanning bus dwc3 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Hub (480 Mb/s, 100mA) | USB 2.0 Hub
Re: [PATCH v5 00/16] Add Rockchip RK3399 USB3.0 Host support
On Mon, May 25, 2020 at 3:06 PM Marcin Juszkiewicz wrote: > > W dniu 25.05.2020 o 11:32, Jagan Teki pisze: > > On Mon, May 25, 2020 at 2:57 PM Marcin Juszkiewicz > > >> No - "scanning bus dwc3 for devices... cannot reset port 1!?" every time > >> and devices plugged into usb-c are ignored. > > > > Can you check 'usb reset' after 'usb start' > > Same situation after each 'usb reset' command. Can you check v6, I have marked you CC. I've a Sandisk Type C disk which got worked with rock-rk3399-pc. Jagan.
Re: [PATCH v6 04/16] arm: mach-rockchip: bind sub-nodes for rk3399_syscon
On Tue, May 26, 2020 at 9:02 AM Frank Wang wrote:
>
> There are some sub-nodes under the grf DT, so add bind callback
> function in rk3399 syscon driver to scan them recursively.
>
> Signed-off-by: Frank Wang
> ---
> arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
> b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
> index 259ca44d68..f27b0ced82 100644
> --- a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
> @@ -20,6 +20,9 @@ static const struct udevice_id rk3399_syscon_ids[] = {
> U_BOOT_DRIVER(syscon_rk3399) = {
> .name = "rk3399_syscon",
> .id = UCLASS_SYSCON,
> +#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> + .bind = dm_scan_fdt_dev,
> +#endif
Reviewed-by: Jagan Teki
Tested-by: Jagan Teki # roc-rk3399-pc
Re: [PATCH v6 12/16] usb: dwc3: add make compatible for rockchip platform
On Tue, May 26, 2020 at 9:04 AM Frank Wang wrote:
>
> RK3399 Type-C PHY is required that must hold whole USB3.0 OTG controller
> in resetting to hold pipe power state in P2 before initializing the PHY.
> This commit fixed it and added device compatible for rockchip platform.
>
> Signed-off-by: Frank Wang
> Signed-off-by: Jagan Teki
> Reviewed-by: Kever Yang
> ---
> drivers/usb/dwc3/dwc3-generic.c | 33 +++--
> 1 file changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
> index eabd53a36d..421e0be135 100644
> --- a/drivers/usb/dwc3/dwc3-generic.c
> +++ b/drivers/usb/dwc3/dwc3-generic.c
> @@ -24,6 +24,12 @@
> #include
> #include
>
> +struct dwc3_glue_data {
> + struct clk_bulk clks;
> + struct reset_ctl_bulk resets;
> + fdt_addr_t regs;
> +};
> +
> struct dwc3_generic_plat {
> fdt_addr_t base;
> u32 maximum_speed;
> @@ -47,6 +53,7 @@ static int dwc3_generic_probe(struct udevice *dev,
> int rc;
> struct dwc3_generic_plat *plat = dev_get_platdata(dev);
> struct dwc3 *dwc3 = >dwc3;
> + struct dwc3_glue_data *glue = dev_get_platdata(dev->parent);
>
> dwc3->dev = dev;
> dwc3->maximum_speed = plat->maximum_speed;
> @@ -55,10 +62,22 @@ static int dwc3_generic_probe(struct udevice *dev,
> dwc3_of_parse(dwc3);
> #endif
>
> + /*
> +* It must hold whole USB3.0 OTG controller in resetting to hold pipe
> +* power state in P2 before initializing TypeC PHY on RK3399 platform.
> +*/
> + if (device_is_compatible(dev->parent, "rockchip,rk3399-dwc3")) {
> + reset_assert_bulk(>resets);
> + udelay(1);
Need to include to fix build warnings, maybe Kever
will do while applying?
Jagan.
Re: [PATCH v5 05/16] arm64: dts: rk3399: Move u2phy into root port
Hi Jagan, Kever,
On 2020/5/15 10:40, Kever Yang wrote:
Hi Jagan, Frank,
On 2020/5/13 下午3:15, Frank Wang wrote:
From: Jagan Teki
Yes, This is changing the actual device tree u2phy
structure but the problem with the current Generic
PHY subsystem is unable to find PHY if the PHY node
is not part of the root structure.
I don't understand for this, it should be able to bind the device when
dm scan fdt.
Rockchip code always can use this node directly without modify, could
you check again?
Sub-nodes under grf were not scanned recursively since dm_scan_fdt_dev
is not assigned to rk3399_syscon driver's bind in Upstream codes .
I have fixed it and updated all changed for patch v6, please refer to
below links.
https://patchwork.ozlabs.org/project/uboot/cover/20200526033220.20047-1-frank.w...@rock-chips.com/
BR,
Frank
Thanks,
- Kever
This will be reverted,
- Once we support the PHY subsystem to get the PHY
even though it is not part of the root node or
- any other relevant solution that get the phy
directly without traversing all nodes.
Signed-off-by: Jagan Teki
---
arch/arm/dts/rk3399.dtsi | 108 +++
1 file changed, 54 insertions(+), 54 deletions(-)
diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 74f2c3d490..6c77f25f23 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -1387,60 +1387,6 @@
status = "disabled";
};
- u2phy0: usb2-phy@e450 {
- compatible = "rockchip,rk3399-usb2phy";
- reg = <0xe450 0x10>;
- clocks = < SCLK_USB2PHY0_REF>;
- clock-names = "phyclk";
- #clock-cells = <0>;
- clock-output-names = "clk_usbphy0_480m";
- status = "disabled";
-
- u2phy0_host: host-port {
- #phy-cells = <0>;
- interrupts = ;
- interrupt-names = "linestate";
- status = "disabled";
- };
-
- u2phy0_otg: otg-port {
- #phy-cells = <0>;
- interrupts = ,
- ,
- ;
- interrupt-names = "otg-bvalid", "otg-id",
- "linestate";
- status = "disabled";
- };
- };
-
- u2phy1: usb2-phy@e460 {
- compatible = "rockchip,rk3399-usb2phy";
- reg = <0xe460 0x10>;
- clocks = < SCLK_USB2PHY1_REF>;
- clock-names = "phyclk";
- #clock-cells = <0>;
- clock-output-names = "clk_usbphy1_480m";
- status = "disabled";
-
- u2phy1_host: host-port {
- #phy-cells = <0>;
- interrupts = ;
- interrupt-names = "linestate";
- status = "disabled";
- };
-
- u2phy1_otg: otg-port {
- #phy-cells = <0>;
- interrupts = ,
- ,
- ;
- interrupt-names = "otg-bvalid", "otg-id",
- "linestate";
- status = "disabled";
- };
- };
-
emmc_phy: phy@f780 {
compatible = "rockchip,rk3399-emmc-phy";
reg = <0xf780 0x24>;
@@ -1462,6 +1408,60 @@
};
};
+ u2phy0: usb2-phy@e450 {
+ compatible = "rockchip,rk3399-usb2phy";
+ reg = <0x0 0xe450 0x0 0x10>;
+ clocks = < SCLK_USB2PHY0_REF>;
+ clock-names = "phyclk";
+ #clock-cells = <0>;
+ clock-output-names = "clk_usbphy0_480m";
+ status = "disabled";
+
+ u2phy0_host: host-port {
+ #phy-cells = <0>;
+ interrupts = ;
+ interrupt-names = "linestate";
+ status = "disabled";
+ };
+
+ u2phy0_otg: otg-port {
+ #phy-cells = <0>;
+ interrupts = ,
+ ,
+ ;
+ interrupt-names = "otg-bvalid", "otg-id",
+ "linestate";
+ status = "disabled";
+ };
+ };
+
+ u2phy1: usb2-phy@e460 {
+ compatible = "rockchip,rk3399-usb2phy";
+ reg = <0x0 0xe460 0x0 0x10>;
+ clocks = < SCLK_USB2PHY1_REF>;
+ clock-names = "phyclk";
+ #clock-cells = <0>;
+ clock-output-names = "clk_usbphy1_480m";
+ status = "disabled";
+
+ u2phy1_host: host-port {
+ #phy-cells = <0>;
+ interrupts = ;
+ interrupt-names = "linestate";
+ status = "disabled";
+ };
+
+ u2phy1_otg: otg-port {
+ #phy-cells = <0>;
+ interrupts = ,
+ ,
+ ;
+ interrupt-names = "otg-bvalid", "otg-id",
+ "linestate";
+ status = "disabled";
+ };
+ };
+
tcphy0: phy@ff7c {
compatible = "rockchip,rk3399-typec-phy";
reg =
[PATCH v6 16/16] roc-rk3399-pc: Enable USB3.0 Host
From: Jagan Teki Enable USB3.0 Host support for ROC-RK3399-PC boards. Tested USB3.0 SSD on Type C1 port on board. => usb start starting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3c: USB EHCI 1.00 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 2 USB Device(s) found scanning bus dwc3 for devices... 6 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Hub (480 Mb/s, 100mA) USB 2.0 Hub [MTT] 1 Hub (5 Gb/s, 0mA) | U-Boot XHCI Host Controller | +-2 Hub (480 Mb/s, 0mA) | | VIA Labs, Inc. USB2.0 Hub | | | +-4 Hub (480 Mb/s, 100mA) | | USB 2.0 Hub | | | +-5 (480 Mb/s, 100mA) |VIA Technologies Inc. USB 2.0 BILLBOARD 0001 | +-3 Hub (5 Gb/s, 0mA) | VIA Labs, Inc. USB3.0 Hub | +-6 Mass Storage (5 Gb/s, 224mA) JMicron External Disk 3.0 DB12345678A2 => usb reset resetting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3c: USB EHCI 1.00 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 2 USB Device(s) found scanning bus dwc3 for devices... 6 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Signed-off-by: Jagan Teki Reviewed-by: Kever Yang --- configs/roc-pc-mezzanine-rk3399_defconfig | 5 + configs/roc-pc-rk3399_defconfig | 6 ++ 2 files changed, 11 insertions(+) diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig b/configs/roc-pc-mezzanine-rk3399_defconfig index 0b853805f3..1f10856caa 100644 --- a/configs/roc-pc-mezzanine-rk3399_defconfig +++ b/configs/roc-pc-mezzanine-rk3399_defconfig @@ -29,6 +29,7 @@ CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y @@ -39,6 +40,8 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_NVME=y CONFIG_PCI=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y +CONFIG_PHY_ROCKCHIP_TYPEC=y CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_PWM=y CONFIG_REGULATOR_RK8XX=y @@ -54,6 +57,8 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig index aff690f039..76e76c160e 100644 --- a/configs/roc-pc-rk3399_defconfig +++ b/configs/roc-pc-rk3399_defconfig @@ -28,6 +28,7 @@ CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y @@ -36,11 +37,14 @@ CONFIG_SPI_FLASH_WINBOND=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y +CONFIG_PHY_ROCKCHIP_TYPEC=y CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_PWM=y CONFIG_REGULATOR_RK8XX=y CONFIG_PWM_ROCKCHIP=y CONFIG_RAM_RK3399_LPDDR4=y +CONFIG_DM_RESET=y CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_ROCKCHIP_SPI=y @@ -50,6 +54,8 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_KEYBOARD=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y -- 2.17.1
[PATCH v6 12/16] usb: dwc3: add make compatible for rockchip platform
RK3399 Type-C PHY is required that must hold whole USB3.0 OTG controller
in resetting to hold pipe power state in P2 before initializing the PHY.
This commit fixed it and added device compatible for rockchip platform.
Signed-off-by: Frank Wang
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
---
drivers/usb/dwc3/dwc3-generic.c | 33 +++--
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index eabd53a36d..421e0be135 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -24,6 +24,12 @@
#include
#include
+struct dwc3_glue_data {
+ struct clk_bulk clks;
+ struct reset_ctl_bulk resets;
+ fdt_addr_t regs;
+};
+
struct dwc3_generic_plat {
fdt_addr_t base;
u32 maximum_speed;
@@ -47,6 +53,7 @@ static int dwc3_generic_probe(struct udevice *dev,
int rc;
struct dwc3_generic_plat *plat = dev_get_platdata(dev);
struct dwc3 *dwc3 = >dwc3;
+ struct dwc3_glue_data *glue = dev_get_platdata(dev->parent);
dwc3->dev = dev;
dwc3->maximum_speed = plat->maximum_speed;
@@ -55,10 +62,22 @@ static int dwc3_generic_probe(struct udevice *dev,
dwc3_of_parse(dwc3);
#endif
+ /*
+* It must hold whole USB3.0 OTG controller in resetting to hold pipe
+* power state in P2 before initializing TypeC PHY on RK3399 platform.
+*/
+ if (device_is_compatible(dev->parent, "rockchip,rk3399-dwc3")) {
+ reset_assert_bulk(>resets);
+ udelay(1);
+ }
+
rc = dwc3_setup_phy(dev, >phys);
if (rc)
return rc;
+ if (device_is_compatible(dev->parent, "rockchip,rk3399-dwc3"))
+ reset_deassert_bulk(>resets);
+
priv->base = map_physmem(plat->base, DWC3_OTG_REGS_END, MAP_NOCACHE);
dwc3->regs = priv->base + DWC3_GLOBALS_REGS_START;
@@ -186,12 +205,6 @@ U_BOOT_DRIVER(dwc3_generic_host) = {
};
#endif
-struct dwc3_glue_data {
- struct clk_bulk clks;
- struct reset_ctl_bulk resets;
- fdt_addr_t regs;
-};
-
struct dwc3_glue_ops {
void (*select_dr_mode)(struct udevice *dev, int index,
enum usb_dr_mode mode);
@@ -394,6 +407,12 @@ static int dwc3_glue_probe(struct udevice *dev)
if (ret)
return ret;
+ if (glue->resets.count == 0) {
+ ret = dwc3_glue_reset_init(child, glue);
+ if (ret)
+ return ret;
+ }
+
while (child) {
enum usb_dr_mode dr_mode;
@@ -424,6 +443,8 @@ static const struct udevice_id dwc3_glue_ids[] = {
{ .compatible = "ti,dwc3", .data = (ulong)_ops },
{ .compatible = "ti,am437x-dwc3", .data = (ulong)_ops },
{ .compatible = "ti,am654-dwc3" },
+ { .compatible = "rockchip,rk3328-dwc3" },
+ { .compatible = "rockchip,rk3399-dwc3" },
{ }
};
--
2.17.1
[PATCH v6 13/16] driver: usb: drop legacy rockchip xhci driver
We have changed to use dwc3 generic driver for usb3.0 host, so the
legacy Rockchip's xHCI driver is not needed, and drop it.
Signed-off-by: Frank Wang
Reviewed-by: Jagan Teki
Reviewed-by: Kever Yang
---
drivers/usb/host/Kconfig | 9 --
drivers/usb/host/Makefile| 1 -
drivers/usb/host/xhci-rockchip.c | 196 ---
3 files changed, 206 deletions(-)
delete mode 100644 drivers/usb/host/xhci-rockchip.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 2f381dc958..088931a6b9 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -53,15 +53,6 @@ config USB_XHCI_PCI
help
Enables support for the PCI-based xHCI controller.
-config USB_XHCI_ROCKCHIP
- bool "Support for Rockchip on-chip xHCI USB controller"
- depends on ARCH_ROCKCHIP
- depends on DM_REGULATOR
- depends on DM_USB
- default y
- help
- Enables support for the on-chip xHCI controller on Rockchip SoCs.
-
config USB_XHCI_RCAR
bool "Renesas RCar USB 3.0 support"
default y
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index e8e3b17e42..29d4f87e38 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -48,7 +48,6 @@ obj-$(CONFIG_USB_XHCI_BRCM) += xhci-brcm.o
obj-$(CONFIG_USB_XHCI_HCD) += xhci.o xhci-mem.o xhci-ring.o
obj-$(CONFIG_USB_XHCI_DWC3) += xhci-dwc3.o
obj-$(CONFIG_USB_XHCI_DWC3_OF_SIMPLE) += dwc3-of-simple.o
-obj-$(CONFIG_USB_XHCI_ROCKCHIP) += xhci-rockchip.o
obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o
obj-$(CONFIG_USB_XHCI_FSL) += xhci-fsl.o
obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
diff --git a/drivers/usb/host/xhci-rockchip.c b/drivers/usb/host/xhci-rockchip.c
deleted file mode 100644
index b67722fe45..00
--- a/drivers/usb/host/xhci-rockchip.c
+++ /dev/null
@@ -1,196 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (c) 2016 Rockchip, Inc.
- * Authors: Daniel Meng
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-struct rockchip_xhci_platdata {
- fdt_addr_t hcd_base;
- struct udevice *vbus_supply;
-};
-
-/*
- * Contains pointers to register base addresses
- * for the usb controller.
- */
-struct rockchip_xhci {
- struct usb_platdata usb_plat;
- struct xhci_ctrl ctrl;
- struct xhci_hccr *hcd;
- struct dwc3 *dwc3_reg;
-};
-
-static int xhci_usb_ofdata_to_platdata(struct udevice *dev)
-{
- struct rockchip_xhci_platdata *plat = dev_get_platdata(dev);
- int ret = 0;
-
- /*
-* Get the base address for XHCI controller from the device node
-*/
- plat->hcd_base = dev_read_addr(dev);
- if (plat->hcd_base == FDT_ADDR_T_NONE) {
- pr_err("Can't get the XHCI register base address\n");
- return -ENXIO;
- }
-
- /* Vbus regulator */
- ret = device_get_supply_regulator(dev, "vbus-supply",
- >vbus_supply);
- if (ret)
- debug("Can't get VBus regulator!\n");
-
- return 0;
-}
-
-/*
- * rockchip_dwc3_phy_setup() - Configure USB PHY Interface of DWC3 Core
- * @dwc: Pointer to our controller context structure
- * @dev: Pointer to ulcass device
- */
-static void rockchip_dwc3_phy_setup(struct dwc3 *dwc3_reg,
- struct udevice *dev)
-{
- u32 reg;
- u32 utmi_bits;
-
- /* Set dwc3 usb2 phy config */
- reg = readl(_reg->g_usb2phycfg[0]);
-
- if (dev_read_bool(dev, "snps,dis-enblslpm-quirk"))
- reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
-
- utmi_bits = dev_read_u32_default(dev, "snps,phyif-utmi-bits", -1);
- if (utmi_bits == 16) {
- reg |= DWC3_GUSB2PHYCFG_PHYIF;
- reg &= ~DWC3_GUSB2PHYCFG_USBTRDTIM_MASK;
- reg |= DWC3_GUSB2PHYCFG_USBTRDTIM_16BIT;
- } else if (utmi_bits == 8) {
- reg &= ~DWC3_GUSB2PHYCFG_PHYIF;
- reg &= ~DWC3_GUSB2PHYCFG_USBTRDTIM_MASK;
- reg |= DWC3_GUSB2PHYCFG_USBTRDTIM_8BIT;
- }
-
- if (dev_read_bool(dev, "snps,dis-u2-freeclk-exists-quirk"))
- reg &= ~DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS;
-
- if (dev_read_bool(dev, "snps,dis-u2-susphy-quirk"))
- reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
-
- writel(reg, _reg->g_usb2phycfg[0]);
-}
-
-static int rockchip_xhci_core_init(struct rockchip_xhci *rkxhci,
- struct udevice *dev)
-{
- int ret;
-
- ret = dwc3_core_init(rkxhci->dwc3_reg);
- if (ret) {
- pr_err("failed to initialize core\n");
- return ret;
- }
-
- rockchip_dwc3_phy_setup(rkxhci->dwc3_reg, dev);
-
- /* We are hard-coding DWC3 core to Host Mode */
- dwc3_set_mode(rkxhci->dwc3_reg, DWC3_GCTL_PRTCAP_HOST);
-
- return 0;
-}
-
-static int
[PATCH v6 15/16] configs: evb-rk3399: update support usb3.0 host
Update evb-rk3399 default config to support USB3.0 Host. Signed-off-by: Frank Wang Reviewed-by: Jagan Teki Reviewed-by: Kever Yang --- configs/evb-rk3399_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig index 7f14e18b1b..6cfb4e5dac 100644 --- a/configs/evb-rk3399_defconfig +++ b/configs/evb-rk3399_defconfig @@ -28,6 +28,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y CONFIG_MMC_DW=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ROCKCHIP=y @@ -35,10 +36,13 @@ CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y +CONFIG_PHY_ROCKCHIP_TYPEC=y CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_PWM=y CONFIG_REGULATOR_RK8XX=y CONFIG_PWM_ROCKCHIP=y +CONFIG_DM_RESET=y CONFIG_DM_RNG=y CONFIG_RNG_ROCKCHIP=y CONFIG_BAUDRATE=150 @@ -49,6 +53,8 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y -- 2.17.1
[PATCH v6 14/16] ARM: dts: rk3399-evb: usb3.0 host support
Configure 'tcphy1' and 'usbdrd_dwc3_1' nodes to support USB3.0 host
for Rockchip RK3399 Evaluation Board.
Signed-off-by: Frank Wang
Reviewed-by: Jagan Teki
Reviewed-by: Kever Yang
---
arch/arm/dts/rk3399-evb-u-boot.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi
b/arch/arm/dts/rk3399-evb-u-boot.dtsi
index e5659d7999..1bebe258f0 100644
--- a/arch/arm/dts/rk3399-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi
@@ -23,3 +23,16 @@
{
u-boot,dm-pre-reloc;
};
+
+ {
+ status = "okay";
+};
+
+_1 {
+ status = "okay";
+};
+
+_dwc3_1 {
+ dr_mode = "host";
+ status = "okay";
+};
--
2.17.1
[PATCH v6 10/16] usb: dwc3: Enable AutoRetry feature in the controller
From: Jagan Teki
By default when core sees any transaction error (CRC or overflow) it
replies with terminating retry ACK (Retry=1 and Nump == 0).
Enabling this Auto Retry feature in controller will make the core send
a non-terminanting ACK upon such transaction errors. That is, ACK TP
with Retry=1 and Nump != 0.
Doing so will give controller a chance to recover from transient error
conditions.
Reference from below Linux commit,
commit ("usb: dwc3: core: Enable AutoRetry feature
in the controller")
Cc: Marek Vasut
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
---
drivers/usb/dwc3/core.c | 9 +
drivers/usb/dwc3/core.h | 3 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index dc92f471c1..aab6c34c2d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -995,6 +995,15 @@ int dwc3_init(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
}
+ if (dwc->dr_mode == USB_DR_MODE_HOST ||
+ dwc->dr_mode == USB_DR_MODE_OTG) {
+ reg = dwc3_readl(dwc->regs, DWC3_GUCTL);
+
+ reg |= DWC3_GUCTL_HSTINAUTORETRY;
+
+ dwc3_writel(dwc->regs, DWC3_GUCTL, reg);
+ }
+
ret = dwc3_core_init_mode(dwc);
if (ret)
goto mode_fail;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b510d8a983..2adcaf0029 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -160,6 +160,9 @@
#define DWC3_GCTL_GBLHIBERNATIONEN (1 << 1)
#define DWC3_GCTL_DSBLCLKGTNG (1 << 0)
+/* Global User Control Register */
+#define DWC3_GUCTL_HSTINAUTORETRY BIT(14)
+
/* Global User Control 1 Register */
#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
#define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
--
2.17.1
[PATCH v6 11/16] usb: dwc3: amend UTMI/UTMIW phy interface setup
Let move 8/16-bit UTMI+ interface initialization into DWC3 core init
that is convenient for both DM_USB and u-boot traditional process.
Signed-off-by: Frank Wang
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
---
drivers/usb/common/common.c | 25 ++
drivers/usb/dwc3/core.c | 65 +++--
drivers/usb/dwc3/core.h | 5 +++
include/linux/usb/phy.h | 18 ++
4 files changed, 82 insertions(+), 31 deletions(-)
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index 0db281b970..d4ae18693c 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -64,3 +65,27 @@ enum usb_device_speed usb_get_maximum_speed(ofnode node)
return USB_SPEED_UNKNOWN;
}
+
+#if CONFIG_IS_ENABLED(DM_USB)
+static const char *const usbphy_modes[] = {
+ [USBPHY_INTERFACE_MODE_UNKNOWN] = "",
+ [USBPHY_INTERFACE_MODE_UTMI]= "utmi",
+ [USBPHY_INTERFACE_MODE_UTMIW] = "utmi_wide",
+};
+
+enum usb_phy_interface usb_get_phy_mode(ofnode node)
+{
+ const char *phy_type;
+ int i;
+
+ phy_type = ofnode_get_property(node, "phy_type", NULL);
+ if (!phy_type)
+ return USBPHY_INTERFACE_MODE_UNKNOWN;
+
+ for (i = 0; i < ARRAY_SIZE(usbphy_modes); i++)
+ if (!strcmp(phy_type, usbphy_modes[i]))
+ return i;
+
+ return USBPHY_INTERFACE_MODE_UNKNOWN;
+}
+#endif
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index aab6c34c2d..c8cb9e13b2 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -334,6 +334,34 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
}
+static void dwc3_hsphy_mode_setup(struct dwc3 *dwc)
+{
+ enum usb_phy_interface hsphy_mode = dwc->hsphy_mode;
+ u32 reg;
+
+ /* Set dwc3 usb2 phy config */
+ reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
+
+ switch (hsphy_mode) {
+ case USBPHY_INTERFACE_MODE_UTMI:
+ reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
+ DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
+ reg |= DWC3_GUSB2PHYCFG_PHYIF(UTMI_PHYIF_8_BIT) |
+ DWC3_GUSB2PHYCFG_USBTRDTIM(USBTRDTIM_UTMI_8_BIT);
+ break;
+ case USBPHY_INTERFACE_MODE_UTMIW:
+ reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
+ DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
+ reg |= DWC3_GUSB2PHYCFG_PHYIF(UTMI_PHYIF_16_BIT) |
+ DWC3_GUSB2PHYCFG_USBTRDTIM(USBTRDTIM_UTMI_16_BIT);
+ break;
+ default:
+ break;
+ }
+
+ dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+}
+
/**
* dwc3_phy_setup - Configure USB PHY Interface of DWC3 Core
* @dwc: Pointer to our controller context structure
@@ -382,6 +410,8 @@ static void dwc3_phy_setup(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
+ dwc3_hsphy_mode_setup(dwc);
+
mdelay(100);
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
@@ -626,35 +656,6 @@ static void dwc3_core_exit_mode(struct dwc3 *dwc)
dwc3_gadget_run(dwc);
}
-static void dwc3_uboot_hsphy_mode(struct dwc3_device *dwc3_dev,
- struct dwc3 *dwc)
-{
- enum usb_phy_interface hsphy_mode = dwc3_dev->hsphy_mode;
- u32 reg;
-
- /* Set dwc3 usb2 phy config */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-
- switch (hsphy_mode) {
- case USBPHY_INTERFACE_MODE_UTMI:
- reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
- DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
- reg |= DWC3_GUSB2PHYCFG_PHYIF(UTMI_PHYIF_8_BIT) |
- DWC3_GUSB2PHYCFG_USBTRDTIM(USBTRDTIM_UTMI_8_BIT);
- break;
- case USBPHY_INTERFACE_MODE_UTMIW:
- reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
- DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
- reg |= DWC3_GUSB2PHYCFG_PHYIF(UTMI_PHYIF_16_BIT) |
- DWC3_GUSB2PHYCFG_USBTRDTIM(USBTRDTIM_UTMI_16_BIT);
- break;
- default:
- break;
- }
-
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-}
-
#define DWC3_ALIGN_MASK(16 - 1)
/**
@@ -743,6 +744,8 @@ int dwc3_uboot_init(struct dwc3_device *dwc3_dev)
dwc->hird_threshold = hird_threshold
| (dwc->is_utmi_l1_suspend << 4);
+ dwc->hsphy_mode = dwc3_dev->hsphy_mode;
+
dwc->index = dwc3_dev->index;
dwc3_cache_hwparams(dwc);
@@ -767,8 +770,6 @@ int dwc3_uboot_init(struct dwc3_device *dwc3_dev)
goto err0;
}
- dwc3_uboot_hsphy_mode(dwc3_dev, dwc);
-
ret = dwc3_event_buffers_setup(dwc);
if (ret) {
[PATCH v6 07/16] usb: dwc3: add dis_enblslpm_quirk
Add a quirk to clear the GUSB2PHYCFG.ENBLSLPM bit, which controls
whether the PHY receives the suspend signal from the controller.
Refer to commit ec791d149bca("usb: dwc3: Add dis_enblslpm_quirk")
in Linux Kernel.
Signed-off-by: Frank Wang
Reviewed-by: Kever Yang
Reviewed-by: Jagan Teki
Tested-by: Jagan Teki
---
drivers/usb/dwc3/core.c | 6 ++
drivers/usb/dwc3/core.h | 2 ++
include/dwc3-uboot.h| 1 +
3 files changed, 9 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 0972e458eb..20be617fd4 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -398,6 +398,9 @@ static void dwc3_phy_setup(struct dwc3 *dwc)
if (dwc->dis_u2_susphy_quirk)
reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
+ if (dwc->dis_enblslpm_quirk)
+ reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
+
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
mdelay(100);
@@ -719,6 +722,7 @@ int dwc3_uboot_init(struct dwc3_device *dwc3_dev)
dwc->dis_u3_susphy_quirk = dwc3_dev->dis_u3_susphy_quirk;
dwc->dis_u2_susphy_quirk = dwc3_dev->dis_u2_susphy_quirk;
dwc->dis_del_phy_power_chg_quirk =
dwc3_dev->dis_del_phy_power_chg_quirk;
+ dwc->dis_enblslpm_quirk = dwc3_dev->dis_enblslpm_quirk;
dwc->tx_de_emphasis_quirk = dwc3_dev->tx_de_emphasis_quirk;
if (dwc3_dev->tx_de_emphasis)
@@ -926,6 +930,8 @@ void dwc3_of_parse(struct dwc3 *dwc)
"snps,dis_u2_susphy_quirk");
dwc->dis_del_phy_power_chg_quirk = dev_read_bool(dev,
"snps,dis-del-phy-power-chg-quirk");
+ dwc->dis_enblslpm_quirk = dev_read_bool(dev,
+ "snps,dis_enblslpm_quirk");
dwc->tx_de_emphasis_quirk = dev_read_bool(dev,
"snps,tx_de_emphasis_quirk");
tmp = dev_read_u8_array_ptr(dev, "snps,tx_de_emphasis", 1);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 7f45a9c459..e76e357f1e 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -162,6 +162,7 @@
/* Global USB2 PHY Configuration Register */
#define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 << 31)
#define DWC3_GUSB2PHYCFG_SUSPHY(1 << 6)
+#define DWC3_GUSB2PHYCFG_ENBLSLPM (1 << 8)
#define DWC3_GUSB2PHYCFG_PHYIF(n) ((n) << 3)
#define DWC3_GUSB2PHYCFG_PHYIF_MASKDWC3_GUSB2PHYCFG_PHYIF(1)
#define DWC3_GUSB2PHYCFG_USBTRDTIM(n) ((n) << 10)
@@ -822,6 +823,7 @@ struct dwc3 {
unsigneddis_u3_susphy_quirk:1;
unsigneddis_u2_susphy_quirk:1;
unsigneddis_del_phy_power_chg_quirk:1;
+ unsigneddis_enblslpm_quirk:1;
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
diff --git a/include/dwc3-uboot.h b/include/dwc3-uboot.h
index ecae34bf06..98d51e05e1 100644
--- a/include/dwc3-uboot.h
+++ b/include/dwc3-uboot.h
@@ -34,6 +34,7 @@ struct dwc3_device {
unsigned dis_u3_susphy_quirk;
unsigned dis_u2_susphy_quirk;
unsigned dis_del_phy_power_chg_quirk;
+ unsigned dis_enblslpm_quirk;
unsigned tx_de_emphasis_quirk;
unsigned tx_de_emphasis;
int index;
--
2.17.1
[PATCH v6 09/16] usb: dwc3: Add disable u2mac linestate check quirk
From: Jagan Teki
This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.
When use this quirk, the controller implements a fixed 40-bit
TxEndDelay after the packet is given on UTMI and ignores the
linestate during the transmit of a token (during token-to-token
and token-to-data IPGAP).
On some rockchip platforms (e.g. rk3399), it requires to disable
the u2mac linestate check to decrease the SSPLIT token to SETUP
token inter-packet delay from 566ns to 466ns, and fix the issue
that FS/LS devices not recognized if inserted through USB 3.0 HUB.
Reference from below Linux commit,
commit <65db7a0c9816> ("usb: dwc3: add disable u2mac linestate
check quirk")
Cc: Marek Vasut
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
---
drivers/usb/dwc3/core.c | 20
drivers/usb/dwc3/core.h | 7 +++
include/dwc3-uboot.h| 1 +
3 files changed, 28 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 3cb66515a2..dc92f471c1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -725,6 +725,7 @@ int dwc3_uboot_init(struct dwc3_device *dwc3_dev)
dwc->dis_u3_susphy_quirk = dwc3_dev->dis_u3_susphy_quirk;
dwc->dis_u2_susphy_quirk = dwc3_dev->dis_u2_susphy_quirk;
dwc->dis_del_phy_power_chg_quirk =
dwc3_dev->dis_del_phy_power_chg_quirk;
+ dwc->dis_tx_ipgap_linecheck_quirk =
dwc3_dev->dis_tx_ipgap_linecheck_quirk;
dwc->dis_enblslpm_quirk = dwc3_dev->dis_enblslpm_quirk;
dwc->dis_u2_freeclk_exists_quirk =
dwc3_dev->dis_u2_freeclk_exists_quirk;
@@ -934,6 +935,8 @@ void dwc3_of_parse(struct dwc3 *dwc)
"snps,dis_u2_susphy_quirk");
dwc->dis_del_phy_power_chg_quirk = dev_read_bool(dev,
"snps,dis-del-phy-power-chg-quirk");
+ dwc->dis_tx_ipgap_linecheck_quirk = dev_read_bool(dev,
+ "snps,dis-tx-ipgap-linecheck-quirk");
dwc->dis_enblslpm_quirk = dev_read_bool(dev,
"snps,dis_enblslpm_quirk");
dwc->dis_u2_freeclk_exists_quirk = dev_read_bool(dev,
@@ -954,6 +957,7 @@ void dwc3_of_parse(struct dwc3 *dwc)
int dwc3_init(struct dwc3 *dwc)
{
int ret;
+ u32 reg;
dwc3_cache_hwparams(dwc);
@@ -975,6 +979,22 @@ int dwc3_init(struct dwc3 *dwc)
goto event_fail;
}
+ if (dwc->revision >= DWC3_REVISION_250A) {
+ reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+
+ /*
+* Enable hardware control of sending remote wakeup
+* in HS when the device is in the L1 state.
+*/
+ if (dwc->revision >= DWC3_REVISION_290A)
+ reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
+
+ if (dwc->dis_tx_ipgap_linecheck_quirk)
+ reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
+
+ dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
+ }
+
ret = dwc3_core_init_mode(dwc);
if (ret)
goto mode_fail;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index c5e656885a..b510d8a983 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -73,6 +73,7 @@
#define DWC3_GCTL 0xc110
#define DWC3_GEVTEN0xc114
#define DWC3_GSTS 0xc118
+#define DWC3_GUCTL10xc11c
#define DWC3_GSNPSID 0xc120
#define DWC3_GGPIO 0xc124
#define DWC3_GUID 0xc128
@@ -159,6 +160,10 @@
#define DWC3_GCTL_GBLHIBERNATIONEN (1 << 1)
#define DWC3_GCTL_DSBLCLKGTNG (1 << 0)
+/* Global User Control 1 Register */
+#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
+#define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
+
/* Global USB2 PHY Configuration Register */
#define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 << 31)
#define DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS (1 << 30)
@@ -771,6 +776,7 @@ struct dwc3 {
#define DWC3_REVISION_260A 0x5533260a
#define DWC3_REVISION_270A 0x5533270a
#define DWC3_REVISION_280A 0x5533280a
+#define DWC3_REVISION_290A 0x5533290a
enum dwc3_ep0_next ep0_next_event;
enum dwc3_ep0_state ep0state;
@@ -824,6 +830,7 @@ struct dwc3 {
unsigneddis_u3_susphy_quirk:1;
unsigneddis_u2_susphy_quirk:1;
unsigneddis_del_phy_power_chg_quirk:1;
+ unsigneddis_tx_ipgap_linecheck_quirk:1;
unsigneddis_enblslpm_quirk:1;
unsigneddis_u2_freeclk_exists_quirk:1;
diff --git a/include/dwc3-uboot.h b/include/dwc3-uboot.h
index 193d225d31..e08530ec4e 100644
--- a/include/dwc3-uboot.h
+++ b/include/dwc3-uboot.h
@@ -34,6 +34,7 @@ struct dwc3_device {
[PATCH v6 05/16] phy: rockchip: Add Rockchip USB2PHY driver
From: Jagan Teki
Add Rockchip USB2PHY driver with initial support.
This will help to use it for EHCI controller in host
mode, and USB 3.0 controller in otg mode.
More functionality like charge, vbus detection will
add it in future changes.
Signed-off-by: Jagan Teki
Signed-off-by: Frank Wang
Reviewed-by: Kever Yang
---
drivers/Makefile | 1 +
drivers/phy/Kconfig | 1 +
drivers/phy/rockchip/Kconfig | 14 +
drivers/phy/rockchip/Makefile | 6 +
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 312 ++
5 files changed, 334 insertions(+)
create mode 100644 drivers/phy/rockchip/Kconfig
create mode 100644 drivers/phy/rockchip/Makefile
create mode 100644 drivers/phy/rockchip/phy-rockchip-inno-usb2.c
diff --git a/drivers/Makefile b/drivers/Makefile
index 4208750428..94e8c5da17 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -91,6 +91,7 @@ obj-y += dfu/
obj-$(CONFIG_PCH) += pch/
obj-y += phy/allwinner/
obj-y += phy/marvell/
+obj-y += phy/rockchip/
obj-y += rtc/
obj-y += scsi/
obj-y += sound/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 1e38c8741f..9c775107e9 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -225,4 +225,5 @@ config PHY_MTK_TPHY
multi-ports is first version, otherwise is second veriosn,
so you can easily distinguish them by banks layout.
+source "drivers/phy/rockchip/Kconfig"
endmenu
diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
new file mode 100644
index 00..d73ac695e1
--- /dev/null
+++ b/drivers/phy/rockchip/Kconfig
@@ -0,0 +1,14 @@
+#
+# Phy drivers for Rockchip platforms
+#
+
+menu "Rockchip PHY driver"
+
+config PHY_ROCKCHIP_INNO_USB2
+ bool "Rockchip INNO USB2PHY Driver"
+ depends on ARCH_ROCKCHIP
+ select PHY
+ help
+ Support for Rockchip USB2.0 PHY with Innosilicon IP block.
+
+endmenu
diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
new file mode 100644
index 00..9b0cbc6acf
--- /dev/null
+++ b/drivers/phy/rockchip/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2020 Amarula Solutions(India)
+#
+
+obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
new file mode 100644
index 00..c5ea6ca31f
--- /dev/null
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Rockchip USB2.0 PHY with Innosilicon IP block driver
+ *
+ * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (C) 2020 Amarula Solutions(India)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define usleep_range(a, b) udelay((b))
+#define BIT_WRITEABLE_SHIFT16
+
+enum rockchip_usb2phy_port_id {
+ USB2PHY_PORT_OTG,
+ USB2PHY_PORT_HOST,
+ USB2PHY_NUM_PORTS,
+};
+
+struct usb2phy_reg {
+ unsigned intoffset;
+ unsigned intbitend;
+ unsigned intbitstart;
+ unsigned intdisable;
+ unsigned intenable;
+};
+
+struct rockchip_usb2phy_port_cfg {
+ struct usb2phy_reg phy_sus;
+ struct usb2phy_reg bvalid_det_en;
+ struct usb2phy_reg bvalid_det_st;
+ struct usb2phy_reg bvalid_det_clr;
+ struct usb2phy_reg ls_det_en;
+ struct usb2phy_reg ls_det_st;
+ struct usb2phy_reg ls_det_clr;
+ struct usb2phy_reg utmi_avalid;
+ struct usb2phy_reg utmi_bvalid;
+ struct usb2phy_reg utmi_ls;
+ struct usb2phy_reg utmi_hstdet;
+};
+
+struct rockchip_usb2phy_cfg {
+ unsigned int reg;
+ const struct rockchip_usb2phy_port_cfg port_cfgs[USB2PHY_NUM_PORTS];
+};
+
+struct rockchip_usb2phy {
+ void *reg_base;
+ struct clk phyclk;
+ const struct rockchip_usb2phy_cfg *phy_cfg;
+};
+
+static inline int property_enable(void *reg_base,
+ const struct usb2phy_reg *reg, bool en)
+{
+ unsigned int val, mask, tmp;
+
+ tmp = en ? reg->enable : reg->disable;
+ mask = GENMASK(reg->bitend, reg->bitstart);
+ val = (tmp << reg->bitstart) | (mask << BIT_WRITEABLE_SHIFT);
+
+ return writel(val, reg_base + reg->offset);
+}
+
+static const
+struct rockchip_usb2phy_port_cfg *us2phy_get_port(struct phy *phy)
+{
+ struct udevice *parent = dev_get_parent(phy->dev);
+ struct rockchip_usb2phy *priv = dev_get_priv(parent);
+ const struct rockchip_usb2phy_cfg *phy_cfg = priv->phy_cfg;
+
+ return _cfg->port_cfgs[phy->id];
+}
+
+static int rockchip_usb2phy_power_on(struct phy *phy)
+{
+ struct udevice *parent = dev_get_parent(phy->dev);
+
[PATCH v6 06/16] phy: rockchip: Add Rockchip USB TypeC PHY driver
From: Jagan Teki Add USB TYPEC PHY driver for rockchip platform. Referenced from Linux TypeC PHY driver, currently supporting usb3-port and dp-port need to add it in the future. Signed-off-by: Frank Wang Signed-off-by: Jagan Teki Reviewed-by: Kever Yang --- drivers/phy/rockchip/Kconfig | 7 + drivers/phy/rockchip/Makefile | 1 + drivers/phy/rockchip/phy-rockchip-typec.c | 796 ++ 3 files changed, 804 insertions(+) create mode 100644 drivers/phy/rockchip/phy-rockchip-typec.c diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig index d73ac695e1..84cc7c876d 100644 --- a/drivers/phy/rockchip/Kconfig +++ b/drivers/phy/rockchip/Kconfig @@ -11,4 +11,11 @@ config PHY_ROCKCHIP_INNO_USB2 help Support for Rockchip USB2.0 PHY with Innosilicon IP block. +config PHY_ROCKCHIP_TYPEC + bool "Rockchip TYPEC PHY Driver" + depends on ARCH_ROCKCHIP + select PHY + help + Enable this to support the Rockchip USB TYPEC PHY. + endmenu diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile index 9b0cbc6acf..95b2f8a3c0 100644 --- a/drivers/phy/rockchip/Makefile +++ b/drivers/phy/rockchip/Makefile @@ -4,3 +4,4 @@ # obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o +obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c b/drivers/phy/rockchip/phy-rockchip-typec.c new file mode 100644 index 00..c9c8e1c542 --- /dev/null +++ b/drivers/phy/rockchip/phy-rockchip-typec.c @@ -0,0 +1,796 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * ROCKCHIP Type-C PHY driver. + * + * Copyright (C) 2020 Amarula Solutions(India) + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd + * Author: Chris Zhong + * Kever Yang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +#define usleep_range(a, b) udelay((b)) + +#define CMN_SSM_BANDGAP(0x21 << 2) +#define CMN_SSM_BIAS (0x22 << 2) +#define CMN_PLLSM0_PLLEN (0x29 << 2) +#define CMN_PLLSM0_PLLPRE (0x2a << 2) +#define CMN_PLLSM0_PLLVREF (0x2b << 2) +#define CMN_PLLSM0_PLLLOCK (0x2c << 2) +#define CMN_PLLSM1_PLLEN (0x31 << 2) +#define CMN_PLLSM1_PLLPRE (0x32 << 2) +#define CMN_PLLSM1_PLLVREF (0x33 << 2) +#define CMN_PLLSM1_PLLLOCK (0x34 << 2) +#define CMN_PLLSM1_USER_DEF_CTRL (0x37 << 2) +#define CMN_ICAL_OVRD (0xc1 << 2) +#define CMN_PLL0_VCOCAL_OVRD (0x83 << 2) +#define CMN_PLL0_VCOCAL_INIT (0x84 << 2) +#define CMN_PLL0_VCOCAL_ITER (0x85 << 2) +#define CMN_PLL0_LOCK_REFCNT_START (0x90 << 2) +#define CMN_PLL0_LOCK_PLLCNT_START (0x92 << 2) +#define CMN_PLL0_LOCK_PLLCNT_THR (0x93 << 2) +#define CMN_PLL0_INTDIV(0x94 << 2) +#define CMN_PLL0_FRACDIV (0x95 << 2) +#define CMN_PLL0_HIGH_THR (0x96 << 2) +#define CMN_PLL0_DSM_DIAG (0x97 << 2) +#define CMN_PLL0_SS_CTRL1 (0x98 << 2) +#define CMN_PLL0_SS_CTRL2 (0x99 << 2) +#define CMN_PLL1_VCOCAL_START (0xa1 << 2) +#define CMN_PLL1_VCOCAL_OVRD (0xa3 << 2) +#define CMN_PLL1_VCOCAL_INIT (0xa4 << 2) +#define CMN_PLL1_VCOCAL_ITER (0xa5 << 2) +#define CMN_PLL1_LOCK_REFCNT_START (0xb0 << 2) +#define CMN_PLL1_LOCK_PLLCNT_START (0xb2 << 2) +#define CMN_PLL1_LOCK_PLLCNT_THR (0xb3 << 2) +#define CMN_PLL1_INTDIV(0xb4 << 2) +#define CMN_PLL1_FRACDIV (0xb5 << 2) +#define CMN_PLL1_HIGH_THR (0xb6 << 2) +#define CMN_PLL1_DSM_DIAG (0xb7 << 2) +#define CMN_PLL1_SS_CTRL1 (0xb8 << 2) +#define CMN_PLL1_SS_CTRL2 (0xb9 << 2) +#define CMN_RXCAL_OVRD (0xd1 << 2) + +#define CMN_TXPUCAL_CTRL (0xe0 << 2) +#define CMN_TXPUCAL_OVRD (0xe1 << 2) +#define CMN_TXPDCAL_CTRL (0xf0 << 2) +#define CMN_TXPDCAL_OVRD (0xf1 << 2) + +/* For CMN_TXPUCAL_CTRL, CMN_TXPDCAL_CTRL */ +#define CMN_TXPXCAL_START BIT(15) +#define CMN_TXPXCAL_DONE BIT(14) +#define CMN_TXPXCAL_NO_RESPONSEBIT(13) +#define CMN_TXPXCAL_CURRENT_RESPONSE BIT(12) + +#define CMN_TXPU_ADJ_CTRL (0x108 << 2) +#define CMN_TXPD_ADJ_CTRL (0x10c << 2) + +/* + * For CMN_TXPUCAL_CTRL, CMN_TXPDCAL_CTRL, + * CMN_TXPU_ADJ_CTRL, CMN_TXPDCAL_CTRL + * + * NOTE: some of these registers are documented to be 2's complement + * signed numbers, but then documented to be always positive. Weird. + * In such a case, using CMN_CALIB_CODE_POS() avoids the unnecessary + * sign extension. + */ +#define CMN_CALIB_CODE_WIDTH 7
[PATCH v6 08/16] usb: dwc3: add dis_u2_freeclk_exists_quirk
Add a quirk to clear the GUSB2PHYCFG.U2_FREECLK_EXISTS bit,
which specifies whether the USB2.0 PHY provides a free-running
PHY clock, which is active when the clock control input is active.
Refer to commit 27f83eeb6b42("usb: dwc3: add dis_u2_freeclk_exists_quirk")
in Linux Rockchip Kernel.
Signed-off-by: Frank Wang
Reviewed-by: Kever Yang
Reviewed-by: Jagan Teki
Tested-by: Jagan Teki
---
drivers/usb/dwc3/core.c | 6 ++
drivers/usb/dwc3/core.h | 2 ++
include/dwc3-uboot.h| 1 +
3 files changed, 9 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 20be617fd4..3cb66515a2 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -401,6 +401,9 @@ static void dwc3_phy_setup(struct dwc3 *dwc)
if (dwc->dis_enblslpm_quirk)
reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
+ if (dwc->dis_u2_freeclk_exists_quirk)
+ reg &= ~DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS;
+
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
mdelay(100);
@@ -723,6 +726,7 @@ int dwc3_uboot_init(struct dwc3_device *dwc3_dev)
dwc->dis_u2_susphy_quirk = dwc3_dev->dis_u2_susphy_quirk;
dwc->dis_del_phy_power_chg_quirk =
dwc3_dev->dis_del_phy_power_chg_quirk;
dwc->dis_enblslpm_quirk = dwc3_dev->dis_enblslpm_quirk;
+ dwc->dis_u2_freeclk_exists_quirk =
dwc3_dev->dis_u2_freeclk_exists_quirk;
dwc->tx_de_emphasis_quirk = dwc3_dev->tx_de_emphasis_quirk;
if (dwc3_dev->tx_de_emphasis)
@@ -932,6 +936,8 @@ void dwc3_of_parse(struct dwc3 *dwc)
"snps,dis-del-phy-power-chg-quirk");
dwc->dis_enblslpm_quirk = dev_read_bool(dev,
"snps,dis_enblslpm_quirk");
+ dwc->dis_u2_freeclk_exists_quirk = dev_read_bool(dev,
+ "snps,dis-u2-freeclk-exists-quirk");
dwc->tx_de_emphasis_quirk = dev_read_bool(dev,
"snps,tx_de_emphasis_quirk");
tmp = dev_read_u8_array_ptr(dev, "snps,tx_de_emphasis", 1);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index e76e357f1e..c5e656885a 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -161,6 +161,7 @@
/* Global USB2 PHY Configuration Register */
#define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 << 31)
+#define DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS (1 << 30)
#define DWC3_GUSB2PHYCFG_SUSPHY(1 << 6)
#define DWC3_GUSB2PHYCFG_ENBLSLPM (1 << 8)
#define DWC3_GUSB2PHYCFG_PHYIF(n) ((n) << 3)
@@ -824,6 +825,7 @@ struct dwc3 {
unsigneddis_u2_susphy_quirk:1;
unsigneddis_del_phy_power_chg_quirk:1;
unsigneddis_enblslpm_quirk:1;
+ unsigneddis_u2_freeclk_exists_quirk:1;
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
diff --git a/include/dwc3-uboot.h b/include/dwc3-uboot.h
index 98d51e05e1..193d225d31 100644
--- a/include/dwc3-uboot.h
+++ b/include/dwc3-uboot.h
@@ -35,6 +35,7 @@ struct dwc3_device {
unsigned dis_u2_susphy_quirk;
unsigned dis_del_phy_power_chg_quirk;
unsigned dis_enblslpm_quirk;
+ unsigned dis_u2_freeclk_exists_quirk;
unsigned tx_de_emphasis_quirk;
unsigned tx_de_emphasis;
int index;
--
2.17.1
[PATCH v6 04/16] arm: mach-rockchip: bind sub-nodes for rk3399_syscon
There are some sub-nodes under the grf DT, so add bind callback
function in rk3399 syscon driver to scan them recursively.
Signed-off-by: Frank Wang
---
arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
index 259ca44d68..f27b0ced82 100644
--- a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
@@ -20,6 +20,9 @@ static const struct udevice_id rk3399_syscon_ids[] = {
U_BOOT_DRIVER(syscon_rk3399) = {
.name = "rk3399_syscon",
.id = UCLASS_SYSCON,
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
+ .bind = dm_scan_fdt_dev,
+#endif
.of_match = rk3399_syscon_ids,
};
--
2.17.1
[PATCH v6 03/16] clk: rk3399: Enable/Disable TCPHY clocks
From: Jagan Teki Enable/Disable TCPHY clock for rk3399 platform. Signed-off-by: Jagan Teki Reviewed-by: Kever Yang --- drivers/clk/rockchip/clk_rk3399.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/clk/rockchip/clk_rk3399.c b/drivers/clk/rockchip/clk_rk3399.c index 98fc6a3267..06232f1903 100644 --- a/drivers/clk/rockchip/clk_rk3399.c +++ b/drivers/clk/rockchip/clk_rk3399.c @@ -1144,6 +1144,18 @@ static int rk3399_clk_enable(struct clk *clk) case HCLK_HOST1_ARB: rk_clrreg(>cru->clksel_con[20], BIT(8)); break; + case SCLK_UPHY0_TCPDPHY_REF: + rk_clrreg(>cru->clkgate_con[13], BIT(4)); + break; + case SCLK_UPHY0_TCPDCORE: + rk_clrreg(>cru->clkgate_con[13], BIT(5)); + break; + case SCLK_UPHY1_TCPDPHY_REF: + rk_clrreg(>cru->clkgate_con[13], BIT(6)); + break; + case SCLK_UPHY1_TCPDCORE: + rk_clrreg(>cru->clkgate_con[13], BIT(7)); + break; case SCLK_PCIEPHY_REF: rk_clrreg(>cru->clksel_con[18], BIT(10)); break; @@ -1226,6 +1238,18 @@ static int rk3399_clk_disable(struct clk *clk) case HCLK_HOST1_ARB: rk_setreg(>cru->clksel_con[20], BIT(8)); break; + case SCLK_UPHY0_TCPDPHY_REF: + rk_setreg(>cru->clkgate_con[13], BIT(4)); + break; + case SCLK_UPHY0_TCPDCORE: + rk_setreg(>cru->clkgate_con[13], BIT(5)); + break; + case SCLK_UPHY1_TCPDPHY_REF: + rk_setreg(>cru->clkgate_con[13], BIT(6)); + break; + case SCLK_UPHY1_TCPDCORE: + rk_setreg(>cru->clkgate_con[13], BIT(7)); + break; case SCLK_PCIEPHY_REF: rk_clrreg(>cru->clksel_con[18], BIT(10)); break; -- 2.17.1
[PATCH v6 00/16] Add Rockchip RK3399 USB3.0 Host support
This series add quirks for DWC3 and add Rockchip RK3399 USB3.0 host support. The function has been tested pass on rk3399-evb and roc-rk3399-pc board. For V6 update: - Use [PATCH v6 04/16] instead of [PATCH v5 05/16] to fix that the current Generic PHY subsystem is unable to find PHY if the PHY node is not part of the root structure. - Add 'Reviewed-by' tag for all patches except [PATCH v6 04/16]. For V5 update: - Fix dwc3-generic driver followed Marek's comments for [PATCH v4 12/16]. - Add 'Reviewed-by' and 'Tested-by' tag for [PATCH v4 07/16] and [PATCH v4 08/16]. For V4 update: - Collect Jagan's all fixed patches [1]. - Amend specific u-boot changes from dts to dtsi for [PATCH v3 6/7]. For V3 update: - Fix compile error for [PATCH v2 1/9]. - Use Jagan's Type-C driver instead of [PATCH v2 5/9]. - Cleanup dts changes for [PATCH v2 7/9]. - Cleanup config changes for [PATCH v2 8/9] and [PATCH v2 9/9]. For V2 update: - Amend type-c driver followed Jagan's comments for [PATCH 5/8]. - Fix dts commit for [PATCH 7/8]. - Split RK3399 default config for [PATCH 8/8]. - Add 'Reviewed-by' tag for [PATCH 1/8], [PATCH 2/8] and [PATCH 3/8]. [1] https://patchwork.ozlabs.org/project/uboot/cover/20200506075025.1677-1-ja...@amarulasolutions.com BR, Frank Frank Wang (8): arm: mach-rockchip: bind sub-nodes for rk3399_syscon usb: dwc3: add dis_enblslpm_quirk usb: dwc3: add dis_u2_freeclk_exists_quirk usb: dwc3: amend UTMI/UTMIW phy interface setup usb: dwc3: add make compatible for rockchip platform driver: usb: drop legacy rockchip xhci driver ARM: dts: rk3399-evb: usb3.0 host support configs: evb-rk3399: update support usb3.0 host Jagan Teki (8): clk: rk3399: Enable/Disable the USB2PHY clk clk: rk3399: Set empty for TCPHY assigned-clocks clk: rk3399: Enable/Disable TCPHY clocks phy: rockchip: Add Rockchip USB2PHY driver phy: rockchip: Add Rockchip USB TypeC PHY driver usb: dwc3: Add disable u2mac linestate check quirk usb: dwc3: Enable AutoRetry feature in the controller roc-rk3399-pc: Enable USB3.0 Host arch/arm/dts/rk3399-evb-u-boot.dtsi | 13 + arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 3 + configs/evb-rk3399_defconfig | 6 + configs/roc-pc-mezzanine-rk3399_defconfig | 5 + configs/roc-pc-rk3399_defconfig | 6 + drivers/Makefile | 1 + drivers/clk/rockchip/clk_rk3399.c | 38 + drivers/phy/Kconfig | 1 + drivers/phy/rockchip/Kconfig | 21 + drivers/phy/rockchip/Makefile | 7 + drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 312 +++ drivers/phy/rockchip/phy-rockchip-typec.c | 796 ++ drivers/usb/common/common.c | 25 + drivers/usb/dwc3/core.c | 106 ++- drivers/usb/dwc3/core.h | 19 + drivers/usb/dwc3/dwc3-generic.c | 33 +- drivers/usb/host/Kconfig | 9 - drivers/usb/host/Makefile | 1 - drivers/usb/host/xhci-rockchip.c | 196 - include/dwc3-uboot.h | 3 + include/linux/usb/phy.h | 18 + 21 files changed, 1376 insertions(+), 243 deletions(-) create mode 100644 drivers/phy/rockchip/Kconfig create mode 100644 drivers/phy/rockchip/Makefile create mode 100644 drivers/phy/rockchip/phy-rockchip-inno-usb2.c create mode 100644 drivers/phy/rockchip/phy-rockchip-typec.c delete mode 100644 drivers/usb/host/xhci-rockchip.c -- 2.17.1
[PATCH v6 02/16] clk: rk3399: Set empty for TCPHY assigned-clocks
From: Jagan Teki Due to v5.7-rc1 sync the SD controller nodes in rk3399.dtsi have SCLK_UPHY0_TCPDCORE, SCLK_UPHY1_TCPDCORE assigned-clocks which are usually required for Linux and don't require to handle them in U-Boot. assigned-clocks = < SCLK_UPHY0_TCPDCORE>; assigned-clocks = < SCLK_UPHY1_TCPDCORE>; So, mark them as empty in clock otherwise device probe on those typec phy driver would fail. Signed-off-by: Jagan Teki Reviewed-by: Kever Yang --- drivers/clk/rockchip/clk_rk3399.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clk/rockchip/clk_rk3399.c b/drivers/clk/rockchip/clk_rk3399.c index b53f2f984e..98fc6a3267 100644 --- a/drivers/clk/rockchip/clk_rk3399.c +++ b/drivers/clk/rockchip/clk_rk3399.c @@ -997,6 +997,8 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong rate) case ACLK_VOP1: case HCLK_VOP1: case HCLK_SD: + case SCLK_UPHY0_TCPDCORE: + case SCLK_UPHY1_TCPDCORE: /** * assigned-clocks handling won't require for vopl, so * return 0 to satisfy clk_set_defaults during device probe. -- 2.17.1
[PATCH v6 01/16] clk: rk3399: Enable/Disable the USB2PHY clk
From: Jagan Teki Enable/Disable the USB2PHY clk for rk3399. CLK is clear in enable and set in disable functionality. Signed-off-by: Jagan Teki Reviewed-by: Kever Yang --- drivers/clk/rockchip/clk_rk3399.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/clk/rockchip/clk_rk3399.c b/drivers/clk/rockchip/clk_rk3399.c index 5fb72d83c2..b53f2f984e 100644 --- a/drivers/clk/rockchip/clk_rk3399.c +++ b/drivers/clk/rockchip/clk_rk3399.c @@ -1091,6 +1091,12 @@ static int rk3399_clk_enable(struct clk *clk) case SCLK_MACREF_OUT: rk_clrreg(>cru->clkgate_con[5], BIT(6)); break; + case SCLK_USB2PHY0_REF: + rk_clrreg(>cru->clkgate_con[6], BIT(5)); + break; + case SCLK_USB2PHY1_REF: + rk_clrreg(>cru->clkgate_con[6], BIT(6)); + break; case ACLK_GMAC: rk_clrreg(>cru->clkgate_con[32], BIT(0)); break; @@ -1167,6 +1173,12 @@ static int rk3399_clk_disable(struct clk *clk) case SCLK_MACREF_OUT: rk_setreg(>cru->clkgate_con[5], BIT(6)); break; + case SCLK_USB2PHY0_REF: + rk_setreg(>cru->clkgate_con[6], BIT(5)); + break; + case SCLK_USB2PHY1_REF: + rk_setreg(>cru->clkgate_con[6], BIT(6)); + break; case ACLK_GMAC: rk_setreg(>cru->clkgate_con[32], BIT(0)); break; -- 2.17.1
[PATCH 3/5] ARM: dts: stm32: Add alternate pinmux for I2C2 pins
Add another mux option for I2C2 pins, this is used on AV96 board.
Signed-off-by: Marek Vasut
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
arch/arm/dts/stm32mp15-pinctrl.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi
b/arch/arm/dts/stm32mp15-pinctrl.dtsi
index 8d00391978..c385896ebc 100644
--- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
@@ -357,6 +357,23 @@
};
};
+ i2c2_pins_c: i2c2-4 {
+ pins {
+ pinmux = , /* I2C2_SCL */
+; /* I2C2_SDA */
+ bias-disable;
+ drive-open-drain;
+ slew-rate = <0>;
+ };
+ };
+
+ i2c2_pins_sleep_c: i2c2-5 {
+ pins {
+ pinmux = , /* I2C2_SCL */
+; /* I2C2_SDA */
+ };
+ };
+
i2c5_pins_a: i2c5-0 {
pins {
pinmux = , /* I2C5_SCL */
--
2.25.1
[PATCH 5/5] ARM: dts: stm32: Disable SDR104 mode on AV96
Disable SDR104 mode until we know it is really stable. Signed-off-by: Marek Vasut Cc: Patrick Delaunay Cc: Patrice Chotard --- arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts b/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts index 7f2e4b98a7..c1cc80bcf5 100644 --- a/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts +++ b/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts @@ -144,7 +144,6 @@ st,sig-dir; st,neg-edge; st,use-ckin; - sd-uhs-sdr104; bus-width = <4>; vmmc-supply = <_sd>; vqmmc-supply = <_switch>; -- 2.25.1
[PATCH 2/5] ARM: stm32: Hog GPIO PF7 high on DHCOR to unlock SPI NOR nWP
The SPI NOR nWP line is connected to GPIO PF7 on the SoM,
pull the GPIO line high by default to clear SPI NOR WP.
Signed-off-by: Marek Vasut
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 9 +
configs/stm32mp15_dhcor_basic_defconfig| 1 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
index ef730a8322..bd4c2adc35 100644
--- a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
@@ -21,6 +21,15 @@
};
};
+ {
+ snor-nwp {
+ gpio-hog;
+ gpios = <7 0>;
+ output-high;
+ line-name = "spi-nor-nwp";
+ };
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/configs/stm32mp15_dhcor_basic_defconfig
b/configs/stm32mp15_dhcor_basic_defconfig
index 7163d0ad1b..249646c449 100644
--- a/configs/stm32mp15_dhcor_basic_defconfig
+++ b/configs/stm32mp15_dhcor_basic_defconfig
@@ -71,6 +71,7 @@ CONFIG_SPL_BLOCK_CACHE=y
CONFIG_DFU_MMC=y
CONFIG_DFU_RAM=y
CONFIG_DFU_VIRT=y
+CONFIG_GPIO_HOG=y
CONFIG_DM_HWSPINLOCK=y
CONFIG_HWSPINLOCK_STM32=y
CONFIG_DM_I2C=y
--
2.25.1
[PATCH 1/5] ARM: stm32: Re-enable KS8851 on DHCOM
Since the KS8851 driver is now in, enable the Kconfig entry on DHCOM to make the second ethernet available. Signed-off-by: Marek Vasut Cc: Patrick Delaunay Cc: Patrice Chotard --- configs/stm32mp15_dhcom_basic_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/stm32mp15_dhcom_basic_defconfig b/configs/stm32mp15_dhcom_basic_defconfig index c1c83eb4fc..6106572673 100644 --- a/configs/stm32mp15_dhcom_basic_defconfig +++ b/configs/stm32mp15_dhcom_basic_defconfig @@ -101,6 +101,7 @@ CONFIG_SPI_FLASH_MTD=y CONFIG_SPL_SPI_FLASH_MTD=y CONFIG_DM_ETH=y CONFIG_DWC_ETH_QOS=y +CONFIG_KS8851_MLL=y CONFIG_PHY=y CONFIG_PHY_STM32_USBPHYC=y CONFIG_PINCONF=y -- 2.25.1
[PATCH 4/5] ARM: dts: stm32: Repair I2C2 operation on AV96
The I2C2 uses different pinmux on AV96, use correct pinmux and
also add comments about the I2C being present on the "low-speed"
expansion connector X6.
Signed-off-by: Marek Vasut
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
b/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
index 1b0579c8ab..7f2e4b98a7 100644
--- a/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
+++ b/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
@@ -107,7 +107,7 @@
};
};
- {
+ {/* X6 I2C1 */
pinctrl-names = "default";
pinctrl-0 = <_pins_b>;
i2c-scl-rising-time-ns = <185>;
@@ -117,9 +117,9 @@
/delete-property/dma-names;
};
- {
+ {/* X6 I2C2 */
pinctrl-names = "default";
- pinctrl-0 = <_pins_b1 _pins_b2>;
+ pinctrl-0 = <_pins_c>;
i2c-scl-rising-time-ns = <185>;
i2c-scl-falling-time-ns = <20>;
status = "okay";
--
2.25.1
RE: [PATCH u-boot v2 1/2] eth/r8152: fix assigning the wrong endpoint
Marek Vasut [mailto:ma...@denx.de] > Sent: Monday, May 25, 2020 9:01 PM [...] > > Excuse me. I test v1 only. > > Do I have to resend v1 for patch #1? > > I'll pick V1, no worries. Thanks. Best Regards, Hayes
RE: [PATCH] armv8: cache_v8: fix mmu_set_region_dcache_behaviour
> Subject: Re: [PATCH] armv8: cache_v8: fix > mmu_set_region_dcache_behaviour > > On Mon, May 11, 2020 at 04:41:07PM +0800, Peng Fan wrote: > > > enum dcache_option already shift left 2 bits, PMD_ATTRINDX(option), > > will wrongly shift left the attr 4bits, which is wrong. And make the > > region user set not has expected attribute and might affect the > > splitted block region. > > > > Reviewed-by: Ye Li > > Signed-off-by: Peng Fan > > Please note that I reworded the commit message a bit. In the interest of > fixing the bug now: > > Applied to u-boot/master. > > But on reading the code and macros to understand things better for the > commit message, I wonder why we don't just use options directly now in the > code? Seems directly using options would make it a bit simplier! I agree. Thanks, Peng. Thanks! > > -- > Tom
[ANN] U-Boot v2020.07-rc3 released
Hey all, It's release day and I've tagged v2020.07-rc3. We're moving along nicely and should continue with prioritizing stabilization and obviously correct updates / migrations at this time. Once again, for a changelog, git log --merges v2020.07-rc2..v2020.07-rc3 and as always, I ask for more details in the PRs people send me so I can put them in the merge commit. I'm going to continue with the every-other-week RC schedule and release on July 6th. I'm currently planning to branch -next on June 8th but PRs can be posted sooner and I'll get them queued up. Thanks all! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] TI changes for v2020.07-rc3
On Mon, May 25, 2020 at 10:37:33PM +0530, Lokesh Vutla wrote: > Hi Tom, > Please find the pull request for v2020.07-rc3 containing TI specific > changes. > > Travis-CI build: > https://travis-ci.org/github/lokeshvutla/u-boot/builds/690912492 > > Thanks and regards, > Lokesh > > The following changes since commit ed9a3aa6452f57af65eb74f73bd2a54c3a2f4b03: > > Merge tag 'efi-2020-07-rc3' of > https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-05-18 08:17:29 > -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2020.07-rc3 > > for you to fetch changes up to c02712a7484918648e5dd09c092035c7eeb7794a: > > arm: mach-k3: Enable dcache in SPL (2020-05-19 14:41:13 +0530) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 8/8] imx: convert mx53loco board to DM_VIDEO
Migration to DM_VIDEO driver is long overdue. Update defconfig to enable usage of converted ipuv3 driver DM configuration. Signed-off-by: Anatolij Gustschin Cc: Jason Liu --- configs/mx53loco_defconfig | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/configs/mx53loco_defconfig b/configs/mx53loco_defconfig index e5d842a75d..40fab2016c 100644 --- a/configs/mx53loco_defconfig +++ b/configs/mx53loco_defconfig @@ -37,7 +37,12 @@ CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y -CONFIG_VIDEO=y -# CONFIG_VIDEO_SW_CURSOR is not set +# CONFIG_BACKLIGHT is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP32 is not set +# CONFIG_VIDEO_ANSI is not set +# CONFIG_PANEL is not set +CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_OF_LIBFDT=y -- 2.17.1
[PATCH 7/8] imx: convert mx51evk board to DM_VIDEO
Migration to DM_VIDEO driver is long overdue. Update defconfig to enable usage of converted ipuv3 driver DM configuration. Signed-off-by: Anatolij Gustschin Cc: Stefano Babic --- configs/mx51evk_defconfig | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/configs/mx51evk_defconfig b/configs/mx51evk_defconfig index dbc4d85a22..b8e3ba205f 100644 --- a/configs/mx51evk_defconfig +++ b/configs/mx51evk_defconfig @@ -36,7 +36,12 @@ CONFIG_USB_STORAGE=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y -CONFIG_VIDEO=y -# CONFIG_VIDEO_SW_CURSOR is not set +# CONFIG_BACKLIGHT is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP32 is not set +# CONFIG_VIDEO_ANSI is not set +# CONFIG_PANEL is not set +CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_OF_LIBFDT=y -- 2.17.1
[PATCH 1/8] imx: convert embest boards to DM_VIDEO
Migration to DM_VIDEO driver is long overdue. Update defconfigs to enable usage of converted ipuv3 driver DM configuration. Signed-off-by: Anatolij Gustschin --- configs/marsboard_defconfig | 9 +++-- configs/riotboard_defconfig | 9 +++-- configs/riotboard_spl_defconfig | 9 +++-- 3 files changed, 21 insertions(+), 6 deletions(-) diff --git a/configs/marsboard_defconfig b/configs/marsboard_defconfig index 765a3ca2b6..9551c63f00 100644 --- a/configs/marsboard_defconfig +++ b/configs/marsboard_defconfig @@ -38,7 +38,12 @@ CONFIG_DM_THERMAL=y CONFIG_USB=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y +CONFIG_DM_VIDEO=y +# CONFIG_BACKLIGHT is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP32 is not set +# CONFIG_VIDEO_ANSI is not set +# CONFIG_PANEL is not set CONFIG_VIDEO_IPUV3=y -CONFIG_VIDEO=y -# CONFIG_VIDEO_SW_CURSOR is not set +CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_OF_LIBFDT=y diff --git a/configs/riotboard_defconfig b/configs/riotboard_defconfig index 73656017d1..d2160d7793 100644 --- a/configs/riotboard_defconfig +++ b/configs/riotboard_defconfig @@ -38,7 +38,12 @@ CONFIG_DM_THERMAL=y CONFIG_USB=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y +CONFIG_DM_VIDEO=y +# CONFIG_BACKLIGHT is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP32 is not set +# CONFIG_VIDEO_ANSI is not set +# CONFIG_PANEL is not set CONFIG_VIDEO_IPUV3=y -CONFIG_VIDEO=y -# CONFIG_VIDEO_SW_CURSOR is not set +CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_OF_LIBFDT=y diff --git a/configs/riotboard_spl_defconfig b/configs/riotboard_spl_defconfig index 5ff8da0355..a7435c6427 100644 --- a/configs/riotboard_spl_defconfig +++ b/configs/riotboard_spl_defconfig @@ -48,8 +48,13 @@ CONFIG_DM_THERMAL=y CONFIG_USB=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y +CONFIG_DM_VIDEO=y +# CONFIG_BACKLIGHT is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP32 is not set +# CONFIG_VIDEO_ANSI is not set +# CONFIG_PANEL is not set CONFIG_VIDEO_IPUV3=y -CONFIG_VIDEO=y -# CONFIG_VIDEO_SW_CURSOR is not set +CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_OF_LIBFDT=y CONFIG_SPL_OF_LIBFDT=y -- 2.17.1
[PATCH 3/8] imx: convert dms-ba16 boards to DM_VIDEO
Migration to DM_VIDEO driver is long overdue. Update defconfigs to enable usage of converted ipuv3 driver DM configuration. Signed-off-by: Anatolij Gustschin Cc: Akshay Bhat Cc: Ken Lin --- configs/dms-ba16-1g_defconfig| 9 +++-- configs/dms-ba16_defconfig | 9 +++-- include/configs/advantech_dms-ba16.h | 2 -- 3 files changed, 14 insertions(+), 6 deletions(-) diff --git a/configs/dms-ba16-1g_defconfig b/configs/dms-ba16-1g_defconfig index 0739527037..64f3a0ff04 100644 --- a/configs/dms-ba16-1g_defconfig +++ b/configs/dms-ba16-1g_defconfig @@ -58,7 +58,12 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y -CONFIG_VIDEO=y -# CONFIG_VIDEO_SW_CURSOR is not set +# CONFIG_BACKLIGHT is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP32 is not set +# CONFIG_VIDEO_ANSI is not set +# CONFIG_PANEL is not set +CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_OF_LIBFDT=y diff --git a/configs/dms-ba16_defconfig b/configs/dms-ba16_defconfig index 03a2c59bad..b2e042c222 100644 --- a/configs/dms-ba16_defconfig +++ b/configs/dms-ba16_defconfig @@ -57,7 +57,12 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y -CONFIG_VIDEO=y -# CONFIG_VIDEO_SW_CURSOR is not set +# CONFIG_BACKLIGHT is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP32 is not set +# CONFIG_VIDEO_ANSI is not set +# CONFIG_PANEL is not set +CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_OF_LIBFDT=y diff --git a/include/configs/advantech_dms-ba16.h b/include/configs/advantech_dms-ba16.h index d44028d510..9cbdb1face 100644 --- a/include/configs/advantech_dms-ba16.h +++ b/include/configs/advantech_dms-ba16.h @@ -202,7 +202,6 @@ #define CONFIG_SYS_FSL_USDHC_NUM3 /* Framebuffer */ -#ifdef CONFIG_VIDEO #define CONFIG_VIDEO_BMP_RLE8 #define CONFIG_SPLASH_SCREEN #define CONFIG_SPLASH_SCREEN_ALIGN @@ -211,7 +210,6 @@ #define CONFIG_VIDEO_BMP_LOGO #define CONFIG_IMX_HDMI #define CONFIG_IMX_VIDEO_SKIP -#endif #define CONFIG_IMX6_PWM_PER_CLK 6600 -- 2.17.1
[PATCH 2/8] imx: convert pico-imx6 to DM_VIDEO
Update defconfig to enable usage of converted ipuv3 driver DM configuration. Signed-off-by: Anatolij Gustschin Cc: Fabio Estevam --- configs/pico-imx6_defconfig | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/configs/pico-imx6_defconfig b/configs/pico-imx6_defconfig index 0bc7e4fc95..503b47f2b1 100644 --- a/configs/pico-imx6_defconfig +++ b/configs/pico-imx6_defconfig @@ -73,5 +73,11 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y +CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y -CONFIG_VIDEO=y +# CONFIG_BACKLIGHT is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP32 is not set +# CONFIG_VIDEO_ANSI is not set +# CONFIG_PANEL is not set +CONFIG_SYS_WHITE_ON_BLACK=y -- 2.17.1
[PATCH 5/8] imx: convert mx6cuboxi board to DM_VIDEO
Migration to DM_VIDEO driver is long overdue. Update defconfig to enable usage of converted ipuv3 driver DM configuration. Signed-off-by: Anatolij Gustschin Cc: Baruch Siach Cc: Fabio Estevam --- configs/mx6cuboxi_defconfig | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig index df7e4611a0..69783310c2 100644 --- a/configs/mx6cuboxi_defconfig +++ b/configs/mx6cuboxi_defconfig @@ -22,7 +22,7 @@ CONFIG_FIT=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run distro_bootcmd" CONFIG_USE_PREBOOT=y -CONFIG_PREBOOT="if hdmidet; then usb start; setenv stdin serial,usbkbd; setenv stdout serial,vga; setenv stderr serial,vga; else setenv stdin serial; setenv stdout serial; setenv stderr serial; fi;" +CONFIG_PREBOOT="if hdmidet; then usb start; setenv stdin serial,usbkbd; setenv stdout serial,vidconsole; setenv stderr serial,vidconsole; else setenv stdin serial; setenv stdout serial; setenv stderr serial; fi;" CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_FS_EXT4=y @@ -59,6 +59,11 @@ CONFIG_DM_THERMAL=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_KEYBOARD=y +CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y -CONFIG_VIDEO=y -# CONFIG_VIDEO_SW_CURSOR is not set +# CONFIG_BACKLIGHT is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP32 is not set +# CONFIG_VIDEO_ANSI is not set +# CONFIG_PANEL is not set +CONFIG_SYS_WHITE_ON_BLACK=y -- 2.17.1
[PATCH 6/8] imx: convert gwventana board to DM_VIDEO
Migration to DM_VIDEO driver is long overdue. Update defconfigs to enable usage of converted ipuv3 driver DM configuration. Signed-off-by: Anatolij Gustschin Cc: Tim Harvey --- configs/gwventana_emmc_defconfig | 9 +++-- configs/gwventana_gw5904_defconfig | 9 +++-- configs/gwventana_nand_defconfig | 9 +++-- 3 files changed, 21 insertions(+), 6 deletions(-) diff --git a/configs/gwventana_emmc_defconfig b/configs/gwventana_emmc_defconfig index 639cb99862..1bfd1d2112 100644 --- a/configs/gwventana_emmc_defconfig +++ b/configs/gwventana_emmc_defconfig @@ -90,8 +90,13 @@ CONFIG_USB_ETH_CDC=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y -CONFIG_VIDEO=y -# CONFIG_VIDEO_SW_CURSOR is not set +# CONFIG_BACKLIGHT is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP32 is not set +# CONFIG_VIDEO_ANSI is not set +# CONFIG_PANEL is not set +CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_OF_LIBFDT=y CONFIG_FDT_FIXUP_PARTITIONS=y diff --git a/configs/gwventana_gw5904_defconfig b/configs/gwventana_gw5904_defconfig index 67ea57c7fc..ad23670d03 100644 --- a/configs/gwventana_gw5904_defconfig +++ b/configs/gwventana_gw5904_defconfig @@ -94,8 +94,13 @@ CONFIG_USB_ETH_CDC=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y -CONFIG_VIDEO=y -# CONFIG_VIDEO_SW_CURSOR is not set +# CONFIG_BACKLIGHT is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP32 is not set +# CONFIG_VIDEO_ANSI is not set +# CONFIG_PANEL is not set +CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_OF_LIBFDT=y CONFIG_FDT_FIXUP_PARTITIONS=y diff --git a/configs/gwventana_nand_defconfig b/configs/gwventana_nand_defconfig index f6e85b680b..a71c04fb7f 100644 --- a/configs/gwventana_nand_defconfig +++ b/configs/gwventana_nand_defconfig @@ -95,8 +95,13 @@ CONFIG_USB_ETH_CDC=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y -CONFIG_VIDEO=y -# CONFIG_VIDEO_SW_CURSOR is not set +# CONFIG_BACKLIGHT is not set +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP32 is not set +# CONFIG_VIDEO_ANSI is not set +# CONFIG_PANEL is not set +CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_OF_LIBFDT=y CONFIG_FDT_FIXUP_PARTITIONS=y -- 2.17.1
[PATCH 4/8] imx: convert cgtqmx6eval board to DM_VIDEO
Migration to DM_VIDEO driver is long overdue. Update defconfig
to enable usage of converted ipuv3 driver DM configuration.
Signed-off-by: Anatolij Gustschin
Cc: Otavio Salvador
---
board/congatec/cgtqmx6eval/cgtqmx6eval.c | 5 +
configs/cgtqmx6eval_defconfig| 9 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/board/congatec/cgtqmx6eval/cgtqmx6eval.c
b/board/congatec/cgtqmx6eval/cgtqmx6eval.c
index 044cefd979..392a3f8f1d 100644
--- a/board/congatec/cgtqmx6eval/cgtqmx6eval.c
+++ b/board/congatec/cgtqmx6eval/cgtqmx6eval.c
@@ -627,6 +627,11 @@ int board_video_skip(void)
return 0;
}
+int ipu_displays_init(void)
+{
+ return board_video_skip();
+}
+
static void setup_display(void)
{
struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
diff --git a/configs/cgtqmx6eval_defconfig b/configs/cgtqmx6eval_defconfig
index a934336f41..94c6e3d908 100644
--- a/configs/cgtqmx6eval_defconfig
+++ b/configs/cgtqmx6eval_defconfig
@@ -79,7 +79,12 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
CONFIG_CI_UDC=y
CONFIG_USB_HOST_ETHER=y
CONFIG_USB_ETHER_ASIX=y
+CONFIG_DM_VIDEO=y
CONFIG_VIDEO_IPUV3=y
-CONFIG_VIDEO=y
-# CONFIG_VIDEO_SW_CURSOR is not set
+# CONFIG_BACKLIGHT is not set
+# CONFIG_VIDEO_BPP8 is not set
+# CONFIG_VIDEO_BPP32 is not set
+# CONFIG_VIDEO_ANSI is not set
+# CONFIG_PANEL is not set
+CONFIG_SYS_WHITE_ON_BLACK=y
CONFIG_OF_LIBFDT=y
--
2.17.1
Re: [PATCH 2/2] sf: Simplify probe for dm code
On Mon, May 25, 2020 at 03:48:22PM -0600, Simon Glass wrote: > Hi Jagan, > > On Mon, 25 May 2020 at 02:14, Jagan Teki wrote: > > > > Hi Simon, > > > > On Fri, May 22, 2020 at 10:20 PM Simon Glass wrote: > > > > > > Hi Jagan, > > > > > > On Fri, 22 May 2020 at 08:41, Jagan Teki > > > wrote: > > > > > > > > Hi Simon, > > > > > > > > On Fri, May 22, 2020 at 7:55 PM Simon Glass wrote: > > > > > > > > > > Hi Jagan, > > > > > > > > > > On Thu, 14 May 2020 at 12:09, Jagan Teki > > > > > wrote: > > > > > > > > > > > > Handling probing code for a particular uclass between > > > > > > dm vs nodm always confusing and requires additional > > > > > > ifdefs to handle them properly. > > > > > > > > > > > > But, having separate low-level code bases for dm and > > > > > > nodm can make it easy for the command level to use same > > > > > > function name to probe the devices. This would indeed > > > > > > avoid extra ifdef call in source code. > > > > > > > > > > > > So, this patch probes the spi flash in common legacy > > > > > > call spi_flash_probe for both dm and nodm devices and > > > > > > give a chance to handle on respective code bases based > > > > > > on the build files. > > > > > > > > > > > > Cc: Simon Glass > > > > > > Cc: Vignesh R > > > > > > Cc: Daniel Schwierzeck > > > > > > Signed-off-by: Jagan Teki > > > > > > --- > > > > > > cmd/sf.c| 22 - > > > > > > drivers/mtd/spi/sf-uclass.c | 38 > > > > > > + > > > > > > drivers/net/fm/fm.c | 20 --- > > > > > > env/sf.c| 17 + > > > > > > include/spi_flash.h | 20 +-- > > > > > > 5 files changed, 19 insertions(+), 98 deletions(-) > > > > > > > > > > +Tom Rini > > > > > > > > > > This is really going the wrong way. You would cement the code in limbo > > > > > forever and no one would be able to migrate property. > > > > > > > > > > Instead, you should add a patch to disable SPI flash on boards which > > > > > have not migrated. Then we can actually clean up the mess properly. > > > > > > > > > > The deadline has passed and people have had more than 5 years to > > > > > migrate. > > > > > > > > > > It is time to make the cut. > > > > > > > > It's not entirely about migration, but also the future development > > > > with MTD uclass. I'm trying to separate the code for dm vs nodm, and > > > > dm files would be further developed to use MTD uclass (series will > > > > send soon) and nodm keep it as static and drop at a later point. I > > > > take the clean part early before moving into MTD uclass since the > > > > migration from SPI flash to MTD is smooth. > > > > > > To me it looks like the DM way is being removed. > > > > > > I really feel this should be done in the reverse order. Remove the old > > > code and then refactor. > > > > > > The old code does not understand DT at all. It means we are stuck with > > > things like CONFIG variables for the bus to use for SPI environment, > > > etc. > > > > > > Please let's just migrate. It is *well* past time. > > > > As I clearly mentioned in the commit message, there is no dm code > > being removed as such all I'm doing is to refactor the code to have > > two functional flows for dm and nodm. This would make the removal of > > non dm and developing the dm code specially on the MTD/SPI-NOR side > > become easy and meaningful. > > Most of nondm spi flash code is not that easy since it has SPL > > foot-print issues,and most of MTD code requires close attention as a > > lot of code is copied/synced from Linux. > > Then I think I am a bit lost. It sounds like you are saying you cannot > migrate to DM? I think we need to tie together 2 threads. There are SPI drivers that are DM migrated for full U-Boot but cannot do the whole DM+DT thing in SPL. -- Tom signature.asc Description: PGP signature
[PATCH] video: make backlight and panel drivers optional
Not all boards use these drivers, so allow to disable them to fix
building boards with U-Boot binary image size restrictions.
Signed-off-by: Anatolij Gustschin
---
drivers/video/Kconfig | 27 +--
drivers/video/Makefile | 5 +++--
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index eb5e26644a..01e8dbf678 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -14,9 +14,17 @@ config DM_VIDEO
option compiles in the video uclass and routes all LCD/video access
through this.
+config BACKLIGHT
+ bool "Enable panel backlight uclass support"
+ depends on DM_VIDEO
+ default y
+ help
+ This provides backlight uclass driver that enables basic panel
+ backlight support.
+
config BACKLIGHT_PWM
bool "Generic PWM based Backlight Driver"
- depends on DM_VIDEO && DM_PWM
+ depends on BACKLIGHT && DM_PWM
default y
help
If you have a LCD backlight adjustable by PWM, say Y to enable
@@ -27,7 +35,7 @@ config BACKLIGHT_PWM
config BACKLIGHT_GPIO
bool "Generic GPIO based Backlight Driver"
- depends on DM_VIDEO
+ depends on BACKLIGHT
help
If you have a LCD backlight adjustable by GPIO, say Y to enable
this driver.
@@ -151,6 +159,21 @@ config NO_FB_CLEAR
loads takes over the screen. This, for example, can be used to
keep splash image on screen until grub graphical boot menu starts.
+config PANEL
+ bool "Enable panel uclass support"
+ depends on DM_VIDEO
+ default y
+ help
+ This provides panel uclass driver that enables basic panel support.
+
+config SIMPLE_PANEL
+ bool "Enable simple panel support"
+ depends on PANEL
+ default y
+ help
+ This turns on a simple panel driver that enables a compatible
+ video panel.
+
source "drivers/video/fonts/Kconfig"
config VIDCONSOLE_AS_LCD
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index df7119d62a..1dbd09a172 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -4,17 +4,18 @@
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
ifdef CONFIG_DM
+obj-$(CONFIG_BACKLIGHT) += backlight-uclass.o
obj-$(CONFIG_BACKLIGHT_GPIO) += backlight_gpio.o
obj-$(CONFIG_BACKLIGHT_PWM) += pwm_backlight.o
obj-$(CONFIG_CONSOLE_NORMAL) += console_normal.o
obj-$(CONFIG_CONSOLE_ROTATION) += console_rotate.o
obj-$(CONFIG_CONSOLE_TRUETYPE) += console_truetype.o fonts/
obj-$(CONFIG_DISPLAY) += display-uclass.o
-obj-$(CONFIG_DM_VIDEO) += backlight-uclass.o
obj-$(CONFIG_VIDEO_MIPI_DSI) += dsi-host-uclass.o
-obj-$(CONFIG_DM_VIDEO) += panel-uclass.o simple_panel.o
obj-$(CONFIG_DM_VIDEO) += video-uclass.o vidconsole-uclass.o
obj-$(CONFIG_DM_VIDEO) += video_bmp.o
+obj-$(CONFIG_PANEL) += panel-uclass.o
+obj-$(CONFIG_SIMPLE_PANEL) += simple_panel.o
endif
obj-${CONFIG_EXYNOS_FB} += exynos/
--
2.17.1
[PATCH] video: ipuv3: fix building with disabled panel driver
Panel code might be disabled for some boards, make this
driver code optional.
Signed-off-by: Anatolij Gustschin
---
drivers/video/imx/mxc_ipuv3_fb.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/video/imx/mxc_ipuv3_fb.c b/drivers/video/imx/mxc_ipuv3_fb.c
index c7a944c1d5..017a8fb22a 100644
--- a/drivers/video/imx/mxc_ipuv3_fb.c
+++ b/drivers/video/imx/mxc_ipuv3_fb.c
@@ -627,7 +627,6 @@ static int ipuv3_video_probe(struct udevice *dev)
#if defined(CONFIG_DISPLAY)
struct udevice *disp_dev;
#endif
- struct udevice *panel_dev;
u32 fb_start, fb_end;
int ret;
@@ -654,9 +653,13 @@ static int ipuv3_video_probe(struct udevice *dev)
return ret;
}
#endif
- ret = uclass_get_device(UCLASS_PANEL, 0, _dev);
- if (panel_dev)
- panel_enable_backlight(panel_dev);
+ if (CONFIG_IS_ENABLED(PANEL)) {
+ struct udevice *panel_dev;
+
+ ret = uclass_get_device(UCLASS_PANEL, 0, _dev);
+ if (panel_dev)
+ panel_enable_backlight(panel_dev);
+ }
uc_priv->xsize = gmode->xres;
uc_priv->ysize = gmode->yres;
--
2.17.1
Re: [PATCH] video: make vidconsole commands optional
Hi Anatolij, On Mon, 25 May 2020 at 15:45, Anatolij Gustschin wrote: > > Hi Simon, > > On Mon, 25 May 2020 15:37:33 -0600 > Simon Glass s...@chromium.org wrote: > ... > > > optional to recude binary size. > > > > reduce > > I'll fix it in v2, thanks! > > > Which board is this? I'd just like to check that it is expected. > > this is tbs2910 board which makes most trouble currently. > I'm trying to make backlight, panel and simple panel code optional as > well, this could save us a few more bytes. OK I see. Yes, those definitely increase the size. Regards, Simon
Re: [PATCH 2/2] sf: Simplify probe for dm code
Hi Jagan, On Mon, 25 May 2020 at 02:14, Jagan Teki wrote: > > Hi Simon, > > On Fri, May 22, 2020 at 10:20 PM Simon Glass wrote: > > > > Hi Jagan, > > > > On Fri, 22 May 2020 at 08:41, Jagan Teki wrote: > > > > > > Hi Simon, > > > > > > On Fri, May 22, 2020 at 7:55 PM Simon Glass wrote: > > > > > > > > Hi Jagan, > > > > > > > > On Thu, 14 May 2020 at 12:09, Jagan Teki > > > > wrote: > > > > > > > > > > Handling probing code for a particular uclass between > > > > > dm vs nodm always confusing and requires additional > > > > > ifdefs to handle them properly. > > > > > > > > > > But, having separate low-level code bases for dm and > > > > > nodm can make it easy for the command level to use same > > > > > function name to probe the devices. This would indeed > > > > > avoid extra ifdef call in source code. > > > > > > > > > > So, this patch probes the spi flash in common legacy > > > > > call spi_flash_probe for both dm and nodm devices and > > > > > give a chance to handle on respective code bases based > > > > > on the build files. > > > > > > > > > > Cc: Simon Glass > > > > > Cc: Vignesh R > > > > > Cc: Daniel Schwierzeck > > > > > Signed-off-by: Jagan Teki > > > > > --- > > > > > cmd/sf.c| 22 - > > > > > drivers/mtd/spi/sf-uclass.c | 38 > > > > > + > > > > > drivers/net/fm/fm.c | 20 --- > > > > > env/sf.c| 17 + > > > > > include/spi_flash.h | 20 +-- > > > > > 5 files changed, 19 insertions(+), 98 deletions(-) > > > > > > > > +Tom Rini > > > > > > > > This is really going the wrong way. You would cement the code in limbo > > > > forever and no one would be able to migrate property. > > > > > > > > Instead, you should add a patch to disable SPI flash on boards which > > > > have not migrated. Then we can actually clean up the mess properly. > > > > > > > > The deadline has passed and people have had more than 5 years to > > > > migrate. > > > > > > > > It is time to make the cut. > > > > > > It's not entirely about migration, but also the future development > > > with MTD uclass. I'm trying to separate the code for dm vs nodm, and > > > dm files would be further developed to use MTD uclass (series will > > > send soon) and nodm keep it as static and drop at a later point. I > > > take the clean part early before moving into MTD uclass since the > > > migration from SPI flash to MTD is smooth. > > > > To me it looks like the DM way is being removed. > > > > I really feel this should be done in the reverse order. Remove the old > > code and then refactor. > > > > The old code does not understand DT at all. It means we are stuck with > > things like CONFIG variables for the bus to use for SPI environment, > > etc. > > > > Please let's just migrate. It is *well* past time. > > As I clearly mentioned in the commit message, there is no dm code > being removed as such all I'm doing is to refactor the code to have > two functional flows for dm and nodm. This would make the removal of > non dm and developing the dm code specially on the MTD/SPI-NOR side > become easy and meaningful. > Most of nondm spi flash code is not that easy since it has SPL > foot-print issues,and most of MTD code requires close attention as a > lot of code is copied/synced from Linux. Then I think I am a bit lost. It sounds like you are saying you cannot migrate to DM? Regards, Simon
Re: [PATCH v12 01/18] misc: add driver for the SiFive otp controller
Hi Pragnesh, On Mon, 25 May 2020 at 01:34, Pragnesh Patel wrote: > > Added a misc driver to handle OTP memory in SiFive SoCs. > > Signed-off-by: Pragnesh Patel > Reviewed-by: Bin Meng > Tested-by: Bin Meng > Reviewed-by: Jagan Teki > Tested-by: Jagan Teki > --- > drivers/misc/Kconfig | 7 + > drivers/misc/Makefile | 1 + > drivers/misc/sifive-otp.c | 275 ++ > 3 files changed, 283 insertions(+) > create mode 100644 drivers/misc/sifive-otp.c Did you miss the change log here? Regards, Simon
Re: [PATCH] video: make vidconsole commands optional
Hi Simon, On Mon, 25 May 2020 15:37:33 -0600 Simon Glass s...@chromium.org wrote: ... > > optional to recude binary size. > > reduce I'll fix it in v2, thanks! > Which board is this? I'd just like to check that it is expected. this is tbs2910 board which makes most trouble currently. I'm trying to make backlight, panel and simple panel code optional as well, this could save us a few more bytes. ... > > drivers/video/Kconfig | 8 > > drivers/video/vidconsole-uclass.c | 2 ++ > > 2 files changed, 10 insertions(+) > > Reviewed-by: Simon Glass Thanks! -- Anatolij
Re: [PATCH] RFC: tiny-dm: Proposal for using driver model in SPL
Hi Tom, On Mon, 25 May 2020 at 14:57, Tom Rini wrote: > > On Mon, May 25, 2020 at 02:34:20PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 25 May 2020 at 13:47, Tom Rini wrote: > > > > > > On Mon, May 25, 2020 at 09:35:44AM -0600, Simon Glass wrote: > > > > > > > This patch provides the documentation for a proposed enhancement to > > > > driver > > > > model to reduce overhead in SPL. > > > > > > > > The actual patches are not included here because they are based on some > > > > pending work by Walter Lozano which is not in final form. > > > > > > > > For now, the source tree is available at: > > > > > > > > > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/tree/dtoc-working > > > > > > > > Comments welcome! > > > > > > So here's my worry. It's not clear, aside from the device tree, how > > > much re-use of existing code we get with this. It feels like it might > > > be fairly minimal. And at that point, are we not perhaps making too > > > much work for ourselves compared with just excepting that there will > > > need to be a place for non-abstracted-framework drivers? What do we do > > > about TPL, when we get to the point of everything being converted to DM > > > and as-needed tiny-DM but there's still TPL drivers? The reason we have > > > SPL_FRAMEWORK as a symbol today is that we already had some > > > SoCs/architectures (primarily PowerPC) that had "SPL" but it was very > > > centric to the SoCs in question. > > > > > > The interface for example for mmc is: > > > int spl_mmc_load_image(struct spl_image_info *spl_image, struct > > > spl_boot_device *bootdev) and neither part of that is inherently DM. So > > > let it be MMC_TINY for the non-DM case and regular DM_MMC for the DM > > > case. I wonder if we could clean that up code a little if we let it be > > > separate. > > > > > > The interface for example for spi is: > > > int spl_spi_load_image(struct spl_image_info *spl_image, > > > struct spl_boot_device *bootdev) and well, the same thing. Or maybe we > > > can even push that up to the spi_flash_load() call. > > > > > > But my worry is that a different set of abstractions here are still > > > going to bring us in more overhead than writing drivers for the > > > functionality we need directly, and if we define what's allowed in this > > > limited case well, that might be good enough. > > > > Some boards (e.g. x86) Need to read multiple things from the SPI flash > > (such as FSP binaries), so I still think we will want a generic > > reading interface. > > > > You could be right, but my hunch is that there is value in having > > things more generic and the cost should be minimal. The value is that > > hopefully writing a few C functions in the SPI driver will be enough > > to enable tiny SPI on an SoC, reusing much of the code in the driver > > (only the reading bits!). We won't need as much special-case code and > > an entirely different way of configuring these devices for TPL/SPL. > > > > It has been interesting digging into the Zephyr model. It's drivers > > are very basic and thus small. But there is still value in using the > > device tree to assemble things. > > > > Anyway I'm not really sure at this point. It is just a hunch. I don't > > think we can know all this until we have a bit more information. > > Perhaps with a board with SPI, MMC and serial converted we would get a > > better picture? > > I think it's absolutely the case that we'll have to convert something > and see how it looks, then convert something else and see if it still > looks good enough. At a high enough level there's not really too much > of a difference between what it sounds like you're proposing and what > I'm proposing. Possibly even in a progmatic way too. We have (I think > anyhow) fairly static board configurations in this case so we don't so > much need to "probe" for possible drivers be told what our device > hierarchy is and to initialize what we're going to use. Yes, we may end up with special, separate code anyway, since if you end up refactoring the driver so much (and putting tiny-dm tentacles into it) that it becomes harder to maintain, it isn't a win. Basically I started out similar to what you are saying, with the idea of just direct calls into the driver (e.g. the driver implements serial_putc() and spi_read_flash()). But then I figured it is a very small overhead to retain some sort of driver model, so I thought I'd try that. I'll fiddle with this again in a week or so... Regards, Simon
Re: [PATCH v4 2/9] usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq
Hi Sylwester, On Mon, 25 May 2020 at 11:42, Sylwester Nawrocki wrote: > > Hi Simon, > > On 25.05.2020 19:04, Simon Glass wrote: > > On Mon, 25 May 2020 at 10:57, Sylwester Nawrocki > > wrote: > >> On 25.05.2020 16:57, Simon Glass wrote: > >>> On Mon, 25 May 2020 at 05:40, Sylwester Nawrocki > >>> wrote: > > There might be hardware configurations where 64-bit data accesses > to XHCI registers are not supported properly. This patch removes > the readq/writeq so always two 32-bit accesses are used to read/write > 64-bit XHCI registers, similarly as it is done in Linux kernel. > > This patch fixes operation of the XHCI controller on RPI4 Broadcom > BCM2711 SoC based board, where the VL805 USB XHCI controller is > connected to the PCIe Root Complex, which is attached to the system > through the SCB bridge. > > Even though the architecture is 64-bit the PCIe BAR is 32-bit and likely > the 64-bit wide register accesses initiated by the CPU are not properly > translated to a sequence of 32-bit PCIe accesses. > xhci_readq(), for example, always returns same value in upper and lower > 32-bits, e.g. 0xabcd1234abcd1234 instead of 0xabcd1234. > >> > >>> Then I think this should be done with a quirk flag, enabled for this > >>> particular device via the compatible string. It should not be an #if, > >>> but an if(). > >> > >> Thanks for your comments. I will check and see how this could be done. > >> It might not be so straightforward since the XHCI controller is a PCI > >> device matched by the pci_device_id so we would need to be looking > >> at the compatible string of the PCI controller to set the quirk in > >> the xhci layer. It's the PCI bridge that introduces the limitation, > >> not the VL805 XHCI controller chip. > > > > OK then it should be modelled as such. > > > > How is this done in Linux? > > In Linux simply always two 32-bit accesses are used for 64-bit registers > read/write. Well the USB maintainer (Marek) might be OK with that, not sure. > > And the quirks in the generic PCI XHCI driver are based on the PCI vendor > and the PCI device ID, so it's not helpful. I couldn't find any reference > to the parent PCI bridge there. In xhci_pci_probe() you can look at the PCI vendor/device with something like: struct pci_child_platdata *plat = dev_get_parent_platdata(dev); // see comments for that struct in pci.h int quirks = 0; if (plat->vendor == xxx && plat->device == xxx) quirks |= SOMETHING xhci_register(, quirks); // add a new param in xhci_register() you can store the quirk in ctrl. > > > You can add a quirk in the PCI controller and then XHCI can check its > > parent's platdata to see the flag, perhaps, since the parent will > > always be UCLASS_PCI. > > OK, I imagined something like that. > > > You can always add the device to the devicetree if needed, and then > > you get a compatible string. > > Will have a look, I wasn't aware we could add a node just for such purpose > without negative side effects. So long as you get the 'reg' property correct (i.e. same bus, device, function) then you are OK. See pci-info.rst for docs Regards, Simon
Re: [PATCH] video: make vidconsole commands optional
Hi Anatolij, On Mon, 25 May 2020 at 13:47, Anatolij Gustschin wrote: > > Converting some boards to DM_VIDEO results in build breakage due > to increased code size. Make video console specific commands > optional to recude binary size. reduce Which board is this? I'd just like to check that it is expected. > > Signed-off-by: Anatolij Gustschin > --- > drivers/video/Kconfig | 8 > drivers/video/vidconsole-uclass.c | 2 ++ > 2 files changed, 10 insertions(+) Reviewed-by: Simon Glass Regards, Simon
Re: [PATCH] RFC: tiny-dm: Proposal for using driver model in SPL
On Mon, May 25, 2020 at 02:34:20PM -0600, Simon Glass wrote: > Hi Tom, > > On Mon, 25 May 2020 at 13:47, Tom Rini wrote: > > > > On Mon, May 25, 2020 at 09:35:44AM -0600, Simon Glass wrote: > > > > > This patch provides the documentation for a proposed enhancement to driver > > > model to reduce overhead in SPL. > > > > > > The actual patches are not included here because they are based on some > > > pending work by Walter Lozano which is not in final form. > > > > > > For now, the source tree is available at: > > > > > >https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/tree/dtoc-working > > > > > > Comments welcome! > > > > So here's my worry. It's not clear, aside from the device tree, how > > much re-use of existing code we get with this. It feels like it might > > be fairly minimal. And at that point, are we not perhaps making too > > much work for ourselves compared with just excepting that there will > > need to be a place for non-abstracted-framework drivers? What do we do > > about TPL, when we get to the point of everything being converted to DM > > and as-needed tiny-DM but there's still TPL drivers? The reason we have > > SPL_FRAMEWORK as a symbol today is that we already had some > > SoCs/architectures (primarily PowerPC) that had "SPL" but it was very > > centric to the SoCs in question. > > > > The interface for example for mmc is: > > int spl_mmc_load_image(struct spl_image_info *spl_image, struct > > spl_boot_device *bootdev) and neither part of that is inherently DM. So > > let it be MMC_TINY for the non-DM case and regular DM_MMC for the DM > > case. I wonder if we could clean that up code a little if we let it be > > separate. > > > > The interface for example for spi is: > > int spl_spi_load_image(struct spl_image_info *spl_image, > > struct spl_boot_device *bootdev) and well, the same thing. Or maybe we > > can even push that up to the spi_flash_load() call. > > > > But my worry is that a different set of abstractions here are still > > going to bring us in more overhead than writing drivers for the > > functionality we need directly, and if we define what's allowed in this > > limited case well, that might be good enough. > > Some boards (e.g. x86) Need to read multiple things from the SPI flash > (such as FSP binaries), so I still think we will want a generic > reading interface. > > You could be right, but my hunch is that there is value in having > things more generic and the cost should be minimal. The value is that > hopefully writing a few C functions in the SPI driver will be enough > to enable tiny SPI on an SoC, reusing much of the code in the driver > (only the reading bits!). We won't need as much special-case code and > an entirely different way of configuring these devices for TPL/SPL. > > It has been interesting digging into the Zephyr model. It's drivers > are very basic and thus small. But there is still value in using the > device tree to assemble things. > > Anyway I'm not really sure at this point. It is just a hunch. I don't > think we can know all this until we have a bit more information. > Perhaps with a board with SPI, MMC and serial converted we would get a > better picture? I think it's absolutely the case that we'll have to convert something and see how it looks, then convert something else and see if it still looks good enough. At a high enough level there's not really too much of a difference between what it sounds like you're proposing and what I'm proposing. Possibly even in a progmatic way too. We have (I think anyhow) fairly static board configurations in this case so we don't so much need to "probe" for possible drivers be told what our device hierarchy is and to initialize what we're going to use. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/2] spl: add fixed memory node in target fdt also when loading ATF
> On 25.05.2020, at 19:57, Heiko Stuebner wrote: > > From: Heiko Stuebner > > In a loading chain SPL -> ATF (->OP-TEE) -> U-Boot, ATF and a subsequent > OP-TEE will re-use the same fdt as the U-Boot target and may need the > information about usable memory ranges. > > Especially OP-TEE needs this to initialize dynamic shared memory > (the only type U-Boot implements when talking to OP-TEE). > > So allow spl_fixup_fdt() to take a fdt_blob argument, falling back to > the existing CONFIG_SYS_SPL_ARGS_ADDR if needed and call it from the > ATF path as well. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Kever Yang Reviewed-by: Philipp Tomsich
altera intel cyclone v / error: enabling full line of zeros but not enabled in Cortex-A9
hi, i have an error message booting linux kernel v4.15 with the u-boot v2020.01 on an cylcone v with arm core. the error message is: L2C-310: enabling full line of zeros but not enabled in Cortex-A9, that is not a warning or an message it is an error. before the update to the version v2020.01, we use the version v2017.09. i get the following message: L2C-310 full line of zeros enabled for Cortex-A9, no error message. we use our own board with an altera cyclone v, i try severall default configs, i got the same error. it is very hard to find the source code to enable the full line support in u-boot. 8.2.3. Write full line of zeros Setting bit [3] of the ACTLR enables this feature. can somebody help me? thanks a lot
Re: [PATCH v5 4/8] lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop()
> On 22.05.2020, at 16:19, Heiko Stuebner wrote: > > From: Heiko Stuebner > > When calculating rrtmp/rr rsa_gen_key_prop() tries to make > (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and > (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] > with rlen being num_bits * 2 > > On a 4096bit key this comes down to to 257 uint32_t elements > in rr and 256 elements in rrtmp but with the current allocation > rr and rrtmp only have 129 uint32_t elements. > > On 2048bit keys this works by chance as the defined max_rsa_size=4096 > allocates a suitable number of elements, but with an actual 4096bit key > this results in other memory parts getting overwritten. > > so double the number of elements in rr and rrtmp so that it matches > the needed number and should increase nicely if max_rsa_size gets > increased in the future. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH] RFC: tiny-dm: Proposal for using driver model in SPL
Hi Tom, On Mon, 25 May 2020 at 13:47, Tom Rini wrote: > > On Mon, May 25, 2020 at 09:35:44AM -0600, Simon Glass wrote: > > > This patch provides the documentation for a proposed enhancement to driver > > model to reduce overhead in SPL. > > > > The actual patches are not included here because they are based on some > > pending work by Walter Lozano which is not in final form. > > > > For now, the source tree is available at: > > > >https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/tree/dtoc-working > > > > Comments welcome! > > So here's my worry. It's not clear, aside from the device tree, how > much re-use of existing code we get with this. It feels like it might > be fairly minimal. And at that point, are we not perhaps making too > much work for ourselves compared with just excepting that there will > need to be a place for non-abstracted-framework drivers? What do we do > about TPL, when we get to the point of everything being converted to DM > and as-needed tiny-DM but there's still TPL drivers? The reason we have > SPL_FRAMEWORK as a symbol today is that we already had some > SoCs/architectures (primarily PowerPC) that had "SPL" but it was very > centric to the SoCs in question. > > The interface for example for mmc is: > int spl_mmc_load_image(struct spl_image_info *spl_image, struct > spl_boot_device *bootdev) and neither part of that is inherently DM. So > let it be MMC_TINY for the non-DM case and regular DM_MMC for the DM > case. I wonder if we could clean that up code a little if we let it be > separate. > > The interface for example for spi is: > int spl_spi_load_image(struct spl_image_info *spl_image, > struct spl_boot_device *bootdev) and well, the same thing. Or maybe we > can even push that up to the spi_flash_load() call. > > But my worry is that a different set of abstractions here are still > going to bring us in more overhead than writing drivers for the > functionality we need directly, and if we define what's allowed in this > limited case well, that might be good enough. Some boards (e.g. x86) Need to read multiple things from the SPI flash (such as FSP binaries), so I still think we will want a generic reading interface. You could be right, but my hunch is that there is value in having things more generic and the cost should be minimal. The value is that hopefully writing a few C functions in the SPI driver will be enough to enable tiny SPI on an SoC, reusing much of the code in the driver (only the reading bits!). We won't need as much special-case code and an entirely different way of configuring these devices for TPL/SPL. It has been interesting digging into the Zephyr model. It's drivers are very basic and thus small. But there is still value in using the device tree to assemble things. Anyway I'm not really sure at this point. It is just a hunch. I don't think we can know all this until we have a bit more information. Perhaps with a board with SPI, MMC and serial converted we would get a better picture? Regards, Simon
[RFC PATCH] imx: skip unused compatible strings in drivers
Converting to DM increases binary size and breaks building some
boards (i.e. tbs2910, gcc 9.2). The approach to address this issue
via cutting off unused properties/nodes in device tree via custom
u-boot.dtsi was not welcome, even if the affected boards do not
pass the built-in device tree to the kernel. Try to drop not
required compatible strings in drivers when building for different
iMX variants. This saves a few bytes when building for i.MX6, with
current buildman default GCC 9.2:
all -843.0 bss +8.0 data -40.0 rodata -547.0 text -264.0
Signed-off-by: Anatolij Gustschin
Cc: Heiko Schocher
Cc: Peng Fan
Cc: Joe Hershberger
Cc: Lukasz Majewski
Cc: Marek Vasut
Cc: Stefano Babic
---
drivers/i2c/mxc_i2c.c | 3 +++
drivers/mmc/fsl_esdhc_imx.c| 18 ++
drivers/net/fec_mxc.c | 16
drivers/pinctrl/nxp/pinctrl-imx6.c | 14 ++
drivers/serial/serial_mxc.c| 10 ++
5 files changed, 61 insertions(+)
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 3b0d27e6cd..abef9d888e 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -1058,7 +1058,10 @@ static const struct dm_i2c_ops mxc_i2c_ops = {
static const struct udevice_id mxc_i2c_ids[] = {
{ .compatible = "fsl,imx21-i2c", },
+#if defined(CONFIG_VF610) || defined(CONFIG_FSL_LSCH2) || \
+defined(CONFIG_FSL_LSCH3) || defined(CONFIG_ARCH_LS1021A)
{ .compatible = "fsl,vf610-i2c", .data = I2C_QUIRK_FLAG, },
+#endif
{}
};
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index 588d6a9d76..6943e4867e 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -1601,31 +1601,49 @@ static const struct dm_mmc_ops fsl_esdhc_ops = {
};
#endif
+#if defined(CONFIG_ARCH_MX7)
static struct esdhc_soc_data usdhc_imx7d_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
| ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
| ESDHC_FLAG_HS400,
};
+#endif
+#if defined(CONFIG_ARCH_IMX8) || defined(CONFIG_ARCH_IMX8M)
static struct esdhc_soc_data usdhc_imx8qm_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING |
ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200 |
ESDHC_FLAG_HS400 | ESDHC_FLAG_HS400_ES,
};
+#endif
static const struct udevice_id fsl_esdhc_ids[] = {
+#ifdef CONFIG_ARCH_MX5
{ .compatible = "fsl,imx53-esdhc", },
+#endif
+#ifdef CONFIG_ARCH_MX6
{ .compatible = "fsl,imx6ul-usdhc", },
{ .compatible = "fsl,imx6sx-usdhc", },
{ .compatible = "fsl,imx6sl-usdhc", },
{ .compatible = "fsl,imx6q-usdhc", },
+#endif
+#ifdef CONFIG_ARCH_MX7
{ .compatible = "fsl,imx7d-usdhc", .data = (ulong)_imx7d_data,},
+#endif
+#ifdef CONFIG_ARCH_MX7ULP
{ .compatible = "fsl,imx7ulp-usdhc", },
+#endif
+#ifdef CONFIG_ARCH_IMX8
{ .compatible = "fsl,imx8qm-usdhc", .data = (ulong)_imx8qm_data,},
+#endif
+#ifdef CONFIG_ARCH_IMX8M
{ .compatible = "fsl,imx8mm-usdhc", .data = (ulong)_imx8qm_data,},
{ .compatible = "fsl,imx8mn-usdhc", .data = (ulong)_imx8qm_data,},
{ .compatible = "fsl,imx8mq-usdhc", .data = (ulong)_imx8qm_data,},
+#endif
+#ifdef CONFIG_ARCH_IMXRT
{ .compatible = "fsl,imxrt-usdhc", },
+#endif
{ .compatible = "fsl,esdhc", },
{ /* sentinel */ }
};
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 9ae2db033e..d829b5b5ba 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -1574,14 +1574,30 @@ static int fecmxc_ofdata_to_platdata(struct udevice
*dev)
}
static const struct udevice_id fecmxc_ids[] = {
+#ifdef CONFIG_ARCH_MX28
{ .compatible = "fsl,imx28-fec" },
+#endif
+#ifdef CONFIG_ARCH_MX6
{ .compatible = "fsl,imx6q-fec" },
+#endif
+#ifdef CONFIG_MX6SL
{ .compatible = "fsl,imx6sl-fec" },
+#endif
+#ifdef CONFIG_MX6SX
{ .compatible = "fsl,imx6sx-fec" },
+#endif
+#ifdef CONFIG_MX6UL
{ .compatible = "fsl,imx6ul-fec" },
+#endif
+#ifdef CONFIG_ARCH_MX5
{ .compatible = "fsl,imx53-fec" },
+#endif
+#ifdef CONFIG_ARCH_MX7
{ .compatible = "fsl,imx7d-fec" },
+#endif
+#ifdef CONFIG_ARCH_VF610
{ .compatible = "fsl,mvf600-fec" },
+#endif
{ }
};
diff --git a/drivers/pinctrl/nxp/pinctrl-imx6.c
b/drivers/pinctrl/nxp/pinctrl-imx6.c
index aafa3057ad..dff4954344 100644
--- a/drivers/pinctrl/nxp/pinctrl-imx6.c
+++ b/drivers/pinctrl/nxp/pinctrl-imx6.c
@@ -12,14 +12,18 @@
static struct imx_pinctrl_soc_info imx6_pinctrl_soc_info __section(".data");
+#ifdef CONFIG_MX6UL
/* FIXME Before reloaction, BSS is overlapped with DT area */
static struct imx_pinctrl_soc_info imx6ul_pinctrl_soc_info = {
.flags = ZERO_OFFSET_VALID,
};
+#endif
+#if defined(CONFIG_MX6SLL) || defined(CONFIG_MX6ULL)
static struct imx_pinctrl_soc_info imx6_snvs_pinctrl_soc_info = {
.flags = ZERO_OFFSET_VALID,
};
[PATCH 2/4] x86: apl: Add hex offsets for registers in FSP-M
When comparing hex dumps it is useful to see the offsets of the registers.
Add them in where they correspond to a multiple of 16.
Possibly it would be useful to have a a command to output the FSP values
in human-readable form, making use of the fsp_bindings implementation.
Signed-off-by: Simon Glass
---
.../include/asm/arch-apollolake/fsp/fsp_m_upd.h | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/arch-apollolake/fsp/fsp_m_upd.h
b/arch/x86/include/asm/arch-apollolake/fsp/fsp_m_upd.h
index a77964f30c..e9be66e5b6 100644
--- a/arch/x86/include/asm/arch-apollolake/fsp/fsp_m_upd.h
+++ b/arch/x86/include/asm/arch-apollolake/fsp/fsp_m_upd.h
@@ -34,7 +34,14 @@ struct __packed fsp_ram_channel {
u8 odt_levels;
};
+/* struct fsp_m_config - FSP-M configuration
+ *
+ * Note that headers precede this and are 64 bytes long. The hex offsets
+ * mentioned in this file are relative to the start of the header, the same
+ * convention used in Intel's APL FSP header file.
+ */
struct __packed fsp_m_config {
+ /* 40 */
u32 serial_debug_port_address;
u8 serial_debug_port_type;
u8 serial_debug_port_device;
@@ -49,6 +56,7 @@ struct __packed fsp_m_config {
u8 profile;
u8 memory_down;
+ /* 50 */
u8 ddr3_l_page_size;
u8 ddr3_lasr;
u8 scrambler_support;
@@ -62,6 +70,7 @@ struct __packed fsp_m_config {
u16 memory_size_limit;
u16 low_memory_max_value;
+ /* 60 */
u16 high_memory_max_value;
u8 disable_fast_boot;
u8 dimm0_spd_address;
@@ -73,6 +82,7 @@ struct __packed fsp_m_config {
u32 msg_level_mask;
u8 unused_upd_space0[4];
+ /* 110 */
u8 pre_mem_gpio_table_pin_num[4];
u32 pre_mem_gpio_table_ptr;
u8 pre_mem_gpio_table_entry_num;
@@ -81,8 +91,10 @@ struct __packed fsp_m_config {
u8 mrc_data_saving;
u32 oem_loading_base;
+ /* 120 */
u8 oem_file_name[16];
+ /* 130 */
void*mrc_boot_data_ptr;
u8 e_mmc_trace_len;
u8 skip_cse_rbp;
@@ -94,20 +106,20 @@ struct __packed fsp_m_config {
u8 msc1_wrap;
u32 msc0_size;
+ /* 140 */
u32 msc1_size;
u8 pti_mode;
u8 pti_training;
u8 pti_speed;
u8 punit_mlvl;
-
u8 pmc_mlvl;
u8 sw_trace_en;
u8 periodic_retraining_disable;
u8 enable_reset_system;
-
u8 enable_s3_heci2;
u8 unused_upd_space1[3];
+ /* 150 */
void*variable_nvs_buffer_ptr;
u8 reserved_fspm_upd[12];
};
--
2.27.0.rc0.183.gde8f92d652-goog
[PATCH 1/4] x86: coral: Correct some FSP-M settings
Some settings were modified slightly in the device-tree conversion. Return
these to their original values.
Signed-off-by: Simon Glass
---
arch/x86/dts/chromebook_coral.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/dts/chromebook_coral.dts
b/arch/x86/dts/chromebook_coral.dts
index aad12f2c4d..5ee056fc95 100644
--- a/arch/x86/dts/chromebook_coral.dts
+++ b/arch/x86/dts/chromebook_coral.dts
@@ -517,6 +517,11 @@
20 23 22 21 18 19 16 17
/* DQB[7:15] pins of LPDDR4 module with offset of 16 */
25 28 30 31 26 27 24 29>;
+
+ fspm,dimm0-spd-address = <0>;
+ fspm,dimm1-spd-address = <0>;
+ fspm,skip-cse-rbp = <1>;
+ fspm,enable-s3-heci2 = <0>;
};
_s {
--
2.27.0.rc0.183.gde8f92d652-goog
[PATCH 3/4] x86: coral: Correct some FSP-S settings
Some settings were modified slightly in the device-tree conversion. Return these to their original values. This makes WiFi work again. Signed-off-by: Simon Glass --- arch/x86/dts/chromebook_coral.dts | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/x86/dts/chromebook_coral.dts b/arch/x86/dts/chromebook_coral.dts index 5ee056fc95..a17a9c2800 100644 --- a/arch/x86/dts/chromebook_coral.dts +++ b/arch/x86/dts/chromebook_coral.dts @@ -600,13 +600,9 @@ fsps,emmc-rx-cmd-data-cntl1 = <0x00181717>; fsps,emmc-rx-cmd-data-cntl2 = <0x10008>; - /* Enable Audio Clock and Power gating */ - fsps,hd-audio-clk-gate = <1>; - fsps,hd-audio-pwr-gate = <1>; - fsps,bios-cfg-lock-down = <1>; - - /* Enable lpss s0ix */ - fsps,lpss-s0ix-enable = <1>; + /* Enable WiFi */ + fsps,pcie-root-port-en = [01 00 00 00 00 00]; + fsps,pcie-rp-hot-plug = [00 00 00 00 00 00]; fsps,skip-mp-init = <1>; fsps,spi-eiss = <0>; -- 2.27.0.rc0.183.gde8f92d652-goog
[PATCH 4/4] x86: apl: Add hex offsets for registers in FSP-S
When comparing hex dumps it is useful to see the offsets of the registers.
Add them in where they correspond to a multiple of 16.
Possibly it would be useful to have a a command to output the FSP values
in human-readable form, making use of the fsp_bindings implementation.
Signed-off-by: Simon Glass
---
.../asm/arch-apollolake/fsp/fsp_s_upd.h | 71 +++
1 file changed, 71 insertions(+)
diff --git a/arch/x86/include/asm/arch-apollolake/fsp/fsp_s_upd.h
b/arch/x86/include/asm/arch-apollolake/fsp/fsp_s_upd.h
index 87596ffd9d..f9c3985c47 100644
--- a/arch/x86/include/asm/arch-apollolake/fsp/fsp_s_upd.h
+++ b/arch/x86/include/asm/arch-apollolake/fsp/fsp_s_upd.h
@@ -9,7 +9,14 @@
#ifndef __ASSEMBLY__
#include
+/* struct fsp_s_config - FSP-S configuration
+ *
+ * Note that struct fsp_upd_header preceeds this and is 32 bytes long. The
+ * hex offsets mentioned in this file are relative to the start of the header,
+ * the same convention used in Intel's APL FSP header file.
+ */
struct __packed fsp_s_config {
+ /* 20 */
u8 active_processor_cores;
u8 disable_core1;
u8 disable_core2;
@@ -26,6 +33,8 @@ struct __packed fsp_s_config {
u8 c_state_auto_demotion;
u8 c_state_un_demotion;
u8 max_core_c_state;
+
+ /* 30 */
u8 pkg_c_state_demotion;
u8 pkg_c_state_un_demotion;
u8 turbo_mode;
@@ -36,6 +45,8 @@ struct __packed fsp_s_config {
u8 ipu_acpi_mode;
u8 force_wake;
u32 gtt_mm_adr;
+
+ /* 40 */
u32 gm_adr;
u8 pavp_lock;
u8 graphics_freq_modify;
@@ -49,6 +60,8 @@ struct __packed fsp_s_config {
u8 power_gating;
u8 unit_level_clock_gating;
u8 fast_boot;
+
+ /* 50 */
u8 dyn_sr;
u8 sa_ipu_enable;
u8 pm_support;
@@ -56,6 +69,8 @@ struct __packed fsp_s_config {
u32 logo_size;
u32 logo_ptr;
u32 graphics_config_ptr;
+
+ /* 60 */
u8 pavp_enable;
u8 pavp_pr3;
u8 cd_clock;
@@ -78,6 +93,8 @@ struct __packed fsp_s_config {
u8 hda_enable;
u8 dsp_enable;
u8 pme;
+
+ /* 90 */
u8 hd_audio_io_buffer_ownership;
u8 hd_audio_io_buffer_voltage;
u8 hd_audio_vc_type;
@@ -94,6 +111,8 @@ struct __packed fsp_s_config {
u8 hmt;
u8 hd_audio_pwr_gate;
u8 hd_audio_clk_gate;
+
+ /* a0 */
u32 dsp_feature_mask;
u32 dsp_pp_module_mask;
u8 bios_cfg_lock_down;
@@ -104,6 +123,8 @@ struct __packed fsp_s_config {
u8 hpet_function_number;
u8 io_apic_bdf_valid;
u8 io_apic_bus_number;
+
+ /* b0 */
u8 io_apic_device_number;
u8 io_apic_function_number;
u8 io_apic_entry24_119;
@@ -124,6 +145,8 @@ struct __packed fsp_s_config {
u8 i2c2_enable;
u8 i2c3_enable;
u8 i2c4_enable;
+
+ /* d0 */
u8 i2c5_enable;
u8 i2c6_enable;
u8 i2c7_enable;
@@ -137,6 +160,8 @@ struct __packed fsp_s_config {
u8 os_dbg_enable;
u8 dci_en;
u32 uart2_kernel_debug_base_address;
+
+ /* e0 */
u8 pcie_clock_gating_disabled;
u8 pcie_root_port8xh_decode;
u8 pcie8xh_decode_port_index;
@@ -150,6 +175,8 @@ struct __packed fsp_s_config {
u8 pcie_rp_pm_sci[6];
u8 pcie_rp_ext_sync[6];
u8 pcie_rp_transmitter_half_swing[6];
+
+ /* 110 */
u8 pcie_rp_acs_enabled[6];
u8 pcie_rp_clk_req_supported[6];
u8 pcie_rp_clk_req_number[6];
@@ -158,6 +185,8 @@ struct __packed fsp_s_config {
u8 pme_interrupt[6];
u8 unsupported_request_report[6];
u8 fatal_error_report[6];
+
+ /* 140 */
u8 no_fatal_error_report[6];
u8 correctable_error_report[6];
u8 system_error_on_fatal_error[6];
@@ -166,6 +195,8 @@ struct __packed fsp_s_config {
u8 pcie_rp_speed[6];
u8 physical_slot_number[6];
u8 pcie_rp_completion_timeout[6];
+
+ /* 170 */
u8 ptm_enable[6];
u8 pcie_rp_aspm[6];
u8 pcie_rp_l1_substates[6];
@@ -173,6 +204,8 @@ struct __packed fsp_s_config {
u8 pcie_rp_ltr_config_lock[6];
u8 pme_b0_s5_dis;
u8 pci_clock_run;
+
+ /* 190 */
u8 timer8254_clk_setting;
u8 enable_sata;
u8 sata_mode;
@@ -185,6 +218,8 @@ struct __packed fsp_s_config {
u8 sata_ports_dev_slp[2];
u8 sata_ports_hot_plug[2];
u8 sata_ports_interlock_sw[2];
+
+ /* 1a0 */
u8
Re: [U-Boot] is it mandatory for SPL to support DM
On Mon, May 25, 2020 at 09:59:32PM +0200, Marek Vasut wrote:
> On 5/25/20 9:55 PM, Tom Rini wrote:
> > On Mon, May 25, 2020 at 09:48:29PM +0200, Marek Vasut wrote:
> >> On 5/25/20 9:28 PM, Tom Rini wrote:
> >>> On Mon, May 25, 2020 at 09:07:54PM +0200, Marek Vasut wrote:
> On 5/25/20 7:32 PM, Tom Rini wrote:
> > On Mon, May 25, 2020 at 10:58:12PM +0530, Jagan Teki wrote:
> >> On Mon, May 25, 2020 at 9:06 PM Simon Glass wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Mon, 25 May 2020 at 04:35, Marek Vasut wrote:
>
> On 5/25/20 10:44 AM, Jagan Teki wrote:
> > SPL has a foot-print constraint, so fully switching a particular
> > subsystem like SPI or SPI Flash to DM would increase the size of it.
> >
> > Possible areas to look at are (assume SPL_DM supported)
> > 1) platdata
> > 2) implement board or platform specific spl device driver which
> > bypassed the actual framework ex: spl_spi_sunxi.c
> >
> > Do we have any other solutions? or any arguments on above step 2?
>
> SPL does not need to support DM until the size problem is solved.
> >>>
> >>> I don't think the problem will ever be 'solved'. It is an ongoing
> >>> battle.
> >>>
> >>> But as it happens I've just sent a proposal for tiny-dm that I think
> >>> will help.
> >>>
> >>> Jagan, which board are you trying to convert? If you are trying to
> >>> convert SPI flash, I think we need to remove the legacy code first.
> >>
> >> These are the partially dm converted drivers, so boards which are
> >> using can eventually need a dm spi switch.
> >>
> >> drivers/spi/fsl_dspi.c
> >> drivers/spi/kirkwood_spi.c
> >> drivers/spi/mxc_spi.c
> >> drivers/spi/mxs_spi.c
> >> drivers/spi/omap3_spi.c
> >> drivers/spi/sh_qspi.c
> >>
> >> I'm looking for proper options along with removal of some legacy code,
> >> and tiny-dm.
> >
> > For the number of about to be year past published deadline (which has
> > been extended at times to get to that point even) boards, I think we
> > need to start by dropping boards. Then we can see what makes sense
> > moving forward.
>
> At least mxc_spi and sh_qspi must stay, since those are heavily used in
> embedded/industrial/automotive.
> >>>
> >>> So, this brings us back to the main topic of this thread. Both of the
> >>> drivers you mention ARE converted to DM, but cannot fit adding DM to
> >>> SPL. Where do we put non-DM SPL code as we have real size constraints
> >>> in SPL/TPL? I should bring this up in Simon's new thread too, but I
> >>> wonder if we shouldn't just make drivers/spl/{mmc,spi,xxx}/ and have the
> >>> non-DM-framework drivers for SPL reside somewhere and move on. The
> >>> notions of "we have a nice abstract framework" and "we need to be as
> >>> small as possible" can and do conflict.
> >>
> >> But then how do you propose to keep sharing code between the two worlds?
> >
> > Sharing defines is easy. Sharing information buried in the device tree
> > requires some of the dtoc changes either in progress or variations on
> > them. Sharing other functionality? Depends on what fits well
> > (logically) in inline functions. But I don't see some duplication of
> > either functional (i.e. read()/write()) nor initialization code as a
> > hard blocker.
> >
> > But the only choice that doesn't have some duplication of code would be
> > "throw out current DM, replace with a new DM that's small enough in all
> > cases". And we're at a few years now of "DM is too big and bloaty!"
> > without "here are my patches to slim down DM for all cases".
>
> Surely the functionality to control/access hardware can be shared ?
> See tiny-mmc for example.
Yes, it can. Lets move over to the other thread where I call that out
as a good example.
--
Tom
signature.asc
Description: PGP signature
Re: [U-Boot] is it mandatory for SPL to support DM
On 5/25/20 9:55 PM, Tom Rini wrote:
> On Mon, May 25, 2020 at 09:48:29PM +0200, Marek Vasut wrote:
>> On 5/25/20 9:28 PM, Tom Rini wrote:
>>> On Mon, May 25, 2020 at 09:07:54PM +0200, Marek Vasut wrote:
On 5/25/20 7:32 PM, Tom Rini wrote:
> On Mon, May 25, 2020 at 10:58:12PM +0530, Jagan Teki wrote:
>> On Mon, May 25, 2020 at 9:06 PM Simon Glass wrote:
>>>
>>> Hi,
>>>
>>> On Mon, 25 May 2020 at 04:35, Marek Vasut wrote:
On 5/25/20 10:44 AM, Jagan Teki wrote:
> SPL has a foot-print constraint, so fully switching a particular
> subsystem like SPI or SPI Flash to DM would increase the size of it.
>
> Possible areas to look at are (assume SPL_DM supported)
> 1) platdata
> 2) implement board or platform specific spl device driver which
> bypassed the actual framework ex: spl_spi_sunxi.c
>
> Do we have any other solutions? or any arguments on above step 2?
SPL does not need to support DM until the size problem is solved.
>>>
>>> I don't think the problem will ever be 'solved'. It is an ongoing
>>> battle.
>>>
>>> But as it happens I've just sent a proposal for tiny-dm that I think
>>> will help.
>>>
>>> Jagan, which board are you trying to convert? If you are trying to
>>> convert SPI flash, I think we need to remove the legacy code first.
>>
>> These are the partially dm converted drivers, so boards which are
>> using can eventually need a dm spi switch.
>>
>> drivers/spi/fsl_dspi.c
>> drivers/spi/kirkwood_spi.c
>> drivers/spi/mxc_spi.c
>> drivers/spi/mxs_spi.c
>> drivers/spi/omap3_spi.c
>> drivers/spi/sh_qspi.c
>>
>> I'm looking for proper options along with removal of some legacy code,
>> and tiny-dm.
>
> For the number of about to be year past published deadline (which has
> been extended at times to get to that point even) boards, I think we
> need to start by dropping boards. Then we can see what makes sense
> moving forward.
At least mxc_spi and sh_qspi must stay, since those are heavily used in
embedded/industrial/automotive.
>>>
>>> So, this brings us back to the main topic of this thread. Both of the
>>> drivers you mention ARE converted to DM, but cannot fit adding DM to
>>> SPL. Where do we put non-DM SPL code as we have real size constraints
>>> in SPL/TPL? I should bring this up in Simon's new thread too, but I
>>> wonder if we shouldn't just make drivers/spl/{mmc,spi,xxx}/ and have the
>>> non-DM-framework drivers for SPL reside somewhere and move on. The
>>> notions of "we have a nice abstract framework" and "we need to be as
>>> small as possible" can and do conflict.
>>
>> But then how do you propose to keep sharing code between the two worlds?
>
> Sharing defines is easy. Sharing information buried in the device tree
> requires some of the dtoc changes either in progress or variations on
> them. Sharing other functionality? Depends on what fits well
> (logically) in inline functions. But I don't see some duplication of
> either functional (i.e. read()/write()) nor initialization code as a
> hard blocker.
>
> But the only choice that doesn't have some duplication of code would be
> "throw out current DM, replace with a new DM that's small enough in all
> cases". And we're at a few years now of "DM is too big and bloaty!"
> without "here are my patches to slim down DM for all cases".
Surely the functionality to control/access hardware can be shared ?
See tiny-mmc for example.
Re: [U-Boot] is it mandatory for SPL to support DM
On Mon, May 25, 2020 at 09:48:29PM +0200, Marek Vasut wrote:
> On 5/25/20 9:28 PM, Tom Rini wrote:
> > On Mon, May 25, 2020 at 09:07:54PM +0200, Marek Vasut wrote:
> >> On 5/25/20 7:32 PM, Tom Rini wrote:
> >>> On Mon, May 25, 2020 at 10:58:12PM +0530, Jagan Teki wrote:
> On Mon, May 25, 2020 at 9:06 PM Simon Glass wrote:
> >
> > Hi,
> >
> > On Mon, 25 May 2020 at 04:35, Marek Vasut wrote:
> >>
> >> On 5/25/20 10:44 AM, Jagan Teki wrote:
> >>> SPL has a foot-print constraint, so fully switching a particular
> >>> subsystem like SPI or SPI Flash to DM would increase the size of it.
> >>>
> >>> Possible areas to look at are (assume SPL_DM supported)
> >>> 1) platdata
> >>> 2) implement board or platform specific spl device driver which
> >>> bypassed the actual framework ex: spl_spi_sunxi.c
> >>>
> >>> Do we have any other solutions? or any arguments on above step 2?
> >>
> >> SPL does not need to support DM until the size problem is solved.
> >
> > I don't think the problem will ever be 'solved'. It is an ongoing
> > battle.
> >
> > But as it happens I've just sent a proposal for tiny-dm that I think
> > will help.
> >
> > Jagan, which board are you trying to convert? If you are trying to
> > convert SPI flash, I think we need to remove the legacy code first.
>
> These are the partially dm converted drivers, so boards which are
> using can eventually need a dm spi switch.
>
> drivers/spi/fsl_dspi.c
> drivers/spi/kirkwood_spi.c
> drivers/spi/mxc_spi.c
> drivers/spi/mxs_spi.c
> drivers/spi/omap3_spi.c
> drivers/spi/sh_qspi.c
>
> I'm looking for proper options along with removal of some legacy code,
> and tiny-dm.
> >>>
> >>> For the number of about to be year past published deadline (which has
> >>> been extended at times to get to that point even) boards, I think we
> >>> need to start by dropping boards. Then we can see what makes sense
> >>> moving forward.
> >>
> >> At least mxc_spi and sh_qspi must stay, since those are heavily used in
> >> embedded/industrial/automotive.
> >
> > So, this brings us back to the main topic of this thread. Both of the
> > drivers you mention ARE converted to DM, but cannot fit adding DM to
> > SPL. Where do we put non-DM SPL code as we have real size constraints
> > in SPL/TPL? I should bring this up in Simon's new thread too, but I
> > wonder if we shouldn't just make drivers/spl/{mmc,spi,xxx}/ and have the
> > non-DM-framework drivers for SPL reside somewhere and move on. The
> > notions of "we have a nice abstract framework" and "we need to be as
> > small as possible" can and do conflict.
>
> But then how do you propose to keep sharing code between the two worlds?
Sharing defines is easy. Sharing information buried in the device tree
requires some of the dtoc changes either in progress or variations on
them. Sharing other functionality? Depends on what fits well
(logically) in inline functions. But I don't see some duplication of
either functional (i.e. read()/write()) nor initialization code as a
hard blocker.
But the only choice that doesn't have some duplication of code would be
"throw out current DM, replace with a new DM that's small enough in all
cases". And we're at a few years now of "DM is too big and bloaty!"
without "here are my patches to slim down DM for all cases".
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] RFC: tiny-dm: Proposal for using driver model in SPL
On Mon, May 25, 2020 at 09:35:44AM -0600, Simon Glass wrote: > This patch provides the documentation for a proposed enhancement to driver > model to reduce overhead in SPL. > > The actual patches are not included here because they are based on some > pending work by Walter Lozano which is not in final form. > > For now, the source tree is available at: > >https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/tree/dtoc-working > > Comments welcome! So here's my worry. It's not clear, aside from the device tree, how much re-use of existing code we get with this. It feels like it might be fairly minimal. And at that point, are we not perhaps making too much work for ourselves compared with just excepting that there will need to be a place for non-abstracted-framework drivers? What do we do about TPL, when we get to the point of everything being converted to DM and as-needed tiny-DM but there's still TPL drivers? The reason we have SPL_FRAMEWORK as a symbol today is that we already had some SoCs/architectures (primarily PowerPC) that had "SPL" but it was very centric to the SoCs in question. The interface for example for mmc is: int spl_mmc_load_image(struct spl_image_info *spl_image, struct spl_boot_device *bootdev) and neither part of that is inherently DM. So let it be MMC_TINY for the non-DM case and regular DM_MMC for the DM case. I wonder if we could clean that up code a little if we let it be separate. The interface for example for spi is: int spl_spi_load_image(struct spl_image_info *spl_image, struct spl_boot_device *bootdev) and well, the same thing. Or maybe we can even push that up to the spi_flash_load() call. But my worry is that a different set of abstractions here are still going to bring us in more overhead than writing drivers for the functionality we need directly, and if we define what's allowed in this limited case well, that might be good enough. -- Tom signature.asc Description: PGP signature
Re: [U-Boot] is it mandatory for SPL to support DM
On 5/25/20 9:28 PM, Tom Rini wrote:
> On Mon, May 25, 2020 at 09:07:54PM +0200, Marek Vasut wrote:
>> On 5/25/20 7:32 PM, Tom Rini wrote:
>>> On Mon, May 25, 2020 at 10:58:12PM +0530, Jagan Teki wrote:
On Mon, May 25, 2020 at 9:06 PM Simon Glass wrote:
>
> Hi,
>
> On Mon, 25 May 2020 at 04:35, Marek Vasut wrote:
>>
>> On 5/25/20 10:44 AM, Jagan Teki wrote:
>>> SPL has a foot-print constraint, so fully switching a particular
>>> subsystem like SPI or SPI Flash to DM would increase the size of it.
>>>
>>> Possible areas to look at are (assume SPL_DM supported)
>>> 1) platdata
>>> 2) implement board or platform specific spl device driver which
>>> bypassed the actual framework ex: spl_spi_sunxi.c
>>>
>>> Do we have any other solutions? or any arguments on above step 2?
>>
>> SPL does not need to support DM until the size problem is solved.
>
> I don't think the problem will ever be 'solved'. It is an ongoing battle.
>
> But as it happens I've just sent a proposal for tiny-dm that I think will
> help.
>
> Jagan, which board are you trying to convert? If you are trying to
> convert SPI flash, I think we need to remove the legacy code first.
These are the partially dm converted drivers, so boards which are
using can eventually need a dm spi switch.
drivers/spi/fsl_dspi.c
drivers/spi/kirkwood_spi.c
drivers/spi/mxc_spi.c
drivers/spi/mxs_spi.c
drivers/spi/omap3_spi.c
drivers/spi/sh_qspi.c
I'm looking for proper options along with removal of some legacy code,
and tiny-dm.
>>>
>>> For the number of about to be year past published deadline (which has
>>> been extended at times to get to that point even) boards, I think we
>>> need to start by dropping boards. Then we can see what makes sense
>>> moving forward.
>>
>> At least mxc_spi and sh_qspi must stay, since those are heavily used in
>> embedded/industrial/automotive.
>
> So, this brings us back to the main topic of this thread. Both of the
> drivers you mention ARE converted to DM, but cannot fit adding DM to
> SPL. Where do we put non-DM SPL code as we have real size constraints
> in SPL/TPL? I should bring this up in Simon's new thread too, but I
> wonder if we shouldn't just make drivers/spl/{mmc,spi,xxx}/ and have the
> non-DM-framework drivers for SPL reside somewhere and move on. The
> notions of "we have a nice abstract framework" and "we need to be as
> small as possible" can and do conflict.
But then how do you propose to keep sharing code between the two worlds?
[PATCH] video: make vidconsole commands optional
Converting some boards to DM_VIDEO results in build breakage due
to increased code size. Make video console specific commands
optional to recude binary size.
Signed-off-by: Anatolij Gustschin
---
drivers/video/Kconfig | 8
drivers/video/vidconsole-uclass.c | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 28c22fe525..eb5e26644a 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -35,6 +35,14 @@ config BACKLIGHT_GPIO
it understands the standard device tree
(leds/backlight/gpio-backlight.txt)
+config CMD_VIDCONSOLE
+ bool "Enable vidconsole commands lcdputs and setcurs"
+ depends on DM_VIDEO
+ default y
+ help
+ Enabling this will provide 'setcurs' and 'lcdputs' commands which
+ support cursor positioning and drawing strings on video framebuffer.
+
config VIDEO_BPP8
bool "Support 8-bit-per-pixel displays"
depends on DM_VIDEO
diff --git a/drivers/video/vidconsole-uclass.c
b/drivers/video/vidconsole-uclass.c
index d30e6db6f6..901347c467 100644
--- a/drivers/video/vidconsole-uclass.c
+++ b/drivers/video/vidconsole-uclass.c
@@ -613,6 +613,7 @@ UCLASS_DRIVER(vidconsole) = {
.per_device_auto_alloc_size = sizeof(struct vidconsole_priv),
};
+#if CONFIG_IS_ENABLED(CMD_VIDCONSOLE)
void vidconsole_position_cursor(struct udevice *dev, unsigned col, unsigned
row)
{
struct vidconsole_priv *priv = dev_get_uclass_priv(dev);
@@ -673,3 +674,4 @@ U_BOOT_CMD(
"print string on video framebuffer",
""
);
+#endif /* CONFIG_IS_ENABLED(CMD_VIDCONSOLE) */
--
2.17.1
Re: [U-Boot] is it mandatory for SPL to support DM
On Mon, May 25, 2020 at 09:07:54PM +0200, Marek Vasut wrote:
> On 5/25/20 7:32 PM, Tom Rini wrote:
> > On Mon, May 25, 2020 at 10:58:12PM +0530, Jagan Teki wrote:
> >> On Mon, May 25, 2020 at 9:06 PM Simon Glass wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Mon, 25 May 2020 at 04:35, Marek Vasut wrote:
>
> On 5/25/20 10:44 AM, Jagan Teki wrote:
> > SPL has a foot-print constraint, so fully switching a particular
> > subsystem like SPI or SPI Flash to DM would increase the size of it.
> >
> > Possible areas to look at are (assume SPL_DM supported)
> > 1) platdata
> > 2) implement board or platform specific spl device driver which
> > bypassed the actual framework ex: spl_spi_sunxi.c
> >
> > Do we have any other solutions? or any arguments on above step 2?
>
> SPL does not need to support DM until the size problem is solved.
> >>>
> >>> I don't think the problem will ever be 'solved'. It is an ongoing battle.
> >>>
> >>> But as it happens I've just sent a proposal for tiny-dm that I think will
> >>> help.
> >>>
> >>> Jagan, which board are you trying to convert? If you are trying to
> >>> convert SPI flash, I think we need to remove the legacy code first.
> >>
> >> These are the partially dm converted drivers, so boards which are
> >> using can eventually need a dm spi switch.
> >>
> >> drivers/spi/fsl_dspi.c
> >> drivers/spi/kirkwood_spi.c
> >> drivers/spi/mxc_spi.c
> >> drivers/spi/mxs_spi.c
> >> drivers/spi/omap3_spi.c
> >> drivers/spi/sh_qspi.c
> >>
> >> I'm looking for proper options along with removal of some legacy code,
> >> and tiny-dm.
> >
> > For the number of about to be year past published deadline (which has
> > been extended at times to get to that point even) boards, I think we
> > need to start by dropping boards. Then we can see what makes sense
> > moving forward.
>
> At least mxc_spi and sh_qspi must stay, since those are heavily used in
> embedded/industrial/automotive.
So, this brings us back to the main topic of this thread. Both of the
drivers you mention ARE converted to DM, but cannot fit adding DM to
SPL. Where do we put non-DM SPL code as we have real size constraints
in SPL/TPL? I should bring this up in Simon's new thread too, but I
wonder if we shouldn't just make drivers/spl/{mmc,spi,xxx}/ and have the
non-DM-framework drivers for SPL reside somewhere and move on. The
notions of "we have a nice abstract framework" and "we need to be as
small as possible" can and do conflict.
--
Tom
signature.asc
Description: PGP signature
Re: [U-Boot] is it mandatory for SPL to support DM
On 5/25/20 7:32 PM, Tom Rini wrote: > On Mon, May 25, 2020 at 10:58:12PM +0530, Jagan Teki wrote: >> On Mon, May 25, 2020 at 9:06 PM Simon Glass wrote: >>> >>> Hi, >>> >>> On Mon, 25 May 2020 at 04:35, Marek Vasut wrote: On 5/25/20 10:44 AM, Jagan Teki wrote: > SPL has a foot-print constraint, so fully switching a particular > subsystem like SPI or SPI Flash to DM would increase the size of it. > > Possible areas to look at are (assume SPL_DM supported) > 1) platdata > 2) implement board or platform specific spl device driver which > bypassed the actual framework ex: spl_spi_sunxi.c > > Do we have any other solutions? or any arguments on above step 2? SPL does not need to support DM until the size problem is solved. >>> >>> I don't think the problem will ever be 'solved'. It is an ongoing battle. >>> >>> But as it happens I've just sent a proposal for tiny-dm that I think will >>> help. >>> >>> Jagan, which board are you trying to convert? If you are trying to >>> convert SPI flash, I think we need to remove the legacy code first. >> >> These are the partially dm converted drivers, so boards which are >> using can eventually need a dm spi switch. >> >> drivers/spi/fsl_dspi.c >> drivers/spi/kirkwood_spi.c >> drivers/spi/mxc_spi.c >> drivers/spi/mxs_spi.c >> drivers/spi/omap3_spi.c >> drivers/spi/sh_qspi.c >> >> I'm looking for proper options along with removal of some legacy code, >> and tiny-dm. > > For the number of about to be year past published deadline (which has > been extended at times to get to that point even) boards, I think we > need to start by dropping boards. Then we can see what makes sense > moving forward. At least mxc_spi and sh_qspi must stay, since those are heavily used in embedded/industrial/automotive.
Re: [U-Boot] is it mandatory for SPL to support DM
On 5/25/20 6:59 PM, Simon Glass wrote: > Hi Marek, > > On Mon, 25 May 2020 at 09:56, Marek Vasut wrote: >> >> On 5/25/20 5:48 PM, Simon Glass wrote: >>> Hi Marek, >>> >>> On Mon, 25 May 2020 at 09:43, Marek Vasut wrote: On 5/25/20 5:36 PM, Simon Glass wrote: > Hi, > > On Mon, 25 May 2020 at 04:35, Marek Vasut wrote: >> >> On 5/25/20 10:44 AM, Jagan Teki wrote: >>> SPL has a foot-print constraint, so fully switching a particular >>> subsystem like SPI or SPI Flash to DM would increase the size of it. >>> >>> Possible areas to look at are (assume SPL_DM supported) >>> 1) platdata >>> 2) implement board or platform specific spl device driver which >>> bypassed the actual framework ex: spl_spi_sunxi.c >>> >>> Do we have any other solutions? or any arguments on above step 2? >> >> SPL does not need to support DM until the size problem is solved. > > I don't think the problem will ever be 'solved'. It is an ongoing battle. > > But as it happens I've just sent a proposal for tiny-dm that I think will > help. > > Jagan, which board are you trying to convert? If you are trying to > convert SPI flash, I think we need to remove the legacy code first. If you want a board which boots from SPI NOR and has some 14k or so limit on SPL, any of the R-Car Gen2 boards fit the bill. >>> >>> Thanks...do you have a link to one? >> >> https://elinux.org/R-Car/Boards/U-Boot-Gen2 > > I mean a link to buy one...if not too expensive. The links on those > pages all go nowhere. Digikey lists it as a 'non-stock' item. Y-RCAR-E2-SILK-A is probably the one you want then. I got it from Mouser iirc.
[PATCH] rockchip: enable USB OHCI host for RockPro64
U-Boot has video output enabled so time to get keyboard working. => usb reset;usb tree resetting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3a: USB OHCI 1.0 Bus usb@fe3c: USB EHCI 1.00 Bus usb@fe3e: USB OHCI 1.0 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3a for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 1 USB Device(s) found scanning bus usb@fe3e for devices... 3 USB Device(s) found scanning bus dwc3 for devices... cannot reset port 1!? 2 USB Device(s) found scanning usb for storage devices... 2 Storage Device(s) found USB device tree: 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (12 Mb/s, 0mA) U-Boot Root Hub 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (12 Mb/s, 0mA) | U-Boot Root Hub | +-2 Hub (12 Mb/s, 100mA) | ALCOR Generic USB Hub | +-3 Mass Storage (12 Mb/s, 200mA) Kingston DT 101 G2 001478544887BB3157380157 1 Hub (5 Gb/s, 0mA) | U-Boot XHCI Host Controller | +-2 Mass Storage (5 Gb/s, 76mA) ADATA ADATA USB Flash Drive 1520405012240002 Signed-off-by: Marcin Juszkiewicz --- configs/rockpro64-rk3399_defconfig | 2 ++ include/configs/rockpro64_rk3399.h | 2 ++ 2 files changed, 4 insertions(+) diff --git configs/rockpro64-rk3399_defconfig configs/rockpro64-rk3399_defconfig index 53abce0057..205be70cb0 100644 --- configs/rockpro64-rk3399_defconfig +++ configs/rockpro64-rk3399_defconfig @@ -52,6 +52,8 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y diff --git include/configs/rockpro64_rk3399.h include/configs/rockpro64_rk3399.h index 7a72cf6049..37a08b2c00 100644 --- include/configs/rockpro64_rk3399.h +++ include/configs/rockpro64_rk3399.h @@ -17,4 +17,6 @@ #define SDRAM_BANK_SIZE(2UL << 30) +#define CONFIG_USB_OHCI_NEW +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2 #endif -- 2.26.2
Re: [PATCH 1/1] doc: dfu: describe more DFU function
On Sat, May 23, 2020 at 02:24:40PM +0200, Heinrich Schuchardt wrote: > Add some of the missing DFU function descriptions. > > Signed-off-by: Heinrich Schuchardt > Acked-by: Lukasz Majewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] doc: dfu: add DFU to HTML documentation
On Sat, May 23, 2020 at 12:01:08PM +0200, Heinrich Schuchardt wrote: > Add the device firmware update functions to the generated HTML > documentation. > > Signed-off-by: Heinrich Schuchardt > Acked-by: Lukasz Majewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] doc: dfu: fix typos in README.dfu
On Sat, May 23, 2020 at 01:48:07PM +0200, Heinrich Schuchardt wrote: > Fix some typos. > > Signed-off-by: Heinrich Schuchardt > Acked-by: Lukasz Majewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] MAINTAINERS: add dfu.h and dfu.rst to DFU
On Sun, May 24, 2020 at 12:02:14PM +0200, Heinrich Schuchardt wrote: > include/dfu.h and doc/api/dfu.rst belong to the device firmware update > sub-system. So let's add them to DFU in MAINTAINERS. > > Signed-off-by: Heinrich Schuchardt > Acked-by: Lukasz Majewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] doc: dfu: describe eMMC partition number parameter
On Sat, May 23, 2020 at 11:36:49AM +0200, Heinrich Schuchardt wrote: > In dfu_alt_info for eMMC the eMMC partition number can be specified. > > The separator in dfu_alt_info is a semicolon not a comma. > > Signed-off-by: Heinrich Schuchardt > Acked-by: Lukasz Majewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/4] sandbox: move compression option to Kconfig
On Fri, May 22, 2020 at 02:07:38PM +0200, Michael Walle wrote: > CONFIG_BZIP2 and CONFIG_GZIP_COMPRESSED are Kconfig options. Select them > by CONFIG_SANDBOX instead of setting them in configs/sandbox.h. > > Signed-off-by: Michael Walle > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/4] cmd: zip: automatically pull in gzip()
On Fri, May 22, 2020 at 02:07:36PM +0200, Michael Walle wrote: > Move the CONFIG_GZIP_COMPRESSED from a config.h macro to a Kconfig menu > item. It is not selectable by a user because there is no reason to do > so. Instead it will be automatically selected by the stuff which uses > gzip(), like the zip command. > > Remove it from the config_whitelist.txt. Also remove > CONFIG_GZIP_COMPRESS_DEF_SZ as this was never used on any board. The > default seems to be sane, otherwise it should be added as a Kconfig > option. > > Signed-off-by: Michael Walle > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/4] cmd: zip: fix implicit declaration warning
On Fri, May 22, 2020 at 02:07:37PM +0200, Michael Walle wrote: > Fix the following warning: > > cmd/zip.c: In function ‘do_zip’: > cmd/zip.c:30:6: warning: implicit declaration of function ‘gzip’; did you > mean ‘do_zip’? [-Wimplicit-function-declaration] > if (gzip((void *) dst, _len, (void *) src, src_len) != 0) > ^~~~ > do_zip > > Include gzip.h header which declares the gzip() function. > > Signed-off-by: Michael Walle > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] env: Convert ENV_ACCESS_IGNORE_FORCE to Kconfig
On Fri, May 22, 2020 at 01:10:14AM +0200, Marek Vasut wrote: > Convert ENV_ACCESS_IGNORE_FORCE to Kconfig, no functional change. > > Signed-off-by: Marek Vasut > Cc: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] tools/env/fw_env.h: remove env.h
On Thu, May 21, 2020 at 11:22:06PM +0200, Romain Naour wrote: > As reported by Nicolas Carrier on the Buildroot mailing list [1], > there is a new build issue while building a program which interacts with > the u-boot environment. This program uses the headers of the ubootenv > library provided by uboot-tools. > > This is a recent change from uboot [2] adding "#include " to > fw_env.h. Adding env.h require a board configuration to build since > it also include compiler.h (and others uboot internal includes). > > env.h include seems not needed since env_set() is not used in fw_env tool. > > Nicolas removed env.h from fw_env tool and fixed it's build issue. > > This problem is present since uboot v2019.10. > > [1] http://lists.busybox.net/pipermail/buildroot/2020-April/280307.html > [2] > https://gitlab.denx.de/u-boot/u-boot/-/commit/9fb625ce05539fe6876a59ce1dcadb76b33c6f6e > > Reported-by: Nicolas Carrier > Signed-off-by: Romain Naour Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Convert CONFIG_CMD_MMC to Kconfig
On Thu, May 21, 2020 at 04:26:03PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_CMD_MMC > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] cmd: unzip: automatically select CONFIG_GZIP
On Fri, May 22, 2020 at 02:07:35PM +0200, Michael Walle wrote: > unzip calls gzwrite() which is provided in lib/gunzip.c. Make sure it is > automatically pulled in if the user selects CMD_UNZIP. > > Signed-off-by: Michael Walle > Reviewed-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] MAINTAINERS: add doc/driver-model/ to DRIVER MODEL
On Wed, May 20, 2020 at 11:24:52PM +0200, Heinrich Schuchardt wrote: > The documentation should rest with the same maintainer as the code. > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] phy: Fix possible NULL pointer deference
On Wed, May 20, 2020 at 10:35:41PM +0530, Vignesh Raghavendra wrote: > It is possible that users of generic_phy_*() APIs may pass a valid > struct phy pointer but phy->dev can be NULL, leading to NULL pointer > deference in phy_dev_ops(). > > So call generic_phy_valid() to verify that phy and phy->dev are both > valid. > > Signed-off-by: Vignesh Raghavendra Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] armv8: cache_v8: fix mmu_set_region_dcache_behaviour
On Mon, May 11, 2020 at 04:41:07PM +0800, Peng Fan wrote: > enum dcache_option already shift left 2 bits, > PMD_ATTRINDX(option), will wrongly shift left the attr 4bits, which > is wrong. And make the region user set not has expected attribute > and might affect the splitted block region. > > Reviewed-by: Ye Li > Signed-off-by: Peng Fan Please note that I reworded the commit message a bit. In the interest of fixing the bug now: Applied to u-boot/master. But on reading the code and macros to understand things better for the commit message, I wonder why we don't just use options directly now in the code? Thanks! -- Tom signature.asc Description: PGP signature
[PATCH v2 2/2] spl: add fixed memory node in target fdt also when loading ATF
From: Heiko Stuebner
In a loading chain SPL -> ATF (->OP-TEE) -> U-Boot, ATF and a subsequent
OP-TEE will re-use the same fdt as the U-Boot target and may need the
information about usable memory ranges.
Especially OP-TEE needs this to initialize dynamic shared memory
(the only type U-Boot implements when talking to OP-TEE).
So allow spl_fixup_fdt() to take a fdt_blob argument, falling back to
the existing CONFIG_SYS_SPL_ARGS_ADDR if needed and call it from the
ATF path as well.
Signed-off-by: Heiko Stuebner
Reviewed-by: Kever Yang
---
changes in v2:
- dropped changeid
- added Kever's review
common/spl/spl.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index b0f0e1557b..90d8bfd058 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -58,7 +58,8 @@ static bd_t bdata __attribute__ ((section(".data")));
*/
__weak void show_boot_progress(int val) {}
-#if defined(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF)
+#if defined(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF) || \
+defined(CONFIG_SPL_ATF)
/* weak, default platform-specific function to initialize dram banks */
__weak int dram_init_banksize(void)
{
@@ -100,12 +101,14 @@ void __weak spl_perform_fixups(struct spl_image_info
*spl_image)
{
}
-void spl_fixup_fdt(void)
+void spl_fixup_fdt(void *fdt_blob)
{
-#if defined(CONFIG_SPL_OF_LIBFDT) && defined(CONFIG_SYS_SPL_ARGS_ADDR)
- void *fdt_blob = (void *)CONFIG_SYS_SPL_ARGS_ADDR;
+#if defined(CONFIG_SPL_OF_LIBFDT)
int err;
+ if (!fdt_blob)
+ return;
+
err = fdt_check_header(fdt_blob);
if (err < 0) {
printf("fdt_root: %s\n", fdt_strerror(err));
@@ -638,7 +641,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
initr_watchdog();
#endif
- if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF))
+ if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF) ||
+ IS_ENABLED(CONFIG_SPL_ATF))
dram_init_banksize();
bootcount_inc();
@@ -680,6 +684,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
#if CONFIG_IS_ENABLED(ATF)
case IH_OS_ARM_TRUSTED_FIRMWARE:
debug("Jumping to U-Boot via ARM Trusted Firmware\n");
+ spl_fixup_fdt(spl_image.fdt_addr);
spl_invoke_atf(_image);
break;
#endif
@@ -699,7 +704,9 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
#ifdef CONFIG_SPL_OS_BOOT
case IH_OS_LINUX:
debug("Jumping to Linux\n");
- spl_fixup_fdt();
+#if defined(CONFIG_SYS_SPL_ARGS_ADDR)
+ spl_fixup_fdt((void *)CONFIG_SYS_SPL_ARGS_ADDR);
+#endif
spl_board_prepare_for_linux();
jump_to_image_linux(_image);
#endif
--
2.25.1
[PATCH v2 1/2] rockchip: spl: do full dram_init instead of only probing
From: Heiko Stuebner
Parts of later SPL may need RAM information as well, so do full
dram_init() call, which includes the existing dram probing but also
initializes the ram information in gd.
dram_init() from sdram.c does the following steps:
- uclass_get_device(UCLASS_RAM, ...) like the current code
- ret = ram_get_info(dev, );
- gd->ram_size = ram.size;
CONFIG_SPL_RAM already makes sure that sdram.c gets compiled
and thus no other variant of dram_init() can exist.
So it's the same functionality as before and only adds that the
SPL now aquires knowledge about the amount of available ram,
which it didn't know about before.
Signed-off-by: Heiko Stuebner
---
changes in v2:
- dropped changeid
- expanded commit message on how this does not change functionality
arch/arm/mach-rockchip/spl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index 0b76af6080..0eda2c3485 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -135,13 +135,15 @@ void board_init_f(ulong dummy)
/* Init ARM arch timer in arch/arm/cpu/armv7/arch_timer.c */
timer_init();
#endif
-#if !defined(CONFIG_TPL) || defined(CONFIG_SPL_OS_BOOT)
+#if !defined(CONFIG_TPL) || defined(CONFIG_SPL_RAM)
debug("\nspl:init dram\n");
- ret = uclass_get_device(UCLASS_RAM, 0, );
+ ret = dram_init();
if (ret) {
printf("DRAM init failed: %d\n", ret);
return;
}
+ gd->ram_top = gd->ram_base + get_effective_memsize();
+ gd->ram_top = board_get_usable_ram_top(gd->ram_size);
#endif
preloader_console_init();
}
--
2.25.1
Re: [PATCH v4 2/9] usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq
Hi Simon, On 25.05.2020 19:04, Simon Glass wrote: > On Mon, 25 May 2020 at 10:57, Sylwester Nawrocki > wrote: >> On 25.05.2020 16:57, Simon Glass wrote: >>> On Mon, 25 May 2020 at 05:40, Sylwester Nawrocki >>> wrote: There might be hardware configurations where 64-bit data accesses to XHCI registers are not supported properly. This patch removes the readq/writeq so always two 32-bit accesses are used to read/write 64-bit XHCI registers, similarly as it is done in Linux kernel. This patch fixes operation of the XHCI controller on RPI4 Broadcom BCM2711 SoC based board, where the VL805 USB XHCI controller is connected to the PCIe Root Complex, which is attached to the system through the SCB bridge. Even though the architecture is 64-bit the PCIe BAR is 32-bit and likely the 64-bit wide register accesses initiated by the CPU are not properly translated to a sequence of 32-bit PCIe accesses. xhci_readq(), for example, always returns same value in upper and lower 32-bits, e.g. 0xabcd1234abcd1234 instead of 0xabcd1234. >> >>> Then I think this should be done with a quirk flag, enabled for this >>> particular device via the compatible string. It should not be an #if, >>> but an if(). >> >> Thanks for your comments. I will check and see how this could be done. >> It might not be so straightforward since the XHCI controller is a PCI >> device matched by the pci_device_id so we would need to be looking >> at the compatible string of the PCI controller to set the quirk in >> the xhci layer. It's the PCI bridge that introduces the limitation, >> not the VL805 XHCI controller chip. > > OK then it should be modelled as such. > > How is this done in Linux? In Linux simply always two 32-bit accesses are used for 64-bit registers read/write. And the quirks in the generic PCI XHCI driver are based on the PCI vendor and the PCI device ID, so it's not helpful. I couldn't find any reference to the parent PCI bridge there. > You can add a quirk in the PCI controller and then XHCI can check its > parent's platdata to see the flag, perhaps, since the parent will > always be UCLASS_PCI. OK, I imagined something like that. > You can always add the device to the devicetree if needed, and then > you get a compatible string. Will have a look, I wasn't aware we could add a node just for such purpose without negative side effects. -- Regards, Sylwester
Re: [RFC PATCH] mtd: spi: Drop redundent SPI flash driver
On Mon, May 25, 2020 at 10:34 PM Simon Glass wrote: > > Hi Jagan, > > On Thu, 14 May 2020 at 07:19, Jagan Teki wrote: > > > > UCLASS_SPI_FLASH driver at driver/mtd/spi is a generic > > spi flash driver to probe jedec,spi-nor flash chips. > > > > Technically a probe call in U_BOOT_DRIVER is local to that > > driver and not applicable to use it another driver or in > > another code. > > > > The apollolake SPL code using the generic probe by adding > > extra SPI flash driver, which make more confusion in terms > > of code readability and driver model structure. > > > > The fact that apollolake SPL requires a separate SPI flash > > driver to handle of-platdata via bind call, so move the > > bind call in the generic flash driver and drop the driver > > from apollolake code. > > > > I hope this wouldn't break generic code usage flash chips > > otherwise, we can handle this via driver data or a separate > > spi driver in drivers/mtd/spi. > > > > Cc: Bin Meng > > Cc: Simon Glass > > Cc: Vignesh R > > Signed-off-by: Jagan Teki > > --- > > arch/x86/cpu/apollolake/spl.c | 60 --- > > drivers/mtd/spi/sf_probe.c| 29 - > > include/spi_flash.h | 12 --- > > 3 files changed, 28 insertions(+), 73 deletions(-) > > Unfortunately this stops TPL from booting. > > Could you expose the 'read' method properly, perhaps? Not sure why it requires, read call seems very much similar to sf isn't it? Jagan.
Re: [U-Boot] is it mandatory for SPL to support DM
On Mon, May 25, 2020 at 10:58:12PM +0530, Jagan Teki wrote: > On Mon, May 25, 2020 at 9:06 PM Simon Glass wrote: > > > > Hi, > > > > On Mon, 25 May 2020 at 04:35, Marek Vasut wrote: > > > > > > On 5/25/20 10:44 AM, Jagan Teki wrote: > > > > SPL has a foot-print constraint, so fully switching a particular > > > > subsystem like SPI or SPI Flash to DM would increase the size of it. > > > > > > > > Possible areas to look at are (assume SPL_DM supported) > > > > 1) platdata > > > > 2) implement board or platform specific spl device driver which > > > > bypassed the actual framework ex: spl_spi_sunxi.c > > > > > > > > Do we have any other solutions? or any arguments on above step 2? > > > > > > SPL does not need to support DM until the size problem is solved. > > > > I don't think the problem will ever be 'solved'. It is an ongoing battle. > > > > But as it happens I've just sent a proposal for tiny-dm that I think will > > help. > > > > Jagan, which board are you trying to convert? If you are trying to > > convert SPI flash, I think we need to remove the legacy code first. > > These are the partially dm converted drivers, so boards which are > using can eventually need a dm spi switch. > > drivers/spi/fsl_dspi.c > drivers/spi/kirkwood_spi.c > drivers/spi/mxc_spi.c > drivers/spi/mxs_spi.c > drivers/spi/omap3_spi.c > drivers/spi/sh_qspi.c > > I'm looking for proper options along with removal of some legacy code, > and tiny-dm. For the number of about to be year past published deadline (which has been extended at times to get to that point even) boards, I think we need to start by dropping boards. Then we can see what makes sense moving forward. -- Tom signature.asc Description: PGP signature
Re: [U-Boot] is it mandatory for SPL to support DM
On Mon, May 25, 2020 at 9:06 PM Simon Glass wrote: > > Hi, > > On Mon, 25 May 2020 at 04:35, Marek Vasut wrote: > > > > On 5/25/20 10:44 AM, Jagan Teki wrote: > > > SPL has a foot-print constraint, so fully switching a particular > > > subsystem like SPI or SPI Flash to DM would increase the size of it. > > > > > > Possible areas to look at are (assume SPL_DM supported) > > > 1) platdata > > > 2) implement board or platform specific spl device driver which > > > bypassed the actual framework ex: spl_spi_sunxi.c > > > > > > Do we have any other solutions? or any arguments on above step 2? > > > > SPL does not need to support DM until the size problem is solved. > > I don't think the problem will ever be 'solved'. It is an ongoing battle. > > But as it happens I've just sent a proposal for tiny-dm that I think will > help. > > Jagan, which board are you trying to convert? If you are trying to > convert SPI flash, I think we need to remove the legacy code first. These are the partially dm converted drivers, so boards which are using can eventually need a dm spi switch. drivers/spi/fsl_dspi.c drivers/spi/kirkwood_spi.c drivers/spi/mxc_spi.c drivers/spi/mxs_spi.c drivers/spi/omap3_spi.c drivers/spi/sh_qspi.c I'm looking for proper options along with removal of some legacy code, and tiny-dm. Jagan.
Re: [PATCH v5 2/8] lib: rsa: take spl/non-spl into account when building rsa_verify_with_pkey()
Am Freitag, 22. Mai 2020, 16:19:31 CEST schrieb Heiko Stuebner: > From: Heiko Stuebner > > Right now in multiple places there are only checks for the full > CONFIG_RSA_VERIFY_WITH_PKEY option, not split into main,spl,tpl variants. > > This breaks when the rsa functions get enabled for SPL, for example to > verify u-boot proper from spl. > > So fix this by using the existing helpers to distinguis between > build-steps. > > Signed-off-by: Heiko Stuebner transplanting a tag from v4: Reviewed-by: Philipp Tomsich
Re: [PATCH v5 6/8] lib: rsa: add documentation to padding_pss_verify to document limitations
Am Freitag, 22. Mai 2020, 16:19:35 CEST schrieb Heiko Stuebner: > From: Heiko Stuebner > > padding_pss_verify only works with the default pss salt setting of -2 > (length to be automatically determined based on the PSS block structure) > not -1 (salt length set to the maximum permissible value), which makes > verifications of signatures with that saltlen fail. > > Until this gets implemented at least document this behaviour. > > Signed-off-by: Heiko Stuebner transplanting a tag from v4: Reviewed-by: Philipp Tomsich
Re: [PATCH v5 3/8] lib: rsa: bring exp_len in line when generating a key_prop
Am Freitag, 22. Mai 2020, 16:19:32 CEST schrieb Heiko Stuebner: > From: Heiko Stuebner > > The exponent field of struct key_prop gets allocated an uint64_t, > and the contents are positioned from the back, so an exponent of > "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" > > Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len > to the size returned from the parser, while on the other hand the > when getting the key from the devicetree exp_len always gets set to > sizeof(uint64_t). > > So bring that in line with the established code. > > Signed-off-by: Heiko Stuebner transplanting a tag from v4: Reviewed-by: Philipp Tomsich
Re: [PATCH v5 5/8] lib: rsa: free local arrays after use in rsa_gen_key_prop()
Am Freitag, 22. Mai 2020, 16:19:34 CEST schrieb Heiko Stuebner: > From: Heiko Stuebner > > n, rr and rrtmp are used for internal calculations, but in the end > the results are copied into separately allocated elements of the > actual key_prop, so the n, rr and rrtmp elements are not used anymore > when returning from the function and should of course be freed. > > Signed-off-by: Heiko Stuebner transplanting a tag from v4: Reviewed-by: Philipp Tomsich
Re: [PATCH v5 4/8] lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop()
Am Freitag, 22. Mai 2020, 16:19:33 CEST schrieb Heiko Stuebner: > From: Heiko Stuebner > > When calculating rrtmp/rr rsa_gen_key_prop() tries to make > (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and > (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] > with rlen being num_bits * 2 > > On a 4096bit key this comes down to to 257 uint32_t elements > in rr and 256 elements in rrtmp but with the current allocation > rr and rrtmp only have 129 uint32_t elements. > > On 2048bit keys this works by chance as the defined max_rsa_size=4096 > allocates a suitable number of elements, but with an actual 4096bit key > this results in other memory parts getting overwritten. > > so double the number of elements in rr and rrtmp so that it matches > the needed number and should increase nicely if max_rsa_size gets > increased in the future. > > Signed-off-by: Heiko Stuebner transplanting a tag from v4: Reviewed-by: Simon Glass
[GIT PULL] TI changes for v2020.07-rc3
Hi Tom, Please find the pull request for v2020.07-rc3 containing TI specific changes. Travis-CI build: https://travis-ci.org/github/lokeshvutla/u-boot/builds/690912492 Thanks and regards, Lokesh The following changes since commit ed9a3aa6452f57af65eb74f73bd2a54c3a2f4b03: Merge tag 'efi-2020-07-rc3' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-05-18 08:17:29 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2020.07-rc3 for you to fetch changes up to c02712a7484918648e5dd09c092035c7eeb7794a: arm: mach-k3: Enable dcache in SPL (2020-05-19 14:41:13 +0530) Below are the major changes in this PR: - Enable DM_ETH on omap3_logic board - Enable Caches in SPL for K3 platforms - Enable backup boot mode support for J721E - Update the DDR timings for AM654 EVM - Add automated tests for RX-51 Adam Ford (1): ARM: omap3_logic boards: Convert to DM_ETH Andreas Dannenberg (1): arm: mach-k3: j721e_init: Add support for backup boot modes Jan Kiszka (1): arm: mach-k3: Enable dcache in SPL Pali Rohár (1): Nokia RX-51: Add automated test for running RX-51 build in qemu Praneeth Bajjuri (1): ddr: k3-am654: EMIF Tool update to 2.02 for IO optimizations and fixes .azure-pipelines.yml | 13 + .gitlab-ci.yml | 8 + .travis.yml| 7 + arch/arm/dts/k3-am654-base-board-ddr4-1600MTs.dtsi | 28 +-- .../arm/dts/logicpd-som-lv-35xx-devkit-u-boot.dtsi | 10 + .../arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi | 10 + .../dts/logicpd-torpedo-35xx-devkit-u-boot.dtsi| 10 + .../dts/logicpd-torpedo-37xx-devkit-u-boot.dtsi| 12 + arch/arm/mach-k3/am6_init.c| 1 + arch/arm/mach-k3/common.c | 35 +++ arch/arm/mach-k3/common.h | 1 + arch/arm/mach-k3/include/mach/j721e_hardware.h | 2 + arch/arm/mach-k3/include/mach/j721e_spl.h | 12 + arch/arm/mach-k3/j721e_init.c | 36 ++- board/logicpd/omap3som/omap3logic.c| 36 ++- board/nokia/rx51/MAINTAINERS | 1 + board/ti/am65x/evm.c | 2 + configs/omap35_logic_defconfig | 2 +- configs/omap35_logic_somlv_defconfig | 2 +- configs/omap3_logic_defconfig | 2 +- configs/omap3_logic_somlv_defconfig| 2 +- test/nokia_rx51_test.sh| 262 + 22 files changed, 455 insertions(+), 39 deletions(-) create mode 100755 test/nokia_rx51_test.sh -- 2.23.0
Re: [PATCH v4 2/9] usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq
Hi Sylwester, On Mon, 25 May 2020 at 10:57, Sylwester Nawrocki wrote: > > Hi Simon, > > On 25.05.2020 16:57, Simon Glass wrote: > > On Mon, 25 May 2020 at 05:40, Sylwester Nawrocki > > wrote: > >> > >> There might be hardware configurations where 64-bit data accesses > >> to XHCI registers are not supported properly. This patch removes > >> the readq/writeq so always two 32-bit accesses are used to read/write > >> 64-bit XHCI registers, similarly as it is done in Linux kernel. > >> > >> This patch fixes operation of the XHCI controller on RPI4 Broadcom > >> BCM2711 SoC based board, where the VL805 USB XHCI controller is > >> connected to the PCIe Root Complex, which is attached to the system > >> through the SCB bridge. > >> > >> Even though the architecture is 64-bit the PCIe BAR is 32-bit and likely > >> the 64-bit wide register accesses initiated by the CPU are not properly > >> translated to a sequence of 32-bit PCIe accesses. > >> xhci_readq(), for example, always returns same value in upper and lower > >> 32-bits, e.g. 0xabcd1234abcd1234 instead of 0xabcd1234. > > > Then I think this should be done with a quirk flag, enabled for this > > particular device via the compatible string. It should not be an #if, > > but an if(). > > Thanks for your comments. I will check and see how this could be done. > It might not be so straightforward since the XHCI controller is a PCI > device matched by the pci_device_id so we would need to be looking > at the compatible string of the PCI controller to set the quirk in > the xhci layer. It's the PCI bridge that introduces the limitation, > not the VL805 XHCI controller chip. OK then it should be modelled as such. How is this done in Linux? You can add a quirk in the PCI controller and then XHCI can check its parent's platdata to see the flag, perhaps, since the parent will always be UCLASS_PCI. You can always add the device to the devicetree if needed, and then you get a compatible string. Regards, Simon
Re: [RFC PATCH] mtd: spi: Drop redundent SPI flash driver
Hi Jagan, On Thu, 14 May 2020 at 07:19, Jagan Teki wrote: > > UCLASS_SPI_FLASH driver at driver/mtd/spi is a generic > spi flash driver to probe jedec,spi-nor flash chips. > > Technically a probe call in U_BOOT_DRIVER is local to that > driver and not applicable to use it another driver or in > another code. > > The apollolake SPL code using the generic probe by adding > extra SPI flash driver, which make more confusion in terms > of code readability and driver model structure. > > The fact that apollolake SPL requires a separate SPI flash > driver to handle of-platdata via bind call, so move the > bind call in the generic flash driver and drop the driver > from apollolake code. > > I hope this wouldn't break generic code usage flash chips > otherwise, we can handle this via driver data or a separate > spi driver in drivers/mtd/spi. > > Cc: Bin Meng > Cc: Simon Glass > Cc: Vignesh R > Signed-off-by: Jagan Teki > --- > arch/x86/cpu/apollolake/spl.c | 60 --- > drivers/mtd/spi/sf_probe.c| 29 - > include/spi_flash.h | 12 --- > 3 files changed, 28 insertions(+), 73 deletions(-) Unfortunately this stops TPL from booting. Could you expose the 'read' method properly, perhaps? Regards, Simon
Re: [PATCH v1 1/3] common: ns3: add error logging support
Hi Rayagonda,
On Sun, 17 May 2020 at 02:33, Rayagonda Kokatanur
wrote:
>
> From: Sheetal Tigadoli
>
> Add error logging support in uboot for ns3 platform.
>
> We log the bootup msgs from all bootstages(BL2, BL31, BL33, and Linux)
> on to DDR. When a watchdog is triggered from any of the bootstages,
> CRMU copies these logs to QSPI error logging space.
>
> Later when doing the post-mortem analysis, we parse the QSPI error
> log space.
Is there a doc somewhere describing the format? If not you should add
something to the top of your source file.
>
> Signed-off-by: Sheetal Tigadoli
> Signed-off-by: Rayagonda Kokatanur
> ---
> common/Kconfig| 8 +++
> common/Makefile | 1 +
> common/bcm_elog.c | 49 +++
> common/console.c | 22 ++
> configs/bcm_ns3_defconfig | 1 +
> include/bcm_elog.h| 37 +
> 6 files changed, 118 insertions(+)
> create mode 100644 common/bcm_elog.c
> create mode 100644 include/bcm_elog.h
>
> diff --git a/common/Kconfig b/common/Kconfig
> index 30cba15948..3980ba31e0 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -634,6 +634,14 @@ config SYS_STDIO_DEREGISTER
> removed (for example a USB keyboard) then this option can be
> enabled to ensure this is handled correctly.
>
> +config BCM_ELOG
> + bool "Broadcom error logging support"
> + default n
Not needed
> + help
> + Enables broadcom error logging support to be used with brcm
> + platforms, say Y to this option to enable the logging support.
> + If unsure, say N.
> +
> endmenu
>
> menu "Logging"
> diff --git a/common/Makefile b/common/Makefile
> index 2e7a090588..dced769dcf 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -95,6 +95,7 @@ else
> obj-$(CONFIG_SPL_SERIAL_SUPPORT) += console.o
> endif
> else
> +obj-$(CONFIG_BCM_ELOG) += bcm_elog.o
> obj-y += console.o
> endif # CONFIG_SPL_BUILD
>
> diff --git a/common/bcm_elog.c b/common/bcm_elog.c
> new file mode 100644
> index 00..8e89a500b9
> --- /dev/null
> +++ b/common/bcm_elog.c
> @@ -0,0 +1,49 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 Broadcom.
> + */
> +
> +#include
> +
> +/* Log one character */
> +int log2ddr(const char ch)
> +{
> + u32 offset, len;
> + uintptr_t base = BCM_ELOG_UBOOT_BASE;
This should really be in a driver. Have you looked at logging? See for
example log_syslog.c which is an example of writing log info obtained
from the log() function.
If that doesn't work then perhaps have a UCLASS_MISC driver that you
can write to?
> +
> + offset = readl(base + BCM_ELOG_OFF_OFFSET);
> + len = readl(base + BCM_ELOG_LEN_OFFSET);
> + writeb(ch, base + offset);
> + offset++;
> +
> + /* log buffer is now full and need to wrap around */
> + if (offset >= BCM_ELOG_UBOOT_SIZE)
> + offset = BCM_ELOG_HEADER_LEN;
> +
> + /* only increment length when log buffer is not full */
> + if (len < BCM_ELOG_UBOOT_SIZE - BCM_ELOG_HEADER_LEN)
> + len++;
> +
> + writel(offset, base + BCM_ELOG_OFF_OFFSET);
> + writel(len, base + BCM_ELOG_LEN_OFFSET);
> +
> + return 0;
> +}
> +
> +/* Routine to initialize error logging */
> +void bcm_elog_init(uintptr_t base, uint32_t size)
> +{
> + u32 val;
> +
> + /*
> +* If a valid signature is found, it means logging is already
> +* initialize. In this case, we should not re-initialize the entry
> +* header in the designated memory
> +*/
> + val = readl(base + BCM_ELOG_SIG_OFFSET);
> + if (val != BCM_ELOG_SIG_VAL) {
> + writel(base + BCM_ELOG_SIG_OFFSET, BCM_ELOG_SIG_VAL);
> + writel(base + BCM_ELOG_OFF_OFFSET, BCM_ELOG_HEADER_LEN);
> + writel(base + BCM_ELOG_LEN_OFFSET, 0);
> + }
> +}
> diff --git a/common/console.c b/common/console.c
> index e398530a13..a65fdc16c2 100644
> --- a/common/console.c
> +++ b/common/console.c
> @@ -20,6 +20,10 @@
> #include
> #include
>
> +#ifdef CONFIG_BCM_ELOG
> +#include
> +#endif
Can't add this to common code, sorry.
Hopefully U-Boot's logging can help here?
> +
> DECLARE_GLOBAL_DATA_PTR;
>
> static int on_console(const char *name, const char *value, enum env_op op,
> @@ -536,6 +540,9 @@ void putc(const char c)
> if (!gd->have_console)
> return pre_console_putc(c);
>
> +#ifdef CONFIG_BCM_ELOG
> + log2ddr(c);
> +#endif
> if (gd->flags & GD_FLG_DEVINIT) {
> /* Send to the standard output */
> fputc(stdout, c);
> @@ -587,6 +594,17 @@ void puts(const char *s)
> if (!gd->have_console)
> return pre_console_puts(s);
>
> +#ifdef CONFIG_BCM_ELOG
> + {
> + const char *tmp = s;
> +
> + while (*tmp) {
> + int c =
