Re: [PATCH] usb: phy: mv_u3d: Remove usb phy driver for mv_u3d
On Tue, 2014-04-15 at 23:34 -0500, Felipe Balbi wrote: $ make drivers/usb/phy/phy-mv-u3d-usb.o CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CC drivers/usb/phy/phy-mv-u3d-usb.o (On x86_64 this manual make command triggers the error Greg reported in https://lkml.org/lkml/2014/2/11/693 .) yup, builds just fine. Even if the ARCH support isn't in place, this driver is *not* breaking anything, it's not preventing anyone from getting work done and it might be helping Marvell decrease the amount of changes they keep out of tree. I don't see any problems this driver in tree as long as there are people working on it and I see the latest commit was 10 days ago, it wouldn't be fair to Marvell to delete their driver if they're still finding ways to make it useful one way or another. Wouldn't it then be better if this driver is at least hooked into the build system? Like, say, this: config MV_U3D_PHY bool Marvell USB 3.0 PHY controller Driver # XXX should depend on CPU_MMP3 when support for MMP3 lands depends on ARM COMPILE_TEST select USB_PHY help Enable this to support Marvell USB 3.0 phy controller for Marvell SoC. (Or perhaps only ARCH_MMP COMPILE_TEST.) That should give it build coverage by the automated tests people appear to run, while work is done on adding MMP3 support. Thanks, Paul Bolle -- 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: musb: dsps: compile suspend/resume only with PM_SLEEP
From: Wolfram Sang w...@sang-engineering.com
Depending on PM is not enough, because only PM_RUNTIME could be
selected. Fixes:
drivers/usb/musb/musb_dsps.c:703:12: warning: 'dsps_suspend' defined but not
used [-Wunused-function]
drivers/usb/musb/musb_dsps.c:721:12: warning: 'dsps_resume' defined but not
used [-Wunused-function]
Signed-off-by: Wolfram Sang w...@sang-engineering.com
---
drivers/usb/musb/musb_dsps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 3372ded5def7..de6f2fefbc08 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -751,7 +751,7 @@ static const struct of_device_id musb_dsps_of_match[] = {
};
MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int dsps_suspend(struct device *dev)
{
struct dsps_glue *glue = dev_get_drvdata(dev);
--
1.9.1
--
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 v2 2/2] usb: gadget: Add xilinx axi usb2 device support
Hi Felipe,
On Wed, Apr 16, 2014 at 11:32 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Apr 16, 2014 at 04:09:28PM +0530, sundeep subbaraya wrote:
Hi Felipe,
On Thu, Apr 3, 2014 at 8:28 PM, Felipe Balbi ba...@ti.com wrote:
+static int start_dma(struct xusb_ep *ep, u32 src, u32 dst, u32 length)
please prepend this with xudc_, it makes tracing a lot easier.
+{
+ struct xusb_udc *udc;
+ int rc = 0;
+ unsigned long timeout;
+
+ udc = ep-udc;
+ /*
+ * Set the addresses in the DMA source and
+ * destination registers and then set the length
+ * into the DMA length register.
+ */
+ udc-write_fn(udc-base_address, XUSB_DMA_DSAR_ADDR_OFFSET, src);
+ udc-write_fn(udc-base_address, XUSB_DMA_DDAR_ADDR_OFFSET, dst);
+ udc-write_fn(udc-base_address, XUSB_DMA_LENGTH_OFFSET, length);
+
+ /*
+ * Wait till DMA transaction is complete and
+ * check whether the DMA transaction was
+ * successful.
+ */
+ while ((udc-read_fn(ep-udc-base_address +
XUSB_DMA_STATUS_OFFSET)
+ XUSB_DMA_DMASR_BUSY) == XUSB_DMA_DMASR_BUSY) {
+ timeout = jiffies + 1;
+
+ if (time_after(jiffies, timeout)) {
+ rc = -ETIMEDOUT;
+ goto clean;
+ }
+ }
don't you get an IRQ for DMA completion ? If you do, you could be using
wait_for_completion()
This function is called in interrupt context when buffer is ready or
free. It initiates DMA to transfer data from IP buffer to memory.
Hence it waits in busy loop till DMA completes
wait, so you start_dma() before your gadget driver asks you to ?
in ep_queue driver starts dma transfer from/to IP buffer to/from req-buf.
If transfer is completed then request is not added to ep request queue
and returns from ep_queue.
If transfer is not completed (actual length) then request is added
to queue and returns from ep_queue.
when buffer processed interrupt occurs, handler starts dma if there is
request in queue and calls complete call back (when actual == length)
Hence answer is Yes for some transfers (start dma called from
interrupt handler not from ep_queue).
Thanks,
Sundeep.B.S.
--
balbi
--
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 1/1] usb: chipidea: add proper delay for waiting correct PHY status
After the PHY has powered and initialized, it needs some delay
for controller to reflect PHY's status. Some status and values
for id, vbus, dp/dm are only stable after this delay. The current
code tries to clear id/vbus status without enough delay, it
causes the status are not cleared properly.
This patch add 2ms delay after phy has initialized, and clear the
unexpected status after that.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/core.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index ff38cf3..d506f34 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -199,11 +199,10 @@ static void ci_hdrc_enter_lpm(struct ci_hdrc *ci, bool
enable)
hw_write(ci, reg, PORTSC_PHCD(ci-hw_bank.lpm),
0);
/*
-* The controller needs at least 1ms to reflect
-* PHY's status, the PHY also needs some time (less
+* the PHY needs some time (less
* than 1ms) to leave low power mode.
*/
- usleep_range(1500, 2000);
+ usleep_range(1000, 1100);
}
}
@@ -555,12 +554,8 @@ static void ci_get_otg_capable(struct ci_hdrc *ci)
ci-is_otg = (hw_read(ci, CAP_DCCPARAMS,
DCCPARAMS_DC | DCCPARAMS_HC)
== (DCCPARAMS_DC | DCCPARAMS_HC));
- if (ci-is_otg) {
+ if (ci-is_otg)
dev_dbg(ci-dev, It is OTG capable controller\n);
- /* Disable and clear all OTG irq */
- hw_write_otgsc(ci, OTGSC_INT_EN_BITS | OTGSC_INT_STATUS_BITS,
- OTGSC_INT_STATUS_BITS);
- }
}
static int ci_hdrc_probe(struct platform_device *pdev)
@@ -622,6 +617,13 @@ static int ci_hdrc_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, unable to init phy: %d\n, ret);
return ret;
+ } else {
+ /*
+* The delay to sync PHY's status, the maximum delay is
+* 2ms since the otgsc uses 1ms timer to debounce the
+* PHY's input
+*/
+ usleep_range(2000, 2500);
}
ci-hw_bank.phys = res-start;
@@ -656,6 +658,9 @@ static int ci_hdrc_probe(struct platform_device *pdev)
}
if (ci-is_otg) {
+ /* Disable and clear all OTG irq */
+ hw_write_otgsc(ci, OTGSC_INT_EN_BITS | OTGSC_INT_STATUS_BITS,
+ OTGSC_INT_STATUS_BITS);
ret = ci_hdrc_otg_init(ci);
if (ret) {
dev_err(dev, init otg fails, ret = %d\n, ret);
@@ -665,11 +670,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
if (ci-roles[CI_ROLE_HOST] ci-roles[CI_ROLE_GADGET]) {
if (ci-is_otg) {
- /*
-* ID pin needs 1ms debouce time,
-* we delay 2ms for safe.
-*/
- mdelay(2);
ci-role = ci_otg_role(ci);
/* Enable ID change irq */
hw_write_otgsc(ci, OTGSC_IDIE, OTGSC_IDIE);
--
1.7.8
--
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: problem with resume after s2ram
On Wed, 16 Apr 2014, Peter Münster wrote:
On Mon, Apr 14 2014, Alan Stern wrote:
How many diagnostic patches have you tried so far? I've lost track.
Hi Alan,
diag1: the one with the alan-timer
diag2: reverts commit 0aa2832dd0d9d860 and instead, prints
out information showing what the commit would do
diag3: partially reverts e583d9db9960 and prints some information to the
kernel log
If you like, you can also apply the diagnostic patch that adds stuff
to ohci-hcd.
Yes, I've applied diag1 and diag3.
The question is: With this patch present and no devices attached to the
rear ports, do the front ports work with system suspend?
Yes. Please find attached the log.
This is really crazy. It appears to indicate that the OHCI controller
for your bus 6 works okay when both the connected ports are in suspend
or neither of them is, but not when one is and one isn't!
Just to verify, please try replacing diag3 with each of the two patches
below (one at a time). If my guess is right, diag3a will work and
diag3b will fail.
Alan Stern
diag3a
--
Index: peter/drivers/usb/core/hub.c
===
--- peter.orig/drivers/usb/core/hub.c
+++ peter/drivers/usb/core/hub.c
@@ -2966,6 +2966,8 @@ int usb_port_suspend(struct usb_device *
return -ENOMEM;
}
+ dev_info(udev-dev, w-e-d %d\n, wakeup_enabled_descendants(udev));
+
/* see 7.1.7.6 */
if (hub_is_superspeed(hub-hdev))
status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
@@ -2981,7 +2983,7 @@ int usb_port_suspend(struct usb_device *
* Therefore we will turn on the suspend feature if udev or any of its
* descendants is enabled for remote wakeup.
*/
- else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) 0)
+ else if (1)
status = set_port_feature(hub-hdev, port1,
USB_PORT_FEAT_SUSPEND);
else {
diag3b
--
Index: peter/drivers/usb/core/hub.c
===
--- peter.orig/drivers/usb/core/hub.c
+++ peter/drivers/usb/core/hub.c
@@ -2966,6 +2966,8 @@ int usb_port_suspend(struct usb_device *
return -ENOMEM;
}
+ dev_info(udev-dev, w-e-d %d\n, wakeup_enabled_descendants(udev));
+
/* see 7.1.7.6 */
if (hub_is_superspeed(hub-hdev))
status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
--
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 v2 2/2] usb: gadget: Add xilinx axi usb2 device support
Hi,
On Thu, Apr 17, 2014 at 1:38 AM, Paul Zimmerman
paul.zimmer...@synopsys.com wrote:
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of sundeep subbaraya
Sent: Wednesday, April 16, 2014 3:39 AM
Hi Felipe,
On Thu, Apr 3, 2014 at 8:28 PM, Felipe Balbi ba...@ti.com wrote:
+static int start_dma(struct xusb_ep *ep, u32 src, u32 dst, u32 length)
please prepend this with xudc_, it makes tracing a lot easier.
+{
+ struct xusb_udc *udc;
+ int rc = 0;
+ unsigned long timeout;
+
+ udc = ep-udc;
+ /*
+ * Set the addresses in the DMA source and
+ * destination registers and then set the length
+ * into the DMA length register.
+ */
+ udc-write_fn(udc-base_address, XUSB_DMA_DSAR_ADDR_OFFSET, src);
+ udc-write_fn(udc-base_address, XUSB_DMA_DDAR_ADDR_OFFSET, dst);
+ udc-write_fn(udc-base_address, XUSB_DMA_LENGTH_OFFSET, length);
+
+ /*
+ * Wait till DMA transaction is complete and
+ * check whether the DMA transaction was
+ * successful.
+ */
+ while ((udc-read_fn(ep-udc-base_address +
XUSB_DMA_STATUS_OFFSET)
+ XUSB_DMA_DMASR_BUSY) == XUSB_DMA_DMASR_BUSY) {
+ timeout = jiffies + 1;
+
+ if (time_after(jiffies, timeout)) {
+ rc = -ETIMEDOUT;
+ goto clean;
+ }
+ }
don't you get an IRQ for DMA completion ? If you do, you could be using
wait_for_completion()
This function is called in interrupt context when buffer is ready or
free. It initiates
DMA to transfer data from IP buffer to memory. Hence it waits in busy
loop till DMA
completes
If this function is called in interrupt context, then you can't use
jiffies for your timeout, since jiffies may not get updated while in
interrupt context.
Yes. It is obvious that this logic is buggy, will change this.
Thanks,
Sundeep.B.S.
--
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
Re: [PATCH] uvc: update uvc_endpoint_max_bpi to handle USB_SPEED_WIRELESS devices
Hi Thomas, On Wednesday 16 April 2014 12:29:22 Thomas Pugliese wrote: On Wed, 16 Apr 2014, Laurent Pinchart wrote: Hi Thomas, (CC'ing the linux-usb mailing list) On Tuesday 15 April 2014 16:45:28 Thomas Pugliese wrote: On Tue, 15 Apr 2014, Laurent Pinchart wrote: Hi Thomas, Could you please send me a proper revert patch with the above description in the commit message and CC Mauro Carvalho Chehab m.che...@samsung.com ? Hi Laurent, I can submit a patch to revert but I should make a correction first. I had backported this change to an earlier kernel (2.6.39) which was before super speed support was added and the regression I described was based on that kernel. It was actually the addition of super speed support that broke windows compatible devices. My previous change fixed spec compliant devices but left windows compatible devices broken. Basically, the timeline of changes is this: 1. Prior to the addition of super speed support (commit 6fd90db8df379e215): all WUSB devices were treated as HIGH_SPEED devices. This is how Windows works so Windows compatible devices would work. For spec compliant WUSB devices, the max packet size would be incorrectly calculated which would result in high-bandwidth isoc streams being unable to find an alt setting that provided enough bandwidth. 2. After super speed support: all WUSB devices fell through to the default case of uvc_endpoint_max_bpi which would mask off the upper bits of the max packet size. This broke both WUSB spec compliant and non compliant devices because no endpoint with a large enough bpi would be found. 3. After 79af67e77f86404e77e: Spec compliant devices are fixed but non-spec compliant (although Windows compatible) devices are broken. Basically, this is the opposite of how it worked prior to super speed support. Given that, I can submit a patch to revert 79af67e77f86404e77e but that would go back to having all WUSB devices broken. Alternatively, the change below will revert the behavior back to scenario 1 where Windows compatible devices work but strictly spec complaint devices may not. I can send a proper patch for whichever scenario you prefer. Thank you for the explanation. Reverting 79af67e77f86404e77e doesn't seem like a very good idea, given that all WUSB devices will be broken. We thus have two options: - leaving the code as-is, with support for spec-compliant WUSB devices but not for microsoft-specific devices - applying the patch below, with support for microsoft-specific USB devices but not for spec-compliant devices This isn't the first time this kind of situation occurs. Microsoft didn't support multiple configurations before Windows 8, making vendors come up with lots of creative MS-specific solutions. I consider those devices non USB compliant, and they should not be allowed to use the USB logo, but that would require a strong political move from the USB Implementers Forum which is more or less controlled by Microsoft... Welcome to the USB mafia. Anyway, I have no experience with WUSB devices, so I don't know what's more common in the wild. What would you suggest ? I think that almost all current devices support the Windows/USB 2.0 format rather than stricty follow the WUSB spec. Even the prototype device that I initially used to test UVC with Wireless USB has been updated to use the USB 2.0 format prior to shipping in order to remain compatible with Windows. That being said, these devices are not very common at all in the consumer market. They are mostly used in embedded/industrial settings so that may factor in as to which direction you want to go. Would there be a way to support both categories of devices ? As you had mentioned previously, it should be possible to support both formats by ignoring the endpoint descriptor and looking at the bMaxBurst, bOverTheAirInterval and wOverTheAirPacketSize fields in the WUSB endpoint companion descriptor. That is a more involved change to the UVC driver and also would require changes to USB core to store the WUSB endpoint companion descriptor in struct usb_host_endpoint similar to what is done for super speed devices. It's more complex indeed, but I believe it would be worth it. Any volunteer ? ;-) In the meantime I'm fine with a patch that reverts to the previous behaviour. Please include the explanation of the problem in the commit message. -- 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: [PATCH] uvc: update uvc_endpoint_max_bpi to handle USB_SPEED_WIRELESS devices
On Thu, 17 Apr 2014, Laurent Pinchart wrote: Hi Thomas, On Wednesday 16 April 2014 12:29:22 Thomas Pugliese wrote: On Wed, 16 Apr 2014, Laurent Pinchart wrote: Hi Thomas, (CC'ing the linux-usb mailing list) On Tuesday 15 April 2014 16:45:28 Thomas Pugliese wrote: On Tue, 15 Apr 2014, Laurent Pinchart wrote: Hi Thomas, Could you please send me a proper revert patch with the above description in the commit message and CC Mauro Carvalho Chehab m.che...@samsung.com ? Hi Laurent, I can submit a patch to revert but I should make a correction first. I had backported this change to an earlier kernel (2.6.39) which was before super speed support was added and the regression I described was based on that kernel. It was actually the addition of super speed support that broke windows compatible devices. My previous change fixed spec compliant devices but left windows compatible devices broken. Basically, the timeline of changes is this: 1. Prior to the addition of super speed support (commit 6fd90db8df379e215): all WUSB devices were treated as HIGH_SPEED devices. This is how Windows works so Windows compatible devices would work. For spec compliant WUSB devices, the max packet size would be incorrectly calculated which would result in high-bandwidth isoc streams being unable to find an alt setting that provided enough bandwidth. 2. After super speed support: all WUSB devices fell through to the default case of uvc_endpoint_max_bpi which would mask off the upper bits of the max packet size. This broke both WUSB spec compliant and non compliant devices because no endpoint with a large enough bpi would be found. 3. After 79af67e77f86404e77e: Spec compliant devices are fixed but non-spec compliant (although Windows compatible) devices are broken. Basically, this is the opposite of how it worked prior to super speed support. Given that, I can submit a patch to revert 79af67e77f86404e77e but that would go back to having all WUSB devices broken. Alternatively, the change below will revert the behavior back to scenario 1 where Windows compatible devices work but strictly spec complaint devices may not. I can send a proper patch for whichever scenario you prefer. Thank you for the explanation. Reverting 79af67e77f86404e77e doesn't seem like a very good idea, given that all WUSB devices will be broken. We thus have two options: - leaving the code as-is, with support for spec-compliant WUSB devices but not for microsoft-specific devices - applying the patch below, with support for microsoft-specific USB devices but not for spec-compliant devices This isn't the first time this kind of situation occurs. Microsoft didn't support multiple configurations before Windows 8, making vendors come up with lots of creative MS-specific solutions. I consider those devices non USB compliant, and they should not be allowed to use the USB logo, but that would require a strong political move from the USB Implementers Forum which is more or less controlled by Microsoft... Welcome to the USB mafia. Anyway, I have no experience with WUSB devices, so I don't know what's more common in the wild. What would you suggest ? I think that almost all current devices support the Windows/USB 2.0 format rather than stricty follow the WUSB spec. Even the prototype device that I initially used to test UVC with Wireless USB has been updated to use the USB 2.0 format prior to shipping in order to remain compatible with Windows. That being said, these devices are not very common at all in the consumer market. They are mostly used in embedded/industrial settings so that may factor in as to which direction you want to go. Would there be a way to support both categories of devices ? As you had mentioned previously, it should be possible to support both formats by ignoring the endpoint descriptor and looking at the bMaxBurst, bOverTheAirInterval and wOverTheAirPacketSize fields in the WUSB endpoint companion descriptor. That is a more involved change to the UVC driver and also would require changes to USB core to store the WUSB endpoint companion descriptor in struct usb_host_endpoint similar to what is done for super speed devices. It's more complex indeed, but I believe it would be worth it. Any volunteer ? ;-) In the meantime I'm fine with a patch that reverts to the previous behaviour. Please include the explanation of the problem in the commit message. -- Regards, Laurent Pinchart I may make an attempt at the more complete fix once I finish some of the other items in my queue. For clarification, would you like a patch that reverts to the pre-super speed behavior where windows-compatible devices work not but spec
Re: [PATCH v2 2/2] usb: gadget: Add xilinx axi usb2 device support
On Thu, Apr 17, 2014 at 03:01:37PM +0530, sundeep subbaraya wrote:
Hi Felipe,
On Wed, Apr 16, 2014 at 11:32 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Apr 16, 2014 at 04:09:28PM +0530, sundeep subbaraya wrote:
Hi Felipe,
On Thu, Apr 3, 2014 at 8:28 PM, Felipe Balbi ba...@ti.com wrote:
+static int start_dma(struct xusb_ep *ep, u32 src, u32 dst, u32 length)
please prepend this with xudc_, it makes tracing a lot easier.
+{
+ struct xusb_udc *udc;
+ int rc = 0;
+ unsigned long timeout;
+
+ udc = ep-udc;
+ /*
+ * Set the addresses in the DMA source and
+ * destination registers and then set the length
+ * into the DMA length register.
+ */
+ udc-write_fn(udc-base_address, XUSB_DMA_DSAR_ADDR_OFFSET, src);
+ udc-write_fn(udc-base_address, XUSB_DMA_DDAR_ADDR_OFFSET, dst);
+ udc-write_fn(udc-base_address, XUSB_DMA_LENGTH_OFFSET, length);
+
+ /*
+ * Wait till DMA transaction is complete and
+ * check whether the DMA transaction was
+ * successful.
+ */
+ while ((udc-read_fn(ep-udc-base_address +
XUSB_DMA_STATUS_OFFSET)
+ XUSB_DMA_DMASR_BUSY) == XUSB_DMA_DMASR_BUSY) {
+ timeout = jiffies + 1;
+
+ if (time_after(jiffies, timeout)) {
+ rc = -ETIMEDOUT;
+ goto clean;
+ }
+ }
don't you get an IRQ for DMA completion ? If you do, you could be using
wait_for_completion()
This function is called in interrupt context when buffer is ready or
free. It initiates DMA to transfer data from IP buffer to memory.
Hence it waits in busy loop till DMA completes
wait, so you start_dma() before your gadget driver asks you to ?
in ep_queue driver starts dma transfer from/to IP buffer to/from req-buf.
If transfer is completed then request is not added to ep request queue
and returns from ep_queue.
If transfer is not completed (actual length) then request is added
to queue and returns from ep_queue.
This is wrong. Why wouldn't you give gadget driver the chance to decide
if it needs to queue the request again or not ?
when buffer processed interrupt occurs, handler starts dma if there is
request in queue and calls complete call back (when actual == length)
Hence answer is Yes for some transfers (start dma called from
interrupt handler not from ep_queue).
this also seems wrong(-ish).
1) as Paul pointed out, you can't rely on jiffies if you're calling this
with IRQs disabled.
2) you don't really need to wait until DMA finishes its transaction
before returning from start_dma(), just use the DMA completion IRQ,
3) I don't see anywhere any sanitizing of arguments, can your DMA really
handle any alignment/unaligned addresses or should you make sure you're
getting good arguments?
You need to work on this a little bit, I guess.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] usb: gadget: fsl: Set dma_ops for FSL USB Gadget Device
Hi, On Fri, Mar 21, 2014 at 01:56:49AM +0530, Suresh Gupta wrote: From: Suresh Gupta b42...@freescale.com DMA mapping functions are moved to common place in udc_core.c which expect the DMA operation of gadget device Signed-off-by: Suresh Gupta b42...@freescale.com --- Changes from previous version: * Added description drivers/usb/gadget/fsl_udc_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c index d68aa77..35cb972 100644 --- a/drivers/usb/gadget/fsl_udc_core.c +++ b/drivers/usb/gadget/fsl_udc_core.c @@ -2456,6 +2456,7 @@ static int __init fsl_udc_probe(struct platform_device *pdev) /* Setup gadget.dev and register with kernel */ dev_set_name(udc_controller-gadget.dev, gadget); udc_controller-gadget.dev.of_node = pdev-dev.of_node; + set_dma_ops(udc_controller-gadget.dev, pdev-dev.archdata.dma_ops); I'm still not convinced this is the best thing to do in a driver. set_dma_ops() isn't even exposed on include/linux/ and no other driver tries to call it. This is really something that should be done at arch level. Perhaps send a note to lakml and see if anybody has a better idea ? cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: phy: mv_u3d: Remove usb phy driver for mv_u3d
On Thu, Apr 17, 2014 at 09:50:28AM +0200, Paul Bolle wrote: On Tue, 2014-04-15 at 23:34 -0500, Felipe Balbi wrote: $ make drivers/usb/phy/phy-mv-u3d-usb.o CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CC drivers/usb/phy/phy-mv-u3d-usb.o (On x86_64 this manual make command triggers the error Greg reported in https://lkml.org/lkml/2014/2/11/693 .) yup, builds just fine. Even if the ARCH support isn't in place, this driver is *not* breaking anything, it's not preventing anyone from getting work done and it might be helping Marvell decrease the amount of changes they keep out of tree. I don't see any problems this driver in tree as long as there are people working on it and I see the latest commit was 10 days ago, it wouldn't be fair to Marvell to delete their driver if they're still finding ways to make it useful one way or another. Wouldn't it then be better if this driver is at least hooked into the build system? Like, say, this: config MV_U3D_PHY bool Marvell USB 3.0 PHY controller Driver # XXX should depend on CPU_MMP3 when support for MMP3 lands depends on ARM COMPILE_TEST select USB_PHY help Enable this to support Marvell USB 3.0 phy controller for Marvell SoC. (Or perhaps only ARCH_MMP COMPILE_TEST.) That should give it build coverage by the automated tests people appear to run, while work is done on adding MMP3 support. I guess we should make it depend on BROKEN instead, or we just apply the patch below: 8- From 60e524d7db4ed04624850fcb84a844c609a960e3 Mon Sep 17 00:00:00 2001 From: Felipe Balbi ba...@ti.com Date: Thu, 17 Apr 2014 11:24:27 -0500 Subject: [PATCH] usb: phy: mv-u3d: switch over to writel/readl by removing the _relaxed suffix, we can build this driver in other architectures. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/phy/phy-mv-u3d-usb.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/usb/phy/phy-mv-u3d-usb.c b/drivers/usb/phy/phy-mv-u3d-usb.c index d317903..d342175 100644 --- a/drivers/usb/phy/phy-mv-u3d-usb.c +++ b/drivers/usb/phy/phy-mv-u3d-usb.c @@ -39,8 +39,8 @@ static u32 mv_u3d_phy_read(void __iomem *base, u32 reg) addr = base; data = base + 0x4; - writel_relaxed(reg, addr); - return readl_relaxed(data); + writel(reg, addr); + return readl(data); } static void mv_u3d_phy_set(void __iomem *base, u32 reg, u32 value) @@ -51,10 +51,10 @@ static void mv_u3d_phy_set(void __iomem *base, u32 reg, u32 value) addr = base; data = base + 0x4; - writel_relaxed(reg, addr); - tmp = readl_relaxed(data); + writel(reg, addr); + tmp = readl(data); tmp |= value; - writel_relaxed(tmp, data); + writel(tmp, data); } static void mv_u3d_phy_clear(void __iomem *base, u32 reg, u32 value) @@ -65,10 +65,10 @@ static void mv_u3d_phy_clear(void __iomem *base, u32 reg, u32 value) addr = base; data = base + 0x4; - writel_relaxed(reg, addr); - tmp = readl_relaxed(data); + writel(reg, addr); + tmp = readl(data); tmp = ~value; - writel_relaxed(tmp, data); + writel(tmp, data); } static void mv_u3d_phy_write(void __iomem *base, u32 reg, u32 value) @@ -78,8 +78,8 @@ static void mv_u3d_phy_write(void __iomem *base, u32 reg, u32 value) addr = base; data = base + 0x4; - writel_relaxed(reg, addr); - writel_relaxed(value, data); + writel(reg, addr); + writel(value, data); } static void mv_u3d_phy_shutdown(struct usb_phy *phy) -- 1.9.2.459.g68773ac -- balbi signature.asc Description: Digital signature
Re: usb audio breaks ohci-pci
On Tue, 1 Apr 2014, Dennis New wrote:
On Tue, 1 Apr 2014 09:30:01 -0400 (EDT), Alan Stern wrote:
I don't know that much can be done to prevent the controller from
crashing, or to recover from such a crash. Maybe resetting the
controller would work, maybe not.
But at least it should be possible to insure that a controller
malfunction doesn't bring down the entire USB stack with it. I will
work on a patch for this, but I'm going to be quite busy with other
matters for the next few days. It may take some time to get the patch
ready for you to test.
Here's a patch for you to test. Let me know if it doesn't apply
properly to the kernel you're using. I can't tell if it will prevent
all your problems, because it's not clear exactly what's going wrong.
But at least this is a start.
Alan Stern
Index: usb-3.14/drivers/usb/host/ohci.h
===
--- usb-3.14.orig/drivers/usb/host/ohci.h
+++ usb-3.14/drivers/usb/host/ohci.h
@@ -408,6 +408,8 @@ struct ohci_hcd {
// there are also chip quirks/bugs in init logic
struct work_struct nec_work; /* Worker for NEC quirk */
+ struct timer_list sf_watchdog;
+ unsignedsf_tick;
/* Needed for ZF Micro quirk */
struct timer_list unlink_watchdog;
Index: usb-3.14/drivers/usb/host/ohci-hcd.c
===
--- usb-3.14.orig/drivers/usb/host/ohci-hcd.c
+++ usb-3.14/drivers/usb/host/ohci-hcd.c
@@ -76,6 +76,7 @@ static const char hcd_name [] = ohci_hc
#include ohci.h
#include pci-quirks.h
+static void enable_sf_interrupt(struct ohci_hcd *ohci);
static void ohci_dump (struct ohci_hcd *ohci, int verbose);
static void ohci_stop (struct usb_hcd *hcd);
@@ -416,6 +417,49 @@ static int check_ed(struct ohci_hcd *ohc
!list_empty(ed-td_list);
}
+/*
+ * Sometimes OHCI controllers fail to issue Start-of-Frame interrupts.
+ * There are two main reasons for this to happen: the controller crashes
+ * without a UE interrupt, or the controller turns off its frame counter
+ * (some versions do this when no ports are connected).
+ *
+ * Without SF interrupts, the ed_rm_list will never be emptied, which means
+ * unlinked URBs will never complete. Hence the need for this watchdog
+ * routine.
+ */
+static void sf_watchdog_func(unsigned long _ohci)
+{
+ unsigned long flags;
+ struct ohci_hcd *ohci = (struct ohci_hcd *) _ohci;
+
+ ohci_err(ohci, OHCI SF watchdog triggered\n);
+ if (ohci-sf_tick == ohci_frame_no(ohci))
+ ohci_err(ohci, Frame counter has stopped at %u\n,
+ ohci-sf_tick);
+ spin_lock_irqsave(ohci-lock, flags);
+ finish_unlinks(ohci, ohci-sf_tick + 20);
+
+ if ((ohci-ed_rm_list || ohci-ed_to_check)
+ ohci-rh_state == OHCI_RH_RUNNING)
+ enable_sf_interrupt(ohci);
+ else
+ ohci_writel(ohci, OHCI_INTR_SF, ohci-regs-intrdisable);
+ spin_unlock_irqrestore(ohci-lock, flags);
+}
+
+static void enable_sf_interrupt(struct ohci_hcd *ohci)
+{
+
+ ohci_writel(ohci, OHCI_INTR_SF, ohci-regs-intrstatus);
+ ohci_writel(ohci, OHCI_INTR_SF, ohci-regs-intrenable);
+
+ /* flush those writes */
+ (void) ohci_readl(ohci, ohci-regs-control);
+
+ ohci-sf_tick = ohci_frame_no(ohci);
+ mod_timer(ohci-sf_watchdog, jiffies + 1 + msecs_to_jiffies(20));
+}
+
/* ZF Micro watchdog timer callback. The ZF Micro chipset sometimes completes
* an interrupt TD but neglects to add it to the donelist. On systems with
* this chipset, we need to periodically check the state of the queues to look
@@ -476,14 +520,7 @@ static void unlink_watchdog_func(unsigne
* those could defer the IRQ more than one frame, using
* DI...) Check again after the next INTR_SF.
*/
- ohci_writel(ohci, OHCI_INTR_SF,
- ohci-regs-intrstatus);
- ohci_writel(ohci, OHCI_INTR_SF,
- ohci-regs-intrenable);
-
- /* flush those writes */
- (void) ohci_readl(ohci, ohci-regs-control);
-
+ enable_sf_interrupt(ohci);
goto out;
}
}
@@ -506,6 +543,9 @@ static int ohci_init (struct ohci_hcd *o
int ret;
struct usb_hcd *hcd = ohci_to_hcd(ohci);
+ setup_timer(ohci-sf_watchdog, sf_watchdog_func,
+ (unsigned long) ohci);
+
if (distrust_firmware)
ohci-flags |= OHCI_QUIRK_HUB_POWER;
@@ -825,6 +865,7 @@ static irqreturn_t ohci_irq (struct usb_
usb_hc_died(hcd);
}
+ del_timer(ohci-sf_watchdog);
RE: [PATCH v6 0/3] usb: dwc2/s3c-hsotg: move s3c-hsotg driver into dwc2
From: Paul Zimmerman Sent: Monday, April 14, 2014 2:14 PM From: Dinh Nguyen dingu...@altera.com This is a shortened version of the patch to combine the dwc2/s3c-hsotg into a single dual-role driver. The series will only move the s3c-hsotg driver into the dwc2 folder, use the defines in the dwc2 hw.h, and removes the s3c-hsotg.h defines. This will make the dual-role combining work a bit easier to review in the future. For now, the dwc2 and s3c-hsotg will be separate drivers. --- Hi Greg, This is Dinh's series for moving the s3c-hsotg driver into the dwc2 directory. The gadget part has been tested by Jingoo and Robert at Samsung, and I have tested the host part on the Synopsys development board (but not on the Raspberry Pi). I would like to have Stephen Warren test this on the Pi, and have Felipe ack the first two patches, then I think it should be good to go. Hi Greg, I haven't heard back from Stephen about testing on the Raspberry Pi. So today I managed to fix my broken Pi and do some quick testing on it, and I didn't see any problems. And, Felipe gave his (qualified) Ack. So, can you please go ahead and merge these patches to usb-next? Thanks. -- 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
usb ports shuts down after kernel loads
Hi, I'm experiencing problem with USB ports - they shuts down after kernel loads - and I've found partial solution - few times switching auto/on on power control of xHCI controller. I want to figure out what is wrong with that and where I can change something to resolve this properly. Where I can see some messages from USB drivers, or turn on more verbose log mode for kernel so I can see what happens just before ports start working? Below are more details. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=74071 Symptoms: USB ports stop working (power off) just after boot loader loads kernel. They don't turn on even after 10 minuts after boot. Undeterminable count of switching value of xHCI controlller power/control in /sys to on and auto and back again and waiting few seconds turns USB ports ON until reboot. Observations: - Is not HW problem (Windows works, before boot (in BIOS) works as well) - With acpi=off USB ports do not shuts down. - With usbcore.autosuspend=-1 nothing changes. - Is not distro specific (same behavior in OpenSUSE, Ubuntu, Debian, different versions - tried with USB live stick) - Is not BIOS/EFI specific, neither arch i686/amd64 - each combination behaves the same - No specific message in dmesg about error with USB - After switching /sys/bus/pci/devices/_xHCI controller address_/power/control to auto, power on USB starts turning on and off (cca in 0.25s intervals). After undetermined count of switches from auto to on and back and waiting up to 10 seconds in every auto state, power stabilizes and driver recognizes connected devices (not before even for short on power states). HW: Lenovo ThinkPad Twist 3347-26G, BIOS v1.65, Core i5-3317U Ivy Bridge (2x USB3.0 ports, ps2 laptop trackpoing, internal USB webcam, synaptic touchpad, keyboard) USB devices - msi usb2.0 hub - rapoo keyboard, zelman optical mouse (same even for directly connected - no problem in HW) Running OS: Ubuntu 14.04, UEFI boot (for testing) Thank you very much Lukas Dolezal -- 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: problem with resume after s2ram
On Thu, Apr 17 2014, Alan Stern wrote: Just to verify, please try replacing diag3 with each of the two patches below (one at a time). If my guess is right, diag3a will work and diag3b will fail. Yes, you're right! -- Peter -- 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] uvc: update uvc_endpoint_max_bpi to handle USB_SPEED_WIRELESS devices
Hi Thomas, On Thursday 17 April 2014 09:53:32 Thomas Pugliese wrote: On Thu, 17 Apr 2014, Laurent Pinchart wrote: On Wednesday 16 April 2014 12:29:22 Thomas Pugliese wrote: [snip] As you had mentioned previously, it should be possible to support both formats by ignoring the endpoint descriptor and looking at the bMaxBurst, bOverTheAirInterval and wOverTheAirPacketSize fields in the WUSB endpoint companion descriptor. That is a more involved change to the UVC driver and also would require changes to USB core to store the WUSB endpoint companion descriptor in struct usb_host_endpoint similar to what is done for super speed devices. It's more complex indeed, but I believe it would be worth it. Any volunteer ? ;-) In the meantime I'm fine with a patch that reverts to the previous behaviour. Please include the explanation of the problem in the commit message. I may make an attempt at the more complete fix once I finish some of the other items in my queue. For clarification, would you like a patch that reverts to the pre-super speed behavior where windows-compatible devices work not but spec compliant devices will not (i.e. treat USB_SPEED_HIGH and USB_SPEED_WIRELESS the same)? I'll trust your judgment on that, if you believe it would be better from a user point of view, please send a patch. Otherwise we can wait until you find time to work on a proper fix. -- 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
Good News
An ATM CARD worth $850,000.00 has been credited to you by United Nations.Reply for more info -- 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 0/3] usb: dwc2/s3c-hsotg: move s3c-hsotg driver into dwc2
On Thu, Apr 17, 2014 at 08:38:11PM +, Paul Zimmerman wrote: From: Paul Zimmerman Sent: Monday, April 14, 2014 2:14 PM From: Dinh Nguyen dingu...@altera.com This is a shortened version of the patch to combine the dwc2/s3c-hsotg into a single dual-role driver. The series will only move the s3c-hsotg driver into the dwc2 folder, use the defines in the dwc2 hw.h, and removes the s3c-hsotg.h defines. This will make the dual-role combining work a bit easier to review in the future. For now, the dwc2 and s3c-hsotg will be separate drivers. --- Hi Greg, This is Dinh's series for moving the s3c-hsotg driver into the dwc2 directory. The gadget part has been tested by Jingoo and Robert at Samsung, and I have tested the host part on the Synopsys development board (but not on the Raspberry Pi). I would like to have Stephen Warren test this on the Pi, and have Felipe ack the first two patches, then I think it should be good to go. Hi Greg, I haven't heard back from Stephen about testing on the Raspberry Pi. So today I managed to fix my broken Pi and do some quick testing on it, and I didn't see any problems. And, Felipe gave his (qualified) Ack. So, can you please go ahead and merge these patches to usb-next? Thanks. Ok, I'll queue them up when I get to the usb patches for 3.16 (still sifting through for 3.15 patches at the moment...) This should happen later next week, 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
