[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Chin Liang See]

Per DesignWare USB OTG databook, driver should retry up to
3 times when transaction error (hcint.xacterr) happen. But
the 3 times doesn't count when the response is nack
(hcint.nak) or frame overrun (hcint.frmoverun)

This patch solved the enumeration error as spotted at socfpga
cyclone5_socdk when plugging in certain pendrive.

Signed-off-by: Chin Liang See <clsee@altera.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Dinh Nguyen <dinh.linux@gmail.com>
Cc: Pavel Machek <pavel@denx.de>
Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Alexander Stein <alexanders83@web.de>
Cc: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/usb/host/dwc2.c | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 541c0f9..f00cd1b 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -786,15 +786,12 @@ int chunk_msg(struct dwc2_priv *priv, struct usb_device *dev,
 	uint32_t xfer_len;
 	uint32_t num_packets;
 	int stop_transfer = 0;
+	int error_retry_count = 0;
 
 	debug("%s: msg: pipe %lx pid %d in %d len %d\n", __func__, pipe, *pid,
 	      in, len);
 
 	do {
-		/* Initialize channel */
-		dwc_otg_hc_init(regs, DWC2_HC_CHANNEL, dev, devnum, ep, in,
-				eptype, max);
-
 		xfer_len = len - done;
 		if (xfer_len > CONFIG_DWC2_MAX_TRANSFER_SIZE)
 			xfer_len = CONFIG_DWC2_MAX_TRANSFER_SIZE - max + 1;
@@ -818,6 +815,14 @@ int chunk_msg(struct dwc2_priv *priv, struct usb_device *dev,
 		debug("%s: chunk: pid %d xfer_len %u pkts %u\n", __func__,
 		      *pid, xfer_len, num_packets);
 
+		/* per DW spec, we can retry up to 3 times */
+		error_retry_count = 3;
+
+error_retry:
+		/* Initialize channel */
+		dwc_otg_hc_init(regs, DWC2_HC_CHANNEL, dev, devnum, ep, in,
+				eptype, max);
+
 		writel((xfer_len << DWC2_HCTSIZ_XFERSIZE_OFFSET) |
 		       (num_packets << DWC2_HCTSIZ_PKTCNT_OFFSET) |
 		       (*pid << DWC2_HCTSIZ_PID_OFFSET),
@@ -841,8 +846,14 @@ int chunk_msg(struct dwc2_priv *priv, struct usb_device *dev,
 				DWC2_HCCHAR_CHEN);
 
 		ret = wait_for_chhltd(regs, &sub, pid, ignore_ack);
-		if (ret)
-			break;
+		if (ret) {
+			if (ret == -EINVAL)
+				error_retry_count--;
+			if (error_retry_count)
+				goto error_retry;
+			else
+				break;
+		}
 
 		if (in) {
 			xfer_len -= sub;
-- 
1.9.2.468.g3f0c02a

[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Marek Vasut]

On Tuesday, January 05, 2016 at 06:00:04 AM, Chin Liang See wrote:
> Per DesignWare USB OTG databook, driver should retry up to
> 3 times when transaction error (hcint.xacterr) happen. But
> the 3 times doesn't count when the response is nack
> (hcint.nak) or frame overrun (hcint.frmoverun)
> 
> This patch solved the enumeration error as spotted at socfpga
> cyclone5_socdk when plugging in certain pendrive.
> 
> Signed-off-by: Chin Liang See <clsee@altera.com>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> Cc: Dinh Nguyen <dinh.linux@gmail.com>
> Cc: Pavel Machek <pavel@denx.de>
> Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Alexander Stein <alexanders83@web.de>
> Cc: Peter Griffin <peter.griffin@linaro.org>

I applied this change on top of u-boot-socfpga/master and tested it on
SoCFPGA CycloneV SoCDK with "Sandisk cruzer force" stick. The board gets 
completely stuck if I have dcache ENABLED and perform 'usb reset'. This
patch is:

Naked-by: Marek Vasut <marex@denx.de>

Sorry :-(

Best regards,
Marek Vasut

[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Chin Liang See]

On Tue, 2016-01-05 at 15:36 +0100, Marek Vasut wrote:
> On Tuesday, January 05, 2016 at 06:00:04 AM, Chin Liang See wrote:
> > Per DesignWare USB OTG databook, driver should retry up to
> > 3 times when transaction error (hcint.xacterr) happen. But
> > the 3 times doesn't count when the response is nack
> > (hcint.nak) or frame overrun (hcint.frmoverun)
> > 
> > This patch solved the enumeration error as spotted at socfpga
> > cyclone5_socdk when plugging in certain pendrive.
> > 
> > Signed-off-by: Chin Liang See <clsee@altera.com>
> > Cc: Marek Vasut <marex@denx.de>
> > Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> > Cc: Dinh Nguyen <dinh.linux@gmail.com>
> > Cc: Pavel Machek <pavel@denx.de>
> > Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>
> > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > Cc: Alexander Stein <alexanders83@web.de>
> > Cc: Peter Griffin <peter.griffin@linaro.org>
> 
> I applied this change on top of u-boot-socfpga/master and tested it
> on
> SoCFPGA CycloneV SoCDK with "Sandisk cruzer force" stick. The board
> gets 
> completely stuck if I have dcache ENABLED and perform 'usb reset'.
> This
> patch is:
> 

Thanks Marek for testing. I managed to find a SanDisk Cruzer Blade and
notice the same fail behaviours as yours. FYI, note that this patch
works well with other 3 pendrive that I have.

With SanDisk, the dwc2 driver was timed out as hcint.xfercomp and
chhltd never get set even after 1s. It keep retrying endlessly due to
miss handling for the ETIMEDOUT within this patch. 

In short, the retry doesn't work for SanDisk but the dcache disable
works. Need to figure out more what cause the failure.

Thanks
Chin Liang

[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Marek Vasut]

On Tuesday, January 05, 2016 at 04:51:47 PM, Chin Liang See wrote:
> On Tue, 2016-01-05 at 15:36 +0100, Marek Vasut wrote:
> > On Tuesday, January 05, 2016 at 06:00:04 AM, Chin Liang See wrote:
> > > Per DesignWare USB OTG databook, driver should retry up to
> > > 3 times when transaction error (hcint.xacterr) happen. But
> > > the 3 times doesn't count when the response is nack
> > > (hcint.nak) or frame overrun (hcint.frmoverun)
> > > 
> > > This patch solved the enumeration error as spotted at socfpga
> > > cyclone5_socdk when plugging in certain pendrive.
> > > 
> > > Signed-off-by: Chin Liang See <clsee@altera.com>
> > > Cc: Marek Vasut <marex@denx.de>
> > > Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> > > Cc: Dinh Nguyen <dinh.linux@gmail.com>
> > > Cc: Pavel Machek <pavel@denx.de>
> > > Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>
> > > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > > Cc: Alexander Stein <alexanders83@web.de>
> > > Cc: Peter Griffin <peter.griffin@linaro.org>
> > 
> > I applied this change on top of u-boot-socfpga/master and tested it
> > on
> > SoCFPGA CycloneV SoCDK with "Sandisk cruzer force" stick. The board
> > gets
> > completely stuck if I have dcache ENABLED and perform 'usb reset'.
> > This
> 
> > patch is:
> Thanks Marek for testing. I managed to find a SanDisk Cruzer Blade and
> notice the same fail behaviours as yours. FYI, note that this patch
> works well with other 3 pendrive that I have.
> 
> With SanDisk, the dwc2 driver was timed out as hcint.xfercomp and
> chhltd never get set even after 1s. It keep retrying endlessly due to
> miss handling for the ETIMEDOUT within this patch.
> 
> In short, the retry doesn't work for SanDisk but the dcache disable
> works. Need to figure out more what cause the failure.

Excellent, I have one of those too (I bought the entire lineup of these
sandisk sticks at one point ;-) )

Best regards,
Marek Vasut

[U-Boot] usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Pavel Machek]

Hi!

After updating from 2016-rc1, I get this compile error:

  CC      common/main.o
  drivers/usb/host/dwc2.c: In function 'usb_lowlevel_init':
  drivers/usb/host/dwc2.c:1028:40: error: 'CONFIG_USB_DWC2_REG_ADDR'
  undeclared (first use in this function)
    priv->regs = (struct dwc2_core_regs *)CONFIG_USB_DWC2_REG_ADDR;
                                            ^
make mrproper socfpga_cyclone5_config

Fixes the problem.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Pavel Machek]

On Sun 2016-01-10 12:56:15, Pavel Machek wrote:
> Hi!
> 
> After updating from 2016-rc1, I get this compile error:
> 
>   CC      common/main.o
>   drivers/usb/host/dwc2.c: In function 'usb_lowlevel_init':
>   drivers/usb/host/dwc2.c:1028:40: error: 'CONFIG_USB_DWC2_REG_ADDR'
>   undeclared (first use in this function)
>     priv->regs = (struct dwc2_core_regs *)CONFIG_USB_DWC2_REG_ADDR;
>                                             ^
> make mrproper socfpga_cyclone5_config
> 
> Fixes the problem.

Well, it "fixes" the problem by not compiling dwc2.

Socfpga clearly wants DWC2:

include/configs/socfpga_common.h:#define CONFIG_USB_DWC2
include/configs/socfpga_common.h:#define CONFIG_USB_GADGET_DWC2_OTG

But does not contain required address:

[pavel at pollux u-boot]$ grep -ri USB_DWC2_REG_ADDR .
./drivers/usb/host/dwc2.c:  priv->regs = (struct dwc2_core_regs *)CONFIG_USB_DWC2_REG_ADDR;
./README:		CONFIG_USB_DWC2_REG_ADDR the physical CPU address of the DWC2
./include/configs/hikey.h:#define CONFIG_USB_DWC2_REG_ADDR 0xF72C0000
./include/configs/rpi-common.h:#define CONFIG_USB_DWC2_REG_ADDR 0x3f980000
./include/configs/rpi-common.h:#define CONFIG_USB_DWC2_REG_ADDR 0x20980000

Plus, make socfpga_cyclone5_config does not enable USB, which is
probably error.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Marek Vasut]

On Sunday, January 10, 2016 at 01:04:17 PM, Pavel Machek wrote:
> On Sun 2016-01-10 12:56:15, Pavel Machek wrote:
> > Hi!
> > 
> > After updating from 2016-rc1, I get this compile error:
> >   CC      common/main.o
> >   drivers/usb/host/dwc2.c: In function 'usb_lowlevel_init':
> >   drivers/usb/host/dwc2.c:1028:40: error: 'CONFIG_USB_DWC2_REG_ADDR'
> >   undeclared (first use in this function)
> >   
> >     priv->regs = (struct dwc2_core_regs *)CONFIG_USB_DWC2_REG_ADDR;
> >     
> >                                             ^
> > 
> > make mrproper socfpga_cyclone5_config
> > 
> > Fixes the problem.
> 
> Well, it "fixes" the problem by not compiling dwc2.
> 
> Socfpga clearly wants DWC2:
> 
> include/configs/socfpga_common.h:#define CONFIG_USB_DWC2
> include/configs/socfpga_common.h:#define CONFIG_USB_GADGET_DWC2_OTG
> 
> But does not contain required address:
> 
> [pavel at pollux u-boot]$ grep -ri USB_DWC2_REG_ADDR .
> ./drivers/usb/host/dwc2.c:  priv->regs = (struct dwc2_core_regs
> *)CONFIG_USB_DWC2_REG_ADDR; ./README:		CONFIG_USB_DWC2_REG_ADDR 
the
> physical CPU address of the DWC2 ./include/configs/hikey.h:#define
> CONFIG_USB_DWC2_REG_ADDR 0xF72C0000 ./include/configs/rpi-common.h:#define
> CONFIG_USB_DWC2_REG_ADDR 0x3f980000 ./include/configs/rpi-common.h:#define
> CONFIG_USB_DWC2_REG_ADDR 0x20980000
> 
> Plus, make socfpga_cyclone5_config does not enable USB, which is
> probably error.

SoCFPGA is using USB DM , so these base addresses are pulled from OF
and are no longer hard-coded.

Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can you please
test mainline _before_ reporting issues ?

Best regards,
Marek Vasut

[U-Boot] usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Pavel Machek]

On Sun 2016-01-10 14:45:54, Marek Vasut wrote:
> On Sunday, January 10, 2016 at 01:04:17 PM, Pavel Machek wrote:
> > On Sun 2016-01-10 12:56:15, Pavel Machek wrote:
> > > Hi!
> > > 
> > > After updating from 2016-rc1, I get this compile error:
> > >   CC      common/main.o
> > >   drivers/usb/host/dwc2.c: In function 'usb_lowlevel_init':
> > >   drivers/usb/host/dwc2.c:1028:40: error: 'CONFIG_USB_DWC2_REG_ADDR'
> > >   undeclared (first use in this function)
> > >   
> > >     priv->regs = (struct dwc2_core_regs *)CONFIG_USB_DWC2_REG_ADDR;
> > >     
> > >                                             ^
> > > 
> > > make mrproper socfpga_cyclone5_config
> > > 
> > > Fixes the problem.
> > 
> > Well, it "fixes" the problem by not compiling dwc2.
> > 
> > Socfpga clearly wants DWC2:
> > 
> > include/configs/socfpga_common.h:#define CONFIG_USB_DWC2
> > include/configs/socfpga_common.h:#define CONFIG_USB_GADGET_DWC2_OTG
> > 
> > But does not contain required address:
> > 
> > [pavel at pollux u-boot]$ grep -ri USB_DWC2_REG_ADDR .
> > ./drivers/usb/host/dwc2.c:  priv->regs = (struct dwc2_core_regs
> > *)CONFIG_USB_DWC2_REG_ADDR; ./README:		CONFIG_USB_DWC2_REG_ADDR 
> the
> > physical CPU address of the DWC2 ./include/configs/hikey.h:#define
> > CONFIG_USB_DWC2_REG_ADDR 0xF72C0000 ./include/configs/rpi-common.h:#define
> > CONFIG_USB_DWC2_REG_ADDR 0x3f980000 ./include/configs/rpi-common.h:#define
> > CONFIG_USB_DWC2_REG_ADDR 0x20980000
> > 
> > Plus, make socfpga_cyclone5_config does not enable USB, which is
> > probably error.
> 
> SoCFPGA is using USB DM , so these base addresses are pulled from OF
> and are no longer hard-coded.
> 
> Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can you please
> test mainline _before_ reporting issues ?

Can you please test mainline before complaining?

With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached .config, I
get the failure. No, CONFIG_DM_USB is not set in the config, which is
probably the problem.

Maybe socfpga should select DM_USB or depend on it?

    
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# U-Boot 2016.01-rc4 Configuration
#
CONFIG_CREATE_ARCH_SYMLINK=y
CONFIG_HAVE_GENERIC_BOARD=y
CONFIG_SYS_GENERIC_BOARD=y
# CONFIG_ARC is not set
CONFIG_ARM=y
# CONFIG_AVR32 is not set
# CONFIG_BLACKFIN is not set
# CONFIG_M68K is not set
# CONFIG_MICROBLAZE is not set
# CONFIG_MIPS is not set
# CONFIG_NDS32 is not set
# CONFIG_NIOS2 is not set
# CONFIG_OPENRISC is not set
# CONFIG_PPC is not set
# CONFIG_SANDBOX is not set
# CONFIG_SH is not set
# CONFIG_SPARC is not set
# CONFIG_X86 is not set
CONFIG_SYS_ARCH="arm"
CONFIG_SYS_CPU="armv7"
CONFIG_SYS_SOC="socfpga"
CONFIG_SYS_VENDOR="altera"
CONFIG_SYS_BOARD="cyclone5-socdk"
CONFIG_SYS_CONFIG_NAME="socfpga_cyclone5_socdk"

#
# ARM architecture
#
CONFIG_HAS_VBAR=y
CONFIG_HAS_THUMB2=y
CONFIG_CPU_V7=y
# CONFIG_SEMIHOSTING is not set
# CONFIG_SYS_L2CACHE_OFF is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_TARGET_EDB93XX is not set
# CONFIG_TARGET_VCMA9 is not set
# CONFIG_TARGET_SMDK2410 is not set
# CONFIG_TARGET_ASPENITE is not set
# CONFIG_TARGET_GPLUGD is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_KIRKWOOD is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_TARGET_DEVKIT3250 is not set
# CONFIG_TARGET_WORK_92105 is not set
# CONFIG_TARGET_MX25PDK is not set
# CONFIG_TARGET_ZMX25 is not set
# CONFIG_TARGET_APF27 is not set
# CONFIG_TARGET_APX4DEVKIT is not set
# CONFIG_TARGET_XFI3 is not set
# CONFIG_TARGET_M28EVK is not set
# CONFIG_TARGET_MX23EVK is not set
# CONFIG_TARGET_MX28EVK is not set
# CONFIG_TARGET_MX23_OLINUXINO is not set
# CONFIG_TARGET_BG0900 is not set
# CONFIG_TARGET_SANSA_FUZE_PLUS is not set
# CONFIG_TARGET_SC_SPS_1 is not set
# CONFIG_ORION5X is not set
# CONFIG_TARGET_SPEAR300 is not set
# CONFIG_TARGET_SPEAR310 is not set
# CONFIG_TARGET_SPEAR320 is not set
# CONFIG_TARGET_SPEAR600 is not set
# CONFIG_TARGET_STV0991 is not set
# CONFIG_TARGET_X600 is not set
# CONFIG_TARGET_IMX31_PHYCORE is not set
# CONFIG_TARGET_MX31ADS is not set
# CONFIG_TARGET_MX31PDK is not set
# CONFIG_TARGET_WOODBURN is not set
# CONFIG_TARGET_WOODBURN_SD is not set
# CONFIG_TARGET_FLEA3 is not set
# CONFIG_TARGET_MX35PDK is not set
# CONFIG_ARCH_BCM283X is not set
# CONFIG_TARGET_VEXPRESS_CA15_TC2 is not set
# CONFIG_TARGET_VEXPRESS_CA5X2 is not set
# CONFIG_TARGET_VEXPRESS_CA9X4 is not set
# CONFIG_TARGET_KWB is not set
# CONFIG_TARGET_TSERIES is not set
# CONFIG_TARGET_CM_T335 is not set
# CONFIG_TARGET_PEPPER is not set
# CONFIG_TARGET_AM335X_IGEP0033 is not set
# CONFIG_TARGET_PCM051 is not set
# CONFIG_TARGET_DRACO is not set
# CONFIG_TARGET_THUBAN is not set
# CONFIG_TARGET_RASTABAN is not set
# CONFIG_TARGET_PXM2 is not set
# CONFIG_TARGET_RUT is not set
# CONFIG_TARGET_PENGWYN is not set
# CONFIG_TARGET_AM335X_BALTOS is not set
# CONFIG_TARGET_AM335X_EVM is not set
# CONFIG_TARGET_AM335X_SL50 is not set
# CONFIG_TARGET_AM43XX_EVM is not set
# CONFIG_TARGET_BAV335X is not set
# CONFIG_TARGET_TI814X_EVM is not set
# CONFIG_TARGET_TI816X_EVM is not set
# CONFIG_TARGET_BCM28155_AP is not set
# CONFIG_TARGET_BCMCYGNUS is not set
# CONFIG_TARGET_BCMNSP is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_S5PC1XX is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_KEYSTONE is not set
# CONFIG_ARCH_MX7 is not set
# CONFIG_ARCH_MX6 is not set
# CONFIG_ARCH_MX5 is not set
# CONFIG_TARGET_M53EVK is not set
# CONFIG_TARGET_MX51EVK is not set
# CONFIG_TARGET_MX53ARD is not set
# CONFIG_TARGET_MX53EVK is not set
# CONFIG_TARGET_MX53LOCO is not set
# CONFIG_TARGET_MX53SMD is not set
# CONFIG_OMAP34XX is not set
# CONFIG_OMAP44XX is not set
# CONFIG_OMAP54XX is not set
# CONFIG_RMOBILE is not set
CONFIG_ARCH_SOCFPGA=y
# CONFIG_TARGET_CM_T43 is not set
# CONFIG_ARCH_SUNXI is not set
# CONFIG_TARGET_TS4800 is not set
# CONFIG_TARGET_VF610TWR is not set
# CONFIG_TARGET_COLIBRI_VF is not set
# CONFIG_TARGET_PCM052 is not set
# CONFIG_ARCH_ZYNQ is not set
# CONFIG_ARCH_ZYNQMP is not set
# CONFIG_TEGRA is not set
# CONFIG_TARGET_VEXPRESS64_AEMV8A is not set
# CONFIG_TARGET_VEXPRESS64_BASE_FVP is not set
# CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM is not set
# CONFIG_TARGET_VEXPRESS64_JUNO is not set
# CONFIG_TARGET_LS2080A_EMU is not set
# CONFIG_TARGET_LS2080A_SIMU is not set
# CONFIG_TARGET_LS2080AQDS is not set
# CONFIG_TARGET_LS2080ARDB is not set
# CONFIG_TARGET_HIKEY is not set
# CONFIG_TARGET_LS1021AQDS is not set
# CONFIG_TARGET_LS1021ATWR is not set
# CONFIG_TARGET_LS1043AQDS is not set
# CONFIG_TARGET_LS1043ARDB is not set
# CONFIG_TARGET_H2200 is not set
# CONFIG_TARGET_COLIBRI_PXA270 is not set
# CONFIG_ARCH_UNIPHIER is not set
# CONFIG_TARGET_STM32F429_DISCOVERY is not set
# CONFIG_ARCH_ROCKCHIP is not set
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_SYS_MALLOC_F=y
# CONFIG_SPL_SYS_MALLOC_SIMPLE is not set
CONFIG_SPL_DM=y
# CONFIG_DM_SERIAL is not set
CONFIG_DM_SPI=y
CONFIG_DM_SPI_FLASH=y
# CONFIG_DM_I2C is not set
CONFIG_DM_GPIO=y
CONFIG_TARGET_SOCFPGA_CYCLONE5=y
CONFIG_TARGET_SOCFPGA_GEN5=y
# CONFIG_TARGET_SOCFPGA_ARRIA5_SOCDK is not set
CONFIG_TARGET_SOCFPGA_CYCLONE5_SOCDK=y
# CONFIG_TARGET_SOCFPGA_DENX_MCVEVK is not set
# CONFIG_TARGET_SOCFPGA_SR1500 is not set
# CONFIG_TARGET_SOCFPGA_EBV_SOCRATES is not set
# CONFIG_TARGET_SOCFPGA_TERASIC_DE0_NANO is not set
# CONFIG_TARGET_SOCFPGA_TERASIC_SOCKIT is not set
CONFIG_SPL_STACK_R_ADDR=0x00800000

#
# ARM debug
#
# CONFIG_DEBUG_LL is not set
# CONFIG_DM_KEYBOARD is not set
CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_socdk"

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_EXPERT=y
CONFIG_SYS_MALLOC_CLEAR_ON_INIT=y

#
# Boot images
#
CONFIG_SUPPORT_SPL=y
CONFIG_SPL=y
CONFIG_SPL_STACK_R=y
# CONFIG_SPL_SEPARATE_BSS is not set
# CONFIG_FIT is not set
CONFIG_SYS_EXTRA_OPTIONS=""

#
# Command line interface
#
# CONFIG_HUSH_PARSER is not set
CONFIG_SYS_PROMPT="=> "

#
# Autoboot options
#
# CONFIG_AUTOBOOT_KEYED is not set

#
# Commands
#

#
# Info commands
#
CONFIG_CMD_BDI=y
CONFIG_CMD_CONSOLE=y
# CONFIG_CMD_CPU is not set
# CONFIG_CMD_LICENSE is not set

#
# Boot commands
#
CONFIG_CMD_BOOTD=y
CONFIG_CMD_BOOTM=y
# CONFIG_CMD_ELF is not set
CONFIG_CMD_GO=y
CONFIG_CMD_RUN=y
CONFIG_CMD_IMI=y
# CONFIG_CMD_IMLS is not set
CONFIG_CMD_XIMG=y

#
# Environment commands
#
CONFIG_CMD_EXPORTENV=y
CONFIG_CMD_IMPORTENV=y
CONFIG_CMD_EDITENV=y
CONFIG_CMD_SAVEENV=y
CONFIG_CMD_ENV_EXISTS=y

#
# Memory commands
#
CONFIG_CMD_MEMORY=y
CONFIG_CMD_CRC32=y
# CONFIG_LOOPW is not set
# CONFIG_CMD_MEMTEST is not set
# CONFIG_CMD_MX_CYCLIC is not set
# CONFIG_CMD_MEMINFO is not set

#
# Device access commands
#
CONFIG_CMD_DM=y
# CONFIG_CMD_DEMO is not set
CONFIG_CMD_LOADB=y
CONFIG_CMD_LOADS=y
# CONFIG_CMD_FLASH is not set
# CONFIG_CMD_NAND is not set
# CONFIG_CMD_SF is not set
# CONFIG_CMD_SPI is not set
# CONFIG_CMD_I2C is not set
# CONFIG_CMD_USB is not set
CONFIG_CMD_FPGA=y
# CONFIG_CMD_GPIO is not set

#
# Shell scripting commands
#
CONFIG_CMD_ECHO=y
CONFIG_CMD_ITEST=y
CONFIG_CMD_SOURCE=y
CONFIG_CMD_SETEXPR=y

#
# Network commands
#
CONFIG_CMD_NET=y
# CONFIG_CMD_TFTPPUT is not set
# CONFIG_CMD_TFTPSRV is not set
# CONFIG_CMD_RARP is not set
# CONFIG_CMD_DHCP is not set
CONFIG_CMD_NFS=y
# CONFIG_CMD_PING is not set
# CONFIG_CMD_CDP is not set
# CONFIG_CMD_SNTP is not set
# CONFIG_CMD_DNS is not set
# CONFIG_CMD_LINK_LOCAL is not set

#
# Misc commands
#
# CONFIG_CMD_TIME is not set
CONFIG_CMD_MISC=y
# CONFIG_CMD_TIMER is not set

#
# Boot timing
#
# CONFIG_BOOTSTAGE is not set
CONFIG_BOOTSTAGE_USER_COUNT=20
CONFIG_BOOTSTAGE_STASH_ADDR=0
CONFIG_BOOTSTAGE_STASH_SIZE=4096

#
# Power commands
#

#
# Security commands
#
# CONFIG_CONSOLE_RECORD is not set
CONFIG_SUPPORT_OF_CONTROL=y

#
# Device Tree Control
#
CONFIG_OF_CONTROL=y
CONFIG_SPL_OF_CONTROL=y
CONFIG_OF_SEPARATE=y
# CONFIG_OF_EMBED is not set
CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clocks clock-names interrupt-parent"
CONFIG_NET=y
# CONFIG_NET_RANDOM_ETHADDR is not set
# CONFIG_NETCONSOLE is not set
CONFIG_NET_TFTP_VARS=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_DM=y
CONFIG_DM_WARN=y
CONFIG_DM_DEVICE_REMOVE=y
CONFIG_DM_STDIO=y
CONFIG_DM_SEQ_ALIAS=y
# CONFIG_REGMAP is not set
# CONFIG_SPL_REGMAP is not set
# CONFIG_DEVRES is not set
CONFIG_SIMPLE_BUS=y
# CONFIG_SPL_SIMPLE_BUS is not set
CONFIG_OF_TRANSLATE=y
# CONFIG_SPL_OF_TRANSLATE is not set
# CONFIG_ADC is not set
# CONFIG_ADC_EXYNOS is not set
# CONFIG_ADC_SANDBOX is not set
# CONFIG_CLK is not set
# CONFIG_CPU is not set

#
# Hardware crypto devices
#
# CONFIG_FSL_CAAM is not set

#
# Demo for driver model
#
# CONFIG_DM_DEMO is not set

#
# DFU support
#
# CONFIG_DFU_TFTP is not set

#
# GPIO Support
#
# CONFIG_ALTERA_PIO is not set
CONFIG_DWAPB_GPIO=y
# CONFIG_ATMEL_PIO4 is not set
# CONFIG_LPC32XX_GPIO is not set
# CONFIG_ROCKCHIP_GPIO is not set
# CONFIG_VYBRID_GPIO is not set

#
# I2C support
#
# CONFIG_DM_I2C_COMPAT is not set
# CONFIG_CROS_EC_KEYB is not set

#
# LED Support
#
# CONFIG_LED is not set
# CONFIG_SPL_LED is not set

#
# Multifunction device drivers
#
# CONFIG_MISC is not set
# CONFIG_CROS_EC is not set
# CONFIG_FSL_SEC_MON is not set
# CONFIG_MXC_OCOTP is not set
# CONFIG_PCA9551_LED is not set
# CONFIG_RESET is not set

#
# MMC Host controller Support
#
# CONFIG_DM_MMC is not set

#
# MTD Support
#
# CONFIG_MTD is not set

#
# NAND Device Support
#
# CONFIG_NAND_DENALI is not set
# CONFIG_NAND_VF610_NFC is not set
# CONFIG_NAND_PXA3XX is not set

#
# Generic NAND options
#
# CONFIG_SPL_NAND_DENALI is not set

#
# SPI Flash Support
#
CONFIG_SPI_FLASH=y
# CONFIG_SPI_FLASH_BAR is not set
# CONFIG_SPI_FLASH_ATMEL is not set
# CONFIG_SPI_FLASH_EON is not set
# CONFIG_SPI_FLASH_GIGADEVICE is not set
# CONFIG_SPI_FLASH_MACRONIX is not set
# CONFIG_SPI_FLASH_SPANSION is not set
# CONFIG_SPI_FLASH_STMICRO is not set
# CONFIG_SPI_FLASH_SST is not set
# CONFIG_SPI_FLASH_WINBOND is not set
CONFIG_SPI_FLASH_USE_4K_SECTORS=y
# CONFIG_SPI_FLASH_DATAFLASH is not set
# CONFIG_SPI_FLASH_MTD is not set
CONFIG_DM_ETH=y
CONFIG_PHYLIB=y
CONFIG_NETDEVICES=y
CONFIG_ALTERA_TSE=y
# CONFIG_E1000 is not set
CONFIG_ETH_DESIGNWARE=y

#
# PCI
#
# CONFIG_DM_PCI is not set

#
# Pin controllers
#
# CONFIG_PINCTRL is not set
# CONFIG_SPL_PINCTRL is not set

#
# Power
#
# CONFIG_DM_PMIC is not set
# CONFIG_DM_REGULATOR is not set
# CONFIG_RAM is not set

#
# Remote Processor drivers
#

#
# Real Time Clock
#
# CONFIG_DM_RTC is not set

#
# Serial drivers
#
# CONFIG_DEBUG_UART is not set
CONFIG_SYS_NS16550=y

#
# Sound support
#
# CONFIG_SOUND is not set

#
# SPI Support
#
# CONFIG_ALTERA_SPI is not set
# CONFIG_CADENCE_QSPI is not set
# CONFIG_DESIGNWARE_SPI is not set
# CONFIG_EXYNOS_SPI is not set
# CONFIG_FSL_DSPI is not set
# CONFIG_FSL_QSPI is not set
# CONFIG_ICH_SPI is not set
# CONFIG_ROCKCHIP_SPI is not set
# CONFIG_TEGRA114_SPI is not set
# CONFIG_TEGRA20_SFLASH is not set
# CONFIG_TEGRA20_SLINK is not set
# CONFIG_TEGRA210_QSPI is not set
# CONFIG_XILINX_SPI is not set
# CONFIG_FSL_ESPI is not set
# CONFIG_TI_QSPI is not set
# CONFIG_DM_THERMAL is not set

#
# Timer Support
#
# CONFIG_TIMER is not set

#
# TPM support
#
# CONFIG_USB is not set

#
# Graphics support
#
# CONFIG_VIDEO_VESA is not set
# CONFIG_VIDEO_LCD_ANX9804 is not set
# CONFIG_VIDEO_LCD_SSD2828 is not set
# CONFIG_DISPLAY_PORT is not set
# CONFIG_VIDEO_TEGRA124 is not set
# CONFIG_VIDEO_BRIDGE is not set
# CONFIG_PHYS_TO_BUS is not set

#
# File systems
#

#
# Library routines
#
# CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED is not set
CONFIG_HAVE_PRIVATE_LIBGCC=y
# CONFIG_USE_PRIVATE_LIBGCC is not set
CONFIG_SYS_HZ=1000
# CONFIG_SYS_VSNPRINTF is not set
# CONFIG_USE_TINY_PRINTF is not set
CONFIG_REGEX=y
# CONFIG_LIB_RAND is not set
# CONFIG_CMD_DHRYSTONE is not set
# CONFIG_RSA is not set
# CONFIG_TPM is not set

#
# Hashing Support
#
# CONFIG_SHA1 is not set
# CONFIG_SHA256 is not set
# CONFIG_SHA_HW_ACCEL is not set

#
# Compression Support
#
# CONFIG_LZ4 is not set
# CONFIG_ERRNO_STR is not set
# CONFIG_UNIT_TEST is not set

[U-Boot] usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Marek Vasut]

On Sunday, January 10, 2016 at 06:50:21 PM, Pavel Machek wrote:
> On Sun 2016-01-10 14:45:54, Marek Vasut wrote:
> > On Sunday, January 10, 2016 at 01:04:17 PM, Pavel Machek wrote:
> > > On Sun 2016-01-10 12:56:15, Pavel Machek wrote:
> > > > Hi!
> > > > 
> > > > After updating from 2016-rc1, I get this compile error:
> > > >   CC      common/main.o
> > > >   drivers/usb/host/dwc2.c: In function 'usb_lowlevel_init':
> > > >   drivers/usb/host/dwc2.c:1028:40: error: 'CONFIG_USB_DWC2_REG_ADDR'
> > > >   undeclared (first use in this function)
> > > >   
> > > >     priv->regs = (struct dwc2_core_regs *)CONFIG_USB_DWC2_REG_ADDR;
> > > >     
> > > >                                             ^
> > > > 
> > > > make mrproper socfpga_cyclone5_config
> > > > 
> > > > Fixes the problem.
> > > 
> > > Well, it "fixes" the problem by not compiling dwc2.
> > > 
> > > Socfpga clearly wants DWC2:
> > > 
> > > include/configs/socfpga_common.h:#define CONFIG_USB_DWC2
> > > include/configs/socfpga_common.h:#define CONFIG_USB_GADGET_DWC2_OTG
> > > 
> > > But does not contain required address:
> > > 
> > > [pavel at pollux u-boot]$ grep -ri USB_DWC2_REG_ADDR .
> > > ./drivers/usb/host/dwc2.c:  priv->regs = (struct dwc2_core_regs
> > > *)CONFIG_USB_DWC2_REG_ADDR; ./README:		CONFIG_USB_DWC2_REG_ADDR
> > 
> > the
> > 
> > > physical CPU address of the DWC2 ./include/configs/hikey.h:#define
> > > CONFIG_USB_DWC2_REG_ADDR 0xF72C0000
> > > ./include/configs/rpi-common.h:#define CONFIG_USB_DWC2_REG_ADDR
> > > 0x3f980000 ./include/configs/rpi-common.h:#define
> > > CONFIG_USB_DWC2_REG_ADDR 0x20980000
> > > 
> > > Plus, make socfpga_cyclone5_config does not enable USB, which is
> > > probably error.
> > 
> > SoCFPGA is using USB DM , so these base addresses are pulled from OF
> > and are no longer hard-coded.
> > 
> > Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can you please
> > test mainline _before_ reporting issues ?
> 
> Can you please test mainline before complaining?

Yes I _did_ test mainline AND booted it on the actual board. The USB does work
(if you disable dcache, which is unrelated bug). It would be very nice if you
did the same thing before you start yelling on the list that there is a bug.

The config you use and the one produced by make socfpga_cyclone5_defconfig 
differ. Use the mainline one, otherwise you will observe possible problems.

> With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached .config, I
> get the failure. No, CONFIG_DM_USB is not set in the config, which is
> probably the problem.

Again, the problem does not happen if you use mainline config. If you enable
random options, you might run into random problems.

> Maybe socfpga should select DM_USB or depend on it?

u-boot$ git grep DM_USB configs/socfpga_*
configs/socfpga_arria5_defconfig:CONFIG_DM_USB=y
configs/socfpga_cyclone5_defconfig:CONFIG_DM_USB=y
configs/socfpga_de0_nano_soc_defconfig:CONFIG_DM_USB=y
configs/socfpga_mcvevk_defconfig:CONFIG_DM_USB=y
configs/socfpga_sockit_defconfig:CONFIG_DM_USB=y
configs/socfpga_socrates_defconfig:CONFIG_DM_USB=y

So your config is broken or outdated, please update your config.

SoCFPGA should select DM_USB only for boards which use USB, so it's done in
each config on per-board basis for now. Once non-DM DWC2 goes away, DWC2 would 
select CONFIG_DM_USB.

Best regards,
Marek Vasut

[U-Boot] Are non-default configurations expected to work? Re: usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Pavel Machek]

> > > Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can you please
> > > test mainline _before_ reporting issues ?
> > 
> > Can you please test mainline before complaining?
> 
> Yes I _did_ test mainline AND booted it on the actual board. The USB does work
> (if you disable dcache, which is unrelated bug). It would be very nice if you
> did the same thing before you start yelling on the list that there is a bug.
> 
> The config you use and the one produced by make socfpga_cyclone5_defconfig 
> differ. Use the mainline one, otherwise you will observe possible
> problems.

Of course they differ. That's why they are called configuration _options_.

> > With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached .config, I
> > get the failure. No, CONFIG_DM_USB is not set in the config, which is
> > probably the problem.
> 
> Again, the problem does not happen if you use mainline config. If you enable
> random options, you might run into random problems.
> 
> > Maybe socfpga should select DM_USB or depend on it?
> 
> u-boot$ git grep DM_USB configs/socfpga_*
> configs/socfpga_arria5_defconfig:CONFIG_DM_USB=y
> configs/socfpga_cyclone5_defconfig:CONFIG_DM_USB=y
> configs/socfpga_de0_nano_soc_defconfig:CONFIG_DM_USB=y
> configs/socfpga_mcvevk_defconfig:CONFIG_DM_USB=y
> configs/socfpga_sockit_defconfig:CONFIG_DM_USB=y
> configs/socfpga_socrates_defconfig:CONFIG_DM_USB=y
> 
> So your config is broken or outdated, please update your config.

No. Mainline is broken. Yes, it happens to work with defconfig. But it
should work with any configuration user can select.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] Are non-default configurations expected to work? Re: usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Marek Vasut]

On Sunday, January 10, 2016 at 07:39:29 PM, Pavel Machek wrote:
> > > > Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can you
> > > > please test mainline _before_ reporting issues ?
> > > 
> > > Can you please test mainline before complaining?
> > 
> > Yes I _did_ test mainline AND booted it on the actual board. The USB does
> > work (if you disable dcache, which is unrelated bug). It would be very
> > nice if you did the same thing before you start yelling on the list that
> > there is a bug.
> > 
> > The config you use and the one produced by make
> > socfpga_cyclone5_defconfig differ. Use the mainline one, otherwise you
> > will observe possible problems.
> 
> Of course they differ. That's why they are called configuration _options_.
> 
> > > With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached .config, I
> > > get the failure. No, CONFIG_DM_USB is not set in the config, which is
> > > probably the problem.
> > 
> > Again, the problem does not happen if you use mainline config. If you
> > enable random options, you might run into random problems.
> > 
> > > Maybe socfpga should select DM_USB or depend on it?
> > 
> > u-boot$ git grep DM_USB configs/socfpga_*
> > configs/socfpga_arria5_defconfig:CONFIG_DM_USB=y
> > configs/socfpga_cyclone5_defconfig:CONFIG_DM_USB=y
> > configs/socfpga_de0_nano_soc_defconfig:CONFIG_DM_USB=y
> > configs/socfpga_mcvevk_defconfig:CONFIG_DM_USB=y
> > configs/socfpga_sockit_defconfig:CONFIG_DM_USB=y
> > configs/socfpga_socrates_defconfig:CONFIG_DM_USB=y
> > 
> > So your config is broken or outdated, please update your config.
> 
> No. Mainline is broken. Yes, it happens to work with defconfig. But it
> should work with any configuration user can select.

The Kconfig conversion is not finished yet, so this is incorrect.
Patches to improve the situation are obviously welcome.

Best regards,
Marek Vasut

[U-Boot] Are non-default configurations expected to work? Re: usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Tom Rini]

On Sun, Jan 10, 2016 at 07:39:29PM +0100, Pavel Machek wrote:

> > > > Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can you please
> > > > test mainline _before_ reporting issues ?
> > > 
> > > Can you please test mainline before complaining?
> > 
> > Yes I _did_ test mainline AND booted it on the actual board. The USB does work
> > (if you disable dcache, which is unrelated bug). It would be very nice if you
> > did the same thing before you start yelling on the list that there is a bug.
> > 
> > The config you use and the one produced by make socfpga_cyclone5_defconfig 
> > differ. Use the mainline one, otherwise you will observe possible
> > problems.
> 
> Of course they differ. That's why they are called configuration _options_.

True.

> > > With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached .config, I
> > > get the failure. No, CONFIG_DM_USB is not set in the config, which is
> > > probably the problem.
> > 
> > Again, the problem does not happen if you use mainline config. If you enable
> > random options, you might run into random problems.
> > 
> > > Maybe socfpga should select DM_USB or depend on it?
> > 
> > u-boot$ git grep DM_USB configs/socfpga_*
> > configs/socfpga_arria5_defconfig:CONFIG_DM_USB=y
> > configs/socfpga_cyclone5_defconfig:CONFIG_DM_USB=y
> > configs/socfpga_de0_nano_soc_defconfig:CONFIG_DM_USB=y
> > configs/socfpga_mcvevk_defconfig:CONFIG_DM_USB=y
> > configs/socfpga_sockit_defconfig:CONFIG_DM_USB=y
> > configs/socfpga_socrates_defconfig:CONFIG_DM_USB=y
> > 
> > So your config is broken or outdated, please update your config.
> 
> No. Mainline is broken. Yes, it happens to work with defconfig. But it
> should work with any configuration user can select.

So, here's the problem.  Disabling CONFIG_DM_USB is not a long term
solution.  If there's a problem when CONFIG_DM_USB is not set, it should
be diagnosed and fixed, especially since we might have a mirror of the
issue inside the DM code, or it might be a more core problem and we
simply luck out in the DM case.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160110/20cc99fe/attachment.sig>

[U-Boot] Are non-default configurations expected to work? Re: usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Marek Vasut]

On Sunday, January 10, 2016 at 08:04:06 PM, Tom Rini wrote:
> On Sun, Jan 10, 2016 at 07:39:29PM +0100, Pavel Machek wrote:
> > > > > Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can you
> > > > > please test mainline _before_ reporting issues ?
> > > > 
> > > > Can you please test mainline before complaining?
> > > 
> > > Yes I _did_ test mainline AND booted it on the actual board. The USB
> > > does work (if you disable dcache, which is unrelated bug). It would be
> > > very nice if you did the same thing before you start yelling on the
> > > list that there is a bug.
> > > 
> > > The config you use and the one produced by make
> > > socfpga_cyclone5_defconfig differ. Use the mainline one, otherwise you
> > > will observe possible problems.
> > 
> > Of course they differ. That's why they are called configuration
> > _options_.
> 
> True.
> 
> > > > With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached .config, I
> > > > get the failure. No, CONFIG_DM_USB is not set in the config, which is
> > > > probably the problem.
> > > 
> > > Again, the problem does not happen if you use mainline config. If you
> > > enable random options, you might run into random problems.
> > > 
> > > > Maybe socfpga should select DM_USB or depend on it?
> > > 
> > > u-boot$ git grep DM_USB configs/socfpga_*
> > > configs/socfpga_arria5_defconfig:CONFIG_DM_USB=y
> > > configs/socfpga_cyclone5_defconfig:CONFIG_DM_USB=y
> > > configs/socfpga_de0_nano_soc_defconfig:CONFIG_DM_USB=y
> > > configs/socfpga_mcvevk_defconfig:CONFIG_DM_USB=y
> > > configs/socfpga_sockit_defconfig:CONFIG_DM_USB=y
> > > configs/socfpga_socrates_defconfig:CONFIG_DM_USB=y
> > > 
> > > So your config is broken or outdated, please update your config.
> > 
> > No. Mainline is broken. Yes, it happens to work with defconfig. But it
> > should work with any configuration user can select.
> 
> So, here's the problem.  Disabling CONFIG_DM_USB is not a long term
> solution.

CONFIG_DM_USB is enabled though.

> If there's a problem when CONFIG_DM_USB is not set, it should
> be diagnosed and fixed, especially since we might have a mirror of the
> issue inside the DM code, or it might be a more core problem and we
> simply luck out in the DM case.

The problem is if you have CONFIG_USB enabled, but _without_ CONFIG_DM_USB.
In that case, the DWC2 driver expects you to define a macro which specifies
the base address of the USB controller. Otherwise the driver picks this info 
from the OF.

I believe there is no problem with this, the driver covers both DM and non-DM
operation this way.

Best regards,
Marek Vasut

[U-Boot] Are non-default configurations expected to work? Re: usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Tom Rini]

On Sun, Jan 10, 2016 at 08:06:59PM +0100, Marek Vasut wrote:
> On Sunday, January 10, 2016 at 08:04:06 PM, Tom Rini wrote:
> > On Sun, Jan 10, 2016 at 07:39:29PM +0100, Pavel Machek wrote:
> > > > > > Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can you
> > > > > > please test mainline _before_ reporting issues ?
> > > > > 
> > > > > Can you please test mainline before complaining?
> > > > 
> > > > Yes I _did_ test mainline AND booted it on the actual board. The USB
> > > > does work (if you disable dcache, which is unrelated bug). It would be
> > > > very nice if you did the same thing before you start yelling on the
> > > > list that there is a bug.
> > > > 
> > > > The config you use and the one produced by make
> > > > socfpga_cyclone5_defconfig differ. Use the mainline one, otherwise you
> > > > will observe possible problems.
> > > 
> > > Of course they differ. That's why they are called configuration
> > > _options_.
> > 
> > True.
> > 
> > > > > With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached .config, I
> > > > > get the failure. No, CONFIG_DM_USB is not set in the config, which is
> > > > > probably the problem.
> > > > 
> > > > Again, the problem does not happen if you use mainline config. If you
> > > > enable random options, you might run into random problems.
> > > > 
> > > > > Maybe socfpga should select DM_USB or depend on it?
> > > > 
> > > > u-boot$ git grep DM_USB configs/socfpga_*
> > > > configs/socfpga_arria5_defconfig:CONFIG_DM_USB=y
> > > > configs/socfpga_cyclone5_defconfig:CONFIG_DM_USB=y
> > > > configs/socfpga_de0_nano_soc_defconfig:CONFIG_DM_USB=y
> > > > configs/socfpga_mcvevk_defconfig:CONFIG_DM_USB=y
> > > > configs/socfpga_sockit_defconfig:CONFIG_DM_USB=y
> > > > configs/socfpga_socrates_defconfig:CONFIG_DM_USB=y
> > > > 
> > > > So your config is broken or outdated, please update your config.
> > > 
> > > No. Mainline is broken. Yes, it happens to work with defconfig. But it
> > > should work with any configuration user can select.
> > 
> > So, here's the problem.  Disabling CONFIG_DM_USB is not a long term
> > solution.
> 
> CONFIG_DM_USB is enabled though.
> 
> > If there's a problem when CONFIG_DM_USB is not set, it should
> > be diagnosed and fixed, especially since we might have a mirror of the
> > issue inside the DM code, or it might be a more core problem and we
> > simply luck out in the DM case.
> 
> The problem is if you have CONFIG_USB enabled, but _without_ CONFIG_DM_USB.
> In that case, the DWC2 driver expects you to define a macro which specifies
> the base address of the USB controller. Otherwise the driver picks this info 
> from the OF.
> 
> I believe there is no problem with this, the driver covers both DM and non-DM
> operation this way.

That's it?  Yes, we should have the missing define added and a lack of
it is a bug we should fix.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160110/3294e40a/attachment.sig>

[U-Boot] Are non-default configurations expected to work? Re: usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Marek Vasut]

On Sunday, January 10, 2016 at 08:16:55 PM, Tom Rini wrote:
> On Sun, Jan 10, 2016 at 08:06:59PM +0100, Marek Vasut wrote:
> > On Sunday, January 10, 2016 at 08:04:06 PM, Tom Rini wrote:
> > > On Sun, Jan 10, 2016 at 07:39:29PM +0100, Pavel Machek wrote:
> > > > > > > Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can you
> > > > > > > please test mainline _before_ reporting issues ?
> > > > > > 
> > > > > > Can you please test mainline before complaining?
> > > > > 
> > > > > Yes I _did_ test mainline AND booted it on the actual board. The
> > > > > USB does work (if you disable dcache, which is unrelated bug). It
> > > > > would be very nice if you did the same thing before you start
> > > > > yelling on the list that there is a bug.
> > > > > 
> > > > > The config you use and the one produced by make
> > > > > socfpga_cyclone5_defconfig differ. Use the mainline one, otherwise
> > > > > you will observe possible problems.
> > > > 
> > > > Of course they differ. That's why they are called configuration
> > > > _options_.
> > > 
> > > True.
> > > 
> > > > > > With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached
> > > > > > .config, I get the failure. No, CONFIG_DM_USB is not set in the
> > > > > > config, which is probably the problem.
> > > > > 
> > > > > Again, the problem does not happen if you use mainline config. If
> > > > > you enable random options, you might run into random problems.
> > > > > 
> > > > > > Maybe socfpga should select DM_USB or depend on it?
> > > > > 
> > > > > u-boot$ git grep DM_USB configs/socfpga_*
> > > > > configs/socfpga_arria5_defconfig:CONFIG_DM_USB=y
> > > > > configs/socfpga_cyclone5_defconfig:CONFIG_DM_USB=y
> > > > > configs/socfpga_de0_nano_soc_defconfig:CONFIG_DM_USB=y
> > > > > configs/socfpga_mcvevk_defconfig:CONFIG_DM_USB=y
> > > > > configs/socfpga_sockit_defconfig:CONFIG_DM_USB=y
> > > > > configs/socfpga_socrates_defconfig:CONFIG_DM_USB=y
> > > > > 
> > > > > So your config is broken or outdated, please update your config.
> > > > 
> > > > No. Mainline is broken. Yes, it happens to work with defconfig. But
> > > > it should work with any configuration user can select.
> > > 
> > > So, here's the problem.  Disabling CONFIG_DM_USB is not a long term
> > > solution.
> > 
> > CONFIG_DM_USB is enabled though.
> > 
> > > If there's a problem when CONFIG_DM_USB is not set, it should
> > > be diagnosed and fixed, especially since we might have a mirror of the
> > > issue inside the DM code, or it might be a more core problem and we
> > > simply luck out in the DM case.
> > 
> > The problem is if you have CONFIG_USB enabled, but _without_
> > CONFIG_DM_USB. In that case, the DWC2 driver expects you to define a
> > macro which specifies the base address of the USB controller. Otherwise
> > the driver picks this info from the OF.
> > 
> > I believe there is no problem with this, the driver covers both DM and
> > non-DM operation this way.
> 
> That's it?  Yes, we should have the missing define added and a lack of
> it is a bug we should fix.

Wrong, the macro was intently removed from all the socfpga config files because:
a) do not want to hardcode any addresses on socfpga, they should come from DT
b) we do want to support multiple controllers and that is not possible without
   CONFIG_DM_USB

CONFIG_DM_USB is a hard requirement on SoCFPGA.

Best regards,
Marek Vasut

[U-Boot] Are non-default configurations expected to work? Re: usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Tom Rini]

On Sun, Jan 10, 2016 at 08:18:39PM +0100, Marek Vasut wrote:
> On Sunday, January 10, 2016 at 08:16:55 PM, Tom Rini wrote:
> > On Sun, Jan 10, 2016 at 08:06:59PM +0100, Marek Vasut wrote:
> > > On Sunday, January 10, 2016 at 08:04:06 PM, Tom Rini wrote:
> > > > On Sun, Jan 10, 2016 at 07:39:29PM +0100, Pavel Machek wrote:
> > > > > > > > Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can you
> > > > > > > > please test mainline _before_ reporting issues ?
> > > > > > > 
> > > > > > > Can you please test mainline before complaining?
> > > > > > 
> > > > > > Yes I _did_ test mainline AND booted it on the actual board. The
> > > > > > USB does work (if you disable dcache, which is unrelated bug). It
> > > > > > would be very nice if you did the same thing before you start
> > > > > > yelling on the list that there is a bug.
> > > > > > 
> > > > > > The config you use and the one produced by make
> > > > > > socfpga_cyclone5_defconfig differ. Use the mainline one, otherwise
> > > > > > you will observe possible problems.
> > > > > 
> > > > > Of course they differ. That's why they are called configuration
> > > > > _options_.
> > > > 
> > > > True.
> > > > 
> > > > > > > With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached
> > > > > > > .config, I get the failure. No, CONFIG_DM_USB is not set in the
> > > > > > > config, which is probably the problem.
> > > > > > 
> > > > > > Again, the problem does not happen if you use mainline config. If
> > > > > > you enable random options, you might run into random problems.
> > > > > > 
> > > > > > > Maybe socfpga should select DM_USB or depend on it?
> > > > > > 
> > > > > > u-boot$ git grep DM_USB configs/socfpga_*
> > > > > > configs/socfpga_arria5_defconfig:CONFIG_DM_USB=y
> > > > > > configs/socfpga_cyclone5_defconfig:CONFIG_DM_USB=y
> > > > > > configs/socfpga_de0_nano_soc_defconfig:CONFIG_DM_USB=y
> > > > > > configs/socfpga_mcvevk_defconfig:CONFIG_DM_USB=y
> > > > > > configs/socfpga_sockit_defconfig:CONFIG_DM_USB=y
> > > > > > configs/socfpga_socrates_defconfig:CONFIG_DM_USB=y
> > > > > > 
> > > > > > So your config is broken or outdated, please update your config.
> > > > > 
> > > > > No. Mainline is broken. Yes, it happens to work with defconfig. But
> > > > > it should work with any configuration user can select.
> > > > 
> > > > So, here's the problem.  Disabling CONFIG_DM_USB is not a long term
> > > > solution.
> > > 
> > > CONFIG_DM_USB is enabled though.
> > > 
> > > > If there's a problem when CONFIG_DM_USB is not set, it should
> > > > be diagnosed and fixed, especially since we might have a mirror of the
> > > > issue inside the DM code, or it might be a more core problem and we
> > > > simply luck out in the DM case.
> > > 
> > > The problem is if you have CONFIG_USB enabled, but _without_
> > > CONFIG_DM_USB. In that case, the DWC2 driver expects you to define a
> > > macro which specifies the base address of the USB controller. Otherwise
> > > the driver picks this info from the OF.
> > > 
> > > I believe there is no problem with this, the driver covers both DM and
> > > non-DM operation this way.
> > 
> > That's it?  Yes, we should have the missing define added and a lack of
> > it is a bug we should fix.
> 
> Wrong, the macro was intently removed from all the socfpga config files because:
> a) do not want to hardcode any addresses on socfpga, they should come from DT
> b) we do want to support multiple controllers and that is not possible without
>    CONFIG_DM_USB
> 
> CONFIG_DM_USB is a hard requirement on SoCFPGA.

Then with your SoCFPGA hat on, you need to fix the Kconfig so invalid
combinations can't happen.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160110/915e554d/attachment.sig>

[U-Boot] Are non-default configurations expected to work? Re: usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Marek Vasut]

On Sunday, January 10, 2016 at 08:28:24 PM, Tom Rini wrote:
> On Sun, Jan 10, 2016 at 08:18:39PM +0100, Marek Vasut wrote:
> > On Sunday, January 10, 2016 at 08:16:55 PM, Tom Rini wrote:
> > > On Sun, Jan 10, 2016 at 08:06:59PM +0100, Marek Vasut wrote:
> > > > On Sunday, January 10, 2016 at 08:04:06 PM, Tom Rini wrote:
> > > > > On Sun, Jan 10, 2016 at 07:39:29PM +0100, Pavel Machek wrote:
> > > > > > > > > Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can
> > > > > > > > > you please test mainline _before_ reporting issues ?
> > > > > > > > 
> > > > > > > > Can you please test mainline before complaining?
> > > > > > > 
> > > > > > > Yes I _did_ test mainline AND booted it on the actual board.
> > > > > > > The USB does work (if you disable dcache, which is unrelated
> > > > > > > bug). It would be very nice if you did the same thing before
> > > > > > > you start yelling on the list that there is a bug.
> > > > > > > 
> > > > > > > The config you use and the one produced by make
> > > > > > > socfpga_cyclone5_defconfig differ. Use the mainline one,
> > > > > > > otherwise you will observe possible problems.
> > > > > > 
> > > > > > Of course they differ. That's why they are called configuration
> > > > > > _options_.
> > > > > 
> > > > > True.
> > > > > 
> > > > > > > > With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached
> > > > > > > > .config, I get the failure. No, CONFIG_DM_USB is not set in
> > > > > > > > the config, which is probably the problem.
> > > > > > > 
> > > > > > > Again, the problem does not happen if you use mainline config.
> > > > > > > If you enable random options, you might run into random
> > > > > > > problems.
> > > > > > > 
> > > > > > > > Maybe socfpga should select DM_USB or depend on it?
> > > > > > > 
> > > > > > > u-boot$ git grep DM_USB configs/socfpga_*
> > > > > > > configs/socfpga_arria5_defconfig:CONFIG_DM_USB=y
> > > > > > > configs/socfpga_cyclone5_defconfig:CONFIG_DM_USB=y
> > > > > > > configs/socfpga_de0_nano_soc_defconfig:CONFIG_DM_USB=y
> > > > > > > configs/socfpga_mcvevk_defconfig:CONFIG_DM_USB=y
> > > > > > > configs/socfpga_sockit_defconfig:CONFIG_DM_USB=y
> > > > > > > configs/socfpga_socrates_defconfig:CONFIG_DM_USB=y
> > > > > > > 
> > > > > > > So your config is broken or outdated, please update your
> > > > > > > config.
> > > > > > 
> > > > > > No. Mainline is broken. Yes, it happens to work with defconfig.
> > > > > > But it should work with any configuration user can select.
> > > > > 
> > > > > So, here's the problem.  Disabling CONFIG_DM_USB is not a long term
> > > > > solution.
> > > > 
> > > > CONFIG_DM_USB is enabled though.
> > > > 
> > > > > If there's a problem when CONFIG_DM_USB is not set, it should
> > > > > be diagnosed and fixed, especially since we might have a mirror of
> > > > > the issue inside the DM code, or it might be a more core problem
> > > > > and we simply luck out in the DM case.
> > > > 
> > > > The problem is if you have CONFIG_USB enabled, but _without_
> > > > CONFIG_DM_USB. In that case, the DWC2 driver expects you to define a
> > > > macro which specifies the base address of the USB controller.
> > > > Otherwise the driver picks this info from the OF.
> > > > 
> > > > I believe there is no problem with this, the driver covers both DM
> > > > and non-DM operation this way.
> > > 
> > > That's it?  Yes, we should have the missing define added and a lack of
> > > it is a bug we should fix.
> > 
> > Wrong, the macro was intently removed from all the socfpga config files
> > because: a) do not want to hardcode any addresses on socfpga, they
> > should come from DT b) we do want to support multiple controllers and
> > that is not possible without
> > 
> >    CONFIG_DM_USB
> > 
> > CONFIG_DM_USB is a hard requirement on SoCFPGA.
> 
> Then with your SoCFPGA hat on, you need to fix the Kconfig so invalid
> combinations can't happen.

Invalid configurations do not happen in mainline, everything is compile tested.
In case someone wants to bulletproof the config, patches are welcome. I am not
certain what should select CONFIG_DM_USB, Simon might help here.

[U-Boot] Are non-default configurations expected to work? Re: usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Tom Rini]

On Sun, Jan 10, 2016 at 08:40:06PM +0100, Marek Vasut wrote:
> On Sunday, January 10, 2016 at 08:28:24 PM, Tom Rini wrote:
> > On Sun, Jan 10, 2016 at 08:18:39PM +0100, Marek Vasut wrote:
> > > On Sunday, January 10, 2016 at 08:16:55 PM, Tom Rini wrote:
> > > > On Sun, Jan 10, 2016 at 08:06:59PM +0100, Marek Vasut wrote:
> > > > > On Sunday, January 10, 2016 at 08:04:06 PM, Tom Rini wrote:
> > > > > > On Sun, Jan 10, 2016 at 07:39:29PM +0100, Pavel Machek wrote:
> > > > > > > > > > Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can
> > > > > > > > > > you please test mainline _before_ reporting issues ?
> > > > > > > > > 
> > > > > > > > > Can you please test mainline before complaining?
> > > > > > > > 
> > > > > > > > Yes I _did_ test mainline AND booted it on the actual board.
> > > > > > > > The USB does work (if you disable dcache, which is unrelated
> > > > > > > > bug). It would be very nice if you did the same thing before
> > > > > > > > you start yelling on the list that there is a bug.
> > > > > > > > 
> > > > > > > > The config you use and the one produced by make
> > > > > > > > socfpga_cyclone5_defconfig differ. Use the mainline one,
> > > > > > > > otherwise you will observe possible problems.
> > > > > > > 
> > > > > > > Of course they differ. That's why they are called configuration
> > > > > > > _options_.
> > > > > > 
> > > > > > True.
> > > > > > 
> > > > > > > > > With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached
> > > > > > > > > .config, I get the failure. No, CONFIG_DM_USB is not set in
> > > > > > > > > the config, which is probably the problem.
> > > > > > > > 
> > > > > > > > Again, the problem does not happen if you use mainline config.
> > > > > > > > If you enable random options, you might run into random
> > > > > > > > problems.
> > > > > > > > 
> > > > > > > > > Maybe socfpga should select DM_USB or depend on it?
> > > > > > > > 
> > > > > > > > u-boot$ git grep DM_USB configs/socfpga_*
> > > > > > > > configs/socfpga_arria5_defconfig:CONFIG_DM_USB=y
> > > > > > > > configs/socfpga_cyclone5_defconfig:CONFIG_DM_USB=y
> > > > > > > > configs/socfpga_de0_nano_soc_defconfig:CONFIG_DM_USB=y
> > > > > > > > configs/socfpga_mcvevk_defconfig:CONFIG_DM_USB=y
> > > > > > > > configs/socfpga_sockit_defconfig:CONFIG_DM_USB=y
> > > > > > > > configs/socfpga_socrates_defconfig:CONFIG_DM_USB=y
> > > > > > > > 
> > > > > > > > So your config is broken or outdated, please update your
> > > > > > > > config.
> > > > > > > 
> > > > > > > No. Mainline is broken. Yes, it happens to work with defconfig.
> > > > > > > But it should work with any configuration user can select.
> > > > > > 
> > > > > > So, here's the problem.  Disabling CONFIG_DM_USB is not a long term
> > > > > > solution.
> > > > > 
> > > > > CONFIG_DM_USB is enabled though.
> > > > > 
> > > > > > If there's a problem when CONFIG_DM_USB is not set, it should
> > > > > > be diagnosed and fixed, especially since we might have a mirror of
> > > > > > the issue inside the DM code, or it might be a more core problem
> > > > > > and we simply luck out in the DM case.
> > > > > 
> > > > > The problem is if you have CONFIG_USB enabled, but _without_
> > > > > CONFIG_DM_USB. In that case, the DWC2 driver expects you to define a
> > > > > macro which specifies the base address of the USB controller.
> > > > > Otherwise the driver picks this info from the OF.
> > > > > 
> > > > > I believe there is no problem with this, the driver covers both DM
> > > > > and non-DM operation this way.
> > > > 
> > > > That's it?  Yes, we should have the missing define added and a lack of
> > > > it is a bug we should fix.
> > > 
> > > Wrong, the macro was intently removed from all the socfpga config files
> > > because: a) do not want to hardcode any addresses on socfpga, they
> > > should come from DT b) we do want to support multiple controllers and
> > > that is not possible without
> > > 
> > >    CONFIG_DM_USB
> > > 
> > > CONFIG_DM_USB is a hard requirement on SoCFPGA.
> > 
> > Then with your SoCFPGA hat on, you need to fix the Kconfig so invalid
> > combinations can't happen.
> 
> Invalid configurations do not happen in mainline, everything is compile tested.
> In case someone wants to bulletproof the config, patches are welcome. I am not
> certain what should select CONFIG_DM_USB, Simon might help here.

No.  That's not how it works.  And Kconfig isn't some esoteric thing no
one has heard of outside of U-Boot.  One of the big points about
switching to Kconfig is that finally, really, people can customize their
build without editing header files and getting bit by poorly or not at
all documented interdependencies.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160110/7cac247f/attachment.sig>

[U-Boot] Are non-default configurations expected to work? Re: usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Marek Vasut]

On Sunday, January 10, 2016 at 09:11:46 PM, Tom Rini wrote:
> On Sun, Jan 10, 2016 at 08:40:06PM +0100, Marek Vasut wrote:
> > On Sunday, January 10, 2016 at 08:28:24 PM, Tom Rini wrote:
> > > On Sun, Jan 10, 2016 at 08:18:39PM +0100, Marek Vasut wrote:
> > > > On Sunday, January 10, 2016 at 08:16:55 PM, Tom Rini wrote:
> > > > > On Sun, Jan 10, 2016 at 08:06:59PM +0100, Marek Vasut wrote:
> > > > > > On Sunday, January 10, 2016 at 08:04:06 PM, Tom Rini wrote:
> > > > > > > On Sun, Jan 10, 2016 at 07:39:29PM +0100, Pavel Machek wrote:
> > > > > > > > > > > Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK.
> > > > > > > > > > > Can you please test mainline _before_ reporting issues
> > > > > > > > > > > ?
> > > > > > > > > > 
> > > > > > > > > > Can you please test mainline before complaining?
> > > > > > > > > 
> > > > > > > > > Yes I _did_ test mainline AND booted it on the actual
> > > > > > > > > board. The USB does work (if you disable dcache, which is
> > > > > > > > > unrelated bug). It would be very nice if you did the same
> > > > > > > > > thing before you start yelling on the list that there is a
> > > > > > > > > bug.
> > > > > > > > > 
> > > > > > > > > The config you use and the one produced by make
> > > > > > > > > socfpga_cyclone5_defconfig differ. Use the mainline one,
> > > > > > > > > otherwise you will observe possible problems.
> > > > > > > > 
> > > > > > > > Of course they differ. That's why they are called
> > > > > > > > configuration _options_.
> > > > > > > 
> > > > > > > True.
> > > > > > > 
> > > > > > > > > > With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and
> > > > > > > > > > attached .config, I get the failure. No, CONFIG_DM_USB
> > > > > > > > > > is not set in the config, which is probably the problem.
> > > > > > > > > 
> > > > > > > > > Again, the problem does not happen if you use mainline
> > > > > > > > > config. If you enable random options, you might run into
> > > > > > > > > random problems.
> > > > > > > > > 
> > > > > > > > > > Maybe socfpga should select DM_USB or depend on it?
> > > > > > > > > 
> > > > > > > > > u-boot$ git grep DM_USB configs/socfpga_*
> > > > > > > > > configs/socfpga_arria5_defconfig:CONFIG_DM_USB=y
> > > > > > > > > configs/socfpga_cyclone5_defconfig:CONFIG_DM_USB=y
> > > > > > > > > configs/socfpga_de0_nano_soc_defconfig:CONFIG_DM_USB=y
> > > > > > > > > configs/socfpga_mcvevk_defconfig:CONFIG_DM_USB=y
> > > > > > > > > configs/socfpga_sockit_defconfig:CONFIG_DM_USB=y
> > > > > > > > > configs/socfpga_socrates_defconfig:CONFIG_DM_USB=y
> > > > > > > > > 
> > > > > > > > > So your config is broken or outdated, please update your
> > > > > > > > > config.
> > > > > > > > 
> > > > > > > > No. Mainline is broken. Yes, it happens to work with
> > > > > > > > defconfig. But it should work with any configuration user
> > > > > > > > can select.
> > > > > > > 
> > > > > > > So, here's the problem.  Disabling CONFIG_DM_USB is not a long
> > > > > > > term solution.
> > > > > > 
> > > > > > CONFIG_DM_USB is enabled though.
> > > > > > 
> > > > > > > If there's a problem when CONFIG_DM_USB is not set, it should
> > > > > > > be diagnosed and fixed, especially since we might have a mirror
> > > > > > > of the issue inside the DM code, or it might be a more core
> > > > > > > problem and we simply luck out in the DM case.
> > > > > > 
> > > > > > The problem is if you have CONFIG_USB enabled, but _without_
> > > > > > CONFIG_DM_USB. In that case, the DWC2 driver expects you to
> > > > > > define a macro which specifies the base address of the USB
> > > > > > controller. Otherwise the driver picks this info from the OF.
> > > > > > 
> > > > > > I believe there is no problem with this, the driver covers both
> > > > > > DM and non-DM operation this way.
> > > > > 
> > > > > That's it?  Yes, we should have the missing define added and a lack
> > > > > of it is a bug we should fix.
> > > > 
> > > > Wrong, the macro was intently removed from all the socfpga config
> > > > files because: a) do not want to hardcode any addresses on socfpga,
> > > > they should come from DT b) we do want to support multiple
> > > > controllers and that is not possible without
> > > > 
> > > >    CONFIG_DM_USB
> > > > 
> > > > CONFIG_DM_USB is a hard requirement on SoCFPGA.
> > > 
> > > Then with your SoCFPGA hat on, you need to fix the Kconfig so invalid
> > > combinations can't happen.
> > 
> > Invalid configurations do not happen in mainline, everything is compile
> > tested. In case someone wants to bulletproof the config, patches are
> > welcome. I am not certain what should select CONFIG_DM_USB, Simon might
> > help here.
> 
> No.  That's not how it works.  And Kconfig isn't some esoteric thing no
> one has heard of outside of U-Boot.  One of the big points about
> switching to Kconfig is that finally, really, people can customize their
> build without editing header files and getting bit by poorly or not at
> all documented interdependencies.

I agree with this.

[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Marek Vasut]

On Tuesday, January 05, 2016 at 05:16:05 PM, Marek Vasut wrote:
> On Tuesday, January 05, 2016 at 04:51:47 PM, Chin Liang See wrote:
> > On Tue, 2016-01-05 at 15:36 +0100, Marek Vasut wrote:
> > > On Tuesday, January 05, 2016 at 06:00:04 AM, Chin Liang See wrote:
> > > > Per DesignWare USB OTG databook, driver should retry up to
> > > > 3 times when transaction error (hcint.xacterr) happen. But
> > > > the 3 times doesn't count when the response is nack
> > > > (hcint.nak) or frame overrun (hcint.frmoverun)
> > > > 
> > > > This patch solved the enumeration error as spotted at socfpga
> > > > cyclone5_socdk when plugging in certain pendrive.
> > > > 
> > > > Signed-off-by: Chin Liang See <clsee@altera.com>
> > > > Cc: Marek Vasut <marex@denx.de>
> > > > Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> > > > Cc: Dinh Nguyen <dinh.linux@gmail.com>
> > > > Cc: Pavel Machek <pavel@denx.de>
> > > > Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>
> > > > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > > > Cc: Alexander Stein <alexanders83@web.de>
> > > > Cc: Peter Griffin <peter.griffin@linaro.org>
> > > 
> > > I applied this change on top of u-boot-socfpga/master and tested it
> > > on
> > > SoCFPGA CycloneV SoCDK with "Sandisk cruzer force" stick. The board
> > > gets
> > > completely stuck if I have dcache ENABLED and perform 'usb reset'.
> > > This
> > 
> > > patch is:
> > Thanks Marek for testing. I managed to find a SanDisk Cruzer Blade and
> > notice the same fail behaviours as yours. FYI, note that this patch
> > works well with other 3 pendrive that I have.
> > 
> > With SanDisk, the dwc2 driver was timed out as hcint.xfercomp and
> > chhltd never get set even after 1s. It keep retrying endlessly due to
> > miss handling for the ETIMEDOUT within this patch.
> > 
> > In short, the retry doesn't work for SanDisk but the dcache disable
> > works. Need to figure out more what cause the failure.
> 
> Excellent, I have one of those too (I bought the entire lineup of these
> sandisk sticks at one point ;-) )

Hi, any news on the SoCFPGA USB/QSPI problem investigation? Thanks!

Best regards,
Marek Vasut

[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Chin Liang See]

On Wed, 2016-01-13 at 03:58 +0100, Marek Vasut wrote:
> On Tuesday, January 05, 2016 at 05:16:05 PM, Marek Vasut wrote:
> > On Tuesday, January 05, 2016 at 04:51:47 PM, Chin Liang See wrote:
> > > On Tue, 2016-01-05 at 15:36 +0100, Marek Vasut wrote:
> > > > On Tuesday, January 05, 2016 at 06:00:04 AM, Chin Liang See
> > > > wrote:
> > > > > Per DesignWare USB OTG databook, driver should retry up to
> > > > > 3 times when transaction error (hcint.xacterr) happen. But
> > > > > the 3 times doesn't count when the response is nack
> > > > > (hcint.nak) or frame overrun (hcint.frmoverun)
> > > > > 
> > > > > This patch solved the enumeration error as spotted at socfpga
> > > > > cyclone5_socdk when plugging in certain pendrive.
> > > > > 
> > > > > Signed-off-by: Chin Liang See <clsee@altera.com>
> > > > > Cc: Marek Vasut <marex@denx.de>
> > > > > Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> > > > > Cc: Dinh Nguyen <dinh.linux@gmail.com>
> > > > > Cc: Pavel Machek <pavel@denx.de>
> > > > > Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>
> > > > > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > > > > Cc: Alexander Stein <alexanders83@web.de>
> > > > > Cc: Peter Griffin <peter.griffin@linaro.org>
> > > > 
> > > > I applied this change on top of u-boot-socfpga/master and
> > > > tested it
> > > > on
> > > > SoCFPGA CycloneV SoCDK with "Sandisk cruzer force" stick. The
> > > > board
> > > > gets
> > > > completely stuck if I have dcache ENABLED and perform 'usb
> > > > reset'.
> > > > This
> > > 
> > > > patch is:
> > > Thanks Marek for testing. I managed to find a SanDisk Cruzer
> > > Blade and
> > > notice the same fail behaviours as yours. FYI, note that this
> > > patch
> > > works well with other 3 pendrive that I have.
> > > 
> > > With SanDisk, the dwc2 driver was timed out as hcint.xfercomp and
> > > chhltd never get set even after 1s. It keep retrying endlessly
> > > due to
> > > miss handling for the ETIMEDOUT within this patch.
> > > 
> > > In short, the retry doesn't work for SanDisk but the dcache
> > > disable
> > > works. Need to figure out more what cause the failure.
> > 
> > Excellent, I have one of those too (I bought the entire lineup of
> > these
> > sandisk sticks at one point ;-) )
> 
> Hi, any news on the SoCFPGA USB/QSPI problem investigation? Thanks!
> 

I am still troubleshooting it. I played with few configuration within
L3 but not helping. This including avoiding multiple outstanding
transaction and security (allow both secure and non secure).

But all these issue will gone once dcache is off. I believe need to
visit the MMU table.

Thanks
Chin Liang

> Best regards,
> Marek Vasut

[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Marek Vasut]

On Wednesday, January 13, 2016 at 04:18:43 PM, Chin Liang See wrote:
> On Wed, 2016-01-13 at 03:58 +0100, Marek Vasut wrote:
> > On Tuesday, January 05, 2016 at 05:16:05 PM, Marek Vasut wrote:
> > > On Tuesday, January 05, 2016 at 04:51:47 PM, Chin Liang See wrote:
> > > > On Tue, 2016-01-05 at 15:36 +0100, Marek Vasut wrote:
> > > > > On Tuesday, January 05, 2016 at 06:00:04 AM, Chin Liang See
> > > > > 
> > > > > wrote:
> > > > > > Per DesignWare USB OTG databook, driver should retry up to
> > > > > > 3 times when transaction error (hcint.xacterr) happen. But
> > > > > > the 3 times doesn't count when the response is nack
> > > > > > (hcint.nak) or frame overrun (hcint.frmoverun)
> > > > > > 
> > > > > > This patch solved the enumeration error as spotted at socfpga
> > > > > > cyclone5_socdk when plugging in certain pendrive.
> > > > > > 
> > > > > > Signed-off-by: Chin Liang See <clsee@altera.com>
> > > > > > Cc: Marek Vasut <marex@denx.de>
> > > > > > Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> > > > > > Cc: Dinh Nguyen <dinh.linux@gmail.com>
> > > > > > Cc: Pavel Machek <pavel@denx.de>
> > > > > > Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>
> > > > > > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > > > > > Cc: Alexander Stein <alexanders83@web.de>
> > > > > > Cc: Peter Griffin <peter.griffin@linaro.org>
> > > > > 
> > > > > I applied this change on top of u-boot-socfpga/master and
> > > > > tested it
> > > > > on
> > > > > SoCFPGA CycloneV SoCDK with "Sandisk cruzer force" stick. The
> > > > > board
> > > > > gets
> > > > > completely stuck if I have dcache ENABLED and perform 'usb
> > > > > reset'.
> > > > > This
> > > > 
> > > > > patch is:
> > > > Thanks Marek for testing. I managed to find a SanDisk Cruzer
> > > > Blade and
> > > > notice the same fail behaviours as yours. FYI, note that this
> > > > patch
> > > > works well with other 3 pendrive that I have.
> > > > 
> > > > With SanDisk, the dwc2 driver was timed out as hcint.xfercomp and
> > > > chhltd never get set even after 1s. It keep retrying endlessly
> > > > due to
> > > > miss handling for the ETIMEDOUT within this patch.
> > > > 
> > > > In short, the retry doesn't work for SanDisk but the dcache
> > > > disable
> > > > works. Need to figure out more what cause the failure.
> > > 
> > > Excellent, I have one of those too (I bought the entire lineup of
> > > these
> > > sandisk sticks at one point ;-) )
> > 
> > Hi, any news on the SoCFPGA USB/QSPI problem investigation? Thanks!
> 
> I am still troubleshooting it. I played with few configuration within
> L3 but not helping. This including avoiding multiple outstanding
> transaction and security (allow both secure and non secure).

Yeah

> But all these issue will gone once dcache is off. I believe need to
> visit the MMU table.

I was there already ;-) But given enough eyeballs, are bugs are shallow.

Best regards,

[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Chin Liang See]

On Wed, 2016-01-13 at 16:22 +0100, Marek Vasut wrote:
> On Wednesday, January 13, 2016 at 04:18:43 PM, Chin Liang See wrote:
> > On Wed, 2016-01-13 at 03:58 +0100, Marek Vasut wrote:
> > > On Tuesday, January 05, 2016 at 05:16:05 PM, Marek Vasut wrote:
> > > > On Tuesday, January 05, 2016 at 04:51:47 PM, Chin Liang See
> > > > wrote:
> > > > > On Tue, 2016-01-05 at 15:36 +0100, Marek Vasut wrote:
> > > > > > On Tuesday, January 05, 2016 at 06:00:04 AM, Chin Liang See
> > > > > > 
> > > > > > wrote:
> > > > > > > Per DesignWare USB OTG databook, driver should retry up
> > > > > > > to
> > > > > > > 3 times when transaction error (hcint.xacterr) happen.
> > > > > > > But
> > > > > > > the 3 times doesn't count when the response is nack
> > > > > > > (hcint.nak) or frame overrun (hcint.frmoverun)
> > > > > > > 
> > > > > > > This patch solved the enumeration error as spotted at
> > > > > > > socfpga
> > > > > > > cyclone5_socdk when plugging in certain pendrive.
> > > > > > > 
> > > > > > > Signed-off-by: Chin Liang See <clsee@altera.com>
> > > > > > > Cc: Marek Vasut <marex@denx.de>
> > > > > > > Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> > > > > > > Cc: Dinh Nguyen <dinh.linux@gmail.com>
> > > > > > > Cc: Pavel Machek <pavel@denx.de>
> > > > > > > Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>
> > > > > > > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > > > > > > Cc: Alexander Stein <alexanders83@web.de>
> > > > > > > Cc: Peter Griffin <peter.griffin@linaro.org>
> > > > > > 
> > > > > > I applied this change on top of u-boot-socfpga/master and
> > > > > > tested it
> > > > > > on
> > > > > > SoCFPGA CycloneV SoCDK with "Sandisk cruzer force" stick.
> > > > > > The
> > > > > > board
> > > > > > gets
> > > > > > completely stuck if I have dcache ENABLED and perform 'usb
> > > > > > reset'.
> > > > > > This
> > > > > 
> > > > > > patch is:
> > > > > Thanks Marek for testing. I managed to find a SanDisk Cruzer
> > > > > Blade and
> > > > > notice the same fail behaviours as yours. FYI, note that this
> > > > > patch
> > > > > works well with other 3 pendrive that I have.
> > > > > 
> > > > > With SanDisk, the dwc2 driver was timed out as hcint.xfercomp
> > > > > and
> > > > > chhltd never get set even after 1s. It keep retrying
> > > > > endlessly
> > > > > due to
> > > > > miss handling for the ETIMEDOUT within this patch.
> > > > > 
> > > > > In short, the retry doesn't work for SanDisk but the dcache
> > > > > disable
> > > > > works. Need to figure out more what cause the failure.
> > > > 
> > > > Excellent, I have one of those too (I bought the entire lineup
> > > > of
> > > > these
> > > > sandisk sticks at one point ;-) )
> > > 
> > > Hi, any news on the SoCFPGA USB/QSPI problem investigation?
> > > Thanks!
> > 
> > I am still troubleshooting it. I played with few configuration
> > within
> > L3 but not helping. This including avoiding multiple outstanding
> > transaction and security (allow both secure and non secure).
> 
> Yeah
> 
> > But all these issue will gone once dcache is off. I believe need to
> > visit the MMU table.
> 
> I was there already ;-) But given enough eyeballs, are bugs are
> shallow.

Continue some troubleshooting today. Notice some behavior change where
the SanDisk Cruzer Blade failed after POR and dcache disable. 

After enabling the debug message, the hub is complaining over current
(port change = 0x9) on the port where pen drive is plugged in. The port
status = 0x10 indicate no device present.

Appreciate any quick advise while digging more the hub spec.

Thanks
Chin Liang

> 
> Best regards,

[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Marek Vasut]

On Thursday, January 14, 2016 at 03:50:18 PM, Chin Liang See wrote:
> On Wed, 2016-01-13 at 16:22 +0100, Marek Vasut wrote:
> > On Wednesday, January 13, 2016 at 04:18:43 PM, Chin Liang See wrote:
> > > On Wed, 2016-01-13 at 03:58 +0100, Marek Vasut wrote:
> > > > On Tuesday, January 05, 2016 at 05:16:05 PM, Marek Vasut wrote:
> > > > > On Tuesday, January 05, 2016 at 04:51:47 PM, Chin Liang See
> > > > > 
> > > > > wrote:
> > > > > > On Tue, 2016-01-05 at 15:36 +0100, Marek Vasut wrote:
> > > > > > > On Tuesday, January 05, 2016 at 06:00:04 AM, Chin Liang See
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > Per DesignWare USB OTG databook, driver should retry up
> > > > > > > > to
> > > > > > > > 3 times when transaction error (hcint.xacterr) happen.
> > > > > > > > But
> > > > > > > > the 3 times doesn't count when the response is nack
> > > > > > > > (hcint.nak) or frame overrun (hcint.frmoverun)
> > > > > > > > 
> > > > > > > > This patch solved the enumeration error as spotted at
> > > > > > > > socfpga
> > > > > > > > cyclone5_socdk when plugging in certain pendrive.
> > > > > > > > 
> > > > > > > > Signed-off-by: Chin Liang See <clsee@altera.com>
> > > > > > > > Cc: Marek Vasut <marex@denx.de>
> > > > > > > > Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> > > > > > > > Cc: Dinh Nguyen <dinh.linux@gmail.com>
> > > > > > > > Cc: Pavel Machek <pavel@denx.de>
> > > > > > > > Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>
> > > > > > > > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > > > > > > > Cc: Alexander Stein <alexanders83@web.de>
> > > > > > > > Cc: Peter Griffin <peter.griffin@linaro.org>
> > > > > > > 
> > > > > > > I applied this change on top of u-boot-socfpga/master and
> > > > > > > tested it
> > > > > > > on
> > > > > > > SoCFPGA CycloneV SoCDK with "Sandisk cruzer force" stick.
> > > > > > > The
> > > > > > > board
> > > > > > > gets
> > > > > > > completely stuck if I have dcache ENABLED and perform 'usb
> > > > > > > reset'.
> > > > > > > This
> > > > > > 
> > > > > > > patch is:
> > > > > > Thanks Marek for testing. I managed to find a SanDisk Cruzer
> > > > > > Blade and
> > > > > > notice the same fail behaviours as yours. FYI, note that this
> > > > > > patch
> > > > > > works well with other 3 pendrive that I have.
> > > > > > 
> > > > > > With SanDisk, the dwc2 driver was timed out as hcint.xfercomp
> > > > > > and
> > > > > > chhltd never get set even after 1s. It keep retrying
> > > > > > endlessly
> > > > > > due to
> > > > > > miss handling for the ETIMEDOUT within this patch.
> > > > > > 
> > > > > > In short, the retry doesn't work for SanDisk but the dcache
> > > > > > disable
> > > > > > works. Need to figure out more what cause the failure.
> > > > > 
> > > > > Excellent, I have one of those too (I bought the entire lineup
> > > > > of
> > > > > these
> > > > > sandisk sticks at one point ;-) )
> > > > 
> > > > Hi, any news on the SoCFPGA USB/QSPI problem investigation?
> > > > Thanks!
> > > 
> > > I am still troubleshooting it. I played with few configuration
> > > within
> > > L3 but not helping. This including avoiding multiple outstanding
> > > transaction and security (allow both secure and non secure).
> > 
> > Yeah
> > 
> > > But all these issue will gone once dcache is off. I believe need to
> > > visit the MMU table.
> > 
> > I was there already ;-) But given enough eyeballs, are bugs are
> > shallow.
> 
> Continue some troubleshooting today. Notice some behavior change where
> the SanDisk Cruzer Blade failed after POR and dcache disable.
> 
> After enabling the debug message, the hub is complaining over current
> (port change = 0x9) on the port where pen drive is plugged in. The port
> status = 0x10 indicate no device present.
> 
> Appreciate any quick advise while digging more the hub spec.

I suspect the data are corrupted somewhere. I wouldn't trust the content
of the descriptor at that point.

[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Marek Vasut]

On Thursday, January 14, 2016 at 04:20:12 PM, Marek Vasut wrote:
> On Thursday, January 14, 2016 at 03:50:18 PM, Chin Liang See wrote:
> > On Wed, 2016-01-13 at 16:22 +0100, Marek Vasut wrote:
> > > On Wednesday, January 13, 2016 at 04:18:43 PM, Chin Liang See wrote:
> > > > On Wed, 2016-01-13 at 03:58 +0100, Marek Vasut wrote:
> > > > > On Tuesday, January 05, 2016 at 05:16:05 PM, Marek Vasut wrote:
> > > > > > On Tuesday, January 05, 2016 at 04:51:47 PM, Chin Liang See
> > > > > > 
> > > > > > wrote:
> > > > > > > On Tue, 2016-01-05 at 15:36 +0100, Marek Vasut wrote:
> > > > > > > > On Tuesday, January 05, 2016 at 06:00:04 AM, Chin Liang See
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > Per DesignWare USB OTG databook, driver should retry up
> > > > > > > > > to
> > > > > > > > > 3 times when transaction error (hcint.xacterr) happen.
> > > > > > > > > But
> > > > > > > > > the 3 times doesn't count when the response is nack
> > > > > > > > > (hcint.nak) or frame overrun (hcint.frmoverun)
> > > > > > > > > 
> > > > > > > > > This patch solved the enumeration error as spotted at
> > > > > > > > > socfpga
> > > > > > > > > cyclone5_socdk when plugging in certain pendrive.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Chin Liang See <clsee@altera.com>
> > > > > > > > > Cc: Marek Vasut <marex@denx.de>
> > > > > > > > > Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> > > > > > > > > Cc: Dinh Nguyen <dinh.linux@gmail.com>
> > > > > > > > > Cc: Pavel Machek <pavel@denx.de>
> > > > > > > > > Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>
> > > > > > > > > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > > > > > > > > Cc: Alexander Stein <alexanders83@web.de>
> > > > > > > > > Cc: Peter Griffin <peter.griffin@linaro.org>
> > > > > > > > 
> > > > > > > > I applied this change on top of u-boot-socfpga/master and
> > > > > > > > tested it
> > > > > > > > on
> > > > > > > > SoCFPGA CycloneV SoCDK with "Sandisk cruzer force" stick.
> > > > > > > > The
> > > > > > > > board
> > > > > > > > gets
> > > > > > > > completely stuck if I have dcache ENABLED and perform 'usb
> > > > > > > > reset'.
> > > > > > > > This
> > > > > > > 
> > > > > > > > patch is:
> > > > > > > Thanks Marek for testing. I managed to find a SanDisk Cruzer
> > > > > > > Blade and
> > > > > > > notice the same fail behaviours as yours. FYI, note that this
> > > > > > > patch
> > > > > > > works well with other 3 pendrive that I have.
> > > > > > > 
> > > > > > > With SanDisk, the dwc2 driver was timed out as hcint.xfercomp
> > > > > > > and
> > > > > > > chhltd never get set even after 1s. It keep retrying
> > > > > > > endlessly
> > > > > > > due to
> > > > > > > miss handling for the ETIMEDOUT within this patch.
> > > > > > > 
> > > > > > > In short, the retry doesn't work for SanDisk but the dcache
> > > > > > > disable
> > > > > > > works. Need to figure out more what cause the failure.
> > > > > > 
> > > > > > Excellent, I have one of those too (I bought the entire lineup
> > > > > > of
> > > > > > these
> > > > > > sandisk sticks at one point ;-) )
> > > > > 
> > > > > Hi, any news on the SoCFPGA USB/QSPI problem investigation?
> > > > > Thanks!
> > > > 
> > > > I am still troubleshooting it. I played with few configuration
> > > > within
> > > > L3 but not helping. This including avoiding multiple outstanding
> > > > transaction and security (allow both secure and non secure).
> > > 
> > > Yeah
> > > 
> > > > But all these issue will gone once dcache is off. I believe need to
> > > > visit the MMU table.
> > > 
> > > I was there already ;-) But given enough eyeballs, are bugs are
> > > shallow.
> > 
> > Continue some troubleshooting today. Notice some behavior change where
> > the SanDisk Cruzer Blade failed after POR and dcache disable.
> > 
> > After enabling the debug message, the hub is complaining over current
> > (port change = 0x9) on the port where pen drive is plugged in. The port
> > status = 0x10 indicate no device present.
> > 
> > Appreciate any quick advise while digging more the hub spec.
> 
> I suspect the data are corrupted somewhere. I wouldn't trust the content
> of the descriptor at that point.

Hi, any news on the USB mess ? :-)

[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Chin Liang See]

On Thu, 2016-02-04 at 12:42 +0100, Marek Vasut wrote:
> On Thursday, January 14, 2016 at 04:20:12 PM, Marek Vasut wrote:
> > On Thursday, January 14, 2016 at 03:50:18 PM, Chin Liang See wrote:
> > > On Wed, 2016-01-13 at 16:22 +0100, Marek Vasut wrote:
> > > 
> > > Continue some troubleshooting today. Notice some behavior change
> > > where
> > > the SanDisk Cruzer Blade failed after POR and dcache disable.
> > > 
> > > After enabling the debug message, the hub is complaining over
> > > current
> > > (port change = 0x9) on the port where pen drive is plugged in.
> > > The port
> > > status = 0x10 indicate no device present.
> > > 
> > > Appreciate any quick advise while digging more the hub spec.
> > 
> > I suspect the data are corrupted somewhere. I wouldn't trust the
> > content
> > of the descriptor at that point.
> 
> Hi, any news on the USB mess ? :-)

Hi Marek,

Sorry for late reply as away for few weeks.
Will look back into this in coming days.
Last troubleshoot was understanding why hub cannot recognize the mass
storage.

Thanks
Chin Liang

[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Marek Vasut]

On 02/19/2016 10:11 AM, Chin Liang See wrote:
> On Thu, 2016-02-04 at 12:42 +0100, Marek Vasut wrote:
>> On Thursday, January 14, 2016 at 04:20:12 PM, Marek Vasut wrote:
>>> On Thursday, January 14, 2016 at 03:50:18 PM, Chin Liang See wrote:
>>>> On Wed, 2016-01-13 at 16:22 +0100, Marek Vasut wrote:
>>>>
>>>> Continue some troubleshooting today. Notice some behavior change
>>>> where
>>>> the SanDisk Cruzer Blade failed after POR and dcache disable.
>>>>
>>>> After enabling the debug message, the hub is complaining over
>>>> current
>>>> (port change = 0x9) on the port where pen drive is plugged in.
>>>> The port
>>>> status = 0x10 indicate no device present.
>>>>
>>>> Appreciate any quick advise while digging more the hub spec.
>>>
>>> I suspect the data are corrupted somewhere. I wouldn't trust the
>>> content
>>> of the descriptor at that point.
>>
>> Hi, any news on the USB mess ? :-)
> 
> Hi Marek,

Hi Chin,

> Sorry for late reply as away for few weeks.
> Will look back into this in coming days.
> Last troubleshoot was understanding why hub cannot recognize the mass
> storage.

Thanks!