[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction
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;
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
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
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
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
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
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,
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,
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.
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 ? :-)
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
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!
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
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@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
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@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
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@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
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@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
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
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
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.
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
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.
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
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.
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.
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.
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.
participants (4)
-
Chin Liang See -
Marek Vasut -
Pavel Machek -
Tom Rini