Re: [PATCH] ARM: dts: omap3-beagle: Fix USB host on beagle boards (for 3.13)
On 11/25/2013 05:50 PM, Nishanth Menon wrote:
On Mon, Nov 25, 2013 at 7:55 AM, Roger Quadros rog...@ti.com wrote:
Beagle (rev. C4) and Beagle-XM (all revs) need VAUX2 1.8V supply
for the USB PHY.
As the generic PHY driver can't handle more than one supply
at the moment, we configure this supply to be always on.
This will cause a very small power impact if the USB host subsystem
is not in use, about 76.86 micro-W + LDO power.
Older Beagle boards (prior to C4) don't have VAUX2 connected anywhere,
so there won't be any functional impact on those boards other than
some additional LDO power consumption.
Reported-by: Nishanth Menon n...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Tested-by: Nishanth Menon n...@ti.com
Thanks Nishant.
I might suggest though that the better alternative might be to get phy
driver to handle multiple regulators considering that DT is supposed
to represent the h/w topology.
Noted. I will work on this for 3.14.
cheers,
-roger
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 8
arch/arm/boot/dts/omap3-beagle.dts| 8
2 files changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 31a632f..b39918e 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -215,3 +215,11 @@
usbhsehci {
phys = 0 hsusb2_phy;
};
+
+vaux2 {
+ regulator-name = usb_1v8;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+};
+
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index fa532aa..9764556 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -178,3 +178,11 @@
mode = 3;
power = 50;
};
+
+vaux2 {
+ regulator-name = vdd_ehci;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+};
+
--
1.8.3.2
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: [RESEND PATCH v3 3/4] usb: musb: dsps, debugfs files
Hi,
On Mon, Nov 25, 2013 at 09:57:39AM -0600, Felipe Balbi wrote:
Hi,
On Mon, Nov 18, 2013 at 04:54:37PM +0100, Markus Pargmann wrote:
@@ -350,6 +373,30 @@ out:
return ret;
}
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
why ? just use the glue's device
I used this to have a more obvious relationship between musb-core
debugfs and musb-dsps debugfs. Otherwise we would have '47401400.usb'
for dsps and 'musb-hdrc.0.auto' for musb core.
But I can change it if you want.
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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: [RESEND PATCH v3 4/4] usb: musb: dsps, use devm_kzalloc
On Mon, Nov 25, 2013 at 09:58:04AM -0600, Felipe Balbi wrote: On Mon, Nov 18, 2013 at 04:54:38PM +0100, Markus Pargmann wrote: Signed-off-by: Markus Pargmann m...@pengutronix.de no commit log == no commit. Sorry, but I'll be very pedantic about it. Okay I will add a commit message. Regards, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: [RESEND PATCH v3 2/4] usb: musb: Bugfix of_node assignment
Hi,
On Mon, Nov 25, 2013 at 05:48:54PM +0100, Sebastian Andrzej Siewior wrote:
On 11/25/2013 05:14 PM, Felipe Balbi wrote:
Hi,
On Mon, Nov 18, 2013 at 04:54:36PM +0100, Markus Pargmann wrote:
It is not safe to assign the of_node to a device without driver.
The device is matched against a list of drivers and the of_node
could lead to a DT match with the parent driver.
Signed-off-by: Markus Pargmann m...@pengutronix.de ---
drivers/usb/musb/musb_core.c | 12 +++-
drivers/usb/musb/musb_dsps.c | 1 - 2 files changed, 11
insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c
b/drivers/usb/musb/musb_core.c index 8b7d903..d5ad9db 100644 ---
a/drivers/usb/musb/musb_core.c +++
b/drivers/usb/musb/musb_core.c @@ -1966,6 +1966,7 @@ static int
musb_probe(struct platform_device *pdev) int irq =
platform_get_irq_byname(pdev, mc); struct resource *iomem; void
__iomem*base; +int ret;
iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0); if
(!iomem || irq = 0) @@ -1975,7 +1976,16 @@ static int
musb_probe(struct platform_device *pdev) if (IS_ERR(base)) return
PTR_ERR(base);
- return musb_init_controller(dev, irq, base); + if
(dev-parent)
don't we always have a parent?
+ dev-of_node = dev-parent-of_node; + +ret =
musb_init_controller(dev, irq, base); +if (ret) { +
dev-of_node = NULL; + return ret; + } + + return 0; }
static int musb_remove(struct platform_device *pdev) diff --git
a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 82e1da0..7b36d32 100644 --- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c @@ -485,7 +485,6 @@ static int
dsps_create_musb_pdev(struct dsps_glue *glue, musb-dev.parent
=
dev; musb-dev.dma_mask= musb_dmamask;
musb-dev.coherent_dma_mask= musb_dmamask; -
musb-dev.of_node
= of_node_get(dn);
Sebastian, does this look correct to you ?
Is this fixing a bug? Commit 4fc4b2 (usb: musb: dsps: do not bind to
musb-hdrc) [0] should fix the problem that is described here.
ux500 is affected by the same problem as dsps but it is only visible on
dsps because we DEFER probe for few reasons there test the fail path.
Sorry, I didn't check again if this is fixed by some applied patches. I
first discovered this bug in september and send this patch in october.
It is the same bug.
So by just looking at it should fix the same problem as the change I
cited _but_ it would also cover ux500. Currently I can't think of any
side effects by assigning of_node if the musb_init_*() did not do it.
If we take this in I would suggest to remove the check I added (because
it does no longer serve any purpose) and the description (why we do
this, what is the problem exactly) is could be taken from my patch
since I think it is better described (it safe to assign a node to a
driver, it becomes unsafe if after platform_probe _also_ the DT probe
is executed which was not to designed to work like this).
Your patch is already applied, so I could simply drop this one.
Regards,
Markus
In the long term I would suggest to move the DT probe over to the musb
core code and we wouldn't need the node assignment anymore…
[0] http://www.spinics.net/lists/linux-usb/msg94701.html
Sebastian
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks
On 26 November 2013 00:10, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, November 25, 2013 01:40:21 PM Ulf Hansson wrote:
To put devices into low power state during sleep, it sometimes makes
sense at subsystem-level to re-use device's runtime PM callbacks.
The PM core will at device_suspend_late disable runtime PM, after that
we can safely operate on these callbacks. At suspend_late the device
will be put into low power state by invoking the device's
runtime_suspend callback, unless the runtime status is already
suspended. At resume_early the state is restored by invoking the
device's runtime_resume callback. Soon after the PM core will re-enable
runtime PM before returning from device_resume_early.
The new pm_generic functions are named pm_generic_suspend_late_runtime
and pm_generic_resume_early_runtime, they are supposed to be used in
pairs.
What happens if the subsystem uses the new functions as its late suspend/
early resume callbacks, but some of its drivers implement .suspend_late()
and .resume_early()?
Good point. Normally, I think the decision of using these callbacks
should be taken at the lowest level, in other words in the driver.
Otherwise the lowest layer of .suspend_late will be by-passed.
Do you think subsystem-level is too vague to indicate that? Should
we say driver-level in the functions comment field instead?
Also, these are system suspend/resume callbacks, so the runtime part of
the names is kind of confusing. I have no idea for better naming at this
point, but still.
Somehow I would like to indicate that it is actually the runtime
callbacks that will be indirectly invoked. Besides that, I would
happily change to whatever you propose. :-)
Do note that these new generic callbacks will work smothly even with
and without CONFIG_PM_RUNTIME, as long as the runtime PM callbacks are
implemented inside CONFIG_PM instead of CONFIG_PM_RUNTIME.
A special thanks to Alan Stern who came up with this idea.
Cc: Kevin Hilman khil...@linaro.org
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/base/power/generic_ops.c | 86
++
include/linux/pm.h |2 +
2 files changed, 88 insertions(+)
diff --git a/drivers/base/power/generic_ops.c
b/drivers/base/power/generic_ops.c
index 5ee030a..3132768 100644
--- a/drivers/base/power/generic_ops.c
+++ b/drivers/base/power/generic_ops.c
@@ -93,6 +93,49 @@ int pm_generic_suspend_late(struct device *dev)
EXPORT_SYMBOL_GPL(pm_generic_suspend_late);
/**
+ * pm_generic_suspend_late_runtime - Generic suspend_late callback for
+ * subsystems that wants to use runtime_suspend callbacks at suspend_late.
This has to be one line. You can add more description below the @dev line.
OK
+ * @dev: Device to suspend.
+ */
+int pm_generic_suspend_late_runtime(struct device *dev)
+{
+ int (*callback)(struct device *);
+ int ret = 0;
+
+ /*
+ * PM core has disabled runtime PM in device_suspend_late, thus we can
+ * safely check the device's runtime status and decide whether
+ * additional actions are needed to put the device into low power
state.
+ * If so, we invoke the device's runtime_suspend callback.
+ * For the !CONFIG_PM_RUNTIME case, pm_runtime_status_suspended()
always
+ * returns false and therefore the runtime_suspend callback will be
+ * invoked.
+ */
+ if (pm_runtime_status_suspended(dev))
+ return 0;
+
+ if (dev-pm_domain)
+ callback = dev-pm_domain-ops.runtime_suspend;
+ else if (dev-type dev-type-pm)
+ callback = dev-type-pm-runtime_suspend;
+ else if (dev-class dev-class-pm)
+ callback = dev-class-pm-runtime_suspend;
+ else if (dev-bus dev-bus-pm)
+ callback = dev-bus-pm-runtime_suspend;
+ else
+ callback = NULL;
+
+ if (!callback dev-driver dev-driver-pm)
+ callback = dev-driver-pm-runtime_suspend;
+
+ if (callback)
+ ret = callback(dev);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pm_generic_suspend_late_runtime);
+
+/**
* pm_generic_suspend - Generic suspend callback for subsystems.
* @dev: Device to suspend.
*/
@@ -237,6 +280,49 @@ int pm_generic_resume_early(struct device *dev)
EXPORT_SYMBOL_GPL(pm_generic_resume_early);
/**
+ * pm_generic_resume_early_runtime - Generic resume_early callback for
+ * subsystems that wants to use runtime_resume callbacks at resume_early.
Same here.
OK
+ * @dev: Device to resume.
+ */
+int pm_generic_resume_early_runtime(struct device *dev)
+{
+ int (*callback)(struct device *);
+ int ret = 0;
+
+ /*
+ * PM core has not yet enabled runtime PM in device_resume_early,
+ * thus we can safely check the device's runtime status and restore the
+ * previous state we had in
Re: Need help to support USB3.0 HID Keyboard device
On Friday 22 November 2013 10:25 PM, Greg KH wrote: On Fri, Nov 22, 2013 at 04:47:10PM +0530, Bhavik Kothari wrote: Hi, I have been working on USB3.0 device driver and wanted to support USB3.0 HID (keyboard). To support HID Keyboard device, I have made below Interface descriptor: Interface Descriptor with alternate settings 0: bLength = 0x9; bDescriptorType = 0x4 (USB_DT_INTERFACE); bInterfaceNumber = 0x0; bAlternateSetting = 0x0; bNumEndpoints = 0x0; bInterfaceClass = (0x3) USB_CLASS_HID; bInterfaceSubClass = 0x0; bInterfaceProtocol = 0x1 (keyboard); iInterface = 0x0; Interface Descriptor with alternate settings 1 along with Super speed endpoints: bLength = 0x9; bDescriptorType = 0x4 (USB_DT_INTERFACE); bInterfaceNumber = 0x0; bAlternateSetting = 0x1; bNumEndpoints = 0x2; (One for EP IN Interrupt and other for EP OUT Interrupt) bInterfaceClass = (0x3) USB_CLASS_HID; bInterfaceSubClass = 0x0; bInterfaceProtocol = 0x1 (keyboard); iInterface = 0x0; However, when xHCI does set_config at that time Interface zero and alternate setting is zero, it never does set_interface with interface zero and alternate setting one, hence host does not detect HID device. So, would you please assist me that what I have to do, so host does set interface with alternate setting one. It's up to a userspace program to switch to the alternate interface, right? The OS can't just know to do that without some type of interaction from you. Have you run your device under the USB verification test suite for Windows? I suggest you do that first, to ensure the firmware is working properly before worrying about how Linux is handling the device. thanks, greg k-h . Hi Greg, Yes, I have run USB3.0 device with USB verification test suite (USB3.0 CV) for Windows, and it passes all test points. However, with same implementation, host does not issue set interface with alternate setting one. I am not sure what to do either from device or Host side, so, Host (xHCI) issues set interface with interface number zero or any other with alternate setting one or more than zero (because alternate setting zero is alloted for control ep, if transfer type is periodic (Interrupt / Isochronous)) Can you please assist me on this, what should I do / implement? Thanks, Bhavik Kothari -- 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/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls
Hi,
On Monday 25 November 2013 11:45 PM, Matt Porter wrote:
This adds a pair of APIs that allows the generic PHY subsystem to
provide information on the PHY bus width. The PHY provider driver may
use phy_set_bus_width() to set the bus width that the PHY supports.
The controller driver may then use phy_get_bus_width() to fetch the
PHY bus width in order to properly configure the controller.
Signed-off-by: Matt Porter matt.por...@linaro.org
---
include/linux/phy/phy.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 6d72269..6ca6c61 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -46,6 +46,7 @@ struct phy_ops {
* @mutex: mutex to protect phy_ops
* @init_count: used to protect when the PHY is used by multiple consumers
* @power_count: used to protect when the PHY is used by multiple consumers
+ * @bus_width: used to specify data width of the PHY bus
*/
struct phy {
struct device dev;
@@ -55,6 +56,7 @@ struct phy {
struct mutexmutex;
int init_count;
int power_count;
+ int bus_width;
the bus_width can be part of the attrs struct which you initially proposed.
Soon there will be requests for other attributes being added (e.g., speed).
};
/**
@@ -127,6 +129,14 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
+static inline int phy_get_bus_width(struct phy *phy)
+{
+ return phy-bus_width;
+}
+static inline void phy_set_bus_width(struct phy *phy, int bus_width)
u32 bus_width?
+{
+ phy-bus_width = bus_width;
+}
struct phy *phy_get(struct device *dev, const char *string);
struct phy *devm_phy_get(struct device *dev, const char *string);
void phy_put(struct phy *phy);
@@ -199,6 +209,16 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
+static inline int phy_get_bus_width(struct phy *phy)
+{
+ return -ENOSYS;
+}
+
+static inline void phy_set_bus_width(struct phy *phy, bus_width)
er.. has this been compile tested?
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/9] staging: dwc2: update DT binding to add generic clock/phy properties
On Monday 25 November 2013 11:46 PM, Matt Porter wrote: dwc2/s3c-hsotg require a single clock to be specified and optionally a generic phy. On the s3c-hsotg driver old style USB phy support is present as a fallback so the generic phy properties are optional. Signed-off-by: Matt Porter matt.por...@linaro.org --- Documentation/devicetree/bindings/staging/dwc2.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt b/Documentation/devicetree/bindings/staging/dwc2.txt index 1a1b7cf..b8b42b6 100644 --- a/Documentation/devicetree/bindings/staging/dwc2.txt +++ b/Documentation/devicetree/bindings/staging/dwc2.txt @@ -5,6 +5,12 @@ Required properties: - compatible : snps,dwc2 - reg : Should contain 1 register range (address and length) - interrupts : Should contain 1 interrupt +- clocks: clock provider specifier +- clock-names: shall be otg +- phys: phy provider specifier +- phy-names: shall be device lets mention in the Documentation too that the phy properties are optional. apart from that.. Acked-by: Kishon Vijay Abraham I kis...@ti.com +Refer to clk/clock-bindings.txt for generic clock consumer properties +Refer to phy/phy-bindings.txt for generic phy consumer properties Example: @@ -12,4 +18,8 @@ Example: compatible = ralink,rt3050-usb, snps,dwc2; reg = 0x101c 4; interrupts = 18; + clocks = usb_otg_ahb_clk; + clock-names = otg; + phys = usbphy; + phy-names = device; }; -- 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 5/9] usb: gadget: s3c-hsotg: use generic phy_init()/phy_exit() support
Hi, On Monday 25 November 2013 11:46 PM, Matt Porter wrote: If a generic phy is present, call phy_init()/phy_exit(). This supports generic phys that must be soft reset before power on. Signed-off-by: Matt Porter matt.por...@linaro.org --- drivers/usb/gadget/s3c-hsotg.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c index da3879b..8dfe33f 100644 --- a/drivers/usb/gadget/s3c-hsotg.c +++ b/drivers/usb/gadget/s3c-hsotg.c @@ -3622,6 +3622,9 @@ static int s3c_hsotg_probe(struct platform_device *pdev) goto err_supplies; } + if (hsotg-phy) IS_ERR? If your phy_get fails *phy* will have a error value.. + phy_init(hsotg-phy); + /* usb phy enable */ s3c_hsotg_phy_enable(hsotg); @@ -3715,6 +3718,8 @@ static int s3c_hsotg_remove(struct platform_device *pdev) } s3c_hsotg_phy_disable(hsotg); + if (hsotg-phy) same here. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/9] usb: gadget: s3c-hsotg: get phy bus width from phy subsystem
Hi,
On Monday 25 November 2013 11:46 PM, Matt Porter wrote:
Adds support for querying the phy bus width from the generic phy
subsystem. Configure UTMI bus width in GUSBCFG based on this value.
Signed-off-by: Matt Porter matt.por...@linaro.org
---
drivers/usb/gadget/s3c-hsotg.c | 14 +-
drivers/usb/gadget/s3c-hsotg.h | 1 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 8dfe33f..be41585 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -144,6 +144,7 @@ struct s3c_hsotg_ep {
* @regs: The memory area mapped for accessing registers.
* @irq: The IRQ number we are using
* @supplies: Definition of USB power supplies
+ * @phyif: PHY interface width
* @dedicated_fifos: Set if the hardware has dedicated IN-EP fifos.
* @num_of_eps: Number of available EPs (excluding EP0)
* @debug_root: root directrory for debugfs.
@@ -171,6 +172,7 @@ struct s3c_hsotg {
struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsotg_supply_names)];
+ u32 phyif;
unsigned intdedicated_fifos:1;
unsigned char num_of_eps;
@@ -2276,7 +2278,7 @@ static void s3c_hsotg_core_init(struct s3c_hsotg *hsotg)
*/
/* set the PLL on, remove the HNP/SRP and set the PHY */
- writel(GUSBCFG_PHYIf16 | GUSBCFG_TOutCal(7) |
+ writel(hsotg-phyif | GUSBCFG_TOutCal(7) |
(0x5 10), hsotg-regs + GUSBCFG);
s3c_hsotg_init_fifo(hsotg);
@@ -3622,6 +3624,16 @@ static int s3c_hsotg_probe(struct platform_device
*pdev)
goto err_supplies;
}
+ /* Set default UTMI width */
+ hsotg-phyif = GUSBCFG_PHYIf16;
+
+ /*
+ * If using the generic PHY framework, check if the PHY bus
+ * width is 8-bit and set the phyif appropriately.
+ */
+ if (hsotg-phy (phy_get_bus_width(phy) == 8))
what if the phy has error value here?
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 7/9] phy: add Broadcom Kona USB2 PHY DT binding
Hi, On Monday 25 November 2013 11:46 PM, Matt Porter wrote: Add a binding that describes the Broadcom Kona USB2 PHY found on the BCM281xx family of SoCs. Signed-off-by: Matt Porter matt.por...@linaro.org --- .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt new file mode 100644 index 000..3dc8b3d --- /dev/null +++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt you should name this bcm-phy. Then you can add binding info of all (future) PHY IP from broadcom here. other than that this looks fine.. Acked-by: Kishon Vijay Abraham I kis...@ti.com Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: musb: conditionally save and restore the context on suspend
Hello.
On 25-11-2013 23:39, Daniel Mack wrote:
It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.
The dsps platform does, however. So add a bit in struct
musb_hdrc_platform_data to let platforms specify their need of such
action being taken.
Signed-off-by: Daniel Mack zon...@gmail.com
[...]
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..e5a581c 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,6 +99,9 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8 mode;
+ /* should the musb core restore registers after suspend? */
+ u8 restore_after_suspend:1;
+
Better placement seems to be with 'extvbus' field which is also 1-bit --
that would save space in the structure.
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 1/5] usb: musb: conditionally save and restore the context on suspend
On 11/26/2013 11:50 AM, Sergei Shtylyov wrote:
On 25-11-2013 23:39, Daniel Mack wrote:
It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.
The dsps platform does, however. So add a bit in struct
musb_hdrc_platform_data to let platforms specify their need of such
action being taken.
Signed-off-by: Daniel Mack zon...@gmail.com
[...]
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..e5a581c 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,6 +99,9 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8 mode;
+/* should the musb core restore registers after suspend? */
+u8 restore_after_suspend:1;
+
Better placement seems to be with 'extvbus' field which is also 1-bit --
that would save space in the structure.
That patch is deprecated, as things are now done unconditionally,
without consulting this flag.
Daniel
--
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/2] PM / Runtime: Add second macro for definition of runtime PM callbacks
It is allowed and will in many cases make sense to have the runtime PM
callbacks to be defined for CONFIG_PM instead of CONFIG_PM_RUNTIME.
Since the PM core disables runtime PM during system suspend, before the
.suspend_late callbacks are invoked, drivers could at this point
directly invoke it's runtime PM callbacks or even walk through it's bus
or power domain, to put it's device into low power state.
Use the new macro SET_PM_RUNTIME_PM_OPS in cases were the above makes
sense. Make sure the callbacks are encapsulated within CONFIG_PM
instead of CONFIG_PM_RUNTIME.
Do note that the old macro SET_RUNTIME_PM_OPS, which is being quite
widely used right now, requires the callbacks to be defined for
CONFIG_PM_RUNTIME. In many cases it will certainly be convenient to
convert to the new macro above, but still some cases are optimal for
only CONFIG_PM_RUNTIME.
Cc: Kevin Hilman khil...@linaro.org
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
include/linux/pm.h |9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index a224c7f..7a830a7 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -320,6 +320,15 @@ struct dev_pm_ops {
#define SET_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn)
#endif
+#ifdef CONFIG_PM
+#define SET_PM_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn) \
+ .runtime_suspend = suspend_fn, \
+ .runtime_resume = resume_fn, \
+ .runtime_idle = idle_fn,
+#else
+#define SET_PM_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn)
+#endif
+
/*
* Use this if you want to use the same suspend and resume callbacks for
suspend
* to RAM and hibernation.
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] PM / Sleep: Add macro to define common late/early system PM callbacks
We use the same approach as for the existing SET_SYSTEM_SLEEP_PM_OPS,
but for the late and early callbacks instead.
The new SET_LATE_SYSTEM_SLEEP_PM_OPS, defined for CONFIG_PM_SLEEP, will
point -suspend_late, -freeze_late and -poweroff_late to the same
function. Vice verse happens for -resume_early, -thaw_early and
-restore_early.
Cc: Kevin Hilman khil...@linaro.org
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
include/linux/pm.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 7a830a7..8c6583a 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -311,6 +311,18 @@ struct dev_pm_ops {
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
#endif
+#ifdef CONFIG_PM_SLEEP
+#define SET_LATE_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
+ .suspend_late = suspend_fn, \
+ .resume_early = resume_fn, \
+ .freeze_late = suspend_fn, \
+ .thaw_early = resume_fn, \
+ .poweroff_late = suspend_fn, \
+ .restore_early = resume_fn,
+#else
+#define SET_LATE_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
+#endif
+
#ifdef CONFIG_PM_RUNTIME
#define SET_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn) \
.runtime_suspend = suspend_fn, \
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Xhci Host not allowed to send get device desc at addr zero
Hi, I'm using Kernel release 3.4 with an embedded xhci host controller Seems USB core driver does not allow xhci controller to send a get device descriptor at address zero As when a device is attached to the root hub, usb core driver reset the device and if the link is superspeed than do a set_address LeCroy Compliance test TD7.06 Data Payload Packet Framing Robustness test script expects for get device descriptor at @ zero from host How to let xhci controller sending a get device descriptor command before setting an address to USB3 device ? Thanks, Aymen -- 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/4 V2] ARM: mx28: Add USB PHY overcurrent pinmux
The GPIO is working for this pin. But also the DIGCTL register bits helped here. Now the OC event triggers if the pin gets pulled to 3V3. I am currently looking for a good place to enable the DIGCTL bits. I suggest to enable them per default. As we don't have USBMISC registers in MX28, the bits should be toggled in ci_hdrc_imx.c if the of property disable-overcurrent is not found. I will use the syscon interface to reach them with the regmap interface. Hi Michael, usbmisc register doesn't stand for the register needs to be in usb controller. Any registers which are related to USB function can be considered as usbmisc registers. You will see FSL-style SoC, the over-current or other related setting are at controller base + 0x800 (0x600), but Sigmatel-style SoC (mx28/mx23), the usb register are not at controller register region. My suggestion is: create usbmisc node for mx28, and put oc setting at there, it can keep ci_hdrc_imx.c clean. Besides, you may need two dts user setting for oc enable and oc polarity. Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] usb: musb: dsps: add support for suspend and resume
On 11/25/2013 10:32 PM, Felipe Balbi wrote:
On Mon, Nov 25, 2013 at 10:30:37PM +0100, Daniel Mack wrote:
On 11/25/2013 10:29 PM, Felipe Balbi wrote:
Hi,
On Mon, Nov 25, 2013 at 10:26:43PM +0100, Daniel Mack wrote:
+static int dsps_resume(struct device *dev)
+{
+ struct dsps_glue *glue = dev_get_drvdata(dev);
+ const struct dsps_musb_wrapper *wrp = glue-wrp;
+ struct musb *musb = platform_get_drvdata(glue-musb);
+ void __iomem *mbase = musb-ctrl_base;
+
+ dsps_writel(mbase, wrp-control, glue-context.control);
+ dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+ dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+ dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+ dsps_writel(mbase, wrp-mode, glue-context.mode);
+ dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+ dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+ //musb_port_reset(musb, false);
Urgs. Development left-over. Sorry. You want me to resend the whole
series or just this last patch?
just the last patch is fine :-)
Sorry, there was one more hunk that shouldn't be there. I'll resend a v4
with all the patches included again, for reference.
--
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 0/4] musb/dsps: suspend related patches for 3.14 (rebased)
v2 - v3:
* removed a development left-over
v3 - v4:
* one hunk removed that sneaked in during rebasing
Daniel Mack (4):
usb: musb: unconditionally save and restore the context on suspend
usb: musb: call musb_port_suspend from musb_bus_suspend
usb: musb: dsps: add {tx,rx}_mode to wrapper
usb: musb: dsps: add support for suspend and resume
drivers/usb/musb/musb_core.c| 14 +-
drivers/usb/musb/musb_dsps.c| 61 +
drivers/usb/musb/musb_host.c| 9 +-
drivers/usb/musb/musb_host.h| 4 +++
drivers/usb/musb/musb_virthub.c | 4 +--
include/linux/usb/musb.h| 3 ++
6 files changed, 91 insertions(+), 4 deletions(-)
--
1.8.4.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 v4 4/4] usb: musb: dsps: add support for suspend and resume
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.
We also have to explicitly de-assert the port reset upon resume on this
platform, but musb_port_reset() should not be called from glue layers.
Hence, introduce a flag in struct musb_hdrc_config for this.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_dsps.c| 57 +
drivers/usb/musb/musb_host.c| 7 -
drivers/usb/musb/musb_host.h| 2 ++
drivers/usb/musb/musb_virthub.c | 2 +-
include/linux/usb/musb.h| 3 +++
5 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index e57d712..3600af0 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8 poll_seconds;
};
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+ u32 control;
+ u32 epintr;
+ u32 coreintr;
+ u32 phy_utmi;
+ u32 mode;
+ u32 tx_mode;
+ u32 rx_mode;
+};
+
/**
* DSPS glue structure.
*/
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+ struct dsps_context context;
};
static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -509,6 +524,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
+ config-host_port_deassert_reset_at_resume = 1;
pdata.mode = get_musb_port_mode(dev);
/* DT keeps this entry in mA, musb expects it as per USB spec */
pdata.power = get_int_prop(dn, mentor,power) / 2;
@@ -632,11 +648,52 @@ static const struct of_device_id musb_dsps_of_match[] = {
};
MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+ struct dsps_glue *glue = dev_get_drvdata(dev);
+ const struct dsps_musb_wrapper *wrp = glue-wrp;
+ struct musb *musb = platform_get_drvdata(glue-musb);
+ void __iomem *mbase = musb-ctrl_base;
+
+ glue-context.control = dsps_readl(mbase, wrp-control);
+ glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+ glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+ glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+ glue-context.mode = dsps_readl(mbase, wrp-mode);
+ glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+ glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+ return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+ struct dsps_glue *glue = dev_get_drvdata(dev);
+ const struct dsps_musb_wrapper *wrp = glue-wrp;
+ struct musb *musb = platform_get_drvdata(glue-musb);
+ void __iomem *mbase = musb-ctrl_base;
+
+ dsps_writel(mbase, wrp-control, glue-context.control);
+ dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+ dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+ dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+ dsps_writel(mbase, wrp-mode, glue-context.mode);
+ dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+ dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
static struct platform_driver dsps_usbss_driver = {
.probe = dsps_probe,
.remove = dsps_remove,
.driver = {
.name = musb-dsps,
+ .pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
};
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 81caf9f..8224138 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2464,7 +2464,12 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
static int musb_bus_resume(struct usb_hcd *hcd)
{
- /* resuming child port does the work */
+ struct musb *musb = hcd_to_musb(hcd);
+
+ if (musb-config
+ musb-config-host_port_deassert_reset_at_resume)
+ musb_port_reset(musb, false);
+
return 0;
}
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index e660af9..7436c24 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
extern void musb_host_resume_root_hub(struct musb *musb);
extern void
[PATCH v4 2/4] usb: musb: call musb_port_suspend from musb_bus_suspend
Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_host.c| 2 ++
drivers/usb/musb/musb_host.h| 2 ++
drivers/usb/musb/musb_virthub.c | 2 +-
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 6582a20..81caf9f 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8 devctl;
+ musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..e660af9 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
extern void musb_root_disconnect(struct musb *musb);
extern void musb_host_resume_root_hub(struct musb *musb);
extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
#else
static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
{
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)
{}
static inline void musb_host_resume_root_hub(struct musb *musb){}
static inline void musb_host_poll_rh_status(struct musb *musb) {}
static inline void musb_host_poke_root_hub(struct musb *musb) {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
#endif
struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 9af6bba..e977441 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -44,7 +44,7 @@
#include musb_core.h
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
{
struct usb_otg *otg = musb-xceiv-otg;
u8 power;
--
1.8.4.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 v4 3/4] usb: musb: dsps: add {tx,rx}_mode to wrapper
rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_dsps.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1901f6f..e57d712 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -83,6 +83,8 @@ struct dsps_musb_wrapper {
u16 coreintr_status;
u16 phy_utmi;
u16 mode;
+ u16 tx_mode;
+ u16 rx_mode;
/* bit positions for control */
unsignedreset:5;
@@ -605,6 +607,8 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.coreintr_status= 0x34,
.phy_utmi = 0xe0,
.mode = 0xe8,
+ .tx_mode= 0x70,
+ .rx_mode= 0x74,
.reset = 0,
.otg_disable= 21,
.iddig = 8,
--
1.8.4.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 v4 1/4] usb: musb: unconditionally save and restore the context on suspend
It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.
The dsps platform does, however, and because it should cause any trouble
on other platforms, do it unconditionally.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_core.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0a43329..797709d 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2215,16 +2215,28 @@ static int musb_suspend(struct device *dev)
*/
}
+ musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
}
static int musb_resume_noirq(struct device *dev)
{
- /* for static cmos like DaVinci, register values were preserved
+ struct musb *musb = dev_to_musb(dev);
+
+ /*
+* For static cmos like DaVinci, register values were preserved
* unless for some reason the whole soc powered down or the USB
* module got reset through the PSC (vs just being disabled).
+*
+* For the DSPS glue layer though, a full register restore has to
+* be done. As it shouldn't harm other platforms, we do it
+* unconditionally.
*/
+
+ musb_restore_context(musb);
+
return 0;
}
--
1.8.4.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 v6 3/3] usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28
Due to imx28 needs ARM swp instruction for writing, we set
CI_HDRC_IMX28_WRITE_FIX for imx28.
Signed-off-by: Peter Chen peter.c...@freescale.com
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
drivers/usb/chipidea/ci_hdrc_imx.c | 32 ++--
1 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 023d3cb..68f7f5e 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -23,6 +23,26 @@
#include ci.h
#include ci_hdrc_imx.h
+#define CI_HDRC_IMX_IMX28_WRITE_FIX BIT(0)
+
+struct ci_hdrc_imx_platform_flag {
+ unsigned int flags;
+};
+
+static const struct ci_hdrc_imx_platform_flag imx27_usb_data = {
+};
+
+static const struct ci_hdrc_imx_platform_flag imx28_usb_data = {
+ .flags = CI_HDRC_IMX_IMX28_WRITE_FIX,
+};
+
+static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
+ { .compatible = fsl,imx28-usb, .data = imx28_usb_data},
+ { .compatible = fsl,imx27-usb, .data = imx27_usb_data},
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ci_hdrc_imx_dt_ids);
+
struct ci_hdrc_imx_data {
struct usb_phy *phy;
struct platform_device *ci_pdev;
@@ -82,6 +102,9 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
CI_HDRC_DISABLE_STREAMING,
};
int ret;
+ const struct of_device_id *of_id =
+ of_match_device(ci_hdrc_imx_dt_ids, pdev-dev);
+ const struct ci_hdrc_imx_platform_flag *imx_platform_flag = of_id-data;
data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
if (!data) {
@@ -115,6 +138,9 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
pdata.phy = data-phy;
+ if (imx_platform_flag-flags CI_HDRC_IMX_IMX28_WRITE_FIX)
+ pdata.flags |= CI_HDRC_IMX28_WRITE_FIX;
+
if (!pdev-dev.dma_mask)
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
if (!pdev-dev.coherent_dma_mask)
@@ -174,12 +200,6 @@ static int ci_hdrc_imx_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
- { .compatible = fsl,imx27-usb, },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, ci_hdrc_imx_dt_ids);
-
static struct platform_driver ci_hdrc_imx_driver = {
.probe = ci_hdrc_imx_probe,
.remove = ci_hdrc_imx_remove,
--
1.7.8
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/3] usb: ehci+chipidea: fix imx28 ENGR119653 USB: ARM to USB register error issue
Changes for v6: - Add volatile for arm swp instruction, since we need io access to fix this problem - Add kernel style comment for imx28_write_fix Peter Chen (3): usb: ehci: add freescale imx28 special write register method usb: chipidea: add freescale imx28 special write register method usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28 drivers/usb/chipidea/ci.h | 26 -- drivers/usb/chipidea/ci_hdrc_imx.c | 32 ++-- drivers/usb/chipidea/core.c|2 ++ drivers/usb/chipidea/host.c|1 + drivers/usb/host/ehci.h| 18 +- include/linux/usb/chipidea.h |1 + 6 files changed, 71 insertions(+), 9 deletions(-) -- 1.7.8 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/3] usb: chipidea: add freescale imx28 special write register method
According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
register error issue, All USB register write operations must
use the ARM SWP instruction. So, we implement special hw_write
and hw_test_and_clear for imx28.
Discussion for it at below:
http://marc.info/?l=linux-usbm=137996395529294w=2
Signed-off-by: Peter Chen peter.c...@freescale.com
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
drivers/usb/chipidea/ci.h| 26 --
drivers/usb/chipidea/core.c |2 ++
drivers/usb/chipidea/host.c |1 +
include/linux/usb/chipidea.h |1 +
4 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 1c94fc5..f66bc24 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -135,6 +135,7 @@ struct hw_bank {
* @id_event: indicates there is an id event, and handled at ci_otg_work
* @b_sess_valid_event: indicates there is a vbus event, and handled
* at ci_otg_work
+ * @imx28_write_fix: Freescale imx28 needs swp instruction for writing
*/
struct ci_hdrc {
struct device *dev;
@@ -173,6 +174,7 @@ struct ci_hdrc {
struct dentry *debugfs;
boolid_event;
boolb_sess_valid_event;
+ boolimx28_write_fix;
};
static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
@@ -253,6 +255,26 @@ static inline u32 hw_read(struct ci_hdrc *ci, enum
ci_hw_regs reg, u32 mask)
return ioread32(ci-hw_bank.regmap[reg]) mask;
}
+#ifdef CONFIG_SOC_IMX28
+static inline void imx28_ci_writel(u32 val, volatile void __iomem *addr)
+{
+ __asm__ (swp %0, %0, [%1] : : r(val), r(addr));
+}
+#else
+static inline void imx28_ci_writel(u32 val, volatile void __iomem *addr)
+{
+}
+#endif
+
+static inline void __hw_write(struct ci_hdrc *ci, u32 val,
+ void __iomem *addr)
+{
+ if (IS_ENABLED(CONFIG_SOC_IMX28) ci-imx28_write_fix)
+ imx28_ci_writel(val, addr);
+ else
+ iowrite32(val, addr);
+}
+
/**
* hw_write: writes to a hw register
* @reg: register index
@@ -266,7 +288,7 @@ static inline void hw_write(struct ci_hdrc *ci, enum
ci_hw_regs reg,
data = (ioread32(ci-hw_bank.regmap[reg]) ~mask)
| (data mask);
- iowrite32(data, ci-hw_bank.regmap[reg]);
+ __hw_write(ci, data, ci-hw_bank.regmap[reg]);
}
/**
@@ -281,7 +303,7 @@ static inline u32 hw_test_and_clear(struct ci_hdrc *ci,
enum ci_hw_regs reg,
{
u32 val = ioread32(ci-hw_bank.regmap[reg]) mask;
- iowrite32(val, ci-hw_bank.regmap[reg]);
+ __hw_write(ci, val, ci-hw_bank.regmap[reg]);
return val;
}
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 6e73f8c..5efdc9b 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -554,6 +554,8 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ci-dev = dev;
ci-platdata = dev-platform_data;
+ ci-imx28_write_fix = !!(ci-platdata-flags
+ CI_HDRC_IMX28_WRITE_FIX);
ret = hw_device_init(ci, base);
if (ret 0) {
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 59e6020..06fd042 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -65,6 +65,7 @@ static int host_start(struct ci_hdrc *ci)
ehci-caps = ci-hw_bank.cap;
ehci-has_hostpc = ci-hw_bank.lpm;
ehci-has_tdi_phy_lpm = ci-hw_bank.lpm;
+ ehci-imx28_write_fix = ci-imx28_write_fix;
if (ci-platdata-reg_vbus) {
ret = regulator_enable(ci-platdata-reg_vbus);
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 7d39967..708bd11 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -24,6 +24,7 @@ struct ci_hdrc_platform_data {
* but otg is not supported (no register otgsc).
*/
#define CI_HDRC_DUAL_ROLE_NOT_OTG BIT(4)
+#define CI_HDRC_IMX28_WRITE_FIXBIT(5)
enum usb_dr_modedr_mode;
#define CI_HDRC_CONTROLLER_RESET_EVENT 0
#define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
--
1.7.8
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/3] usb: ehci: add freescale imx28 special write register method
According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
register error issue, All USB register write operations must
use the ARM SWP instruction. So, we implement a special ehci_write
for imx28.
Discussion for it at below:
http://marc.info/?l=linux-usbm=137996395529294w=2
Signed-off-by: Peter Chen peter.c...@freescale.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
drivers/usb/host/ehci.h | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index e8f41c5..4a320ab 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -225,6 +225,7 @@ struct ehci_hcd { /* one per controller */
unsignedhas_synopsys_hc_bug:1; /* Synopsys HC */
unsignedframe_index_bug:1; /* MosChip (AKA NetMos) */
unsignedneed_oc_pp_cycle:1; /* MPC834X port power */
+ unsignedimx28_write_fix:1; /* For Freescale i.MX28 */
/* required for usb32 quirk */
#define OHCI_CTRL_HCFS (3 6)
@@ -728,6 +729,18 @@ static inline unsigned int ehci_readl(const struct
ehci_hcd *ehci,
#endif
}
+#ifdef CONFIG_SOC_IMX28
+static inline void imx28_ehci_writel(const unsigned int val,
+ volatile __u32 __iomem *addr)
+{
+ __asm__ (swp %0, %0, [%1] : : r(val), r(addr));
+}
+#else
+static inline void imx28_ehci_writel(const unsigned int val,
+ volatile __u32 __iomem *addr)
+{
+}
+#endif
static inline void ehci_writel(const struct ehci_hcd *ehci,
const unsigned int val, __u32 __iomem *regs)
{
@@ -736,7 +749,10 @@ static inline void ehci_writel(const struct ehci_hcd *ehci,
writel_be(val, regs) :
writel(val, regs);
#else
- writel(val, regs);
+ if (IS_ENABLED(CONFIG_SOC_IMX28) ehci-imx28_write_fix)
+ imx28_ehci_writel(val, regs);
+ else
+ writel(val, regs);
#endif
}
--
1.7.8
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/3] usb: ehci+chipidea: fix imx28 ENGR119653 USB: ARM to USB register error issue
On 11/26/2013 01:11 PM, Peter Chen wrote: Changes for v6: - Add volatile for arm swp instruction, since we need io access to fix this problem - Add kernel style comment for imx28_write_fix Looks good now. I'll send you my Tested-by this afternoon. tnx, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: Xhci Host not allowed to send get device desc at addr zero
Hi Aymen On Tue, Nov 26, 2013 at 4:31 PM, Aymen BOUATTAY aymen.bouat...@st.com wrote: Hi, I'm using Kernel release 3.4 with an embedded xhci host controller Seems USB core driver does not allow xhci controller to send a get device descriptor at address zero As when a device is attached to the root hub, usb core driver reset the device and if the link is superspeed than do a set_address LeCroy Compliance test TD7.06 Data Payload Packet Framing Robustness test script expects for get device descriptor at @ zero from host How to let xhci controller sending a get device descriptor command before setting an address to USB3 device ? It does not work because USE_NEW_SCHEME has not been enabled for super speed devices. I see following comment An xHCI controller cannot send any packets to a device until a set address command successfully completes. in commit c6515272b858742962c1de0f3bf497a048b9abd7 Author: Sarah Sharp sarah.a.sh...@linux.intel.com Date: Mon Apr 27 19:57:26 2009 -0700 USB: Support for addressing a USB device under xHCI Hi Sarah, But as per usb3.0 specs section 9.4.3 get descriptor should be allowed in default state. xhci specs is not very clear about it. xhci specs says once a successful address device command has completed, system software can issue USB GET_DESCRIPTOR request through Default Control Endpoint to retrieve the USB Device, configuration, etc. descriptors from USB device. So, what if XHCI Software issues, SET ADDRESS(0) followed by GET DESC(Device). Regards Pratyush Thanks, Aymen -- 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 -- 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 10/12] usb: r8a66597-hcd: Convert to clk_prepare/unprepare
Hi Greg, On Monday 25 November 2013 18:36:08 Greg Kroah-Hartman wrote: On Tue, Nov 26, 2013 at 03:00:30AM +0100, Laurent Pinchart wrote: On Saturday 09 November 2013 08:10:59 Greg Kroah-Hartman wrote: On Sat, Nov 09, 2013 at 03:12:05PM +0100, Laurent Pinchart wrote: On Tuesday 29 October 2013 18:47:26 Shimoda, Yoshihiro wrote: Hi Laurent-san, (2013/10/29 7:49), Laurent Pinchart wrote: Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and clk_disable_unprepare() to get ready for the migration to the common clock framework. Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Cc: linux-usb@vger.kernel.org Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Thank you for the patch. Acked-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Could you please pick this patch up ? I'll pick things up after 3.13-rc1 is out, I can't do anything until then. Sure. As this patch is a dependency for other series that will go through different trees, could you please provide a stable branch in your tree with this patch included that you will push to v3.14 ? If you need this for other work, feel free to take it in your tree, I have no real need for it to go in mine. Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Sounds good to me, thanks. Simon, could you please pick this patch then ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: zte_ev not properly handling ZTE AC2726 CDMA modems
On Mon, Nov 25, 2013 at 06:15:28PM -0800, Dmitry Kunilov wrote:
Hi everyone,
As a late follow-up to the discussion that happened in June about moving
support for most ZTE CDMA devices from option.c to zte_ev.c (where the
decision was to convert and see if anyone complains), I'd like to complain
:)
We have a park of approximately thirty ZTE AC2726 EVDO modems connected to
Broadcom-based routers running Linux-mips. After recent upgrade from ancient
2.6.22 to relatively modern 3.9.11, all 30 are having the same problem: pppd
connects and Internet access works for 20 to 60 seconds, then connectivity
drops and pppd logs an LCP timeout. After that, pppd is able to restart the
connection and run for another 20-60 seconds.
I did notice that these modems are now handled by zte_ev instead of option,
so I went and moved all the DEVICE_INFO's back from zte_ev.c to option.c and
also disabled zte_ev module in the kernel configuration. After this change,
the modems work just fine, like they did on 2.6.22 - using the option
driver.
Please let me know if there is any debug info I can collect to help resolve
this issue.
Would you mind trying the patch below (against v3.12)?
Thanks,
Johan
From a84412903e68e9e5ae4693ddd1fa7d9c780cbd28 Mon Sep 17 00:00:00 2001
From: Johan Hovold jhov...@gmail.com
Date: Tue, 26 Nov 2013 15:26:49 +0100
Subject: [PATCH] USB: serial: zte_ev debug patch
Continue to read on errors.
Warn about failed reads and writes.
Increase zte_ev buffer sizes.
Fix race in write which could lead to (temporarily) degraded throughput
(backport of fix in Greg's usb-linus branch).
---
drivers/usb/serial/generic.c | 23 ---
drivers/usb/serial/zte_ev.c | 2 ++
2 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 1f31e6b4c251..b5d976ae1b0d 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -176,14 +176,7 @@ retry:
return result;
}
- /* Try sending off another urb, unless in irq context (in which case
-* there will be no free urb). */
- if (!in_irq())
- goto retry;
-
- clear_bit_unlock(USB_SERIAL_WRITE_BUSY, port-flags);
-
- return 0;
+ goto retry;
}
/**
@@ -369,15 +362,15 @@ void usb_serial_generic_read_bulk_callback(struct urb
*urb)
dev_dbg(port-dev, %s - urb %d, len %d\n, __func__, i,
urb-actual_length);
- if (urb-status) {
- dev_dbg(port-dev, %s - non-zero urb status: %d\n,
+ if (!urb-status) {
+ usb_serial_debug_data(port-dev, __func__, urb-actual_length,
+ data);
+ port-serial-type-process_read_urb(urb);
+ } else {
+ dev_warn(port-dev, %s - non-zero urb status: %d\n,
__func__, urb-status);
- return;
}
- usb_serial_debug_data(port-dev, __func__, urb-actual_length, data);
- port-serial-type-process_read_urb(urb);
-
/* Throttle the device if requested by tty */
spin_lock_irqsave(port-lock, flags);
port-throttled = port-throttle_req;
@@ -406,7 +399,7 @@ void usb_serial_generic_write_bulk_callback(struct urb *urb)
spin_unlock_irqrestore(port-lock, flags);
if (status) {
- dev_dbg(port-dev, %s - non-zero urb status: %d\n,
+ dev_warn(port-dev, %s - non-zero urb status: %d\n,
__func__, status);
spin_lock_irqsave(port-lock, flags);
diff --git a/drivers/usb/serial/zte_ev.c b/drivers/usb/serial/zte_ev.c
index fca4c752a4ed..36152e3e2605 100644
--- a/drivers/usb/serial/zte_ev.c
+++ b/drivers/usb/serial/zte_ev.c
@@ -307,6 +307,8 @@ static struct usb_serial_driver zio_device = {
},
.id_table = id_table,
.num_ports =1,
+ .bulk_in_size = 2048,
+ .bulk_out_size =2048,
.open = zte_ev_usb_serial_open,
.close =zte_ev_usb_serial_close,
};
--
1.8.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/3] usb: ehci+chipidea: fix imx28 ENGR119653 USB: ARM to USB register error issue
On 11/26/2013 01:44 PM, Marc Kleine-Budde wrote: On 11/26/2013 01:11 PM, Peter Chen wrote: Changes for v6: - Add volatile for arm swp instruction, since we need io access to fix this problem - Add kernel style comment for imx28_write_fix Looks good now. I'll send you my Tested-by this afternoon. Tested-by: Marc Kleine-Budde m...@pengutronix.de on $CUSTOMER mx28 hardware. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
[PATCH v2 1/2] usb: chipidea: usbmisc: Add support for i.MX27/i.MX31 CPUs
This adds i.MX27 and i.MX31 as the next user of the usbmisc driver.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
drivers/usb/chipidea/usbmisc_imx.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 8a1094b..4381c5a6 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -21,6 +21,10 @@
#define MX25_USB_PHY_CTRL_OFFSET 0x08
#define MX25_BM_EXTERNAL_VBUS_DIVIDER BIT(23)
+#define MX27_H1_PM_BIT BIT(8)
+#define MX27_H2_PM_BIT BIT(16)
+#define MX27_OTG_PM_BITBIT(24)
+
#define MX53_USB_OTG_PHY_CTRL_0_OFFSET 0x08
#define MX53_USB_UH2_CTRL_OFFSET 0x14
#define MX53_USB_UH3_CTRL_OFFSET 0x18
@@ -68,6 +72,36 @@ static int usbmisc_imx25_post(struct imx_usbmisc_data *data)
return 0;
}
+static int usbmisc_imx27_init(struct imx_usbmisc_data *data)
+{
+ unsigned long flags;
+ u32 val;
+
+ switch (data-index) {
+ case 0:
+ val = MX27_OTG_PM_BIT;
+ break;
+ case 1:
+ val = MX27_H1_PM_BIT;
+ break;
+ case 2:
+ val = MX27_H2_PM_BIT;
+ break;
+ default:
+ return -EINVAL;
+ };
+
+ spin_lock_irqsave(usbmisc-lock, flags);
+ if (data-disable_oc)
+ val = readl(usbmisc-base) | val;
+ else
+ val = readl(usbmisc-base) ~val;
+ writel(val, usbmisc-base);
+ spin_unlock_irqrestore(usbmisc-lock, flags);
+
+ return 0;
+}
+
static int usbmisc_imx53_init(struct imx_usbmisc_data *data)
{
void __iomem *reg = NULL;
@@ -128,6 +162,10 @@ static const struct usbmisc_ops imx25_usbmisc_ops = {
.post = usbmisc_imx25_post,
};
+static const struct usbmisc_ops imx27_usbmisc_ops = {
+ .init = usbmisc_imx27_init,
+};
+
static const struct usbmisc_ops imx53_usbmisc_ops = {
.init = usbmisc_imx53_init,
};
@@ -162,6 +200,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
.data = imx25_usbmisc_ops,
},
{
+ .compatible = fsl,imx27-usbmisc,
+ .data = imx27_usbmisc_ops,
+ },
+ {
.compatible = fsl,imx53-usbmisc,
.data = imx53_usbmisc_ops,
},
--
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 v2 2/2] usb: chipidea: usbmisc: Add support for i.MX51 CPU
This adds i.MX51 as the next user of the usbmisc driver.
Functionality is similar to i.MX53, so at this stage simply
reuse existing i.MX53 calls.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
drivers/usb/chipidea/usbmisc_imx.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 4381c5a6..cd061ab 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -204,6 +204,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
.data = imx27_usbmisc_ops,
},
{
+ .compatible = fsl,imx51-usbmisc,
+ .data = imx53_usbmisc_ops,
+ },
+ {
.compatible = fsl,imx53-usbmisc,
.data = imx53_usbmisc_ops,
},
--
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: Any good ways to sync udc status with gadget driver?
On Tue, 26 Nov 2013, Peter Chen wrote:
With runtime pm enabled udc driver, we may put controller to low
power mode when vbus is off or with SRP request. But gadget driver
may not know the udc status when it calls usb_ep_ops and usb_gadget_ops.
I meet this problem when I plug out usb cable from PC (using
g_mass_storage),
my callstack like: vbus interrupt-.vbus_session-composite_disconnect
-pm_runtime_put_sync(_gadget-dev), the composite_disconnect will
call fsg_disable, but fsg_disable calls usb_ep_disable using async way,
there are register accesses for usb_ep_disable. So sometimes, I get
system
hang due to visit register without clock, sometimes not.
Another use case is uvc, it enables dp pullup (call .pullup) by
application,
but at that time, the udc may be in low power mode.
The ways I can think for dealing with above cases:
- Add pm_runtime_get{_sync} and pm_runtime_put{_sync} during usb_ep_ops
and usb_gadget_ops APIs, it needs to change every runtime pm enabled
udc
driver's related APIs, I don't think it is a good way.
- Like hcd driver, we maintain some controller status, such as
HCD_HW_ACCESSIBLE(hcd),
etc, and udc dirver (or udc-core) update the status, and composite.c
decides whether it needs to call pm_runtime_get{_sync} and
pm_runtime_put{_sync}
according to hardware status, for example, it needs to wait gadget to
finish its hardware operation if it is async (like g_mass_storage).
Any other good suggestions?
The UDC driver knows what the power state is at all times. Therefore,
when usb_ep_disable is called while the hardware is at low power, the
routine can avoid accessing the hardware. Since there's no connection
to host at such times, the usb_ep_disable really shouldn't need to do
anything.
The same sort of thing is true of pullup. The driver should keep track
of whether the pullup will need to be turned on when the hardware goes
back to full power, but as long as you are at low power, the routine
should not need to access the hardware at all.
Thanks, Alan.
So you suggest the individual udc driver should keep controller status track
at all necessary places, eg, ep_flush, ep_dequeue, ep_disable etc.
And the udc decides whether it does noop or power on controller to access
register, right?
Right. For most of these operations, you probably will not need to
power-on the controller.
In fact, for most of these operations you probably will not need to do
anything whenever Vbus is off or the D+ pullup is off, even if the
controller is still at full power.
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 v2 4/4] usb: musb: dsps: add support for suspend and resume
On Tue, Nov 26, 2013 at 01:30:24PM +0100, Daniel Mack wrote:
On 11/25/2013 10:32 PM, Felipe Balbi wrote:
On Mon, Nov 25, 2013 at 10:30:37PM +0100, Daniel Mack wrote:
On 11/25/2013 10:29 PM, Felipe Balbi wrote:
Hi,
On Mon, Nov 25, 2013 at 10:26:43PM +0100, Daniel Mack wrote:
+static int dsps_resume(struct device *dev)
+{
+struct dsps_glue *glue = dev_get_drvdata(dev);
+const struct dsps_musb_wrapper *wrp = glue-wrp;
+struct musb *musb = platform_get_drvdata(glue-musb);
+void __iomem *mbase = musb-ctrl_base;
+
+dsps_writel(mbase, wrp-control, glue-context.control);
+dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+dsps_writel(mbase, wrp-mode, glue-context.mode);
+dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+//musb_port_reset(musb, false);
Urgs. Development left-over. Sorry. You want me to resend the whole
series or just this last patch?
just the last patch is fine :-)
Sorry, there was one more hunk that shouldn't be there. I'll resend a v4
with all the patches included again, for reference.
ok, thanks :-)
--
balbi
signature.asc
Description: Digital signature
[PATCH] usb: phy: fsm: don't depend on indirect includes
this header uses spinlocks and errno values, so we must include linux/spinlock.h and linux/errno.h to avoid build errors. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/phy/phy-fsm-usb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/phy/phy-fsm-usb.h b/drivers/usb/phy/phy-fsm-usb.h index 7441b46..32f86a3 100644 --- a/drivers/usb/phy/phy-fsm-usb.h +++ b/drivers/usb/phy/phy-fsm-usb.h @@ -15,6 +15,9 @@ * 675 Mass Ave, Cambridge, MA 02139, USA. */ +#include linux/spinlock.h +#include linux/errno.h + #undef VERBOSE #ifdef VERBOSE -- 1.8.4.GIT -- 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: Need help to support USB3.0 HID Keyboard device
On Tue, Nov 26, 2013 at 03:26:04PM +0530, Bhavik Kothari wrote: On Friday 22 November 2013 10:25 PM, Greg KH wrote: On Fri, Nov 22, 2013 at 04:47:10PM +0530, Bhavik Kothari wrote: Hi, I have been working on USB3.0 device driver and wanted to support USB3.0 HID (keyboard). To support HID Keyboard device, I have made below Interface descriptor: Interface Descriptor with alternate settings 0: bLength = 0x9; bDescriptorType = 0x4 (USB_DT_INTERFACE); bInterfaceNumber = 0x0; bAlternateSetting = 0x0; bNumEndpoints = 0x0; bInterfaceClass = (0x3) USB_CLASS_HID; bInterfaceSubClass = 0x0; bInterfaceProtocol = 0x1 (keyboard); iInterface = 0x0; Interface Descriptor with alternate settings 1 along with Super speed endpoints: bLength = 0x9; bDescriptorType = 0x4 (USB_DT_INTERFACE); bInterfaceNumber = 0x0; bAlternateSetting = 0x1; bNumEndpoints = 0x2; (One for EP IN Interrupt and other for EP OUT Interrupt) bInterfaceClass = (0x3) USB_CLASS_HID; bInterfaceSubClass = 0x0; bInterfaceProtocol = 0x1 (keyboard); iInterface = 0x0; However, when xHCI does set_config at that time Interface zero and alternate setting is zero, it never does set_interface with interface zero and alternate setting one, hence host does not detect HID device. So, would you please assist me that what I have to do, so host does set interface with alternate setting one. It's up to a userspace program to switch to the alternate interface, right? The OS can't just know to do that without some type of interaction from you. Have you run your device under the USB verification test suite for Windows? I suggest you do that first, to ensure the firmware is working properly before worrying about how Linux is handling the device. thanks, greg k-h . Hi Greg, Yes, I have run USB3.0 device with USB verification test suite (USB3.0 CV) for Windows, and it passes all test points. However, with same implementation, host does not issue set interface with alternate setting one. That sounds correct. I am not sure what to do either from device or Host side, so, Host (xHCI) issues set interface with interface number zero or any other with alternate setting one or more than zero (because alternate setting zero is alloted for control ep, if transfer type is periodic (Interrupt / Isochronous)) Can you please assist me on this, what should I do / implement? Did you read Alan's response to your questions? What about what he said to do? 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
[REWORKED PATCH 4/5] usb: phy: move OTG FSM header
From: Anton Tikhomirov av.tikhomi...@samsung.com Other USB drivers may want to use OTG final state machine implementation, so make this header available for them. Signed-off-by: Anton Tikhomirov av.tikhomi...@samsung.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/phy/phy-fsl-usb.h| 2 +- drivers/usb/phy/phy-fsm-usb.c| 3 +-- drivers/usb/phy/phy-fsm-usb.h = include/linux/usb/otg-fsm.h | 0 3 files changed, 2 insertions(+), 3 deletions(-) rename drivers/usb/phy/phy-fsm-usb.h = include/linux/usb/otg-fsm.h (100%) diff --git a/drivers/usb/phy/phy-fsl-usb.h b/drivers/usb/phy/phy-fsl-usb.h index 7365170..5986c96 100644 --- a/drivers/usb/phy/phy-fsl-usb.h +++ b/drivers/usb/phy/phy-fsl-usb.h @@ -15,7 +15,7 @@ * 675 Mass Ave, Cambridge, MA 02139, USA. */ -#include phy-fsm-usb.h +#include linux/usb/otg-fsm.h #include linux/usb/otg.h #include linux/ioctl.h diff --git a/drivers/usb/phy/phy-fsm-usb.c b/drivers/usb/phy/phy-fsm-usb.c index 2817b04..6223872 100644 --- a/drivers/usb/phy/phy-fsm-usb.c +++ b/drivers/usb/phy/phy-fsm-usb.c @@ -28,8 +28,7 @@ #include linux/usb.h #include linux/usb/gadget.h #include linux/usb/otg.h - -#include phy-fsm-usb.h +#include linux/usb/otg-fsm.h /* Change USB protocol when there is a protocol change */ static int otg_set_protocol(struct otg_fsm *fsm, int protocol) diff --git a/drivers/usb/phy/phy-fsm-usb.h b/include/linux/usb/otg-fsm.h similarity index 100% rename from drivers/usb/phy/phy-fsm-usb.h rename to include/linux/usb/otg-fsm.h -- 1.8.4.GIT -- 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
[REWORKED PATCH 1/5] usb: phy: fsm: don't depend on indirect includes
this header uses spinlocks and errno values, so we must include linux/spinlock.h and linux/errno.h to avoid build errors. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/phy/phy-fsm-usb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/phy/phy-fsm-usb.h b/drivers/usb/phy/phy-fsm-usb.h index 7441b46..32f86a3 100644 --- a/drivers/usb/phy/phy-fsm-usb.h +++ b/drivers/usb/phy/phy-fsm-usb.h @@ -15,6 +15,9 @@ * 675 Mass Ave, Cambridge, MA 02139, USA. */ +#include linux/spinlock.h +#include linux/errno.h + #undef VERBOSE #ifdef VERBOSE -- 1.8.4.GIT -- 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
[REWORKED PATCH 2/5] usb: phy: fsm: protect against multiple inclusions
From: Anton Tikhomirov av.tikhomi...@samsung.com if this header is included twice, we would have redefinition build errors. Fix this. Signed-off-by: Anton Tikhomirov av.tikhomi...@samsung.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/phy/phy-fsm-usb.h | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/phy/phy-fsm-usb.h b/drivers/usb/phy/phy-fsm-usb.h index 32f86a3..200f4d1 100644 --- a/drivers/usb/phy/phy-fsm-usb.h +++ b/drivers/usb/phy/phy-fsm-usb.h @@ -15,6 +15,9 @@ * 675 Mass Ave, Cambridge, MA 02139, USA. */ +#ifndef __LINUX_USB_OTG_FSM_H +#define __LINUX_USB_OTG_FSM_H + #include linux/spinlock.h #include linux/errno.h @@ -237,3 +240,5 @@ static inline int otg_start_gadget(struct otg_fsm *fsm, int on) } int otg_statemachine(struct otg_fsm *fsm); + +#endif /* __LINUX_USB_OTG_FSM_H */ -- 1.8.4.GIT -- 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
[REWORKED PATCH 5/5] usb: phy: Add OTG FSM configuration option
From: Anton Tikhomirov av.tikhomi...@samsung.com This patch removes dependency on Freescale USB UTG Transceiver driver and makes OTG FSM implementation selectable. Signed-off-by: Anton Tikhomirov av.tikhomi...@samsung.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/phy/Kconfig | 10 +- drivers/usb/phy/Makefile | 4 ++-- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 08e2f39..921a9f4 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -6,6 +6,14 @@ menu USB Physical Layer drivers config USB_PHY def_bool n +config USB_OTG_FSM + bool USB 2.0 OTG FSM implementation + select USB_OTG + select USB_PHY + help + Implements OTG Final State Machine as specified in On-The-Go + and Embedded Host Supplement to the USB Revision 2.0 Specification. + # # USB Transceiver Drivers # @@ -20,7 +28,7 @@ config AB8500_USB config FSL_USB2_OTG bool Freescale USB OTG Transceiver Driver - depends on USB_EHCI_FSL USB_FSL_USB2 PM_RUNTIME + depends on USB_EHCI_FSL USB_FSL_USB2 USB_OTG_FSM PM_RUNTIME select USB_OTG select USB_PHY help diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index 022c1da..1bf6c08 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -3,12 +3,12 @@ # obj-$(CONFIG_USB_PHY) += phy.o obj-$(CONFIG_OF) += of.o +obj-$(CONFIG_USB_OTG_FSM) += phy-fsm-usb.o # transceiver drivers, keep the list sorted obj-$(CONFIG_AB8500_USB) += phy-ab8500-usb.o -phy-fsl-usb2-objs := phy-fsl-usb.o phy-fsm-usb.o -obj-$(CONFIG_FSL_USB2_OTG) += phy-fsl-usb2.o +obj-$(CONFIG_FSL_USB2_OTG) += phy-fsl-usb.o obj-$(CONFIG_ISP1301_OMAP) += phy-isp1301-omap.o obj-$(CONFIG_MV_U3D_PHY) += phy-mv-u3d-usb.o obj-$(CONFIG_NOP_USB_XCEIV)+= phy-generic.o -- 1.8.4.GIT -- 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
[REWORKED PATCH 3/5] usb: phy: replace spinlock with mutex in OTG FSM
From: Anton Tikhomirov av.tikhomi...@samsung.com
OTG Final State Machine calls functions which may sleep.
For example, start_gadget callback implementation can use
usb_gadget_vbus_connect(), whose context: can sleep.
If so, mutex should be used instead of spinlock.
Signed-off-by: Anton Tikhomirov av.tikhomi...@samsung.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/phy/phy-fsl-usb.c | 7 +++
drivers/usb/phy/phy-fsm-usb.c | 7 +++
drivers/usb/phy/phy-fsm-usb.h | 4 ++--
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 7f3c73b..62d5af2 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -848,7 +848,7 @@ static int fsl_otg_conf(struct platform_device *pdev)
pr_info(Couldn't init OTG timers\n);
goto err;
}
- spin_lock_init(fsl_otg_tc-fsm.lock);
+ mutex_init(fsl_otg_tc-fsm.lock);
/* Set OTG state machine operations */
fsl_otg_tc-fsm.ops = fsl_otg_ops;
@@ -1017,10 +1017,9 @@ static int show_fsl_usb2_otg_state(struct device *dev,
struct otg_fsm *fsm = fsl_otg_dev-fsm;
char *next = buf;
unsigned size = PAGE_SIZE;
- unsigned long flags;
int t;
- spin_lock_irqsave(fsm-lock, flags);
+ mutex_lock(fsm-lock);
/* basic driver infomation */
t = scnprintf(next, size,
@@ -1088,7 +1087,7 @@ static int show_fsl_usb2_otg_state(struct device *dev,
size -= t;
next += t;
- spin_unlock_irqrestore(fsm-lock, flags);
+ mutex_unlock(fsm-lock);
return PAGE_SIZE - size;
}
diff --git a/drivers/usb/phy/phy-fsm-usb.c b/drivers/usb/phy/phy-fsm-usb.c
index 329c2d2..2817b04 100644
--- a/drivers/usb/phy/phy-fsm-usb.c
+++ b/drivers/usb/phy/phy-fsm-usb.c
@@ -23,7 +23,7 @@
#include linux/kernel.h
#include linux/types.h
-#include linux/spinlock.h
+#include linux/mutex.h
#include linux/delay.h
#include linux/usb.h
#include linux/usb/gadget.h
@@ -245,9 +245,8 @@ int otg_set_state(struct otg_fsm *fsm, enum usb_otg_state
new_state)
int otg_statemachine(struct otg_fsm *fsm)
{
enum usb_otg_state state;
- unsigned long flags;
- spin_lock_irqsave(fsm-lock, flags);
+ mutex_lock(fsm-lock);
state = fsm-otg-phy-state;
state_changed = 0;
@@ -359,7 +358,7 @@ int otg_statemachine(struct otg_fsm *fsm)
default:
break;
}
- spin_unlock_irqrestore(fsm-lock, flags);
+ mutex_lock(fsm-lock);
VDBG(quit statemachine, changed = %d\n, state_changed);
return state_changed;
diff --git a/drivers/usb/phy/phy-fsm-usb.h b/drivers/usb/phy/phy-fsm-usb.h
index 200f4d1..b6ba1bf 100644
--- a/drivers/usb/phy/phy-fsm-usb.h
+++ b/drivers/usb/phy/phy-fsm-usb.h
@@ -18,7 +18,7 @@
#ifndef __LINUX_USB_OTG_FSM_H
#define __LINUX_USB_OTG_FSM_H
-#include linux/spinlock.h
+#include linux/mutex.h
#include linux/errno.h
#undef VERBOSE
@@ -116,7 +116,7 @@ struct otg_fsm {
/* Current usb protocol used: 0:undefine; 1:host; 2:client */
int protocol;
- spinlock_t lock;
+ struct mutex lock;
};
struct otg_fsm_ops {
--
1.8.4.GIT
--
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: [REWORKED PATCH 1/5] usb: phy: fsm: don't depend on indirect includes
Hi, On Tue, Nov 26, 2013 at 10:33:44AM -0600, Felipe Balbi wrote: this header uses spinlocks and errno values, so we must include linux/spinlock.h and linux/errno.h to avoid build errors. Signed-off-by: Felipe Balbi ba...@ti.com Anton, I had to rework your patch series quite a bit in order to make it acceptable. It seems unlikely that you compile-tested your series, considering we would very clearly see build errors after moving the header around. Your driver depends (or depended?) too much on indirect header inclusions. Make sure to build test each and every patch in your series next time, or they won't make it to mainline. -- balbi signature.asc Description: Digital signature
Re: musb： bluk_split only worked for the first segment(PIO only)
On Thu, Nov 21, 2013 at 4:40 AM, Yingchun Li sword.l.dra...@gmail.com wrote: hi, if musb bulk_split is enable, the segment size will be set according to hw_ep-max_packet_sz_tx, and the segment will be writen to fifo. But after the first tranfser end, the segment size will be set no larger than qh-maxpacket (in musb_host_tx),and the bluk_split make no sense. so please check the following patch, I have tested it on my board. For the platforms which do not support bulk split/combine, I would think the right fix should be set musb-bulk_combine = false, and musb-bulk_split = false at the end of musb_core_init() in musb_core.c. -Bin. diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index 6582a20..f251132 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -1455,8 +1455,8 @@ done: * (and presumably, FIFO is not half-full) we should write *two* * packets before updating TXCSR; other docs disagree... */ - if (length qh-maxpacket) - length = qh-maxpacket; + if (length qh-segsize) + length = qh-segsize; /* Unmap the buffer so that CPU can use it */ usb_hcd_unmap_urb_for_dma(musb-hcd, urb); -- 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 -- 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 00/15] usb: phy: msm: Fixes, cleanups and DT support
Hi, On Tue, Nov 12, 2013 at 04:51:35PM +0200, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com Hi, Patches have been tested on top of Stephen's clock controller patches[1] and recent fixes for chipidea msm glue layer driver posted here[2]. Hardware platform AP8074 DragonBoard. Only gadget mode utilized for now. CV Test Suite engine Chapter 9 tests are passing except Halt Endpoint Test. usbtest driver report following failure: test 13 -- 32 (Broken pipe) ep 81 couldn't set halt, -32 This will be investigated further. Patches could be applied cleanly on top of the usb-3.13-rc1. Regards, Ivan [1] http://comments.gmane.org/gmane.linux.ports.arm.msm/5375 [2] https://lkml.org/lkml/2013/11/11/310 I wonder how will this be taken upstream provided there are interdependencies between arch/ and drivers/ patches. I can Ack patches but I'd really like to avoid merging of topic branches all over the place :-s cheers -- balbi signature.asc Description: Digital signature
Re: [RESEND PATCH v3 3/4] usb: musb: dsps, debugfs files
Hi,
On Tue, Nov 26, 2013 at 10:25:26AM +0100, Markus Pargmann wrote:
On Mon, Nov 18, 2013 at 04:54:37PM +0100, Markus Pargmann wrote:
@@ -350,6 +373,30 @@ out:
return ret;
}
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
why ? just use the glue's device
I used this to have a more obvious relationship between musb-core
debugfs and musb-dsps debugfs. Otherwise we would have '47401400.usb'
for dsps and 'musb-hdrc.0.auto' for musb core.
But I can change it if you want.
yeah, I guess it's best to use the device name on this one, even though
it'll look at bit weird. At least it'll be guaranteed to be unique.
--
balbi
signature.asc
Description: Digital signature
Re: [RESEND PATCH v3 4/4] usb: musb: dsps, use devm_kzalloc
On Tue, Nov 26, 2013 at 10:26:17AM +0100, Markus Pargmann wrote: On Mon, Nov 25, 2013 at 09:58:04AM -0600, Felipe Balbi wrote: On Mon, Nov 18, 2013 at 04:54:38PM +0100, Markus Pargmann wrote: Signed-off-by: Markus Pargmann m...@pengutronix.de no commit log == no commit. Sorry, but I'll be very pedantic about it. Okay I will add a commit message. yeah, even if obvious. -- balbi signature.asc Description: Digital signature
Re: BUG: usb: obex in g_nokia.ko causing kernel panic
On Tuesday 19 November 2013 11:51:12 Pali Rohár wrote: Hi! For a long time (since 3.5 or 3.8? - I do not remember) obex subdriver in g_nokia usb gadget module causing kernel panic after module is loaded on Nokia N900. I do not know where is problem and due to immediatelly kernel crash when loading driver I was not able to see any dmesg output. Now I was able to store something into mtd log and here is crash backtrace: Log Entry 437 (at position 52) 4[ 18.606414] [c037eac0] (__schedule+0x5c/0x50c) from [c037d3bc] (schedule_timeout+0x1f4/0x25c) 4[ 18.623809] [c037d3bc] (schedule_timeout+0x1f4/0x25c) from [c037f12c] (wait_for_common+0xc8/0x1ac) 4[ 18.649291] [c037f12c] (wait_for_common+0xc8/0x1ac) from [c028c1c0] (omap_i2c_xfer+0x338/0x488) 4[ 18.674499] [c028c1c0] (omap_i2c_xfer+0x338/0x488) from [c0288144] (__i2c_transfer+0x40/0x74) 4[ 18.692047] [c0288144] (__i2c_transfer+0x40/0x74) from [c0288a2c] (i2c_transfer+0x6c/0x90) 4[ 18.709320] [c0288a2c] (i2c_transfer+0x6c/0x90) from [c02351c8] (regmap_i2c_read+0x48/0x68) 4[ 18.726715] [c02351c8] (regmap_i2c_read+0x48/0x68) from [c023161c] (_regmap_raw_read+0x128/0x220) 4[ 18.752685] [c023161c] (_regmap_raw_read+0x128/0x220) from [c02317b4] (regmap_raw_read+0xa0/0x130) 4[ 18.779052] [c02317b4] (regmap_raw_read+0xa0/0x130) from [c023193c] (regmap_bulk_read+0xf8/0x16c) 4[ 18.805694] [c023193c] (regmap_bulk_read+0xf8/0x16c) from [c0238ea8] (twl_i2c_read+0xa4/0xe0) 4[ 18.823730] [c0238ea8] (twl_i2c_read+0xa4/0xe0) from [c0274d34] (__twl4030_phy_power.isra.12+0x1c/0x58) 4[ 18.850921] [c0274d34] (__twl4030_phy_power.isra.12+0x1c/0x58) from [c0274df0] (twl4030_phy_power.part.14+0x80/0xc8) 4[ 18.879699] [c0274df0] (twl4030_phy_power.part.14+0x80/0xc8) from [c0274f9c] (twl4030_set_suspend+0x54/0x1e8) 4[ 18.908325] [c0274f9c] (twl4030_set_suspend+0x54/0x1e8) from [c027c8c4] (omap2430_runtime_resume+0x5c/0x64) 4[ 18.937042] [c027c8c4] (omap2430_runtime_resume+0x5c/0x64) from [c0225dd0] (pm_generic_runtime_resume+0x2c/0x38) 4[ 18.966461] [c0225dd0] (pm_generic_runtime_resume+0x2c/0x38) from [c0229fe0] (__rpm_callback+0x54/0x80) 4[ 18.995117] [c0229fe0] (__rpm_callback+0x54/0x80) from [c022a04c] (rpm_callback+0x40/0x74) 4[ 19.013610] [c022a04c] (rpm_callback+0x40/0x74) from [c022b3c8] (rpm_resume+0x448/0x63c) 4[ 19.031921] [c022b3c8] (rpm_resume+0x448/0x63c) from [c022b2e4] (rpm_resume+0x364/0x63c) 4[ 19.050140] [c022b2e4] (rpm_resume+0x364/0x63c) from [c022b874] (__pm_runtime_resume+0x48/0x74) 4[ 19.077728] [c022b874] (__pm_runtime_resume+0x48/0x74) from [c027b4fc] (musb_gadget_pullup+0x1c/0xb4) 4[ 19.105895] [c027b4fc] (musb_gadget_pullup+0x1c/0xb4) from [bf025c14] (usb_function_deactivate+0x54/0xa4 [libcomposite]) 4[ 19.135955] [bf025c14] (usb_function_deactivate+0x54/0xa4 [libcomposite]) from [bf05b3b8] (obex_bind+0x124/0x1d8 [usb_f_obex]) 4[ 19.166870] [bf05b3b8] (obex_bind+0x124/0x1d8 [usb_f_obex]) from [bf025794] (usb_add_function+0x58/0xf4 [libcomposite]) 4[ 19.197143] [bf025794] (usb_add_function+0x58/0xf4 [libcomposite]) from [bf037420] (nokia_bind_config+0x204/0x250 [g_nokia]) 4[ 19.227905] [bf037420] (nokia_bind_config+0x204/0x250 [g_nokia]) from [bf0263fc] (usb_add_config+0x28/0xc0 [libcomposite]) 4[ 19.258483] [bf0263fc] (usb_add_config+0x28/0xc0 [libcomposite]) from [bf03709c] (nokia_bind+0x9c/0x21c [g_nokia]) 4[ 19.288421] [bf03709c] (nokia_bind+0x9c/0x21c [g_nokia]) from [bf0275bc] (composite_bind+0x74/0x180 [libcomposite]) 4[ 19.318420] [bf0275bc] (composite_bind+0x74/0x180 [libcomposite]) from [c027d658] (udc_bind_to_driver+0x2c/0xc4) 4[ 19.348114] [c027d658] (udc_bind_to_driver+0x2c/0xc4) from [c027d764] (usb_gadget_probe_driver+0x74/0x94) 4[ 19.377166] [c027d764] (usb_gadget_probe_driver+0x74/0x94) from [c00086f8] (do_one_initcall+0x94/0x138) 4[ 19.406005] [c00086f8] (do_one_initcall+0x94/0x138) from [c007a460] (load_module+0x113c/0x13c4) 4[ 19.434051] [c007a460] (load_module+0x113c/0x13c4) from [c007a7b4] (SyS_init_module+0xcc/0xec) 4[ 19.462127] [c007a7b4] (SyS_init_module+0xcc/0xec) from [c000dd40] (ret_fast_syscall+0x0/0x30) 0[ 19.490753] Code: 0a2e e1a4 eb001438 e598300c (e5d3202c) 4[ 19.506805] ---[ end trace 060b62ec0d68a78b ]--- 0[ 19.523132] Kernel panic - not syncing: Fatal exception in interrupt (above dump is from 3.12-rc5 kernel) When I disable obex code in drivers/usb/gadget/nokia.c then gadget driver working fine without any crash, error or warning. Here is patch which disabling obex code which I using (for 3.12): diff --git a/drivers/usb/gadget/nokia.c b/drivers/usb/gadget/nokia.c index ba47977..869cbfa 100644 --- a/drivers/usb/gadget/nokia.c +++ b/drivers/usb/gadget/nokia.c @@ -110,10 +110,10 @@ static struct usb_function *f_acm_cfg1; static struct usb_function *f_acm_cfg2; static struct usb_function *f_ecm_cfg1; static struct usb_function
Re: BUG: usb: obex in g_nokia.ko causing kernel panic
Hi, On Tue, Nov 19, 2013 at 11:51:12AM +0100, Pali Rohár wrote: Hi! For a long time (since 3.5 or 3.8? - I do not remember) obex subdriver in g_nokia usb gadget module causing kernel panic after module is loaded on Nokia N900. I do not know where is problem and due to immediatelly kernel crash when loading driver I was not able to see any dmesg output. Now I was able to store something into mtd log and here is crash backtrace: Log Entry 437 (at position 52) 4[ 18.606414] [c037eac0] (__schedule+0x5c/0x50c) from [c037d3bc] (schedule_timeout+0x1f4/0x25c) 4[ 18.623809] [c037d3bc] (schedule_timeout+0x1f4/0x25c) from [c037f12c] (wait_for_common+0xc8/0x1ac) 4[ 18.649291] [c037f12c] (wait_for_common+0xc8/0x1ac) from [c028c1c0] (omap_i2c_xfer+0x338/0x488) 4[ 18.674499] [c028c1c0] (omap_i2c_xfer+0x338/0x488) from [c0288144] (__i2c_transfer+0x40/0x74) 4[ 18.692047] [c0288144] (__i2c_transfer+0x40/0x74) from [c0288a2c] (i2c_transfer+0x6c/0x90) 4[ 18.709320] [c0288a2c] (i2c_transfer+0x6c/0x90) from [c02351c8] (regmap_i2c_read+0x48/0x68) 4[ 18.726715] [c02351c8] (regmap_i2c_read+0x48/0x68) from [c023161c] (_regmap_raw_read+0x128/0x220) 4[ 18.752685] [c023161c] (_regmap_raw_read+0x128/0x220) from [c02317b4] (regmap_raw_read+0xa0/0x130) 4[ 18.779052] [c02317b4] (regmap_raw_read+0xa0/0x130) from [c023193c] (regmap_bulk_read+0xf8/0x16c) 4[ 18.805694] [c023193c] (regmap_bulk_read+0xf8/0x16c) from [c0238ea8] (twl_i2c_read+0xa4/0xe0) 4[ 18.823730] [c0238ea8] (twl_i2c_read+0xa4/0xe0) from [c0274d34] (__twl4030_phy_power.isra.12+0x1c/0x58) 4[ 18.850921] [c0274d34] (__twl4030_phy_power.isra.12+0x1c/0x58) from [c0274df0] (twl4030_phy_power.part.14+0x80/0xc8) 4[ 18.879699] [c0274df0] (twl4030_phy_power.part.14+0x80/0xc8) from [c0274f9c] (twl4030_set_suspend+0x54/0x1e8) 4[ 18.908325] [c0274f9c] (twl4030_set_suspend+0x54/0x1e8) from [c027c8c4] (omap2430_runtime_resume+0x5c/0x64) 4[ 18.937042] [c027c8c4] (omap2430_runtime_resume+0x5c/0x64) from [c0225dd0] (pm_generic_runtime_resume+0x2c/0x38) 4[ 18.966461] [c0225dd0] (pm_generic_runtime_resume+0x2c/0x38) from [c0229fe0] (__rpm_callback+0x54/0x80) 4[ 18.995117] [c0229fe0] (__rpm_callback+0x54/0x80) from [c022a04c] (rpm_callback+0x40/0x74) 4[ 19.013610] [c022a04c] (rpm_callback+0x40/0x74) from [c022b3c8] (rpm_resume+0x448/0x63c) 4[ 19.031921] [c022b3c8] (rpm_resume+0x448/0x63c) from [c022b2e4] (rpm_resume+0x364/0x63c) 4[ 19.050140] [c022b2e4] (rpm_resume+0x364/0x63c) from [c022b874] (__pm_runtime_resume+0x48/0x74) 4[ 19.077728] [c022b874] (__pm_runtime_resume+0x48/0x74) from [c027b4fc] (musb_gadget_pullup+0x1c/0xb4) 4[ 19.105895] [c027b4fc] (musb_gadget_pullup+0x1c/0xb4) from [bf025c14] (usb_function_deactivate+0x54/0xa4 [libcomposite]) 4[ 19.135955] [bf025c14] (usb_function_deactivate+0x54/0xa4 [libcomposite]) from [bf05b3b8] (obex_bind+0x124/0x1d8 [usb_f_obex]) 4[ 19.166870] [bf05b3b8] (obex_bind+0x124/0x1d8 [usb_f_obex]) from [bf025794] (usb_add_function+0x58/0xf4 [libcomposite]) 4[ 19.197143] [bf025794] (usb_add_function+0x58/0xf4 [libcomposite]) from [bf037420] (nokia_bind_config+0x204/0x250 [g_nokia]) 4[ 19.227905] [bf037420] (nokia_bind_config+0x204/0x250 [g_nokia]) from [bf0263fc] (usb_add_config+0x28/0xc0 [libcomposite]) 4[ 19.258483] [bf0263fc] (usb_add_config+0x28/0xc0 [libcomposite]) from [bf03709c] (nokia_bind+0x9c/0x21c [g_nokia]) 4[ 19.288421] [bf03709c] (nokia_bind+0x9c/0x21c [g_nokia]) from [bf0275bc] (composite_bind+0x74/0x180 [libcomposite]) 4[ 19.318420] [bf0275bc] (composite_bind+0x74/0x180 [libcomposite]) from [c027d658] (udc_bind_to_driver+0x2c/0xc4) 4[ 19.348114] [c027d658] (udc_bind_to_driver+0x2c/0xc4) from [c027d764] (usb_gadget_probe_driver+0x74/0x94) 4[ 19.377166] [c027d764] (usb_gadget_probe_driver+0x74/0x94) from [c00086f8] (do_one_initcall+0x94/0x138) 4[ 19.406005] [c00086f8] (do_one_initcall+0x94/0x138) from [c007a460] (load_module+0x113c/0x13c4) 4[ 19.434051] [c007a460] (load_module+0x113c/0x13c4) from [c007a7b4] (SyS_init_module+0xcc/0xec) 4[ 19.462127] [c007a7b4] (SyS_init_module+0xcc/0xec) from [c000dd40] (ret_fast_syscall+0x0/0x30) 0[ 19.490753] Code: 0a2e e1a4 eb001438 e598300c (e5d3202c) 4[ 19.506805] ---[ end trace 060b62ec0d68a78b ]--- 0[ 19.523132] Kernel panic - not syncing: Fatal exception in interrupt (above dump is from 3.12-rc5 kernel) looks like it's trying to do i2c transfers from atomic. But why only when obex is enabled ? Makes no sense. What do you have on userland ? Is there anything trying to access the obex interface ? Was the USB cable attached at that time ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] usb: dwc3: Add Keystone specific glue layer
On Mon, Nov 25, 2013 at 07:49:01PM -0500, Santosh Shilimkar wrote: On Monday 25 November 2013 03:39 PM, Felipe Balbi wrote: Hi, [...] + kdwc3_dma_mask = dma_get_mask(dev); + dev-dma_mask = kdwc3_dma_mask; + + error = kdwc3_enable(kdwc); I would drop this function and just add your clk_prepare() here, then move clk_enable()/clk_disable() to -runtime_resume/-runtime_suspend() respectively. Then you could just call pm_runtime_get_sync() when you need to access your registers and pm_runtime_put() when you want to drop the clock reference. this will even make PM implementation a lot easier for you going forward. Just to make the PM runtime part clear, there are few issues with PM core clock layer [1], hence drivers is using clock layer. Its trivial to update the driver though once the issue is sorted out. Meanwhile driver development continue to be with clock calls. I don't mind having those clock calls, just suggested a different placement for them. -- balbi signature.asc Description: Digital signature
Re: BUG: usb: obex in g_nokia.ko causing kernel panic
On Tue, Nov 26, 2013 at 06:10:22PM +0100, Pali Rohár wrote: On Tuesday 19 November 2013 11:51:12 Pali Rohár wrote: For a long time (since 3.5 or 3.8? - I do not remember) obex subdriver in g_nokia usb gadget module causing kernel panic after module is loaded on Nokia N900. I do not know where is problem and due to immediatelly kernel crash when loading driver I was not able to see any dmesg output. Now I was able to store something into mtd log and here is crash backtrace: [...] Hi! can you look at this problem? So it worked at some time? Have you tried to git bisect the problem? -- Sebastian signature.asc Description: Digital signature
Re: BUG: usb: obex in g_nokia.ko causing kernel panic
On Tuesday 26 November 2013 18:16:06 Felipe Balbi wrote: Hi, On Tue, Nov 19, 2013 at 11:51:12AM +0100, Pali Rohár wrote: Hi! For a long time (since 3.5 or 3.8? - I do not remember) obex subdriver in g_nokia usb gadget module causing kernel panic after module is loaded on Nokia N900. I do not know where is problem and due to immediatelly kernel crash when loading driver I was not able to see any dmesg output. Now I was able to store something into mtd log and here is crash backtrace: Log Entry 437 (at position 52) 4[ 18.606414] [c037eac0] (__schedule+0x5c/0x50c) from [c037d3bc] (schedule_timeout+0x1f4/0x25c) 4[ 18.623809] [c037d3bc] (schedule_timeout+0x1f4/0x25c) from [c037f12c] (wait_for_common+0xc8/0x1ac) 4[ 18.649291] [c037f12c] (wait_for_common+0xc8/0x1ac) from [c028c1c0] (omap_i2c_xfer+0x338/0x488) 4[ 18.674499] [c028c1c0] (omap_i2c_xfer+0x338/0x488) from [c0288144] (__i2c_transfer+0x40/0x74) 4[ 18.692047] [c0288144] (__i2c_transfer+0x40/0x74) from [c0288a2c] (i2c_transfer+0x6c/0x90) 4[ 18.709320] [c0288a2c] (i2c_transfer+0x6c/0x90) from [c02351c8] (regmap_i2c_read+0x48/0x68) 4[ 18.726715] [c02351c8] (regmap_i2c_read+0x48/0x68) from [c023161c] (_regmap_raw_read+0x128/0x220) 4[ 18.752685] [c023161c] (_regmap_raw_read+0x128/0x220) from [c02317b4] (regmap_raw_read+0xa0/0x130) 4[ 18.779052] [c02317b4] (regmap_raw_read+0xa0/0x130) from [c023193c] (regmap_bulk_read+0xf8/0x16c) 4[ 18.805694] [c023193c] (regmap_bulk_read+0xf8/0x16c) from [c0238ea8] (twl_i2c_read+0xa4/0xe0) 4[ 18.823730] [c0238ea8] (twl_i2c_read+0xa4/0xe0) from [c0274d34] (__twl4030_phy_power.isra.12+0x1c/0x58) 4[ 18.850921] [c0274d34] (__twl4030_phy_power.isra.12+0x1c/0x58) from [c0274df0] (twl4030_phy_power.part.14+0x80/0xc8) 4[ 18.879699] [c0274df0] (twl4030_phy_power.part.14+0x80/0xc8) from [c0274f9c] (twl4030_set_suspend+0x54/0x1e8) 4[ 18.908325] [c0274f9c] (twl4030_set_suspend+0x54/0x1e8) from [c027c8c4] (omap2430_runtime_resume+0x5c/0x64) 4[ 18.937042] [c027c8c4] (omap2430_runtime_resume+0x5c/0x64) from [c0225dd0] (pm_generic_runtime_resume+0x2c/0x38) 4[ 18.966461] [c0225dd0] (pm_generic_runtime_resume+0x2c/0x38) from [c0229fe0] (__rpm_callback+0x54/0x80) 4[ 18.995117] [c0229fe0] (__rpm_callback+0x54/0x80) from [c022a04c] (rpm_callback+0x40/0x74) 4[ 19.013610] [c022a04c] (rpm_callback+0x40/0x74) from [c022b3c8] (rpm_resume+0x448/0x63c) 4[ 19.031921] [c022b3c8] (rpm_resume+0x448/0x63c) from [c022b2e4] (rpm_resume+0x364/0x63c) 4[ 19.050140] [c022b2e4] (rpm_resume+0x364/0x63c) from [c022b874] (__pm_runtime_resume+0x48/0x74) 4[ 19.077728] [c022b874] (__pm_runtime_resume+0x48/0x74) from [c027b4fc] (musb_gadget_pullup+0x1c/0xb4) 4[ 19.105895] [c027b4fc] (musb_gadget_pullup+0x1c/0xb4) from [bf025c14] (usb_function_deactivate+0x54/0xa4 [libcomposite]) 4[ 19.135955] [bf025c14] (usb_function_deactivate+0x54/0xa4 [libcomposite]) from [bf05b3b8] (obex_bind+0x124/0x1d8 [usb_f_obex]) 4[ 19.166870] [bf05b3b8] (obex_bind+0x124/0x1d8 [usb_f_obex]) from [bf025794] (usb_add_function+0x58/0xf4 [libcomposite]) 4[ 19.197143] [bf025794] (usb_add_function+0x58/0xf4 [libcomposite]) from [bf037420] (nokia_bind_config+0x204/0x250 [g_nokia]) 4[ 19.227905] [bf037420] (nokia_bind_config+0x204/0x250 [g_nokia]) from [bf0263fc] (usb_add_config+0x28/0xc0 [libcomposite]) 4[ 19.258483] [bf0263fc] (usb_add_config+0x28/0xc0 [libcomposite]) from [bf03709c] (nokia_bind+0x9c/0x21c [g_nokia]) 4[ 19.288421] [bf03709c] (nokia_bind+0x9c/0x21c [g_nokia]) from [bf0275bc] (composite_bind+0x74/0x180 [libcomposite]) 4[ 19.318420] [bf0275bc] (composite_bind+0x74/0x180 [libcomposite]) from [c027d658] (udc_bind_to_driver+0x2c/0xc4) 4[ 19.348114] [c027d658] (udc_bind_to_driver+0x2c/0xc4) from [c027d764] (usb_gadget_probe_driver+0x74/0x94) 4[ 19.377166] [c027d764] (usb_gadget_probe_driver+0x74/0x94) from [c00086f8] (do_one_initcall+0x94/0x138) 4[ 19.406005] [c00086f8] (do_one_initcall+0x94/0x138) from [c007a460] (load_module+0x113c/0x13c4) 4[ 19.434051] [c007a460] (load_module+0x113c/0x13c4) from [c007a7b4] (SyS_init_module+0xcc/0xec) 4[ 19.462127] [c007a7b4] (SyS_init_module+0xcc/0xec) from [c000dd40] (ret_fast_syscall+0x0/0x30) 0[ 19.490753] Code: 0a2e e1a4 eb001438 e598300c (e5d3202c) 4[ 19.506805] ---[ end trace 060b62ec0d68a78b ]--- 0[ 19.523132] Kernel panic - not syncing: Fatal exception in interrupt (above dump is from 3.12-rc5 kernel) looks like it's trying to do i2c transfers from atomic. But why only when obex is enabled ? Makes no sense. What do you have on userland ? Is there anything trying to access the obex interface ? Was the USB cable attached at that time ? Yes, only when initliaizing obex. Other is ok. Problem is there with Maemo userland and also with clean userland (rescueOS) where
Re: BUG: usb: obex in g_nokia.ko causing kernel panic
On Tuesday 26 November 2013 18:17:49 Sebastian Reichel wrote: On Tue, Nov 26, 2013 at 06:10:22PM +0100, Pali Rohár wrote: On Tuesday 19 November 2013 11:51:12 Pali Rohár wrote: For a long time (since 3.5 or 3.8? - I do not remember) obex subdriver in g_nokia usb gadget module causing kernel panic after module is loaded on Nokia N900. I do not know where is problem and due to immediatelly kernel crash when loading driver I was not able to see any dmesg output. Now I was able to store something into mtd log and here is crash backtrace: [...] Hi! can you look at this problem? So it worked at some time? Have you tried to git bisect the problem? -- Sebastian Yes, if I remember it worked with some older 3.x kernel. I do not know if I still have old tree. But there is problem with bisecting, because booting older kernel is hard on n900... At lest on 2.6.28 kernel g_nokia.ko working fine. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[RFCv3 1/3] usb: gadget: ep: add feature flags
Add a few flags to tell gadget framework which
features a particular endpoint supports.
Signed-off-by: Felipe Balbi ba...@ti.com
---
include/linux/usb/gadget.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 942ef5e..cf1d027 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -159,6 +159,12 @@ struct usb_ep_ops {
* enabled and remains valid until the endpoint is disabled.
* @comp_desc: In case of SuperSpeed support, this is the endpoint companion
* descriptor that is used to configure the endpoint
+ * @has_bulk: endpoint supports bulk transfers
+ * @has_control: endpoint supports control transfers
+ * @has_interrupt: endpoint supports interrupt transfers
+ * @has_isochronous: endpoint supports isochronous transfers
+ * @has_dir_in: endpoint supports IN direction
+ * @has_dir_out: endpoint supports OUT direction
*
* the bus controller driver lists all the general purpose endpoints in
* gadget-ep_list. the control endpoint (gadget-ep0) is not in that list,
@@ -177,6 +183,13 @@ struct usb_ep {
u8 address;
const struct usb_endpoint_descriptor*desc;
const struct usb_ss_ep_comp_descriptor *comp_desc;
+
+ unsignedhas_bulk:1;
+ unsignedhas_control:1;
+ unsignedhas_interrupt:1;
+ unsignedhas_isochronous:1;
+ unsignedhas_dir_in:1;
+ unsignedhas_dir_out:1;
};
/*-*/
--
1.8.4.GIT
--
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
[RFCv3 0/3] usb: gadget: start dropping endpoint naming conventions
here's a third RFC on my original endpoint feature flag RFC. The only change now is that I fixed epautoconf based on Alan's comment (thanks Alan). I have also dropped the first patch and will already make sure it reaches my next branch soon. !!!! !! COMPILE TESTED ONLY FOLLOWS, USE AT YOUR OWN RISK !! !!!! Felipe Balbi (3): usb: gadget: ep: add feature flags usb: gadget: epautoconf: check feature flags usb: dwc3: gadget: set endpoint feature flags drivers/usb/dwc3/gadget.c | 19 +++ drivers/usb/gadget/epautoconf.c | 28 ++-- include/linux/usb/gadget.h | 13 + 3 files changed, 58 insertions(+), 2 deletions(-) -- 1.8.4.GIT -- 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
[RFCv3 3/3] usb: dwc3: gadget: set endpoint feature flags
just so we can start using a more solid endpoint
matching system.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/gadget.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 5452c0f..d687c3a 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1655,6 +1655,18 @@ static int dwc3_gadget_init_hw_endpoints(struct dwc3
*dwc,
if (epnum == 0 || epnum == 1) {
dep-endpoint.maxpacket = 512;
dep-endpoint.maxburst = 1;
+ dep-endpoint.has_control = true;
+
+ /*
+* REVISIT here we lie a bit to gadget framework,
+* because gadget framework expects to see a single
+* USB Endpoint zero, and we want the driver to manage
+* HW endpoints, we must tell gadget framework that
+* HW Endpoint zero supports both directions.
+*/
+ dep-endpoint.has_dir_in = true;
+ dep-endpoint.has_dir_out = true;
+
dep-endpoint.ops = dwc3_gadget_ep0_ops;
if (!epnum)
dwc-gadget.ep0 = dep-endpoint;
@@ -1663,6 +1675,13 @@ static int dwc3_gadget_init_hw_endpoints(struct dwc3
*dwc,
dep-endpoint.maxpacket = 1024;
dep-endpoint.max_streams = 15;
+
+ dep-endpoint.has_bulk = true;
+ dep-endpoint.has_interrupt = true;
+ dep-endpoint.has_isochronous = true;
+ dep-endpoint.has_dir_in = !!direction;
+ dep-endpoint.has_dir_out = !direction;
+
dep-endpoint.ops = dwc3_gadget_ep_ops;
list_add_tail(dep-endpoint.ep_list,
dwc-gadget.ep_list);
--
1.8.4.GIT
--
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
[RFCv3 2/3] usb: gadget: epautoconf: check feature flags
Start matching endpoints against feature flags,
this will help us dropping the naming conventions
currently used by the Gadget Framework.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/epautoconf.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index feaaa7b..3fe0d42 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -62,6 +62,31 @@ ep_matches (
if (USB_ENDPOINT_XFER_CONTROL == type)
return 0;
+ /* first check feature flags */
+ if (ep-has_dir_in ^ usb_endpoint_dir_in(desc))
+ return 0;
+
+ if (ep-has_dir_out ^ usb_endpoint_dir_out(desc))
+ return 0;
+
+ switch (type) {
+ case USB_ENDPOINT_XFER_CONTROL:
+ /* only ep0 */
+ return 0;
+ case USB_ENDPOINT_XFER_BULK:
+ if (ep-has_bulk)
+ goto match;
+ break;
+ case USB_ENDPOINT_XFER_INT:
+ if (ep-has_interrupt)
+ goto match;
+ break;
+ case USB_ENDPOINT_XFER_ISOC:
+ if (ep-has_isochronous)
+ goto match;
+ break;
+ }
+
/* some other naming convention */
if ('e' != ep-name[0])
return 0;
@@ -159,8 +184,7 @@ ep_matches (
break;
}
- /* MATCH!! */
-
+match:
/* report address */
desc-bEndpointAddress = USB_DIR_IN;
if (isdigit (ep-name [2])) {
--
1.8.4.GIT
--
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: BUG: usb: obex in g_nokia.ko causing kernel panic
Hi, On Tue, Nov 26, 2013 at 06:28:05PM +0100, Pali Rohár wrote: [ snip ] (above dump is from 3.12-rc5 kernel) looks like it's trying to do i2c transfers from atomic. But why only when obex is enabled ? Makes no sense. What do you have on userland ? Is there anything trying to access the obex interface ? Was the USB cable attached at that time ? Yes, only when initliaizing obex. Other is ok. Problem is there with Maemo userland and also with clean userland (rescueOS) where is only busybox and some simple init scripts. On Maemo maybe something is trying to access obex, but on rescueOS for sure nothing. Problem happends when cable is attached and also when not = always. As a debug effort, can you apply hack below and see if it helps ? diff --git a/drivers/usb/gadget/f_obex.c b/drivers/usb/gadget/f_obex.c index ad39f1d..4af2f06 100644 --- a/drivers/usb/gadget/f_obex.c +++ b/drivers/usb/gadget/f_obex.c @@ -267,10 +267,12 @@ static void obex_connect(struct gserial *g) if (!obex-can_activate) return; +#if 0 status = usb_function_activate(g-func); if (status) DBG(cdev, obex ttyGS%d function activate -- %d\n, obex-port_num, status); +#endif } static void obex_disconnect(struct gserial *g) @@ -282,10 +284,12 @@ static void obex_disconnect(struct gserial *g) if (!obex-can_activate) return; +#if 0 status = usb_function_deactivate(g-func); if (status) DBG(cdev, obex ttyGS%d function deactivate -- %d\n, obex-port_num, status); +#endif } /*-*/ @@ -372,6 +376,7 @@ static int obex_bind(struct usb_configuration *c, struct usb_function *f) if (status) goto fail; +#if 0 /* Avoid letting this gadget enumerate until the userspace * OBEX server is active. */ @@ -381,6 +386,7 @@ static int obex_bind(struct usb_configuration *c, struct usb_function *f) obex-port_num, status); else obex-can_activate = true; +#endif DBG(cdev, obex ttyGS%d: %s speed IN/%s OUT/%s\n, -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH] usb: gadget/uvc: add streaming and data event handling
On Fri, Sep 06, 2013 at 12:18:54AM +0200, Michael Grzeschik wrote: This patch lets the kernel handle setup and data events of the uvc gadget. It is generating its response data by the prepared usb uvc control descriptores. For now only simple probe and commit events are generated and stored inside the uvc_device structure. Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de Laurent ? Any comments ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/1] usb: gadget: f_fs: Add support for SuperSpeed Mode
Hi,
On Tue, Oct 08, 2013 at 09:52:55AM +0530, Manu Gautam wrote:
On 10/2/2013 10:06 AM, Manu Gautam wrote:
On 10/1/2013 8:07 PM, Felipe Balbi wrote:
Hi,
On Mon, Sep 30, 2013 at 02:31:50PM +0530, Manu Gautam wrote:
On 9/28/2013 1:52 AM, Paul Zimmerman wrote:
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Manu Gautam
Sent: Thursday, September 26, 2013 12:08 AM
On 9/26/2013 2:10 AM, Felipe Balbi wrote:
On Tue, Sep 24, 2013 at 03:00:20PM +0530, Manu Gautam wrote:
Hi Felipe,
I wanted to mention one point with respect to this patch: Below
changes in the functionfs.h to add ss_count (super speed descriptors
count) in desc_header (which is passed from userspace) make the driver
incompatible with existing userspace applications compiled against old
header file. Let me know if that is acceptable. We are using this
driver with Android for adbd (android debug bridge) and these changes
are required to support adb over Super Speed controllers e.g. DWC3
along with changed in adbd to pass SS EP and companion descriptors.
Good you mentioned, it saves me the trouble of reviewing this patch :-)
It's not acceptable to break userspace ABI at all. If you want
SuperSpeed support on function fs, we need to figure out a way to do so
without breaking userspace.
This might mean adding a separate userspace interface to be used with
superspeed. While at that, we might want to add a few bytes of
reserved,
unused space in our structures for situations where we need to add more
data into it, just to make it slightly future proof.
Thanks for your reply.
As you suggested we can have a different interface for super speed
which would be optional to workaround ABI compatibility issue.
Let me know if below interface looks fine to you, I will then implement
accordingly:
Just a suggestion: Instead of a new interface for SuperSpeed, why not
just add the new fields to the end of the ffs_data struct? And have the
functions that copy the struct to/from userspace check the 'len' value
passed in, and only handle the SuperSpeed stuff if the length indicates
it is new userspace?
Initially I thought on similar lines but then adding a new interface for
SS looked cleaner to me. But, your suggestion also make sense as we can
avoid extra system call and the same interface can be extended later.
One more thing we can do is to add a magic number after hs_desc (i.e. at
the end of existing ffs_data) to specify that ss_descriptors are
following.
This can be used by kernel driver to check if userspace is trying pass
ss desc only or some invalid data.
Felipe: Your recommendation on this?
We need to have some more people look at this. I remember there were
always some concerns about Chris architecture when doing such changes.
Can you please add appropriate folks to this thread who can check this as
well?
I have CC'ed Michal and Andrzej as they have contributed to this driver.
Followed is the interface enhancement that I am suggesting:
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index d6b0128..0f8f7be 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -13,6 +13,7 @@ enum {
FUNCTIONFS_STRINGS_MAGIC = 2
};
+#define FUNCTIONFS_SS_DESC_MAGIC 0x0055DE5C
#ifndef __KERNEL__
@@ -50,7 +51,11 @@ struct usb_functionfs_descs_head {
* | 12 | hs_count | LE32 | number of high-speed descriptors |
* | 16 | fs_descrs | Descriptor[] | list of full-speed descriptors |
* | | hs_descrs | Descriptor[] | list of high-speed descriptors |
+ * | | ss_magic | LE32 | FUNCTIONFS_SS_DESC_MAGIC |
+ * | | ss_count | LE32 | number of super-speed descriptors|
+ * | | ss_descrs | Descriptor[] | list of super-speed descriptors |
*
+ * ss_magic: if present then it implies that SS_DESCs are also present
* descs are just valid USB descriptors and have the following format:
*
* | off | name| type | description |
any comments here ? nobody ? Manu, if nobody complains in another week,
please send this hunk as a formal patch.
--
balbi
signature.asc
Description: Digital signature
Re: [RFCv3 2/3] usb: gadget: epautoconf: check feature flags
On Tue, 26 Nov 2013, Felipe Balbi wrote:
Start matching endpoints against feature flags,
this will help us dropping the naming conventions
currently used by the Gadget Framework.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/epautoconf.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index feaaa7b..3fe0d42 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -62,6 +62,31 @@ ep_matches (
if (USB_ENDPOINT_XFER_CONTROL == type)
return 0;
+ /* first check feature flags */
+ if (ep-has_dir_in ^ usb_endpoint_dir_in(desc))
+ return 0;
+
+ if (ep-has_dir_out ^ usb_endpoint_dir_out(desc))
+ return 0;
I should have noticed this sooner (argh!). The ^ operation isn't what
you want here -- if the endpoint hardware can work in either direction
then one of those two tests is bound to fail. The code should be
structured more like the tests for the endpoint type, below. In other
words, like this:
if (usb_endpoint_dir_in(desc)) {
if (!ep-has_dir_in)
return 0;
} else {
if (!ep-has_dir_out)
return 0;
}
Alan Stern
+
+ switch (type) {
+ case USB_ENDPOINT_XFER_CONTROL:
+ /* only ep0 */
+ return 0;
+ case USB_ENDPOINT_XFER_BULK:
+ if (ep-has_bulk)
+ goto match;
+ break;
+ case USB_ENDPOINT_XFER_INT:
+ if (ep-has_interrupt)
+ goto match;
+ break;
+ case USB_ENDPOINT_XFER_ISOC:
+ if (ep-has_isochronous)
+ goto match;
+ break;
+ }
+
/* some other naming convention */
if ('e' != ep-name[0])
return 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: [RFCv3 2/3] usb: gadget: epautoconf: check feature flags
On Tue, Nov 26, 2013 at 12:56:04PM -0500, Alan Stern wrote:
On Tue, 26 Nov 2013, Felipe Balbi wrote:
Start matching endpoints against feature flags,
this will help us dropping the naming conventions
currently used by the Gadget Framework.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/epautoconf.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/epautoconf.c
b/drivers/usb/gadget/epautoconf.c
index feaaa7b..3fe0d42 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -62,6 +62,31 @@ ep_matches (
if (USB_ENDPOINT_XFER_CONTROL == type)
return 0;
+ /* first check feature flags */
+ if (ep-has_dir_in ^ usb_endpoint_dir_in(desc))
+ return 0;
+
+ if (ep-has_dir_out ^ usb_endpoint_dir_out(desc))
+ return 0;
I should have noticed this sooner (argh!). The ^ operation isn't what
you want here -- if the endpoint hardware can work in either direction
then one of those two tests is bound to fail. The code should be
structured more like the tests for the endpoint type, below. In other
words, like this:
if (usb_endpoint_dir_in(desc)) {
if (!ep-has_dir_in)
return 0;
} else {
if (!ep-has_dir_out)
return 0;
}
again, good point. /me should really review his own patches before
sending them out.
--
balbi
signature.asc
Description: Digital signature
Re: [RFCv3 2/3] usb: gadget: epautoconf: check feature flags
Hi,
On Tue, Nov 26, 2013 at 11:57:21AM -0600, Felipe Balbi wrote:
On Tue, Nov 26, 2013 at 12:56:04PM -0500, Alan Stern wrote:
On Tue, 26 Nov 2013, Felipe Balbi wrote:
Start matching endpoints against feature flags,
this will help us dropping the naming conventions
currently used by the Gadget Framework.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/epautoconf.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/epautoconf.c
b/drivers/usb/gadget/epautoconf.c
index feaaa7b..3fe0d42 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -62,6 +62,31 @@ ep_matches (
if (USB_ENDPOINT_XFER_CONTROL == type)
return 0;
+ /* first check feature flags */
+ if (ep-has_dir_in ^ usb_endpoint_dir_in(desc))
+ return 0;
+
+ if (ep-has_dir_out ^ usb_endpoint_dir_out(desc))
+ return 0;
I should have noticed this sooner (argh!). The ^ operation isn't what
you want here -- if the endpoint hardware can work in either direction
then one of those two tests is bound to fail. The code should be
structured more like the tests for the endpoint type, below. In other
words, like this:
if (usb_endpoint_dir_in(desc)) {
if (!ep-has_dir_in)
return 0;
} else {
if (!ep-has_dir_out)
return 0;
}
again, good point. /me should really review his own patches before
sending them out.
fixed in my tree [1], will only resend if there are other comments.
[1] http://bit.ly/1aRAH9m
--
balbi
signature.asc
Description: Digital signature
Re: BUG: usb: obex in g_nokia.ko causing kernel panic
On Tue 2013-11-26 18:17:49, Sebastian Reichel wrote: On Tue, Nov 26, 2013 at 06:10:22PM +0100, Pali Rohár wrote: On Tuesday 19 November 2013 11:51:12 Pali Rohár wrote: For a long time (since 3.5 or 3.8? - I do not remember) obex subdriver in g_nokia usb gadget module causing kernel panic after module is loaded on Nokia N900. I do not know where is problem and due to immediatelly kernel crash when loading driver I was not able to see any dmesg output. Now I was able to store something into mtd log and here is crash backtrace: [...] Hi! can you look at this problem? So it worked at some time? Have you tried to git bisect the problem? You are a cruel person :-). N900 historically boots about half of the time, trying to do git bisect there is a nice weekend project... for about next century or so. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: usb: obex in g_nokia.ko causing kernel panic
On Tuesday 26 November 2013 18:39:54 Felipe Balbi wrote: Hi, On Tue, Nov 26, 2013 at 06:28:05PM +0100, Pali Rohár wrote: [ snip ] (above dump is from 3.12-rc5 kernel) looks like it's trying to do i2c transfers from atomic. But why only when obex is enabled ? Makes no sense. What do you have on userland ? Is there anything trying to access the obex interface ? Was the USB cable attached at that time ? Yes, only when initliaizing obex. Other is ok. Problem is there with Maemo userland and also with clean userland (rescueOS) where is only busybox and some simple init scripts. On Maemo maybe something is trying to access obex, but on rescueOS for sure nothing. Problem happends when cable is attached and also when not = always. As a debug effort, can you apply hack below and see if it helps ? diff --git a/drivers/usb/gadget/f_obex.c b/drivers/usb/gadget/f_obex.c index ad39f1d..4af2f06 100644 --- a/drivers/usb/gadget/f_obex.c +++ b/drivers/usb/gadget/f_obex.c @@ -267,10 +267,12 @@ static void obex_connect(struct gserial *g) if (!obex-can_activate) return; +#if 0 status = usb_function_activate(g-func); if (status) DBG(cdev, obex ttyGS%d function activate -- %d\n, obex-port_num, status); +#endif } static void obex_disconnect(struct gserial *g) @@ -282,10 +284,12 @@ static void obex_disconnect(struct gserial *g) if (!obex-can_activate) return; +#if 0 status = usb_function_deactivate(g-func); if (status) DBG(cdev, obex ttyGS%d function deactivate -- %d\n, obex-port_num, status); +#endif } /*--- --*/ @@ -372,6 +376,7 @@ static int obex_bind(struct usb_configuration *c, struct usb_function *f) if (status) goto fail; +#if 0 /* Avoid letting this gadget enumerate until the userspace * OBEX server is active. */ @@ -381,6 +386,7 @@ static int obex_bind(struct usb_configuration *c, struct usb_function *f) obex-port_num, status); else obex-can_activate = true; +#endif DBG(cdev, obex ttyGS%d: %s speed IN/%s OUT/%s\n, Hi, with above patch g_nokia.ko working and not crashing. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: BUG: usb: obex in g_nokia.ko causing kernel panic
Hi, On Tue, Nov 26, 2013 at 07:06:43PM +0100, Pavel Machek wrote: For a long time (since 3.5 or 3.8? - I do not remember) obex subdriver in g_nokia usb gadget module causing kernel panic after module is loaded on Nokia N900. I do not know where is problem and due to immediatelly kernel crash when loading driver I was not able to see any dmesg output. Now I was able to store something into mtd log and here is crash backtrace: [...] Hi! can you look at this problem? So it worked at some time? Have you tried to git bisect the problem? You are a cruel person :-). N900 historically boots about half of the time, trying to do git bisect there is a nice weekend project... for about next century or so. heh, I'll agree to that :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] usb: dwc3: Add Keystone specific glue layer
On Tuesday 26 November 2013 12:16 PM, Felipe Balbi wrote: On Mon, Nov 25, 2013 at 07:49:01PM -0500, Santosh Shilimkar wrote: On Monday 25 November 2013 03:39 PM, Felipe Balbi wrote: Hi, [...] + kdwc3_dma_mask = dma_get_mask(dev); + dev-dma_mask = kdwc3_dma_mask; + + error = kdwc3_enable(kdwc); I would drop this function and just add your clk_prepare() here, then move clk_enable()/clk_disable() to -runtime_resume/-runtime_suspend() respectively. Then you could just call pm_runtime_get_sync() when you need to access your registers and pm_runtime_put() when you want to drop the clock reference. this will even make PM implementation a lot easier for you going forward. Just to make the PM runtime part clear, there are few issues with PM core clock layer [1], hence drivers is using clock layer. Its trivial to update the driver though once the issue is sorted out. Meanwhile driver development continue to be with clock calls. I don't mind having those clock calls, just suggested a different placement for them. I got that part. Just wanted to clear the runtime PM part. Regards, Santosh -- 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: BUG: usb: obex in g_nokia.ko causing kernel panic
Hi, On Tue, Nov 26, 2013 at 07:10:08PM +0100, Pali Rohár wrote: (above dump is from 3.12-rc5 kernel) looks like it's trying to do i2c transfers from atomic. But why only when obex is enabled ? Makes no sense. What do you have on userland ? Is there anything trying to access the obex interface ? Was the USB cable attached at that time ? Yes, only when initliaizing obex. Other is ok. Problem is there with Maemo userland and also with clean userland (rescueOS) where is only busybox and some simple init scripts. On Maemo maybe something is trying to access obex, but on rescueOS for sure nothing. Problem happends when cable is attached and also when not = always. As a debug effort, can you apply hack below and see if it helps ? diff --git a/drivers/usb/gadget/f_obex.c b/drivers/usb/gadget/f_obex.c index ad39f1d..4af2f06 100644 --- a/drivers/usb/gadget/f_obex.c +++ b/drivers/usb/gadget/f_obex.c @@ -267,10 +267,12 @@ static void obex_connect(struct gserial *g) if (!obex-can_activate) return; +#if 0 status = usb_function_activate(g-func); if (status) DBG(cdev, obex ttyGS%d function activate -- %d\n, obex-port_num, status); +#endif } static void obex_disconnect(struct gserial *g) @@ -282,10 +284,12 @@ static void obex_disconnect(struct gserial *g) if (!obex-can_activate) return; +#if 0 status = usb_function_deactivate(g-func); if (status) DBG(cdev, obex ttyGS%d function deactivate -- %d\n, obex-port_num, status); +#endif } /*--- --*/ @@ -372,6 +376,7 @@ static int obex_bind(struct usb_configuration *c, struct usb_function *f) if (status) goto fail; +#if 0 /* Avoid letting this gadget enumerate until the userspace * OBEX server is active. */ @@ -381,6 +386,7 @@ static int obex_bind(struct usb_configuration *c, struct usb_function *f) obex-port_num, status); else obex-can_activate = true; +#endif DBG(cdev, obex ttyGS%d: %s speed IN/%s OUT/%s\n, Hi, with above patch g_nokia.ko working and not crashing. yeah, makes sense. We shouldn't call phy operations in atomic context. I'll see how easy it would be to fix that. Real patch coming soon(-ish). -- balbi signature.asc Description: Digital signature
Re: BUG: usb: obex in g_nokia.ko causing kernel panic
Hi, On Tue, Nov 26, 2013 at 12:59:13PM -0600, Felipe Balbi wrote: diff --git a/drivers/usb/gadget/f_obex.c b/drivers/usb/gadget/f_obex.c index ad39f1d..4af2f06 100644 --- a/drivers/usb/gadget/f_obex.c +++ b/drivers/usb/gadget/f_obex.c @@ -267,10 +267,12 @@ static void obex_connect(struct gserial *g) if (!obex-can_activate) return; +#if 0 status = usb_function_activate(g-func); if (status) DBG(cdev, obex ttyGS%d function activate -- %d\n, obex-port_num, status); +#endif } static void obex_disconnect(struct gserial *g) @@ -282,10 +284,12 @@ static void obex_disconnect(struct gserial *g) if (!obex-can_activate) return; +#if 0 status = usb_function_deactivate(g-func); if (status) DBG(cdev, obex ttyGS%d function deactivate -- %d\n, obex-port_num, status); +#endif } /*--- --*/ @@ -372,6 +376,7 @@ static int obex_bind(struct usb_configuration *c, struct usb_function *f) if (status) goto fail; +#if 0 /* Avoid letting this gadget enumerate until the userspace * OBEX server is active. */ @@ -381,6 +386,7 @@ static int obex_bind(struct usb_configuration *c, struct usb_function *f) obex-port_num, status); else obex-can_activate = true; +#endif DBG(cdev, obex ttyGS%d: %s speed IN/%s OUT/%s\n, Hi, with above patch g_nokia.ko working and not crashing. yeah, makes sense. We shouldn't call phy operations in atomic context. I'll see how easy it would be to fix that. Real patch coming soon(-ish). I think we could send diff below for the -rc cycle and figure out a better to handle this for the merge window. Can you check if it also works with patch below ? diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 2a408cd..8aa59a2 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -659,7 +659,6 @@ static int omap2430_runtime_suspend(struct device *dev) OTG_INTERFSEL); omap2430_low_level_exit(musb); - phy_power_off(musb-phy); } return 0; @@ -674,7 +673,6 @@ static int omap2430_runtime_resume(struct device *dev) omap2430_low_level_init(musb); musb_writel(musb-mregs, OTG_INTERFSEL, musb-context.otg_interfsel); - phy_power_on(musb-phy); } return 0; -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 06/14] USB: centralize usb port power policy
On Mon, 2013-11-25 at 11:05 -0800, Dan Williams wrote: On Mon, Nov 25, 2013 at 3:33 AM, Oliver Neukum oneu...@suse.de wrote: On Fri, 2013-11-22 at 12:18 -0800, Dan Williams wrote: On Fri, Nov 22, 2013 at 2:39 AM, Oliver Neukum oneu...@suse.de wrote: On Fri, 2013-11-22 at 01:07 -0800, Dan Williams wrote: Move all port power policy evaluation to usb_port_runtime_suspend(). Makes it clearer what blocks port power off and is preparation for follow on changes that 1/ make a usb_port a proper (device model) parent of a usb_device 2/ advertise to userspace what constraints are keeping a port powered 3/ changing the meaning of the usb_port runtime suspended state. 4/ add new constraints peer-port-power-state and connect_type It seems to me that if you use reset_resume() you must check whether all children further down in the tree support reset_resume() in their drivers. If a device does not support reset_resume I expect it will fail autosuspend_check(). When that happens the device will stay in the Why? They would fail only if, needs_remote_wakeup were set. It may or may not be. It also fails in the simple case where the driver has disabled autosuspend for the device. If a device is enabling autosuspend and does not support reset_resume it will already have issues with its parent hub going into autosuspend. The hub resume path forces reset_resume for child devices. Can you please elaborate? It seems to me that hub_activate() deals with a survival of the power session just fine. There seems to be a fundamental misunderstanding here. Regards Oliver -- 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 4/4] usb/gadget: f_sourcesink: add configfs support
On Thu, Nov 07, 2013 at 08:41:28AM +0100, Andrzej Pietrasiewicz wrote: Add support for using the sourcesink function in gadgets composed with configfs. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com fuzz on Kconfig, please check [1] [1] http://bit.ly/18mbMMQ -- balbi signature.asc Description: Digital signature
Re: [PATCH 09/12] usb: gadget: r8a66597-udc: Convert to clk_prepare/unprepare
On Tue, Nov 26, 2013 at 03:16:47AM +0100, Laurent Pinchart wrote: Hi Felipe, On Monday 25 November 2013 20:12:39 Felipe Balbi wrote: Hi, On Tue, Nov 26, 2013 at 02:59:51AM +0100, Laurent Pinchart wrote: (2013/10/29 7:49), Laurent Pinchart wrote: Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and clk_disable_unprepare() to get ready for the migration to the common clock framework. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Thank you for the patch. Acked-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Could you please pick this patch up ? after -rc1 is out, I don't see why not. Great then :-) As this patch is a dependency for other series that will go through different trees, could you please provide a stable branch in your tree with this patch included that you will push to v3.14 ? You guys are always killing me with those stable branch requests :-) I'll get one up tomorrow. I guess I can avoid a topic branch altogether if I just make this the first patch in next branch. I could push only $subject for now until you merge then I'll push other stuff. Is that enough for you ? My 'next' is always immutable. That sounds good, thank you. You can already push the other patches without waiting for me, I can dig the commit ID of the first patch in your next branch. pushed, btw. you should have received my automatic email. If you merge my next, you'll get only that commit. I believe tomorrow I'll be able to push more commits into next. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 3/4] usb/gadget: f_loopback: add configfs support
On Thu, Nov 07, 2013 at 08:41:27AM +0100, Andrzej Pietrasiewicz wrote: Add support for using the loopback USB function in gadgets composed with configfs. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com this one applied with fuzz on Kconfig, can you check if it looks good to you at [1] ? [1] http://bit.ly/1aRYYMC -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 06/14] USB: centralize usb port power policy
On Tue, Nov 26, 2013 at 11:40 AM, Oliver Neukum oneu...@suse.de wrote: On Mon, 2013-11-25 at 11:05 -0800, Dan Williams wrote: On Mon, Nov 25, 2013 at 3:33 AM, Oliver Neukum oneu...@suse.de wrote: On Fri, 2013-11-22 at 12:18 -0800, Dan Williams wrote: On Fri, Nov 22, 2013 at 2:39 AM, Oliver Neukum oneu...@suse.de wrote: On Fri, 2013-11-22 at 01:07 -0800, Dan Williams wrote: Move all port power policy evaluation to usb_port_runtime_suspend(). Makes it clearer what blocks port power off and is preparation for follow on changes that 1/ make a usb_port a proper (device model) parent of a usb_device 2/ advertise to userspace what constraints are keeping a port powered 3/ changing the meaning of the usb_port runtime suspended state. 4/ add new constraints peer-port-power-state and connect_type It seems to me that if you use reset_resume() you must check whether all children further down in the tree support reset_resume() in their drivers. If a device does not support reset_resume I expect it will fail autosuspend_check(). When that happens the device will stay in the Why? They would fail only if, needs_remote_wakeup were set. It may or may not be. It also fails in the simple case where the driver has disabled autosuspend for the device. If a device is enabling autosuspend and does not support reset_resume it will already have issues with its parent hub going into autosuspend. The hub resume path forces reset_resume for child devices. Can you please elaborate? It seems to me that hub_activate() deals with a survival of the power session just fine. There seems to be a fundamental misunderstanding here. Your concern was what to do when a device does not support reset_resume and I was merely pointing out that such a device will experience reset_resume as a part of hub_resume(). So, aside from possibly changing the occurrence frequency these port power changes are not introducing a new recovery scheme. What's unclear? -- 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] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks
On Tuesday, November 26, 2013 10:48:56 AM Ulf Hansson wrote: On 26 November 2013 00:10, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, November 25, 2013 01:40:21 PM Ulf Hansson wrote: To put devices into low power state during sleep, it sometimes makes sense at subsystem-level to re-use device's runtime PM callbacks. The PM core will at device_suspend_late disable runtime PM, after that we can safely operate on these callbacks. At suspend_late the device will be put into low power state by invoking the device's runtime_suspend callback, unless the runtime status is already suspended. At resume_early the state is restored by invoking the device's runtime_resume callback. Soon after the PM core will re-enable runtime PM before returning from device_resume_early. The new pm_generic functions are named pm_generic_suspend_late_runtime and pm_generic_resume_early_runtime, they are supposed to be used in pairs. What happens if the subsystem uses the new functions as its late suspend/ early resume callbacks, but some of its drivers implement .suspend_late() and .resume_early()? Good point. Normally, I think the decision of using these callbacks should be taken at the lowest level, in other words in the driver. Otherwise the lowest layer of .suspend_late will be by-passed. I'm not sure what's the point to add them, then. If the driver has to decide anyway, it may simply populate its .suspend_late and .resume_early pointers I think. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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: zte_ev not properly handling ZTE AC2726 CDMA modems
Hi Jonah,
Do you think this patch will work against 3.9.11? If not, I'll have to
invest some time into upgrading to 3.12 which proved to be difficult given
all the Broadcom-related modifications in the kernel..
Thank you!
Regards, Dmitry
-Original Message-
From: Johan Hovold [mailto:jhov...@gmail.com]
Sent: Tuesday, November 26, 2013 6:39 AM
To: Dmitry Kunilov
Cc: linux-usb@vger.kernel.org
Subject: Re: zte_ev not properly handling ZTE AC2726 CDMA modems
On Mon, Nov 25, 2013 at 06:15:28PM -0800, Dmitry Kunilov wrote:
Hi everyone,
As a late follow-up to the discussion that happened in June about
moving support for most ZTE CDMA devices from option.c to zte_ev.c
(where the decision was to convert and see if anyone complains), I'd
like to complain
:)
We have a park of approximately thirty ZTE AC2726 EVDO modems
connected to Broadcom-based routers running Linux-mips. After recent
upgrade from ancient
2.6.22 to relatively modern 3.9.11, all 30 are having the same
problem: pppd connects and Internet access works for 20 to 60 seconds,
then connectivity drops and pppd logs an LCP timeout. After that, pppd
is able to restart the connection and run for another 20-60 seconds.
I did notice that these modems are now handled by zte_ev instead of
option, so I went and moved all the DEVICE_INFO's back from zte_ev.c
to option.c and also disabled zte_ev module in the kernel
configuration. After this change, the modems work just fine, like they
did on 2.6.22 - using the option driver.
Please let me know if there is any debug info I can collect to help
resolve this issue.
Would you mind trying the patch below (against v3.12)?
Thanks,
Johan
From a84412903e68e9e5ae4693ddd1fa7d9c780cbd28 Mon Sep 17 00:00:00 2001
From: Johan Hovold jhov...@gmail.com
Date: Tue, 26 Nov 2013 15:26:49 +0100
Subject: [PATCH] USB: serial: zte_ev debug patch
Continue to read on errors.
Warn about failed reads and writes.
Increase zte_ev buffer sizes.
Fix race in write which could lead to (temporarily) degraded throughput
(backport of fix in Greg's usb-linus branch).
---
drivers/usb/serial/generic.c | 23 ---
drivers/usb/serial/zte_ev.c | 2 ++
2 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 1f31e6b4c251..b5d976ae1b0d 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -176,14 +176,7 @@ retry:
return result;
}
- /* Try sending off another urb, unless in irq context (in which case
-* there will be no free urb). */
- if (!in_irq())
- goto retry;
-
- clear_bit_unlock(USB_SERIAL_WRITE_BUSY, port-flags);
-
- return 0;
+ goto retry;
}
/**
@@ -369,15 +362,15 @@ void usb_serial_generic_read_bulk_callback(struct urb
*urb)
dev_dbg(port-dev, %s - urb %d, len %d\n, __func__, i,
urb-actual_length);
- if (urb-status) {
- dev_dbg(port-dev, %s - non-zero urb status: %d\n,
+ if (!urb-status) {
+ usb_serial_debug_data(port-dev, __func__,
urb-actual_length,
+
data);
+ port-serial-type-process_read_urb(urb);
+ } else {
+ dev_warn(port-dev, %s - non-zero urb status: %d\n,
__func__, urb-status);
- return;
}
- usb_serial_debug_data(port-dev, __func__, urb-actual_length,
data);
- port-serial-type-process_read_urb(urb);
-
/* Throttle the device if requested by tty */
spin_lock_irqsave(port-lock, flags);
port-throttled = port-throttle_req;
@@ -406,7 +399,7 @@ void usb_serial_generic_write_bulk_callback(struct urb
*urb)
spin_unlock_irqrestore(port-lock, flags);
if (status) {
- dev_dbg(port-dev, %s - non-zero urb status: %d\n,
+ dev_warn(port-dev, %s - non-zero urb status: %d\n,
__func__, status);
spin_lock_irqsave(port-lock, flags); diff --git
a/drivers/usb/serial/zte_ev.c b/drivers/usb/serial/zte_ev.c index
fca4c752a4ed..36152e3e2605 100644
--- a/drivers/usb/serial/zte_ev.c
+++ b/drivers/usb/serial/zte_ev.c
@@ -307,6 +307,8 @@ static struct usb_serial_driver zio_device = {
},
.id_table = id_table,
.num_ports =1,
+ .bulk_in_size = 2048,
+ .bulk_out_size =2048,
.open = zte_ev_usb_serial_open,
.close =zte_ev_usb_serial_close,
};
--
1.8.4.4
--
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: zte_ev not properly handling ZTE AC2726 CDMA modems
[ Please, try to avoid top-posting. ]
On Tue, Nov 26, 2013 at 12:37:21PM -0800, Dmitry Kunilov wrote:
Hi Jonah,
Do you think this patch will work against 3.9.11? If not, I'll have to
invest some time into upgrading to 3.12 which proved to be difficult given
all the Broadcom-related modifications in the kernel..
Yes, the patch should work on 3.9 as well, although it might not apply
cleanly. Try the patch below instead if your stuck with 3.9.
Thanks,
Johan
-Original Message-
From: Johan Hovold [mailto:jhov...@gmail.com]
Sent: Tuesday, November 26, 2013 6:39 AM
To: Dmitry Kunilov
Cc: linux-usb@vger.kernel.org
Subject: Re: zte_ev not properly handling ZTE AC2726 CDMA modems
On Mon, Nov 25, 2013 at 06:15:28PM -0800, Dmitry Kunilov wrote:
Hi everyone,
As a late follow-up to the discussion that happened in June about
moving support for most ZTE CDMA devices from option.c to zte_ev.c
(where the decision was to convert and see if anyone complains), I'd
like to complain
:)
We have a park of approximately thirty ZTE AC2726 EVDO modems
connected to Broadcom-based routers running Linux-mips. After recent
upgrade from ancient
2.6.22 to relatively modern 3.9.11, all 30 are having the same
problem: pppd connects and Internet access works for 20 to 60 seconds,
then connectivity drops and pppd logs an LCP timeout. After that, pppd
is able to restart the connection and run for another 20-60 seconds.
I did notice that these modems are now handled by zte_ev instead of
option, so I went and moved all the DEVICE_INFO's back from zte_ev.c
to option.c and also disabled zte_ev module in the kernel
configuration. After this change, the modems work just fine, like they
did on 2.6.22 - using the option driver.
Please let me know if there is any debug info I can collect to help
resolve this issue.
Would you mind trying the patch below (against v3.12)?
Thanks,
Johan
From 9520079e3047f2c74a1965196e4d1993e6ca11a0 Mon Sep 17 00:00:00 2001
From: Johan Hovold jhov...@gmail.com
Date: Tue, 26 Nov 2013 15:26:49 +0100
Subject: [PATCH v3.9] USB: serial: zte_ev debug patch
Continue to read on errors.
Warn about failed reads and writes.
Increase zte_ev buffer sizes.
Fix race in write which could lead to (temporarily) degraded throughput
(backport of fix in Greg's usb-linus branch).
---
drivers/usb/serial/generic.c | 23 ---
drivers/usb/serial/zte_ev.c | 2 ++
2 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 4c5c23f1cae5..01ab8c78eb9d 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -187,14 +187,7 @@ retry:
return result;
}
- /* Try sending off another urb, unless in irq context (in which case
-* there will be no free urb). */
- if (!in_irq())
- goto retry;
-
- clear_bit_unlock(USB_SERIAL_WRITE_BUSY, port-flags);
-
- return 0;
+ goto retry;
}
/**
@@ -350,15 +343,15 @@ void usb_serial_generic_read_bulk_callback(struct urb
*urb)
dev_dbg(port-dev, %s - port %d, urb %d, len %d\n,
__func__, port-number, i, urb-actual_length);
- if (urb-status) {
- dev_dbg(port-dev, %s - non-zero urb status: %d\n,
+ if (!urb-status) {
+ usb_serial_debug_data(port-dev, __func__, urb-actual_length,
+ data);
+ port-serial-type-process_read_urb(urb);
+ } else {
+ dev_warn(port-dev, %s - non-zero urb status: %d\n,
__func__, urb-status);
- return;
}
- usb_serial_debug_data(port-dev, __func__, urb-actual_length, data);
- port-serial-type-process_read_urb(urb);
-
/* Throttle the device if requested by tty */
spin_lock_irqsave(port-lock, flags);
port-throttled = port-throttle_req;
@@ -387,7 +380,7 @@ void usb_serial_generic_write_bulk_callback(struct urb *urb)
spin_unlock_irqrestore(port-lock, flags);
if (status) {
- dev_dbg(port-dev, %s - non-zero urb status: %d\n,
+ dev_warn(port-dev, %s - non-zero urb status: %d\n,
__func__, status);
spin_lock_irqsave(port-lock, flags);
diff --git a/drivers/usb/serial/zte_ev.c b/drivers/usb/serial/zte_ev.c
index 39ee7373b4ee..952dbb23cbbc 100644
--- a/drivers/usb/serial/zte_ev.c
+++ b/drivers/usb/serial/zte_ev.c
@@ -295,6 +295,8 @@ static struct usb_serial_driver zio_device = {
},
.id_table = id_table,
.num_ports =1,
+ .bulk_in_size = 2048,
+ .bulk_out_size =2048,
.open = zte_ev_usb_serial_open,
.close =zte_ev_usb_serial_close,
};
--
1.8.4.4
--
To unsubscribe from this
Re: [PATCH v3 09/10] ARM: dts: omap3-beagle-xm: Add USB Host support
* Roger Quadros rog...@ti.com [131120 02:33]: Nishant, On 11/19/2013 11:05 PM, Nishanth Menon wrote: On 09/24/2013 03:53 AM, Roger Quadros wrote: Provide RESET GPIO and Power regulator for the USB PHY, the USB Host port mode and the PHY device for the controller. Also provide pin multiplexer information for USB host pins. We also relocate omap3_pmx_core pin definations so that they are close to omap3_pmx_wkup pin definations. Signed-off-by: Roger Quadros rog...@ti.com --- just using this thread, but a question - I am kernel * master dec8e46 Merge tag 'arc-v3.13-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc and I see that VAUX2 which supplies USB_1V8[1] is not enabled - I did a quick patch and it did seem to work (Usb keyboard, networking, mouse etc on my ehci ports seems to come up good) - any suggestions how we'd like to handle this? It worked for me without your patch. It could be that u-boot is enabling that regulator for me. I'm on u-boot-v2013.10. In any case, your patch seems the right thing to do. We should take it in the rc cycle. Can you guys post a proper fix for this? Meanwhile, I'll mark this thread as read to shrink my inbox a bit. Regards, Tony -- 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] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks
On Tue, 26 Nov 2013, Rafael J. Wysocki wrote: On Tuesday, November 26, 2013 10:48:56 AM Ulf Hansson wrote: On 26 November 2013 00:10, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, November 25, 2013 01:40:21 PM Ulf Hansson wrote: To put devices into low power state during sleep, it sometimes makes sense at subsystem-level to re-use device's runtime PM callbacks. Ulf, please be more careful about the distinction between device and driver. Devices don't have callbacks; drivers do. You made this mistake a few times in the patch description. The PM core will at device_suspend_late disable runtime PM, after that we can safely operate on these callbacks. At suspend_late the device will be put into low power state by invoking the device's runtime_suspend callback, unless the runtime status is already suspended. At resume_early the state is restored by invoking the device's runtime_resume callback. Soon after the PM core will re-enable runtime PM before returning from device_resume_early. The new pm_generic functions are named pm_generic_suspend_late_runtime and pm_generic_resume_early_runtime, they are supposed to be used in pairs. What happens if the subsystem uses the new functions as its late suspend/ early resume callbacks, but some of its drivers implement .suspend_late() and .resume_early()? The same thing that happens whenever any PM-related callback is defined by both the subsystem and the driver: The PM core uses the subsystem's callback. (Or the pm_domain's callback, or the type's callback, or the class's callback.) Besides, Ulf specifically assumed at the top of this message that re-using the runtime-suspend callback makes sense at the subsystem level. This must mean it is appropriate for all drivers in the subsystem. So why would a driver want to override the subsystem's behavior? Good point. Normally, I think the decision of using these callbacks should be taken at the lowest level, in other words in the driver. Otherwise the lowest layer of .suspend_late will be by-passed. I'm not sure what's the point to add them, then. If the driver has to decide anyway, it may simply populate its .suspend_late and .resume_early pointers I think. Another possibility is to have the pm_generic_suspend_late_runtime routine check to see if the driver has defined a suspend_late callback. If the driver has its own callback, we could invoke it instead of invoking the runtime_suspend callback. However, I'm not sure that doing this would be worthwhile. And it would hang in an infinite loop if the driver set its suspend_late pointer to pm_generic_suspend_late_runtime! 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
huawei E5776 (hilink) 3.12--3.13 not working anymore
Hi, I have it already mentioned somewhere. Sorry for duplicates. The Huawei E5776 (normal use, classic IPv4, hilink mode (with webinterface and RFC1918 IP- config including NAT) worked well with 3.12 and before, but it doesn't work any more with 3.13. At least one local branded version of the huawei E3776 is also affected. Thomas e5776.tar.xz Description: application/xz-compressed-tar
Re: [3.8-rc3 - 3.8-rc4 regression] Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used
On Mon, Aug 12, 2013 at 10:09 AM, Tejun Heo t...@kernel.org wrote: Hello, Jonathan. On Mon, Aug 12, 2013 at 12:04:11AM -0700, Jonathan Nieder wrote: My laptop fails to boot[1] with the message 'Volume group data not found'. Bisects to v3.8-rc4~17 (the above commit). Reverting that commit on top of current master (d92581fcad18, 2013-08-10) produces a working kernel. dmesg output from that working kernel attached. More details, including .config, at [2]. Any ideas for tracking this down? Which initrd / boot script are you using? It looks like lvm assemble scripts are running before sdX are detected leading to volume assembly failure. Before the patch, any module loading would end up synchronizing async probes but after the patch modprobe invocations which don't schedule them won't be. Does your boot script happen to run multiple modprobes in parallel and proceed to configure lvm without waiting for modprobes of libata drivers to finish? Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ I'm also hitting a regression b/c of this patch. Booting 3.10.20 on a number of older machines with onboard sata controllers are unable to find their root device quickly enough. I bisected the issue down to 774a1221e862b343388347bac9b318767336b20b. Reverting it allows my systems to boot fine. I'm seeing this with both sata_svw and ahci. I'm using ubuntu precise userspace which is using initramfs-tools 0.99ubuntu13.1. From what I can tell the modprobes in this initrd are done in serial, but the port probing is async. This allows init to continue on to try and mount root, but it's not there yet. I'm attaching some serial log output with initcall_debug enabled. Both ahci and sata_svw call ata_host_activate(), which call ata_host_register() and async_schedule(async_port_probe, ap). Let me know what other information you may need. Thanks -- Josh seriallog Description: Binary data
Re: [RFC V2 PATCH 0/2] Defer HCD init until the external PHY, bound to the HCD is ready
On 11/07/2013 03:14 PM, Valentine Barshak wrote: This adds remove_phy flag to the HCD structure. If the flag is set and if hcd-phy is valid, the phy is shutdown and released whenever usb_add_hcd fails or usb_hcd_remove is called. This also adds generic external phy support that allows the HCD driver to search for a USB phy, bound to the HCD, when the HC is being added. If the USB PHY is found, it is initialized and the remove_phy flag is set. In case PHY is not ready, the usb_add_hcd function returns the -EPROBE_DEFER error code which defers HCD probing till the PHY becomes ready. If no PHY is bound to the HCD, or it has been initialized by the glue-driver before calling usb_add_hcd(), the HCD is added as usual. This approach can be used to initialize the external PHY for the R-Car PCI USB hosts, that share USB ports with USBHS/USBSS devices. All we need to do is to make R-Car Gen2 platform code bind the Gen2 USB phy device to the PCI HC devices, and make the phy-rcar-gen2-usb driver register USB phy with usb_add_phy_dev() AOT usb_add_phy() callback. Changes from previous version: * Used #ifdef CONFIG_USB_PHY instead of introducing new config option. Valentine Barshak (2): usb: hcd: Remove USB phy if needed usb: hcd: Initialize USB phy if needed drivers/usb/core/hcd.c | 34 +- include/linux/usb/hcd.h | 1 + 2 files changed, 34 insertions(+), 1 deletion(-) Greg, are you going to take these or is there anything else I have to do? Thanks, Val. -- 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 09/12] usb: gadget: r8a66597-udc: Convert to clk_prepare/unprepare
Hi Felipe, On Tuesday 26 November 2013 13:54:22 Felipe Balbi wrote: On Tue, Nov 26, 2013 at 03:16:47AM +0100, Laurent Pinchart wrote: On Monday 25 November 2013 20:12:39 Felipe Balbi wrote: On Tue, Nov 26, 2013 at 02:59:51AM +0100, Laurent Pinchart wrote: (2013/10/29 7:49), Laurent Pinchart wrote: Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and clk_disable_unprepare() to get ready for the migration to the common clock framework. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Thank you for the patch. Acked-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Could you please pick this patch up ? after -rc1 is out, I don't see why not. Great then :-) As this patch is a dependency for other series that will go through different trees, could you please provide a stable branch in your tree with this patch included that you will push to v3.14 ? You guys are always killing me with those stable branch requests :-) I'll get one up tomorrow. I guess I can avoid a topic branch altogether if I just make this the first patch in next branch. I could push only $subject for now until you merge then I'll push other stuff. Is that enough for you ? My 'next' is always immutable. That sounds good, thank you. You can already push the other patches without waiting for me, I can dig the commit ID of the first patch in your next branch. pushed, btw. you should have received my automatic email. I have, thank you. If you merge my next, you'll get only that commit. I believe tomorrow I'll be able to push more commits into next. I've asked Simon Horman (the Renesas SoC kernel maintainer) to merge your next branch in his tree. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: [RFC V2 PATCH 0/2] Defer HCD init until the external PHY, bound to the HCD is ready
On Wed, Nov 27, 2013 at 01:31:06AM +0400, Valentine wrote: On 11/07/2013 03:14 PM, Valentine Barshak wrote: This adds remove_phy flag to the HCD structure. If the flag is set and if hcd-phy is valid, the phy is shutdown and released whenever usb_add_hcd fails or usb_hcd_remove is called. This also adds generic external phy support that allows the HCD driver to search for a USB phy, bound to the HCD, when the HC is being added. If the USB PHY is found, it is initialized and the remove_phy flag is set. In case PHY is not ready, the usb_add_hcd function returns the -EPROBE_DEFER error code which defers HCD probing till the PHY becomes ready. If no PHY is bound to the HCD, or it has been initialized by the glue-driver before calling usb_add_hcd(), the HCD is added as usual. This approach can be used to initialize the external PHY for the R-Car PCI USB hosts, that share USB ports with USBHS/USBSS devices. All we need to do is to make R-Car Gen2 platform code bind the Gen2 USB phy device to the PCI HC devices, and make the phy-rcar-gen2-usb driver register USB phy with usb_add_phy_dev() AOT usb_add_phy() callback. Changes from previous version: * Used #ifdef CONFIG_USB_PHY instead of introducing new config option. Valentine Barshak (2): usb: hcd: Remove USB phy if needed usb: hcd: Initialize USB phy if needed drivers/usb/core/hcd.c | 34 +- include/linux/usb/hcd.h | 1 + 2 files changed, 34 insertions(+), 1 deletion(-) Greg, are you going to take these or is there anything else I have to do? I don't see anything to take here, sorry. You sent some patches with Request for Comments, which usually means, don't apply them, I just want people to look at them, so I don't apply them... If you want me to apply them, please resend without that. Also, I'd like to get Alan's ACK on these, as they touch the core HCD code. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [3.8-rc3 - 3.8-rc4 regression] Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used
On Tue, Nov 26, 2013 at 1:29 PM, Josh Hunt joshhun...@gmail.com wrote:
Both ahci and sata_svw call ata_host_activate(), which call
ata_host_register() and async_schedule(async_port_probe, ap).
Well, with the modern logic (only wait for async probing if the
module itself did async probing) the ahci and svw modules didn't
really change any behavior.
But other modules did. I wonder, for example, if people insmod the dm
module, and expect all devices to exist afterwards. Which the old
logic of we always wait for all async code regardless of whether we
started it ourselves would do, but the new logic does not.
Something similar might hit the (non-modular) md auto-detect ioctl.
So maybe we should just special-case those two issues, and say let's
just wait for async requests here
Something like the appended (whitespace-damaged) diff. Does that make
a difference to you guys? And if it does, can you check *which* of the
two async_synchronize_full() calls it is that matters for your cases?
Linus
--- duh, apply by hand --
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 0704c523a76b..7e7a2f743b11 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -351,6 +351,7 @@ static int __init dm_init(void)
goto bad;
}
+ async_synchronize_full();
return 0;
bad:
diff --git a/drivers/md/md.c b/drivers/md/md.c
index b6b7a2866c9e..1d173dc662fc 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8602,6 +8602,7 @@ static void autostart_arrays(int part)
i_scanned = 0;
i_passed = 0;
+ async_synchronize_full();
printk(KERN_INFO md: Autodetecting RAID arrays.\n);
while (!list_empty(all_detected_devices) i_scanned INT_MAX) {
--
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 V2 PATCH 0/2] Defer HCD init until the external PHY, bound to the HCD is ready
On 11/27/2013 01:44 AM, Greg KH wrote: On Wed, Nov 27, 2013 at 01:31:06AM +0400, Valentine wrote: On 11/07/2013 03:14 PM, Valentine Barshak wrote: This adds remove_phy flag to the HCD structure. If the flag is set and if hcd-phy is valid, the phy is shutdown and released whenever usb_add_hcd fails or usb_hcd_remove is called. This also adds generic external phy support that allows the HCD driver to search for a USB phy, bound to the HCD, when the HC is being added. If the USB PHY is found, it is initialized and the remove_phy flag is set. In case PHY is not ready, the usb_add_hcd function returns the -EPROBE_DEFER error code which defers HCD probing till the PHY becomes ready. If no PHY is bound to the HCD, or it has been initialized by the glue-driver before calling usb_add_hcd(), the HCD is added as usual. This approach can be used to initialize the external PHY for the R-Car PCI USB hosts, that share USB ports with USBHS/USBSS devices. All we need to do is to make R-Car Gen2 platform code bind the Gen2 USB phy device to the PCI HC devices, and make the phy-rcar-gen2-usb driver register USB phy with usb_add_phy_dev() AOT usb_add_phy() callback. Changes from previous version: * Used #ifdef CONFIG_USB_PHY instead of introducing new config option. Valentine Barshak (2): usb: hcd: Remove USB phy if needed usb: hcd: Initialize USB phy if needed drivers/usb/core/hcd.c | 34 +- include/linux/usb/hcd.h | 1 + 2 files changed, 34 insertions(+), 1 deletion(-) Greg, are you going to take these or is there anything else I have to do? I don't see anything to take here, sorry. You sent some patches with Request for Comments, which usually means, don't apply them, I just want people to look at them, so I don't apply them... If you want me to apply them, please resend without that. Also, I'd like to get Alan's ACK on these, as they touch the core HCD code. thanks, Alan's ack is already there. Just wanted to make sure you don't need anything else. greg k-h I'll resend in a bit. Thanks, Val. -- 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: [3.8-rc3 - 3.8-rc4 regression] Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used
On Tue, Nov 26, 2013 at 3:53 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Nov 26, 2013 at 1:29 PM, Josh Hunt joshhun...@gmail.com wrote:
Both ahci and sata_svw call ata_host_activate(), which call
ata_host_register() and async_schedule(async_port_probe, ap).
Well, with the modern logic (only wait for async probing if the
module itself did async probing) the ahci and svw modules didn't
really change any behavior.
But other modules did. I wonder, for example, if people insmod the dm
module, and expect all devices to exist afterwards. Which the old
logic of we always wait for all async code regardless of whether we
started it ourselves would do, but the new logic does not.
Something similar might hit the (non-modular) md auto-detect ioctl.
So maybe we should just special-case those two issues, and say let's
just wait for async requests here
Something like the appended (whitespace-damaged) diff. Does that make
a difference to you guys? And if it does, can you check *which* of the
two async_synchronize_full() calls it is that matters for your cases?
Linus
--- duh, apply by hand --
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 0704c523a76b..7e7a2f743b11 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -351,6 +351,7 @@ static int __init dm_init(void)
goto bad;
}
+ async_synchronize_full();
return 0;
bad:
diff --git a/drivers/md/md.c b/drivers/md/md.c
index b6b7a2866c9e..1d173dc662fc 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8602,6 +8602,7 @@ static void autostart_arrays(int part)
i_scanned = 0;
i_passed = 0;
+ async_synchronize_full();
printk(KERN_INFO md: Autodetecting RAID arrays.\n);
while (!list_empty(all_detected_devices) i_scanned INT_MAX)
{
I should have clarified that I'm not using dm/md in my setup. I know
the modules are getting loaded in the log I attached, but root is not
a md/dm device.
--
Josh
--
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 09/10] ARM: dts: omap3-beagle-xm: Add USB Host support
On Tue, Nov 26, 2013 at 3:04 PM, Tony Lindgren t...@atomide.com wrote: * Roger Quadros rog...@ti.com [131120 02:33]: Nishant, On 11/19/2013 11:05 PM, Nishanth Menon wrote: On 09/24/2013 03:53 AM, Roger Quadros wrote: Provide RESET GPIO and Power regulator for the USB PHY, the USB Host port mode and the PHY device for the controller. Also provide pin multiplexer information for USB host pins. We also relocate omap3_pmx_core pin definations so that they are close to omap3_pmx_wkup pin definations. Signed-off-by: Roger Quadros rog...@ti.com --- just using this thread, but a question - I am kernel * master dec8e46 Merge tag 'arc-v3.13-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc and I see that VAUX2 which supplies USB_1V8[1] is not enabled - I did a quick patch and it did seem to work (Usb keyboard, networking, mouse etc on my ehci ports seems to come up good) - any suggestions how we'd like to handle this? It worked for me without your patch. It could be that u-boot is enabling that regulator for me. I'm on u-boot-v2013.10. In any case, your patch seems the right thing to do. We should take it in the rc cycle. Can you guys post a proper fix for this? Meanwhile, I'll mark this thread as read to shrink my inbox a bit. already done: https://patchwork.kernel.org/patch/3231151/ -- 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] ARM: dts: omap3-beagle: Fix USB host on beagle boards (for 3.13)
* Roger Quadros rog...@ti.com [131126 00:57]: On 11/25/2013 05:50 PM, Nishanth Menon wrote: On Mon, Nov 25, 2013 at 7:55 AM, Roger Quadros rog...@ti.com wrote: Beagle (rev. C4) and Beagle-XM (all revs) need VAUX2 1.8V supply for the USB PHY. As the generic PHY driver can't handle more than one supply at the moment, we configure this supply to be always on. This will cause a very small power impact if the USB host subsystem is not in use, about 76.86 micro-W + LDO power. Older Beagle boards (prior to C4) don't have VAUX2 connected anywhere, so there won't be any functional impact on those boards other than some additional LDO power consumption. Reported-by: Nishanth Menon n...@ti.com Signed-off-by: Roger Quadros rog...@ti.com Tested-by: Nishanth Menon n...@ti.com Thanks Nishant. Thanks, applying this into omap-for-v3.13/fixes-take4. Tony -- 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: [3.8-rc3 - 3.8-rc4 regression] Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used
Hello, On Tue, Nov 26, 2013 at 04:12:41PM -0600, Josh Hunt wrote: I should have clarified that I'm not using dm/md in my setup. I know the modules are getting loaded in the log I attached, but root is not a md/dm device. Can you please still try it? The init script is broken and we're now just trying to restore just enough of the old behavior so that the issue is not exposed. The boot script in use seems to load md/dm modules after storage drivers and use their termination as the signal for storage ready, so it could be a good enough bandaid even if you're not using dm/md. Thanks. -- tejun -- 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: [3.8-rc3 - 3.8-rc4 regression] Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used
On Tue, Nov 26, 2013 at 2:12 PM, Josh Hunt joshhun...@gmail.com wrote: I should have clarified that I'm not using dm/md in my setup. I know the modules are getting loaded in the log I attached, but root is not a md/dm device. Hmm. The initcall debugging doesn't actually show any of the wait for async events, because those debug messages come from do_one_initcall(), and the waiting happens later. Plus your messages don't actually show where you are trying to - and failing - to mount the root filesystem. Without that kind of information, it's kind of hard to guess. Maybe you could add a few printk's to your kernel? Add one to do_init_module() *after* the if (current-flags PF_USED_ASYNC) async_synchronize_full(); thing, and another to fs/namespace.c: do_mount() (just put something like printk(do_mount: %s at %s\n, dev_name, dir_name); or whatever, so that we can see when that happens.. Linus -- 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
[V2 PATCH 0/2] Defer HCD init until the external PHY, bound to the HCD is ready
This adds remove_phy flag to the HCD structure. If the flag is set and if hcd-phy is valid, the phy is shutdown and released whenever usb_add_hcd fails or usb_hcd_remove is called. This also adds generic external phy support that allows the HCD driver to search for a USB phy, bound to the HCD, when the HC is being added. If the USB PHY is found, it is initialized and the remove_phy flag is set. In case PHY is not ready, the usb_add_hcd function returns the -EPROBE_DEFER error code which defers HCD probing till the PHY becomes ready. If no PHY is bound to the HCD, or it has been initialized by the glue-driver before calling usb_add_hcd(), the HCD is added as usual. This approach can be used to initialize the external PHY for the R-Car PCI USB hosts, that share USB ports with USBHS/USBSS devices. All we need to do is to make R-Car Gen2 platform code bind the Gen2 USB phy device to the PCI HC devices, and make the phy-rcar-gen2-usb driver register USB phy with usb_add_phy_dev() AOT usb_add_phy() callback. Changes from previous version: * Used #ifdef CONFIG_USB_PHY instead of introducing new config option. Valentine Barshak (2): usb: hcd: Remove USB phy if needed usb: hcd: Initialize USB phy if needed drivers/usb/core/hcd.c | 34 +- include/linux/usb/hcd.h | 1 + 2 files changed, 34 insertions(+), 1 deletion(-) -- 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: zte_ev not properly handling ZTE AC2726 CDMA modems
-Original Message- From: Johan Hovold [mailto:jhov...@gmail.com] Sent: Tuesday, November 26, 2013 6:39 AM To: Dmitry Kunilov Cc: linux-usb@vger.kernel.org Subject: Re: zte_ev not properly handling ZTE AC2726 CDMA modems On Mon, Nov 25, 2013 at 06:15:28PM -0800, Dmitry Kunilov wrote: Hi everyone, As a late follow-up to the discussion that happened in June about moving support for most ZTE CDMA devices from option.c to zte_ev.c (where the decision was to convert and see if anyone complains), I'd like to complain :) We have a park of approximately thirty ZTE AC2726 EVDO modems connected to Broadcom-based routers running Linux-mips. After recent upgrade from ancient 2.6.22 to relatively modern 3.9.11, all 30 are having the same problem: pppd connects and Internet access works for 20 to 60 seconds, then connectivity drops and pppd logs an LCP timeout. After that, pppd is able to restart the connection and run for another 20-60 seconds. I did notice that these modems are now handled by zte_ev instead of option, so I went and moved all the DEVICE_INFO's back from zte_ev.c to option.c and also disabled zte_ev module in the kernel configuration. After this change, the modems work just fine, like they did on 2.6.22 - using the option driver. Please let me know if there is any debug info I can collect to help resolve this issue. Would you mind trying the patch below (against v3.12)? Thanks, Johan On Tue, Nov 26, 2013 at 12:37:21PM -0800, Dmitry Kunilov wrote: Hi Jonah, Do you think this patch will work against 3.9.11? If not, I'll have to invest some time into upgrading to 3.12 which proved to be difficult given all the Broadcom-related modifications in the kernel.. Yes, the patch should work on 3.9 as well, although it might not apply cleanly. Try the patch below instead if your stuck with 3.9. Thanks, Johan The patch didn't fix the problem. I am attaching the output that I am getting in the syslog. Note that I have two usb modems connected to that router and that's how I am able to debug it. 2-1 is an external USB2.0 hub, 2-1.2 is the ZTE modem, and 2-1.1 is a Huawei CDMA modem, which is working fine. The problem happens both with and without a hub. Dmitry. Nov 26 22:31:28 iqvpn daemon.notice pppd[647]: local IP address 10.182.147.158 Nov 26 22:31:28 iqvpn daemon.notice pppd[647]: remote IP address 192.168.50.12 Nov 26 22:31:28 iqvpn daemon.notice pppd[647]: primary DNS address 213.55.96.148 Nov 26 22:31:28 iqvpn daemon.notice pppd[647]: secondary DNS address 213.55.96.166 Nov 26 22:31:58 iqvpn kern.debug kernel: usb 2-1: clear tt buffer port 1, a5 ep4 t10008d82 Nov 26 22:31:58 iqvpn kern.debug kernel: usb 2-1: clear tt buffer port 1, a5 ep6 t10008d80 Nov 26 22:31:59 iqvpn kern.debug kernel: usb 2-1: clear tt buffer port 1, a5 ep6 t10008d80 Nov 26 22:32:00 iqvpn kern.debug kernel: usb 2-1: clear tt buffer port 2, a6 ep4 t08008d82 Nov 26 22:32:00 iqvpn kern.warn kernel: zte_ev ttyUSB4: usb_serial_generic_read_bulk_callback - non-zero urb status: -2 Nov 26 22:32:00 iqvpn kern.warn kernel: zte_ev ttyUSB4: usb_serial_generic_read_bulk_callback - non-zero urb status: -2 Nov 26 22:32:01 iqvpn kern.debug kernel: usb 2-1: clear tt buffer port 1, a5 ep6 t90008d80 Nov 26 22:32:03 iqvpn kern.debug kernel: usb 2-1: clear tt buffer port 2, a6 ep4 t08008d82 Nov 26 22:32:03 iqvpn kern.warn kernel: zte_ev ttyUSB4: usb_serial_generic_read_bulk_callback - non-zero urb status: -2 Nov 26 22:32:03 iqvpn kern.warn kernel: zte_ev ttyUSB4: usb_serial_generic_read_bulk_callback - non-zero urb status: -2 Nov 26 22:32:17 iqvpn kern.debug kernel: usb 2-1: clear tt buffer port 1, a5 ep6 t90008d80 Nov 26 22:32:19 iqvpn kern.debug kernel: usb 2-1: clear tt buffer port 2, a6 ep4 t08008d82 Nov 26 22:32:19 iqvpn kern.warn kernel: zte_ev ttyUSB4: usb_serial_generic_read_bulk_callback - non-zero urb status: -2 Nov 26 22:32:19 iqvpn kern.warn kernel: zte_ev ttyUSB4: usb_serial_generic_read_bulk_callback - non-zero urb status: -2 Nov 26 22:32:31 iqvpn kern.warn kernel: zte_ev ttyUSB5: usb_serial_generic_write_bulk_callback - non-zero urb status: -2 Nov 26 22:32:31 iqvpn kern.debug kernel: usb 2-1: clear tt buffer port 2, a6 ep7 t00018c82 Nov 26 22:32:31 iqvpn kern.warn kernel: zte_ev ttyUSB5: usb_serial_generic_write_bulk_callback - non-zero urb status: -2 Nov 26 22:32:31 iqvpn kern.debug kernel: usb 2-1: clear tt buffer port 2, a6 ep7 t08008d82 Nov 26 22:32:31 iqvpn kern.warn kernel: zte_ev ttyUSB5: usb_serial_generic_read_bulk_callback - non-zero urb status: -2 Nov 26 22:32:31 iqvpn kern.warn kernel: zte_ev ttyUSB5: usb_serial_generic_read_bulk_callback - non-zero urb status: -2 Nov 26 22:32:33 iqvpn kern.debug kernel: usb 2-1: clear tt buffer port 2, a6 ep8 t08008d80 Nov 26 22:32:33 iqvpn kern.warn kernel: zte_ev ttyUSB6: usb_serial_generic_read_bulk_callback - non-zero urb status: -2 Nov 26 22:32:33 iqvpn kern.warn
[PATCH 1/2] usb: hcd: Remove USB phy if needed
This adds remove_phy flag to the HCD structure. If the flag is
set and if hcd-phy is valid, the phy is shutdown and released
whenever usb_add_hcd fails or usb_hcd_remove is called.
This can be used by the HCD drivers to auto-remove
the external USB phy when it is no longer needed.
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/core/hcd.c | 14 +-
include/linux/usb/hcd.h | 1 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 6bffb8c..7527c8e 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -44,6 +44,7 @@
#include linux/usb.h
#include linux/usb/hcd.h
+#include linux/usb/phy.h
#include usb.h
@@ -2603,7 +2604,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
*/
if ((retval = hcd_buffer_create(hcd)) != 0) {
dev_dbg(hcd-self.controller, pool alloc failed\n);
- return retval;
+ goto err_remove_phy;
}
if ((retval = usb_register_bus(hcd-self)) 0)
@@ -2734,6 +2735,12 @@ err_allocate_root_hub:
usb_deregister_bus(hcd-self);
err_register_bus:
hcd_buffer_destroy(hcd);
+err_remove_phy:
+ if (hcd-remove_phy hcd-phy) {
+ usb_phy_shutdown(hcd-phy);
+ usb_put_phy(hcd-phy);
+ hcd-phy = NULL;
+ }
return retval;
}
EXPORT_SYMBOL_GPL(usb_add_hcd);
@@ -2806,6 +2813,11 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_put_dev(hcd-self.root_hub);
usb_deregister_bus(hcd-self);
hcd_buffer_destroy(hcd);
+ if (hcd-remove_phy hcd-phy) {
+ usb_phy_shutdown(hcd-phy);
+ usb_put_phy(hcd-phy);
+ hcd-phy = NULL;
+ }
}
EXPORT_SYMBOL_GPL(usb_remove_hcd);
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index b8aba19..758ce80 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -134,6 +134,7 @@ struct usb_hcd {
unsignedrh_registered:1;/* is root hub registered? */
unsignedrh_pollable:1; /* may we poll the root hub? */
unsignedmsix_enabled:1; /* driver has MSI-X enabled? */
+ unsignedremove_phy:1; /* auto-remove USB phy */
/* The next flag is a stopgap, to be removed when all the HCDs
* support the new root-hub polling mechanism. */
--
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
[PATCH 2/2] usb: hcd: Initialize USB phy if needed
This adds external USB phy support to USB HCD driver that
allows to find and initialize external USB phy, bound to
the HCD, when the HCD is added.
The usb_add_hcd function returns -EPROBE_DEFER if the USB
phy, bound to the HCD, is not ready.
If no USB phy is bound, the HCD is initialized as usual.
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/core/hcd.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 7527c8e..649506b 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2589,6 +2589,26 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
+#ifdef CONFIG_USB_PHY
+ if (!hcd-phy) {
+ struct usb_phy *phy = usb_get_phy_dev(hcd-self.controller, 0);
+
+ if (IS_ERR(phy)) {
+ retval = PTR_ERR(phy);
+ if (retval == -EPROBE_DEFER)
+ return retval;
+ } else {
+ retval = usb_phy_init(phy);
+ if (retval) {
+ usb_put_phy(phy);
+ return retval;
+ }
+ hcd-phy = phy;
+ hcd-remove_phy = 1;
+ }
+ }
+#endif
+
dev_info(hcd-self.controller, %s\n, hcd-product_desc);
/* Keep old behaviour if authorized_default is not in [0, 1]. */
--
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: [PATCH v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks
On 26 November 2013 22:09, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 26 Nov 2013, Rafael J. Wysocki wrote: On Tuesday, November 26, 2013 10:48:56 AM Ulf Hansson wrote: On 26 November 2013 00:10, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, November 25, 2013 01:40:21 PM Ulf Hansson wrote: To put devices into low power state during sleep, it sometimes makes sense at subsystem-level to re-use device's runtime PM callbacks. Ulf, please be more careful about the distinction between device and driver. Devices don't have callbacks; drivers do. You made this mistake a few times in the patch description. Sorry, my bad. The PM core will at device_suspend_late disable runtime PM, after that we can safely operate on these callbacks. At suspend_late the device will be put into low power state by invoking the device's runtime_suspend callback, unless the runtime status is already suspended. At resume_early the state is restored by invoking the device's runtime_resume callback. Soon after the PM core will re-enable runtime PM before returning from device_resume_early. The new pm_generic functions are named pm_generic_suspend_late_runtime and pm_generic_resume_early_runtime, they are supposed to be used in pairs. What happens if the subsystem uses the new functions as its late suspend/ early resume callbacks, but some of its drivers implement .suspend_late() and .resume_early()? The same thing that happens whenever any PM-related callback is defined by both the subsystem and the driver: The PM core uses the subsystem's callback. (Or the pm_domain's callback, or the type's callback, or the class's callback.) Besides, Ulf specifically assumed at the top of this message that re-using the runtime-suspend callback makes sense at the subsystem level. This must mean it is appropriate for all drivers in the subsystem. So why would a driver want to override the subsystem's behavior? Good point. Normally, I think the decision of using these callbacks should be taken at the lowest level, in other words in the driver. Otherwise the lowest layer of .suspend_late will be by-passed. I'm not sure what's the point to add them, then. If the driver has to decide anyway, it may simply populate its .suspend_late and .resume_early pointers I think. Another possibility is to have the pm_generic_suspend_late_runtime routine check to see if the driver has defined a suspend_late callback. If the driver has its own callback, we could invoke it instead of invoking the runtime_suspend callback. There are already a generic callbacks that does this. Normally the generic callbacks is used from buses and power domains. My new callbacks are intended to be used from the driver, so those are kind of different from the others in that sense. However, I'm not sure that doing this would be worthwhile. And it would hang in an infinite loop if the driver set its suspend_late pointer to pm_generic_suspend_late_runtime! :-) Alan Stern Kind regards Ulf Hansson -- 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] PM / Runtime: Implement the pm_generic_runtime functions for CONFIG_PM
The pm_generic_runtime_suspend|resume functions were implemented within
CONFIG_PM_RUNTIME.
As we also may use runtime PM callbacks during system suspend, to put
devices into low power state, we need to move the implementation of
pm_generic_runtime_suspend|resume to CONFIG_PM.
This change prevents the platform bus from by-passing driver's runtime
PM callbacks while only CONFIG_PM_SLEEP and not CONFIG_PM_RUNTIME is
being used.
Cc: Kevin Hilman khil...@linaro.org
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/base/power/generic_ops.c |4 ++--
include/linux/pm_runtime.h | 12
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/base/power/generic_ops.c b/drivers/base/power/generic_ops.c
index 5ee030a..a2e55bf 100644
--- a/drivers/base/power/generic_ops.c
+++ b/drivers/base/power/generic_ops.c
@@ -10,7 +10,7 @@
#include linux/pm_runtime.h
#include linux/export.h
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
/**
* pm_generic_runtime_suspend - Generic runtime suspend callback for
subsystems.
* @dev: Device to suspend.
@@ -48,7 +48,7 @@ int pm_generic_runtime_resume(struct device *dev)
return ret;
}
EXPORT_SYMBOL_GPL(pm_generic_runtime_resume);
-#endif /* CONFIG_PM_RUNTIME */
+#endif /* CONFIG_PM */
#ifdef CONFIG_PM_SLEEP
/**
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index 6fa7cea..16c9a62 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -23,6 +23,14 @@
usage_count */
#define RPM_AUTO 0x08/* Use autosuspend_delay */
+#ifdef CONFIG_PM
+extern int pm_generic_runtime_suspend(struct device *dev);
+extern int pm_generic_runtime_resume(struct device *dev);
+#else
+static inline int pm_generic_runtime_suspend(struct device *dev) { return 0; }
+static inline int pm_generic_runtime_resume(struct device *dev) { return 0; }
+#endif
+
#ifdef CONFIG_PM_RUNTIME
extern struct workqueue_struct *pm_wq;
@@ -37,8 +45,6 @@ extern void pm_runtime_enable(struct device *dev);
extern void __pm_runtime_disable(struct device *dev, bool check_resume);
extern void pm_runtime_allow(struct device *dev);
extern void pm_runtime_forbid(struct device *dev);
-extern int pm_generic_runtime_suspend(struct device *dev);
-extern int pm_generic_runtime_resume(struct device *dev);
extern void pm_runtime_no_callbacks(struct device *dev);
extern void pm_runtime_irq_safe(struct device *dev);
extern void __pm_runtime_use_autosuspend(struct device *dev, bool use);
@@ -142,8 +148,6 @@ static inline bool pm_runtime_active(struct device *dev) {
return true; }
static inline bool pm_runtime_status_suspended(struct device *dev) { return
false; }
static inline bool pm_runtime_enabled(struct device *dev) { return false; }
-static inline int pm_generic_runtime_suspend(struct device *dev) { return 0; }
-static inline int pm_generic_runtime_resume(struct device *dev) { return 0; }
static inline void pm_runtime_no_callbacks(struct device *dev) {}
static inline void pm_runtime_irq_safe(struct device *dev) {}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks
On Tuesday, November 26, 2013 04:09:44 PM Alan Stern wrote: On Tue, 26 Nov 2013, Rafael J. Wysocki wrote: On Tuesday, November 26, 2013 10:48:56 AM Ulf Hansson wrote: On 26 November 2013 00:10, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, November 25, 2013 01:40:21 PM Ulf Hansson wrote: To put devices into low power state during sleep, it sometimes makes sense at subsystem-level to re-use device's runtime PM callbacks. Ulf, please be more careful about the distinction between device and driver. Devices don't have callbacks; drivers do. You made this mistake a few times in the patch description. The PM core will at device_suspend_late disable runtime PM, after that we can safely operate on these callbacks. At suspend_late the device will be put into low power state by invoking the device's runtime_suspend callback, unless the runtime status is already suspended. At resume_early the state is restored by invoking the device's runtime_resume callback. Soon after the PM core will re-enable runtime PM before returning from device_resume_early. The new pm_generic functions are named pm_generic_suspend_late_runtime and pm_generic_resume_early_runtime, they are supposed to be used in pairs. What happens if the subsystem uses the new functions as its late suspend/ early resume callbacks, but some of its drivers implement .suspend_late() and .resume_early()? The same thing that happens whenever any PM-related callback is defined by both the subsystem and the driver: The PM core uses the subsystem's callback. (Or the pm_domain's callback, or the type's callback, or the class's callback.) Precisely. But my question was more about how we are going to indicate it to the driver writers (who may not be familiar with that subsystem to start with and may have experience with some other subsystems that don't use these new functions) that they are not supposed to populate .suspend_late and .resume_early. Besides, Ulf specifically assumed at the top of this message that re-using the runtime-suspend callback makes sense at the subsystem level. This must mean it is appropriate for all drivers in the subsystem. So why would a driver want to override the subsystem's behavior? By mistake? Good point. Normally, I think the decision of using these callbacks should be taken at the lowest level, in other words in the driver. Otherwise the lowest layer of .suspend_late will be by-passed. I'm not sure what's the point to add them, then. If the driver has to decide anyway, it may simply populate its .suspend_late and .resume_early pointers I think. Another possibility is to have the pm_generic_suspend_late_runtime routine check to see if the driver has defined a suspend_late callback. If the driver has its own callback, we could invoke it instead of invoking the runtime_suspend callback. However, I'm not sure that doing this would be worthwhile. And it would hang in an infinite loop if the driver set its suspend_late pointer to pm_generic_suspend_late_runtime! Well, that's supposed to be a subsystem-level callback. Anyway, my personal opinion is that we seem to be adding confusion instead of reducing it here ... Rafael -- 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] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks
On Wednesday, November 27, 2013 12:44:35 AM Ulf Hansson wrote: On 26 November 2013 22:09, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 26 Nov 2013, Rafael J. Wysocki wrote: On Tuesday, November 26, 2013 10:48:56 AM Ulf Hansson wrote: On 26 November 2013 00:10, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, November 25, 2013 01:40:21 PM Ulf Hansson wrote: To put devices into low power state during sleep, it sometimes makes sense at subsystem-level to re-use device's runtime PM callbacks. Ulf, please be more careful about the distinction between device and driver. Devices don't have callbacks; drivers do. You made this mistake a few times in the patch description. Sorry, my bad. The PM core will at device_suspend_late disable runtime PM, after that we can safely operate on these callbacks. At suspend_late the device will be put into low power state by invoking the device's runtime_suspend callback, unless the runtime status is already suspended. At resume_early the state is restored by invoking the device's runtime_resume callback. Soon after the PM core will re-enable runtime PM before returning from device_resume_early. The new pm_generic functions are named pm_generic_suspend_late_runtime and pm_generic_resume_early_runtime, they are supposed to be used in pairs. What happens if the subsystem uses the new functions as its late suspend/ early resume callbacks, but some of its drivers implement .suspend_late() and .resume_early()? The same thing that happens whenever any PM-related callback is defined by both the subsystem and the driver: The PM core uses the subsystem's callback. (Or the pm_domain's callback, or the type's callback, or the class's callback.) Besides, Ulf specifically assumed at the top of this message that re-using the runtime-suspend callback makes sense at the subsystem level. This must mean it is appropriate for all drivers in the subsystem. So why would a driver want to override the subsystem's behavior? Good point. Normally, I think the decision of using these callbacks should be taken at the lowest level, in other words in the driver. Otherwise the lowest layer of .suspend_late will be by-passed. I'm not sure what's the point to add them, then. If the driver has to decide anyway, it may simply populate its .suspend_late and .resume_early pointers I think. Another possibility is to have the pm_generic_suspend_late_runtime routine check to see if the driver has defined a suspend_late callback. If the driver has its own callback, we could invoke it instead of invoking the runtime_suspend callback. There are already a generic callbacks that does this. Normally the generic callbacks is used from buses and power domains. My new callbacks are intended to be used from the driver, so those are kind of different from the others in that sense. Hmm. I see. For that to work, the subsystem's .suspend() and .resume() callbacks will have to be implemented in a special way, because of the unknown runtime PM status of devices while those callbacks are being executed. Presumably you think about subsystems that don't implement those callbacks at all? Rafael -- 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
