Re: [PATCH v4 0/6] Enable ICSSG Ethernet Driver for AM65x
On 4/16/2024 2:50 PM, MD Danish Anwar wrote: > The series introduces device tree and config changes and AM65x > to enable ICSSG driver. The series also enables SPL_LOAD_FIT_APPLY_OVERLAY > for AM65x in order to load overlay over spl. > > The ICSSG2 node is added in device tree overlay so that it remains in > sync with linux kernel. > > This series has been tested on AM65x SR2.0, and the ICSSG interface is > able to ping / dhcp and boot kernel using tftp in uboot. > > The users need to set env variables fw_storage_interface, fw_dev_part, > fw_ubi_mtdpart, fw_ubi_volume to indicate which storage medium and > partition they want to use to load firmware files from. By default the env > fw_storage_interface=mmc and fw_dev_part=1:2 but users can modify these > envs as per their requirements. > > This is the v4 of the series [1]. The series doesn't depend on any patch > and can be applied cleanly on u-boot/master > > Changes from v3 to v4: > *) Separated the device tree and board specific changes into this series >from the main series [1]. > *) Added check for TARGET_AM654_A53_EVM config in board file as suggested >by Dan Carpenter > *) Rebased on latest u-boot/master. > > [1] https://lore.kernel.org/all/20240124064930.1787929-1-danishan...@ti.com/ > > MD Danish Anwar (6): > arm: dts: k3-am654-base-board: Add ICSSG2 Ethernet support > arm: dts: k3-am65x-binman: Add ICSSG2 overlay and configuration > configs: am65x_evm_a53: Enable ICSSG Driver > configs: am65x_evm_a53: add SPL_LOAD_FIT_APPLY_OVERLAY > board: ti: am65x: Add check for k3-am654-icssg2 in > board_fit_config_match() > board: ti: am65x: Set fw_storage_interface and fw_dev_part ENVs > > arch/arm/dts/Makefile | 4 +- > arch/arm/dts/k3-am654-icssg2.dtso | 145 ++ > arch/arm/dts/k3-am65x-binman.dtsi | 65 +- > board/ti/am65x/am65x.env | 4 + > board/ti/am65x/evm.c | 9 +- > configs/am65x_evm_a53_defconfig | 2 + > 6 files changed, 221 insertions(+), 8 deletions(-) > create mode 100644 arch/arm/dts/k3-am654-icssg2.dtso > > > base-commit: 6e316e3f397b5e01e98c5dd56cdbaab961daeedf For the series, Acked-by: Ravi Gunasekaran Regards, Ravi
[PATCH v3] usb: cdns3: gadget.c: Set fast access bit
From: Aswath Govindraju
When the device port is in a low power state [U3/L2/Not Connected],
accesses to usb device registers may take a long time. This could lead to
potential core hang when the controller registers are accessed after the
port is disabled by setting DEVDS field. Setting the fast register access
bit ensures that the PHY clock is keeping up in active state.
Therefore, set fast access bit to ensure the accesses to device registers
are quick even in low power states.
commit b5148d946f45 ("usb: cdns3: gadget: set fast access bit") in the
upstream kernel is taken as reference.
Signed-off-by: Aswath Govindraju
Signed-off-by: Ravi Gunasekaran
Reviewed-by: Roger Quadros
Reviewed-by: Marek Vasut
---
Changes since v2:
* Updated the commit description with reference to upstream kernel commit
* Picked up Marek's Reviewed-by tag from v2
Changes since v1:
-
* Rebased to tip of -next
* Added Reviewed-by tag
v2: https://lore.kernel.org/all/20240423082420.32336-1-r-gunaseka...@ti.com/
v1: https://lore.kernel.org/u-boot/20230505121353.23486-1-r-gunaseka...@ti.com/
drivers/usb/cdns3/gadget.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index 7aa0c6b2be..d11175dc5b 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -2325,6 +2325,9 @@ static void cdns3_gadget_config(struct cdns3_device
*priv_dev)
writel(USB_IEN_INIT, >usb_ien);
writel(USB_CONF_CLK2OFFDS | USB_CONF_L1DS, >usb_conf);
+ /* Set the Fast access bit */
+ writel(PUSB_PWR_FST_REG_ACCESS, _dev->regs->usb_pwr);
+
cdns3_configure_dmult(priv_dev, NULL);
cdns3_gadget_pullup(_dev->gadget, 1);
@@ -2383,6 +2386,7 @@ static int cdns3_gadget_udc_stop(struct usb_gadget
*gadget)
/* disable interrupt for device */
writel(0, _dev->regs->usb_ien);
+ writel(0, _dev->regs->usb_pwr);
writel(USB_CONF_DEVDS, _dev->regs->usb_conf);
return ret;
base-commit: bc39e06778168a34bb4e0a34fbee4edbde4414d8
--
2.17.1
[PATCH v2] usb: cdns3: gadget.c: Set fast access bit
From: Aswath Govindraju
When the device port is in a low power state [U3/L2/Not Connected],
accesses to usb device registers may take a long time. This could lead to
potential core hang when the controller registers are accessed after the
port is disabled by setting DEVDS field. Setting the fast register access
bit ensures that the PHY clock is keeping up in active state.
Therefore, set fast access bit to ensure the accesses to device registers
are quick even in low power states.
Signed-off-by: Aswath Govindraju
Signed-off-by: Ravi Gunasekaran
Reviewed-by: Roger Quadros
---
v1 was posted and was reviewed as well. But it did not get merged.
This change is present in upstream linux kernel as well.
Upstream Linux kernel commit: b5148d946f45 ("usb: cdns3: gadget: set fast
access bit")
Changes since v1:
* Rebased to tip of -next
* Added Reviewed-by tag
v1: https://lore.kernel.org/u-boot/20230505121353.23486-1-r-gunaseka...@ti.com/
drivers/usb/cdns3/gadget.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index 7aa0c6b2be..d11175dc5b 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -2325,6 +2325,9 @@ static void cdns3_gadget_config(struct cdns3_device
*priv_dev)
writel(USB_IEN_INIT, >usb_ien);
writel(USB_CONF_CLK2OFFDS | USB_CONF_L1DS, >usb_conf);
+ /* Set the Fast access bit */
+ writel(PUSB_PWR_FST_REG_ACCESS, _dev->regs->usb_pwr);
+
cdns3_configure_dmult(priv_dev, NULL);
cdns3_gadget_pullup(_dev->gadget, 1);
@@ -2383,6 +2386,7 @@ static int cdns3_gadget_udc_stop(struct usb_gadget
*gadget)
/* disable interrupt for device */
writel(0, _dev->regs->usb_ien);
+ writel(0, _dev->regs->usb_pwr);
writel(USB_CONF_DEVDS, _dev->regs->usb_conf);
return ret;
base-commit: bc39e06778168a34bb4e0a34fbee4edbde4414d8
--
2.17.1
Re: [PATCH v5 4/5] net: ti: icssg: Add ICSSG ethernet driver
On 4/4/24 12:38 PM, MD Danish Anwar wrote: > This is the PRUSS Ethernet driver for TI AM654 SR2.0 and later SoCs with > the ICSSG PRU Sub-system running EMAC firmware. ICSSG Subsystem supports > two slices per instance. This driver caters to both slices / ports of > the icssg subsystem. > > Since it is not possible for Ethernet driver to register more than one > port for a given instance, this patch introduces top level PRUETH as > UCLASS_MISC and binds UCLASS_ETH to individual ports in order to support > bringing up more than one Ethernet interface in U-Boot. > > Since top level driver is UCLASS_MISC, board files would need to > instantiate the driver explicitly. > > Signed-off-by: MD Danish Anwar > --- > arch/arm/mach-k3/common.c | 11 + > drivers/net/ti/Kconfig| 13 + > drivers/net/ti/Makefile | 1 + > drivers/net/ti/icssg_prueth.c | 685 ++ > drivers/net/ti/icssg_prueth.h | 3 + > 5 files changed, 713 insertions(+) > create mode 100644 drivers/net/ti/icssg_prueth.c > Reviewed-by: Ravi Gunasekaran -- Regards, Ravi
Re: [PATCH v5 2/5] net: ti: icssg: Add Firmware config and classification APIs.
On 4/4/24 12:38 PM, MD Danish Anwar wrote: > Add icssg_config.h / .c and icssg_classifier.c files. These are firmware > configuration and classification related files. Add MII helper APIs and > MACROs. These APIs and MACROs will be later used by ICSSG Ethernet driver. > Also introduce icssg_prueth.h which has definition of prueth related > structures. > > Signed-off-by: MD Danish Anwar > --- > drivers/net/ti/icss_mii_rt.h | 192 ++ > drivers/net/ti/icssg_classifier.c | 376 +++ > drivers/net/ti/icssg_config.c | 406 ++ > drivers/net/ti/icssg_config.h | 177 + > drivers/net/ti/icssg_prueth.h | 83 ++ > 5 files changed, 1234 insertions(+) > create mode 100644 drivers/net/ti/icss_mii_rt.h > create mode 100644 drivers/net/ti/icssg_classifier.c > create mode 100644 drivers/net/ti/icssg_config.c > create mode 100644 drivers/net/ti/icssg_config.h > create mode 100644 drivers/net/ti/icssg_prueth.h > Reviewed-by: Ravi Gunasekaran -- Regards, Ravi
Re: [PATCH v4 5/5] net: ti: icssg: Add support sending FDB command to update rx_flow_id
On 3/27/24 10:58 AM, MD Danish Anwar wrote: > ICSSG firmware supports FDB commands. Add support to send FDB commands > from driver. Once rx_flow_id is obtained from dma, let firmware know that > we are using this rx_flow_id by sending a FDB command. > > Signed-off-by: MD Danish Anwar > --- > drivers/net/ti/icssg_config.c | 68 +++ > drivers/net/ti/icssg_config.h | 18 ++ > drivers/net/ti/icssg_prueth.c | 6 > drivers/net/ti/icssg_prueth.h | 6 > 4 files changed, 98 insertions(+) > Reviewed-by: Ravi Gunasekaran -- Regards, Ravi
Re: [PATCH v4 4/5] net: ti: icssg: Add ICSSG ethernet driver
On 3/27/24 10:58 AM, MD Danish Anwar wrote: > This is the PRUSS Ethernet driver for TI AM654 Sr2.0 and laterSoCs with s/Sr2.0/SR2.0 s/laterSoCs/later SoCs > the ICSSG PRU Sub-system running EMAC firmware. ICSSG Subsystem supports > two slices per instance. This driver caters to both slices / ports of > the icssg subsystem. > > Since it is not possible for Ethernet driver to register more than one > port for a given instance, this patch introduces top level PRUETH as > UCLASS_MISC and binds UCLASS_ETH to individual ports in order to support > bringing up more than one Ethernet interface in U-Boot. > > Since top level driver is UCLASS_MISC, board files would need to > instantiate the driver explicitly. > > Signed-off-by: MD Danish Anwar > --- > arch/arm/mach-k3/common.c | 11 + > drivers/net/ti/Kconfig| 13 + > drivers/net/ti/Makefile | 1 + > drivers/net/ti/icssg_prueth.c | 685 ++ > drivers/net/ti/icssg_prueth.h | 3 + > 5 files changed, 713 insertions(+) > create mode 100644 drivers/net/ti/icssg_prueth.c > [...] > @@ -7,3 +7,4 @@ obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o > obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o cpsw_mdio.o > obj-$(CONFIG_TI_AM65_CPSW_NUSS) += am65-cpsw-nuss.o > obj-$(CONFIG_MDIO_TI_CPSW) += cpsw_mdio.o > +obj-$(CONFIG_TI_ICSSG_PRUETH) += icssg_prueth.o icssg_classifier.o > icssg_config.o icssg_queues.o > diff --git a/drivers/net/ti/icssg_prueth.c b/drivers/net/ti/icssg_prueth.c > new file mode 100644 > index 00..d22a56c217 > --- /dev/null > +++ b/drivers/net/ti/icssg_prueth.c > @@ -0,0 +1,685 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Texas Instruments K3 AM65 PRU Ethernet Driver > + * > + * Copyright (C) 2018-2024, Texas Instruments, Incorporated URL is missing. > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "icssg_prueth.h" > +#include "icss_mii_rt.h" > + > +#define ICSS_SLICE0 0 > +#define ICSS_SLICE1 1 > + > +#ifdef PKTSIZE_ALIGN > +#define UDMA_RX_BUF_SIZE PKTSIZE_ALIGN > +#else > +#define UDMA_RX_BUF_SIZE ALIGN(1522, ARCH_DMA_MINALIGN) PKTSIZE is defined in include/net.h as below #define PKTSIZE 1522 Please use the macro. > +#endif > + [...] -- Regards, Ravi
Re: [PATCH v4 3/5] net: ti: icssg: Add icssg queues APIs and macros
On 3/27/24 10:58 AM, MD Danish Anwar wrote: > Add icssg_queue.c file. This file introduces macros and APIs related to > ICSSG queues. These will be used by ICSSG Ethernet driver. > > Signed-off-by: MD Danish Anwar > --- > drivers/net/ti/icssg_prueth.h | 5 > drivers/net/ti/icssg_queues.c | 51 +++ > 2 files changed, 56 insertions(+) > create mode 100644 drivers/net/ti/icssg_queues.c > Reviewed-by: Ravi Gunasekaran -- Regards, Ravi
Re: [PATCH v4 2/5] net: ti: icssg: Add Firmware config and classification APIs.
On 3/27/24 10:58 AM, MD Danish Anwar wrote: > Add icssg_config.h / .c and icssg_classifier.c files. These are firmware > configuration and classification related files. Add MII helper APIs and > MACROs. These APIs and MACROs will be later used by ICSSG Ethernet driver. > Also introduce icssg_prueth.h which has definition of prueth related > structures. > > Signed-off-by: MD Danish Anwar > --- > drivers/net/ti/icss_mii_rt.h | 192 ++ > drivers/net/ti/icssg_classifier.c | 376 +++ > drivers/net/ti/icssg_config.c | 406 ++ > drivers/net/ti/icssg_config.h | 177 + > drivers/net/ti/icssg_prueth.h | 83 ++ > 5 files changed, 1234 insertions(+) > create mode 100644 drivers/net/ti/icss_mii_rt.h > create mode 100644 drivers/net/ti/icssg_classifier.c > create mode 100644 drivers/net/ti/icssg_config.c > create mode 100644 drivers/net/ti/icssg_config.h > create mode 100644 drivers/net/ti/icssg_prueth.h > > diff --git a/drivers/net/ti/icss_mii_rt.h b/drivers/net/ti/icss_mii_rt.h > new file mode 100644 > index 00..4a78394701 > --- /dev/null > +++ b/drivers/net/ti/icss_mii_rt.h > @@ -0,0 +1,192 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +/* PRU-ICSS MII_RT register definitions > + * > + * Copyright (C) 2015-2024 Texas Instruments Incorporated - http://www.ti.com In this and other patches, please fix the URL s/http/https > + */ > + > +#ifndef __NET_PRUSS_MII_RT_H__ > +#define __NET_PRUSS_MII_RT_H__ > + > +#include > + > +/* PRUSS_MII_RT Registers */ > +#define PRUSS_MII_RT_RXCFG0 0x0 > +#define PRUSS_MII_RT_RXCFG1 0x4 > +#define PRUSS_MII_RT_TXCFG0 0x10 > +#define PRUSS_MII_RT_TXCFG1 0x14 > +#define PRUSS_MII_RT_TX_CRC0 0x20 > +#define PRUSS_MII_RT_TX_CRC1 0x24 > +#define PRUSS_MII_RT_TX_IPG0 0x30 > +#define PRUSS_MII_RT_TX_IPG1 0x34 > +#define PRUSS_MII_RT_PRS00x38 > +#define PRUSS_MII_RT_PRS10x3c > +#define PRUSS_MII_RT_RX_FRMS00x40 > +#define PRUSS_MII_RT_RX_FRMS10x44 > +#define PRUSS_MII_RT_RX_PCNT00x48 > +#define PRUSS_MII_RT_RX_PCNT10x4c > +#define PRUSS_MII_RT_RX_ERR0 0x50 > +#define PRUSS_MII_RT_RX_ERR1 0x54 > + > +/* PRUSS_MII_RT_RXCFG0/1 bits */ > +#define PRUSS_MII_RT_RXCFG_RX_ENABLE BIT(0) > +#define PRUSS_MII_RT_RXCFG_RX_DATA_RDY_MODE_DIS BIT(1) > +#define PRUSS_MII_RT_RXCFG_RX_CUT_PREAMBLE BIT(2) > +#define PRUSS_MII_RT_RXCFG_RX_MUX_SELBIT(3) > +#define PRUSS_MII_RT_RXCFG_RX_L2_EN BIT(4) > +#define PRUSS_MII_RT_RXCFG_RX_BYTE_SWAP BIT(5) > +#define PRUSS_MII_RT_RXCFG_RX_AUTO_FWD_PRE BIT(6) > +#define PRUSS_MII_RT_RXCFG_RX_L2_EOF_SCLR_DISBIT(9) > + > +/* PRUSS_MII_RT_TXCFG0/1 bits */ > +#define PRUSS_MII_RT_TXCFG_TX_ENABLE BIT(0) > +#define PRUSS_MII_RT_TXCFG_TX_AUTO_PREAMBLE BIT(1) > +#define PRUSS_MII_RT_TXCFG_TX_EN_MODEBIT(2) > +#define PRUSS_MII_RT_TXCFG_TX_BYTE_SWAP BIT(3) > +#define PRUSS_MII_RT_TXCFG_TX_MUX_SELBIT(8) > +#define PRUSS_MII_RT_TXCFG_PRE_TX_AUTO_SEQUENCE BIT(9) > +#define PRUSS_MII_RT_TXCFG_PRE_TX_AUTO_ESC_ERR BIT(10) > +#define PRUSS_MII_RT_TXCFG_TX_32_MODE_EN BIT(11) > +#define PRUSS_MII_RT_TXCFG_TX_IPG_WIRE_CLK_ENBIT(12) /* SR2.0 > onwards */ > + > +#define PRUSS_MII_RT_TXCFG_TX_START_DELAY_SHIFT 16 > +#define PRUSS_MII_RT_TXCFG_TX_START_DELAY_MASK GENMASK(25, 16) > + > +#define PRUSS_MII_RT_TXCFG_TX_CLK_DELAY_SHIFT28 > +#define PRUSS_MII_RT_TXCFG_TX_CLK_DELAY_MASK GENMASK(30, 28) > + > +/* PRUSS_MII_RT_TX_IPG0/1 bits */ > +#define PRUSS_MII_RT_TX_IPG_IPG_SHIFT0 > +#define PRUSS_MII_RT_TX_IPG_IPG_MASK GENMASK(9, 0) > + > +/* PRUSS_MII_RT_PRS0/1 bits */ > +#define PRUSS_MII_RT_PRS_COL BIT(0) > +#define PRUSS_MII_RT_PRS_CRS BIT(1) > + > +/* PRUSS_MII_RT_RX_FRMS0/1 bits */ > +#define PRUSS_MII_RT_RX_FRMS_MIN_FRM_SHIFT 0 > +#define PRUSS_MII_RT_RX_FRMS_MIN_FRM_MASKGENMASK(15, 0) > + > +#define PRUSS_MII_RT_RX_FRMS_MAX_FRM_SHIFT 16 > +#define PRUSS_MII_RT_RX_FRMS_MAX_FRM_MASKGENMASK(31, 16) > + > +/* Min/Max in MII_RT_RX_FRMS */ > +/* For EMAC and Switch */ > +#define PRUSS_MII_RT_RX_FRMS_MAX (VLAN_ETH_FRAME_LEN + ETH_FCS_LEN) > +#define PRUSS_MII_RT_RX_FRMS_MIN_FRM (64) > + > +/* for HSR and PRP */ > +#define PRUSS_MII_RT_RX_FRMS_MAX_FRM_LRE (PRUSS_MII_RT_RX_FRMS_MAX + \ > + ICSS_LRE_TAG_RCT_SIZE) > +/* PRUSS_MII_RT_RX_PCNT0/1 bits */ > +#define PRUSS_MII_RT_RX_PCNT_MIN_PCNT_SHIFT 0 > +#define PRUSS_MII_RT_RX_PCNT_MIN_PCNT_MASK GENMASK(3, 0) > + > +#define PRUSS_MII_RT_RX_PCNT_MAX_PCNT_SHIFT 4 > +#define PRUSS_MII_RT_RX_PCNT_MAX_PCNT_MASK GENMASK(7, 4) > + > +/* PRUSS_MII_RT_RX_ERR0/1 bits */ > +#define PRUSS_MII_RT_RX_ERR_MIN_PCNT_ERR BIT(0) > +#define
Re: [PATCH v4 1/5] net: ti: icssg: Add Firmware Interface for ICSSG Ethernet driver.
On 3/27/24 10:58 AM, MD Danish Anwar wrote: > Add firmware interface related headers and macros for ICSSG Ethernet > driver. These macros will be later used by the ICSSG ethernet driver. > > Signed-off-by: MD Danish Anwar > --- > drivers/net/ti/icssg_switch_map.h | 209 ++ > 1 file changed, 209 insertions(+) > create mode 100644 drivers/net/ti/icssg_switch_map.h > Reviewed-by: Ravi Gunasekaran -- Regards, Ravi
Re: [PATCH] arm: mach-k3: Fix config check for FS_LOADER
On 3/14/24 8:03 PM, MD Danish Anwar wrote: > load_firmware() API calls fs-loader APIs and checks for CONFIG_FS_LOADER > before calling those APIs. The if check only checks for CONFIG_FS_LOADER > but not for CONFIG_SPL_FS_LOADER. > > When CONFIG_FS_LOADER is enabled, load_firmware() API calls fs-loader APIs > but this is done at SPL stage and at this time FS_LOADER is not built yet > as a result we see below build error. > > AR spl/boot/built-in.o > LD spl/u-boot-spl > arm-none-linux-gnueabihf-ld.bfd: arch/arm/mach-k3/common.o: in function > `load_firmware': > /home/danish/workspace/u-boot/arch/arm/mach-k3/common.c:184: undefined > reference to `get_fs_loader' > arm-none-linux-gnueabihf-ld.bfd: > /home/danish/workspace/u-boot/arch/arm/mach-k3/common.c:185: undefined > reference to `request_firmware_into_buf' > make[2]: *** [/home/danish/workspace/u-boot/scripts/Makefile.spl:527: > spl/u-boot-spl] Error 1 > make[1]: *** [/home/danish/workspace/u-boot/Makefile:2055: > spl/u-boot-spl] Error 2 > make[1]: Leaving directory '/home/danish/uboot_images/am64x/r5' > make: *** [Makefile:177: sub-make] Error 2 > > Fix this by modifying the if check to CONFIG_IS_ENABLED(FS_LOADER) instead > of IS_ENABLED(CONFIG_FS_LOADER) as the former will check for the > appropriate config option (CONFIG_SPL_FS_LOADER / CONFIG_FS_LOADER) based > on the build stage. > > Signed-off-by: MD Danish Anwar > --- > arch/arm/mach-k3/r5/common.c | 2 +- > arch/arm/mach-omap2/boot-common.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c > index 7309573a3f..c02f8d3309 100644 > --- a/arch/arm/mach-k3/r5/common.c > +++ b/arch/arm/mach-k3/r5/common.c > @@ -70,7 +70,7 @@ int load_firmware(char *name_fw, char *name_loadaddr, u32 > *loadaddr) > char *name = NULL; > int size = 0; > > - if (!IS_ENABLED(CONFIG_FS_LOADER)) > + if (!CONFIG_IS_ENABLED(FS_LOADER)) > return 0; > > *loadaddr = 0; > diff --git a/arch/arm/mach-omap2/boot-common.c > b/arch/arm/mach-omap2/boot-common.c > index 57917da25c..aa0ab13d5f 100644 > --- a/arch/arm/mach-omap2/boot-common.c > +++ b/arch/arm/mach-omap2/boot-common.c > @@ -190,7 +190,7 @@ int load_firmware(char *name_fw, u32 *loadaddr) > struct udevice *fsdev; > int size = 0; > > - if (!IS_ENABLED(CONFIG_FS_LOADER)) > + if (!CONFIG_IS_ENABLED(FS_LOADER)) > return 0; > > if (!*loadaddr) Acked-by: Ravi Gunasekaran -- Regards, Ravi
Re: [PATCH v2 2/2] net: am65-cpsw: cpsw_mdio: Switch to proper DM_MDIO framework
On 2/28/24 4:05 PM, Roger Quadros wrote: > Add a new Kconfig symbol MDIO_TI_CPSW for the CPSW MDIO > driver and build it with proper DM support if enabled. > > If MDIO_TI_CPSW is not enabled then we continue to > behave like before. > > Clean up MDIO custom handling in am65-cpsw and use > dm_eth_phy_connect() to get the PHY. > > Signed-off-by: Roger Quadros > --- > Changelog: > > v2: no change > --- > drivers/net/ti/Kconfig | 8 ++ > drivers/net/ti/Makefile | 3 +- > drivers/net/ti/am65-cpsw-nuss.c | 190 ++ > drivers/net/ti/cpsw_mdio.c | 198 > +++- > drivers/net/ti/cpsw_mdio.h | 2 + > 5 files changed, 196 insertions(+), 205 deletions(-) > Tested dhcp and ping in u-boot on J721S2-EVM, SK-AM62B Tested-by: Ravi Gunasekaran -- Regards, Ravi
Re: [PATCH v5] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 2/17/24 5:56 PM, MD Danish Anwar wrote: > Add APIs to set a firmware_name to a rproc and boot the rproc with the > same firmware. > > Clients can call rproc_set_firmware() API to set firmware_name for a rproc > whereas rproc_boot() will load the firmware set by rproc_set_firmware() to > a buffer by calling request_firmware_into_buf(). rproc_boot() will then > load the firmware file to the remote processor and start the remote > processor. > > Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in > Kconfig so that we can call request_firmware_into_buf() from remoteproc > driver. > > Signed-off-by: MD Danish Anwar > --- > Changes from v4 to v5: > *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size >that can be loaded to a rproc. > *) Added freeing of address in rproc_boot() as pointed out by Ravi. > *) Allocating the address at a later point in rproc_boot() > *) Rebased on latest u-boot/master [commit >9e00b6993f724da9699ef12573307afea8c19284] > > Changes from v3 to v4: > *) No functional change. Splitted the patch out of the series as suggested >by Nishant. > *) Droppped the RFC tag. > > v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/ > v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/ > > drivers/remoteproc/Kconfig| 8 +++ > drivers/remoteproc/rproc-uclass.c | 100 ++ > include/remoteproc.h | 34 ++ > 3 files changed, 142 insertions(+) > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig > index 781de530af..759d21437a 100644 > --- a/drivers/remoteproc/Kconfig > +++ b/drivers/remoteproc/Kconfig [...] > + > +free_buffer: > + free(addr); Thanks for taking care of freeing the memory. Acked-by: Ravi Gunasekaran [...] -- Regards, Ravi
Re: [PATCH 1/2] net: mdio: Handle bus level GPIO Reset
On 2/19/24 9:03 PM, Roger Quadros wrote:
> Some platforms have bus level Reset controlled
> by a GPIO line. If available then handle bus reset
> via GPIO.
>
> Signed-off-by: Roger Quadros
> ---
> include/phy.h | 7 +++
> net/mdio-uclass.c | 37 -
> 2 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/include/phy.h b/include/phy.h
> index e02cbdb58c..90a595cae4 100644
> --- a/include/phy.h
> +++ b/include/phy.h
> @@ -9,6 +9,7 @@
> #ifndef _PHY_H
> #define _PHY_H
>
> +#include
> #include
> #include
> #include
> @@ -76,6 +77,12 @@ struct mii_dev {
> int (*reset)(struct mii_dev *bus);
> struct phy_device *phymap[PHY_MAX_ADDR];
> u32 phy_mask;
> + /** @reset_delay_us: Bus GPIO reset pulse width in microseconds */
> + int reset_delay_us;
> + /** @reset_post_delay_us: Bus GPIO reset deassert delay in microseconds
> */
> + int reset_post_delay_us;
> + /** @reset_gpiod: Bus Reset GPIO descriptor pointer */
> + struct gpio_desc reset_gpiod;
> };
>
> /* struct phy_driver: a structure which defines PHY behavior
> diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
> index e758cc66d7..4500c50430 100644
> --- a/net/mdio-uclass.c
> +++ b/net/mdio-uclass.c
> @@ -14,6 +14,9 @@
> #include
> #include
> #include
> +#include
> +
> +#define DEFAULT_GPIO_RESET_DELAY 10 /* in microseconds */
>
> void dm_mdio_probe_devices(void)
> {
> @@ -80,6 +83,16 @@ int dm_mdio_write(struct udevice *mdio_dev, int addr, int
> devad, int reg,
> int dm_mdio_reset(struct udevice *mdio_dev)
> {
> struct mdio_ops *ops = mdio_get_ops(mdio_dev);
> + struct mdio_perdev_priv *pdata = dev_get_uclass_priv(mdio_dev);
> + struct mii_dev *mii_bus = pdata->mii_bus;
> +
> + if (dm_gpio_is_valid(_bus->reset_gpiod)) {
> + dm_gpio_set_value(_bus->reset_gpiod, 1);
undefined reference to `dm_gpio_set_value'
Build fails for configs that don't have CONFIG_DM_GPIO defined.
We can have this under "if (IS_ENABLED(CONFIG_DM_GPIO))"
> + udelay(mii_bus->reset_delay_us);
> + dm_gpio_set_value(_bus->reset_gpiod, 0);
> + if (mii_bus->reset_post_delay_us > 0)
> + udelay(mii_bus->reset_post_delay_us);
> + }
>
> if (!ops->reset)
> return 0;
> @@ -111,14 +124,36 @@ static int mdio_reset(struct mii_dev *mii_bus)
> static int dm_mdio_post_probe(struct udevice *dev)
> {
> struct mdio_perdev_priv *pdata = dev_get_uclass_priv(dev);
> + struct mii_dev *mii_bus;
> + int ret;
>
> - pdata->mii_bus = mdio_alloc();
> + mii_bus = mdio_alloc();
> + if (!mii_bus) {
> + dev_err(dev, "couldn't allocate mii_bus\n");
> + return -ENOMEM;
> + }
> + pdata->mii_bus = mii_bus;
> pdata->mii_bus->read = mdio_read;
> pdata->mii_bus->write = mdio_write;
> pdata->mii_bus->reset = mdio_reset;
> pdata->mii_bus->priv = dev;
> strlcpy(pdata->mii_bus->name, dev->name, MDIO_NAME_LEN);
>
> + if (IS_ENABLED(CONFIG_DM_GPIO)) {
> + /* Get bus level PHY reset GPIO details */
> + mii_bus->reset_delay_us = dev_read_u32_default(dev,
> "reset-delay-us",
> +
> DEFAULT_GPIO_RESET_DELAY);
> + mii_bus->reset_post_delay_us = dev_read_u32_default(dev,
> +
> "reset-post-delay-us",
> + 0);
> + ret = gpio_request_by_name(dev, "reset-gpios", 0,
> _bus->reset_gpiod,
> +GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
> + if (ret && ret != -ENOENT) {
> + dev_err(dev, "couldn't get reset-gpios: %d\n", ret);
> + return ret;
> + }
> + }
> +
> return mdio_register(pdata->mii_bus);
> }
>
>
--
Regards,
Ravi
Re: [PATCH v4] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 1/30/2024 12:03 PM, MD Danish Anwar wrote:
> Add APIs to set a firmware_name to a rproc and boot the rproc with the
> same firmware.
>
> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
> load the firmware file to the remote processor and start the remote
> processor.
>
> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
> Kconfig so that we can call request_firmware_into_buf() from remoteproc
> driver.
>
> Signed-off-by: MD Danish Anwar
> ---
> Changes from v3 to v4:
> *) No functional change. Splitted the patch out of the series as suggested
>by Nishant.
> *) Droppped the RFC tag.
>
> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
>
> drivers/remoteproc/Kconfig| 1 +
> drivers/remoteproc/rproc-uclass.c | 85 +++
> include/remoteproc.h | 35 +
> 3 files changed, 121 insertions(+)
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 781de530af..0fdf1b38ea 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
> # All users should depend on DM
> config REMOTEPROC
> bool
> + select FS_LOADER
> depends on DM
>
> # Please keep the configuration alphabetically sorted.
> diff --git a/drivers/remoteproc/rproc-uclass.c
> b/drivers/remoteproc/rproc-uclass.c
> index 28b362c887..76db4157f7 100644
> --- a/drivers/remoteproc/rproc-uclass.c
> +++ b/drivers/remoteproc/rproc-uclass.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -961,3 +962,87 @@ unsigned long rproc_parse_resource_table(struct udevice
> *dev, struct rproc *cfg)
>
> return 1;
> }
> +
> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
> +{
> + struct dm_rproc_uclass_pdata *uc_pdata;
> + int len;
> + char *p;
> +
> + if (!rproc_dev || !fw_name)
> + return -EINVAL;
> +
> + uc_pdata = dev_get_uclass_plat(rproc_dev);
> +
> + len = strcspn(fw_name, "\n");
> + if (!len) {
> + debug("can't provide empty string for firmware name\n");
> + return -EINVAL;
> + }
> +
> + p = strndup(fw_name, len);
> + if (!p)
> + return -ENOMEM;
> +
> + uc_pdata->fw_name = p;
> +
> + return 0;
> +}
> +
> +int rproc_boot(struct udevice *rproc_dev, size_t fw_size)
> +{
> + struct dm_rproc_uclass_pdata *uc_pdata;
> + struct udevice *fs_loader;
> + void *addr = malloc(fw_size);
> + int core_id, ret = 0;
> + char *firmware;
> + ulong rproc_addr;
> +
> + if (!rproc_dev)
> + return -EINVAL;
> +
> + if (!addr)
> + return -ENOMEM;
> +
addr is not freed.
> + uc_pdata = dev_get_uclass_plat(rproc_dev);
> + core_id = dev_seq(rproc_dev);
> + firmware = uc_pdata->fw_name;
> +
> + if (!firmware) {
> + debug("No firmware set for rproc core %d\n", core_id);
> + return -EINVAL;
> + }
> +
> + /* Initialize all rproc cores */
> + rproc_init();
> +
> + /* Loading firmware to a given address */
> + ret = get_fs_loader(_loader);
> + if (ret) {
> + debug("could not get fs loader: %d\n", ret);
> + return ret;
> + }
> +
> + ret = request_firmware_into_buf(fs_loader, firmware, addr, fw_size, 0);
> + if (ret < 0) {
> + debug("could not request %s: %d\n", firmware, ret);
> + return ret;
> + }
> +
> + rproc_addr = (ulong)addr;
> +
> + ret = rproc_load(core_id, rproc_addr, ret);
> + if (ret) {
> + debug("failed to load %s to rproc core %d from addr 0x%08lX err
> %d\n",
> + uc_pdata->fw_name, core_id, rproc_addr, ret);
> + return ret;
> + }
> +
> + ret = rproc_start(core_id);
> + if (ret) {
> + debug("failed to start rproc core %d\n", core_id);
> + return ret;
> + }
> +
> + return ret;
> +}
> diff --git a/include/remoteproc.h b/include/remoteproc.h
> index 91a88791a4..e53f85ba51 100644
> --- a/include/remoteproc.h
> +++ b/include/remoteproc.h
> @@ -403,6 +403,7 @@ enum rproc_mem_type {
> * @name: Platform-specific way of naming the Remote proc
> * @mem_type: one of 'enum rproc_mem_type'
> * @driver_plat_data: driver specific platform data that may be needed.
> + * @fw_name: firmware name
> *
> * This can be accessed with dev_get_uclass_plat() for any UCLASS_REMOTEPROC
> * device.
> @@ -412,6 +413,7 @@ struct dm_rproc_uclass_pdata {
> const char *name;
> enum rproc_mem_type mem_type;
> void *driver_plat_data;
> + char *fw_name;
> };
>
> /**
> @@ -705,6 +707,35 @@ unsigned long
Re: [PATCH v4] dma: ti: k3-udma: Use ring_idx to pair k3 nav rings
On 1/30/2024 11:48 AM, MD Danish Anwar wrote:
> Use ring_idx to pair rings. ring_idx will be same as tx flow_id for all
> non-negative flow_ids. For negative flow_ids, ring_idx will be tchan->id
> added with bchan_cnt.
>
> Signed-off-by: MD Danish Anwar
> ---
> Changes from v3 to v4:
> *) No functional change. Splitted the patch out of the series as suggested
>by Nishant.
>
> v3: https://lore.kernel.org/all/20240124064930.1787929-2-danishan...@ti.com/
>
> drivers/dma/ti/k3-udma.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> index 8a62d63dfe..eea9ec9659 100644
> --- a/drivers/dma/ti/k3-udma.c
> +++ b/drivers/dma/ti/k3-udma.c
> @@ -876,13 +876,20 @@ static int udma_alloc_tx_resources(struct udma_chan *uc)
> {
> struct k3_nav_ring_cfg ring_cfg;
> struct udma_dev *ud = uc->ud;
> - int ret;
> + struct udma_tchan *tchan;
> + int ring_idx, ret;
>
> ret = udma_get_tchan(uc);
> if (ret)
> return ret;
>
> - ret = k3_nav_ringacc_request_rings_pair(ud->ringacc, uc->tchan->id, -1,
> + tchan = uc->tchan;
> + if (tchan->tflow_id >= 0)
> + ring_idx = tchan->tflow_id;
> + else
> + ring_idx = ud->bchan_cnt + tchan->id;
> +
> + ret = k3_nav_ringacc_request_rings_pair(ud->ringacc, ring_idx, -1,
> >tchan->t_ring,
> >tchan->tc_ring);
> if (ret) {
I see this change present in upstream linux kernel as well.
You could consider providing the link to kernel if such changes are already
merged there.
Reviewed-by: Ravi Gunasekaran
Re: [PATCH v4] misc: fs-loader: Use fw_storage_interface instead of storage_interface
On 1/30/2024 11:56 AM, MD Danish Anwar wrote: > The fs-loader driver reads env storage_interface and uses it to load > firmware file into memory using the medium set by env. Update the driver > to use env fw_storage_interface as this variable is only used to load > firmwares. The env storage_interface will act as fallback so that the > existing implementations do not break. > > Also update the FS Loader documentation accordingly. > > Signed-off-by: MD Danish Anwar > --- > Changes from v3 to v4: > *) No functional change. Splitted the patch out of the series as suggested >by Nishant. > *) Droppped the RFC tag. > > v3: https://lore.kernel.org/all/20240124064930.1787929-3-danishan...@ti.com/ Acked-by: Ravi Gunasekaran
Re: [PATCH] include: env: ti: mmc: Add 'ti' directory prefix for overlays
On 9/15/23 6:12 PM, Nishanth Menon wrote:
> On 15:42-20230915, Ravi Gunasekaran wrote:
>> DTSOs are stored in vendor specific directories in Linux.
>
> what is dtso? kernel generates dtbo
I'm sorry, my bad. I will be careful in future.
>
>> Add the vendor prefix to the path to load the overlay correctly.
>>
>> Signed-off-by: Ravi Gunasekaran
>> ---
>> include/env/ti/mmc.env | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/env/ti/mmc.env b/include/env/ti/mmc.env
>> index 0256a2d2aa..3e6b0287a3 100644
>> --- a/include/env/ti/mmc.env
>> +++ b/include/env/ti/mmc.env
>> @@ -70,7 +70,7 @@ get_overlay_mmc=
>> fdt resize 0x10;
>> for overlay in $name_overlays;
>> do;
>> -load mmc ${bootpart} ${dtboaddr} ${bootdir}/dtb/${overlay} &&
>> +load mmc ${bootpart} ${dtboaddr} ${bootdir}/dtb/ti/${overlay} &&
>> fdt apply ${dtboaddr};
>> done;
>> get_kern_mmc=load mmc ${bootpart} ${loadaddr}
>>
>> base-commit: 2fe4b54556ea6271237b35de68dc458bfceab94c
>
> we should move to stdboot and simplify this.
Noted.
>
--
Regards,
Ravi
[PATCH] include: env: ti: mmc: Add 'ti' directory prefix for overlays
DTSOs are stored in vendor specific directories in Linux.
Add the vendor prefix to the path to load the overlay correctly.
Signed-off-by: Ravi Gunasekaran
---
include/env/ti/mmc.env | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/env/ti/mmc.env b/include/env/ti/mmc.env
index 0256a2d2aa..3e6b0287a3 100644
--- a/include/env/ti/mmc.env
+++ b/include/env/ti/mmc.env
@@ -70,7 +70,7 @@ get_overlay_mmc=
fdt resize 0x10;
for overlay in $name_overlays;
do;
- load mmc ${bootpart} ${dtboaddr} ${bootdir}/dtb/${overlay} &&
+ load mmc ${bootpart} ${dtboaddr} ${bootdir}/dtb/ti/${overlay} &&
fdt apply ${dtboaddr};
done;
get_kern_mmc=load mmc ${bootpart} ${loadaddr}
base-commit: 2fe4b54556ea6271237b35de68dc458bfceab94c
--
2.17.1
[PATCH] configs: am65x_evm_r5_usbmsc_defconfig: Enable DWC3 wrapper for SPL
commit 280f45d23977 ("configs: get rid of build warnings due to
SPL_USB_DWC3_GENERIC") missed enabling DWC3 glue layer for
usbmsc_defconfig and this broke boot from USB mass storage.
Fix this by enabling DWC3 glue layer.
Fixes: 280f45d23977 ("configs: get rid of build warnings due to
SPL_USB_DWC3_GENERIC")
Signed-off-by: Ravi Gunasekaran
---
configs/am65x_evm_r5_usbmsc_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configs/am65x_evm_r5_usbmsc_defconfig
b/configs/am65x_evm_r5_usbmsc_defconfig
index 8da49c78c8..733a1c1874 100644
--- a/configs/am65x_evm_r5_usbmsc_defconfig
+++ b/configs/am65x_evm_r5_usbmsc_defconfig
@@ -85,6 +85,7 @@ CONFIG_SYS_I2C_OMAP24XX=y
CONFIG_DM_MAILBOX=y
CONFIG_K3_SEC_PROXY=y
CONFIG_MISC=y
+CONFIG_SPL_MISC=y
CONFIG_K3_AVS0=y
# CONFIG_MMC is not set
CONFIG_PHY=y
@@ -122,6 +123,7 @@ CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_DWC3=y
CONFIG_USB_DWC3=y
CONFIG_USB_DWC3_GENERIC=y
+CONFIG_SPL_USB_DWC3_GENERIC=y
CONFIG_USB_STORAGE=y
CONFIG_SPL_USB_STORAGE=y
CONFIG_USB_GADGET=y
--
2.17.1
Re: [PATCH] net: Fix the displayed value of bytes transferred
Siddharth,
On 8/10/23 2:45 PM, Siddharth Vadapalli wrote:
> In the case of NETLOOP_SUCCESS, the decimal value of the u32 variable
> "net_boot_file_size" is printed using "%d", resulting in negative values
> being reported for large file sizes. Fix this by using "%lu" to print
> the decimal value corresponding to the bytes transferred.
>
> Fixes: 1411157d8578 ("net: cosmetic: Fixup var names related to boot file")
> Signed-off-by: Siddharth Vadapalli
> ---
> net/net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/net.c b/net/net.c
> index 43abbac7c3..7aaeafc247 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -716,7 +716,7 @@ restart:
> case NETLOOP_SUCCESS:
> net_cleanup_loop();
> if (net_boot_file_size > 0) {
> - printf("Bytes transferred = %d (%x hex)\n",
> + printf("Bytes transferred = %lu (%x hex)\n",
'net_boot_file_size' is of type u32. Using "%lu" will throw a warning for this.
As per [0], format specifier for 'unsigned int' is "%d, %x'.
You could perhaps change the data type of 'net_boot_file_size' to 'ulong' as
well.
[0] - https://u-boot.readthedocs.io/en/latest/develop/printf.html
> net_boot_file_size, net_boot_file_size);
> env_set_hex("filesize", net_boot_file_size);
> env_set_hex("fileaddr", image_load_addr);
--
Regards,
Ravi
Re: [PATCH 0/4] net: ti: am65-cpsw-nuss: Fix DT binding handling of pinctrl
On 7/26/23 6:22 PM, Nishanth Menon wrote: > On 14:44-20230726, Ravi Gunasekaran wrote: > [...] >> If it is the former, then would a duplicate mdio node help keep the changes >> to minimum? > > That is worse hack. How does it make sense to have two mdio nodes to > represent the same hardware block? we are trying to get closer to kernel > dts support not farther away from it. > I know it's not a clean hack. In k3-am625-sk-u-boot.dtsi, as a hack, the mdio pinctrl gets added to cpsw node. So was wondering if a duplicate mdio pinctrl node could be added in the same file. Just wanted to know if we could skip the changes in CPSW driver posted by Maxime. But Maxime's approach is much cleaner. We can just sync up kernel dts and not keeping adding the hack to every K3 SoC's DT. -- Regards, Ravi
Re: [PATCH 0/4] net: ti: am65-cpsw-nuss: Fix DT binding handling of pinctrl
Maxime, On 7/26/23 6:19 PM, Maxime Ripard wrote: > Hi Ravi, > > On Wed, Jul 26, 2023 at 02:44:00PM +0530, Ravi Gunasekaran wrote: >> On 7/20/23 7:42 PM, Maxime Ripard wrote: >>> Hi >>> >>> Sorry, I didn't receive Roger mail so I'll reply here >>> >>> On Thu, Jul 20, 2023 at 09:00:19AM -0500, Nishanth Menon wrote: >>>> On 16:56-20230720, Roger Quadros wrote: >>>>> Hi, >>>>> >>>>> On 20/07/2023 16:33, Ravi Gunasekaran wrote: >>>>>> >>>>>> >>>>>> On 7/20/2023 3:25 PM, Maxime Ripard wrote: >>>>>>> Hi, >>>>>>> >>>>>>> This series is based on: >>>>>>> https://lore.kernel.org/all/20230713072019.3153871-1...@ti.com/ >>>>>>> >>>>>>> It fixes the issue of Linux booting from the DT embedded by U-boot. The >>>>>>> main issue there is that U-Boot doesn't handle the MDIO child node that >>>>>>> might have resources attached to it. >>>>>>> >>>>>>> Thus, any pinctrl configuration that could be attached to the MDIO >>>>>>> child node is effectively ignored. Unfortunately, starting with 6.5-rc1, >>>>>>> Linux does just that. >>>>> >>>>> I didn't get this part. Linux does not ignore pinctrl configuration >>>>> attached >>>>> to MDIO child node. What changed in 6.5-rc1? >>> >>> Linux doesn't ignore it, but Linux started putting pinctrl configuration >>> on the MDIO node, which is ignored by U-Boot. >>> >>>>>>> This was solved by duplicating the pinctrl configuration onto the MAC >>>>> >>>>> If I remember right, there is no driver model driver for MDIO in u-boot >>>>> and >>>>> adding the mdio pinctrl into CPSW DT node was a hack in u-boot. >>> >>> Yeah, but we now have in the U-Boot DT two nodes referencing the same >>> pinctrl configuration: the CPSW and the MDIO node. Linux then tries to >>> assign that configuration to both devices and it fails. >> >> This response might be late, as I know things have moved ahead after this >> discussion. But I just wanted to understand the root cause little bit more. >> Is the issue mainly because the same mdio pinctrl node(phandle) is >> referenced in >> two other nodes? Or is it because of same pins being updated in two different >> places in the kernel? >> >> If it is the former, then would a duplicate mdio node help keep the changes >> to minimum? > > Neither, actually :/ The issue is that, with the changes made by > Nishanth to bring the 6.5-rc1 DTS in, the same pinctrl node is > referenced in two separate nodes, and Linux sees that as conflicting > users of the same pins. So you mean to say, finally it boils down to the users of the same pins. Even if there are two nodes with the same pinctrl configuration, we would still hit the issue. > > One quick workaround would be to remove the MDIO pinctrl property, and > add it to the MAC pinctrl property. > > That's fairly dangerous if either get extended though, so it might not > be a proper solution long term. A proper solution would be to update the MDIO driver. I'm sorry that it doesn't follow the standard driver model. We have plans to fix it soon. > > I hope it's clearer > > Maxime -- Regards, Ravi
Re: [PATCH 0/4] net: ti: am65-cpsw-nuss: Fix DT binding handling of pinctrl
Maxime, On 7/20/23 7:42 PM, Maxime Ripard wrote: > Hi > > Sorry, I didn't receive Roger mail so I'll reply here > > On Thu, Jul 20, 2023 at 09:00:19AM -0500, Nishanth Menon wrote: >> On 16:56-20230720, Roger Quadros wrote: >>> Hi, >>> >>> On 20/07/2023 16:33, Ravi Gunasekaran wrote: >>>> >>>> >>>> On 7/20/2023 3:25 PM, Maxime Ripard wrote: >>>>> Hi, >>>>> >>>>> This series is based on: >>>>> https://lore.kernel.org/all/20230713072019.3153871-1...@ti.com/ >>>>> >>>>> It fixes the issue of Linux booting from the DT embedded by U-boot. The >>>>> main issue there is that U-Boot doesn't handle the MDIO child node that >>>>> might have resources attached to it. >>>>> >>>>> Thus, any pinctrl configuration that could be attached to the MDIO >>>>> child node is effectively ignored. Unfortunately, starting with 6.5-rc1, >>>>> Linux does just that. >>> >>> I didn't get this part. Linux does not ignore pinctrl configuration attached >>> to MDIO child node. What changed in 6.5-rc1? > > Linux doesn't ignore it, but Linux started putting pinctrl configuration > on the MDIO node, which is ignored by U-Boot. > >>>>> This was solved by duplicating the pinctrl configuration onto the MAC >>> >>> If I remember right, there is no driver model driver for MDIO in u-boot and >>> adding the mdio pinctrl into CPSW DT node was a hack in u-boot. > > Yeah, but we now have in the U-Boot DT two nodes referencing the same > pinctrl configuration: the CPSW and the MDIO node. Linux then tries to > assign that configuration to both devices and it fails. This response might be late, as I know things have moved ahead after this discussion. But I just wanted to understand the root cause little bit more. Is the issue mainly because the same mdio pinctrl node(phandle) is referenced in two other nodes? Or is it because of same pins being updated in two different places in the kernel? If it is the former, then would a duplicate mdio node help keep the changes to minimum? > >>>>> device node. Unfortunately, this doesn't work for Linux since now it has >>>>> two devices competing for the same pins. >>> >>> What has really changed here is that you are passing u-boot's device >>> tree to Linux. > > I didn't change anything. This is the default boot process if you don't > provide a DT in the ESP partition. > >>> This has nothing to do with 6.5-rc1 right? > > The issue started to occur with Nishanth patch to sync with Linux > 6.5-rc1 device trees, so there's definitely a connection. > >>> I suppose your solution is still a hack but of lesser evil than >>> duplicating MDIO pinctrl in CPSW node. >>> >>> The proper solution would be to implement driver model for the >>> davinci MDIO driver. Siddharth has been working on this. If that is >>> close to ready we should just use that instead. >> >> But this allows for a cleaner device tree while the driver can be fixed >> up independently, correct? Unfortunately, Siddharth's driver model work, >> from what I understand, is around 2024 timeframe.. which is probably not >> something that helps us in the community at this point. > > Yeah, at the moment I have to choose between getting the MMC to work in > Linux or the Ethernet ports. The former is working thanks to your patch, > the latter is broken because of it. Ideally I'd like both :) > > Maxime -- Regards, Ravi
Re: [PATCH 3/3] arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1
On 7/25/23 11:47 PM, Tom Rini wrote: > On Tue, Jul 25, 2023 at 09:09:34AM -0500, Nishanth Menon wrote: >> On 15:56-20230725, Maxime Ripard wrote: >>> Hi, >>> >>> On Tue, Jul 25, 2023 at 07:58:56AM -0500, Nishanth Menon wrote: Update the am62 and am625 device-trees from linux v6.3-rc5 This needed the followin tweaks to the u-boot specific dtsi as well: - Switch tick-timer to the main_timer as it's now defined in the main dtsi - Secure proxies are defined in Soc dtsis - Drop duplicate nodes - u-boot.dtsi is includes in r5-sk, no need for either the definitions from main.dtsi OR duplication from u-boot.dtsi - Add mdio pins to the cpsw3g pinctrl in u-boot dtsi. It moved to a subnode in the linux dtsi that u-boot doesn't use/support Cc: Francesco Dolcini Cc: Sjoerd Simons Cc: Wadim Egorov Signed-off-by: Nishanth Menon --- I decided not to pick up changes from Roger and Maxime as they are'nt regression fixes, instead the fixups can be done on top of the basic sync. >>> >>> This breaks Linux network interfaces so I very much considers this a >>> regression. >> The current u-boot.dtsi I am confused - pinctrl mdio is still a >> problem, is'nt it? >> https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/k3-am625-sk-u-boot.dtsi#L132 >> The follow on fixups from both your and Roger's series should fix things >> up, correct? > > I'm a little confused here too. For each of these cases, what happens? > - Today, one of these platforms, we pass the kernel the in-memory U-Boot > device tree. And if this is functional for networking, how/why? In here, the mdio pinctrl configuration is present only in one node (CPSW). So there is no conflict when the in-memory DT is passed by U-Boot to kernel. > - "Tomorrow", one of these platforms, with Nishanth's series applied, we > pass the in-memory U-Boot device tree In this case, the DT passed by U-Boot has the mdio pinctrl info present in two nodes - one in CPSW and other in MDIO. This causes failure in Linux as both nodes refer to same pinctrl configuration. > - Today or "Tomorrow", we continue to pass a device tree loaded from > SD/whatever that matches the kernel. This should work, and I think is > what's assumed to be the only functional option right now Kernel DT has mdio pinctrl info only in one node (MDIO). So passing a DT that matches the kernel does not cause any issue. > -- Regards, Ravi
Re: [PATCH 0/4] net: ti: am65-cpsw-nuss: Fix DT binding handling of pinctrl
On 7/20/2023 3:25 PM, Maxime Ripard wrote: > Hi, > > This series is based on: > https://lore.kernel.org/all/20230713072019.3153871-1...@ti.com/ > > It fixes the issue of Linux booting from the DT embedded by U-boot. The > main issue there is that U-Boot doesn't handle the MDIO child node that > might have resources attached to it. > > Thus, any pinctrl configuration that could be attached to the MDIO > child node is effectively ignored. Unfortunately, starting with 6.5-rc1, > Linux does just that. > > This was solved by duplicating the pinctrl configuration onto the MAC > device node. Unfortunately, this doesn't work for Linux since now it has > two devices competing for the same pins. > > Let me know what you think, > Maxime > > Signed-off-by: Maxime Ripard > --- > Maxime Ripard (4): > pinctrl: Create a select_state variant with the ofnode > net: ti: am65-cpsw-nuss: Enforce pinctrl state on the MDIO child node > fixup! arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1 > fixup! arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1 > > arch/arm/dts/k3-am625-sk-u-boot.dtsi | 7 -- > drivers/net/ti/am65-cpsw-nuss.c | 49 > > drivers/pinctrl/pinctrl-uclass.c | 15 ++- > include/dm/pinctrl.h | 26 ++- > 4 files changed, 83 insertions(+), 14 deletions(-) > --- > base-commit: acff6e7c553d5a839e885730a4018465a34ba5a7 > change-id: 20230720-ti-mdio-pinmux-a12525dba973 > > Best regards, Adding Roger
Re: [PATCH] usb: cdns3: gadget: Configure speed in udc_start
On 7/19/23 4:03 PM, Marek Vasut wrote:
> On 7/19/23 10:59, Ravi Gunasekaran wrote:
>> When one of the functions does not support super speed, the composite
>> driver forces the gadget to high speed. But the speed is never
>> configured in the cdns3 gadget driver. So configure the speed
>> in cdns3_gadget_udc_start just like in the kernel.
>>
>> Signed-off-by: Ravi Gunasekaran
>
> Is this a patch picked from the kernel ?
> Is there a matching kernel commit ID ?
The commit 4df50f89f5 ("usb: composite: force gadget to be USB2 for HS only
function")
in u-boot, forces the gadget's max speed to high speed and had a mention in the
commit
description that the gadget's udc_start would configure itself in USB 2.0.
I checked the cdns3 gadget driver in kernel, and the cdns3_gadget_udc_start()
configures speed. So this is not a patch picked directly from the kernel. I
used
kernel code for reference.
>
>> ---
>> drivers/usb/cdns3/gadget.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
>> index fcaeab9cc1..cae570cf59 100644
>> --- a/drivers/usb/cdns3/gadget.c
>> +++ b/drivers/usb/cdns3/gadget.c
>> @@ -82,6 +82,9 @@ static int __cdns3_gadget_ep_queue(struct usb_ep *ep,
>> struct usb_request *request,
>> gfp_t gfp_flags);
>> +static void cdns3_gadget_udc_set_speed(struct usb_gadget *gadget,
>> + enum usb_device_speed speed);
>> +
>> /**
>> * cdns3_set_register_bit - set bit in given register.
>> * @ptr: address of device controller register to be read and changed
>> @@ -2341,6 +2344,7 @@ static int cdns3_gadget_udc_start(struct usb_gadget
>> *gadget,
>> spin_lock_irqsave(_dev->lock, flags);
>> priv_dev->gadget_driver = driver;
>> + cdns3_gadget_udc_set_speed(gadget, gadget->max_speed);
>> cdns3_gadget_config(priv_dev);
>> spin_unlock_irqrestore(_dev->lock, flags);
>> return 0;
>>
>> base-commit: 76c61f29d63163d178b1584ecc9fc2c96c538ff0
>
> Where did this ^ come from ?
I'm based on origin/next. Please let me know if I should base on origin/master?
--
Regards,
Ravi
[PATCH] usb: cdns3: gadget: Configure speed in udc_start
When one of the functions does not support super speed, the composite driver forces the gadget to high speed. But the speed is never configured in the cdns3 gadget driver. So configure the speed in cdns3_gadget_udc_start just like in the kernel. Signed-off-by: Ravi Gunasekaran --- drivers/usb/cdns3/gadget.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c index fcaeab9cc1..cae570cf59 100644 --- a/drivers/usb/cdns3/gadget.c +++ b/drivers/usb/cdns3/gadget.c @@ -82,6 +82,9 @@ static int __cdns3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request, gfp_t gfp_flags); +static void cdns3_gadget_udc_set_speed(struct usb_gadget *gadget, + enum usb_device_speed speed); + /** * cdns3_set_register_bit - set bit in given register. * @ptr: address of device controller register to be read and changed @@ -2341,6 +2344,7 @@ static int cdns3_gadget_udc_start(struct usb_gadget *gadget, spin_lock_irqsave(_dev->lock, flags); priv_dev->gadget_driver = driver; + cdns3_gadget_udc_set_speed(gadget, gadget->max_speed); cdns3_gadget_config(priv_dev); spin_unlock_irqrestore(_dev->lock, flags); return 0; base-commit: 76c61f29d63163d178b1584ecc9fc2c96c538ff0 -- 2.17.1
Re: [RFC PATCH 2/4] arm: mach-k3: am62: Add timer0 id to the dev list
On 7/13/23 12:50 PM, Nishanth Menon wrote:
> From: Sjoerd Simons
>
> Timer0 is used by u-boot as the tick timer; Add it to the soc devices
> list so it can be enabled via the k3 power controller.
>
> Signed-off-by: Sjoerd Simons
> Reviewed-by: Tom Rini
> Tested-by: Ravi Gunasekaran
> Tested-by: Mattijs Korpershoek
> Cc: Francesco Dolcini
> Cc: Wadim Egorov
> [n...@ti.com: Fixup num_devices]
> Signed-off-by: Nishanth Menon
> ---
> Changes since Sjoerd's revision:
> I fixed up the num_devs to be 22.
>
> V1: https://lore.kernel.org/r/20230406185542.1179073-3-sjo...@collabora.com
> arch/arm/mach-k3/am62x/dev-data.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-k3/am62x/dev-data.c
> b/arch/arm/mach-k3/am62x/dev-data.c
> index 616d0650b9c0..c747769cf05c 100644
> --- a/arch/arm/mach-k3/am62x/dev-data.c
> +++ b/arch/arm/mach-k3/am62x/dev-data.c
> @@ -58,6 +58,7 @@ static struct ti_dev soc_dev_list[] = {
> PSC_DEV(161, _lpsc_list[8]),
> PSC_DEV(162, _lpsc_list[9]),
> PSC_DEV(75, _lpsc_list[10]),
> + PSC_DEV(36, _lpsc_list[11]),
> PSC_DEV(102, _lpsc_list[11]),
> PSC_DEV(146, _lpsc_list[11]),
> PSC_DEV(13, _lpsc_list[12]),
> @@ -74,5 +75,5 @@ const struct ti_k3_pd_platdata am62x_pd_platdata = {
> .num_psc = 2,
> .num_pd = 5,
> .num_lpsc = 16,
> - .num_devs = 21,
> + .num_devs = 22,
How about using ARRAY_SIZE()?
> };
--
Regards,
Ravi
[PATCH] common: dfu: Remove leading space characters
As per [1], dfu_alt_info is mentioned to be as semicolon separated
string of information on each alternate and the parsing logic in
the dfu.c is based on this.
Typically, the dfu_alt_info_* is defined in .h files as preprocessor
macros with 'alt' info separated by semicolon.
But when dfu_alt_info_* is added in the environment files(.env)
the script at "scripts/env2string.awk" converts a newline to space.
Thus adding a space character after semicolon. This results in
incorrect parsing in dfu.c which is based on the information that
'alt' info are only semicolon separated.
One option is to add dfu_alt_info_* variable in .env in single line.
But there is possiblity for it to exceed the line length limit.
So update the parsing logic to remove leading space characters
before adding to the dfu list.
[1]: https://u-boot.readthedocs.io/en/latest/usage/dfu.html
Signed-off-by: Ravi Gunasekaran
---
drivers/dfu/dfu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 516dda6179..b2ee5f1ede 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -135,6 +135,7 @@ int dfu_config_interfaces(char *env)
a = s;
do {
part = strsep(, ";");
+ part = skip_spaces(part);
ret = dfu_alt_add(dfu, i, d, part);
if (ret)
return ret;
@@ -629,6 +630,7 @@ int dfu_config_entities(char *env, char *interface, char
*devstr)
for (i = 0; i < dfu_alt_num; i++) {
s = strsep(, ";");
+ s = skip_spaces(s);
ret = dfu_alt_add(dfu, interface, devstr, s);
if (ret) {
/* We will free "dfu" in dfu_free_entities() */
base-commit: f0e201433a2f6e6776fe7aaa6a89ca3df21a4435
--
2.17.1
Re: [PATCH] phy: ti: phy-j721e-wiz: Add j721s2-wiz-10g module support
On 15/05/23 4:20 pm, Ravi Gunasekaran wrote:
> Add support for j721s2-wiz-10g device to use clock-names interface
> instead of explicitly defining clock nodes within device tree node.
>
> Signed-off-by: Ravi Gunasekaran
> ---
> drivers/phy/ti/phy-j721e-wiz.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
> index 23397175d3..34314d0bd1 100644
> --- a/drivers/phy/ti/phy-j721e-wiz.c
> +++ b/drivers/phy/ti/phy-j721e-wiz.c
> @@ -256,6 +256,7 @@ enum wiz_type {
> J721E_WIZ_10G,
> AM64_WIZ_10G,
> J784S4_WIZ_10G,
> + J721S2_WIZ_10G,
> };
>
> struct wiz_data {
> @@ -307,6 +308,15 @@ static struct wiz_data j784s4_wiz_10g = {
> .clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
> };
>
> +static struct wiz_data j721s2_10g_data = {
> + .type = J721S2_WIZ_10G,
> + .pll0_refclk_mux_sel = _refclk_mux_sel,
> + .pll1_refclk_mux_sel = _refclk_mux_sel,
> + .refclk_dig_sel = _dig_sel_10g,
> + .clk_mux_sel = clk_mux_sel_10g,
> + .clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
> +};
> +
> #define WIZ_TYPEC_DIR_DEBOUNCE_MIN 100 /* ms */
> #define WIZ_TYPEC_DIR_DEBOUNCE_MAX 1000
>
> @@ -1037,8 +1047,14 @@ static int j721e_wiz_bind_of_clocks(struct wiz *wiz)
> ofnode node;
> int i, rc;
>
> - if (type == AM64_WIZ_10G || type == J784S4_WIZ_10G)
> + switch (type) {
> + case AM64_WIZ_10G:
> + case J784S4_WIZ_10G:
> + case J721S2_WIZ_10G:
> return j721e_wiz_bind_clocks(wiz);
> + default:
> + break;
> + };
>
> div_clk_drv = lists_driver_lookup_name("wiz_div_clk");
> if (!div_clk_drv) {
> @@ -1282,6 +1298,9 @@ static const struct udevice_id j721e_wiz_ids[] = {
> {
> .compatible = "ti,j784s4-wiz-10g", .data =
> (ulong)_wiz_10g,
> },
> + {
> + .compatible = "ti,j721s2-wiz-10g", .data =
> (ulong)_10g_data,
> + },
> {}
> };
>
This patch is needed inorder to sync up the J721S2 SerDes node in
DTS in u-boot with linux kernel.
>
> base-commit: eaa9efafffaf87e3414db5d21face5e2dad105e4
--
Regards,
Ravi
[PATCH] phy: ti: phy-j721e-wiz: Add j721s2-wiz-10g module support
Add support for j721s2-wiz-10g device to use clock-names interface
instead of explicitly defining clock nodes within device tree node.
Signed-off-by: Ravi Gunasekaran
---
drivers/phy/ti/phy-j721e-wiz.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 23397175d3..34314d0bd1 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -256,6 +256,7 @@ enum wiz_type {
J721E_WIZ_10G,
AM64_WIZ_10G,
J784S4_WIZ_10G,
+ J721S2_WIZ_10G,
};
struct wiz_data {
@@ -307,6 +308,15 @@ static struct wiz_data j784s4_wiz_10g = {
.clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
};
+static struct wiz_data j721s2_10g_data = {
+ .type = J721S2_WIZ_10G,
+ .pll0_refclk_mux_sel = _refclk_mux_sel,
+ .pll1_refclk_mux_sel = _refclk_mux_sel,
+ .refclk_dig_sel = _dig_sel_10g,
+ .clk_mux_sel = clk_mux_sel_10g,
+ .clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
+};
+
#define WIZ_TYPEC_DIR_DEBOUNCE_MIN 100 /* ms */
#define WIZ_TYPEC_DIR_DEBOUNCE_MAX 1000
@@ -1037,8 +1047,14 @@ static int j721e_wiz_bind_of_clocks(struct wiz *wiz)
ofnode node;
int i, rc;
- if (type == AM64_WIZ_10G || type == J784S4_WIZ_10G)
+ switch (type) {
+ case AM64_WIZ_10G:
+ case J784S4_WIZ_10G:
+ case J721S2_WIZ_10G:
return j721e_wiz_bind_clocks(wiz);
+ default:
+ break;
+ };
div_clk_drv = lists_driver_lookup_name("wiz_div_clk");
if (!div_clk_drv) {
@@ -1282,6 +1298,9 @@ static const struct udevice_id j721e_wiz_ids[] = {
{
.compatible = "ti,j784s4-wiz-10g", .data =
(ulong)_wiz_10g,
},
+ {
+ .compatible = "ti,j721s2-wiz-10g", .data =
(ulong)_10g_data,
+ },
{}
};
base-commit: eaa9efafffaf87e3414db5d21face5e2dad105e4
--
2.17.1
Re: [EXTERNAL] Re: [PATCH] usb: cdns3: gadget.c: Set fast access bit
Pawel, On 11/05/23 11:00 am, Pawel Laszczak wrote: >> >> +Pawel & Peter >> >> On 09/05/2023 08:58, Ravi Gunasekaran wrote: >>> Hi Roger, >>> >>> On 05/05/23 6:02 pm, Roger Quadros wrote: >>>> Hi Ravi, >>>> >>>> On 05/05/2023 15:13, Ravi Gunasekaran wrote: >>>>> From: Aswath Govindraju >>>>> >>>>> When the device port is in a low power state [U3/L2/Not Connected], >>>>> accesses to usb device registers may take a long time. This could >>>>> lead to potential core hang when the controller registers are >>>>> accessed after the port is disabled by setting DEVDS field. Setting >>>>> the fast register access bit ensures that the PHY clock is keeping up in >> active state. >>>>> >>>>> Therefore, set fast access bit to ensure the accesses to device >>>>> registers are quick even in low power states. >>>>> >>>>> Signed-off-by: Aswath Govindraju >>>>> --- >>>>> drivers/usb/cdns3/gadget.c | 4 >>>>> 1 file changed, 4 insertions(+) >>>>> >>>>> diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c >>>>> index fcaeab9cc1..fddc8c931a 100644 >>>>> --- a/drivers/usb/cdns3/gadget.c >>>>> +++ b/drivers/usb/cdns3/gadget.c >>>>> @@ -2321,6 +2321,9 @@ static void cdns3_gadget_config(struct >> cdns3_device *priv_dev) >>>>> writel(USB_IEN_INIT, >usb_ien); >>>>> writel(USB_CONF_CLK2OFFDS | USB_CONF_L1DS, >usb_conf); >>>>> >>>>> + /* Set the Fast access bit */ >>>>> + writel(PUSB_PWR_FST_REG_ACCESS, _dev->regs->usb_pwr); >>>>> + >>>> >>>> Should this be done in cdns3_gadget_udc_start() so it is symmetric? >>>> >>> >>> cdns3_gadget_config() is called in cdns3_gadget_udc_start() and >>> cdns3_gadget_resume(). These settings seems to be needed during resume >>> as well. >> >> But this bit was never cleared in suspend so why do you need to set it again >> it >> in resume? >> > > In my opinion setting PUSB_PWR_FST_REG_ACCESS is not needed in > cdns3_gadget_resume, but it should not have any negative impact for > driver. The cdns3_gadget_config function seems like a good place for > setting this bit. > In the suspend(), USB_CONF_CFGRST (register: usb_conf.CFGRST) is set, resetting the USB device configuration. Does this mean PUSB_PWR_FST_REG_ACCESS will also be reset? Regards, Ravi > Regards, > Pawel Laszczak > >> The commit log says that this bit must be kept set in low power states. >> >>> >>>>> cdns3_configure_dmult(priv_dev, NULL); >>>>> >>>>> cdns3_gadget_pullup(_dev->gadget, 1); @@ -2378,6 +2381,7 >> @@ >>>>> static int cdns3_gadget_udc_stop(struct usb_gadget *gadget) >>>>> >>>>> /* disable interrupt for device */ >>>>> writel(0, _dev->regs->usb_ien); >>>>> + writel(0, _dev->regs->usb_pwr); >>>>> writel(USB_CONF_DEVDS, _dev->regs->usb_conf); >>>>> >>>>> return ret; >>>>> >>>>> base-commit: a25dcda452bf6a6de72764a8d990d72e5def643d >>>> >> >> -- >> cheers, >> -roger
Re: [EXTERNAL] Re: [PATCH] usb: cdns3: gadget.c: Set fast access bit
Hi Roger, On 05/05/23 6:02 pm, Roger Quadros wrote: > Hi Ravi, > > On 05/05/2023 15:13, Ravi Gunasekaran wrote: >> From: Aswath Govindraju >> >> When the device port is in a low power state [U3/L2/Not Connected], >> accesses to usb device registers may take a long time. This could lead to >> potential core hang when the controller registers are accessed after the >> port is disabled by setting DEVDS field. Setting the fast register access >> bit ensures that the PHY clock is keeping up in active state. >> >> Therefore, set fast access bit to ensure the accesses to device registers >> are quick even in low power states. >> >> Signed-off-by: Aswath Govindraju >> --- >> drivers/usb/cdns3/gadget.c | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c >> index fcaeab9cc1..fddc8c931a 100644 >> --- a/drivers/usb/cdns3/gadget.c >> +++ b/drivers/usb/cdns3/gadget.c >> @@ -2321,6 +2321,9 @@ static void cdns3_gadget_config(struct cdns3_device >> *priv_dev) >> writel(USB_IEN_INIT, >usb_ien); >> writel(USB_CONF_CLK2OFFDS | USB_CONF_L1DS, >usb_conf); >> >> +/* Set the Fast access bit */ >> +writel(PUSB_PWR_FST_REG_ACCESS, _dev->regs->usb_pwr); >> + > > Should this be done in cdns3_gadget_udc_start() so it is symmetric? > cdns3_gadget_config() is called in cdns3_gadget_udc_start() and cdns3_gadget_resume(). These settings seems to be needed during resume as well. >> cdns3_configure_dmult(priv_dev, NULL); >> >> cdns3_gadget_pullup(_dev->gadget, 1); >> @@ -2378,6 +2381,7 @@ static int cdns3_gadget_udc_stop(struct usb_gadget >> *gadget) >> >> /* disable interrupt for device */ >> writel(0, _dev->regs->usb_ien); >> +writel(0, _dev->regs->usb_pwr); >> writel(USB_CONF_DEVDS, _dev->regs->usb_conf); >> >> return ret; >> >> base-commit: a25dcda452bf6a6de72764a8d990d72e5def643d > > cheers, > -roger -- Regards, Ravi
[PATCH] usb: cdns3: gadget.c: Set fast access bit
From: Aswath Govindraju When the device port is in a low power state [U3/L2/Not Connected], accesses to usb device registers may take a long time. This could lead to potential core hang when the controller registers are accessed after the port is disabled by setting DEVDS field. Setting the fast register access bit ensures that the PHY clock is keeping up in active state. Therefore, set fast access bit to ensure the accesses to device registers are quick even in low power states. Signed-off-by: Aswath Govindraju --- drivers/usb/cdns3/gadget.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c index fcaeab9cc1..fddc8c931a 100644 --- a/drivers/usb/cdns3/gadget.c +++ b/drivers/usb/cdns3/gadget.c @@ -2321,6 +2321,9 @@ static void cdns3_gadget_config(struct cdns3_device *priv_dev) writel(USB_IEN_INIT, >usb_ien); writel(USB_CONF_CLK2OFFDS | USB_CONF_L1DS, >usb_conf); + /* Set the Fast access bit */ + writel(PUSB_PWR_FST_REG_ACCESS, _dev->regs->usb_pwr); + cdns3_configure_dmult(priv_dev, NULL); cdns3_gadget_pullup(_dev->gadget, 1); @@ -2378,6 +2381,7 @@ static int cdns3_gadget_udc_stop(struct usb_gadget *gadget) /* disable interrupt for device */ writel(0, _dev->regs->usb_ien); + writel(0, _dev->regs->usb_pwr); writel(USB_CONF_DEVDS, _dev->regs->usb_conf); return ret; base-commit: a25dcda452bf6a6de72764a8d990d72e5def643d -- 2.17.1
Re: [PATCH v2 0/8] Add DFU, emmc and usb boot for TI am62x
On 07/04/23 12:25 am, Sjoerd Simons wrote: > This series adds more boot sources for the TI am62x. For that the dts' > are synced from the upstream ti-next git tree (to add usb nodes), some > dwc3 glue is and finally the default configuration is tuned to add > support for DFU and USB (host and gadget) > > > Changes in v2: > - Update dts sync to v6.3-rc5 > - Switch dwc3 glue to a seperate driver rather then in dwc-generic > - Minimize config changes to just DFU configuration > - Only enable usb port 0 DFU in SPL > - Create a seperate defconfig for R5 > > Sjoerd Simons (8): > omap: timer: add ti,am654-timer compatibility > arm: mach-k3: am62: Add timer0 id to the dev list > arm: dts: k3-am62: Bump dtsi from linux > arm: dts: k3-am625-sk: Enable emmc in SPL > usb: dwc3: Add dwc3 glue driver for am62 > configs: am62: Add configs for enabling USB in U-Boot > arm: dts: k3-am625-sk: Enable usb ports in u-boot > configs: am62x_evm_*: Enable USB and DFU support > > arch/arm/dts/k3-am62-main.dtsi| 259 +++--- > arch/arm/dts/k3-am62-mcu.dtsi | 49 + > arch/arm/dts/k3-am62-wakeup.dtsi | 4 +- > arch/arm/dts/k3-am625-r5-sk.dts | 2 +- > arch/arm/dts/k3-am625-sk-u-boot.dtsi | 27 ++- > arch/arm/dts/k3-am625-sk.dts | 95 +- > arch/arm/dts/k3-am625.dtsi| 52 ++ > arch/arm/mach-k3/am62x/dev-data.c | 1 + > configs/am62x_evm_a53_defconfig | 35 +++- > configs/am62x_evm_r5_usbdfu_defconfig | 116 > drivers/timer/omap-timer.c| 1 + > drivers/usb/dwc3/Kconfig | 14 ++ > drivers/usb/dwc3/Makefile | 1 + > drivers/usb/dwc3/dwc3-am62.c | 127 + > include/configs/am62x_evm.h | 10 +- > 15 files changed, 701 insertions(+), 92 deletions(-) > create mode 100644 configs/am62x_evm_r5_usbdfu_defconfig > create mode 100644 drivers/usb/dwc3/dwc3-am62.c I tested USB DFU boot on AM62 and it works fine. Tested-by: Ravi Gunasekaran -- Regards, Ravi
Re: [PATCH v2 0/5] enable DMA and CPSW nodes for am62ax SoC family
Bryan, On 03/04/23 3:06 am, Bryan Brattlof wrote: > Hello again everyone! > > This patch series syncs TI's am62ax device tree files with what has been > merged in the v6.3-rc4 of the Linux Kernel. This series will also enable > YMODEM support to make automated testing (which uses the UART boot > method to load the bootloaders) > > Thanks for reviewing > ~Bryan > > Changed from v1: [0] > > o Rebased on top of -next branch > o dropped 'u-boot,dm-spl' for the new 'bootph-pre-ram' properties > > [0] https://lore.kernel.org/u-boot/20230327184035.2128786-1...@ti.com/ > > Bryan Brattlof (4): > arm: dts: sync am62ax dtbs with linux v6.3-rc4 > arm: dts: add DMA and CPSW nodes for uboot > configs: enable net features for am62ax > configs: am62ax: enable ymodem support for a53 spl > > Vignesh Raghavendra (1): > dma: ti: k3-udma: Introduce DMA support for the am62ax > > arch/arm/dts/k3-am62a-main.dtsi | 365 ++ > arch/arm/dts/k3-am62a-mcu.dtsi| 51 > arch/arm/dts/k3-am62a-wakeup.dtsi | 2 +- > arch/arm/dts/k3-am62a7-r5-sk.dts | 8 + > arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 26 +- > arch/arm/dts/k3-am62a7-sk.dts | 70 + > arch/arm/dts/k3-am62a7.dtsi | 1 + > configs/am62ax_evm_a53_defconfig | 7 +- > drivers/dma/ti/Makefile | 1 + > drivers/dma/ti/k3-psil-am62a.c| 196 ++ > drivers/dma/ti/k3-psil-priv.h | 1 + > drivers/dma/ti/k3-psil.c | 2 + > 12 files changed, 727 insertions(+), 3 deletions(-) > create mode 100644 drivers/dma/ti/k3-psil-am62a.c > > > base-commit: 942ac73afc37fb98695af4489ea1549c21615a5e Acked-by: Ravi Gunasekaran -- Regards, Ravi
Re: [PATCH 3/5] arm: dts: add DMA and CPSW nodes for uboot
Hi Bryan,
On 28/03/23 12:10 am, Bryan Brattlof wrote:
> Update the uboot dtsi to enable DMA and CPSW at the uboot level
>
> Signed-off-by: Bryan Brattlof
> ---
> arch/arm/dts/k3-am62a7-r5-sk.dts | 8
> arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 26 +-
> 2 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/k3-am62a7-r5-sk.dts
> b/arch/arm/dts/k3-am62a7-r5-sk.dts
> index 58b7c8ad050fd..ea2e202237556 100644
> --- a/arch/arm/dts/k3-am62a7-r5-sk.dts
> +++ b/arch/arm/dts/k3-am62a7-r5-sk.dts
> @@ -141,3 +141,11 @@
> status = "okay";
> u-boot,dm-spl;
> };
> +
> +_pktdma {
> + ti,sci = <_tifs>;
> +};
> +
> +_bcdma {
> + ti,sci = <_tifs>;
> +};
> diff --git a/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
> b/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
> index 7fc749ed70976..07ade7120cfe5 100644
> --- a/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
> @@ -15,7 +15,7 @@
> };
> };
>
> -_main{
> +_main {
> u-boot,dm-spl;
>
> timer1: timer@240 {
> @@ -138,3 +138,27 @@
> _mmc1 {
> u-boot,dm-spl;
> };
> +
> +_bcdma {
> + u-boot,dm-spl;
> +};
"u-boot,dm-spl" is now "bootph-pre-ram". The changes are present in -next.
For the existing DT source files, these have already been taken care of [0]
So please base on -next. Otherwise the series LGTM
[0] https://lore.kernel.org/all/20230213155641.1208774-4-...@chromium.org/
> +
> +_pktdma {
> + u-boot,dm-spl;
> +};
> +
> + {
> + reg = <0x00 0x0800 0x00 0x20>,
> + <0x00 0x43000200 0x00 0x8>;
> + reg-names = "cpsw_nuss", "mac_efuse";
> + /delete-property/ ranges;
> + pinctrl-0 = <_mdio1_pins_default
> + _rgmii1_pins_default>;
> + u-boot,dm-spl;
> +
> + cpsw-phy-sel@04044 {
> + compatible = "ti,am64-phy-gmii-sel";
> + reg = <0x00 0x00104044 0x00 0x8>;
> + u-boot,dm-spl;
> + };
> +};
--
Regards,
Ravi
Re: [EXTERNAL] [PATCH 0/2] phy: ti: j721e-wiz: Add support to manage type-C swap on Lane2 and lane3
On 13/03/23 6:12 pm, Sinthu Raja wrote: > From: Sinthu Raja > > Hi All, > This series of patch add support to enable lane2 and lane3 swap by > configuring the LN23 bit. Also, it's possible that the Type-C plug orientation > on the DIR line will be implemented through hardware design. In that > situation, there won't be an external GPIO line available, but the > driver still needs to address this since the DT won't use the > typec-gpio-dir property. Update code to handle if typec-dir-gpios property > is not specified in DT. > > Sinthu Raja (2): > phy: ti: j721e-wiz: Manage TypeC lane swap if typec-dir-gpios not > specified > phy: ti: j721e-wiz: Add support to enable LN23 Type-C swap > > drivers/phy/ti/phy-j721e-wiz.c | 58 -- > 1 file changed, 49 insertions(+), 9 deletions(-) > Reviewed-by: Ravi Gunasekaran -- Regards, Ravi
[PATCH 1/2] net: ti: cpsw-mdio: Add workaround for errata i2329
In certain TI SoCs, on the CPSW and ICSS peripherals, there is
a possibility that the MDIO interface returns corrupt data on
MDIO reads or writes incorrect data on MDIO writes. There is also
a possibility for the MDIO interface to become unavailable until
the next peripheral reset.
The workaround is to configure the MDIO in manual mode and disable the
MDIO state machine and emulate the MDIO protocol by reading and writing
appropriate fields in MDIO_MANUAL_IF_REG register of the MDIO controller
to manipulate the MDIO clock and data pins.
More details about the errata i2329 and the workaround is available in:
https://www.ti.com/lit/er/sprz487a/sprz487a.pdf
Add implementation to disable MDIO state machine, configure MDIO in manual
mode and provide software MDIO read and writes via MDIO bitbanging. Allow
the MDIO to be initialized based on the need for manual mode.
Signed-off-by: Ravi Gunasekaran
---
drivers/net/ti/am65-cpsw-nuss.c | 3 +-
drivers/net/ti/cpsw.c | 3 +-
drivers/net/ti/cpsw_mdio.c | 255 +++-
drivers/net/ti/cpsw_mdio.h | 2 +-
drivers/net/ti/keystone_net.c | 3 +-
5 files changed, 258 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 9580fa37ea..29c0422961 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -552,7 +552,8 @@ static int am65_cpsw_mdio_init(struct udevice *dev)
cpsw_common->bus = cpsw_mdio_init(dev->name,
cpsw_common->mdio_base,
cpsw_common->bus_freq,
- clk_get_rate(_common->fclk));
+ clk_get_rate(_common->fclk),
+ false);
if (!cpsw_common->bus)
return -EFAULT;
diff --git a/drivers/net/ti/cpsw.c b/drivers/net/ti/cpsw.c
index 8988c21e66..41cba7930d 100644
--- a/drivers/net/ti/cpsw.c
+++ b/drivers/net/ti/cpsw.c
@@ -922,7 +922,8 @@ int _cpsw_register(struct cpsw_priv *priv)
idx = idx + 1;
}
- priv->bus = cpsw_mdio_init(priv->dev->name, data->mdio_base, 0, 0);
+ priv->bus = cpsw_mdio_init(priv->dev->name, data->mdio_base, 0, 0,
+ false);
if (!priv->bus)
return -EFAULT;
diff --git a/drivers/net/ti/cpsw_mdio.c b/drivers/net/ti/cpsw_mdio.c
index f4cb86d10a..a5ba73b739 100644
--- a/drivers/net/ti/cpsw_mdio.c
+++ b/drivers/net/ti/cpsw_mdio.c
@@ -23,6 +23,11 @@ struct cpsw_mdio_regs {
#define CONTROL_FAULT_ENABLE BIT(18)
#define CONTROL_DIV_MASK GENMASK(15, 0)
+#define MDIO_MAN_MDCLK_OBIT(2)
+#define MDIO_MAN_OE BIT(1)
+#define MDIO_MAN_PINBIT(0)
+#define MDIO_MANUALMODE BIT(31)
+
u32 alive;
u32 link;
u32 linkintraw;
@@ -32,7 +37,9 @@ struct cpsw_mdio_regs {
u32 userintmasked;
u32 userintmaskset;
u32 userintmaskclr;
- u32 __reserved_1[20];
+ u32 manualif;
+ u32 poll;
+ u32 __reserved_1[18];
struct {
u32 access;
@@ -51,6 +58,13 @@ struct cpsw_mdio_regs {
#define PHY_REG_MASK 0x1f
#define PHY_ID_MASK0x1f
+#define MDIO_BITRANGE 0x8000
+#define C22_READ_PATTERN0x6
+#define C22_WRITE_PATTERN 0x5
+#define C22_BITRANGE0x8
+#define PHY_BITRANGE0x10
+#define PHY_DATA_BITRANGE 0x8000
+
/*
* This timeout definition is a worst-case ultra defensive measure against
* unexpected controller lock ups. Ideally, we should never ever hit this
@@ -58,12 +72,239 @@ struct cpsw_mdio_regs {
*/
#define CPSW_MDIO_TIMEOUT100 /* msecs */
+enum cpsw_mdio_manual {
+ MDIO_PIN = 0,
+ MDIO_OE,
+ MDIO_MDCLK,
+};
+
struct cpsw_mdio {
struct cpsw_mdio_regs *regs;
struct mii_dev *bus;
int div;
};
+static void cpsw_mdio_disable(struct cpsw_mdio *mdio)
+{
+ u32 reg;
+ /* Disable MDIO state machine */
+ reg = readl(>regs->control);
+ reg &= ~CONTROL_ENABLE;
+
+ writel(reg, >regs->control);
+}
+
+static void cpsw_mdio_enable_manual_mode(struct cpsw_mdio *mdio)
+{
+ u32 reg;
+
+ /* set manual mode */
+ reg = readl(>regs->poll);
+ reg |= MDIO_MANUALMODE;
+
+ writel(reg, >regs->poll);
+}
+
+static void cpsw_mdio_sw_set_bit(struct cpsw_mdio *mdio,
+enum cpsw_mdio_manual bit)
+{
+ u32 reg;
+
+ reg = readl(>regs->manualif);
+
+ switch (bit) {
+ case MDIO_OE:
+ reg |= MDIO_MAN_OE;
+ writel(reg, >regs->manualif);
+ break;
+ case MDIO_PIN:
+
[PATCH 2/2] net: ti: am65-cpsw-nuss: Enable MDIO manual mode
For the TI SoCs affected by errata i2329, enable MDIO manual
mode by default
Signed-off-by: Ravi Gunasekaran
---
drivers/net/ti/am65-cpsw-nuss.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 29c0422961..5ef04e3d83 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -127,6 +128,8 @@ struct am65_cpsw_priv {
boolhas_phy;
ofnode phy_node;
u32 phy_addr;
+
+ boolmdio_manual_mode;
};
#ifdef PKTSIZE_ALIGN
@@ -541,6 +544,20 @@ static const struct eth_ops am65_cpsw_ops = {
.read_rom_hwaddr = am65_cpsw_read_rom_hwaddr,
};
+static const struct soc_attr k3_mdio_soc_data[] = {
+ { .family = "AM62X", .revision = "SR1.0" },
+ { .family = "AM64X", .revision = "SR1.0" },
+ { .family = "AM64X", .revision = "SR2.0" },
+ { .family = "AM65X", .revision = "SR1.0" },
+ { .family = "AM65X", .revision = "SR2.0" },
+ { .family = "J7200", .revision = "SR1.0" },
+ { .family = "J7200", .revision = "SR2.0" },
+ { .family = "J721E", .revision = "SR1.0" },
+ { .family = "J721E", .revision = "SR1.1" },
+ { .family = "J721S2", .revision = "SR1.0" },
+ { /* sentinel */ },
+};
+
static int am65_cpsw_mdio_init(struct udevice *dev)
{
struct am65_cpsw_priv *priv = dev_get_priv(dev);
@@ -553,7 +570,7 @@ static int am65_cpsw_mdio_init(struct udevice *dev)
cpsw_common->mdio_base,
cpsw_common->bus_freq,
clk_get_rate(_common->fclk),
- false);
+ priv->mdio_manual_mode);
if (!cpsw_common->bus)
return -EFAULT;
@@ -658,6 +675,10 @@ static int am65_cpsw_port_probe(struct udevice *dev)
sprintf(portname, "%s%s", dev->parent->name, dev->name);
device_set_name(dev, portname);
+ priv->mdio_manual_mode = false;
+ if (soc_device_match(k3_mdio_soc_data))
+ priv->mdio_manual_mode = true;
+
ret = am65_cpsw_ofdata_parse_phy(dev);
if (ret)
goto out;
--
2.17.1
[PATCH 0/2] Implement workaround for errata i2329
This patch series adds the MDIO workaround for the errata i2329. On certain TI SoC's CPSW and ICSS peripherals, there is a possibility that the MDIO interface returns corrupt data on MDIO reads or writes incorrect data on MDIO writes. There is also a possibility for the MDIO interface to become unavailable until the next peripheral reset. The workaround is to configure the MDIO in manual mode and disable the MDIO state machine and emulate the MDIO protocol by reading and writing appropriate fields in MDIO_MANUAL_IF_REG register of the MDIO controller to manipulate the MDIO clock and data pins. Ravi Gunasekaran (2): net: ti: cpsw-mdio: Add workaround for errata i2329 net: ti: am65-cpsw-nuss: Enable MDIO manual mode drivers/net/ti/am65-cpsw-nuss.c | 24 ++- drivers/net/ti/cpsw.c | 3 +- drivers/net/ti/cpsw_mdio.c | 255 +++- drivers/net/ti/cpsw_mdio.h | 2 +- drivers/net/ti/keystone_net.c | 3 +- 5 files changed, 279 insertions(+), 8 deletions(-) -- 2.17.1
