[PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
Disable the MUSB interrupts till MUSB is recovered fully from BABBLE
condition. There are chances that we could get multiple interrupts
till the time the babble recover work gets scheduled. Sometimes
this could even end up in an endless loop making MUSB itself unusable.
Reported-by: Felipe Balbi ba...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3345c94..992c768 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -423,6 +423,7 @@ void musb_hnp_stop(struct musb *musb)
musb-port1_status = ~(USB_PORT_STAT_C_CONNECTION 16);
}
+static void musb_generic_disable(struct musb *musb);
/*
* Interrupt Service Routine to record USB global interrupts.
* Since these do not happen often and signify things of
@@ -846,9 +847,11 @@ b_host:
}
/* handle babble condition */
- if (int_usb MUSB_INTR_BABBLE is_host_active(musb))
+ if (int_usb MUSB_INTR_BABBLE is_host_active(musb)) {
+ musb_generic_disable(musb);
schedule_delayed_work(musb-recover_work,
msecs_to_jiffies(100));
+ }
#if 0
/* REVISIT ... this would be for multiplexing periodic endpoints, or
--
1.8.3.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: [RFC/PATCH v2] usb: host: xhci: issue 'Reset Endpoint' for !CONTROL EPs from finish_td()
On 13.11.2014 20:46, Felipe Balbi wrote: On Thu, Nov 13, 2014 at 12:31:28PM -0600, Felipe Balbi wrote: Hi, (your mailing is un-wrapping emails, I always end up with pretty long lines and have to rewrap them) On Thu, Nov 13, 2014 at 07:58:28PM +0200, Mathias Nyman wrote: The algorithm described in the DVB tuner bug is clearly wrong, since it doesn't move the dequeue pointer until usb_clear_halt() is called, which is far too late. The right approach is to fix up the dequeue pointer before giving back the URB (so there's no need to save a stopped TD value). Otherwise there will be TDs in the endpoint ring containing stale DMA pointers to buffers that have already been unmapped. Thats right, I cleaned up the patch and removed resetting the endpoint from the .endpoint_reset() callback which was called as a result of usb_clear_halt(). Now we queue a reset endpoint and set dequeue pointer before giving back the URB. I still set a stopped td value, but could as well just pass it as function parameter. Actually I'll do that in later cleanup patch. Latest version of the patch is now in my tree in a reset-rework-v2 branch, with fixes comments and removed The brach includes the other dorbell ringing patch as well. both are on top of 3.18-rc4. I still need to test it before sending it further, the tree is here: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git reset-rework-v2 I'll test this one. for both commits on that branch, you can add my: Tested-by: Felipe Balbi ba...@ti.com But please also add proper fixes and Cc: stable, so older kernels can use those. Thanks a lot for testing again. I'll CC stable and add your tested-by, but I still don't know exactly which commit it Fixes. This might have been there since the early days of xhci. -Mathias -- 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 1/3] usb: chipidea: add controller reset API
On Thu, Nov 13, 2014 at 09:55:34PM -0600, Felipe Balbi wrote:
Hi,
On Fri, Nov 14, 2014 at 08:03:15AM +0800, Peter Chen wrote:
Add controller reset API, it may be used for host/otg driver in future.
you need a better commit log here. How would it be used ? when ? And,
more importantly, why ?
I will add more information
Why would we need to reset the IP outside of -probe() ?
I don't oppose to the refactoring, but why would we ever need to reset
this IP ?
Usually, we need to below reset controller at below situations:
- Role switch, host-device and device-host
- Return from hibernation, which the controller will lost its power,
and the content of the register are lost.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
Changes for v2:
- Add return value check for controller reset at hw_device_reset
drivers/usb/chipidea/core.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index bd74f27..dffd89b 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -385,6 +385,26 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
}
/**
+ * hw_controller_reset: do controller reset
+ * @ci: the controller
+ *
minor nit: indentation
Will change
+ * This function returns an error code
+ */
+static int hw_controller_reset(struct ci_hdrc *ci)
+{
+ int count = 0;
+
+ hw_write(ci, OP_USBCMD, USBCMD_RST, USBCMD_RST);
+ while (hw_read(ci, OP_USBCMD, USBCMD_RST)) {
+ udelay(10);
+ if (count++ 1000)
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+/**
* hw_device_reset: resets chip (execute without interruption)
* @ci: the controller
*
@@ -392,13 +412,17 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
*/
int hw_device_reset(struct ci_hdrc *ci, u32 mode)
{
+ int ret;
+
/* should flush stop before reset */
hw_write(ci, OP_ENDPTFLUSH, ~0, ~0);
hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
- hw_write(ci, OP_USBCMD, USBCMD_RST, USBCMD_RST);
- while (hw_read(ci, OP_USBCMD, USBCMD_RST))
- udelay(10); /* not RTOS friendly */
+ ret = hw_controller_reset(ci);
+ if (ret) {
+ dev_err(ci-dev, error for reset, ret=%d\n, ret);
+ return ret;
+ }
if (ci-platdata-notify_event)
ci-platdata-notify_event(ci,
--
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
--
balbi
--
Best Regards,
Peter Chen
--
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: musb: core: Disable the Interrupts till BABBLE is fully handled
On 11/14/2014 09:24 AM, George Cherian wrote: Disable the MUSB interrupts till MUSB is recovered fully from BABBLE condition. There are chances that we could get multiple interrupts till the time the babble recover work gets scheduled. Sometimes this could even end up in an endless loop making MUSB itself unusable. How do you trigger the babble error? Is this something that happens during suspend resume, plugging / unplugging a device or randomly while the device is used? Sebastian -- 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/3] usb: chipidea: parameter 'mode' isn't needed for hw_device_reset
On Thu, Nov 13, 2014 at 09:56:58PM -0600, Felipe Balbi wrote:
On Fri, Nov 14, 2014 at 08:03:16AM +0800, Peter Chen wrote:
The hw_device_reset is dedicated to be used at device mode initializaiton,
so delete the parameter 'mode'. For host driver, the ehci driver will
all things.
this last sentence doesn't parse very well.
Thanks, will add.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/ci.h | 2 +-
drivers/usb/chipidea/core.c| 8
drivers/usb/chipidea/otg_fsm.c | 2 +-
drivers/usb/chipidea/udc.c | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 5bbfcc7..65913d4 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -352,7 +352,7 @@ u32 hw_read_intr_enable(struct ci_hdrc *ci);
u32 hw_read_intr_status(struct ci_hdrc *ci);
-int hw_device_reset(struct ci_hdrc *ci, u32 mode);
+int hw_device_reset(struct ci_hdrc *ci);
int hw_port_test_set(struct ci_hdrc *ci, u8 mode);
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index dffd89b..053ab4f 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -410,7 +410,7 @@ static int hw_controller_reset(struct ci_hdrc *ci)
*
* This function returns an error code
*/
-int hw_device_reset(struct ci_hdrc *ci, u32 mode)
+int hw_device_reset(struct ci_hdrc *ci)
{
int ret;
@@ -440,12 +440,12 @@ int hw_device_reset(struct ci_hdrc *ci, u32 mode)
/* USBMODE should be configured step by step */
hw_write(ci, OP_USBMODE, USBMODE_CM, USBMODE_CM_IDLE);
- hw_write(ci, OP_USBMODE, USBMODE_CM, mode);
+ hw_write(ci, OP_USBMODE, USBMODE_CM, USBMODE_CM_DC);
/* HW = 2.3 */
hw_write(ci, OP_USBMODE, USBMODE_SLOM, USBMODE_SLOM);
- if (hw_read(ci, OP_USBMODE, USBMODE_CM) != mode) {
- pr_err(cannot enter in %s mode, ci_role(ci)-name);
+ if (hw_read(ci, OP_USBMODE, USBMODE_CM) != USBMODE_CM_DC) {
+ pr_err(cannot enter in %s device mode, ci_role(ci)-name);
pr_err(lpm = %i, ci-hw_bank.lpm);
return -ENODEV;
}
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 21058ae..e8c936d 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -543,7 +543,7 @@ static int ci_otg_start_host(struct otg_fsm *fsm, int
on)
ci_role_start(ci, CI_ROLE_HOST);
} else {
ci_role_stop(ci);
- hw_device_reset(ci, USBMODE_CM_DC);
+ hw_device_reset(ci);
ci_role_start(ci, CI_ROLE_GADGET);
}
mutex_lock(fsm-lock);
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index bdaa7ba..4fe18ce 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1471,7 +1471,7 @@ static int ci_udc_vbus_session(struct usb_gadget
*_gadget, int is_active)
if (gadget_ready) {
if (is_active) {
pm_runtime_get_sync(_gadget-dev);
- hw_device_reset(ci, USBMODE_CM_DC);
+ hw_device_reset(ci);
hw_device_state(ci, ci-ep0out-qh.dma);
usb_gadget_set_state(_gadget, USB_STATE_POWERED);
} else {
@@ -1660,7 +1660,7 @@ static int ci_udc_start(struct usb_gadget *gadget,
pm_runtime_get_sync(ci-gadget.dev);
if (ci-vbus_active) {
spin_lock_irqsave(ci-lock, flags);
- hw_device_reset(ci, USBMODE_CM_DC);
+ hw_device_reset(ci);
wow, you guys reset this IP all the time... that's scary, could be
hiding bugs easily.
In current chipidea design, it indeed resets controller often, it
resets controller when the usb cable connects to pc and the gadget
driver is there, something like which we do for RUN/STOP bit.
--
Best Regards,
Peter Chen
--
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] Rework xhci: clear root port wake on bits if controller isn't wake-up capable
On 14.11.2014 05:14, Lu, Baolu wrote: Hi Mathias, This patch series has been acked by Alan Stern. There seems no further comments from others. Can you please pull in it? Thanks, -baolu Ah, yes, thanks for reminding, I'll pull them in and send them forward. -Mathias -- 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 3/3] USB: host: Introduce flag to enable use of 64-bit dma_mask for ehci-platform
On Thu, Nov 13, 2014 at 08:44:17PM -0800, Florian Fainelli wrote:
2014-11-13 13:36 GMT-08:00 Andreas Herrmann
andreas.herrm...@caviumnetworks.com:
ehci-octeon driver used a 64-bit dma_mask. With removal of ehci-octeon
and usage of ehci-platform ehci dma_mask is now limited to 32 bits
(coerced in ehci_platform_probe).
Provide a flag in ehci platform data to allow use of 64 bits for
dma_mask.
Why not just allow enforcing an arbitrary DMA mask?
I thought about that but as it's currently just 32 or 64 bits
a flag is sufficient. (At the moment I am not aware that
other ehci-platform devices would require something else.)
I'll change the flag to a mask if desired.
Alan, what's your opinion about this?
Andreas
Cc: David Daney david.da...@cavium.com
Cc: Alex Smith alex.sm...@imgtec.com
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Andreas Herrmann andreas.herrm...@caviumnetworks.com
---
arch/mips/cavium-octeon/octeon-platform.c |4 +---
drivers/usb/host/ehci-platform.c |3 ++-
include/linux/usb/ehci_pdriver.h |1 +
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/mips/cavium-octeon/octeon-platform.c
b/arch/mips/cavium-octeon/octeon-platform.c
index eea60b6..12410a2 100644
--- a/arch/mips/cavium-octeon/octeon-platform.c
+++ b/arch/mips/cavium-octeon/octeon-platform.c
@@ -310,6 +310,7 @@ static struct usb_ehci_pdata octeon_ehci_pdata = {
#ifdef __BIG_ENDIAN
.big_endian_mmio= 1,
#endif
+ .dma_mask_64= 1,
.power_on = octeon_ehci_power_on,
.power_off = octeon_ehci_power_off,
};
@@ -331,8 +332,6 @@ static void __init octeon_ehci_hw_start(struct device
*dev)
octeon2_usb_clocks_stop();
}
-static u64 octeon_ehci_dma_mask = DMA_BIT_MASK(64);
-
static int __init octeon_ehci_device_init(void)
{
struct platform_device *pd;
@@ -347,7 +346,6 @@ static int __init octeon_ehci_device_init(void)
if (!pd)
return 0;
- pd-dev.dma_mask = octeon_ehci_dma_mask;
pd-dev.platform_data = octeon_ehci_pdata;
octeon_ehci_hw_start(pd-dev);
diff --git a/drivers/usb/host/ehci-platform.c
b/drivers/usb/host/ehci-platform.c
index 2da18ea..6df808b 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -155,7 +155,8 @@ static int ehci_platform_probe(struct platform_device
*dev)
if (!pdata)
pdata = ehci_platform_defaults;
- err = dma_coerce_mask_and_coherent(dev-dev, DMA_BIT_MASK(32));
+ err = dma_coerce_mask_and_coherent(dev-dev,
+ pdata-dma_mask_64 ? DMA_BIT_MASK(64) : DMA_BIT_MASK(32));
if (err)
return err;
diff --git a/include/linux/usb/ehci_pdriver.h
b/include/linux/usb/ehci_pdriver.h
index 7eb4dcd..f69529e 100644
--- a/include/linux/usb/ehci_pdriver.h
+++ b/include/linux/usb/ehci_pdriver.h
@@ -45,6 +45,7 @@ struct usb_ehci_pdata {
unsignedbig_endian_desc:1;
unsignedbig_endian_mmio:1;
unsignedno_io_watchdog:1;
+ unsigneddma_mask_64:1;
/* Turn on all power and clocks */
int (*power_on)(struct platform_device *pdev);
--
1.7.9.5
--
Florian
--
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 v1] chipidea: issue message when some calls fail in -probe()
On Thu, Nov 13, 2014 at 05:59:47PM +0200, Andy Shevchenko wrote:
There is no message when PHY is not enabled, IRQ line can't be acquired, or
debugfs registration fails. This patch adds the messages.
But you get the error return value from probe, it indicates the probe has
failed, usually, we don't add more error information at probe.
Peter
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/usb/chipidea/core.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index c57448a..ffd2457 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -659,8 +659,10 @@ static int ci_hdrc_probe(struct platform_device *pdev)
/* if both generic PHY and USB PHY layers aren't enabled */
if (PTR_ERR(ci-phy) == -ENOSYS
- PTR_ERR(ci-usb_phy) == -ENXIO)
+ PTR_ERR(ci-usb_phy) == -ENXIO) {
+ dev_err(dev, PHY and USB PHY layers aren't enabled\n);
return -ENXIO;
+ }
if (IS_ERR(ci-phy) IS_ERR(ci-usb_phy))
return -EPROBE_DEFER;
@@ -761,16 +763,22 @@ 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);
- if (ret)
+ if (ret) {
+ dev_err(dev, can't acquire IRQ line %d\n, ci-irq);
goto stop;
+ }
if (ci_otg_is_fsm_mode(ci))
ci_hdrc_otg_fsm_start(ci);
ret = dbg_create_files(ci);
- if (!ret)
- return 0;
+ if (ret) {
+ dev_err(dev, can't register debugfs files\n);
+ goto release_irq;
+ }
+ return 0;
+release_irq:
free_irq(ci-irq, ci);
stop:
ci_role_destroy(ci);
--
2.1.3
--
Best Regards,
Peter Chen
--
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] HID: usbhid: get/put around clearing needs_remote_wakeup
On Thu, 2014-11-13 at 12:16 -0800, Benson Leung wrote: In usbhid_open, usb_autopm_get_interface is called before setting the needs_remote_wakeup flag, and usb_autopm_put_interface is called after hid_start_in. However, when the device is closed in usbhid_close, the same protection isn't there when clearing needs_remote_wakeup. This will add that to usbhid_close as well as usbhid_stop. Interesting, but this has the side effect of waking devices that are asleep just to remove the flag. Regards Oliver -- Oliver Neukum oneu...@suse.de -- 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: musb: core: Disable the Interrupts till BABBLE is fully handled
On 11/14/2014 02:12 PM, Sebastian Andrzej Siewior wrote: On 11/14/2014 09:24 AM, George Cherian wrote: Disable the MUSB interrupts till MUSB is recovered fully from BABBLE condition. There are chances that we could get multiple interrupts till the time the babble recover work gets scheduled. Sometimes this could even end up in an endless loop making MUSB itself unusable. How do you trigger the babble error? Is this something that happens during suspend resume, plugging / unplugging a device or randomly while the device is used? I have never seen this error while device is successfully enumerated and while working fine. Mostly u get it when we connect/disconnect devices to HOST port. Normally I use the following for testing BABBLE - Especially when a fully loaded USB HUB getting connected to HOST port. - Or repeatedly load and unload musb_hdrc.ko with some device connected. If nothing of the above work you might be the lucky one to have a good board Sebastian -- 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 1/2] usb: dwc2/gadget: add mutex to serialize init/deinit calls
Hello,
On 2014-11-13 21:55, Paul Zimmerman wrote:
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Thursday, November 13, 2014 7:18 AM
On 2014-10-31 19:46, Paul Zimmerman wrote:
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Friday, October 31, 2014 3:13 AM
This patch adds mutex, which protects initialization and
deinitialization procedures against suspend/resume methods.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 20
2 files changed, 21 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9f77b4d1c5ff..58732a9a0019 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -187,6 +187,7 @@ struct s3c_hsotg {
struct s3c_hsotg_plat*plat;
spinlock_t lock;
+ struct mutexinit_mutex;
void __iomem*regs;
int irq;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index d8dda39c9e16..a2e4272a904e 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -21,6 +21,7 @@
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/debugfs.h
+#include linux/mutex.h
#include linux/seq_file.h
#include linux/delay.h
#include linux/io.h
@@ -2908,6 +2909,7 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget,
return -EINVAL;
}
+ mutex_lock(hsotg-init_mutex);
WARN_ON(hsotg-driver);
driver-driver.bus = NULL;
@@ -2933,9 +2935,12 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget,
dev_info(hsotg-dev, bound driver %s\n, driver-driver.name);
+ mutex_unlock(hsotg-init_mutex);
+
return 0;
err:
+ mutex_unlock(hsotg-init_mutex);
hsotg-driver = NULL;
return ret;
}
@@ -2957,6 +2962,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
if (!hsotg)
return -ENODEV;
+ mutex_lock(hsotg-init_mutex);
+
/* all endpoints should be shutdown */
for (ep = 1; ep hsotg-num_of_eps; ep++)
s3c_hsotg_ep_disable(hsotg-eps[ep].ep);
@@ -2974,6 +2981,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
clk_disable(hsotg-clk);
+ mutex_unlock(hsotg-init_mutex);
+
return 0;
}
@@ -3002,6 +3011,7 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
dev_dbg(hsotg-dev, %s: is_on: %d\n, __func__, is_on);
+ mutex_lock(hsotg-init_mutex);
spin_lock_irqsave(hsotg-lock, flags);
if (is_on) {
clk_enable(hsotg-clk);
@@ -3013,6 +3023,7 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
hsotg-gadget.speed = USB_SPEED_UNKNOWN;
spin_unlock_irqrestore(hsotg-lock, flags);
+ mutex_unlock(hsotg-init_mutex);
return 0;
}
@@ -3507,6 +3518,7 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
}
spin_lock_init(hsotg-lock);
+ mutex_init(hsotg-init_mutex);
hsotg-irq = ret;
@@ -3652,6 +3664,8 @@ static int s3c_hsotg_suspend(struct platform_device
*pdev, pm_message_t
state)
unsigned long flags;
int ret = 0;
+ mutex_lock(hsotg-init_mutex);
+
if (hsotg-driver)
dev_info(hsotg-dev, suspending usb gadget %s\n,
hsotg-driver-driver.name);
@@ -3674,6 +3688,8 @@ static int s3c_hsotg_suspend(struct platform_device
*pdev, pm_message_t
state)
clk_disable(hsotg-clk);
}
+ mutex_unlock(hsotg-init_mutex);
+
return ret;
}
@@ -3683,7 +3699,9 @@ static int s3c_hsotg_resume(struct platform_device *pdev)
unsigned long flags;
int ret = 0;
+ mutex_lock(hsotg-init_mutex);
if (hsotg-driver) {
+
dev_info(hsotg-dev, resuming usb gadget %s\n,
hsotg-driver-driver.name);
@@ -3699,6 +3717,8 @@ static int s3c_hsotg_resume(struct platform_device *pdev)
s3c_hsotg_core_connect(hsotg);
spin_unlock_irqrestore(hsotg-lock, flags);
+ mutex_unlock(hsotg-init_mutex);
+
return ret;
}
Hmm. I can't find any other UDC driver that uses a mutex in its
suspend/resume functions. Can you explain why this is needed only
for dwc2?
I've posted this version because I thought you were not convinced that
the patch
usb: dwc2/gadget: rework suspend/resume code to correctly restore
gadget state
can add code for initialization and deinitialization in suspend/resume
paths.
My problem with that patch was that you were checking the -enabled
flag outside of the spinlock. To address that, you only need to move
the check inside of the spinlock. I don't see why a mutex is needed.
It is not that simple. I can add spin_lock() before checking enabled,
but then
I would need to spin_unlock() to call
Re: [PATCH 1/3] USB: host: Remove ehci-octeon and ohci-octeon drivers
On Thu, Nov 13, 2014 at 10:36:28PM +0100, Andreas Herrmann wrote: From: Alan Stern st...@rowland.harvard.edu From: Alan Stern st...@rowland.harvard.edu Is there an echo? Is there an echo? Remove special-purpose octeon drivers and instead use ehci-platform and ohci-platform as suggested with http://marc.info/?l=linux-mipsm=140139694721623w=2 [andreas.herrmann: fixed compile error] Cc: David Daney david.da...@cavium.com Cc: Alex Smith alex.sm...@imgtec.com Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Andreas Herrmann andreas.herrm...@caviumnetworks.com --- arch/mips/cavium-octeon/octeon-platform.c | 274 - arch/mips/configs/cavium_octeon_defconfig |3 + drivers/usb/host/Kconfig | 18 +- drivers/usb/host/Makefile |1 - drivers/usb/host/ehci-hcd.c |5 - drivers/usb/host/ehci-octeon.c| 188 drivers/usb/host/octeon2-common.c | 200 - drivers/usb/host/ohci-hcd.c |5 - drivers/usb/host/ohci-octeon.c| 202 - 9 files changed, 285 insertions(+), 611 deletions(-) delete mode 100644 drivers/usb/host/ehci-octeon.c delete mode 100644 drivers/usb/host/octeon2-common.c delete mode 100644 drivers/usb/host/ohci-octeon.c For the MIPS bits: For the MIPS bits: Acked-by: Ralf Baechle r...@linux-mips.org Acked-by: Ralf Baechle r...@linux-mips.org Ralf Ralf -- 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/3] USB: host: Remove hard-coded octeon platform information for ehci/ohci
On Thu, Nov 13, 2014 at 10:36:29PM +0100, Andreas Herrmann wrote: Instead rely on device tree information for ehci and ohci. This was suggested with http://www.linux-mips.org/archives/linux-mips/2014-05/msg00307.html The device tree will *always* have correct ehci/ohci clock configuration, so use it. This allows us to remove a big chunk of platform configuration code from octeon-platform.c. More or less I rebased that patch on Alan's work to remove ehci-octeon and ohci-octeon drivers. Cc: David Daney david.da...@cavium.com Cc: Alex Smith alex.sm...@imgtec.com Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Andreas Herrmann andreas.herrm...@caviumnetworks.com For the MIPS bits: Acked-by: Ralf Baechle r...@linux-mips.org Ralf -- 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 v1] chipidea: issue message when some calls fail in -probe()
On Fri, 2014-11-14 at 15:58 +0800, Peter Chen wrote:
On Thu, Nov 13, 2014 at 05:59:47PM +0200, Andy Shevchenko wrote:
There is no message when PHY is not enabled, IRQ line can't be acquired, or
debugfs registration fails. This patch adds the messages.
But you get the error return value from probe, it indicates the probe has
failed, usually, we don't add more error information at probe.
I spend more than hour to understand what is happening in my case. I
compiled in the module and didn't get why probe failed.
With this patch applied I would have understood this like in couple of
minutes.
I think it is very useful to save time of debugging.
Peter
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/usb/chipidea/core.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index c57448a..ffd2457 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -659,8 +659,10 @@ static int ci_hdrc_probe(struct platform_device *pdev)
/* if both generic PHY and USB PHY layers aren't enabled */
if (PTR_ERR(ci-phy) == -ENOSYS
- PTR_ERR(ci-usb_phy) == -ENXIO)
+ PTR_ERR(ci-usb_phy) == -ENXIO) {
+ dev_err(dev, PHY and USB PHY layers aren't enabled\n);
return -ENXIO;
+ }
if (IS_ERR(ci-phy) IS_ERR(ci-usb_phy))
return -EPROBE_DEFER;
@@ -761,16 +763,22 @@ 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);
- if (ret)
+ if (ret) {
+ dev_err(dev, can't acquire IRQ line %d\n, ci-irq);
goto stop;
+ }
if (ci_otg_is_fsm_mode(ci))
ci_hdrc_otg_fsm_start(ci);
ret = dbg_create_files(ci);
- if (!ret)
- return 0;
+ if (ret) {
+ dev_err(dev, can't register debugfs files\n);
+ goto release_irq;
+ }
+ return 0;
+release_irq:
free_irq(ci-irq, ci);
stop:
ci_role_destroy(ci);
--
2.1.3
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
--
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 1/3] USB: host: Remove ehci-octeon and ohci-octeon drivers
On Fri, Nov 14, 2014 at 10:31:51AM +0100, Ralf Baechle wrote: On Thu, Nov 13, 2014 at 10:36:28PM +0100, Andreas Herrmann wrote: From: Alan Stern st...@rowland.harvard.edu From: Alan Stern st...@rowland.harvard.edu Is there an echo? Oops. Is there an echo? LOL. Remove special-purpose octeon drivers and instead use ehci-platform and ohci-platform as suggested with http://marc.info/?l=linux-mipsm=140139694721623w=2 [andreas.herrmann: fixed compile error] Cc: David Daney david.da...@cavium.com Cc: Alex Smith alex.sm...@imgtec.com Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Andreas Herrmann andreas.herrm...@caviumnetworks.com --- arch/mips/cavium-octeon/octeon-platform.c | 274 - arch/mips/configs/cavium_octeon_defconfig |3 + drivers/usb/host/Kconfig | 18 +- drivers/usb/host/Makefile |1 - drivers/usb/host/ehci-hcd.c |5 - drivers/usb/host/ehci-octeon.c| 188 drivers/usb/host/octeon2-common.c | 200 - drivers/usb/host/ohci-hcd.c |5 - drivers/usb/host/ohci-octeon.c| 202 - 9 files changed, 285 insertions(+), 611 deletions(-) delete mode 100644 drivers/usb/host/ehci-octeon.c delete mode 100644 drivers/usb/host/octeon2-common.c delete mode 100644 drivers/usb/host/ohci-octeon.c For the MIPS bits: For the MIPS bits: Acked-by: Ralf Baechle r...@linux-mips.org Acked-by: Ralf Baechle r...@linux-mips.org Ralf Ralf Double thanks, Andreas -- 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] Immutable branch between MFD, GPIO and I2C
On Mon, Nov 10, 2014 at 6:43 PM, Lee Jones lee.jo...@linaro.org wrote: Please don't pull this -- it is missing a patch. Will fix. Okay, dependency fixed. Sorry for the fuss. Pull when ready. Letting it just sit around unless there are conflicts coming up... Seems like this can go through MFD alone from the GPIO side of things. Yours, Linus Walleij -- 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/2] usb: musb: musb_cppi41: revert to old timer poll intervals
Maybe I`ve found a nice old patch: https://github.com/Angstrom-distribution/meta-ti/blob/master/recipes-kernel/linux/linux-ti33x-psp-3.2/psp/0010-usb-musb-cppi41-enable-txfifo-empty-interrupt-logic.patch Is tx fifo empty interrupt logic already used? So maybe for ISOC we can avoid the busy hrtimer loop. -- Sebastian Reimers signature.asc Description: This is a digitally signed message part
Re: [PATCH v3] usb: dwc2/gadget: report disconnect event from 'end session' irq
On 2014-11-13 21:50, Paul Zimmerman wrote:
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Thursday, November 13, 2014 5:40 AM
On 2014-10-31 19:15, Paul Zimmerman wrote:
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Friday, October 31, 2014 1:04 AM
To: linux-usb@vger.kernel.org; linux-samsung-...@vger.kernel.org
Cc: Marek Szyprowski; Kyungmin Park; Robert Baldyga; Paul Zimmerman; Krzysztof
Kozlowski; Felipe
Balbi
Subject: [PATCH v3] usb: dwc2/gadget: report disconnect event from 'end
session' irq
This patch adds a call to s3c_hsotg_disconnect() from 'end session'
interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
about unplugged usb cable. 'disconnected' interrupt (DISCONNINT) might
look a bit more suitable for this event, but it is asserted only in
host mode, so in device mode we need to use something else.
Additional check has been added in s3c_hsotg_disconnect() function
to ensure that the event is reported only once after successful device
enumeration.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 55c90c53f2d6..b42df32e7737 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -212,6 +212,7 @@ struct s3c_hsotg {
struct usb_gadget gadget;
unsigned intsetup;
unsigned long last_rst;
+ unsigned intaddress;
struct s3c_hsotg_ep *eps;
};
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index fcd2bb55ccca..6304efba11aa 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1114,6 +1114,7 @@ static void s3c_hsotg_process_control(struct s3c_hsotg
*hsotg,
DCFG_DEVADDR_SHIFT) DCFG_DEVADDR_MASK;
writel(dcfg, hsotg-regs + DCFG);
+ hsotg-address = ctrl-wValue;
dev_info(hsotg-dev, new address %d\n, ctrl-wValue);
ret = s3c_hsotg_send_reply(hsotg, ep0, NULL, 0);
@@ -2031,6 +2032,10 @@ static void s3c_hsotg_disconnect(struct s3c_hsotg *hsotg)
{
unsigned ep;
+ if (!hsotg-address)
+ return;
+
+ hsotg-address = 0;
for (ep = 0; ep hsotg-num_of_eps; ep++)
kill_all_requests(hsotg, hsotg-eps[ep], -ESHUTDOWN, true);
@@ -2290,6 +2295,11 @@ irq_retry:
dev_info(hsotg-dev, OTGInt: %08x\n, otgint);
writel(otgint, hsotg-regs + GOTGINT);
+
+ if (otgint GOTGINT_SES_END_DET) {
+ s3c_hsotg_disconnect(hsotg);
+ hsotg-gadget.speed = USB_SPEED_UNKNOWN;
+ }
}
if (gintsts GINTSTS_SESSREQINT) {
I don't think this is right. The host can send control requests to
the device before it sends a SetAddress to change from the default
address of 0. So if a GOTGINT_SES_END_DET happens before the
SetAddress, it will be ignored.
Or am I missing something?
Well, right. However before finishing enumeration (setting the address)
host usually
only retrieves some usb descriptors what doesn't change the state of the
gadget.
Right now we always reported 'disconnected' event before setting the new
address,
what is a bit overkill (in some cases gadget driver got this even more
than once).
The above code handles all cases correctly and reports disconnect event
only once.
Well, if the disconnect happens before the SetAddress, the disconnect
won't be reported at all. Unless I'm reading the code wrong.
Right, although this is not really an issue for any gadget driver.
However if you
prefer to report disconnect event more than once, I'm okay and I will
remove the
check based on the device address.
Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland
--
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: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
On Wed, Nov 12, 2014 at 2:21 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams d...@redhat.com wrote: On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote: Hi, I wanted to understand what is going on the kernel-side when connecting to the Internet via a Huawei E173 USB web-stick (3rd Generation: UMTS / HSPA). Especially the correlation between the diverse USB/NET kernel-drivers and how the networking is setup. [ Sitting in front of a foreign Windows machine ] [ CC Aleksander ] Hi Dan, sorry for the late (and short) response. AFAICS you have given a skeleton for a usb-wwan-networking documentation :-). Personally, I would like to take into account some kernel-config options and some more things. I started with documenting... I have still some difficulties in understanding USB WWAN Networking. So, this is what I revealed... # USB: HUAWEI E173 3G/UMTS/HSPA INTERNET STICK ### USB-NETWORKING AND WWAN SETUP CONFIG_USB_USBNET=m--- usb networking CONFIG_USB_NET_CDCETHER=m --- usb-wwan (net) configuration CONFIG_USB_SERIAL_WWAN=m --- usb-wwan (serial) configuration CONFIG_USB_SERIAL_OPTION=m --- usb-serial driver called option ### PPP OPTIONS CONFIG_PPP=y CONFIG_PPP_BSDCOMP=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_FILTER=y CONFIG_PPP_MULTILINK=y CONFIG_PPP_ASYNC=m Beyond the PPP options, I wanted to understand what CONFIG_USB_NET_CDCETHER does and why I need it. Can someone help? Thanks. - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/Kconfig#n189 P.S.: cdc_ether Kconfig option and checking my logs From [1]... ... config USB_NET_CDCETHER tristate CDC Ethernet support (smart devices such as cable modems) depends on USB_USBNET default y help This option supports devices conforming to the Communication Device Class (CDC) Ethernet Control Model, a specification that's easy to implement in device firmware. The CDC specifications are available from http://www.usb.org/. CDC Ethernet is an implementation option for DOCSIS cable modems that support USB connectivity, used for non-Microsoft USB hosts. The Linux-USB CDC Ethernet Gadget driver is an open implementation. This driver should work with at least the following devices: * Dell Wireless 5530 HSPA * Ericsson PipeRider (all variants) * Ericsson Mobile Broadband Module (all variants) * Motorola (DM100 and SB4100) * Broadcom Cable Modem (reference design) * Toshiba (PCX1100U and F3507g/F3607gw) * ... This driver creates an interface named ethX, where X depends on what other networking devices you have in use. However, if the IEEE 802 local assignment bit is set in the address, a usbX name is used instead. ... From my logs... $ dmesg | egrep -i 'option|wwan|ppp|3-1.2|huawei|gsm|modem' [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.549498] PPP generic driver version 2.4.2 [1.299059] usb 3-1.2: new high-speed USB device number 3 using ehci-pci [1.394084] usb 3-1.2: New USB device found, idVendor=12d1, idProduct=1436 [1.394095] usb 3-1.2: New USB device strings: Mfr=4, Product=3, SerialNumber=0 [1.394100] usb 3-1.2: Product: HUAWEI Mobile [1.394103] usb 3-1.2: Manufacturer: HUAWEI Technology [2.115424] usb-storage 3-1.2:1.0: USB Mass Storage device detected [2.125026] usb-storage 3-1.2:1.1: USB Mass Storage device detected [2.125607] usb-storage 3-1.2:1.2: USB Mass Storage device detected [2.125888] usb-storage 3-1.2:1.3: USB Mass Storage device detected [2.126187] usb-storage 3-1.2:1.4: USB Mass Storage device detected [2.126461] usb-storage 3-1.2:1.5: USB Mass Storage device detected [2.127098] scsi host11: usb-storage 3-1.2:1.5 [2.129370] usb-storage 3-1.2:1.6: USB Mass Storage device detected [2.131685] scsi host12: usb-storage 3-1.2:1.6 [3.127317] scsi 11:0:0:0: CD-ROMHUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2 [3.137589] scsi 12:0:0:0: Direct-Access HUAWEI SD Storage 2.31 PQ: 0 ANSI: 2 [ 13.500302] cdc_ether 3-1.2:1.1 wwan0: register 'cdc_ether' at usb-:00:1a.0-1.2, Mobile Broadband Network Device, 02:50:f3:00:00:00 [ 14.160221] usbcore: registered new interface driver option [ 14.160820] usbserial: USB Serial support registered for GSM modem (1-port) [ 14.160940] option 3-1.2:1.0: GSM modem (1-port) converter detected [ 14.163032] usb 3-1.2: GSM modem (1-port) converter now attached to ttyUSB0 [ 14.163305] option 3-1.2:1.3: GSM modem (1-port) converter detected [ 14.163676] usb 3-1.2: GSM modem (1-port) converter now attached to ttyUSB1 [ 14.163742] option 3-1.2:1.4: GSM modem (1-port) converter detected [ 14.165227] usb 3-1.2: GSM modem (1-port) converter now attached to ttyUSB2 [ 72.877065] PPP BSD Compression module registered [ 72.881701] PPP Deflate Compression module registered - EOT - -- To unsubscribe from this list: send
Re: [PATCH 0/3] USB: host: Misc patches to remove hard-coded octeon platform information
On Thu, Nov 13, 2014 at 05:13:36PM -0500, Alan Stern wrote: On Thu, 13 Nov 2014, Andreas Herrmann wrote: Hi Alan, With following patches I want to base octeon ehci/ohci device configuration on device tree information. I picked up patches that were submitted in May. See http://marc.info/?l=linux-usbm=140135823325811w=2 and http://marc.info/?l=linux-mipsm=140139694721623w=2 Patch #1 is your untested preliminary pass to remove [oe]hci-octeon drivers. Patch #2 is the removal of hard-coded platform information (but now rebased on your patch) Patch #3 adapts dma_mask for ehci (as used in ehci-octeon) Overall diffstat is arch/mips/cavium-octeon/octeon-platform.c | 380 +++-- arch/mips/configs/cavium_octeon_defconfig |3 + drivers/usb/host/Kconfig | 18 +- drivers/usb/host/Makefile |1 - drivers/usb/host/ehci-hcd.c |5 - drivers/usb/host/ehci-octeon.c| 188 -- drivers/usb/host/ehci-platform.c |4 +- drivers/usb/host/octeon2-common.c | 200 --- drivers/usb/host/ohci-hcd.c |5 - drivers/usb/host/ohci-octeon.c| 202 --- drivers/usb/host/ohci-platform.c |1 + include/linux/usb/ehci_pdriver.h |1 + 12 files changed, 330 insertions(+), 678 deletions(-) Patches are based on v3.18-rc4-65-g2c54396 Comments welcome. At a very quick first glance, it looks great. Have you tested it thoroughly? [sorry have to use another mail account, so far your mail didn't show up at my caviumnetworks account] I've tested it only on an EdgeRouterPro (Octeon II system, which I have on-site). octeon_ehci_device_init and octeon_ohci_device_init run way before ehci-platform and ohci-platform probe for devices. So everything should be initialized orderly. With current mainline (w/o these patches) USB doesn't work on my EdgeRouterPro due to an (inappropriate) OCTEON_IS_MODEL check. I'd say having the patches in linux-next for awhile wouldn't hurt. Andreas -- 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/2] usb: musb: musb_cppi41: revert to old timer poll intervals
On 11/14/2014 11:19 AM, Sebastian Reimers wrote: Maybe I`ve found a nice old patch: https://github.com/Angstrom-distribution/meta-ti/blob/master/recipes-kernel/linux/linux-ti33x-psp-3.2/psp/0010-usb-musb-cppi41-enable-txfifo-empty-interrupt-logic.patch Is tx fifo empty interrupt logic already used? So maybe for ISOC we can avoid the busy hrtimer loop. Thanks for that. No, it is not used but I had the same idea while I fixed the HS detect but no idea if it is possible didn't get around to check with the manual. Now that there is a patch doing so it seems to be possible :) I have something else on my plate for today but then I will look at this. Sebastian -- 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 1/3] usb: chipidea: add controller reset API
Hello.
On 11/14/2014 3:03 AM, Peter Chen wrote:
Add controller reset API, it may be used for host/otg driver in future.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
Changes for v2:
- Add return value check for controller reset at hw_device_reset
drivers/usb/chipidea/core.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index bd74f27..dffd89b 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
[...]
@@ -392,13 +412,17 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
*/
int hw_device_reset(struct ci_hdrc *ci, u32 mode)
{
+ int ret;
+
/* should flush stop before reset */
hw_write(ci, OP_ENDPTFLUSH, ~0, ~0);
hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
- hw_write(ci, OP_USBCMD, USBCMD_RST, USBCMD_RST);
- while (hw_read(ci, OP_USBCMD, USBCMD_RST))
- udelay(10); /* not RTOS friendly */
+ ret = hw_controller_reset(ci);
+ if (ret) {
+ dev_err(ci-dev, error for reset, ret=%d\n, ret);
Perhaps error resetting?
+ return ret;
+ }
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: [PATCH v3] usb: dwc2/gadget: report disconnect event from 'end session' irq
Hello,
On 2014-11-13 21:50, Paul Zimmerman wrote:
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Thursday, November 13, 2014 5:40 AM
On 2014-10-31 19:15, Paul Zimmerman wrote:
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Friday, October 31, 2014 1:04 AM
To: linux-usb@vger.kernel.org; linux-samsung-...@vger.kernel.org
Cc: Marek Szyprowski; Kyungmin Park; Robert Baldyga; Paul Zimmerman; Krzysztof
Kozlowski; Felipe
Balbi
Subject: [PATCH v3] usb: dwc2/gadget: report disconnect event from 'end
session' irq
This patch adds a call to s3c_hsotg_disconnect() from 'end session'
interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
about unplugged usb cable. 'disconnected' interrupt (DISCONNINT) might
look a bit more suitable for this event, but it is asserted only in
host mode, so in device mode we need to use something else.
Additional check has been added in s3c_hsotg_disconnect() function
to ensure that the event is reported only once after successful device
enumeration.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 55c90c53f2d6..b42df32e7737 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -212,6 +212,7 @@ struct s3c_hsotg {
struct usb_gadget gadget;
unsigned intsetup;
unsigned long last_rst;
+ unsigned intaddress;
struct s3c_hsotg_ep *eps;
};
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index fcd2bb55ccca..6304efba11aa 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1114,6 +1114,7 @@ static void s3c_hsotg_process_control(struct s3c_hsotg
*hsotg,
DCFG_DEVADDR_SHIFT) DCFG_DEVADDR_MASK;
writel(dcfg, hsotg-regs + DCFG);
+ hsotg-address = ctrl-wValue;
dev_info(hsotg-dev, new address %d\n, ctrl-wValue);
ret = s3c_hsotg_send_reply(hsotg, ep0, NULL, 0);
@@ -2031,6 +2032,10 @@ static void s3c_hsotg_disconnect(struct s3c_hsotg *hsotg)
{
unsigned ep;
+ if (!hsotg-address)
+ return;
+
+ hsotg-address = 0;
for (ep = 0; ep hsotg-num_of_eps; ep++)
kill_all_requests(hsotg, hsotg-eps[ep], -ESHUTDOWN, true);
@@ -2290,6 +2295,11 @@ irq_retry:
dev_info(hsotg-dev, OTGInt: %08x\n, otgint);
writel(otgint, hsotg-regs + GOTGINT);
+
+ if (otgint GOTGINT_SES_END_DET) {
+ s3c_hsotg_disconnect(hsotg);
+ hsotg-gadget.speed = USB_SPEED_UNKNOWN;
+ }
}
if (gintsts GINTSTS_SESSREQINT) {
I don't think this is right. The host can send control requests to
the device before it sends a SetAddress to change from the default
address of 0. So if a GOTGINT_SES_END_DET happens before the
SetAddress, it will be ignored.
Or am I missing something?
Well, right. However before finishing enumeration (setting the address)
host usually
only retrieves some usb descriptors what doesn't change the state of the
gadget.
Right now we always reported 'disconnected' event before setting the new
address,
what is a bit overkill (in some cases gadget driver got this even more
than once).
The above code handles all cases correctly and reports disconnect event
only once.
Well, if the disconnect happens before the SetAddress, the disconnect
won't be reported at all. Unless I'm reading the code wrong.
Ok, I found other way to ensure that disconnect event is reported only
once.
I will post a patch in a few minutes.
Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland
--
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] usb: dwc2/gadget: rework disconnect event handling
This patch adds a call to s3c_hsotg_disconnect() from 'end session'
interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
about unplugged usb cable. DISCONNINT interrupt cannot be used for this
purpose, because it is asserted only in host mode.
To avoid reporting disconnect event more than once, a disconnect call has
been moved from USB_REQ_SET_ADDRESS handling function to SESSREQINT
interrupt. This way driver ensures that disconnect event is reported
either when usb cable is unplugged or every time the host starts a new
session.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 55c90c53f2d6..78b9090ebf71 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -210,6 +210,7 @@ struct s3c_hsotg {
u8 ctrl_buff[8];
struct usb_gadget gadget;
+ unsigned intsession:1;
unsigned intsetup;
unsigned long last_rst;
struct s3c_hsotg_ep *eps;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index fcd2bb55ccca..c7f68dc1cf6b 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1029,7 +1029,6 @@ static int s3c_hsotg_process_req_feature(struct s3c_hsotg
*hsotg,
}
static void s3c_hsotg_enqueue_setup(struct s3c_hsotg *hsotg);
-static void s3c_hsotg_disconnect(struct s3c_hsotg *hsotg);
/**
* s3c_hsotg_stall_ep0 - stall ep0
@@ -1107,7 +1106,6 @@ static void s3c_hsotg_process_control(struct s3c_hsotg
*hsotg,
if ((ctrl-bRequestType USB_TYPE_MASK) == USB_TYPE_STANDARD) {
switch (ctrl-bRequest) {
case USB_REQ_SET_ADDRESS:
- s3c_hsotg_disconnect(hsotg);
dcfg = readl(hsotg-regs + DCFG);
dcfg = ~DCFG_DEVADDR_MASK;
dcfg |= (le16_to_cpu(ctrl-wValue)
@@ -2031,6 +2029,10 @@ static void s3c_hsotg_disconnect(struct s3c_hsotg *hsotg)
{
unsigned ep;
+ if (!hsotg-session)
+ return;
+
+ hsotg-session = 0;
for (ep = 0; ep hsotg-num_of_eps; ep++)
kill_all_requests(hsotg, hsotg-eps[ep], -ESHUTDOWN, true);
@@ -2290,11 +2292,18 @@ irq_retry:
dev_info(hsotg-dev, OTGInt: %08x\n, otgint);
writel(otgint, hsotg-regs + GOTGINT);
+
+ if (otgint GOTGINT_SES_END_DET) {
+ s3c_hsotg_disconnect(hsotg);
+ hsotg-gadget.speed = USB_SPEED_UNKNOWN;
+ }
}
if (gintsts GINTSTS_SESSREQINT) {
dev_dbg(hsotg-dev, %s: SessReqInt\n, __func__);
writel(GINTSTS_SESSREQINT, hsotg-regs + GINTSTS);
+ s3c_hsotg_disconnect(hsotg);
+ hsotg-session = 1;
}
if (gintsts GINTSTS_ENUMDONE) {
--
1.9.2
--
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: [PATCHv4 2/6] phy: improved lookup method
Hi Vivek, On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: Hi Heikki, Kishon, How about adding the change in attached patch [1] on top of this patch. Just introduced the phy pointer in phy_lookup structure, and modified phy_find() accordingly. [1] Attachment: 0001-phy-core-Use-phy-pointer-with-phy_lookup_table.patch Just to let you know, I'm finally able to work on this again. I was actually thinking that we should just roll back to the previous version where I didn't yet use the parent name, and rethink how to solve the problem Kishon pointed out. But, I'll take a look at this properly on Monday. 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
[PATCH v1] chipidea: pci: register nop PHY
Since PHY for Chipidea is optional (not all SoCs having PHY for Chipidea should
be programmed), we register 'nop' PHY for platforms that does not have
programmable PHY.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/usb/chipidea/ci_hdrc_pci.c | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_pci.c
b/drivers/usb/chipidea/ci_hdrc_pci.c
index 241ae34..7e0b701 100644
--- a/drivers/usb/chipidea/ci_hdrc_pci.c
+++ b/drivers/usb/chipidea/ci_hdrc_pci.c
@@ -16,10 +16,16 @@
#include linux/interrupt.h
#include linux/usb/gadget.h
#include linux/usb/chipidea.h
+#include linux/usb/usb_phy_generic.h
/* driver name */
#define UDC_DRIVER_NAME ci_hdrc_pci
+struct ci_hdrc_pci {
+ struct platform_device *ci;
+ struct platform_device *phy;
+};
+
/**
* PCI block
*/
@@ -52,7 +58,7 @@ static int ci_hdrc_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
struct ci_hdrc_platform_data *platdata = (void *)id-driver_data;
- struct platform_device *plat_ci;
+ struct ci_hdrc_pci *ci;
struct resource res[3];
int retval = 0, nres = 2;
@@ -61,6 +67,10 @@ static int ci_hdrc_pci_probe(struct pci_dev *pdev,
return -ENODEV;
}
+ ci = devm_kzalloc(pdev-dev, sizeof(*ci), GFP_KERNEL);
+ if (!ci)
+ return -ENOMEM;
+
retval = pcim_enable_device(pdev);
if (retval)
return retval;
@@ -73,20 +83,27 @@ static int ci_hdrc_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
pci_try_set_mwi(pdev);
+ /* register a nop PHY */
+ ci-phy = usb_phy_generic_register();
+ if (!ci-phy)
+ return -ENOMEM;
+
memset(res, 0, sizeof(res));
+
res[0].start= pci_resource_start(pdev, 0);
res[0].end = pci_resource_end(pdev, 0);
res[0].flags= IORESOURCE_MEM;
res[1].start= pdev-irq;
res[1].flags= IORESOURCE_IRQ;
- plat_ci = ci_hdrc_add_device(pdev-dev, res, nres, platdata);
- if (IS_ERR(plat_ci)) {
+ ci-ci = ci_hdrc_add_device(pdev-dev, res, nres, platdata);
+ if (IS_ERR(ci-ci)) {
dev_err(pdev-dev, ci_hdrc_add_device failed!\n);
- return PTR_ERR(plat_ci);
+ usb_phy_generic_unregister(ci-phy);
+ return PTR_ERR(ci-ci);
}
- pci_set_drvdata(pdev, plat_ci);
+ pci_set_drvdata(pdev, ci);
return 0;
}
@@ -101,9 +118,10 @@ static int ci_hdrc_pci_probe(struct pci_dev *pdev,
*/
static void ci_hdrc_pci_remove(struct pci_dev *pdev)
{
- struct platform_device *plat_ci = pci_get_drvdata(pdev);
+ struct ci_hdrc_pci *ci = pci_get_drvdata(pdev);
- ci_hdrc_remove_device(plat_ci);
+ ci_hdrc_remove_device(ci-ci);
+ usb_phy_generic_unregister(ci-phy);
}
/**
--
2.1.3
--
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 v2] usb: host: xhci: issue 'Reset Endpoint' for !CONTROL EPs from finish_td()
On Fri, Nov 14, 2014 at 10:39:15AM +0200, Mathias Nyman wrote: On 13.11.2014 20:46, Felipe Balbi wrote: On Thu, Nov 13, 2014 at 12:31:28PM -0600, Felipe Balbi wrote: Hi, (your mailing is un-wrapping emails, I always end up with pretty long lines and have to rewrap them) On Thu, Nov 13, 2014 at 07:58:28PM +0200, Mathias Nyman wrote: The algorithm described in the DVB tuner bug is clearly wrong, since it doesn't move the dequeue pointer until usb_clear_halt() is called, which is far too late. The right approach is to fix up the dequeue pointer before giving back the URB (so there's no need to save a stopped TD value). Otherwise there will be TDs in the endpoint ring containing stale DMA pointers to buffers that have already been unmapped. Thats right, I cleaned up the patch and removed resetting the endpoint from the .endpoint_reset() callback which was called as a result of usb_clear_halt(). Now we queue a reset endpoint and set dequeue pointer before giving back the URB. I still set a stopped td value, but could as well just pass it as function parameter. Actually I'll do that in later cleanup patch. Latest version of the patch is now in my tree in a reset-rework-v2 branch, with fixes comments and removed The brach includes the other dorbell ringing patch as well. both are on top of 3.18-rc4. I still need to test it before sending it further, the tree is here: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git reset-rework-v2 I'll test this one. for both commits on that branch, you can add my: Tested-by: Felipe Balbi ba...@ti.com But please also add proper fixes and Cc: stable, so older kernels can use those. Thanks a lot for testing again. I'll CC stable and add your tested-by, but I still don't know exactly which commit it Fixes. This might have been there since the early days of xhci. git blame usually helps. Just look for code which was differentiating COMP_STALL and treating it differently. I know that at least v3.14 has the problem. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/3] usb: chipidea: parameter 'mode' isn't needed for hw_device_reset
Hi,
On Fri, Nov 14, 2014 at 03:40:55PM +0800, Peter Chen wrote:
@@ -1660,7 +1660,7 @@ static int ci_udc_start(struct usb_gadget *gadget,
pm_runtime_get_sync(ci-gadget.dev);
if (ci-vbus_active) {
spin_lock_irqsave(ci-lock, flags);
- hw_device_reset(ci, USBMODE_CM_DC);
+ hw_device_reset(ci);
wow, you guys reset this IP all the time... that's scary, could be
hiding bugs easily.
In current chipidea design, it indeed resets controller often, it
resets controller when the usb cable connects to pc and the gadget
driver is there, something like which we do for RUN/STOP bit.
RUN/STOP on dwc3 is not an IP reset though. Neither it is on XHCI/EHCI.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/3] usb: chipidea: add controller reset API
On Fri, Nov 14, 2014 at 03:33:44PM +0800, Peter Chen wrote: On Thu, Nov 13, 2014 at 09:55:34PM -0600, Felipe Balbi wrote: Hi, On Fri, Nov 14, 2014 at 08:03:15AM +0800, Peter Chen wrote: Add controller reset API, it may be used for host/otg driver in future. you need a better commit log here. How would it be used ? when ? And, more importantly, why ? I will add more information Why would we need to reset the IP outside of -probe() ? I don't oppose to the refactoring, but why would we ever need to reset this IP ? Usually, we need to below reset controller at below situations: - Role switch, host-device and device-host - Return from hibernation, which the controller will lost its power, and the content of the register are lost. resetting is probably not the best solution in either case, though. It might be the easiest, but not the best. For suspend/resume, you would be better off saving/restoring contenxt and for role switch, you could just reprogram the few registers which need to change when role swapping. -- balbi signature.asc Description: Digital signature
Re: [PATCH v1] chipidea: pci: register nop PHY
On Fri, Nov 14, 2014 at 04:33:22PM +0200, Andy Shevchenko wrote:
Since PHY for Chipidea is optional (not all SoCs having PHY for Chipidea
should
be programmed), we register 'nop' PHY for platforms that does not have
s/does not/do not/
@@ -73,20 +83,27 @@ static int ci_hdrc_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
pci_try_set_mwi(pdev);
+ /* register a nop PHY */
+ ci-phy = usb_phy_generic_register();
+ if (!ci-phy)
+ return -ENOMEM;
+
memset(res, 0, sizeof(res));
+
res[0].start= pci_resource_start(pdev, 0);
res[0].end = pci_resource_end(pdev, 0);
res[0].flags= IORESOURCE_MEM;
res[1].start= pdev-irq;
res[1].flags= IORESOURCE_IRQ;
- plat_ci = ci_hdrc_add_device(pdev-dev, res, nres, platdata);
- if (IS_ERR(plat_ci)) {
+ ci-ci = ci_hdrc_add_device(pdev-dev, res, nres, platdata);
+ if (IS_ERR(ci-ci)) {
dev_err(pdev-dev, ci_hdrc_add_device failed!\n);
- return PTR_ERR(plat_ci);
+ usb_phy_generic_unregister(ci-phy);
+ return PTR_ERR(ci-ci);
}
- pci_set_drvdata(pdev, plat_ci);
+ pci_set_drvdata(pdev, ci);
doesn't seem like this fits here. Should probably be a separate patch.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] HID: usbhid: get/put around clearing needs_remote_wakeup
On Thu, 13 Nov 2014, Benson Leung wrote: Hi Alan, On Thu, Nov 13, 2014 at 2:11 PM, Alan Stern st...@rowland.harvard.edu wrote: Wait a minute -- in your previous email you said this approach didn't work. So does it work or doesn't it? Sorry for the confusion. The approach *does* work. That was actually my original idea to fix the problem, but I saw other places in the kernel where it was done with a get/put. The reason for the get/put is to force a call to autosuspend_check(). But in this case, if killing the interrupt URB causes autosuspend_check() to run then the get/put isn't needed. On the other hand, I don't see why killing the interrupt URB would cause autosuspend_check() to run. Can you explain that? 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 3/3] USB: host: Introduce flag to enable use of 64-bit dma_mask for ehci-platform
On Fri, 14 Nov 2014, Andreas Herrmann wrote: On Thu, Nov 13, 2014 at 08:44:17PM -0800, Florian Fainelli wrote: 2014-11-13 13:36 GMT-08:00 Andreas Herrmann andreas.herrm...@caviumnetworks.com: ehci-octeon driver used a 64-bit dma_mask. With removal of ehci-octeon and usage of ehci-platform ehci dma_mask is now limited to 32 bits (coerced in ehci_platform_probe). Provide a flag in ehci platform data to allow use of 64 bits for dma_mask. Why not just allow enforcing an arbitrary DMA mask? I thought about that but as it's currently just 32 or 64 bits a flag is sufficient. (At the moment I am not aware that other ehci-platform devices would require something else.) I'll change the flag to a mask if desired. Alan, what's your opinion about this? I'm not aware of any devices that need a different DMA mask either. Florian, do you have any reason for thinking such a thing might come along? Like Andreas, I don't mind making it more general if there's a good reason to do so. 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
[PATCH v7 05/13] phy: add the Berlin USB PHY driver
Add the driver driving the Marvell Berlin USB PHY. This allows to initialize the PHY and to use it from the USB driver later. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com --- drivers/phy/Kconfig | 7 ++ drivers/phy/Makefile | 1 + drivers/phy/phy-berlin-usb.c | 224 +++ 3 files changed, 232 insertions(+) create mode 100644 drivers/phy/phy-berlin-usb.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 2a436e607f99..b6da75f563e7 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -15,6 +15,13 @@ config GENERIC_PHY phy users can obtain reference to the PHY. All the users of this framework should select this config. +config PHY_BERLIN_USB + tristate Marvell Berlin USB PHY Driver + depends on ARCH_BERLIN HAS_IOMEM OF + select GENERIC_PHY + help + Enable this to support the USB PHY on Marvell Berlin SoCs. + config PHY_BERLIN_SATA tristate Marvell Berlin SATA PHY driver depends on ARCH_BERLIN HAS_IOMEM OF diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index c4590fce082f..6fd1f776fd8d 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_GENERIC_PHY) += phy-core.o +obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o diff --git a/drivers/phy/phy-berlin-usb.c b/drivers/phy/phy-berlin-usb.c new file mode 100644 index ..f9f13067f50f --- /dev/null +++ b/drivers/phy/phy-berlin-usb.c @@ -0,0 +1,224 @@ +/* + * Copyright (C) 2014 Marvell Technology Group Ltd. + * + * Antoine Tenart antoine.ten...@free-electrons.com + * Jisheng Zhang jszh...@marvell.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/gpio.h +#include linux/io.h +#include linux/module.h +#include linux/of_device.h +#include linux/of_gpio.h +#include linux/phy/phy.h +#include linux/platform_device.h +#include linux/reset.h + +#define USB_PHY_PLL0x04 +#define USB_PHY_PLL_CONTROL0x08 +#define USB_PHY_TX_CTRL0 0x10 +#define USB_PHY_TX_CTRL1 0x14 +#define USB_PHY_TX_CTRL2 0x18 +#define USB_PHY_RX_CTRL0x20 +#define USB_PHY_ANALOG 0x34 + +/* USB_PHY_PLL */ +#define CLK_REF_DIV(x) ((x) 4) +#define FEEDBACK_CLK_DIV(x)((x) 8) + +/* USB_PHY_PLL_CONTROL */ +#define CLK_STABLE BIT(0) +#define PLL_CTRL_PIN BIT(1) +#define PLL_CTRL_REG BIT(2) +#define PLL_ON BIT(3) +#define PHASE_OFF_TOL_125 (0x0 5) +#define PHASE_OFF_TOL_250 BIT(5) +#define KVC0_CALIB (0x0 9) +#define KVC0_REG_CTRL BIT(9) +#define KVC0_HIGH (0x0 10) +#define KVC0_LOW (0x3 10) +#define CLK_BLK_EN BIT(13) + +/* USB_PHY_TX_CTRL0 */ +#define EXT_HS_RCAL_EN BIT(3) +#define EXT_FS_RCAL_EN BIT(4) +#define IMPCAL_VTH_DIV(x) ((x) 5) +#define EXT_RS_RCAL_DIV(x) ((x) 8) +#define EXT_FS_RCAL_DIV(x) ((x) 12) + +/* USB_PHY_TX_CTRL1 */ +#define TX_VDD15_14(0x0 4) +#define TX_VDD15_15BIT(4) +#define TX_VDD15_16(0x2 4) +#define TX_VDD15_17(0x3 4) +#define TX_VDD12_VDD (0x0 6) +#define TX_VDD12_11BIT(6) +#define TX_VDD12_12(0x2 6) +#define TX_VDD12_13(0x3 6) +#define LOW_VDD_EN BIT(8) +#define TX_OUT_AMP(x) ((x) 9) + +/* USB_PHY_TX_CTRL2 */ +#define TX_CHAN_CTRL_REG(x)((x) 0) +#define DRV_SLEWRATE(x)((x) 4) +#define IMP_CAL_FS_HS_DLY_0(0x0 6) +#define IMP_CAL_FS_HS_DLY_1BIT(6) +#define IMP_CAL_FS_HS_DLY_2(0x2 6) +#define IMP_CAL_FS_HS_DLY_3(0x3 6) +#define FS_DRV_EN_MASK(x) ((x) 8) +#define HS_DRV_EN_MASK(x) ((x) 12) + +/* USB_PHY_RX_CTRL */ +#define PHASE_FREEZE_DLY_2_CL (0x0 0) +#define PHASE_FREEZE_DLY_4_CL BIT(0) +#define ACK_LENGTH_8_CL(0x0 2) +#define ACK_LENGTH_12_CL BIT(2) +#define ACK_LENGTH_16_CL (0x2 2) +#define ACK_LENGTH_20_CL (0x3 2) +#define SQ_LENGTH_3(0x0 4) +#define SQ_LENGTH_6BIT(4) +#define SQ_LENGTH_9(0x2 4) +#define SQ_LENGTH_12 (0x3 4) +#define DISCON_THRESHOLD_260 (0x0 6) +#define DISCON_THRESHOLD_270 BIT(6) +#define DISCON_THRESHOLD_280 (0x2 6) +#define DISCON_THRESHOLD_290 (0x3 6) +#define SQ_THRESHOLD(x)((x) 8) +#define LPF_COEF(x)((x) 12) +#define INTPL_CUR_10 (0x0 14) +#define INTPL_CUR_20 BIT(14) +#define INTPL_CUR_30 (0x2
[PATCH v7 13/13] ARM: dts: berlin: enable USB on the Google Chromecast
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Enable usb1 on Google Chromecast which is connected to micro-USB
plug used for external power supply, too.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
index bcd81ffc495d..5c42c3bfb613 100644
--- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
+++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
@@ -27,3 +27,7 @@
};
uart0 { status = okay; };
+
+usb_phy1 { status = okay; };
+
+usb1 { status = okay; };
--
2.1.0
--
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 v7 08/13] usb: chipidea: add a usb2 driver for ci13xxx
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 | 117
2 files changed, 118 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 ..15a0947483b8
--- /dev/null
+++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
@@ -0,0 +1,117 @@
+/*
+ * 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 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;
+ }
+ }
+
+ ret = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto clk_err;
+
+ 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);
+ clk_disable_unprepare(priv-clk);
+
+ return 0;
+}
+
+static const struct of_device_id ci_hdrc_usb2_of_match[] = {
+ { .compatible = chipidea,usb2 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ci_hdrc_usb2_of_match);
+
+static struct platform_driver ci_hdrc_usb2_driver = {
+ .probe = ci_hdrc_usb2_probe,
+ .remove = ci_hdrc_usb2_remove,
+ .driver = {
+ .name = chipidea-usb2,
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(ci_hdrc_usb2_of_match),
+ },
+};
+module_platform_driver(ci_hdrc_usb2_driver);
+
+MODULE_DESCRIPTION(ChipIdea HDRC USB2 binding for ci13xxx);
+MODULE_AUTHOR(Antoine Tenart antoine.ten...@free-electrons.com);
+MODULE_LICENSE(GPL);
--
2.1.0
--
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 v7 12/13] ARM: dts: berlin: add BG2CD nodes for USB support
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Adds nodes describing the Marvell Berlin BG2CD USB PHY and USB. The BG2CD
SoC has 2 USB ChipIdea controllers, with usb0 host-only and usb1 dual-role
capable.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
arch/arm/boot/dts/berlin2cd.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 68f7032b4686..af5e628547ce 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -66,6 +66,22 @@
clocks = chip CLKID_TWD;
};
+ usb_phy0: usb-phy@b74000 {
+ compatible = marvell,berlin2cd-usb-phy;
+ reg = 0xb74000 0x128;
+ #phy-cells = 0;
+ resets = chip 0x178 23;
+ status = disabled;
+ };
+
+ usb_phy1: usb-phy@b78000 {
+ compatible = marvell,berlin2cd-usb-phy;
+ reg = 0xb78000 0x128;
+ #phy-cells = 0;
+ resets = chip 0x178 24;
+ status = disabled;
+ };
+
apb@e8 {
compatible = simple-bus;
#address-cells = 1;
@@ -242,6 +258,26 @@
};
};
+ usb0: usb@ed {
+ compatible = chipidea,usb2;
+ reg = 0xed 0x200;
+ interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB0;
+ phys = usb_phy0;
+ phy-names = usb-phy;
+ status = disabled;
+ };
+
+ usb1: usb@ee {
+ compatible = chipidea,usb2;
+ reg = 0xee 0x200;
+ interrupts = GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB1;
+ phys = usb_phy1;
+ phy-names = usb-phy;
+ status = disabled;
+ };
+
apb@fc {
compatible = simple-bus;
#address-cells = 1;
--
2.1.0
--
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 v7 11/13] ARM: dts: Berlin: enable USB on the BG2Q DMP
Enable the 2 available USB PHY and USB nodes on the Marvell Berlin BG2Q
DMP.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 53 ++
1 file changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index ea1f99b8eed6..f7c25580e122 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@ -7,6 +7,8 @@
*/
/dts-v1/;
+
+#include dt-bindings/gpio/gpio.h
#include berlin2q.dtsi
/ {
@@ -21,6 +23,39 @@
choosen {
bootargs = console=ttyS0,115200 earlyprintk;
};
+
+ regulators {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ reg_usb0_vbus: regulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = usb0_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = portb 8 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
+
+ reg_usb1_vbus: regulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = usb1_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = portb 10 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
+
+ reg_usb2_vbus: regulator@2 {
+ compatible = regulator-fixed;
+ regulator-name = usb2_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = portb 12 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
+ };
};
sdhci1 {
@@ -46,6 +81,24 @@
status = okay;
};
+usb_phy0 {
+ status = okay;
+};
+
+usb_phy2 {
+ status = okay;
+};
+
+usb0 {
+ vbus-supply = reg_usb0_vbus;
+ status = okay;
+};
+
+usb2 {
+ vbus-supply = reg_usb2_vbus;
+ status = okay;
+};
+
eth0 {
status = okay;
};
--
2.1.0
--
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 v7 06/13] Documentation: bindings: add doc for the Berlin USB PHY
Document the bindings of the Marvell Berlin USB PHY driver.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
Documentation/devicetree/bindings/phy/berlin-usb-phy.txt | 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/berlin-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/berlin-usb-phy.txt
b/Documentation/devicetree/bindings/phy/berlin-usb-phy.txt
new file mode 100644
index ..be33780f668e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/berlin-usb-phy.txt
@@ -0,0 +1,16 @@
+* Marvell Berlin USB PHY
+
+Required properties:
+- compatible: marvell,berlin2-usb-phy or marvell,berlin2cd-usb-phy
+- reg: base address and length of the registers
+- #phys-cells: should be 0
+- resets: reference to the reset controller
+
+Example:
+
+ usb-phy@f774000 {
+ compatible = marvell,berlin2-usb-phy;
+ reg = 0xf774000 0x128;
+ #phy-cells = 0;
+ resets = chip 0x104 14;
+ };
--
2.1.0
--
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 v7 10/13] ARM: dts: berlin: add BG2Q nodes for USB support
Adds nodes describing the Marvell Berlin BG2Q USB PHY and USB. The BG2Q
SoC has 3 USB host controller, compatible with ChipIdea.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
arch/arm/boot/dts/berlin2q.dtsi | 55 +
1 file changed, 55 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 2de8d6f8973c..834142bdfbb1 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -114,6 +114,40 @@
#interrupt-cells = 3;
};
+ usb_phy2: phy@a2f400 {
+ compatible = marvell,berlin2-usb-phy;
+ reg = 0xa2f400 0x128;
+ #phy-cells = 0;
+ resets = chip 0x104 14;
+ status = disabled;
+ };
+
+ usb2: usb@a3 {
+ compatible = chipidea,usb2;
+ reg = 0xa3 0x1;
+ interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB2;
+ phys = usb_phy2;
+ phy-names = usb-phy;
+ status = disabled;
+ };
+
+ usb_phy0: phy@b74000 {
+ compatible = marvell,berlin2-usb-phy;
+ reg = 0xb74000 0x128;
+ #phy-cells = 0;
+ resets = chip 0x104 12;
+ status = disabled;
+ };
+
+ usb_phy1: phy@b78000 {
+ compatible = marvell,berlin2-usb-phy;
+ reg = 0xb78000 0x128;
+ #phy-cells = 0;
+ resets = chip 0x104 13;
+ status = disabled;
+ };
+
eth0: ethernet@b9 {
compatible = marvell,pxa168-eth;
reg = 0xb9 0x1;
@@ -365,6 +399,26 @@
};
};
+ usb0: usb@ed {
+ compatible = chipidea,usb2;
+ reg = 0xed 0x1;
+ interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB0;
+ phys = usb_phy0;
+ phy-names = usb-phy;
+ status = disabled;
+ };
+
+ usb1: usb@ee {
+ compatible = chipidea,usb2;
+ reg = 0xee 0x1;
+ interrupts = GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB1;
+ phys = usb_phy1;
+ phy-names = usb-phy;
+ status = disabled;
+ };
+
apb@fc {
compatible = simple-bus;
#address-cells = 1;
@@ -457,5 +511,6 @@
interrupts = GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH;
};
};
+
};
};
--
2.1.0
--
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 v7 09/13] Documentation: bindings: add doc for the USB2 ChipIdea USB driver
Document the USB2 ChipIdea driver (ci13xxx) bindings.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
.../devicetree/bindings/usb/ci-hdrc-usb2.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
new file mode 100644
index ..27f8b1e5ee46
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -0,0 +1,24 @@
+* USB2 ChipIdea USB controller for ci13xxx
+
+Required properties:
+- compatible: should be chipidea,usb2
+- reg: base address and length of the registers
+- interrupts: interrupt for the USB controller
+
+Optional properties:
+- clocks: reference to the USB clock
+- phys: reference to the USB PHY
+- phy-names: should be usb-phy
+- vbus-supply: reference to the VBUS regulator
+
+Example:
+
+ usb@f7ed {
+ compatible = chipidea,usb2;
+ reg = 0xf7ed 0x1;
+ interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB0;
+ phys = usb_phy0;
+ phy-names = usb-phy;
+ vbus-supply = reg_usb0_vbus;
+ };
--
2.1.0
--
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 v7 03/13] ARM: Berlin: select the reset controller
The Marvell Berlin SoCs now has a reset controller. Add the needed configuration. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com --- arch/arm/mach-berlin/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig index 24f85be71671..5803f773a065 100644 --- a/arch/arm/mach-berlin/Kconfig +++ b/arch/arm/mach-berlin/Kconfig @@ -1,11 +1,13 @@ menuconfig ARCH_BERLIN bool Marvell Berlin SoCs if ARCH_MULTI_V7 + select ARCH_HAS_RESET_CONTROLLER select ARCH_REQUIRE_GPIOLIB select ARM_GIC select GENERIC_IRQ_CHIP select DW_APB_ICTL select DW_APB_TIMER_OF select PINCTRL + select RESET_CONTROLLER if ARCH_BERLIN -- 2.1.0 -- 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 v7 04/13] ARM: dts: berlin: add a required reset property in the chip controller node
The chip controller node now also describes the Marvell Berlin reset
controller. Add the required 'reset-cells' property.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Acked-by: Philipp Zabel p.za...@pengutronix.de
---
arch/arm/boot/dts/berlin2.dtsi | 1 +
arch/arm/boot/dts/berlin2cd.dtsi | 1 +
arch/arm/boot/dts/berlin2q.dtsi | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 9d7c810ebd0b..d7e81e124de0 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -249,6 +249,7 @@
chip: chip-control@ea {
compatible = marvell,berlin2-chip-ctrl;
#clock-cells = 1;
+ #reset-cells = 2;
reg = 0xea 0x400;
clocks = refclk;
clock-names = refclk;
diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index cc1df65da504..68f7032b4686 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -231,6 +231,7 @@
chip: chip-control@ea {
compatible = marvell,berlin2cd-chip-ctrl;
#clock-cells = 1;
+ #reset-cells = 2;
reg = 0xea 0x400;
clocks = refclk;
clock-names = refclk;
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 891d56b03922..2de8d6f8973c 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -349,6 +349,7 @@
chip: chip-control@ea {
compatible = marvell,berlin2q-chip-ctrl;
#clock-cells = 1;
+ #reset-cells = 2;
reg = 0xea 0x400, 0xdd0170 0x10;
clocks = refclk;
clock-names = refclk;
--
2.1.0
--
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 v7 02/13] Documentation: bindings: add reset bindings docs for Marvell Berlin SoCs
Add the reset binding documentation to the SoC binding documentation as
the reset driver in Marvell Berlin SoC is part of the chip/system
control registers. This patch adds the required properties to configure
the reset controller.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Acked-by: Philipp Zabel p.za...@pengutronix.de
---
Documentation/devicetree/bindings/arm/marvell,berlin.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt
b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
index 904de5781f44..a99eb9eb14c0 100644
--- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
@@ -106,11 +106,21 @@ Required subnode-properties:
- groups: a list of strings describing the group names.
- function: a string describing the function used to mux the groups.
+* Reset controller binding
+
+A reset controller is part of the chip control registers set. The chip control
+node also provides the reset. The register set is not at the same offset
between
+Berlin SoCs.
+
+Required property:
+- #reset-cells: must be set to 2
+
Example:
chip: chip-control@ea {
compatible = marvell,berlin2-chip-ctrl;
#clock-cells = 1;
+ #reset-cells = 2;
reg = 0xea 0x400;
clocks = refclk, externaldev 0;
clock-names = refclk, video_ext0;
--
2.1.0
--
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 v7 07/13] usb: chipidea: fix phy handling
The generic platform device for CI drivers is probed by calling
ci_hdrc_probe. This is not the same device as the one for the specific
driver, so the of_node isn't the one we're looking into.
This result in not being able to probe the phys. Since all CI driver are
retrieving their phys in the specific code, this didn't impact any of
them yet.
Fixes it using the right of node pointer, by using dev-parent instead
of dev in phy get functions.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
drivers/usb/chipidea/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index ba0ac2723098..36318c85ad65 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -654,8 +654,8 @@ static int ci_hdrc_probe(struct platform_device *pdev)
} else if (ci-platdata-usb_phy) {
ci-usb_phy = ci-platdata-usb_phy;
} else {
- ci-phy = devm_phy_get(dev, usb-phy);
- ci-usb_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ ci-phy = devm_phy_get(dev-parent, usb-phy);
+ ci-usb_phy = devm_usb_get_phy(dev-parent, USB_PHY_TYPE_USB2);
/* if both generic PHY and USB PHY layers aren't enabled */
if (PTR_ERR(ci-phy) == -ENOSYS
--
2.1.0
--
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 v7 01/13] reset: add the Berlin reset controller driver
Add a reset controller for Marvell Berlin SoCs which is used by the
USB PHYs drivers (for now).
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Acked-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/reset/Makefile | 1 +
drivers/reset/reset-berlin.c | 131 +++
2 files changed, 132 insertions(+)
create mode 100644 drivers/reset/reset-berlin.c
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 60fed3d7820b..157d421f755b 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
+obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
obj-$(CONFIG_ARCH_STI) += sti/
diff --git a/drivers/reset/reset-berlin.c b/drivers/reset/reset-berlin.c
new file mode 100644
index ..f8b48a13cf0b
--- /dev/null
+++ b/drivers/reset/reset-berlin.c
@@ -0,0 +1,131 @@
+/*
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Tenart antoine.ten...@free-electrons.com
+ * Sebastian Hesselbarth sebastian.hesselba...@gmail.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/delay.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/reset-controller.h
+#include linux/slab.h
+#include linux/types.h
+
+#define BERLIN_MAX_RESETS 32
+
+#define to_berlin_reset_priv(p)\
+ container_of((p), struct berlin_reset_priv, rcdev)
+
+struct berlin_reset_priv {
+ void __iomem*base;
+ unsigned intsize;
+ struct reset_controller_dev rcdev;
+};
+
+static int berlin_reset_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct berlin_reset_priv *priv = to_berlin_reset_priv(rcdev);
+ int offset = id 8;
+ int mask = BIT(id 0x1f);
+
+ writel(mask, priv-base + offset);
+
+ /* let the reset be effective */
+ udelay(10);
+
+ return 0;
+}
+
+static struct reset_control_ops berlin_reset_ops = {
+ .reset = berlin_reset_reset,
+};
+
+static int berlin_reset_xlate(struct reset_controller_dev *rcdev,
+ const struct of_phandle_args *reset_spec)
+{
+ struct berlin_reset_priv *priv = to_berlin_reset_priv(rcdev);
+ unsigned offset, bit;
+
+ if (WARN_ON(reset_spec-args_count != rcdev-of_reset_n_cells))
+ return -EINVAL;
+
+ offset = reset_spec-args[0];
+ bit = reset_spec-args[1];
+
+ if (offset = priv-size)
+ return -EINVAL;
+
+ if (bit = BERLIN_MAX_RESETS)
+ return -EINVAL;
+
+ return (offset 8) | bit;
+}
+
+static int __berlin_reset_init(struct device_node *np)
+{
+ struct berlin_reset_priv *priv;
+ struct resource res;
+ resource_size_t size;
+ int ret;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(np, 0, res);
+ if (ret)
+ goto err;
+
+ size = resource_size(res);
+ priv-base = ioremap(res.start, size);
+ if (!priv-base) {
+ ret = -ENOMEM;
+ goto err;
+ }
+ priv-size = size;
+
+ priv-rcdev.owner = THIS_MODULE;
+ priv-rcdev.ops = berlin_reset_ops;
+ priv-rcdev.of_node = np;
+ priv-rcdev.of_reset_n_cells = 2;
+ priv-rcdev.of_xlate = berlin_reset_xlate;
+
+ reset_controller_register(priv-rcdev);
+
+ return 0;
+
+err:
+ kfree(priv);
+ return ret;
+}
+
+static const struct of_device_id berlin_reset_of_match[] __initconst = {
+ { .compatible = marvell,berlin2-chip-ctrl },
+ { .compatible = marvell,berlin2cd-chip-ctrl },
+ { .compatible = marvell,berlin2q-chip-ctrl },
+ { },
+};
+
+static int __init berlin_reset_init(void)
+{
+ struct device_node *np;
+ int ret;
+
+ for_each_matching_node(np, berlin_reset_of_match) {
+ ret = __berlin_reset_init(np);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+arch_initcall(berlin_reset_init);
--
2.1.0
--
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 v7 03/13] ARM: Berlin: select the reset controller
On Friday 14 November 2014 16:25:53 Antoine Tenart wrote: menuconfig ARCH_BERLIN bool Marvell Berlin SoCs if ARCH_MULTI_V7 + select ARCH_HAS_RESET_CONTROLLER select ARCH_REQUIRE_GPIOLIB select ARM_GIC select GENERIC_IRQ_CHIP select DW_APB_ICTL select DW_APB_TIMER_OF select PINCTRL + select RESET_CONTROLLER RESET_CONTROLLER is meant to be user-selectable, don't add a 'select' here, but instead make the driver 'depends on RESET_CONTROLLER'. Arnd -- 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 v7 00/13] ARM: berlin: USB support
This series adds the support for ChipIdea USB2 (ci13xxx) controllers, the USB PHYs of the Marvell Berlin SoCs and also adds a reset controller for these SoCs. The reset controller is used by the PHY driver and shares the existing chip controller node with the clocks and one pin controller. The Marvell Berlin USB controllers are host only on the BG2Q and are compatible with USB ChipIdea. We here add a glue to use the available common functions for this kind of controllers, and add a generic USB2 ChipIdea driver. A PHY driver is also added to control the USB PHY. This series applies on top of the generic PHY support in the USB framework[1]. Patches 1-4 should already have been taken by Sebastian. Changes since v6: - removed ci_hdrc_usb2_dt_probe - fixed a bug in the ChipIdea core for PHY handling - called unconditionally dma_set_mask_and_coherent() Changes since v5: - added a missing header in ci_hdrc_usb2 Changes since v4: - fixed the error handling of ci_hdrc_usb2_probe() Changes since v3: - removed the DMA mask property - moved the clock handling in the common probe function - fixed the documentation for the USB2 ChipIdea USB PHY binding - made sure the reset bit is 0-31 in the reset driver Changes since v2: - moved the PHY driver to the generic PHY framework - changed the compatible to 'chipidea,usb2' - added a property to set the DMA mask in the USB2 CI driver - separated dt specific calls in the CI probing function - rebased on top of the generic PHY support for CI[1] Changes since v1: - made the Berlin CI USB driver a generic one - added support to custom offset for the reset register - added fixed regulators to support supply the VBUS - modified the PHY driver to support the one one the BG2CD as well - documented the reset properties - added bindings for the BG2CD - cosmetic fixes [1] git://git.free-electrons.com:users/antoine-tenart/linux.git usb-phy Antoine Tenart (11): reset: add the Berlin reset controller driver Documentation: bindings: add reset bindings docs for Marvell Berlin SoCs ARM: Berlin: select the reset controller ARM: dts: berlin: add a required reset property in the chip controller node phy: add the Berlin USB PHY driver Documentation: bindings: add doc for the Berlin USB PHY usb: chipidea: fix phy handling usb: chipidea: add a usb2 driver for ci13xxx Documentation: bindings: add doc for the USB2 ChipIdea USB driver ARM: dts: berlin: add BG2Q nodes for USB support ARM: dts: Berlin: enable USB on the BG2Q DMP Sebastian Hesselbarth (2): ARM: dts: berlin: add BG2CD nodes for USB support ARM: dts: berlin: enable USB on the Google Chromecast .../devicetree/bindings/arm/marvell,berlin.txt | 10 + .../devicetree/bindings/phy/berlin-usb-phy.txt | 16 ++ .../devicetree/bindings/usb/ci-hdrc-usb2.txt | 24 +++ arch/arm/boot/dts/berlin2.dtsi | 1 + arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 4 + arch/arm/boot/dts/berlin2cd.dtsi | 37 arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 53 + arch/arm/boot/dts/berlin2q.dtsi| 56 ++ arch/arm/mach-berlin/Kconfig | 2 + drivers/phy/Kconfig| 7 + drivers/phy/Makefile | 1 + drivers/phy/phy-berlin-usb.c | 224 + drivers/reset/Makefile | 1 + drivers/reset/reset-berlin.c | 131 drivers/usb/chipidea/Makefile | 1 + drivers/usb/chipidea/ci_hdrc_usb2.c| 117 +++ drivers/usb/chipidea/core.c| 4 +- 17 files changed, 687 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/berlin-usb-phy.txt create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt create mode 100644 drivers/phy/phy-berlin-usb.c create mode 100644 drivers/reset/reset-berlin.c create mode 100644 drivers/usb/chipidea/ci_hdrc_usb2.c -- 2.1.0 -- 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 v7 03/13] ARM: Berlin: select the reset controller
On 11/14/2014 04:33 PM, Arnd Bergmann wrote: On Friday 14 November 2014 16:25:53 Antoine Tenart wrote: menuconfig ARCH_BERLIN bool Marvell Berlin SoCs if ARCH_MULTI_V7 + select ARCH_HAS_RESET_CONTROLLER select ARCH_REQUIRE_GPIOLIB select ARM_GIC select GENERIC_IRQ_CHIP select DW_APB_ICTL select DW_APB_TIMER_OF select PINCTRL + select RESET_CONTROLLER RESET_CONTROLLER is meant to be user-selectable, don't add a 'select' here, but instead make the driver 'depends on RESET_CONTROLLER'. It already went into arm-soc for v3.19 - ergo, we need an extra patch for removing the current 'select'. Sebastian -- 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 v2] usb: host: xhci: issue 'Reset Endpoint' for !CONTROL EPs from finish_td()
Hi, On Fri, Nov 14, 2014 at 09:04:16AM -0600, Felipe Balbi wrote: On Fri, Nov 14, 2014 at 10:39:15AM +0200, Mathias Nyman wrote: On 13.11.2014 20:46, Felipe Balbi wrote: On Thu, Nov 13, 2014 at 12:31:28PM -0600, Felipe Balbi wrote: Hi, (your mailing is un-wrapping emails, I always end up with pretty long lines and have to rewrap them) On Thu, Nov 13, 2014 at 07:58:28PM +0200, Mathias Nyman wrote: The algorithm described in the DVB tuner bug is clearly wrong, since it doesn't move the dequeue pointer until usb_clear_halt() is called, which is far too late. The right approach is to fix up the dequeue pointer before giving back the URB (so there's no need to save a stopped TD value). Otherwise there will be TDs in the endpoint ring containing stale DMA pointers to buffers that have already been unmapped. Thats right, I cleaned up the patch and removed resetting the endpoint from the .endpoint_reset() callback which was called as a result of usb_clear_halt(). Now we queue a reset endpoint and set dequeue pointer before giving back the URB. I still set a stopped td value, but could as well just pass it as function parameter. Actually I'll do that in later cleanup patch. Latest version of the patch is now in my tree in a reset-rework-v2 branch, with fixes comments and removed The brach includes the other dorbell ringing patch as well. both are on top of 3.18-rc4. I still need to test it before sending it further, the tree is here: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git reset-rework-v2 I'll test this one. for both commits on that branch, you can add my: Tested-by: Felipe Balbi ba...@ti.com But please also add proper fixes and Cc: stable, so older kernels can use those. Thanks a lot for testing again. I'll CC stable and add your tested-by, but I still don't know exactly which commit it Fixes. This might have been there since the early days of xhci. git blame usually helps. Just look for code which was differentiating COMP_STALL and treating it differently. I know that at least v3.14 has the problem. Here you go: Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.) Cc: sta...@vger.kernel.org # v2.6.33+ Please make sure to send these patches ASAP otherwise they will not hit v3.18-final, it's getting pretty late. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/6] usb: chipidea: add a core function to setup ci_hdrc_platform_data
Peter, On Fri, Nov 14, 2014 at 09:16:55AM +0800, Peter Chen wrote: Ok, Antoine, I find this patch set may not have many benefits due to below reasons: - There is already function ci_get_platdata to do the similar things - If the PHY can't get from the DT, it will use devm_phy_get or devm_usb_get_phy to get, this code has already in core. I am apologized that I wanted you to do a patch for moving get PHY operation to core, it doesn't have many benefits currently - For non-dt user, the phy get function has already in core like I said above. - For dt generic phy user, it uses of_phy_get, the second parameter con_id may be different for platforms. - For dt usb phy, it uses devm_usb_get_phy_by_phandle, the second parameters phandle may be different for platforms. Ok. So, please rebase my next tree which your generic phy patch set has already in, and send your generic usb2 chipidea patch base on it. I just rebased my usb2 ci generic driver series and sent it to you and to the mailing lists. Since there is not reason from now to delay it, I expect it to be merged soon. I wouldn't want to miss yet another release. 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 v3] usb: dwc2: add bus suspend/resume for dwc2
On Thu, 13 Nov 2014, Julius Werner wrote: Another thing might be that the port connect interrupt does not correctly resume the root hub. I don't really know many details about how that works, and it seems pretty complicated. But I can see that all other HCDs seem to call usb_hcd_resume_root_hub() from their interrupt handlers, which we don't. There's also a That's how a root hub sends a wakeup request to the kernel. The controller issues an interrupt, and when the HCD's interrupt handler sees that the root hub is suspended, it calls usb_hcd_resume_root_hub() instead of trying to query the hardware (because in general you _can't_ query the hardware while it's in a low-power state). usb_hcd_start_port_resume() in EHCI which I'm not familiar with, that seems to have been added recently. usb_hcd_start_port_resume() and usb_hcd_end_port_resume() were added in order to fix a race. We want to avoid suspending a root hub if a downstream suspended device is currently being resumed. The HCD is supposed to call these two routines when it begins and ends resume signalling on any of its ports. This will prevent the core from suspending the root hub while the port resume is in progress. And finally, it seems that all normal host controllers (UHCI/OHCI/EHCI/XHCI) now do the usb_hcd-uses_new_polling thing (where you're supposed to call hcd_poll_rh_status() from the HCD code)... the old polling code still seems to be in place, but without any relevant driver using I wouldn't be so sure if it's still functional. It is functional. The difference between the old and new polling schemes isn't all that big. In the old scheme, the core polls for root hub status changes every 250 ms. With the new scheme, the core doesn't poll -- it relies on the HCD to call usb_hcd_poll_rh_status() whenever there's a status-change interrupt. There's also a flag the HCD can set to ask for polling even if it uses the new scheme. This helps in situations where the root-hub status-change interrupts aren't reliable (for example, if they are edge-triggered rather than level-triggered). +Alan who should know HCD/core interactions much better and might have some ideas what the DWC2 driver is still missing right now. I know essentially zero about the DWC2 driver. But I'm happy to help by explaining how the core mechanisms are intended to be used. 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: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
On Fri, 2014-11-14 at 11:56 +0100, Sedat Dilek wrote: On Wed, Nov 12, 2014 at 2:21 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams d...@redhat.com wrote: On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote: Hi, I wanted to understand what is going on the kernel-side when connecting to the Internet via a Huawei E173 USB web-stick (3rd Generation: UMTS / HSPA). Especially the correlation between the diverse USB/NET kernel-drivers and how the networking is setup. [ Sitting in front of a foreign Windows machine ] [ CC Aleksander ] Hi Dan, sorry for the late (and short) response. AFAICS you have given a skeleton for a usb-wwan-networking documentation :-). Personally, I would like to take into account some kernel-config options and some more things. I started with documenting... I have still some difficulties in understanding USB WWAN Networking. So, this is what I revealed... # USB: HUAWEI E173 3G/UMTS/HSPA INTERNET STICK ### USB-NETWORKING AND WWAN SETUP CONFIG_USB_USBNET=m--- usb networking CONFIG_USB_NET_CDCETHER=m --- usb-wwan (net) configuration CONFIG_USB_SERIAL_WWAN=m --- usb-wwan (serial) configuration CONFIG_USB_SERIAL_OPTION=m --- usb-serial driver called option Most WWAN devices actually require option, because most WWAN devices have serial ports (even if they aren't used for PPP), and 'option' is the driver that handles this. The 'option' name is historic, but the driver should really be called something like 'wwan-serial-generic' or something like that. You're missing a few other net type drivers: CONFIG_USB_NET_QMI_WWAN = Qualcomm QMI capable devices (net) CONFIG_USB_HSO = Option High-Speed (net) devices CONFIG_USB_NET_KALMIA = Samsung LTE dongle (net) CONFIG_USB_SIERRA_NET = Sierra devices (net) CONFIG_USB_NET_CDC_NCM = Ericsson F5321 (?) and some others (net) CONFIG_USB_NET_HUAWEI_CDC_NCM = Huawei NCM variant (net) CONFIG_USB_VL600 = LG VL600 / AD600 LTE device (net) CONFIG_USB_NET_CDC_MBIM = MBIM (net) devices (popular currently) and maybe even: CONFIG_USB_CDC_PHONET = Nokia phones and USB sticks, not net but proprietary protocol that handles both data/control channels For the serial side: CONFIG_USB_ACM = generic serial devices, many are *not* WWAN but many WWAN devices use this class/driver CONFIG_USB_SERIAL_QCAUX = Various Qualcomm-based devices' auxiliary ports (DIAG, GPS, etc) CONFIG_USB_SERIAL_QUALCOMM = Firmware loading and auxiliary ports on various Qualcomm Gobi devices CONFIG_USB_SERIAL_SIERRAWIRELESS = Older Sierra device serial ports for PPP/control and auxiliary functions WWAN devices basically mix match these drivers depending on what interfaces the firmware exposes. For example, some Sierra devices may require both CONFIG_USB_SERIAL_SIERRAWIRELESS and CONFIG_USB_SIERRA_NET. Older Sierra devices may use only CONFIG_USB_SERIAL_SIERRAWIRELESS and do not provide a 'net' port at all, but use only PPP. Sierra devices based on Icera chips may use CONFIG_USB_ACM and either CONFIG_USB_SIERRA_NET or CONFIG_USB_NET_CDCETHER. Some Huawei devices may use CONFIG_USB_NET_CDCETHER and either CONFIG_USB_SERIAL_OPTION or CONFIG_USB_ACM. Other Huawei devices may use CONFIG_USB_NET_QMI_WWAN and CONFIG_USB_SERIAL_OPTION. Even other Huawei devices may be Qualcomm Gobi type and use CONFIG_USB_NET_QMI_WWAN and CONFIG_USB_SERIAL_QUALCOMM. So you see it really depends on exactly how the firmware is implemented. But in general, devices still fall into the categories I originally listed, and the drivers fall into specific categories too (net, serial, proprietary), and devices mix match drivers to achieve the end result. Dan ### PPP OPTIONS CONFIG_PPP=y CONFIG_PPP_BSDCOMP=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_FILTER=y CONFIG_PPP_MULTILINK=y CONFIG_PPP_ASYNC=m Beyond the PPP options, I wanted to understand what CONFIG_USB_NET_CDCETHER does and why I need it. Can someone help? Thanks. - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/Kconfig#n189 P.S.: cdc_ether Kconfig option and checking my logs From [1]... ... config USB_NET_CDCETHER tristate CDC Ethernet support (smart devices such as cable modems) depends on USB_USBNET default y help This option supports devices conforming to the Communication Device Class (CDC) Ethernet Control Model, a specification that's easy to implement in device firmware. The CDC specifications are available from http://www.usb.org/. CDC Ethernet is an implementation option for DOCSIS cable modems that support USB connectivity, used for non-Microsoft USB hosts. The Linux-USB CDC Ethernet Gadget driver is an open implementation. This driver should work with at least the following devices: * Dell Wireless 5530 HSPA * Ericsson PipeRider (all variants) * Ericsson Mobile Broadband Module (all variants) * Motorola
Re: [RFC/PATCH v2] usb: host: xhci: issue 'Reset Endpoint' for !CONTROL EPs from finish_td()
On 14.11.2014 17:49, Felipe Balbi wrote: Hi, On Fri, Nov 14, 2014 at 09:04:16AM -0600, Felipe Balbi wrote: On Fri, Nov 14, 2014 at 10:39:15AM +0200, Mathias Nyman wrote: On 13.11.2014 20:46, Felipe Balbi wrote: On Thu, Nov 13, 2014 at 12:31:28PM -0600, Felipe Balbi wrote: Hi, (your mailing is un-wrapping emails, I always end up with pretty long lines and have to rewrap them) On Thu, Nov 13, 2014 at 07:58:28PM +0200, Mathias Nyman wrote: The algorithm described in the DVB tuner bug is clearly wrong, since it doesn't move the dequeue pointer until usb_clear_halt() is called, which is far too late. The right approach is to fix up the dequeue pointer before giving back the URB (so there's no need to save a stopped TD value). Otherwise there will be TDs in the endpoint ring containing stale DMA pointers to buffers that have already been unmapped. Thats right, I cleaned up the patch and removed resetting the endpoint from the .endpoint_reset() callback which was called as a result of usb_clear_halt(). Now we queue a reset endpoint and set dequeue pointer before giving back the URB. I still set a stopped td value, but could as well just pass it as function parameter. Actually I'll do that in later cleanup patch. Latest version of the patch is now in my tree in a reset-rework-v2 branch, with fixes comments and removed The brach includes the other dorbell ringing patch as well. both are on top of 3.18-rc4. I still need to test it before sending it further, the tree is here: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git reset-rework-v2 I'll test this one. for both commits on that branch, you can add my: Tested-by: Felipe Balbi ba...@ti.com But please also add proper fixes and Cc: stable, so older kernels can use those. Thanks a lot for testing again. I'll CC stable and add your tested-by, but I still don't know exactly which commit it Fixes. This might have been there since the early days of xhci. git blame usually helps. Just look for code which was differentiating COMP_STALL and treating it differently. I know that at least v3.14 has the problem. Here you go: Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.) Cc: sta...@vger.kernel.org # v2.6.33+ Please make sure to send these patches ASAP otherwise they will not hit v3.18-final, it's getting pretty late. Amazing, was still struggling trying to figure out which one it was. It goes back a long way, I'll send the patches right away. I btw now got a device I should be able to load gzero on, once I figure out how to flash it. Thanks again -Mathias -- 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
[no subject]
unsubscribe linux-usb angel...@gmail.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: [RFC/PATCH v2] usb: host: xhci: issue 'Reset Endpoint' for !CONTROL EPs from finish_td()
On Fri, Nov 14, 2014 at 06:37:33PM +0200, Mathias Nyman wrote: On 14.11.2014 17:49, Felipe Balbi wrote: Hi, On Fri, Nov 14, 2014 at 09:04:16AM -0600, Felipe Balbi wrote: On Fri, Nov 14, 2014 at 10:39:15AM +0200, Mathias Nyman wrote: On 13.11.2014 20:46, Felipe Balbi wrote: On Thu, Nov 13, 2014 at 12:31:28PM -0600, Felipe Balbi wrote: Hi, (your mailing is un-wrapping emails, I always end up with pretty long lines and have to rewrap them) On Thu, Nov 13, 2014 at 07:58:28PM +0200, Mathias Nyman wrote: The algorithm described in the DVB tuner bug is clearly wrong, since it doesn't move the dequeue pointer until usb_clear_halt() is called, which is far too late. The right approach is to fix up the dequeue pointer before giving back the URB (so there's no need to save a stopped TD value). Otherwise there will be TDs in the endpoint ring containing stale DMA pointers to buffers that have already been unmapped. Thats right, I cleaned up the patch and removed resetting the endpoint from the .endpoint_reset() callback which was called as a result of usb_clear_halt(). Now we queue a reset endpoint and set dequeue pointer before giving back the URB. I still set a stopped td value, but could as well just pass it as function parameter. Actually I'll do that in later cleanup patch. Latest version of the patch is now in my tree in a reset-rework-v2 branch, with fixes comments and removed The brach includes the other dorbell ringing patch as well. both are on top of 3.18-rc4. I still need to test it before sending it further, the tree is here: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git reset-rework-v2 I'll test this one. for both commits on that branch, you can add my: Tested-by: Felipe Balbi ba...@ti.com But please also add proper fixes and Cc: stable, so older kernels can use those. Thanks a lot for testing again. I'll CC stable and add your tested-by, but I still don't know exactly which commit it Fixes. This might have been there since the early days of xhci. git blame usually helps. Just look for code which was differentiating COMP_STALL and treating it differently. I know that at least v3.14 has the problem. Here you go: Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.) Cc: sta...@vger.kernel.org # v2.6.33+ Please make sure to send these patches ASAP otherwise they will not hit v3.18-final, it's getting pretty late. Amazing, was still struggling trying to figure out which one it was. It goes back a long way, I'll send the patches right away. cool, thanks :-) I btw now got a device I should be able to load gzero on, once I figure out how to flash it. let me know if you need help with getting dwc3 running (I'm assuming you have one of the baytrail skus with peripheral mode support). -- balbi signature.asc Description: Digital signature
Re: Bug 88151 - PCI device intel xhci with 64-bit bar address can NOT work on x86_32 PAE kernel
On Fri, Nov 14, 2014 at 01:20:41PM +0800, Aaron Ma wrote: x86_32 kernel config This is associated with [Bug 88131] The bootlog is already in Bug 88131. You aren't saying where that bug is, please provide the full details in an email, this doesn't help us very much :( 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
[PATCH 1/4] xhci: don't start a halted endpoint before its new dequeue is set
A halted endpoint ring must first be reset, then move the ring
dequeue pointer past the problematic TRB. If we start the ring too
early after reset, but before moving the dequeue pointer we
will end up executing the same problematic TRB again.
As we always issue a set transfer dequeue command after a reset
endpoint command we can skip starting endpoint rings at reset endpoint
command completion.
Without this fix we end up trying to handle the same faulty TD for
contol endpoints. causing timeout, and failing testusb ctrl_out write
tests.
Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.)
Cc: sta...@vger.kernel.org # v2.6.33+
Tested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-ring.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index bc6fcbc..d6646db 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1069,7 +1069,6 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd
*xhci, int slot_id,
} else {
/* Clear our internal halted state and restart the ring(s) */
xhci-devs[slot_id]-eps[ep_index].ep_state = ~EP_HALTED;
- ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
}
}
--
1.8.3.2
--
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 0/4] xhci fixes for 3.18-rc
Hi Greg These patches for usb-linus solve two xhci issues, fixing xhci halted endpoint handling to now follow the specification, and pass testusb control message tests The other one reverts a faulty xhci controller wakeup solution, and writes a new proper solution. Lu Baolu (2): Revert xhci: clear root port wake on bits if controller isn't wake-up capable usb: xhci: rework root port wake bits if controller isn't allowed to wakeup Mathias Nyman (2): xhci: don't start a halted endpoint before its new dequeue is set xhci: Reset a halted endpoint immediately when we encounter a stall. drivers/usb/host/xhci-hub.c | 5 +- drivers/usb/host/xhci-pci.c | 2 +- drivers/usb/host/xhci-plat.c | 10 +++- drivers/usb/host/xhci-ring.c | 41 - drivers/usb/host/xhci.c | 107 ++- drivers/usb/host/xhci.h | 2 +- 6 files changed, 78 insertions(+), 89 deletions(-) -- 1.8.3.2 -- 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 4/4] usb: xhci: rework root port wake bits if controller isn't allowed to wakeup
From: Lu Baolu baolu...@linux.intel.com
When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
platforms may generate spurious wakeup, even if PCI PME# is disabled.
The initial commit ff8cbf250b44 (xhci: clear root port wake on bits),
which also got into stable, turned out to not work correctly and had to
be reverted, and is now rewritten.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Suggested-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Alan Stern st...@rowland.harvard.edu
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-pci.c | 2 +-
drivers/usb/host/xhci-plat.c | 10 +-
drivers/usb/host/xhci.c | 42 +-
drivers/usb/host/xhci.h | 2 +-
4 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 9a69b1f..142b601 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -281,7 +281,7 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool
do_wakeup)
if (xhci-quirks XHCI_COMP_MODE_QUIRK)
pdev-no_d3cold = true;
- return xhci_suspend(xhci);
+ return xhci_suspend(xhci, do_wakeup);
}
static int xhci_pci_resume(struct usb_hcd *hcd, bool hibernated)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3d78b0c..646300c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -204,7 +204,15 @@ static int xhci_plat_suspend(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
- return xhci_suspend(xhci);
+ /*
+* xhci_suspend() needs `do_wakeup` to know whether host is allowed
+* to do wakeup during suspend. Since xhci_plat_suspend is currently
+* only designed for system suspend, device_may_wakeup() is enough
+* to dertermine whether host is allowed to do wakeup. Need to
+* reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
+* also applies to runtime suspend.
+*/
+ return xhci_suspend(xhci, device_may_wakeup(dev));
}
static int xhci_plat_resume(struct device *dev)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4d0d240..033b46c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -35,6 +35,8 @@
#define DRIVER_AUTHOR Sarah Sharp
#define DRIVER_DESC 'eXtensible' Host Controller (xHC) Driver
+#definePORT_WAKE_BITS (PORT_WKOC_E | PORT_WKDISC_E | PORT_WKCONN_E)
+
/* Some 0.95 hardware can't handle the chain bit on a Link TRB being cleared */
static int link_quirk;
module_param(link_quirk, int, S_IRUGO | S_IWUSR);
@@ -851,13 +853,47 @@ static void xhci_clear_command_ring(struct xhci_hcd *xhci)
xhci_set_cmd_ring_deq(xhci);
}
+static void xhci_disable_port_wake_on_bits(struct xhci_hcd *xhci)
+{
+ int port_index;
+ __le32 __iomem **port_array;
+ unsigned long flags;
+ u32 t1, t2;
+
+ spin_lock_irqsave(xhci-lock, flags);
+
+ /* disble usb3 ports Wake bits*/
+ port_index = xhci-num_usb3_ports;
+ port_array = xhci-usb3_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t1 = xhci_port_state_to_neutral(t1);
+ t2 = t1 ~PORT_WAKE_BITS;
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ /* disble usb2 ports Wake bits*/
+ port_index = xhci-num_usb2_ports;
+ port_array = xhci-usb2_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t1 = xhci_port_state_to_neutral(t1);
+ t2 = t1 ~PORT_WAKE_BITS;
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ spin_unlock_irqrestore(xhci-lock, flags);
+}
+
/*
* Stop HC (not bus-specific)
*
* This is called when the machine transition into S3/S4 mode.
*
*/
-int xhci_suspend(struct xhci_hcd *xhci)
+int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
{
int rc = 0;
unsigned intdelay = XHCI_MAX_HALT_USEC;
@@ -868,6 +904,10 @@ int xhci_suspend(struct xhci_hcd *xhci)
xhci-shared_hcd-state != HC_STATE_SUSPENDED)
return -EINVAL;
+ /* Clear root port wake on bits if wakeup not allowed. */
+ if (!do_wakeup)
+ xhci_disable_port_wake_on_bits(xhci);
+
/* Don't poll the roothubs on bus suspend. */
xhci_dbg(xhci, %s: stopping port polling.\n, __func__);
clear_bit(HCD_FLAG_POLL_RH, hcd-flags);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index df76d64..d745715
[PATCH 2/4] xhci: Reset a halted endpoint immediately when we encounter a stall.
If a device is halted and reuturns a STALL, then the halted endpoint
needs to be cleared both on the host and device side. The host
side halt is cleared by issueing a xhci reset endpoint command. The device side
is cleared with a ClearFeature(ENDPOINT_HALT) request, which should
be issued by the device driver if a URB reruen -EPIPE.
Previously we cleared the host side halt after the device side was cleared.
To make sure the host side halt is cleared in time we want to issue the
reset endpoint command immedialtely when a STALL status is encountered.
Otherwise we end up not following the specs and not returning -EPIPE
several times in a row when trying to transfer data to a halted endpoint.
Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.)
Cc: sta...@vger.kernel.org # v2.6.33+
Tested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-ring.c | 40 +++
drivers/usb/host/xhci.c | 65 ++--
2 files changed, 25 insertions(+), 80 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d6646db..d4125fb 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1822,22 +1822,13 @@ static int finish_td(struct xhci_hcd *xhci, struct
xhci_td *td,
ep-stopped_td = td;
return 0;
} else {
- if (trb_comp_code == COMP_STALL) {
- /* The transfer is completed from the driver's
-* perspective, but we need to issue a set dequeue
-* command for this stalled endpoint to move the dequeue
-* pointer past the TD. We can't do that here because
-* the halt condition must be cleared first. Let the
-* USB class driver clear the stall later.
-*/
- ep-stopped_td = td;
- ep-stopped_stream = ep_ring-stream_id;
- } else if (xhci_requires_manual_halt_cleanup(xhci,
- ep_ctx, trb_comp_code)) {
- /* Other types of errors halt the endpoint, but the
-* class driver doesn't call usb_reset_endpoint() unless
-* the error is -EPIPE. Clear the halted status in the
-* xHCI hardware manually.
+ if (trb_comp_code == COMP_STALL ||
+ xhci_requires_manual_halt_cleanup(xhci, ep_ctx,
+ trb_comp_code)) {
+ /* Issue a reset endpoint command to clear the host side
+* halt, followed by a set dequeue command to move the
+* dequeue pointer past the TD.
+* The class driver clears the device side halt later.
*/
xhci_cleanup_halted_endpoint(xhci,
slot_id, ep_index, ep_ring-stream_id,
@@ -1957,9 +1948,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct
xhci_td *td,
else
td-urb-actual_length = 0;
- xhci_cleanup_halted_endpoint(xhci,
- slot_id, ep_index, 0, td, event_trb);
- return finish_td(xhci, td, event_trb, event, ep, status, true);
+ return finish_td(xhci, td, event_trb, event, ep, status, false);
}
/*
* Did we transfer any data, despite the errors that might have
@@ -2518,17 +2507,8 @@ cleanup:
if (ret) {
urb = td-urb;
urb_priv = urb-hcpriv;
- /* Leave the TD around for the reset endpoint function
-* to use(but only if it's not a control endpoint,
-* since we already queued the Set TR dequeue pointer
-* command for stalled control endpoints).
-*/
- if (usb_endpoint_xfer_control(urb-ep-desc) ||
- (trb_comp_code != COMP_STALL
- trb_comp_code != COMP_BABBLE))
- xhci_urb_free_priv(xhci, urb_priv);
- else
- kfree(urb_priv);
+
+ xhci_urb_free_priv(xhci, urb_priv);
usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb-dev-bus),
urb);
if ((urb-actual_length != urb-transfer_buffer_length
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2a5d45b..4d0d240 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2912,68 +2912,33 @@ void xhci_cleanup_stalled_ring(struct xhci_hcd *xhci,
}
}
-/* Deal with
[PATCH 3/4] Revert xhci: clear root port wake on bits if controller isn't wake-up capable
From: Lu Baolu baolu...@linux.intel.com
commit ff8cbf250b44 (xhci: clear root port wake on bits if controller isn't)
can cause device detection error if runtime PM is enabled, and S3 wake
is disabled. Revert it.
https://bugzilla.kernel.org/show_bug.cgi?id=85701
This commit got into stable and should be reverted from there as well.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Reported-by: Dmitry Nezhevenko d...@inhex.net
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 696160d..388cfd8 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -22,7 +22,6 @@
#include linux/slab.h
-#include linux/device.h
#include asm/unaligned.h
#include xhci.h
@@ -1149,9 +1148,7 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
* is enabled, so also enable remote wake here.
*/
- if (hcd-self.root_hub-do_remote_wakeup
-device_may_wakeup(hcd-self.controller)) {
-
+ if (hcd-self.root_hub-do_remote_wakeup) {
if (t1 PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 = ~PORT_WKCONN_E;
--
1.8.3.2
--
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 v7 03/13] ARM: Berlin: select the reset controller
Sebastian, On Fri, Nov 14, 2014 at 04:36:50PM +0100, Sebastian Hesselbarth wrote: On 11/14/2014 04:33 PM, Arnd Bergmann wrote: On Friday 14 November 2014 16:25:53 Antoine Tenart wrote: menuconfig ARCH_BERLIN bool Marvell Berlin SoCs if ARCH_MULTI_V7 + select ARCH_HAS_RESET_CONTROLLER select ARCH_REQUIRE_GPIOLIB select ARM_GIC select GENERIC_IRQ_CHIP select DW_APB_ICTL select DW_APB_TIMER_OF select PINCTRL + select RESET_CONTROLLER RESET_CONTROLLER is meant to be user-selectable, don't add a 'select' here, but instead make the driver 'depends on RESET_CONTROLLER'. It already went into arm-soc for v3.19 - ergo, we need an extra patch for removing the current 'select'. Do you want me to send the extra patch fixing this issue? 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 1/4] xhci: don't start a halted endpoint before its new dequeue is set
On Fri, Nov 14, 2014 at 07:23:49PM +0200, Mathias Nyman wrote:
A halted endpoint ring must first be reset, then move the ring
dequeue pointer past the problematic TRB. If we start the ring too
early after reset, but before moving the dequeue pointer we
will end up executing the same problematic TRB again.
As we always issue a set transfer dequeue command after a reset
endpoint command we can skip starting endpoint rings at reset endpoint
command completion.
Without this fix we end up trying to handle the same faulty TD for
contol endpoints. causing timeout, and failing testusb ctrl_out write
tests.
Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.)
Cc: sta...@vger.kernel.org # v2.6.33+
this one is something else, here you go:
Fixes: e9df17e (USB: xhci: Correct assumptions about number of rings per
endpoint.)
Cc: sta...@vger.kernel.org #v2.6.35
Tested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-ring.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index bc6fcbc..d6646db 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1069,7 +1069,6 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd
*xhci, int slot_id,
} else {
/* Clear our internal halted state and restart the ring(s) */
xhci-devs[slot_id]-eps[ep_index].ep_state = ~EP_HALTED;
- ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
}
}
--
1.8.3.2
--
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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/4] Revert xhci: clear root port wake on bits if controller isn't wake-up capable
On Fri, Nov 14, 2014 at 07:23:51PM +0200, Mathias Nyman wrote:
From: Lu Baolu baolu...@linux.intel.com
commit ff8cbf250b44 (xhci: clear root port wake on bits if controller isn't)
can cause device detection error if runtime PM is enabled, and S3 wake
is disabled. Revert it.
https://bugzilla.kernel.org/show_bug.cgi?id=85701
This commit got into stable and should be reverted from there as well.
how far back ? Aparently 2.6.37+
Cc: stable sta...@vger.kernel.org
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Reported-by: Dmitry Nezhevenko d...@inhex.net
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 696160d..388cfd8 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -22,7 +22,6 @@
#include linux/slab.h
-#include linux/device.h
#include asm/unaligned.h
#include xhci.h
@@ -1149,9 +1148,7 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
* is enabled, so also enable remote wake here.
*/
- if (hcd-self.root_hub-do_remote_wakeup
- device_may_wakeup(hcd-self.controller)) {
-
+ if (hcd-self.root_hub-do_remote_wakeup) {
if (t1 PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 = ~PORT_WKCONN_E;
--
1.8.3.2
--
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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 4/4] usb: xhci: rework root port wake bits if controller isn't allowed to wakeup
On Fri, Nov 14, 2014 at 07:23:52PM +0200, Mathias Nyman wrote:
From: Lu Baolu baolu...@linux.intel.com
When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
platforms may generate spurious wakeup, even if PCI PME# is disabled.
The initial commit ff8cbf250b44 (xhci: clear root port wake on bits),
which also got into stable, turned out to not work correctly and had to
be reverted, and is now rewritten.
Cc: stable sta...@vger.kernel.org
how far back ? Apparently, also, 2.6.37+
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Suggested-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Alan Stern st...@rowland.harvard.edu
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-pci.c | 2 +-
drivers/usb/host/xhci-plat.c | 10 +-
drivers/usb/host/xhci.c | 42 +-
drivers/usb/host/xhci.h | 2 +-
4 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 9a69b1f..142b601 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -281,7 +281,7 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool
do_wakeup)
if (xhci-quirks XHCI_COMP_MODE_QUIRK)
pdev-no_d3cold = true;
- return xhci_suspend(xhci);
+ return xhci_suspend(xhci, do_wakeup);
}
static int xhci_pci_resume(struct usb_hcd *hcd, bool hibernated)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3d78b0c..646300c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -204,7 +204,15 @@ static int xhci_plat_suspend(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
- return xhci_suspend(xhci);
+ /*
+ * xhci_suspend() needs `do_wakeup` to know whether host is allowed
+ * to do wakeup during suspend. Since xhci_plat_suspend is currently
+ * only designed for system suspend, device_may_wakeup() is enough
+ * to dertermine whether host is allowed to do wakeup. Need to
+ * reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
+ * also applies to runtime suspend.
+ */
+ return xhci_suspend(xhci, device_may_wakeup(dev));
}
static int xhci_plat_resume(struct device *dev)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4d0d240..033b46c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -35,6 +35,8 @@
#define DRIVER_AUTHOR Sarah Sharp
#define DRIVER_DESC 'eXtensible' Host Controller (xHC) Driver
+#define PORT_WAKE_BITS (PORT_WKOC_E | PORT_WKDISC_E | PORT_WKCONN_E)
+
/* Some 0.95 hardware can't handle the chain bit on a Link TRB being cleared
*/
static int link_quirk;
module_param(link_quirk, int, S_IRUGO | S_IWUSR);
@@ -851,13 +853,47 @@ static void xhci_clear_command_ring(struct xhci_hcd
*xhci)
xhci_set_cmd_ring_deq(xhci);
}
+static void xhci_disable_port_wake_on_bits(struct xhci_hcd *xhci)
+{
+ int port_index;
+ __le32 __iomem **port_array;
+ unsigned long flags;
+ u32 t1, t2;
+
+ spin_lock_irqsave(xhci-lock, flags);
+
+ /* disble usb3 ports Wake bits*/
+ port_index = xhci-num_usb3_ports;
+ port_array = xhci-usb3_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t1 = xhci_port_state_to_neutral(t1);
+ t2 = t1 ~PORT_WAKE_BITS;
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ /* disble usb2 ports Wake bits*/
+ port_index = xhci-num_usb2_ports;
+ port_array = xhci-usb2_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t1 = xhci_port_state_to_neutral(t1);
+ t2 = t1 ~PORT_WAKE_BITS;
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ spin_unlock_irqrestore(xhci-lock, flags);
+}
+
/*
* Stop HC (not bus-specific)
*
* This is called when the machine transition into S3/S4 mode.
*
*/
-int xhci_suspend(struct xhci_hcd *xhci)
+int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
{
int rc = 0;
unsigned intdelay = XHCI_MAX_HALT_USEC;
@@ -868,6 +904,10 @@ int xhci_suspend(struct xhci_hcd *xhci)
xhci-shared_hcd-state != HC_STATE_SUSPENDED)
return -EINVAL;
+ /* Clear root port wake on bits if wakeup not allowed. */
+ if (!do_wakeup)
+ xhci_disable_port_wake_on_bits(xhci);
+
/* Don't poll the roothubs on bus suspend. */
xhci_dbg(xhci, %s: stopping port polling.\n, __func__);
Re: [PATCH 3/3] USB: host: Introduce flag to enable use of 64-bit dma_mask for ehci-platform
On 11/14/2014 07:23 AM, Alan Stern wrote: On Fri, 14 Nov 2014, Andreas Herrmann wrote: On Thu, Nov 13, 2014 at 08:44:17PM -0800, Florian Fainelli wrote: 2014-11-13 13:36 GMT-08:00 Andreas Herrmann andreas.herrm...@caviumnetworks.com: ehci-octeon driver used a 64-bit dma_mask. With removal of ehci-octeon and usage of ehci-platform ehci dma_mask is now limited to 32 bits (coerced in ehci_platform_probe). Provide a flag in ehci platform data to allow use of 64 bits for dma_mask. Why not just allow enforcing an arbitrary DMA mask? I thought about that but as it's currently just 32 or 64 bits a flag is sufficient. (At the moment I am not aware that other ehci-platform devices would require something else.) I'll change the flag to a mask if desired. Alan, what's your opinion about this? I'm not aware of any devices that need a different DMA mask either. Florian, do you have any reason for thinking such a thing might come along? Like Andreas, I don't mind making it more general if there's a good reason to do so. I don't have a specific platform I am thinking about, just that while we are there allowing a dma_mask to be specified, I would rather pass an u64 that covers all possible cases. Thanks! -- Florian -- 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 1/4] xhci: don't start a halted endpoint before its new dequeue is set
On 14.11.2014 19:29, Felipe Balbi wrote: On Fri, Nov 14, 2014 at 07:23:49PM +0200, Mathias Nyman wrote: A halted endpoint ring must first be reset, then move the ring dequeue pointer past the problematic TRB. If we start the ring too early after reset, but before moving the dequeue pointer we will end up executing the same problematic TRB again. As we always issue a set transfer dequeue command after a reset endpoint command we can skip starting endpoint rings at reset endpoint command completion. Without this fix we end up trying to handle the same faulty TD for contol endpoints. causing timeout, and failing testusb ctrl_out write tests. Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.) Cc: sta...@vger.kernel.org # v2.6.33+ this one is something else, here you go: Fixes: e9df17e (USB: xhci: Correct assumptions about number of rings per endpoint.) Cc: sta...@vger.kernel.org #v2.6.35 ah, ok, I'll resend -Mathias -- 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 3/4] Revert xhci: clear root port wake on bits if controller isn't wake-up capable
On 14.11.2014 19:30, Felipe Balbi wrote: On Fri, Nov 14, 2014 at 07:23:51PM +0200, Mathias Nyman wrote: From: Lu Baolu baolu...@linux.intel.com commit ff8cbf250b44 (xhci: clear root port wake on bits if controller isn't) can cause device detection error if runtime PM is enabled, and S3 wake is disabled. Revert it. https://bugzilla.kernel.org/show_bug.cgi?id=85701 This commit got into stable and should be reverted from there as well. how far back ? Aparently 2.6.37+ That's how far the original patch says it should go yes, but I only found stable mails from 3.11.20.14, 3.2.62 3.13.11.6 -Mathias -- 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 3/4] Revert xhci: clear root port wake on bits if controller isn't wake-up capable
On Fri, Nov 14, 2014 at 07:40:01PM +0200, Mathias Nyman wrote: On 14.11.2014 19:30, Felipe Balbi wrote: On Fri, Nov 14, 2014 at 07:23:51PM +0200, Mathias Nyman wrote: From: Lu Baolu baolu...@linux.intel.com commit ff8cbf250b44 (xhci: clear root port wake on bits if controller isn't) can cause device detection error if runtime PM is enabled, and S3 wake is disabled. Revert it. https://bugzilla.kernel.org/show_bug.cgi?id=85701 This commit got into stable and should be reverted from there as well. how far back ? Aparently 2.6.37+ That's how far the original patch says it should go yes, but I only found stable mails from 3.11.20.14, 3.2.62 3.13.11.6 ok, so v3.2+ sounds like the right approach. -- balbi signature.asc Description: Digital signature
[PATCHv2 1/4] xhci: don't start a halted endpoint before its new dequeue is set
A halted endpoint ring must first be reset, then move the ring
dequeue pointer past the problematic TRB. If we start the ring too
early after reset, but before moving the dequeue pointer we
will end up executing the same problematic TRB again.
As we always issue a set transfer dequeue command after a reset
endpoint command we can skip starting endpoint rings at reset endpoint
command completion.
Without this fix we end up trying to handle the same faulty TD for
contol endpoints. causing timeout, and failing testusb ctrl_out write
tests.
Fixes: e9df17e (USB: xhci: Correct assumptions about number of rings per
endpoint.)
Cc: sta...@vger.kernel.org #v2.6.35
Tested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-ring.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index bc6fcbc..d6646db 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1069,7 +1069,6 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd
*xhci, int slot_id,
} else {
/* Clear our internal halted state and restart the ring(s) */
xhci-devs[slot_id]-eps[ep_index].ep_state = ~EP_HALTED;
- ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
}
}
--
1.8.3.2
--
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
[PATCHv2 2/4] xhci: Reset a halted endpoint immediately when we encounter a stall.
If a device is halted and reuturns a STALL, then the halted endpoint
needs to be cleared both on the host and device side. The host
side halt is cleared by issueing a xhci reset endpoint command. The device side
is cleared with a ClearFeature(ENDPOINT_HALT) request, which should
be issued by the device driver if a URB reruen -EPIPE.
Previously we cleared the host side halt after the device side was cleared.
To make sure the host side halt is cleared in time we want to issue the
reset endpoint command immedialtely when a STALL status is encountered.
Otherwise we end up not following the specs and not returning -EPIPE
several times in a row when trying to transfer data to a halted endpoint.
Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.)
Cc: sta...@vger.kernel.org # v2.6.33+
Tested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-ring.c | 40 +++
drivers/usb/host/xhci.c | 65 ++--
2 files changed, 25 insertions(+), 80 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d6646db..d4125fb 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1822,22 +1822,13 @@ static int finish_td(struct xhci_hcd *xhci, struct
xhci_td *td,
ep-stopped_td = td;
return 0;
} else {
- if (trb_comp_code == COMP_STALL) {
- /* The transfer is completed from the driver's
-* perspective, but we need to issue a set dequeue
-* command for this stalled endpoint to move the dequeue
-* pointer past the TD. We can't do that here because
-* the halt condition must be cleared first. Let the
-* USB class driver clear the stall later.
-*/
- ep-stopped_td = td;
- ep-stopped_stream = ep_ring-stream_id;
- } else if (xhci_requires_manual_halt_cleanup(xhci,
- ep_ctx, trb_comp_code)) {
- /* Other types of errors halt the endpoint, but the
-* class driver doesn't call usb_reset_endpoint() unless
-* the error is -EPIPE. Clear the halted status in the
-* xHCI hardware manually.
+ if (trb_comp_code == COMP_STALL ||
+ xhci_requires_manual_halt_cleanup(xhci, ep_ctx,
+ trb_comp_code)) {
+ /* Issue a reset endpoint command to clear the host side
+* halt, followed by a set dequeue command to move the
+* dequeue pointer past the TD.
+* The class driver clears the device side halt later.
*/
xhci_cleanup_halted_endpoint(xhci,
slot_id, ep_index, ep_ring-stream_id,
@@ -1957,9 +1948,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct
xhci_td *td,
else
td-urb-actual_length = 0;
- xhci_cleanup_halted_endpoint(xhci,
- slot_id, ep_index, 0, td, event_trb);
- return finish_td(xhci, td, event_trb, event, ep, status, true);
+ return finish_td(xhci, td, event_trb, event, ep, status, false);
}
/*
* Did we transfer any data, despite the errors that might have
@@ -2518,17 +2507,8 @@ cleanup:
if (ret) {
urb = td-urb;
urb_priv = urb-hcpriv;
- /* Leave the TD around for the reset endpoint function
-* to use(but only if it's not a control endpoint,
-* since we already queued the Set TR dequeue pointer
-* command for stalled control endpoints).
-*/
- if (usb_endpoint_xfer_control(urb-ep-desc) ||
- (trb_comp_code != COMP_STALL
- trb_comp_code != COMP_BABBLE))
- xhci_urb_free_priv(xhci, urb_priv);
- else
- kfree(urb_priv);
+
+ xhci_urb_free_priv(xhci, urb_priv);
usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb-dev-bus),
urb);
if ((urb-actual_length != urb-transfer_buffer_length
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2a5d45b..4d0d240 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2912,68 +2912,33 @@ void xhci_cleanup_stalled_ring(struct xhci_hcd *xhci,
}
}
-/* Deal with
[PATCHv2 3/4] Revert xhci: clear root port wake on bits if controller isn't wake-up capable
From: Lu Baolu baolu...@linux.intel.com
commit ff8cbf250b44 (xhci: clear root port wake on bits if controller isn't)
can cause device detection error if runtime PM is enabled, and S3 wake
is disabled. Revert it.
https://bugzilla.kernel.org/show_bug.cgi?id=85701
This commit got into stable and should be reverted from there as well.
Cc: stable sta...@vger.kernel.org # v3.2+
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Reported-by: Dmitry Nezhevenko d...@inhex.net
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 696160d..388cfd8 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -22,7 +22,6 @@
#include linux/slab.h
-#include linux/device.h
#include asm/unaligned.h
#include xhci.h
@@ -1149,9 +1148,7 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
* is enabled, so also enable remote wake here.
*/
- if (hcd-self.root_hub-do_remote_wakeup
-device_may_wakeup(hcd-self.controller)) {
-
+ if (hcd-self.root_hub-do_remote_wakeup) {
if (t1 PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 = ~PORT_WKCONN_E;
--
1.8.3.2
--
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
[PATCHv2 0/4] xhci fixes for 3.18-rc
Hi Greg second try, correcting a wrong fixes commit ID, and missing stable version in previous try. These patches for usb-linus solve two xhci issues, fixing xhci halted endpoint handling to now follow the specification, and pass testusb control message tests The other one reverts a faulty xhci controller wakeup solution, and writes a new proper solution. Lu Baolu (2): Revert xhci: clear root port wake on bits if controller isn't wake-up capable usb: xhci: rework root port wake bits if controller isn't allowed to wakeup Mathias Nyman (2): xhci: don't start a halted endpoint before its new dequeue is set xhci: Reset a halted endpoint immediately when we encounter a stall. drivers/usb/host/xhci-hub.c | 5 +- drivers/usb/host/xhci-pci.c | 2 +- drivers/usb/host/xhci-plat.c | 10 +++- drivers/usb/host/xhci-ring.c | 41 - drivers/usb/host/xhci.c | 107 ++- drivers/usb/host/xhci.h | 2 +- 6 files changed, 78 insertions(+), 89 deletions(-) -- 1.8.3.2 -- 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
[PATCHv2 4/4] usb: xhci: rework root port wake bits if controller isn't allowed to wakeup
From: Lu Baolu baolu...@linux.intel.com
When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
platforms may generate spurious wakeup, even if PCI PME# is disabled.
The initial commit ff8cbf250b44 (xhci: clear root port wake on bits),
which also got into stable, turned out to not work correctly and had to
be reverted, and is now rewritten.
Cc: stable sta...@vger.kernel.org # v3.2+
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Suggested-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Alan Stern st...@rowland.harvard.edu
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-pci.c | 2 +-
drivers/usb/host/xhci-plat.c | 10 +-
drivers/usb/host/xhci.c | 42 +-
drivers/usb/host/xhci.h | 2 +-
4 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 9a69b1f..142b601 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -281,7 +281,7 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool
do_wakeup)
if (xhci-quirks XHCI_COMP_MODE_QUIRK)
pdev-no_d3cold = true;
- return xhci_suspend(xhci);
+ return xhci_suspend(xhci, do_wakeup);
}
static int xhci_pci_resume(struct usb_hcd *hcd, bool hibernated)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3d78b0c..646300c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -204,7 +204,15 @@ static int xhci_plat_suspend(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
- return xhci_suspend(xhci);
+ /*
+* xhci_suspend() needs `do_wakeup` to know whether host is allowed
+* to do wakeup during suspend. Since xhci_plat_suspend is currently
+* only designed for system suspend, device_may_wakeup() is enough
+* to dertermine whether host is allowed to do wakeup. Need to
+* reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
+* also applies to runtime suspend.
+*/
+ return xhci_suspend(xhci, device_may_wakeup(dev));
}
static int xhci_plat_resume(struct device *dev)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4d0d240..033b46c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -35,6 +35,8 @@
#define DRIVER_AUTHOR Sarah Sharp
#define DRIVER_DESC 'eXtensible' Host Controller (xHC) Driver
+#definePORT_WAKE_BITS (PORT_WKOC_E | PORT_WKDISC_E | PORT_WKCONN_E)
+
/* Some 0.95 hardware can't handle the chain bit on a Link TRB being cleared */
static int link_quirk;
module_param(link_quirk, int, S_IRUGO | S_IWUSR);
@@ -851,13 +853,47 @@ static void xhci_clear_command_ring(struct xhci_hcd *xhci)
xhci_set_cmd_ring_deq(xhci);
}
+static void xhci_disable_port_wake_on_bits(struct xhci_hcd *xhci)
+{
+ int port_index;
+ __le32 __iomem **port_array;
+ unsigned long flags;
+ u32 t1, t2;
+
+ spin_lock_irqsave(xhci-lock, flags);
+
+ /* disble usb3 ports Wake bits*/
+ port_index = xhci-num_usb3_ports;
+ port_array = xhci-usb3_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t1 = xhci_port_state_to_neutral(t1);
+ t2 = t1 ~PORT_WAKE_BITS;
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ /* disble usb2 ports Wake bits*/
+ port_index = xhci-num_usb2_ports;
+ port_array = xhci-usb2_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t1 = xhci_port_state_to_neutral(t1);
+ t2 = t1 ~PORT_WAKE_BITS;
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ spin_unlock_irqrestore(xhci-lock, flags);
+}
+
/*
* Stop HC (not bus-specific)
*
* This is called when the machine transition into S3/S4 mode.
*
*/
-int xhci_suspend(struct xhci_hcd *xhci)
+int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
{
int rc = 0;
unsigned intdelay = XHCI_MAX_HALT_USEC;
@@ -868,6 +904,10 @@ int xhci_suspend(struct xhci_hcd *xhci)
xhci-shared_hcd-state != HC_STATE_SUSPENDED)
return -EINVAL;
+ /* Clear root port wake on bits if wakeup not allowed. */
+ if (!do_wakeup)
+ xhci_disable_port_wake_on_bits(xhci);
+
/* Don't poll the roothubs on bus suspend. */
xhci_dbg(xhci, %s: stopping port polling.\n, __func__);
clear_bit(HCD_FLAG_POLL_RH, hcd-flags);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index
Re: [PATCH v7 11/13] ARM: dts: Berlin: enable USB on the BG2Q DMP
Hello.
On 11/14/2014 06:26 PM, Antoine Tenart wrote:
Enable the 2 available USB PHY and USB nodes on the Marvell Berlin BG2Q
DMP.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 53 ++
1 file changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index ea1f99b8eed6..f7c25580e122 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
[...]
@@ -21,6 +23,39 @@
choosen {
bootargs = console=ttyS0,115200 earlyprintk;
};
+
+ regulators {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ reg_usb0_vbus: regulator@0 {
Erm, I'm not seeing the reg prop. The unit-address part of the name
shouldn't be used without the reg prop.
[...]
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: [PATCH v4] usb: dwc2/gadget: rework disconnect event handling
-Original Message-
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Friday, November 14, 2014 4:20 AM
This patch adds a call to s3c_hsotg_disconnect() from 'end session'
interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
about unplugged usb cable. DISCONNINT interrupt cannot be used for this
purpose, because it is asserted only in host mode.
To avoid reporting disconnect event more than once, a disconnect call has
been moved from USB_REQ_SET_ADDRESS handling function to SESSREQINT
interrupt. This way driver ensures that disconnect event is reported
either when usb cable is unplugged or every time the host starts a new
session.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 55c90c53f2d6..78b9090ebf71 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -210,6 +210,7 @@ struct s3c_hsotg {
u8 ctrl_buff[8];
struct usb_gadget gadget;
+ unsigned intsession:1;
unsigned intsetup;
unsigned long last_rst;
struct s3c_hsotg_ep *eps;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index fcd2bb55ccca..c7f68dc1cf6b 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1029,7 +1029,6 @@ static int s3c_hsotg_process_req_feature(struct
s3c_hsotg *hsotg,
}
static void s3c_hsotg_enqueue_setup(struct s3c_hsotg *hsotg);
-static void s3c_hsotg_disconnect(struct s3c_hsotg *hsotg);
/**
* s3c_hsotg_stall_ep0 - stall ep0
@@ -1107,7 +1106,6 @@ static void s3c_hsotg_process_control(struct s3c_hsotg
*hsotg,
if ((ctrl-bRequestType USB_TYPE_MASK) == USB_TYPE_STANDARD) {
switch (ctrl-bRequest) {
case USB_REQ_SET_ADDRESS:
- s3c_hsotg_disconnect(hsotg);
dcfg = readl(hsotg-regs + DCFG);
dcfg = ~DCFG_DEVADDR_MASK;
dcfg |= (le16_to_cpu(ctrl-wValue)
@@ -2031,6 +2029,10 @@ static void s3c_hsotg_disconnect(struct s3c_hsotg
*hsotg)
{
unsigned ep;
+ if (!hsotg-session)
+ return;
+
+ hsotg-session = 0;
for (ep = 0; ep hsotg-num_of_eps; ep++)
kill_all_requests(hsotg, hsotg-eps[ep], -ESHUTDOWN, true);
@@ -2290,11 +2292,18 @@ irq_retry:
dev_info(hsotg-dev, OTGInt: %08x\n, otgint);
writel(otgint, hsotg-regs + GOTGINT);
+
+ if (otgint GOTGINT_SES_END_DET) {
+ s3c_hsotg_disconnect(hsotg);
I think you should clear hsotg-session here, shouldn't you?
Otherwise I think s3c_hsotg_disconnect() will be called twice, once
here and once when the next GINTSTS_SESSREQINT comes.
--
Paul
+ hsotg-gadget.speed = USB_SPEED_UNKNOWN;
+ }
}
if (gintsts GINTSTS_SESSREQINT) {
dev_dbg(hsotg-dev, %s: SessReqInt\n, __func__);
writel(GINTSTS_SESSREQINT, hsotg-regs + GINTSTS);
+ s3c_hsotg_disconnect(hsotg);
+ hsotg-session = 1;
}
if (gintsts GINTSTS_ENUMDONE) {
--
1.9.2
--
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] usb: dwc2/gadget: rework disconnect event handling
On Fri, Nov 14, 2014 at 07:01:37PM +, Paul Zimmerman wrote:
-Original Message-
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Friday, November 14, 2014 4:20 AM
This patch adds a call to s3c_hsotg_disconnect() from 'end session'
interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
about unplugged usb cable. DISCONNINT interrupt cannot be used for this
purpose, because it is asserted only in host mode.
To avoid reporting disconnect event more than once, a disconnect call has
been moved from USB_REQ_SET_ADDRESS handling function to SESSREQINT
interrupt. This way driver ensures that disconnect event is reported
either when usb cable is unplugged or every time the host starts a new
session.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 55c90c53f2d6..78b9090ebf71 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -210,6 +210,7 @@ struct s3c_hsotg {
u8 ctrl_buff[8];
struct usb_gadget gadget;
+ unsigned intsession:1;
unsigned intsetup;
unsigned long last_rst;
struct s3c_hsotg_ep *eps;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index fcd2bb55ccca..c7f68dc1cf6b 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1029,7 +1029,6 @@ static int s3c_hsotg_process_req_feature(struct
s3c_hsotg *hsotg,
}
static void s3c_hsotg_enqueue_setup(struct s3c_hsotg *hsotg);
-static void s3c_hsotg_disconnect(struct s3c_hsotg *hsotg);
/**
* s3c_hsotg_stall_ep0 - stall ep0
@@ -1107,7 +1106,6 @@ static void s3c_hsotg_process_control(struct
s3c_hsotg *hsotg,
if ((ctrl-bRequestType USB_TYPE_MASK) == USB_TYPE_STANDARD) {
switch (ctrl-bRequest) {
case USB_REQ_SET_ADDRESS:
- s3c_hsotg_disconnect(hsotg);
dcfg = readl(hsotg-regs + DCFG);
dcfg = ~DCFG_DEVADDR_MASK;
dcfg |= (le16_to_cpu(ctrl-wValue)
@@ -2031,6 +2029,10 @@ static void s3c_hsotg_disconnect(struct s3c_hsotg
*hsotg)
{
unsigned ep;
+ if (!hsotg-session)
+ return;
+
+ hsotg-session = 0;
for (ep = 0; ep hsotg-num_of_eps; ep++)
kill_all_requests(hsotg, hsotg-eps[ep], -ESHUTDOWN, true);
@@ -2290,11 +2292,18 @@ irq_retry:
dev_info(hsotg-dev, OTGInt: %08x\n, otgint);
writel(otgint, hsotg-regs + GOTGINT);
+
+ if (otgint GOTGINT_SES_END_DET) {
+ s3c_hsotg_disconnect(hsotg);
I think you should clear hsotg-session here, shouldn't you?
Otherwise I think s3c_hsotg_disconnect() will be called twice, once
here and once when the next GINTSTS_SESSREQINT comes.
the best way to avoid that would be fiddle with hsotg-session inside
s3c_hsotg_disconnect() only.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v7 03/13] ARM: Berlin: select the reset controller
On 14.11.2014 18:28, Antoine Tenart wrote: Sebastian, On Fri, Nov 14, 2014 at 04:36:50PM +0100, Sebastian Hesselbarth wrote: On 11/14/2014 04:33 PM, Arnd Bergmann wrote: On Friday 14 November 2014 16:25:53 Antoine Tenart wrote: menuconfig ARCH_BERLIN bool Marvell Berlin SoCs if ARCH_MULTI_V7 + select ARCH_HAS_RESET_CONTROLLER select ARCH_REQUIRE_GPIOLIB select ARM_GIC select GENERIC_IRQ_CHIP select DW_APB_ICTL select DW_APB_TIMER_OF select PINCTRL + select RESET_CONTROLLER RESET_CONTROLLER is meant to be user-selectable, don't add a 'select' here, but instead make the driver 'depends on RESET_CONTROLLER'. It already went into arm-soc for v3.19 - ergo, we need an extra patch for removing the current 'select'. Do you want me to send the extra patch fixing this issue? Yes, please. The patch in question is already in a tagged, stabled, and pulled branch - so there is nothing I can do about it. You can just send it as an independent patch, I'll pick it up quickly. Sebastian -- 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 1/2] usb: dwc2/gadget: add mutex to serialize init/deinit calls
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Friday, November 14, 2014 1:19 AM
On 2014-11-13 21:55, Paul Zimmerman wrote:
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Thursday, November 13, 2014 7:18 AM
On 2014-10-31 19:46, Paul Zimmerman wrote:
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Friday, October 31, 2014 3:13 AM
This patch adds mutex, which protects initialization and
deinitialization procedures against suspend/resume methods.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 20
2 files changed, 21 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9f77b4d1c5ff..58732a9a0019 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -187,6 +187,7 @@ struct s3c_hsotg {
struct s3c_hsotg_plat*plat;
spinlock_t lock;
+struct mutexinit_mutex;
void __iomem*regs;
int irq;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index d8dda39c9e16..a2e4272a904e 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -21,6 +21,7 @@
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/debugfs.h
+#include linux/mutex.h
#include linux/seq_file.h
#include linux/delay.h
#include linux/io.h
@@ -2908,6 +2909,7 @@ static int s3c_hsotg_udc_start(struct usb_gadget
*gadget,
return -EINVAL;
}
+mutex_lock(hsotg-init_mutex);
WARN_ON(hsotg-driver);
driver-driver.bus = NULL;
@@ -2933,9 +2935,12 @@ static int s3c_hsotg_udc_start(struct usb_gadget
*gadget,
dev_info(hsotg-dev, bound driver %s\n, driver-driver.name);
+mutex_unlock(hsotg-init_mutex);
+
return 0;
err:
+mutex_unlock(hsotg-init_mutex);
hsotg-driver = NULL;
return ret;
}
@@ -2957,6 +2962,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget
*gadget,
if (!hsotg)
return -ENODEV;
+mutex_lock(hsotg-init_mutex);
+
/* all endpoints should be shutdown */
for (ep = 1; ep hsotg-num_of_eps; ep++)
s3c_hsotg_ep_disable(hsotg-eps[ep].ep);
@@ -2974,6 +2981,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget
*gadget,
clk_disable(hsotg-clk);
+mutex_unlock(hsotg-init_mutex);
+
return 0;
}
@@ -3002,6 +3011,7 @@ static int s3c_hsotg_pullup(struct usb_gadget
*gadget, int is_on)
dev_dbg(hsotg-dev, %s: is_on: %d\n, __func__, is_on);
+mutex_lock(hsotg-init_mutex);
spin_lock_irqsave(hsotg-lock, flags);
if (is_on) {
clk_enable(hsotg-clk);
@@ -3013,6 +3023,7 @@ static int s3c_hsotg_pullup(struct usb_gadget
*gadget, int is_on)
hsotg-gadget.speed = USB_SPEED_UNKNOWN;
spin_unlock_irqrestore(hsotg-lock, flags);
+mutex_unlock(hsotg-init_mutex);
return 0;
}
@@ -3507,6 +3518,7 @@ static int s3c_hsotg_probe(struct platform_device
*pdev)
}
spin_lock_init(hsotg-lock);
+mutex_init(hsotg-init_mutex);
hsotg-irq = ret;
@@ -3652,6 +3664,8 @@ static int s3c_hsotg_suspend(struct
platform_device *pdev, pm_message_t
state)
unsigned long flags;
int ret = 0;
+mutex_lock(hsotg-init_mutex);
+
if (hsotg-driver)
dev_info(hsotg-dev, suspending usb gadget %s\n,
hsotg-driver-driver.name);
@@ -3674,6 +3688,8 @@ static int s3c_hsotg_suspend(struct
platform_device *pdev, pm_message_t
state)
clk_disable(hsotg-clk);
}
+mutex_unlock(hsotg-init_mutex);
+
return ret;
}
@@ -3683,7 +3699,9 @@ static int s3c_hsotg_resume(struct platform_device
*pdev)
unsigned long flags;
int ret = 0;
+mutex_lock(hsotg-init_mutex);
if (hsotg-driver) {
+
dev_info(hsotg-dev, resuming usb gadget %s\n,
hsotg-driver-driver.name);
@@ -3699,6 +3717,8 @@ static int s3c_hsotg_resume(struct platform_device
*pdev)
s3c_hsotg_core_connect(hsotg);
spin_unlock_irqrestore(hsotg-lock, flags);
+mutex_unlock(hsotg-init_mutex);
+
return ret;
}
Hmm. I can't find any other UDC driver that uses a mutex in its
suspend/resume functions. Can you explain why this is needed only
for dwc2?
I've posted this version because I thought you were not convinced that
the patch
usb: dwc2/gadget: rework suspend/resume code to
Re: [PATCH v3 1/2] usb: dwc2/gadget: add mutex to serialize init/deinit calls
Hi, On Fri, Nov 14, 2014 at 07:43:23PM +, Paul Zimmerman wrote: @@ -3699,6 +3717,8 @@ static int s3c_hsotg_resume(struct platform_device *pdev) s3c_hsotg_core_connect(hsotg); spin_unlock_irqrestore(hsotg-lock, flags); + mutex_unlock(hsotg-init_mutex); + return ret; } Hmm. I can't find any other UDC driver that uses a mutex in its suspend/resume functions. Can you explain why this is needed only for dwc2? I've posted this version because I thought you were not convinced that the patch usb: dwc2/gadget: rework suspend/resume code to correctly restore gadget state can add code for initialization and deinitialization in suspend/resume paths. My problem with that patch was that you were checking the -enabled flag outside of the spinlock. To address that, you only need to move the check inside of the spinlock. I don't see why a mutex is needed. It is not that simple. I can add spin_lock() before checking enabled, but then I would need to spin_unlock() to call regulator_bulk_enable() and phy_enable(), because both cannot be called from atomic context. This means that the spinlock in such case will not protect anything and is simply useless. Ah, OK. So you're using the mutex instead of the -enabled flag that you proposed in the rework suspend/resume code patch. So this patch is a replacement for that one. Somehow I was thinking this patch was on top of that one. So I guess this is OK, but I would like to get Felipe's opinion about it before we apply this. Felipe? I can't think of a better way, I'm afraid :-( -- balbi signature.asc Description: Digital signature
RE: [PATCH v3] usb: dwc2: add bus suspend/resume for dwc2
From: jwer...@google.com [mailto:jwer...@google.com] On Behalf Of Julius
Werner
Sent: Thursday, November 13, 2014 8:50 PM
I will figure out how to make dwc2 detect the device connect after auto
suspend,
or disable the auto suspend feature for the dwc2 hcd.
I think auto-suspend of the root hub device (which is what calls
bus_suspend, but is not the host controller device itself) is expected
to always happen and not really meant to be disabled. I'm surprised
that the controller would fail to come back up, though. Does removing
the PCGCTL part make it work? That's the only thing I can think of
(but then again the function should immediately return if the port is
not in L0, so if there is nothing plugged in the suspend shouldn't
really do anything).
Hi guys,
I don't have any experience with suspend/resume on the dwc2 controller
I'm afraid. One suggestion would be to look at our Synopsys vendor
driver to see how it is handled there.
That driver is part of the Raspberry Pi upstream kernel, which you
can find at https://github.com/raspberrypi/linux. The driver is
under drivers/usb/host/dwc_otg.
In particular, in dwc_otg_cil_intr.c there is a function named
dwc_otg_handle_wakeup_detected_intr() which might be of interest.
Unfortunately, that driver code is rather convoluted, so it may be
difficult to figure out exactly what the driver is doing.
--
Paul
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: [RESUBMIT] [PATCH] Replace mentions of list_struct to list_head
Em Thu, 13 Nov 2014 20:48:41 -0500 Steven Rostedt rost...@goodmis.org escreveu: On Fri, 14 Nov 2014 05:09:55 +0400 Andrey Utkin andrey.krieger.ut...@gmail.com wrote: There's no such thing as list_struct. I guess there isn't. Indeed ;) Signed-off-by: Andrey Utkin andrey.krieger.ut...@gmail.com Acked-by: Steven Rostedt rost...@goodmis.org Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com -- Steve --- drivers/gpu/drm/radeon/mkregtable.c | 24 drivers/media/pci/cx18/cx18-driver.h | 2 +- include/linux/list.h | 34 +- include/linux/plist.h| 10 +- include/linux/rculist.h | 8 scripts/kconfig/list.h | 6 +++--- tools/usb/usbip/libsrc/list.h| 2 +- 7 files changed, 43 insertions(+), 43 deletions(-) -- 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 0/3] USB: host: Misc patches to remove hard-coded octeon platform information
On Fri, Nov 14, 2014 at 12:47:14PM +0100, Andreas Herrmann wrote: On Thu, Nov 13, 2014 at 05:13:36PM -0500, Alan Stern wrote: At a very quick first glance, it looks great. Have you tested it thoroughly? [sorry have to use another mail account, so far your mail didn't show up at my caviumnetworks account] I've tested it only on an EdgeRouterPro (Octeon II system, which I have on-site). I have also tested them on EdgeRouter Pro. Thanks, this is great improvement. Tested-by: Aaro Koskinen aaro.koski...@iki.fi A. -- 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: [PATCHv7 3/8] usb: dwc2: convert to use dev_pm_ops API
From: dingu...@opensource.altera.com [mailto:dingu...@opensource.altera.com]
Sent: Tuesday, November 11, 2014 9:14 AM
From: Dinh Nguyen dingu...@opensource.altera.com
Update suspend/resume to use dev_pm_ops API.
Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com
---
drivers/usb/dwc2/platform.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index eeba8a4..b94867b 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -219,9 +219,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
return retval;
}
-static int dwc2_suspend(struct platform_device *dev, pm_message_t state)
+static int dwc2_suspend(struct device *dev)
{
- struct dwc2_hsotg *dwc2 = platform_get_drvdata(dev);
+ struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
int ret = 0;
if (dwc2_is_device_mode(dwc2))
@@ -229,9 +229,9 @@ static int dwc2_suspend(struct platform_device *dev,
pm_message_t state)
return ret;
}
-static int dwc2_resume(struct platform_device *dev)
+static int dwc2_resume(struct device *dev)
{
- struct dwc2_hsotg *dwc2 = platform_get_drvdata(dev);
+ struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
int ret = 0;
if (dwc2_is_device_mode(dwc2))
@@ -239,15 +239,18 @@ static int dwc2_resume(struct platform_device *dev)
return ret;
}
+static const struct dev_pm_ops dwc2_dev_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(dwc2_suspend, dwc2_resume)
+};
+
static struct platform_driver dwc2_platform_driver = {
.driver = {
.name = dwc2_driver_name,
.of_match_table = dwc2_of_match_table,
+ .pm = dwc2_dev_pm_ops,
},
.probe = dwc2_driver_probe,
.remove = dwc2_driver_remove,
- .suspend = dwc2_suspend,
- .resume = dwc2_resume,
};
module_platform_driver(dwc2_platform_driver);
Acked-by: Paul Zimmerman pa...@synopsys.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: [PATCHv7 5/8] usb: dwc2: Update common interrupt handler to call gadget interrupt handler
From: dingu...@opensource.altera.com [mailto:dingu...@opensource.altera.com]
Sent: Tuesday, November 11, 2014 9:14 AM
From: Dinh Nguyen dingu...@opensource.altera.com
Make dwc2_handle_common_intr call the gadget interrupt function when operating
in peripheral mode. Remove the spinlock functions in s3c_hsotg_irq as
dwc2_handle_common_intr() already has the spinlocks.
Move the registeration of the IRQ to common code for platform and PCI.
Remove duplicate interrupt conditions that was in gadget, as those are handled
by dwc2 common interrupt handler.
Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com
---
v7: Use IRQF_SHARED
v5: remove individual devm_request_irq from gadget and hcd, and place a
single devm_request_irq in platform and pci.
v2: Keep interrupt handler for host and peripheral modes separate
---
drivers/usb/dwc2/core.c | 10 --
drivers/usb/dwc2/gadget.c | 46
+++--
drivers/usb/dwc2/pci.c | 6 ++
drivers/usb/dwc2/platform.c | 8
4 files changed, 17 insertions(+), 53 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index d926945..7605850b 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -458,16 +458,6 @@ int dwc2_core_init(struct dwc2_hsotg *hsotg, bool
select_phy, int irq)
/* Clear the SRP success bit for FS-I2c */
hsotg-srp_success = 0;
- if (irq = 0) {
- dev_dbg(hsotg-dev, registering common handler for irq%d\n,
- irq);
- retval = devm_request_irq(hsotg-dev, irq,
- dwc2_handle_common_intr, IRQF_SHARED,
- dev_name(hsotg-dev), hsotg);
- if (retval)
- return retval;
- }
-
/* Enable common interrupts */
dwc2_enable_common_interrupts(hsotg);
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index ec85340..37c7916 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2285,33 +2285,12 @@ irq_retry:
gintsts = gintmsk;
- if (gintsts GINTSTS_OTGINT) {
- u32 otgint = readl(hsotg-regs + GOTGINT);
-
- dev_info(hsotg-dev, OTGInt: %08x\n, otgint);
-
- writel(otgint, hsotg-regs + GOTGINT);
- }
-
- if (gintsts GINTSTS_SESSREQINT) {
- dev_dbg(hsotg-dev, %s: SessReqInt\n, __func__);
- writel(GINTSTS_SESSREQINT, hsotg-regs + GINTSTS);
- }
-
This hunk will clash with the patch that Marek has just submitted,
which uses the SESSREQINT in the gadget. But I guess you two and
Felipe can resolve that :)
if (gintsts GINTSTS_ENUMDONE) {
writel(GINTSTS_ENUMDONE, hsotg-regs + GINTSTS);
s3c_hsotg_irq_enumdone(hsotg);
}
- if (gintsts GINTSTS_CONIDSTSCHNG) {
- dev_dbg(hsotg-dev, ConIDStsChg (DSTS=0x%08x, GOTCTL=%08x)\n,
- readl(hsotg-regs + DSTS),
- readl(hsotg-regs + GOTGCTL));
-
- writel(GINTSTS_CONIDSTSCHNG, hsotg-regs + GINTSTS);
- }
-
if (gintsts (GINTSTS_OEPINT | GINTSTS_IEPINT)) {
u32 daint = readl(hsotg-regs + DAINT);
u32 daintmsk = readl(hsotg-regs + DAINTMSK);
@@ -2392,25 +2371,6 @@ irq_retry:
s3c_hsotg_handle_rx(hsotg);
}
- if (gintsts GINTSTS_MODEMIS) {
- dev_warn(hsotg-dev, warning, mode mismatch triggered\n);
- writel(GINTSTS_MODEMIS, hsotg-regs + GINTSTS);
- }
-
- if (gintsts GINTSTS_USBSUSP) {
- dev_info(hsotg-dev, GINTSTS_USBSusp\n);
- writel(GINTSTS_USBSUSP, hsotg-regs + GINTSTS);
-
- call_gadget(hsotg, suspend);
- }
-
- if (gintsts GINTSTS_WKUPINT) {
- dev_info(hsotg-dev, GINTSTS_WkUpIn\n);
- writel(GINTSTS_WKUPINT, hsotg-regs + GINTSTS);
-
- call_gadget(hsotg, resume);
- }
-
if (gintsts GINTSTS_ERLYSUSP) {
dev_dbg(hsotg-dev, GINTSTS_ErlySusp\n);
writel(GINTSTS_ERLYSUSP, hsotg-regs + GINTSTS);
@@ -3510,14 +3470,14 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int
irq)
s3c_hsotg_hw_cfg(hsotg);
s3c_hsotg_init(hsotg);
- ret = devm_request_irq(dev, irq, s3c_hsotg_irq, 0,
- dev_name(dev), hsotg);
+ ret = devm_request_irq(hsotg-dev, irq, s3c_hsotg_irq, IRQF_SHARED,
+ dev_name(hsotg-dev), hsotg);
if (ret 0) {
s3c_hsotg_phy_disable(hsotg);
clk_disable_unprepare(hsotg-clk);
regulator_bulk_disable(ARRAY_SIZE(hsotg-supplies),
hsotg-supplies);
- dev_err(dev, cannot claim IRQ\n);
+ dev_err(dev, cannot claim IRQ for gadget\n);
RE: [PATCHv7 7/8] usb: dwc2: move usb_disabled() call to host driver only
From: dingu...@opensource.altera.com [mailto:dingu...@opensource.altera.com]
Sent: Tuesday, November 11, 2014 9:14 AM
From: Dinh Nguyen dingu...@opensource.altera.com
Since platform.c will get built for both Host and Gadget, if we leave the
usb_disabled() call in platform.c, it results in the following build error
when (!USB USB_GADGET) condition is met.
ERROR: usb_disabled [drivers/usb/dwc2/dwc2_platform.ko] undefined!
Since usb_disabled() is mostly used to disable USB host functionality, move
the call the host portion for the DWC2 driver.
Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com
---
drivers/usb/dwc2/hcd.c | 3 +++
drivers/usb/dwc2/platform.c | 3 ---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index fa60f4a..755e16b 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2780,6 +2780,9 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
int i, num_channels;
int retval;
+ if (usb_disabled())
+ return -ENODEV;
+
dev_dbg(hsotg-dev, DWC OTG HCD INIT\n);
/* Detect config values from hardware */
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 3552602..57eb8a3 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -157,9 +157,6 @@ static int dwc2_driver_probe(struct platform_device *dev)
int retval;
int irq;
- if (usb_disabled())
- return -ENODEV;
-
match = of_match_device(dwc2_of_match_table, dev-dev);
if (match match-data) {
params = match-data;
This patch also fixes a minor buglet, in that we were missing the
usb_disabled() check in pci.c.
Acked-by: Paul Zimmerman pa...@synopsys.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: [PATCHv7 6/8] usb: dwc2: gadget: Do not fail probe if there isn't a clock node
From: dingu...@opensource.altera.com [mailto:dingu...@opensource.altera.com]
Sent: Tuesday, November 11, 2014 9:14 AM
From: Dinh Nguyen dingu...@opensource.altera.com
Since the dwc2 hcd driver is currently not looking for a clock node during
init, we should not completely fail if there isn't a clock provided.
By assigning clk = NULL, this allows the driver, when configured for dual-role
mode, to be able to continue loading the host portion of the driver when
a clock node is not specified.
Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com
---
v7: Reworked to use clk=NULL and remove the need to is IS_ERR(clk)
v6: none
v5: reworked to not access gadget functions from the hcd.
---
drivers/usb/dwc2/gadget.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 37c7916..367689b 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3431,6 +3431,7 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
hsotg-clk = devm_clk_get(dev, otg);
if (IS_ERR(hsotg-clk)) {
+ hsotg-clk = NULL;
dev_err(dev, cannot get otg clock\n);
return PTR_ERR(hsotg-clk);
}
Whoops, you just broke the return value, since you NULL out
hsotg-clk and then call PTR_ERR() on it.
--
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] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
On Fri, Nov 14, 2014 at 02:41:57PM +0530, George Cherian wrote: On 11/14/2014 02:12 PM, Sebastian Andrzej Siewior wrote: On 11/14/2014 09:24 AM, George Cherian wrote: Disable the MUSB interrupts till MUSB is recovered fully from BABBLE condition. There are chances that we could get multiple interrupts till the time the babble recover work gets scheduled. Sometimes this could even end up in an endless loop making MUSB itself unusable. How do you trigger the babble error? Is this something that happens during suspend resume, plugging / unplugging a device or randomly while the device is used? I have never seen this error while device is successfully enumerated and while working fine. Mostly u get it when we connect/disconnect devices to HOST port. Normally I use the following for testing BABBLE - Especially when a fully loaded USB HUB getting connected to HOST port. - Or repeatedly load and unload musb_hdrc.ko with some device connected. If nothing of the above work you might be the lucky one to have a good board if you have a BBB, connect host port to device port, load g_zero and run any of testusb test cases. -- balbi signature.asc Description: Digital signature
Re: [PATCH v7 08/13] usb: chipidea: add a usb2 driver for ci13xxx
On Fri, Nov 14, 2014 at 04:25:58PM +0100, 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 | 117 2 files changed, 118 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 usb2 is too generic, you should call it ci_hdcr_marvell, or something like that. -- balbi signature.asc Description: Digital signature
Re: [PATCHv7 6/8] usb: dwc2: gadget: Do not fail probe if there isn't a clock node
On Fri, Nov 14, 2014 at 09:01:49PM +, Paul Zimmerman wrote:
From: dingu...@opensource.altera.com [mailto:dingu...@opensource.altera.com]
Sent: Tuesday, November 11, 2014 9:14 AM
From: Dinh Nguyen dingu...@opensource.altera.com
Since the dwc2 hcd driver is currently not looking for a clock node during
init, we should not completely fail if there isn't a clock provided.
By assigning clk = NULL, this allows the driver, when configured for
dual-role
mode, to be able to continue loading the host portion of the driver when
a clock node is not specified.
Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com
---
v7: Reworked to use clk=NULL and remove the need to is IS_ERR(clk)
v6: none
v5: reworked to not access gadget functions from the hcd.
---
drivers/usb/dwc2/gadget.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 37c7916..367689b 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3431,6 +3431,7 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int
irq)
hsotg-clk = devm_clk_get(dev, otg);
if (IS_ERR(hsotg-clk)) {
+ hsotg-clk = NULL;
dev_err(dev, cannot get otg clock\n);
return PTR_ERR(hsotg-clk);
}
Whoops, you just broke the return value, since you NULL out
hsotg-clk and then call PTR_ERR() on it.
yeah, the idea was to remove the early return too :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v7 08/13] usb: chipidea: add a usb2 driver for ci13xxx
Felipe, On Fri, Nov 14, 2014 at 03:08:32PM -0600, Felipe Balbi wrote: On Fri, Nov 14, 2014 at 04:25:58PM +0100, 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 | 117 2 files changed, 118 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 usb2 is too generic, you should call it ci_hdcr_marvell, or something like that. This driver is generic, and not only for Marvell Berlin SoCs. It is part of the Berlin USB series as it is the first SoC to use it but Xilinx can also use it for example. 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 v7 08/13] usb: chipidea: add a usb2 driver for ci13xxx
On Fri, Nov 14, 2014 at 10:10:52PM +0100, Antoine Tenart wrote: Felipe, On Fri, Nov 14, 2014 at 03:08:32PM -0600, Felipe Balbi wrote: On Fri, Nov 14, 2014 at 04:25:58PM +0100, 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 | 117 2 files changed, 118 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 usb2 is too generic, you should call it ci_hdcr_marvell, or something like that. This driver is generic, and not only for Marvell Berlin SoCs. It is part of the Berlin USB series as it is the first SoC to use it but Xilinx can also use it for example. then how about ci_hdrc_generic.c ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v7 11/13] ARM: dts: Berlin: enable USB on the BG2Q DMP
Hi,
On Fri, Nov 14, 2014 at 09:47:11PM +0300, Sergei Shtylyov wrote:
On 11/14/2014 06:26 PM, Antoine Tenart wrote:
Enable the 2 available USB PHY and USB nodes on the Marvell Berlin BG2Q
DMP.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 53
++
1 file changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index ea1f99b8eed6..f7c25580e122 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
[...]
@@ -21,6 +23,39 @@
choosen {
bootargs = console=ttyS0,115200 earlyprintk;
};
+
+regulators {
+compatible = simple-bus;
+#address-cells = 1;
+#size-cells = 0;
+
+reg_usb0_vbus: regulator@0 {
Erm, I'm not seeing the reg prop. The unit-address part of the name
shouldn't be used without the reg prop.
[...]
Well, I respect the bindings described at:
Documentation/devicetree/bindings/regulator/fixed-regulator.txt
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 v4] usb: dwc2/gadget: rework disconnect event handling
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe Balbi
Sent: Friday, November 14, 2014 11:05 AM
On Fri, Nov 14, 2014 at 07:01:37PM +, Paul Zimmerman wrote:
-Original Message-
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Friday, November 14, 2014 4:20 AM
This patch adds a call to s3c_hsotg_disconnect() from 'end session'
interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
about unplugged usb cable. DISCONNINT interrupt cannot be used for this
purpose, because it is asserted only in host mode.
To avoid reporting disconnect event more than once, a disconnect call has
been moved from USB_REQ_SET_ADDRESS handling function to SESSREQINT
interrupt. This way driver ensures that disconnect event is reported
either when usb cable is unplugged or every time the host starts a new
session.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 55c90c53f2d6..78b9090ebf71 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -210,6 +210,7 @@ struct s3c_hsotg {
u8 ctrl_buff[8];
struct usb_gadget gadget;
+ unsigned intsession:1;
unsigned intsetup;
unsigned long last_rst;
struct s3c_hsotg_ep *eps;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index fcd2bb55ccca..c7f68dc1cf6b 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1029,7 +1029,6 @@ static int s3c_hsotg_process_req_feature(struct
s3c_hsotg *hsotg,
}
static void s3c_hsotg_enqueue_setup(struct s3c_hsotg *hsotg);
-static void s3c_hsotg_disconnect(struct s3c_hsotg *hsotg);
/**
* s3c_hsotg_stall_ep0 - stall ep0
@@ -1107,7 +1106,6 @@ static void s3c_hsotg_process_control(struct
s3c_hsotg *hsotg,
if ((ctrl-bRequestType USB_TYPE_MASK) == USB_TYPE_STANDARD) {
switch (ctrl-bRequest) {
case USB_REQ_SET_ADDRESS:
- s3c_hsotg_disconnect(hsotg);
dcfg = readl(hsotg-regs + DCFG);
dcfg = ~DCFG_DEVADDR_MASK;
dcfg |= (le16_to_cpu(ctrl-wValue)
@@ -2031,6 +2029,10 @@ static void s3c_hsotg_disconnect(struct s3c_hsotg
*hsotg)
{
unsigned ep;
+ if (!hsotg-session)
+ return;
+
+ hsotg-session = 0;
for (ep = 0; ep hsotg-num_of_eps; ep++)
kill_all_requests(hsotg, hsotg-eps[ep], -ESHUTDOWN, true);
@@ -2290,11 +2292,18 @@ irq_retry:
dev_info(hsotg-dev, OTGInt: %08x\n, otgint);
writel(otgint, hsotg-regs + GOTGINT);
+
+ if (otgint GOTGINT_SES_END_DET) {
+ s3c_hsotg_disconnect(hsotg);
I think you should clear hsotg-session here, shouldn't you?
Otherwise I think s3c_hsotg_disconnect() will be called twice, once
here and once when the next GINTSTS_SESSREQINT comes.
the best way to avoid that would be fiddle with hsotg-session inside
s3c_hsotg_disconnect() only.
Whoops, I just noticed that hsotg-session *is* cleared inside of
s3c_hsotg_disconnect(). So I think the patch is good as-is.
Acked-by: Paul Zimmerman pa...@synopsys.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 v4] usb: dwc2/gadget: rework disconnect event handling
From: Paul Zimmerman
Sent: Friday, November 14, 2014 1:21 PM
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe Balbi
Sent: Friday, November 14, 2014 11:05 AM
On Fri, Nov 14, 2014 at 07:01:37PM +, Paul Zimmerman wrote:
-Original Message-
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Friday, November 14, 2014 4:20 AM
This patch adds a call to s3c_hsotg_disconnect() from 'end session'
interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
about unplugged usb cable. DISCONNINT interrupt cannot be used for this
purpose, because it is asserted only in host mode.
To avoid reporting disconnect event more than once, a disconnect call
has
been moved from USB_REQ_SET_ADDRESS handling function to SESSREQINT
interrupt. This way driver ensures that disconnect event is reported
either when usb cable is unplugged or every time the host starts a new
session.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 55c90c53f2d6..78b9090ebf71 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -210,6 +210,7 @@ struct s3c_hsotg {
u8 ctrl_buff[8];
struct usb_gadget gadget;
+ unsigned intsession:1;
unsigned intsetup;
unsigned long last_rst;
struct s3c_hsotg_ep *eps;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index fcd2bb55ccca..c7f68dc1cf6b 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1029,7 +1029,6 @@ static int s3c_hsotg_process_req_feature(struct
s3c_hsotg *hsotg,
}
static void s3c_hsotg_enqueue_setup(struct s3c_hsotg *hsotg);
-static void s3c_hsotg_disconnect(struct s3c_hsotg *hsotg);
/**
* s3c_hsotg_stall_ep0 - stall ep0
@@ -1107,7 +1106,6 @@ static void s3c_hsotg_process_control(struct
s3c_hsotg *hsotg,
if ((ctrl-bRequestType USB_TYPE_MASK) == USB_TYPE_STANDARD) {
switch (ctrl-bRequest) {
case USB_REQ_SET_ADDRESS:
- s3c_hsotg_disconnect(hsotg);
dcfg = readl(hsotg-regs + DCFG);
dcfg = ~DCFG_DEVADDR_MASK;
dcfg |= (le16_to_cpu(ctrl-wValue)
@@ -2031,6 +2029,10 @@ static void s3c_hsotg_disconnect(struct
s3c_hsotg *hsotg)
{
unsigned ep;
+ if (!hsotg-session)
+ return;
+
+ hsotg-session = 0;
for (ep = 0; ep hsotg-num_of_eps; ep++)
kill_all_requests(hsotg, hsotg-eps[ep], -ESHUTDOWN,
true);
@@ -2290,11 +2292,18 @@ irq_retry:
dev_info(hsotg-dev, OTGInt: %08x\n, otgint);
writel(otgint, hsotg-regs + GOTGINT);
+
+ if (otgint GOTGINT_SES_END_DET) {
+ s3c_hsotg_disconnect(hsotg);
I think you should clear hsotg-session here, shouldn't you?
Otherwise I think s3c_hsotg_disconnect() will be called twice, once
here and once when the next GINTSTS_SESSREQINT comes.
the best way to avoid that would be fiddle with hsotg-session inside
s3c_hsotg_disconnect() only.
Whoops, I just noticed that hsotg-session *is* cleared inside of
s3c_hsotg_disconnect(). So I think the patch is good as-is.
Acked-by: Paul Zimmerman pa...@synopsys.com
I'm having second thoughts about this. Currently, the
GINTSTS_SESSREQINT interrupt in the gadget does nothing except print
a debug message. So I'm not sure that all versions of the controller
actually assert this interrupt when a connection is made. If they
don't, then this patch would break the disconnect handling, since
hsotg-session would never get set.
In particular, I'm thinking that a core which is synthesized without
SRP support may not implement the GINTSTS_SESSREQINT interrupt. The
databook seems to imply that:
SessReqInt: In Device mode, this interrupt is asserted when the
utmisrp_bvalid signal goes high.
And in the section which describes the utmisrp_bvalid signal, there is
a note that says:
This interface is present only when parameter OTG_MODE specifies an
SRP-capable configuration.
So Marek, can you try moving the line which sets hsotg-session = 1
into s3c_hsotg_irq_enumdone() instead? Then we will be sure it gets set
to one after a connect. Probably it should be renamed from 'session'
to 'connect' in that case.
--
Paul
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to
Re: [V2 PATCH 01/10] added media agnostic (MA) USB HCD driver
On Wed, Nov 12, 2014 at 05:03:18PM -0500, Alan Stern wrote: On Wed, 12 Nov 2014, Sean O. Stalley wrote: Our plan to support multiple MA devices is to have them all connected to the same virtual host controller, so only 1 would be needed. Would you prefer we have 1 host controller instance per MA device? We are definitely open to suggestions on how this should be architected. I haven't read the MA USB spec, so I don't know how it's intended to work. Still, what happens if you create a virtual host controller with, say, 16 ports, and then someone wants to connect a 17th MA device? To summarize the spec: MA USB groups a host connected devices into MA service sets (MSS). The architectural limit is 254 MA devices per MSS. If the host needs to connect more devices than that, It can start a new MSS and connect to 254 more MA devices. Is supporting up to 254 devices on one machine sufficient? Would it make sense (and does the usb stack support) having 254 root ports on one host controller? If so, we could make our host controller instance have 254 ports. I'm guessing the hub driver may have a problem with this (especially for superspeed). If that doesn't make sense (or isn't supported), we can have 1 host controller instance per MA device. Would that be preferred? Also, I noticed that your patch adds a new bus type for these MA host controllers. It really seems like overkill to have a whole new bus type if there's only going to be one device on it. The bus was added when we were quickly trying to replace the platform device code. It's probably not the right thing to do. I'm still not sure why we can't make our hcd a platform device, especially since dummy_hcd the usbip's hcd are both platform devices. If we get rid of these locks, endpoints can't run simultaneously. MA USB IN endpoints have to copy data, which could take a while. I don't know what you mean by run simultaneously. Certainly multiple network packets can be transmitted and received concurrently even if you use a single spinlock, since your locking won't affect the networking subsystem. I meant we couldn't have 2 threads in our driver. With one lock, One thread would always have to wait for the other, even though they could be working on 2 different endpoints doing completely independent tasks. Couldn't this cause a bottleneck? Probably not enough to matter. After all, the other host controller drivers rely on a single spinlock. And if it did matter, you could drop the spinlock while copying the data. Good point. We can cut our driver down to using 1 lock. If we find that only having 1 spinlock does cause a bottleneck, we can deal with it then. Thanks, Sean -- 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: [RESUBMIT] [PATCH] Replace mentions of list_struct to list_head
-Original Message- From: Andrey Utkin [mailto:andrey.krieger.ut...@gmail.com] Sent: Thursday, November 13, 2014 8:10 PM To: linux-usb@vger.kernel.org; linux-kbu...@vger.kernel.org; linux- me...@vger.kernel.org; linux-ker...@vger.kernel.org; dri- de...@lists.freedesktop.org; kernel-janit...@vger.kernel.org; gre...@linuxfoundation.org; mgor...@suse.de; ddstr...@ieee.org; jeffrey.t.kirs...@intel.com; yamad...@jp.panasonic.com; kenhel...@firemail.de; o...@redhat.com; a...@linux-foundation.org; shuah...@samsung.com; valentina.mane...@gmail.com; yann.morin.1...@free.fr; la...@cn.fujitsu.com; mathieu.desnoy...@efficios.com; rost...@goodmis.org; j...@joshtriplett.org; paul...@linux.vnet.ibm.com; m.che...@samsung.com; awa...@md.metrocast.net; airl...@linux.ie; Koenig, Christian; Deucher, Alexander; triv...@kernel.org Cc: Andrey Utkin Subject: [RESUBMIT] [PATCH] Replace mentions of list_struct to list_head There's no such thing as list_struct. Signed-off-by: Andrey Utkin andrey.krieger.ut...@gmail.com Acked-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/mkregtable.c | 24 drivers/media/pci/cx18/cx18-driver.h | 2 +- include/linux/list.h | 34 +- include/linux/plist.h| 10 +- include/linux/rculist.h | 8 scripts/kconfig/list.h | 6 +++--- tools/usb/usbip/libsrc/list.h| 2 +- 7 files changed, 43 insertions(+), 43 deletions(-) diff --git a/drivers/gpu/drm/radeon/mkregtable.c b/drivers/gpu/drm/radeon/mkregtable.c index 4a85bb6..b928c17 100644 --- a/drivers/gpu/drm/radeon/mkregtable.c +++ b/drivers/gpu/drm/radeon/mkregtable.c @@ -347,7 +347,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_entry - get the struct for this entry * @ptr: the struct list_head pointer. * @type:the type of the struct this is embedded in. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. */ #define list_entry(ptr, type, member) \ container_of(ptr, type, member) @@ -356,7 +356,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_first_entry - get the first element from a list * @ptr: the list head to take the element from. * @type:the type of the struct this is embedded in. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. * * Note, that list is expected to be not empty. */ @@ -406,7 +406,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry - iterate over list of given type * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. */ #define list_for_each_entry(pos, head, member) \ for (pos = list_entry((head)-next, typeof(*pos), member); \ @@ -417,7 +417,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry_reverse - iterate backwards over list of given type. * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. */ #define list_for_each_entry_reverse(pos, head, member) \ for (pos = list_entry((head)-prev, typeof(*pos), member); \ @@ -428,7 +428,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_prepare_entry - prepare a pos entry for use in list_for_each_entry_continue() * @pos: the type * to use as a start point * @head:the head of the list - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. * * Prepares a pos entry for use as a start point in list_for_each_entry_continue(). */ @@ -439,7 +439,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry_continue - continue iteration over list of given type * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. * * Continue to iterate over list of given type, continuing after * the current position. @@ -453,7 +453,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry_continue_reverse - iterate backwards from the given point * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head
Re: [RESUBMIT] [PATCH] Replace mentions of list_struct to list_head
On Fri, Nov 14, 2014 at 05:09:55AM +0400, Andrey Utkin wrote: There's no such thing as list_struct. Signed-off-by: Andrey Utkin andrey.krieger.ut...@gmail.com May as well get group rates on the acks... ;-) Acked-by: Paul E. McKenney paul...@linux.vnet.ibm.com --- drivers/gpu/drm/radeon/mkregtable.c | 24 drivers/media/pci/cx18/cx18-driver.h | 2 +- include/linux/list.h | 34 +- include/linux/plist.h| 10 +- include/linux/rculist.h | 8 scripts/kconfig/list.h | 6 +++--- tools/usb/usbip/libsrc/list.h| 2 +- 7 files changed, 43 insertions(+), 43 deletions(-) diff --git a/drivers/gpu/drm/radeon/mkregtable.c b/drivers/gpu/drm/radeon/mkregtable.c index 4a85bb6..b928c17 100644 --- a/drivers/gpu/drm/radeon/mkregtable.c +++ b/drivers/gpu/drm/radeon/mkregtable.c @@ -347,7 +347,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_entry - get the struct for this entry * @ptr: the struct list_head pointer. * @type:the type of the struct this is embedded in. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. */ #define list_entry(ptr, type, member) \ container_of(ptr, type, member) @@ -356,7 +356,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_first_entry - get the first element from a list * @ptr: the list head to take the element from. * @type:the type of the struct this is embedded in. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. * * Note, that list is expected to be not empty. */ @@ -406,7 +406,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry - iterate over list of given type * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. */ #define list_for_each_entry(pos, head, member) \ for (pos = list_entry((head)-next, typeof(*pos), member); \ @@ -417,7 +417,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry_reverse - iterate backwards over list of given type. * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. */ #define list_for_each_entry_reverse(pos, head, member) \ for (pos = list_entry((head)-prev, typeof(*pos), member); \ @@ -428,7 +428,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_prepare_entry - prepare a pos entry for use in list_for_each_entry_continue() * @pos: the type * to use as a start point * @head:the head of the list - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. * * Prepares a pos entry for use as a start point in list_for_each_entry_continue(). */ @@ -439,7 +439,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry_continue - continue iteration over list of given type * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. * * Continue to iterate over list of given type, continuing after * the current position. @@ -453,7 +453,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry_continue_reverse - iterate backwards from the given point * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. * * Start to iterate over list of given type backwards, continuing after * the current position. @@ -467,7 +467,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry_from - iterate over list of given type from the current point * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. * * Iterate over list of given type, continuing from current position. */ @@ -480,7 +480,7 @@ static inline void list_splice_tail_init(struct list_head *list, * @pos: the type * to use as a loop cursor. * @n: another
