Re: [PATCH] drivers/usb/host/ehci-xilinx-of.c: Include linux/of_irq.h to avoid compiling error
On Wed, Sep 24, 2014 at 11:41:55AM -0400, Alan Stern wrote: On Mon, 22 Sep 2014, Michal Simek wrote: Hi Alan and Greg, On 09/20/2014 06:19 AM, Chen Gang wrote: Hello Maintainers: Please help check this patch, when you have time. Thanks. On 09/08/2014 01:20 PM, Michal Simek wrote: On 09/03/2014 05:50 PM, Chen Gang wrote: Need include it for irq_of_parse_and_map(), the related error with allmodconfig under microblaze: drivers/usb/host/ehci-xilinx-of.c: In function ?ehci_hcd_xilinx_of_probe?: drivers/usb/host/ehci-xilinx-of.c:156:2: error: implicit declaration of function ?irq_of_parse_and_map? [-Werror=implicit-function-declaration] irq = irq_of_parse_and_map(dn, 0); ^ Signed-off-by: Chen Gang gang.chen.5...@gmail.com --- drivers/usb/host/ehci-xilinx-of.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/ehci-xilinx-of.c b/drivers/usb/host/ehci-xilinx-of.c index fe57710..a232836 100644 --- a/drivers/usb/host/ehci-xilinx-of.c +++ b/drivers/usb/host/ehci-xilinx-of.c @@ -31,6 +31,7 @@ #include linux/of.h #include linux/of_platform.h #include linux/of_address.h +#include linux/of_irq.h /** * ehci_xilinx_port_handed_over - hand the port out if failed to enable it Acked-by: Michal Simek mon...@monstr.eu Alan: Can you please add this patch to your queue? Greg: If Alan is not maintaining this part of kernel, is this patch in your queue? I have also not a problem to add this patch through my microblaze tree but I think it will be much better to use any USB tree. Greg should be able to accept a trivial patch like this one directly. I can, if someone will resend it so I can apply it :) thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
On Thu, Sep 25, 2014 at 10:50:22AM +0530, Vivek Gautam wrote: Hi Greg, On Mon, Sep 22, 2014 at 11:15 AM, Vivek Gautam gautam.vi...@samsung.com wrote: Now that we have completely moved from older USB-PHY drivers to newer GENERIC-PHY drivers for PHYs available with USB controllers on Exynos series of SoCs, we can remove the support for the same in our host drivers too. We also defer the probe for our host in case we end up getting EPROBE_DEFER error when getting PHYs. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Alan Stern st...@rowland.harvard.edu --- Did this one got missed for usb-next ? I can only see usb: host: ohci-exynos: Remove unnecessary usb-phy support in the next branch. Ignore me if you have already taken care of this, and plan to queue it up. If it's not in my tree already, please resend as I don't have this in my queue anymore. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
On Mon, Sep 29, 2014 at 7:21 AM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Sep 25, 2014 at 10:50:22AM +0530, Vivek Gautam wrote: Hi Greg, On Mon, Sep 22, 2014 at 11:15 AM, Vivek Gautam gautam.vi...@samsung.com wrote: Now that we have completely moved from older USB-PHY drivers to newer GENERIC-PHY drivers for PHYs available with USB controllers on Exynos series of SoCs, we can remove the support for the same in our host drivers too. We also defer the probe for our host in case we end up getting EPROBE_DEFER error when getting PHYs. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Alan Stern st...@rowland.harvard.edu --- Did this one got missed for usb-next ? I can only see usb: host: ohci-exynos: Remove unnecessary usb-phy support in the next branch. Ignore me if you have already taken care of this, and plan to queue it up. If it's not in my tree already, please resend as I don't have this in my queue anymore. yea, i don't see it in usb-next. I will resend it then. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 RESEND 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Changes since v4:
- returning 'ret' instead of PTR_ERR(phy), since ret is nothing but that only.
Changes since v3:
- Addressed review comments by Alan:
-- Skipped renaming 'phy_number' variable,
-- resorted to just adding minimal change required for phy assignment.
-- updated patch description to mention EPROBE_DEFER support.
drivers/usb/host/ehci-exynos.c | 74 +++-
1 file changed, 20 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 2eed9a4..7189f2e 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
#include linux/of_gpio.h
#include linux/phy/phy.h
#include linux/platform_device.h
-#include linux/usb/phy.h
-#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
#include linux/usb/hcd.h
-#include linux/usb/otg.h
#include ehci.h
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
struct exynos_ehci_hcd {
struct clk *clk;
- struct usb_phy *phy;
- struct usb_otg *otg;
- struct phy *phy_g[PHY_NUMBER];
+ struct phy *phy[PHY_NUMBER];
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
@@ -60,8 +55,9 @@ static int exynos_ehci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
- int ret = 0;
+ int ret;
+ /* Get PHYs for the controller */
for_each_available_child_of_node(dev-of_node, child) {
ret = of_property_read_u32(child, reg, phy_number);
if (ret) {
@@ -77,31 +73,21 @@ static int exynos_ehci_get_phy(struct device *dev,
}
phy = devm_of_phy_get(dev, child, NULL);
+ exynos_ehci-phy[phy_number] = phy;
of_node_put(child);
- if (IS_ERR(phy))
- /* Lets fallback to older USB-PHYs */
- goto usb_phy_old;
- exynos_ehci-phy_g[phy_number] = phy;
- /* Make the older PHYs unavailable */
- exynos_ehci-phy = ERR_PTR(-ENXIO);
- }
-
- return 0;
-
-usb_phy_old:
- exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(exynos_ehci-phy)) {
- ret = PTR_ERR(exynos_ehci-phy);
- if (ret != -ENXIO ret != -ENODEV) {
- dev_err(dev, no usb2 phy configured\n);
- return ret;
+ if (IS_ERR(phy)) {
+ ret = PTR_ERR(phy);
+ if (ret == -EPROBE_DEFER) {
+ return ret;
+ } else if (ret != -ENOSYS ret != -ENODEV) {
+ dev_err(dev,
+ Error retrieving usb2 phy: %d\n, ret);
+ return ret;
+ }
}
- dev_dbg(dev, Failed to get usb2 phy\n);
- } else {
- exynos_ehci-otg = exynos_ehci-phy-otg;
}
- return ret;
+ return 0;
}
static int exynos_ehci_phy_enable(struct device *dev)
@@ -111,16 +97,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
- if (!IS_ERR(exynos_ehci-phy))
- return usb_phy_init(exynos_ehci-phy);
-
for (i = 0; ret == 0 i PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ehci-phy_g[i]))
- ret = phy_power_on(exynos_ehci-phy_g[i]);
+ if (!IS_ERR(exynos_ehci-phy[i]))
+ ret = phy_power_on(exynos_ehci-phy[i]);
if (ret)
for (i--; i = 0; i--)
- if (!IS_ERR(exynos_ehci-phy_g[i]))
- phy_power_off(exynos_ehci-phy_g[i]);
+ if (!IS_ERR(exynos_ehci-phy[i]))
+ phy_power_off(exynos_ehci-phy[i]);
return ret;
}
@@ -131,14 +114,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
- if (!IS_ERR(exynos_ehci-phy)) {
- usb_phy_shutdown(exynos_ehci-phy);
- return;
- }
-
for (i = 0; i PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ehci-phy_g[i]))
- phy_power_off(exynos_ehci-phy_g[i]);
+ if
Re: [PATCH] drivers: usb :fsl: Add support for USB controller version-2.5
On Mon, Sep 29, 2014 at 03:46:02AM +, nikhil.bad...@freescale.com wrote:
-Original Message-
From: Greg KH [mailto:g...@kroah.com]
Sent: Wednesday, September 24, 2014 10:19 AM
To: Badola Nikhil-B46172
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH] drivers: usb :fsl: Add support for USB controller
version-2.5
On Thu, Aug 21, 2014 at 12:56:22PM +0530, Nikhil Badola wrote:
Add support for USB controller version-2.5 used in
T4240 rev2.0, T1024, B3421, T1040, T2080, LS1021A.
Signed-off-by: Nikhil Badola nikhil.bad...@freescale.com
---
- Depends on commit 990c2c7829d98517228f2b2ff14919c83b75e124
drivers: usb: fsl: Check IP version 2.4 for mph USB controller
drivers/usb/host/fsl-mph-dr-of.c | 5 +
include/linux/fsl_devices.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/usb/host/fsl-mph-dr-of.c
b/drivers/usb/host/fsl-mph-dr-of.c
index e0315de..45b9e36 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -127,6 +127,7 @@ static int usb_get_ver_info(struct device_node *np)
* returns 1 for usb controller version 1.6
* returns 2 for usb controller version 2.2
* returns 3 for usb controller version 2.4
+ * returns 4 for usb controller version 2.5
* returns 0 otherwise
*/
if (of_device_is_compatible(np, fsl-usb2-dr)) { @@ -136,6 +137,8
@@ static int usb_get_ver_info(struct device_node *np)
ver = FSL_USB_VER_2_2;
else if (of_device_is_compatible(np, fsl-usb2-dr-v2.4))
ver = FSL_USB_VER_2_4;
+ else if (of_device_is_compatible(np, fsl-usb2-dr-v2.5))
+ ver = FSL_USB_VER_2_5;
else /* for previous controller versions */
ver = FSL_USB_VER_OLD;
@@ -153,6 +156,8 @@ static int usb_get_ver_info(struct device_node *np)
ver = FSL_USB_VER_2_2;
else if (of_device_is_compatible(np, fsl-usb2-mph-v2.4))
ver = FSL_USB_VER_2_4;
+ else if (of_device_is_compatible(np, fsl-usb2-mph-v2.5))
+ ver = FSL_USB_VER_2_5;
else /* for previous controller versions */
ver = FSL_USB_VER_OLD;
}
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index a82296a..2a2f56b 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -24,6 +24,7 @@
#define FSL_USB_VER_1_6 1
#define FSL_USB_VER_2_2 2
#define FSL_USB_VER_2_4 3
+#define FSL_USB_VER_2_5 4
Why not just keep going and add the rest of the numbers while you are at it?
This is the last controller version of this family hence there would not be
any requirement
to add further numbers.
People always bring products back, you never know this :)
Seriously, what are these two patches doing? You just set the value, never
do
anything with it, what good is it?
We indeed use these macros for controller version specific code, for example
in following snippet from ehci-fsl.c
if (pdata-have_sysif_regs
pdata-controller_ver FSL_USB_VER_1_6
(phy_mode == FSL_USB2_PHY_ULPI)) {
/* check PHY_CLK_VALID to get phy clk valid */
.
.
If we don't set the macros then by default FSL_USB_VER_OLD, which is 0, is
assigned as
controller version and in that case phy_clk_valid bit would not be checked
for controller version 2.4 and 2.5.
You are relying on a define to be a specific value, which seems wrong
as it's impossible to figure this type of thing out. Please use an
enumerated type at the very least if you want to test this type of
thing.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] phy: improved lookup method
On Thursday 25 September 2014 12:30 PM, Heikki Krogerus wrote:
Assume you have 2 phys in your system..
static struct phy_lookup usb_lookup = {
.phy_name = phy-usb.0,
.dev_id = usb.0,
.con_id = usb,
};
static struct phy_lookup sata_lookup = {
.phy_name = sata-usb.1,
.dev_id = sata.0,
.con_id = sata,
};
First you do modprobe phy-usb, the probe of USB PHY driver gets
invoked and it
creates the PHY. The phy-core will find a free id (now it will be 0)
and then
name the phy as phy-usb.0.
Then with modprobe phy-sata, the phy-core will create phy-sata.1.
This is an ideal case where the .phy_name in phy_lookup matches.
Consider if the order is flipped and the user does modprobe phy-sata
first. The
phy_names won't match anymore (the sata phy device name would be
sata-usb.0).
Actually, I don't think there would be this problem if we used the
name of the actual device which is the parent of phy devices, right?
hmm.. but if the parent is a multi-phy phy provider (like pipe3 PHY
driver), we
might end up with the same problem.
I'm not completely sure what you mean? If you are talking about
platforms with multiple instances of a single phy, I don't see how
there could ever be a scenario where we did not know the order in
which they were enumerated. Can you give an example again?
If a single IP implements multiple PHYs (phy-miphy365x.c in linux-phy
next),
the parent for all the phy devices would be the same.
Hold on...
Let's take a step back here. Where could we actually have a scenario
where the phy device, the dev_id (consumer) and the con_id would all
be the same? There can't be such a case.
It's not like you could ever have a driver requesting multiple phys
with the same con_id. You would just get the same phy handle even if
you used dt.
phy1 = phy_get(dev, phy);
...
phy2 = phy_get(dev, phy);
And if the drivers requesting those phys are different, your consumers
are different.
sounds right to me.
Cheers
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/usb/host/ehci-xilinx-of.c: Include linux/of_irq.h to avoid compiling error
On 9/29/14 9:52, Greg Kroah-Hartman wrote: On Wed, Sep 24, 2014 at 11:41:55AM -0400, Alan Stern wrote: On Mon, 22 Sep 2014, Michal Simek wrote: Alan: Can you please add this patch to your queue? Greg: If Alan is not maintaining this part of kernel, is this patch in your queue? I have also not a problem to add this patch through my microblaze tree but I think it will be much better to use any USB tree. Greg should be able to accept a trivial patch like this one directly. I can, if someone will resend it so I can apply it :) This patch you have already applied (applied this patch in 2014-09-24), so I need not resend it. Thank all of you for your work. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL
A question, the dwc3 controller is the PCI-E device in my platform,
but the class code of PCI header is 0x0c0330, the same with xHC.
That's because it need to meet the windows enviroment. The dwc3
controller acted as only host mode to bind with windows xhci driver.
But on linux, sometimes, we auto-bind with xhci driver as well (class
code 0x0c0330) despite we use Pid/Vid on dwc3 driver. Then I need
rmmod xhci_hcd module and modprobe dwc3_pci module manually.
Any idea to resolve this issue?
Declare a fixup quirk. I'm not a pci expert, but I think something
like this should work..
static void dwc3_fix_amd_nl_class(struct pci_dev *pdev)
{
pdev-class = 0x0c03fe;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL,
dwc3_fix_amd_nl_class);
Heikki, can you confirm if your DWC3 incarnations present this same
feature ? :-)
The DWC3 is not given xHCI class code on our boards.
Cheers,
--
heikki
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/4] usb: gadget: Refactor request completion
Hi,
On 09/24/2014 10:43 PM, Michal Sojka wrote:
Use the recently introduced usb_gadget_giveback_request() in favor of
direct invocation of the completion routine.
All places in drivers/usb/ matching [-.]complete( were replaced with a
call to usb_gadget_giveback_request(). This was compile-tested with all
ARM drivers enabled and runtime-tested for musb.
Signed-off-by: Michal Sojka so...@merica.cz
---
drivers/usb/chipidea/udc.c | 6 +++---
drivers/usb/dwc2/gadget.c | 6 +++---
drivers/usb/dwc3/gadget.c | 2 +-
drivers/usb/gadget/udc/amd5536udc.c | 2 +-
drivers/usb/gadget/udc/at91_udc.c | 2 +-
drivers/usb/gadget/udc/atmel_usba_udc.c | 4 ++--
drivers/usb/gadget/udc/bcm63xx_udc.c| 2 +-
drivers/usb/gadget/udc/dummy_hcd.c | 10 +-
drivers/usb/gadget/udc/fotg210-udc.c| 2 +-
drivers/usb/gadget/udc/fsl_qe_udc.c | 6 +-
drivers/usb/gadget/udc/fsl_udc_core.c | 6 ++
drivers/usb/gadget/udc/fusb300_udc.c| 2 +-
drivers/usb/gadget/udc/goku_udc.c | 2 +-
drivers/usb/gadget/udc/gr_udc.c | 2 +-
drivers/usb/gadget/udc/lpc32xx_udc.c| 2 +-
drivers/usb/gadget/udc/m66592-udc.c | 2 +-
drivers/usb/gadget/udc/mv_u3d_core.c| 8 ++--
drivers/usb/gadget/udc/mv_udc_core.c| 8 ++--
drivers/usb/gadget/udc/net2272.c| 2 +-
drivers/usb/gadget/udc/net2280.c| 2 +-
drivers/usb/gadget/udc/omap_udc.c | 2 +-
drivers/usb/gadget/udc/pch_udc.c| 2 +-
drivers/usb/gadget/udc/pxa25x_udc.c | 2 +-
drivers/usb/gadget/udc/pxa27x_udc.c | 2 +-
drivers/usb/gadget/udc/r8a66597-udc.c | 2 +-
drivers/usb/gadget/udc/s3c-hsudc.c | 3 +--
drivers/usb/gadget/udc/s3c2410_udc.c| 2 +-
drivers/usb/musb/musb_gadget.c | 2 +-
drivers/usb/renesas_usbhs/mod_gadget.c | 2 +-
29 files changed, 41 insertions(+), 56 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index b8125aa..0444d3f 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -627,7 +627,7 @@ __acquires(hwep-lock)
if (hwreq-req.complete != NULL) {
spin_unlock(hwep-lock);
- hwreq-req.complete(hwep-ep, hwreq-req);
+ usb_gadget_giveback_request(hwep-ep, hwreq-req);
spin_lock(hwep-lock);
}
}
@@ -922,7 +922,7 @@ __acquires(hwep-lock)
if ((hwep-type == USB_ENDPOINT_XFER_CONTROL)
hwreq-req.length)
hweptemp = hwep-ci-ep0in;
- hwreq-req.complete(hweptemp-ep, hwreq-req);
+ usb_gadget_giveback_request(hweptemp-ep, hwreq-req);
spin_lock(hwep-lock);
}
}
@@ -1347,7 +1347,7 @@ static int ep_dequeue(struct usb_ep *ep, struct
usb_request *req)
if (hwreq-req.complete != NULL) {
spin_unlock(hwep-lock);
- hwreq-req.complete(hwep-ep, hwreq-req);
+ usb_gadget_giveback_request(hwep-ep, hwreq-req);
spin_lock(hwep-lock);
}
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index ce6071d..ada5f30 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -987,8 +987,8 @@ static int s3c_hsotg_process_req_feature(struct s3c_hsotg
*hsotg,
hs_req = ep-req;
ep-req = NULL;
list_del_init(hs_req-queue);
- hs_req-req.complete(ep-ep,
- hs_req-req);
+ usb_gadget_giveback_request(ep-ep,
+
hs_req-req);
}
/* If we have pending request, then start it */
@@ -1245,7 +1245,7 @@ static void s3c_hsotg_complete_request(struct s3c_hsotg
*hsotg,
if (hs_req-req.complete) {
spin_unlock(hsotg-lock);
- hs_req-req.complete(hs_ep-ep, hs_req-req);
+ usb_gadget_giveback_request(hs_ep-ep, hs_req-req);
spin_lock(hsotg-lock);
}
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 490a6ca..45f1dfc 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -268,7 +268,7 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct
dwc3_request *req,
req-request.length, status);
spin_unlock(dwc-lock);
- req-request.complete(dep-endpoint, req-request);
+ usb_gadget_giveback_request(dep-endpoint, req-request);
spin_lock(dwc-lock);
}
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
Re: [PATCH v6 2/4] usb: gadget: Refactor request completion
On Mon, Sep 29 2014, Robert Baldyga wrote: Hi, On 09/24/2014 10:43 PM, Michal Sojka wrote: Use the recently introduced usb_gadget_giveback_request() in favor of direct invocation of the completion routine. All places in drivers/usb/ matching [-.]complete( were replaced with a call to usb_gadget_giveback_request(). This was compile-tested with all ARM drivers enabled and runtime-tested for musb. Signed-off-by: Michal Sojka so...@merica.cz [...] diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c b/drivers/usb/gadget/udc/fsl_qe_udc.c index 7324308..dd18ea3 100644 --- a/drivers/usb/gadget/udc/fsl_qe_udc.c +++ b/drivers/usb/gadget/udc/fsl_qe_udc.c @@ -118,10 +118,7 @@ static void done(struct qe_ep *ep, struct qe_req *req, int status) ep-stopped = 1; spin_unlock(udc-lock); -/* this complete() should a func implemented by gadget layer, - * eg fsg-bulk_in_complete() */ -if (req-req.complete) -req-req.complete(ep-ep, req-req); +usb_gadget_giveback_request(ep-ep, req-req); It looks like you have omitted if() statement. Are you sure that request has set complete() callback? Yes, see the rest of the thread. This was suggested by other reviewers. -Michal -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB changes for v3.18 merge window
On Wed, Sep 17, 2014 at 7:56 PM, Felipe Balbi ba...@ti.com wrote:
Andrzej Pietrasiewicz (23):
usb: gadget: uvc: rename functions to avoid conflicts with host uvc
It seems not everything got renamed:
drivers/usb/gadget/function/uvc_v4l2.c:363:23: error:
'uvcg_v4l2_get_unmapped_area' undeclared here (not in a function)
make[5]: *** [drivers/usb/gadget/function/uvc_v4l2.o] Error 1
http://kisskb.ellerman.id.au/kisskb/buildresult/12028115/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL
On Sun, Sep 28, 2014 at 06:41:39PM -0500, Felipe Balbi wrote:
Hi,
On Sun, Sep 28, 2014 at 11:11:23AM +0800, Huang Rui wrote:
On Fri, Sep 26, 2014 at 09:35:21AM -0500, Felipe Balbi wrote:
On Fri, Sep 26, 2014 at 04:50:26PM +0800, Huang Rui wrote:
On Thu, Sep 25, 2014 at 09:50:32AM -0500, Felipe Balbi wrote:
Hi,
On Thu, Sep 25, 2014 at 03:21:46PM +0800, Huang Rui wrote:
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3
*dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ * @dwc: Pointer to our controller context structure
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK |
DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX |
DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE |
DWC3_GUSB3PIPECTL_RX_DETOPOLL;
UX_EXITINPX is supposed to be used with a faulty PHY, I need to see an
erratum before I can accept it. You have also duplicated the bit in
this
initialization.
U1U2EXITFAIL - also a workaround bit and I need to see an erratum.
RX_DETOPOLL - it seems like it's safe to leave this one out as it can
only be proven to work with this bit after going through full USB
certification.
What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.
Look at the description of each of those bits and you'll see it mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX, as an
example:
This bit is added for SS PHY workaround where SS PHY ...
Got it, so faulty PHY you meant that some special PHYs didn't not meet
the standards someplace.
For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.
Thanks, that's great. I wonder if there's a way to detect that we're
running on FPGA. Can you check with your HW designers ? I'll go dig on
Synopsys databook myself too on Monday.
I checked with HW designers, they can update the origin value of GUID
register of FPGA to add ASCII codes as prefix of fpga. I can checked
it before driver re-writes it as kernel version (I see you latest
testing branch have this behavior).
It's alright that AMD PHY needs this bit, but then, let's get
confirmation from IP/SoC/SilVal team and add a proper comment stating
why we need them. This is so we don't forget that $version of AMD's PHY
needs workarounds for A, B, and C silicon errata.
Yes, but currently, I needn't write AMD own phy driver. There isn't
any requirement from HW side to program the phy register. So I used
NOP USB transceiver driver till now.
NOP is a perfectly valid use-case :-) We still want to know that version
x of AMD's PHY is quirky on these or that case :-)
I can use the SMBus revsion ID for different chips version of amd. You
can refer usb/host/pci-quirks.c, I already added the different chip
version macros there for xHC. If PHY version updates, the chip version
must update too.
Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches.
I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under 3.14
before.
v3.14 is rather old, if you're sending patches upstream. I'd rather see
patches tested with either next or latest Linus' tag. My testing/next
branch is also usually fine too.
Yes, I am doing these testing.
An issue meet your msc.c.
ray@hr-slim:~/felipe/usb-tools$ gcc -Wall -O2 -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -o msc msc.c
/tmp/ccUBcDC4.o: In function `do_write':
/home/ray/felipe/usb-tools/msc.c:275: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:308: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o: In function `do_read':
/home/ray/felipe/usb-tools/msc.c:332: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:349: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o: In function `do_writev':
/home/ray/felipe/usb-tools/msc.c:401: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o:/home/ray/felipe/usb-tools/msc.c:407: more undefined references
to `clock_gettime' follow
collect2: ld returned 1 exit status
Any idea?
If you want, you can definitely defer a v2 until v3.18-rc1 is tagged.
Do you mean: when kernel upgrade to v3.18-rc1,
[PATCH v3 1/1] usb: chipidea: using devm_request_irq to instead of request_irq
Using devm_request_irq to instead of request_irq. Suggested-by: Arnd Bergmann a...@arndb.de Signed-off-by: Peter Chen peter.c...@freescale.com --- Changes for v3: - Fix checkpatch.pl error Changes for v2: - Fix missing 'dev' for devm_request_irq drivers/usb/chipidea/core.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index 3df5005..9e9dc64 100644 --- a/drivers/usb/chipidea/core.c +++ b/drivers/usb/chipidea/core.c @@ -712,8 +712,8 @@ static int ci_hdrc_probe(struct platform_device *pdev) } platform_set_drvdata(pdev, ci); - ret = request_irq(ci-irq, ci_irq, IRQF_SHARED, ci-platdata-name, - ci); + ret = devm_request_irq(dev, ci-irq, ci_irq, IRQF_SHARED, + ci-platdata-name, ci); if (ret) goto stop; @@ -724,7 +724,6 @@ static int ci_hdrc_probe(struct platform_device *pdev) if (!ret) return 0; - free_irq(ci-irq, ci); stop: ci_role_destroy(ci); deinit_phy: @@ -738,7 +737,6 @@ static int ci_hdrc_remove(struct platform_device *pdev) struct ci_hdrc *ci = platform_get_drvdata(pdev); dbg_remove_files(ci); - free_irq(ci-irq, ci); ci_role_destroy(ci); ci_hdrc_enter_lpm(ci, true); usb_phy_shutdown(ci-transceiver); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: f_rndis: fix usb_interface_descriptor for rndis
Hello Lars, sorry for my late answer ... Am 24.09.2014 16:22, schrieb Lars Melin: On 2014-09-24 20:12, Heiko Schocher wrote: Hello Lars, Am 24.09.2014 14:25, schrieb Lars Melin: On 2014-09-24 13:48, Heiko Schocher wrote: use the values for RNDIS over Ethernet as defined in http://www.usb.org/developers/defined_class (search for RDNIS): - baseclass: 0xef (miscellaneous) - subclass: 0x04 - protocol: 0x01 That is usb class, it is not the same thing as communication device class. --- a/include/uapi/linux/usb/cdc.h +++ b/include/uapi/linux/usb/cdc.h @@ -12,6 +12,7 @@ #include linux/types.h #define USB_CDC_SUBCLASS_ACM 0x02 +#define USB_CDC_SUBCLASS_RNDIS 0x04 No, no, no. There is no CDC_SUBCLASS_RNDIS and you can not define one over an already used cdc subclass number, 0x04 is Multi-Channel Control Model Ah, ok, so I have to define this values in a new header file, as there is no current file for the USB_CLASS_MISC defines? Or is there a proper place for them? BTW: where do I find the cdc subclass number, 0x04 is Multi-Channel Control Model define? bye, Heiko You can still find the original specification usbcdc11.pdf on the net if you google for it, it has been pulled from usb.org where you could download it until a few years ago. It is old but covers a lot of what you need to know. Hmm.. maybe I am to dummy for finding this docment... http://www.usb.org/results?q=usbcdc11.pdfsubmit=Search does not find this document ... could you send me a direct link? I found with the above search: http://www.usb.org/developers/defined_class and this site, exactly describes the values for RNDIS over ethernet, as my patch changes [1] Linux has afaik only the cdc.h definition file, everything else is coded by class/subclass in respectively drivers when needed. why not in header files? I thought, magical values are not welcome in source code ... As for the is_rndis() function case, this function is defined in 2 places: - drivers/net/usb/cdc_ether.c - drivers/usb/core/generic.c Has this a special reason? This seems suboptimal to me ... 02/02/ff or e0/01/03 are the most common interface attribute for rndis, both of them together with a data interface with attributes 0a/00/00. I must admit, I am not a USB nor a RNDIS expert ... Please check the whitelisting in drivers/net/usb/rndis_host.c and also blacklistings in other net drivers under the same path, it should give you an idea how to bind an interface to a specific driver by interface attributes and/or usb vid:pid. You should be able to do the same for your particular device. Hmm.. I did not understand you here ... so, one step back: I got from a customer this patch (in a similiar version) and he did tests with [3] and saw, that a board which runs linux, is seen in [3] with the values [2] ... so he changed the values in drivers/usb/gadget/function/f_rndis.c to the values [1], which are documented in [4] and with them the test [3] is happy ... and the file Documentation/usb/linux.inf is not longer needed on the windows pc! So he (and at the end I too) thought, that this is the proper way to make [3] happy ... (maybe [3] is incorrect ? ) Is current ML code correct? And if yes, why? If the values [2] in current ML linux are correct, could you say me, where they are documented? (and sorry for my stupid questions ...) Thanks! bye, Heiko [1] values which my patch sets for RNDIS over ethernet - baseclass: 0xef (miscellaneous) - subclass: 0x04 - protocol: 0x01 [2] currently used values for RNDIS over ethernet - baseclass: 0x02 (USB_CLASS_COMM) - subclass: 0x02 - protocol: 0xff [3] USB Compliance test suite which runs Windows, see: http://www.usb.org/developers/tools/usb20_tools/#usb20cv [4] http://www.usb.org/developers/defined_class -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Urb completion handler returns -32
Hi All, I want to know the reason for getting INT urb completion status as -EPIPE ? Thanks, Pnav -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: uvc: fix up uvcg_v4l2_get_unmapped_area typo
Patch usb: gadget: uvc: rename functions to avoid conflicts with host uvc
renamed a lot of symbols but missed one references that was inside of
an #ifdef:
drivers/usb/gadget/function/uvc_v4l2.c:363:23: error:
'uvcg_v4l2_get_unmapped_area' undeclared here (not in a function)
.get_unmapped_area = uvcg_v4l2_get_unmapped_area,
^
drivers/usb/gadget/function/uvc_v4l2.c:344:22: warning:
'uvc_v4l2_get_unmapped_area' defined but not used [-Wunused-function]
static unsigned long uvc_v4l2_get_unmapped_area(struct file *file,
^
This renames the reference according the changed function name.
Signed-off-by: Arnd Bergmann a...@arndb.de
Fixes: 7ea95b110811 (usb: gadget: uvc: rename functions to avoid conflicts
with host uvc)
Cc: Andrzej Pietrasiewicz andrze...@samsung.com
Cc: Michael Grzeschik m.grzesc...@pengutronix.de
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Felipe Balbi ba...@ti.com
Cc: linux-usb@vger.kernel.org
---
diff --git a/drivers/usb/gadget/function/uvc_v4l2.c
b/drivers/usb/gadget/function/uvc_v4l2.c
index b52f2681ec21..5aad7fededa5 100644
--- a/drivers/usb/gadget/function/uvc_v4l2.c
+++ b/drivers/usb/gadget/function/uvc_v4l2.c
@@ -341,7 +341,7 @@ uvc_v4l2_poll(struct file *file, poll_table *wait)
}
#ifndef CONFIG_MMU
-static unsigned long uvc_v4l2_get_unmapped_area(struct file *file,
+static unsigned long uvcg_v4l2_get_unmapped_area(struct file *file,
unsigned long addr, unsigned long len, unsigned long pgoff,
unsigned long flags)
{
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: uvc: fix up uvcg_v4l2_get_unmapped_area typo
Hi Arnd,
Thank you for the patch.
On Monday 29 September 2014 14:30:20 Arnd Bergmann wrote:
Patch usb: gadget: uvc: rename functions to avoid conflicts with host uvc
renamed a lot of symbols but missed one references that was inside of
an #ifdef:
drivers/usb/gadget/function/uvc_v4l2.c:363:23: error:
'uvcg_v4l2_get_unmapped_area' undeclared here (not in a function)
.get_unmapped_area = uvcg_v4l2_get_unmapped_area,
^
drivers/usb/gadget/function/uvc_v4l2.c:344:22: warning:
'uvc_v4l2_get_unmapped_area' defined but not used [-Wunused-function]
static unsigned long uvc_v4l2_get_unmapped_area(struct file *file, ^
This renames the reference according the changed function name.
Signed-off-by: Arnd Bergmann a...@arndb.de
Fixes: 7ea95b110811 (usb: gadget: uvc: rename functions to avoid conflicts
with host uvc) Cc: Andrzej Pietrasiewicz andrze...@samsung.com
Cc: Michael Grzeschik m.grzesc...@pengutronix.de
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Felipe Balbi ba...@ti.com
Cc: linux-usb@vger.kernel.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Felipe, could you please this up ?
---
diff --git a/drivers/usb/gadget/function/uvc_v4l2.c
b/drivers/usb/gadget/function/uvc_v4l2.c index b52f2681ec21..5aad7fededa5
100644
--- a/drivers/usb/gadget/function/uvc_v4l2.c
+++ b/drivers/usb/gadget/function/uvc_v4l2.c
@@ -341,7 +341,7 @@ uvc_v4l2_poll(struct file *file, poll_table *wait)
}
#ifndef CONFIG_MMU
-static unsigned long uvc_v4l2_get_unmapped_area(struct file *file,
+static unsigned long uvcg_v4l2_get_unmapped_area(struct file *file,
unsigned long addr, unsigned long len, unsigned long pgoff,
unsigned long flags)
{
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB changes for v3.18 merge window
Hi Geert, On Monday 29 September 2014 11:31:30 Geert Uytterhoeven wrote: On Wed, Sep 17, 2014 at 7:56 PM, Felipe Balbi ba...@ti.com wrote: Andrzej Pietrasiewicz (23): usb: gadget: uvc: rename functions to avoid conflicts with host uvc It seems not everything got renamed: drivers/usb/gadget/function/uvc_v4l2.c:363:23: error: 'uvcg_v4l2_get_unmapped_area' undeclared here (not in a function) make[5]: *** [drivers/usb/gadget/function/uvc_v4l2.o] Error 1 http://kisskb.ellerman.id.au/kisskb/buildresult/12028115/ Indeed :-/ I should have caught that, my bad. Arnd has sent a patch to fix the problem, I've asked Felipe to apply it. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Urb completion handler returns -32
Hi All, Sorry I forgot to add this small detail: I am having a USB bluetooth dongle and it support Control \ Interrupt \ Bulk \ Isochronous Transfers. I am having a device driver for this, In driver probe function I am submitting an URB to INT endpoint. And in the completion handler again re-queue that URB. Most of the times I see urb-status as -32(EPIPE) in INT urb completion handler. Here I don’t know why I am getting this error. This error observed if I connect more than three devices to host via USB-Hub. Can anyone tell me what might be the reason for getting this error. Thanks, Pnav On Mon, Sep 29, 2014 at 5:49 PM, Naveen Kumar Parna pnaveen...@gmail.com wrote: Hi All, I want to know the reason for getting INT urb completion status as -EPIPE ? Thanks, Pnav -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: msm: Fix Sparse warning
This change fixes below sparse warning:
drivers/usb/phy/phy-msm-usb.c:1397:30:
warning: symbol 'msm_otg_mode_fops' was not declared.Should it be static?
Cc: Srinivas Kandagatla srinivas.kandaga...@linaro.org
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-usb@vger.kernel.org
Signed-off-by: Pramod Gurav pramod.gu...@smartplayin.com
---
drivers/usb/phy/phy-msm-usb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 4bc3fd7..f663f32 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1394,7 +1394,7 @@ out:
return status;
}
-const struct file_operations msm_otg_mode_fops = {
+static const struct file_operations msm_otg_mode_fops = {
.open = msm_otg_mode_open,
.read = seq_read,
.write = msm_otg_mode_write,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: host: st: fix ehci/ohci driver selection
The newly added sti ehci and ohci drivers come with a single Kconfig entry that does not depend on either of the base drivers, which leads to a link error when they are disabled: drivers/built-in.o: In function `ohci_platform_init': :(.init.text+0x14788): undefined reference to `ohci_init_driver' To fix that, this patch introduces two separate Kconfig options with proper dependencies, which avoids the problem and is also more consistent with the other glue drivers. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: d115837259ada (usb: host: ohci-st: Add OHCI driver support for ST STB devices) Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Peter Griffin peter.grif...@linaro.org Cc: Alan Stern st...@rowland.harvard.edu Cc: linux-usb@vger.kernel.org diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index b943545f862c..002ba1d5bcf5 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -174,6 +174,15 @@ config USB_EHCI_HCD_SPEAR Enables support for the on-chip EHCI controller on ST SPEAr chips. +config USB_EHCI_HCD_STI + tristate Support for ST STiHxxx on-chip EHCI USB controller + depends on ARCH_STI OF + select GENERIC_PHY + select USB_EHCI_HCD_PLATFORM + help + Enable support for the on-chip EHCI controller found on + STMicroelectronics consumer electronics SoC's. + config USB_EHCI_HCD_AT91 tristate Support for Atmel on-chip EHCI USB controller depends on USB_EHCI_HCD ARCH_AT91 @@ -402,6 +411,15 @@ config USB_OHCI_HCD_SPEAR Enables support for the on-chip OHCI controller on ST SPEAr chips. +config USB_OHCI_HCD_STI + tristate Support for ST STiHxxx on-chip OHCI USB controller + depends on ARCH_STI OF + select GENERIC_PHY + select USB_OHCI_HCD_PLATFORM + help + Enable support for the on-chip OHCI controller found on + STMicroelectronics consumer electronics SoC's. + config USB_OHCI_HCD_S3C2410 tristate OHCI support for Samsung S3C24xx/S3C64xx SoC series depends on USB_OHCI_HCD (ARCH_S3C24XX || ARCH_S3C64XX) @@ -761,14 +779,6 @@ config USB_HCD_SSB If unsure, say N. -config USB_HCD_ST - tristate ST USB driver for ST SoC Series - depends on ARCH_STI OF - select GENERIC_PHY - help - Enable support for the on-chip OHCI EHCI controller found on - STMicroelectronics consumer electronics SoC's. - config USB_HCD_TEST_MODE bool HCD test mode support ---help--- diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index ae2db0b87993..0336bb2c0e6f 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -38,6 +38,7 @@ obj-$(CONFIG_USB_EHCI_MXC)+= ehci-mxc.o obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o +obj-$(CONFIG_USB_EHCI_HCD_ST) += ehci-st.o obj-$(CONFIG_USB_EHCI_EXYNOS) += ehci-exynos.o obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o @@ -55,6 +56,7 @@ obj-$(CONFIG_USB_OHCI_EXYNOS) += ohci-exynos.o obj-$(CONFIG_USB_OHCI_HCD_OMAP1) += ohci-omap.o obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o +obj-$(CONFIG_USB_OHCI_HCD_STI) += ohci-st.o obj-$(CONFIG_USB_OHCI_HCD_AT91)+= ohci-at91.o obj-$(CONFIG_USB_OHCI_HCD_S3C2410) += ohci-s3c2410.o obj-$(CONFIG_USB_OHCI_HCD_LPC32XX) += ohci-nxp.o @@ -77,4 +79,3 @@ obj-$(CONFIG_USB_HCD_SSB) += ssb-hcd.o obj-$(CONFIG_USB_FUSBH200_HCD) += fusbh200-hcd.o obj-$(CONFIG_USB_FOTG210_HCD) += fotg210-hcd.o obj-$(CONFIG_USB_MAX3421_HCD) += max3421-hcd.o -obj-$(CONFIG_USB_HCD_ST) += ehci-st.o ohci-st.o -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Urb completion handler returns -32
On Mon, 29 Sep 2014, Naveen Kumar Parna wrote: Hi All, I want to know the reason for getting INT urb completion status as -EPIPE ? The most common reasons are: The device replied with a STALL. The device runs at low speed or full speed and is connected through a USB-2 hub. Under those conditions, URBs complete with -EPIPE status when the device is disconnected. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: host: st: fix ehci/ohci driver selection
On Mon, 29 Sep 2014, Arnd Bergmann wrote: The newly added sti ehci and ohci drivers come with a single Kconfig entry that does not depend on either of the base drivers, which leads to a link error when they are disabled: drivers/built-in.o: In function `ohci_platform_init': :(.init.text+0x14788): undefined reference to `ohci_init_driver' To fix that, this patch introduces two separate Kconfig options with proper dependencies, which avoids the problem and is also more consistent with the other glue drivers. Not to mention that the patch places the new Kconfig options inside the appropriate if blocks. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: d115837259ada (usb: host: ohci-st: Add OHCI driver support for ST STB devices) Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Peter Griffin peter.grif...@linaro.org Cc: Alan Stern st...@rowland.harvard.edu Cc: linux-usb@vger.kernel.org Acked-by: Alan Stern st...@rowland.harvard.edu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB changes for v3.18 merge window
On Mon, Sep 29, 2014 at 03:35:22PM +0300, Laurent Pinchart wrote: Hi Geert, On Monday 29 September 2014 11:31:30 Geert Uytterhoeven wrote: On Wed, Sep 17, 2014 at 7:56 PM, Felipe Balbi ba...@ti.com wrote: Andrzej Pietrasiewicz (23): usb: gadget: uvc: rename functions to avoid conflicts with host uvc It seems not everything got renamed: drivers/usb/gadget/function/uvc_v4l2.c:363:23: error: 'uvcg_v4l2_get_unmapped_area' undeclared here (not in a function) make[5]: *** [drivers/usb/gadget/function/uvc_v4l2.o] Error 1 http://kisskb.ellerman.id.au/kisskb/buildresult/12028115/ Indeed :-/ I should have caught that, my bad. Arnd has sent a patch to fix the problem, I've asked Felipe to apply it. another one that my randconfig tests didn't catch :-s -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 2/4] usb: gadget: Refactor request completion
Hi, On Mon, Sep 29, 2014 at 10:50:02AM +0200, Robert Baldyga wrote: diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c b/drivers/usb/gadget/udc/fsl_qe_udc.c index 7324308..dd18ea3 100644 --- a/drivers/usb/gadget/udc/fsl_qe_udc.c +++ b/drivers/usb/gadget/udc/fsl_qe_udc.c @@ -118,10 +118,7 @@ static void done(struct qe_ep *ep, struct qe_req *req, int status) ep-stopped = 1; spin_unlock(udc-lock); - /* this complete() should a func implemented by gadget layer, -* eg fsg-bulk_in_complete() */ - if (req-req.complete) - req-req.complete(ep-ep, req-req); + usb_gadget_giveback_request(ep-ep, req-req); It looks like you have omitted if() statement. Are you sure that request has set complete() callback? complete is mandatory. If a request comes without a complete, it deserves to oops. Maybe it's worth to add this if inside usb_gadget_giveback_request() function? nope, we want those cases to oops so we catch the broken gadget driver. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL
Hi,
On Mon, Sep 29, 2014 at 05:38:32PM +0800, Huang Rui wrote:
On Thu, Sep 25, 2014 at 03:21:46PM +0800, Huang Rui wrote:
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3
*dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ * @dwc: Pointer to our controller context structure
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK |
DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX |
DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE |
DWC3_GUSB3PIPECTL_RX_DETOPOLL;
UX_EXITINPX is supposed to be used with a faulty PHY, I need to see
an
erratum before I can accept it. You have also duplicated the bit in
this
initialization.
U1U2EXITFAIL - also a workaround bit and I need to see an erratum.
RX_DETOPOLL - it seems like it's safe to leave this one out as it
can
only be proven to work with this bit after going through full USB
certification.
What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.
Look at the description of each of those bits and you'll see it mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX, as an
example:
This bit is added for SS PHY workaround where SS PHY ...
Got it, so faulty PHY you meant that some special PHYs didn't not meet
the standards someplace.
For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.
Thanks, that's great. I wonder if there's a way to detect that we're
running on FPGA. Can you check with your HW designers ? I'll go dig on
Synopsys databook myself too on Monday.
I checked with HW designers, they can update the origin value of GUID
register of FPGA to add ASCII codes as prefix of fpga. I can checked
it before driver re-writes it as kernel version (I see you latest
testing branch have this behavior).
while that's a nice idea, it wouldn't work for everybody; only AMD.
If there's no generic way implemented by Synopsys into the RTL, then
we better not add anything.
It's alright that AMD PHY needs this bit, but then, let's get
confirmation from IP/SoC/SilVal team and add a proper comment stating
why we need them. This is so we don't forget that $version of AMD's PHY
needs workarounds for A, B, and C silicon errata.
Yes, but currently, I needn't write AMD own phy driver. There isn't
any requirement from HW side to program the phy register. So I used
NOP USB transceiver driver till now.
NOP is a perfectly valid use-case :-) We still want to know that version
x of AMD's PHY is quirky on these or that case :-)
I can use the SMBus revsion ID for different chips version of amd. You
can refer usb/host/pci-quirks.c, I already added the different chip
version macros there for xHC. If PHY version updates, the chip version
must update too.
Please provide a patch and let's discuss :-)
Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches.
I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under 3.14
before.
v3.14 is rather old, if you're sending patches upstream. I'd rather see
patches tested with either next or latest Linus' tag. My testing/next
branch is also usually fine too.
Yes, I am doing these testing.
An issue meet your msc.c.
ray@hr-slim:~/felipe/usb-tools$ gcc -Wall -O2 -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -o msc msc.c
/tmp/ccUBcDC4.o: In function `do_write':
/home/ray/felipe/usb-tools/msc.c:275: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:308: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o: In function `do_read':
/home/ray/felipe/usb-tools/msc.c:332: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:349: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o: In function `do_writev':
/home/ray/felipe/usb-tools/msc.c:401: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o:/home/ray/felipe/usb-tools/msc.c:407: more undefined
references to `clock_gettime' follow
collect2: ld returned 1 exit status
Any idea?
builds fine here:
$ make clean
Re: problems with usb stick after suspend and wake up
On Mon, 29 Sep 2014, Norbert Preining wrote: Hi Alan, sorry for the journalctl output. I have now done the following:L * boot into 3.17-rc7 * mount the usb stick (recovery completed) * unmount, mount, unmount - just to be sure all is fine * started usbmon capturing on bus 3 * mount the usb stick * suspend to ram * wake up now the stick is officially mounted (/proc/mounts) * umount error messages pop up * try to mount more error messages * capture dmesg output * stip usbmon The two files are available here: http://www.preining.info/kernel/3.mon.out.gz (size 21596) http://www.preining.info/kernel/3.mon.out (size 216343) and http://www.preining.info/kernel/dmesg.log.gz (size 17883) http://www.preining.info/kernel/dmesg.log (size 67734) Just a few more things: * usb persistency is turned on * I checked the stick with badblocks during creation of the fs The first error occurred the first time the computer tried to write data to the stick following the resume. Oddly enough, an earlier write before the suspend worked correctly. But the real problem occurred when the computer asked the stick to provide the reason for the error. At that point the stick refused to answer. There were several resets, and the write was retried after each reset. And each time the write failed, and the stick refused to answer when asked the reason for the failure. There's no obvious cause for this problem. It really looks like something is wrong with the USB stick. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/4] usb: dwc3: introduce dual role switch function with debugfs
On Mon, Sep 29, 2014 at 09:35:07AM +0800, Huang Rui wrote: On Fri, Sep 26, 2014 at 09:35:55AM -0500, Felipe Balbi wrote: Hi, On Fri, Sep 26, 2014 at 05:22:09PM +0800, Huang Rui wrote: What you need here is something to talk to usbcore and udc-core and orchestrate the mode change through usb_add_hcd()/usb_add_gadget_udc() and their counterparts. George Cherian is already working on a version of that. I saw your tree have a dwc3-role-switch branch, is that you mentioned here for the working. unfortunately not, what George is working is not there yet :-s So I will drop for this patch on V2, and focus on AMD NL support patches submission firstly, is that OK? yup, that's fine. Thanks -- balbi signature.asc Description: Digital signature
Re: problems with usb stick after suspend and wake up
El 29/09/14 11:15, Alan Stern escribió: The first error occurred the first time the computer tried to write data to the stick following the resume. Oddly enough, an earlier write before the suspend worked correctly. But the real problem occurred when the computer asked the stick to provide the reason for the error. At that point the stick refused to answer. There were several resets, and the write was retried after each reset. And each time the write failed, and the stick refused to answer when asked the reason for the failure. There's no obvious cause for this problem. It really looks like something is wrong with the USB stick. Ok the culprit is the USB stick, but when retrying and seeing that the resets are unsuccessful, could the USB power be removed for the stick for half a second and restored and the write retried then? Have a nice day! P.s.: sorry if I am saying nonsense... -- Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ From Montevideo, Uruguay, at the south of South America. Freelance programmer and GNU/Linux system administrator, hire me! Alternatives: iba...@codigolibre.net - http://go.to/ibaldo -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problems with usb stick after suspend and wake up
On Mon, 29 Sep 2014, Ivan Baldo wrote: El 29/09/14 11:15, Alan Stern escribi�: The first error occurred the first time the computer tried to write data to the stick following the resume. Oddly enough, an earlier write before the suspend worked correctly. But the real problem occurred when the computer asked the stick to provide the reason for the error. At that point the stick refused to answer. There were several resets, and the write was retried after each reset. And each time the write failed, and the stick refused to answer when asked the reason for the failure. There's no obvious cause for this problem. It really looks like something is wrong with the USB stick. Ok the culprit is the USB stick, but when retrying and seeing that the resets are unsuccessful, could the USB power be removed for the stick for half a second and restored and the write retried then? The simple answer is No. Host USB controllers often are not capable of turning off USB power. Besides, what would happen if the device were not a stick but a disk drive with an external power supply? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx
On Wed, Sep 24, 2014 at 04:58:14PM -0700, Sören Brinkmann wrote: On Tue, 2014-09-23 at 12:28PM +0200, Antoine Tenart wrote: Add a USB2 ChipIdea driver for ci13xxx, with optional PHY, clock and DMA mask, to support USB2 ChipIdea controllers that don't need specific functions. Tested on the Marvell Berlin SoCs USB controllers. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com This driver also works for Zynq. I didn't do extensive testing, but I could access a flash drive successfully. Tested-by: Soren Brinkmann soren.brinkm...@xilinx.com Thanks! Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx
Peter, Arnd, Felipe, On Tue, Sep 23, 2014 at 12:28:03PM +0200, Antoine Tenart wrote: Add a USB2 ChipIdea driver for ci13xxx, with optional PHY, clock and DMA mask, to support USB2 ChipIdea controllers that don't need specific functions. Did we agree on the modifications needed to get this accepted? If so, can one of you sum up what's need to be done, I got a bit lost reading all the discussions on this thread. Anyway, that would be good to get this series accepted as the Berlin USB support depends on it. This series has been out since the beginning of June and non-critical changes can be added by future series. Thanks, Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: uvc: fix up uvcg_v4l2_get_unmapped_area typo
On Mon, Sep 29, 2014 at 03:34:11PM +0300, Laurent Pinchart wrote: Hi Arnd, Thank you for the patch. On Monday 29 September 2014 14:30:20 Arnd Bergmann wrote: Patch usb: gadget: uvc: rename functions to avoid conflicts with host uvc renamed a lot of symbols but missed one references that was inside of an #ifdef: drivers/usb/gadget/function/uvc_v4l2.c:363:23: error: 'uvcg_v4l2_get_unmapped_area' undeclared here (not in a function) .get_unmapped_area = uvcg_v4l2_get_unmapped_area, ^ drivers/usb/gadget/function/uvc_v4l2.c:344:22: warning: 'uvc_v4l2_get_unmapped_area' defined but not used [-Wunused-function] static unsigned long uvc_v4l2_get_unmapped_area(struct file *file, ^ This renames the reference according the changed function name. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: 7ea95b110811 (usb: gadget: uvc: rename functions to avoid conflicts with host uvc) Cc: Andrzej Pietrasiewicz andrze...@samsung.com Cc: Michael Grzeschik m.grzesc...@pengutronix.de Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Felipe, could you please this up ? I can take it. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: msm: Fix Sparse warning
On Mon, Sep 29, 2014 at 06:17:40PM +0530, Pramod Gurav wrote: This change fixes below sparse warning: drivers/usb/phy/phy-msm-usb.c:1397:30: warning: symbol 'msm_otg_mode_fops' was not declared.Should it be static? Cc: Srinivas Kandagatla srinivas.kandaga...@linaro.org Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-usb@vger.kernel.org Signed-off-by: Pramod Gurav pramod.gu...@smartplayin.com --- drivers/usb/phy/phy-msm-usb.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) This is already in my tree, why resend it? confused, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: f_rndis: fix usb_interface_descriptor for rndis
On 2014-09-29 19:11, Heiko Schocher wrote: Hello Lars, sorry for my late answer ... Am 24.09.2014 16:22, schrieb Lars Melin: On 2014-09-24 20:12, Heiko Schocher wrote: Hello Lars, Am 24.09.2014 14:25, schrieb Lars Melin: On 2014-09-24 13:48, Heiko Schocher wrote: use the values for RNDIS over Ethernet as defined in http://www.usb.org/developers/defined_class (search for RDNIS): - baseclass: 0xef (miscellaneous) - subclass: 0x04 - protocol: 0x01 That is usb class, it is not the same thing as communication device class. --- a/include/uapi/linux/usb/cdc.h +++ b/include/uapi/linux/usb/cdc.h @@ -12,6 +12,7 @@ #include linux/types.h #define USB_CDC_SUBCLASS_ACM 0x02 +#define USB_CDC_SUBCLASS_RNDIS 0x04 No, no, no. There is no CDC_SUBCLASS_RNDIS and you can not define one over an already used cdc subclass number, 0x04 is Multi-Channel Control Model Ah, ok, so I have to define this values in a new header file, as there is no current file for the USB_CLASS_MISC defines? Or is there a proper place for them? BTW: where do I find the cdc subclass number, 0x04 is Multi-Channel Control Model define? bye, Heiko You can still find the original specification usbcdc11.pdf on the net if you google for it, it has been pulled from usb.org where you could download it until a few years ago. It is old but covers a lot of what you need to know. Hmm.. maybe I am to dummy for finding this docment... http://www.usb.org/results?q=usbcdc11.pdfsubmit=Search does not find this document ... could you send me a direct link? I found with the above search: http://www.usb.org/developers/defined_class I don't know if it is a good idea to provide a link here to a document which usb.org has made unavailable, I told you to google for the file name , not to search for it on usb.org and this site, exactly describes the values for RNDIS over ethernet, as my patch changes [1] Linux has afaik only the cdc.h definition file, everything else is coded by class/subclass in respectively drivers when needed. why not in header files? I thought, magical values are not welcome in source code ... I was wrong, usb class definitions are included in ../include/uapi/linux/usb/ch9.h As for the is_rndis() function case, this function is defined in 2 places: - drivers/net/usb/cdc_ether.c - drivers/usb/core/generic.c Has this a special reason? This seems suboptimal to me ... Yes it has, but the core driver is not an interface driver so it is not of relevance in this case. cdc_ether handles interfaces of device connected to the usb bus, not interfaces of gadget devices created by linux. I got from a customer this patch (in a similiar version) and he did tests with [3] and saw, that a board which runs linux, is seen in [3] with the values [2] ... so he changed the values in drivers/usb/gadget/function/f_rndis.c to the values [1], which are documented in [4] and with them the test [3] is happy ... and the file Documentation/usb/linux.inf is not longer needed on the windows pc! The patch from your customer removed the most common rndis interface attributes and substituted them with one of many other interface attributes which Microsoft uses, this is not the right way of doing it. Why did he patch ../core/generic.c and ../net/usb/cdc_ether.c if he wants to change the interface attributes of g_rndis? Lars -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] usb: renesas_usbhs: Add device tree support for R-Car H2 and M2
Hello.
On 09/03/2014 09:25 AM, Yoshihiro Shimoda wrote:
This driver supports other SoCs, but they need boards/Soc depend code.
So, this patch adds device tree support for R-Car H2 and M2 initially.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
drivers/usb/renesas_usbhs/common.c | 44
1 file changed, 44 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index 1b9bf8d..b3b6813 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -18,6 +18,8 @@
#include linux/gpio.h
#include linux/io.h
#include linux/module.h
+#include linux/of_device.h
+#include linux/of_gpio.h
#include linux/pm_runtime.h
#include linux/slab.h
#include linux/sysfs.h
@@ -438,6 +440,43 @@ static int usbhsc_drvcllbck_notify_hotplug(struct
platform_device *pdev)
[...]
+static struct renesas_usbhs_platform_info *usbhs_parse_dt(struct device *dev)
+{
+ struct renesas_usbhs_platform_info *info;
+ struct renesas_usbhs_driver_param *dparam;
+ const struct of_device_id *of_id = of_match_device(usbhs_of_match, dev);
+ u32 tmp;
+ int gpio;
+
+ info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return NULL;
+
+ dparam = info-driver_param;
+ dparam-type = of_id ? (u32)of_id-data : 0;
+ if (!of_property_read_u32(dev-of_node, renesas,buswait, tmp))
+ dparam-buswait_bwait = tmp;
+ gpio = of_get_named_gpio_flags(dev-of_node, renesas,enable-gpio, 0,
+ NULL);
+ if (gpio 0)
+ dparam-enable_gpio = gpio;
+
+ return info;
I don't see where you parse the optional phy property. It should exist
for the Lager and Koelsch boards you target.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Friday, September 26, 2014 9:31 PM
On Sat, Sep 27, 2014 at 01:05:46AM +, Paul Zimmerman wrote:
Well, it's called LPM Errata because the feature was added to the USB
spec as an erratum. It's not an erratum to our controller. But I don't
have any strong feelings about how the driver support is implemented.
how about adding a has_lpm_erratum to struct dwc3 which gets
initialized either through pdata or DT ? Then above WARN() would become:
WARN(dwc-revision DWC3_REVISION_240A dwc-has_lpm_erratum,
LPM Erratum not available on dwc3 revisisions 2.40a\n);
Then we're not really calling it a quirk. In fact Huang, when respining
your series, let's convert your quirk bits into single-bit fields inside
struct dwc3 and struct platform_data. Like so:
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 4d4e854..e233ce1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -695,11 +695,13 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
+ dwc-has_lpm_erratum = of_property_read_bool(node,
snps,has-lpm-erratum);
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
+ dwc-has_lpm_erratum = pdata-has_lpm_erratum;
dwc-needs_fifo_resize = pdata-tx_fifo_resize;
dwc-dr_mode = pdata-dr_mode;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 66f6256..23e1504 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -661,6 +661,8 @@ struct dwc3_scratchpad_array {
* @ep0_bounced: true when we used bounce buffer
* @ep0_expect_in: true when we expect a DATA IN transfer
* @has_hibernation: true when dwc3 was configured with Hibernation
+ * @has_lpm_erratum: true when core was configured with LPM Erratum. Note
that
+ * there's now way for software to detect this in runtime.
* @is_selfpowered: true when we are selfpowered
* @needs_fifo_resize: not all users might want fifo resizing, flag it
* @pullups_connected: true when Run/Stop bit is set
@@ -764,6 +766,7 @@ struct dwc3 {
unsignedep0_bounced:1;
unsignedep0_expect_in:1;
unsignedhas_hibernation:1;
+ unsignedhas_lpm_erratum:1;
unsignedis_selfpowered:1;
unsignedneeds_fifo_resize:1;
unsignedpullups_connected:1;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 68497b3..112352e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1577,6 +1577,13 @@ static int dwc3_gadget_start(struct usb_gadget *g,
}
dwc3_writel(dwc-regs, DWC3_DCFG, reg);
+ if (dwc-has_lpm_erratum) {
+ reg = dwc3_readl(dwc-regs, DWC3_DCTL);
+ /* REVISIT should this be configurable ? */
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);
+ dwc3_writel(dwc-regs, DWC3_DCTL, reg);
+ }
Yes, I think this really wants to be configurable. The value used is
supposed to depend on the latencies in the system etc.
--
Paul
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] ARM: shmobile: r8a7790: link PCI USB devices to USB PHY
Describe the PCI USB devices that are behind the PCI bridges, adding necessary
links to the USB PHY device.
Based on the original work by Ben Dooks ben.do...@codethink.co.uk.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
This patch is against 'renesas-devel-20140924-v3.17-rc6' tag of Simon Horman's
'renesas.git' repo plus R8A7790/Lager USB PHY support patches posted before.
The patch requires the USB PHY driver and USB HCD generic PHY support (merged
by Kishon and Greg recently) in order to work.
Changes in version 4:
- refreshed the patch.
Changes in version 3:
- adjusted phys properties in the PCI OHCI/EHCI device nodes;
- resolved rejects.
Changes in version 2:
- renamed the PCI OHCI/EHCI device nodes to comply with the PCI binding;
- changed the PHY specifier in the PCI#2 node to reflect that channel #1 support
was dropped;
- resolved rejects, refreshed the patch.
arch/arm/boot/dts/r8a7790.dtsi | 28
1 file changed, 28 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7790.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7790.dtsi
+++ renesas/arch/arm/boot/dts/r8a7790.dtsi
@@ -1107,6 +1107,20 @@
interrupt-map = 0x 0 0 1 gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 gic 0 108 IRQ_TYPE_LEVEL_HIGH;
+
+ usb@0,1 {
+ reg = 0x800 0 0 0 0;
+ device_type = pci;
+ phys = usb0 0;
+ phy-names = usb;
+ };
+
+ usb@0,2 {
+ reg = 0x1000 0 0 0 0;
+ device_type = pci;
+ phys = usb0 0;
+ phy-names = usb;
+ };
};
pci1: pci@ee0b {
@@ -1147,6 +1161,20 @@
interrupt-map = 0x 0 0 1 gic 0 113 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 gic 0 113 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 gic 0 113 IRQ_TYPE_LEVEL_HIGH;
+
+ usb@0,1 {
+ reg = 0x800 0 0 0 0;
+ device_type = pci;
+ phys = usb2 0;
+ phy-names = usb;
+ };
+
+ usb@0,2 {
+ reg = 0x1000 0 0 0 0;
+ device_type = pci;
+ phys = usb2 0;
+ phy-names = usb;
+ };
};
pciec: pcie@fe00 {
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] ARM: shmobile: r8a7791: link PCI USB devices to USB PHY
Describe the PCI USB devices that are behind the PCI bridges, adding necessary
links to the USB PHY device.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
This patch is against 'renesas-devel-20140924-v3.17-rc6' tag of Simon Horman's
'renesas.git' repo plus R8A7791/Koelsch/Henninger USB PHY support patches posted
before. The patch requires the USB PHY driver and USB HCD generic PHY support
(merged by Kishon and Greg recently) in order to work.
Changes in version 4:
- refreshed the patch.
Changes in version 3:
- adjusted phys properties in the PCI OHCI/EHCI device nodes;
- resolved rejects.
Changes in version 2:
- renamed the PCI OHCI/EHCI device nodes to comply with the PCI binding;
- changed the PHY specifier in the PCI#1 node to reflect that channel #1 support
was dropped;
- resolved rejects.
arch/arm/boot/dts/r8a7791.dtsi | 28
1 file changed, 28 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -1125,6 +1125,20 @@
interrupt-map = 0x 0 0 1 gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 gic 0 108 IRQ_TYPE_LEVEL_HIGH;
+
+ usb@0,1 {
+ reg = 0x800 0 0 0 0;
+ device_type = pci;
+ phys = usb0 0;
+ phy-names = usb;
+ };
+
+ usb@0,2 {
+ reg = 0x1000 0 0 0 0;
+ device_type = pci;
+ phys = usb0 0;
+ phy-names = usb;
+ };
};
pci1: pci@ee0d {
@@ -1145,6 +1159,20 @@
interrupt-map = 0x 0 0 1 gic 0 113 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 gic 0 113 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 gic 0 113 IRQ_TYPE_LEVEL_HIGH;
+
+ usb@0,1 {
+ reg = 0x800 0 0 0 0;
+ device_type = pci;
+ phys = usb2 0;
+ phy-names = usb;
+ };
+
+ usb@0,2 {
+ reg = 0x1000 0 0 0 0;
+ device_type = pci;
+ phys = usb2 0;
+ phy-names = usb;
+ };
};
pciec: pcie@fe00 {
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL
Hi,
On Mon, Sep 29, 2014 at 05:59:42PM +, Paul Zimmerman wrote:
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 68497b3..112352e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1577,6 +1577,13 @@ static int dwc3_gadget_start(struct usb_gadget *g,
}
dwc3_writel(dwc-regs, DWC3_DCFG, reg);
+ if (dwc-has_lpm_erratum) {
+ reg = dwc3_readl(dwc-regs, DWC3_DCTL);
+ /* REVISIT should this be configurable ? */
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);
+ dwc3_writel(dwc-regs, DWC3_DCTL, reg);
+ }
Yes, I think this really wants to be configurable. The value used is
supposed to depend on the latencies in the system etc.
alright, in that case we need to pass that through DT/pdata as well.
--
balbi
signature.asc
Description: Digital signature
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Mon, 29 Sep 2014 09:28:37 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: On Sun, 28 Sep 2014, Mark Knibbs wrote: There's no telling the reason for this difference. It's got to be a hardware issue, though, not a software problem. Maybe your xHCI controller just isn't optimized for carrying out full-speed transfers. That's a possibility, but the improvement between my initial test with kernel 3.14 and 3.16.2 (0.63MB/sec - 0.75MB/sec) was obviously down to software. Since you reliably observe a difference in speed between these kernels, you are in an ideal situation to use bisection. That ought to pinpoint the code changes responsible for the speed difference. I'll try to get onto that shortly. It will be very painful on my old laptop though..! I re-tested today with kernel 3.17-rc6 (on Lubuntu 12.04.5) and the USB 3.0 result is back down to ~0.63MB/sec: # sg_rbuf --buffer=524288 -v -t -q /dev/sg5 Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 READ BUFFER reports: buffer capacity=983040, offset boundary=0 time to read data from buffer was 332.637465 secs, 0.63 MB/sec Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) Again, bisection should help. Not a proper bisection, but today I tested various kernels as available from http://kernel.ubuntu.com/~kernel-ppa/mainline/ Quite interesting! It's not a hardware issue after all, and it's quite an old regression. The USB 2 port rates are very consistent over all kernels. 2.6.32 and 2.6.33 are just as fast in USB 3.0 ports (in fact 0.05% faster) as in USB 2.0 ports. The regression occurred between 2.6.33 and 2.6.34, after which USB 1.1 devices work 40% faster in USB 2 ports than USB 3 ports. There was some improvement between 3.10 and 3.14, but things regressed again between 3.16 and 3.17-rc1. Kernel USB2 time USB3 time USB2 rate USB3 rate USB3%of2 %USB2faster 2.6.32.63.26 242.405270 242.283844 865,142.9 865,576.5 100.05%-0.05% 2.6.33.20242.400737 242.285208 865,159.1 865,571.6 100.05%-0.05% 2.6.34.15242.400247 340.095006 865,160.8 616,637.1 71.27% 40.30% 2.6.36.4 242.400864 339.286585 865,158.6 618,106.4 71.44% 39.97% 3.7.10 243.009366 340.206814 862,992.3 616,434.4 71.43% 40.00% 3.10.55 242.400230 336.598467 865,160.9 623,042.6 72.01% 38.86% 3.14.19 242.401219 287.017822 865,157.4 730,669.6 84.46% 18.41% 3.16.2 242.400229 284.858724 865,160.9 736,207.7 85.09% 17.52% 3.16.3 242.400258 289.192172 865,160.8 725,175.9 83.82% 19.30% 3.17-rc1 242.400248 339.129056 865,160.8 618,393.5 71.48% 39.90% 3.17-rc6 242.400239 339.548579 865,160.9 617,629.4 71.39% 40.08% For someone with no actual USB 1.1 drive, could connecting a USB 2.0 drive through an old USB 1.1 hub (then to a USB 2.0 or 3.0 port) work for testing? USB 1.1 hubs are probably still relatively easy to come by. Yes, that would work. Great. I hope someone else is motivated to reproduce the issue. It will take a long time for me to bisect due to my slow computer. Mark -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problems with usb stick after suspend and wake up
Hi Alan, On Mon, 29 Sep 2014, Alan Stern wrote: There were several resets, and the write was retried after each reset. And each time the write failed, and the stick refused to answer when asked the reason for the failure. There's no obvious cause for this problem. It really looks like something is wrong with the USB stick. Hmm, ok, thanks. I think I will return it then. I hope they accept my explanation about it. Thanks for looking into it!!! Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx
On Tue, Sep 23, 2014 at 12:28:03PM +0200, Antoine Tenart wrote:
Add a USB2 ChipIdea driver for ci13xxx, with optional PHY, clock
and DMA mask, to support USB2 ChipIdea controllers that don't need
specific functions.
Tested on the Marvell Berlin SoCs USB controllers.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
drivers/usb/chipidea/Makefile | 1 +
drivers/usb/chipidea/ci_hdrc_usb2.c | 138
2 files changed, 139 insertions(+)
create mode 100644 drivers/usb/chipidea/ci_hdrc_usb2.c
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 2f099c7df7b5..1fc86a2ca22d 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -10,6 +10,7 @@ ci_hdrc-$(CONFIG_USB_OTG_FSM) += otg_fsm.o
# Glue/Bridge layers go here
+obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_usb2.o
obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_msm.o
obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zevio.o
diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c
b/drivers/usb/chipidea/ci_hdrc_usb2.c
new file mode 100644
index ..6eae1de587f2
--- /dev/null
+++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Tenart antoine.ten...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/module.h
+#include linux/of.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/usb/chipidea.h
+#include linux/usb/hcd.h
+#include linux/usb/ulpi.h
+
+#include ci.h
+
+struct ci_hdrc_usb2_priv {
+ struct platform_device *ci_pdev;
+ struct clk *clk;
+};
+
+static int ci_hdrc_usb2_dt_probe(struct device *dev,
+ struct ci_hdrc_platform_data *ci_pdata)
+{
+ ci_pdata-phy = of_phy_get(dev-of_node, 0);
+ if (IS_ERR(ci_pdata-phy)) {
+ if (PTR_ERR(ci_pdata-phy) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* PHY is optional */
+ ci_pdata-phy = NULL;
+ }
+
+ return 0;
+}
+
+static struct ci_hdrc_platform_data ci_default_pdata = {
+ .capoffset = DEF_CAPOFFSET,
+ .flags = CI_HDRC_REQUIRE_TRANSCEIVER |
+ CI_HDRC_DISABLE_STREAMING,
+};
+
+static int ci_hdrc_usb2_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct ci_hdrc_usb2_priv *priv;
+ struct ci_hdrc_platform_data *ci_pdata = dev_get_platdata(pdev-dev);
+ int ret;
+
+ if (!ci_pdata)
+ ci_pdata = ci_default_pdata;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv-clk = devm_clk_get(dev, NULL);
+ if (!IS_ERR(priv-clk)) {
+ ret = clk_prepare_enable(priv-clk);
+ if (ret) {
+ dev_err(dev, failed to enable the clock: %d\n, ret);
+ return ret;
+ }
+ }
+
+ if (dev-of_node) {
+ ret = ci_hdrc_usb2_dt_probe(dev, ci_pdata);
+ if (ret)
+ goto clk_err;
+ } else {
+ ret = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto clk_err;
+ }
My suggestion:
- call dma_coerce_mask_and_coherent(dev-dev, DMA_BIT_MASK(32)) for both
dt and non-dt
- Do not need function ci_hdrc_usb2_dt_probe, the phy handle should be moved
to core driver, since your generic phy driver are still not accepted, I
can't do it by myself. Either you or I can do it after your generic phy support
series has been accepted.
- Others are ok.
Peter
+
+ ci_pdata-name = dev_name(pdev-dev);
+
+ priv-ci_pdev = ci_hdrc_add_device(dev, pdev-resource,
+pdev-num_resources, ci_pdata);
+ if (IS_ERR(priv-ci_pdev)) {
+ ret = PTR_ERR(priv-ci_pdev);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev,
+ failed to register ci_hdrc platform device:
%d\n,
+ ret);
+ goto clk_err;
+ }
+
+ platform_set_drvdata(pdev, priv);
+
+ pm_runtime_no_callbacks(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
+
+clk_err:
+ if (!IS_ERR(priv-clk))
+ clk_disable_unprepare(priv-clk);
+ return ret;
+}
+
+static int ci_hdrc_usb2_remove(struct platform_device *pdev)
+{
+ struct ci_hdrc_usb2_priv *priv = platform_get_drvdata(pdev);
+
+ pm_runtime_disable(pdev-dev);
+ ci_hdrc_remove_device(priv-ci_pdev);
+
Re: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL
On Mon, Sep 29, 2014 at 09:15:13AM -0500, Felipe Balbi wrote:
Hi,
On Mon, Sep 29, 2014 at 05:38:32PM +0800, Huang Rui wrote:
On Thu, Sep 25, 2014 at 03:21:46PM +0800, Huang Rui wrote:
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct
dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ * @dwc: Pointer to our controller context structure
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK |
DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX |
DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE |
DWC3_GUSB3PIPECTL_RX_DETOPOLL;
UX_EXITINPX is supposed to be used with a faulty PHY, I need to
see an
erratum before I can accept it. You have also duplicated the bit
in this
initialization.
U1U2EXITFAIL - also a workaround bit and I need to see an
erratum.
RX_DETOPOLL - it seems like it's safe to leave this one out as
it can
only be proven to work with this bit after going through full USB
certification.
What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.
Look at the description of each of those bits and you'll see it
mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX, as
an
example:
This bit is added for SS PHY workaround where SS PHY ...
Got it, so faulty PHY you meant that some special PHYs didn't not meet
the standards someplace.
For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.
Thanks, that's great. I wonder if there's a way to detect that we're
running on FPGA. Can you check with your HW designers ? I'll go dig on
Synopsys databook myself too on Monday.
I checked with HW designers, they can update the origin value of GUID
register of FPGA to add ASCII codes as prefix of fpga. I can checked
it before driver re-writes it as kernel version (I see you latest
testing branch have this behavior).
while that's a nice idea, it wouldn't work for everybody; only AMD.
If there's no generic way implemented by Synopsys into the RTL, then
we better not add anything.
Because the RTL is frozen.
I checked the spec again of GUID:
1) To store the version or revision of your system
2) To store hardware configurations that are outside the core
3) As a scratch register.
As 2) described, it also makes sence the store the HW configuration (FPGA
version) on this register.
Can we split the 32bit space to two 16bit area, one of them stores the HW
configuration, and the other stores the kernel version? I think other SOC
(especially x86-based) would use this method. :)
It looks like there isn't another register can program into the version info.
It's alright that AMD PHY needs this bit, but then, let's get
confirmation from IP/SoC/SilVal team and add a proper comment stating
why we need them. This is so we don't forget that $version of AMD's
PHY
needs workarounds for A, B, and C silicon errata.
Yes, but currently, I needn't write AMD own phy driver. There isn't
any requirement from HW side to program the phy register. So I used
NOP USB transceiver driver till now.
NOP is a perfectly valid use-case :-) We still want to know that version
x of AMD's PHY is quirky on these or that case :-)
I can use the SMBus revsion ID for different chips version of amd. You
can refer usb/host/pci-quirks.c, I already added the different chip
version macros there for xHC. If PHY version updates, the chip version
must update too.
Please provide a patch and let's discuss :-)
Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches.
I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under 3.14
before.
v3.14 is rather old, if you're sending patches upstream. I'd rather see
patches tested with either next or latest Linus' tag. My testing/next
branch is also usually fine too.
Yes, I am doing these testing.
An issue meet your msc.c.
ray@hr-slim:~/felipe/usb-tools$ gcc
Re: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL
Hi,
On Tue, Sep 30, 2014 at 11:12:55AM +0800, Huang Rui wrote:
On Thu, Sep 25, 2014 at 03:21:46PM +0800, Huang Rui wrote:
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct
dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for
NL
+ * @dwc: Pointer to our controller context structure
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK |
DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX |
DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE |
DWC3_GUSB3PIPECTL_RX_DETOPOLL;
UX_EXITINPX is supposed to be used with a faulty PHY, I need to
see an
erratum before I can accept it. You have also duplicated the
bit in this
initialization.
U1U2EXITFAIL - also a workaround bit and I need to see an
erratum.
RX_DETOPOLL - it seems like it's safe to leave this one out as
it can
only be proven to work with this bit after going through full
USB
certification.
What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.
Look at the description of each of those bits and you'll see it
mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX,
as an
example:
This bit is added for SS PHY workaround where SS PHY ...
Got it, so faulty PHY you meant that some special PHYs didn't not meet
the standards someplace.
For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.
Thanks, that's great. I wonder if there's a way to detect that we're
running on FPGA. Can you check with your HW designers ? I'll go dig on
Synopsys databook myself too on Monday.
I checked with HW designers, they can update the origin value of GUID
register of FPGA to add ASCII codes as prefix of fpga. I can checked
it before driver re-writes it as kernel version (I see you latest
testing branch have this behavior).
while that's a nice idea, it wouldn't work for everybody; only AMD.
If there's no generic way implemented by Synopsys into the RTL, then
we better not add anything.
Because the RTL is frozen.
I checked the spec again of GUID:
1) To store the version or revision of your system
2) To store hardware configurations that are outside the core
3) As a scratch register.
As 2) described, it also makes sence the store the HW configuration (FPGA
version) on this register.
Can we split the 32bit space to two 16bit area, one of them stores the HW
configuration, and the other stores the kernel version? I think other SOC
(especially x86-based) would use this method. :)
It looks like there isn't another register can program into the version info.
the problem is that we won't have something that will work for
everybody. Note that the register can be used as scratch register as
well and there's really no way we will be able to get every RTL designer
in every company out there who's licensing this core to agree on using
this register the exact same way.
Unless it ships already built into the RTL Synopsys delivers, there's
no way we can use it in the core dwc3 driver ;-)
Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches.
I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under 3.14
before.
v3.14 is rather old, if you're sending patches upstream. I'd rather see
patches tested with either next or latest Linus' tag. My testing/next
branch is also usually fine too.
Yes, I am doing these testing.
An issue meet your msc.c.
ray@hr-slim:~/felipe/usb-tools$ gcc -Wall -O2 -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -o msc msc.c
/tmp/ccUBcDC4.o: In function `do_write':
/home/ray/felipe/usb-tools/msc.c:275: undefined reference to
`clock_gettime'
/home/ray/felipe/usb-tools/msc.c:308: undefined reference to
`clock_gettime'
/tmp/ccUBcDC4.o: In function `do_read':
/home/ray/felipe/usb-tools/msc.c:332: undefined reference to
Re: [PATCH v4 0/2] Add USB PHY device tree support for R8A7790/Lager board
On Fri, Sep 26, 2014 at 01:58:01PM -0700, Sergei Shtylyov wrote: Hello. Here's the set of 2 patches against Simon Horman's 'renesas.git' repo, 'renesas-devel-20140924-v3.17-rc6' tag. Here we add the USB PHY device tree support on the R8A7790/Lager reference board. The patchset requires the USB PHY driver already merged by Kishon and Greg in order to work, so can be applied at last... [1/2] ARM: shmobile: r8a7790: add USB PHY DT support [2/2] ARM: shmobile: lager: enable USB PHY Thanks, I have queued these up. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] Add USB PHY device tree support for R8A7791/Koelsch/Henninger board
On Sat, Sep 27, 2014 at 01:05:41AM +0400, Sergei Shtylyov wrote: Hello. Here's the set of 3 patches against Simon Horman's 'renesas.git' repo, 'renesas-devel-20140924-v3.17-rc6' tag. Here we add the USB PHY device tree support on the R8A7791/Koelsch/Henninger boards. The patchset requires the USB PHY driver already merged by Kishon and Greg in order to work, so can be applied at last... [1/3] ARM: shmobile: r8a7791: add USB PHY DT support [2/3] ARM: shmobile: koelsch: enable USB PHY [3/3] ARM: shmobile: henninger: enable USB PHY Thanks, I have queued these up. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] ARM: shmobile: r8a7790: link PCI USB devices to USB PHY
On Mon, Sep 29, 2014 at 10:21:59PM +0400, Sergei Shtylyov wrote:
Describe the PCI USB devices that are behind the PCI bridges, adding necessary
links to the USB PHY device.
Based on the original work by Ben Dooks ben.do...@codethink.co.uk.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Thanks, I have queued this up.
---
This patch is against 'renesas-devel-20140924-v3.17-rc6' tag of Simon Horman's
'renesas.git' repo plus R8A7790/Lager USB PHY support patches posted before.
The patch requires the USB PHY driver and USB HCD generic PHY support (merged
by Kishon and Greg recently) in order to work.
Changes in version 4:
- refreshed the patch.
Changes in version 3:
- adjusted phys properties in the PCI OHCI/EHCI device nodes;
- resolved rejects.
Changes in version 2:
- renamed the PCI OHCI/EHCI device nodes to comply with the PCI binding;
- changed the PHY specifier in the PCI#2 node to reflect that channel #1
support
was dropped;
- resolved rejects, refreshed the patch.
arch/arm/boot/dts/r8a7790.dtsi | 28
1 file changed, 28 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7790.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7790.dtsi
+++ renesas/arch/arm/boot/dts/r8a7790.dtsi
@@ -1107,6 +1107,20 @@
interrupt-map = 0x 0 0 1 gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 gic 0 108 IRQ_TYPE_LEVEL_HIGH;
+
+ usb@0,1 {
+ reg = 0x800 0 0 0 0;
+ device_type = pci;
+ phys = usb0 0;
+ phy-names = usb;
+ };
+
+ usb@0,2 {
+ reg = 0x1000 0 0 0 0;
+ device_type = pci;
+ phys = usb0 0;
+ phy-names = usb;
+ };
};
pci1: pci@ee0b {
@@ -1147,6 +1161,20 @@
interrupt-map = 0x 0 0 1 gic 0 113 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 gic 0 113 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 gic 0 113 IRQ_TYPE_LEVEL_HIGH;
+
+ usb@0,1 {
+ reg = 0x800 0 0 0 0;
+ device_type = pci;
+ phys = usb2 0;
+ phy-names = usb;
+ };
+
+ usb@0,2 {
+ reg = 0x1000 0 0 0 0;
+ device_type = pci;
+ phys = usb2 0;
+ phy-names = usb;
+ };
};
pciec: pcie@fe00 {
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] ARM: shmobile: r8a7791: link PCI USB devices to USB PHY
On Mon, Sep 29, 2014 at 10:23:11PM +0400, Sergei Shtylyov wrote:
Describe the PCI USB devices that are behind the PCI bridges, adding necessary
links to the USB PHY device.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Thanks, I have queued this up.
---
This patch is against 'renesas-devel-20140924-v3.17-rc6' tag of Simon Horman's
'renesas.git' repo plus R8A7791/Koelsch/Henninger USB PHY support patches
posted
before. The patch requires the USB PHY driver and USB HCD generic PHY support
(merged by Kishon and Greg recently) in order to work.
Changes in version 4:
- refreshed the patch.
Changes in version 3:
- adjusted phys properties in the PCI OHCI/EHCI device nodes;
- resolved rejects.
Changes in version 2:
- renamed the PCI OHCI/EHCI device nodes to comply with the PCI binding;
- changed the PHY specifier in the PCI#1 node to reflect that channel #1
support
was dropped;
- resolved rejects.
arch/arm/boot/dts/r8a7791.dtsi | 28
1 file changed, 28 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -1125,6 +1125,20 @@
interrupt-map = 0x 0 0 1 gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 gic 0 108 IRQ_TYPE_LEVEL_HIGH;
+
+ usb@0,1 {
+ reg = 0x800 0 0 0 0;
+ device_type = pci;
+ phys = usb0 0;
+ phy-names = usb;
+ };
+
+ usb@0,2 {
+ reg = 0x1000 0 0 0 0;
+ device_type = pci;
+ phys = usb0 0;
+ phy-names = usb;
+ };
};
pci1: pci@ee0d {
@@ -1145,6 +1159,20 @@
interrupt-map = 0x 0 0 1 gic 0 113 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 gic 0 113 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 gic 0 113 IRQ_TYPE_LEVEL_HIGH;
+
+ usb@0,1 {
+ reg = 0x800 0 0 0 0;
+ device_type = pci;
+ phys = usb2 0;
+ phy-names = usb;
+ };
+
+ usb@0,2 {
+ reg = 0x1000 0 0 0 0;
+ device_type = pci;
+ phys = usb2 0;
+ phy-names = usb;
+ };
};
pciec: pcie@fe00 {
--
To unsubscribe from this list: send the line unsubscribe linux-sh in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
