Re: [PATCH v10 00/11] Add USB OTG HNP and SRP support on Chipidea usb driver
On Tue, Apr 15, 2014 at 02:48:44PM +0800, Peter Chen wrote:
On Tue, Apr 15, 2014 at 09:43:04AM +0800, Li Jun wrote:
On Mon, Apr 14, 2014 at 08:45:13PM +0800, Peter Chen wrote:
On Mon, Apr 14, 2014 at 10:22:32AM +0800, Li Jun wrote:
On Mon, Apr 14, 2014 at 09:37:50AM +0800, Li Jun wrote:
From: Li Jun b47...@freescale.com
This patchset adds USB OTG HNP and SRP support on chipidea usb driver,
existing OTG port role swtich function by ID pin status kept
unchanged,
based on that, if select CONFIG_USB_OTG_FSM, OTG HNP and SRP will be
supported.
Reference to:
On-The-Go and Embedded Host Supplement to the USB Revision 2.0
Specification July 27, 2012
Revision 2.0 version 1.1a
Changes since v9:
- Move xxx_fsm_start to be after request irq since xxx_fsm_work need
call to
disable_irq_nosync(ci-irq).
Then, the interrupt will be on during the host initialization, it may
have unexpected interrupt.
Maybe for some devices which need not vbus from host, the enum will start
when
host init. one possible solution is split the current fsm_start into 2
parts,
the first part is put into fsm_init(thus before request_irq), the 2nd part
is
put into fsm_start, any idea? if no objection, I can go in this way.
Try to defer ci_otg_fsm_work using queue_work, and disable irq before
it.
Can work in this way, I will change.
- Add fsm handling in xxx_fsm_work for regsiter gadget driver with
vbus on, instead
of rely on B_SE0_SRP timer(which is not directly linked to this
case and need wait
1s).
The B_SE0_SRP timer still will queue otg fsm work or not? If it is, any
side effects?
yes, still queue otg fsm work, but no side effects, as B-device is already
queue
one fsm work before B_SE0_SRP timer time out, then the later one will just
try to
change state but do nothing.
Get it.
- Add comments on a_idle to a_wait_vrise due to ID change, which is
out of OTG spec
but make sense for user experience.
- Remove blank line introduced in v9.
Sorry, missed one update in v10 changes summary:
- Clear ID interrupt status before enable ID irq in ci_hdrc_probe().
At ci_get_otg_capable, it will clear all otg interrupt status.
I do still find there is one ID change irq pending there when power up with
ID is low.
if I need rework the fsm start and put host init before request irq, this
problem
will not exist.
Try to find the root cause for it please, we can't accept the code which
still not find the root cause.
After more check on this,
- The default state of ID is 1
- It's too early to clear ID change irq stats in current sequence, my simple log
information shows the ID is still in default state(1) when clear and disable
OTG irq in ci_get_otg_capable().
- There is already safe check of ID status by 2ms delay in current code:
...
if (ci-is_otg) {
/*
* ID pin needs 1ms debouce time,
* we delay 2ms for safe.
*/
mdelay(2);
ci-role = ci_otg_role(ci);
...
After this delay, ID state becomes correct(0) and real ID change should
already happened, so I think this is the right place to clear this unexpected
ID interrupt.
Li Jun
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb/serial/ch341: Add parity support
On Tue, Apr 15, 2014 at 11:26:52PM +, Karl P wrote: On 04/15/2014 05:34 PM, Johan Hovold wrote: On Tue, Apr 15, 2014 at 04:06:11PM +0200, Johan Hovold wrote: Specifically, I asked if you are able to make sense of the values of register 0x2518. The reason I ask is that your patch changes the value of that register from 0x50 (set in ch341_configure) to 0xc3 (when no parity is used) and I want to make sure that you're not inadvertently changing some other setting. You're right, I realised I'd forgotten some of your other comments earlier, but wasn't back to a computer to update, my apologies. No problem. Do you know what those other bits do? Do they encode the number of data and stop bits? From a quick glance it seems like 0xc0parity mode (2 bits) 0x08parity enable but your patch now also sets bits 0x83 and clears bit 0x10. That should have been: 0x30parity mode (2 bits) 0x08parity enable and your patch now always sets bits 0x83. No, I have no idea what these bits mean. We can go and look at FreeBSD's code and make assumptions about whether their decode is any more correct or not. (They break things into parts and declare 8bit registers, that must be set two at a time) As I mentioned, this was based on wireshark tracing of windows programs opening the serial port, and without any better documentation, it's all I've got to go on. Without better documentation, how do we even know that what _was_ being done was any more or less correct than what it will be doing now? All I can say is that 8-n-1 works as it did before, and 8-e-1, 8-o-1 and 8-m-1/8-s-1 now actually work at all. The register appears to be a standard 8-bit (8250, 16450, 16550) UART Line Control Register (LCR): * Bit 7: Divisor Latch Access Bit (DLAB). When set, access to the data * transmit/receive register (THR/RBR) and the Interrupt Enable Register * (IER) is disabled. Any access to these ports is now redirected to the * Divisor Latch Registers. Setting this bit, loading the Divisor * Registers, and clearing DLAB should be done with interrupts disabled. * Bit 6: Set Break. When set to 1, the transmitter begins to transmit * continuous Spacing until this bit is set to 0. This overrides any * bits of characters that are being transmitted. * Bit 5: Stick Parity. When parity is enabled, setting this bit causes parity * to always be 1 or 0, based on the value of Bit 4. * Bit 4: Even Parity Select (EPS). When parity is enabled and Bit 5 is 0, * setting this bit causes even parity to be transmitted and expected. * Otherwise, odd parity is used. * Bit 3: Parity Enable (PEN). When set to 1, a parity bit is inserted * between the last bit of the data and the Stop Bit. The UART will also * expect parity to be present in the received data. * Bit 2: Number of Stop Bits (STB). If set to 1 and using 5-bit data words, * 1.5 Stop Bits are transmitted and expected in each data word. For * 6, 7 and 8-bit data words, 2 Stop Bits are transmitted and expected. * When this bit is set to 0, one Stop Bit is used on each data word. * Bit 1: Word Length Select Bit #1 (WLSB1) * Bit 0: Word Length Select Bit #0 (WLSB0) * Together these bits specify the number of bits in each data word. * 1 0 Word Length * 0 0 5 Data Bits * 0 1 6 Data Bits * 1 0 7 Data Bits * 1 1 8 Data Bits This is an excerpt from drivers/usb/serial/mct_u232.h but the definition is standard. Maybe it's setting data bits to 8? (the ch340 doesn't support variable data bits, the ch341 does) Data bit support / stop bit support is still not supported by this driver anyway, I believe that's a project for another day. Yes, that guess seems correct. But this would mean that the driver is currently unusable with ch341 devices (unless you actually want 5 data bits)? And then your patch isn't just adding parity support. So, the only things that looks odd about your patch is that it sets bit 7 (which is possibly not even used) and that the driver has always been setting bit 6... Your other comment was about using the #define for 0x9a labelled write register I can if you would like, but that would make some of the code use the define others not. Unless you want me to redo the _rest_ of existing code to use this define. Further, while write register _seems_ like a believable interpretation of the magic number, unless someone has some better documentation, it's just an educated guess._Only_ the break support code, which came from FreeBSD even attempts to make up/assign names to some of these magic numbers. I'm happy to go and do this, (replacing magic numbers with the recently added #defines) but I had endeavoured to follow the style of the
RE: [PATCH v10 00/11] Add USB OTG HNP and SRP support on Chipidea usb driver
On Tue, Apr 15, 2014 at 02:48:44PM +0800, Peter Chen wrote:
On Tue, Apr 15, 2014 at 09:43:04AM +0800, Li Jun wrote:
On Mon, Apr 14, 2014 at 08:45:13PM +0800, Peter Chen wrote:
On Mon, Apr 14, 2014 at 10:22:32AM +0800, Li Jun wrote:
On Mon, Apr 14, 2014 at 09:37:50AM +0800, Li Jun wrote:
From: Li Jun b47...@freescale.com
This patchset adds USB OTG HNP and SRP support on chipidea usb
driver, existing OTG port role swtich function by ID pin
status kept unchanged, based on that, if select
CONFIG_USB_OTG_FSM, OTG HNP and SRP will be supported.
Reference to:
On-The-Go and Embedded Host Supplement to the USB Revision
2.0 Specification July 27, 2012 Revision 2.0 version 1.1a
Changes since v9:
- Move xxx_fsm_start to be after request irq since xxx_fsm_work
need call to
disable_irq_nosync(ci-irq).
Then, the interrupt will be on during the host initialization, it
may have unexpected interrupt.
Maybe for some devices which need not vbus from host, the enum will
start when host init. one possible solution is split the current
fsm_start into 2 parts, the first part is put into fsm_init(thus
before request_irq), the 2nd part is put into fsm_start, any idea? if
no objection, I can go in this way.
Try to defer ci_otg_fsm_work using queue_work, and disable irq before
it.
Can work in this way, I will change.
- Add fsm handling in xxx_fsm_work for regsiter gadget driver
with vbus on, instead
of rely on B_SE0_SRP timer(which is not directly linked to
this case and need wait
1s).
The B_SE0_SRP timer still will queue otg fsm work or not? If it
is, any side effects?
yes, still queue otg fsm work, but no side effects, as B-device is
already queue one fsm work before B_SE0_SRP timer time out, then the
later one will just try to change state but do nothing.
Get it.
- Add comments on a_idle to a_wait_vrise due to ID change,
which is out of OTG spec
but make sense for user experience.
- Remove blank line introduced in v9.
Sorry, missed one update in v10 changes summary:
- Clear ID interrupt status before enable ID irq in
ci_hdrc_probe().
At ci_get_otg_capable, it will clear all otg interrupt status.
I do still find there is one ID change irq pending there when power
up with ID is low.
if I need rework the fsm start and put host init before request irq,
this problem will not exist.
Try to find the root cause for it please, we can't accept the code
which still not find the root cause.
After more check on this,
- The default state of ID is 1
- It's too early to clear ID change irq stats in current sequence, my
simple log
information shows the ID is still in default state(1) when clear and
disable
OTG irq in ci_get_otg_capable().
- There is already safe check of ID status by 2ms delay in current code:
...
if (ci-is_otg) {
/*
* ID pin needs 1ms debouce time,
* we delay 2ms for safe.
*/
mdelay(2);
ci-role = ci_otg_role(ci);
...
I think I know the reason why you see this problem, your PHY is in low power
mode
during the initialization, so after PHY's initialization has finished, we need
to
delay 2ms for controller to reflect phy's status, and delay at
ci_hdrc_enter_lpm are too much,
Please omit this ID status clear change in your patch, I will submit a patch to
fix it soon.
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
[PATCH] uwb: adds missing error handling
There is checking NULL before dereferncing but
it need to add return.
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
drivers/uwb/drp.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/uwb/drp.c b/drivers/uwb/drp.c
index 16ada83..1a2fd97 100644
--- a/drivers/uwb/drp.c
+++ b/drivers/uwb/drp.c
@@ -599,8 +599,11 @@ static void uwb_drp_handle_alien_drp(struct uwb_rc *rc,
struct uwb_ie_drp *drp_i
/* alloc and initialize new uwb_cnflt_alien */
cnflt = kzalloc(sizeof(struct uwb_cnflt_alien), GFP_KERNEL);
- if (!cnflt)
+ if (!cnflt) {
dev_err(dev, failed to alloc uwb_cnflt_alien struct\n);
+ return;
+ }
+
INIT_LIST_HEAD(cnflt-rc_node);
init_timer(cnflt-timer);
cnflt-timer.function = uwb_cnflt_timer;
--
1.7.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][next] phy: core: make NULL a valid phy reference if !CONFIG_GENERIC_PHY
Hi,
On Thursday 13 March 2014 07:07 PM, Santosh Shilimkar wrote:
On Thursday 13 March 2014 07:11 PM, Strashko, Grygorii wrote:
This fixes a regression on Keystone 2 platforms caused by patch
57303488cd37da58263e842de134dc65f7c626d5
usb: dwc3: adapt dwc3 core to use Generic PHY Framework which adds
optional support of generic phy in DWC3 core.
On Keystone 2 platforms the USB is not working now because
CONFIG_GENERIC_PHY isn't set and, as result, Generic PHY APIs stubs
return -ENOSYS always. The log shows:
dwc3 269.dwc3: failed to initialize core
dwc3: probe of 269.dwc3 failed with error -38
Hence, fix it by making NULL a valid phy reference in Generic PHY
APIs stubs in the same way as it was done by the patch
04c2facad8fee66c981a51852806d8923336f362 drivers: phy: Make NULL
a valid phy reference.
CC: Kishon Vijay Abraham I kis...@ti.com
CC: Felipe Balbi ba...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
This fixes the regression seen in Linux next and patch seems
reasonable to me.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Felipe, Kishon,
Can you guys pick this fix if you are ok by it. Thanks
include/linux/phy/phy.h |8
1 file changed, 8 insertions(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e2f5ca9..5a9b193 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -204,21 +204,29 @@ static inline void phy_pm_runtime_forbid(struct phy
*phy)
static inline int phy_init(struct phy *phy)
{
+if (!phy)
+return 0;
return -ENOSYS;
}
static inline int phy_exit(struct phy *phy)
{
+if (!phy)
+return 0;
return -ENOSYS;
}
static inline int phy_power_on(struct phy *phy)
{
+if (!phy)
+return 0;
return -ENOSYS;
}
static inline int phy_power_off(struct phy *phy)
{
+if (!phy)
+return 0;
return -ENOSYS;
}
Can you add these checks for other stubs in phy.h too?
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: Fwd: Isochronos audio
On 9 April 2014 19:53, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 9 Apr 2014, Clemens Ladisch wrote: Alan Stern wrote: The IN transfer was 1 frame long and scheduled for frame 1123, so its completion indicates that the current frame number is = 1123. The OUT transfer was 6 frames long and scheduled for frame , so it should have completed in frame 1117. But the timestamps show that the two URBs completed at the same time (only 13 us between them). Furthermore, I clearly recall Sarah Sharp (the original maintainer for xhci-hcd) saying that the support for isochronous transfers needed attention. This may well be an example. Alan Stern Hi, Is there any progress on this or is it low priority? BR Russel -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] usb: gadget: Add xilinx axi usb2 device support
Hi Felipe,
On Thu, Apr 3, 2014 at 8:28 PM, Felipe Balbi ba...@ti.com wrote:
+static int start_dma(struct xusb_ep *ep, u32 src, u32 dst, u32 length)
please prepend this with xudc_, it makes tracing a lot easier.
+{
+ struct xusb_udc *udc;
+ int rc = 0;
+ unsigned long timeout;
+
+ udc = ep-udc;
+ /*
+ * Set the addresses in the DMA source and
+ * destination registers and then set the length
+ * into the DMA length register.
+ */
+ udc-write_fn(udc-base_address, XUSB_DMA_DSAR_ADDR_OFFSET, src);
+ udc-write_fn(udc-base_address, XUSB_DMA_DDAR_ADDR_OFFSET, dst);
+ udc-write_fn(udc-base_address, XUSB_DMA_LENGTH_OFFSET, length);
+
+ /*
+ * Wait till DMA transaction is complete and
+ * check whether the DMA transaction was
+ * successful.
+ */
+ while ((udc-read_fn(ep-udc-base_address + XUSB_DMA_STATUS_OFFSET)
+ XUSB_DMA_DMASR_BUSY) == XUSB_DMA_DMASR_BUSY) {
+ timeout = jiffies + 1;
+
+ if (time_after(jiffies, timeout)) {
+ rc = -ETIMEDOUT;
+ goto clean;
+ }
+ }
don't you get an IRQ for DMA completion ? If you do, you could be using
wait_for_completion()
This function is called in interrupt context when buffer is ready or
free. It initiates
DMA to transfer data from IP buffer to memory. Hence it waits in busy
loop till DMA
completes
Thanks,
Sundeep.B.S.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb/serial/ch341: Add parity support
On Wed, Apr 16, 2014 at 10:17:29AM +0200, Johan Hovold wrote: This is an excerpt from drivers/usb/serial/mct_u232.h but the definition is standard. Maybe it's setting data bits to 8? (the ch340 doesn't support variable data bits, the ch341 does) Data bit support / stop bit support is still not supported by this driver anyway, I believe that's a project for another day. Yes, that guess seems correct. But this would mean that the driver is currently unusable with ch341 devices (unless you actually want 5 data bits)? And then your patch isn't just adding parity support. So, the only things that looks odd about your patch is that it sets bit 7 (which is possibly not even used) and that the driver has always been setting bit 6... Thanks for the interesting LCR info, I've never looked at those old devices anywhere closely enough, so it didn't have any meaning to me. (And hopefully it's not just coincidental for some pieces) Your other comment was about using the #define for 0x9a labelled write register I can if you would like, but that would make some of the code use the define others not. Unless you want me to redo the _rest_ of existing code to use this define. Further, while write register _seems_ like a believable interpretation of the magic number, unless someone has some better documentation, it's just an educated guess._Only_ the break support code, which came from FreeBSD even attempts to make up/assign names to some of these magic numbers. I'm happy to go and do this, (replacing magic numbers with the recently added #defines) but I had endeavoured to follow the style of the existing code. Fair enough. I don't mind keeping some of those magic constants for now, but I think we should at least assume that we're dealing with a fairly standard LCR register and use appropriate names and defines for that bit that you patch is changing. That is, something like: u8 lcr; and #define UART_LCR_DLAB 0x80 /* Divisor latch access bit (?) */ #define UART_LCR_SBC0x40 /* Set break control (?) */ #define UART_LCR_SPAR 0x20 /* Stick parity */ #define UART_LCR_EPAR 0x10 /* Even parity select */ #define UART_LCR_PARITY 0x08 /* Parity Enable */ #define UART_LCR_STOP 0x04 /* Stop bits: 0=1 bit, 1=2 bits */ #define UART_LCR_WLEN5 0x00 /* Wordlength: 5 bits */ #define UART_LCR_WLEN6 0x01 /* Wordlength: 6 bits */ #define UART_LCR_WLEN7 0x02 /* Wordlength: 7 bits */ #define UART_LCR_WLEN8 0x03 /* Wordlength: 8 bits */ Could you redo your patch using those defines? It's up to you if you want to implement stop and data bit support at once or do that as a follow-up patch (but please still use UART_LCR_WLEN8 if you choose to keep the data bits hard-coded). Yes, I can do that, but I don't have any good devices handy to test variable databits. I can maybe test out variable stop bit, I think I have some hardware for that, but parity is my primary (really, only) concern. Are those already defined somewhere else, or are you proposing (re) defining them again in this driver? Could you also see if everything appears to be working even if you leave DLAB and SBC unset? Yeah, I kinda took that as required testing :) Do you have access to both ch340 and ch341 devices in order to verify that both types keep working? This is also why I don't want to go too far with trying to test stop bits and data bits. I have a CH340, which doesn't support variable stop/data bits, and another device with the chip labels scratched off, that could be either. This is going to take a while longer to redo unfortunately. Sincerely, Karl Palsson -- 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: Fwd: Isochronos audio
On 04/16/2014 01:17 PM, Russel Hughes wrote: On 9 April 2014 19:53, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 9 Apr 2014, Clemens Ladisch wrote: Alan Stern wrote: The IN transfer was 1 frame long and scheduled for frame 1123, so its completion indicates that the current frame number is = 1123. The OUT transfer was 6 frames long and scheduled for frame , so it should have completed in frame 1117. But the timestamps show that the two URBs completed at the same time (only 13 us between them). Furthermore, I clearly recall Sarah Sharp (the original maintainer for xhci-hcd) saying that the support for isochronous transfers needed attention. This may well be an example. Alan Stern Hi, Is there any progress on this or is it low priority? I'll add checking the xhci side of this to my TODO list, (which starts to be quite long already). Might take some before I get to it. -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] phy: core: make NULL a valid phy reference if !CONFIG_GENERIC_PHY
This fixes a regression on Keystone 2 platforms caused by patch
57303488cd37da58263e842de134dc65f7c626d5
usb: dwc3: adapt dwc3 core to use Generic PHY Framework which adds
optional support of generic phy in DWC3 core.
On Keystone 2 platforms the USB is not working now because
CONFIG_GENERIC_PHY isn't set and, as result, Generic PHY APIs stubs
return -ENOSYS always. The log shows:
dwc3 269.dwc3: failed to initialize core
dwc3: probe of 269.dwc3 failed with error -38
Hence, fix it by making NULL a valid phy reference in Generic PHY
APIs stubs in the same way as it was done by the patch
04c2facad8fee66c981a51852806d8923336f362 drivers: phy: Make NULL
a valid phy reference.
CC: Kishon Vijay Abraham I kis...@ti.com
CC: Felipe Balbi ba...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
This fixes for regression in 3.15-rc1 - USB doesn't work on Keystone 2
Changes in v2:
- the same check added at stubs
phy_pm_runtime_get(struct phy *phy)
phy_pm_runtime_get_sync(struct phy *phy)
phy_pm_runtime_put(struct phy *phy)
phy_pm_runtime_put_sync(struct phy *phy)
include/linux/phy/phy.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e2f5ca9..2760744 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -174,21 +174,29 @@ void devm_of_phy_provider_unregister(struct device *dev,
#else
static inline int phy_pm_runtime_get(struct phy *phy)
{
+ if (!phy)
+ return 0;
return -ENOSYS;
}
static inline int phy_pm_runtime_get_sync(struct phy *phy)
{
+ if (!phy)
+ return 0;
return -ENOSYS;
}
static inline int phy_pm_runtime_put(struct phy *phy)
{
+ if (!phy)
+ return 0;
return -ENOSYS;
}
static inline int phy_pm_runtime_put_sync(struct phy *phy)
{
+ if (!phy)
+ return 0;
return -ENOSYS;
}
@@ -204,21 +212,29 @@ static inline void phy_pm_runtime_forbid(struct phy *phy)
static inline int phy_init(struct phy *phy)
{
+ if (!phy)
+ return 0;
return -ENOSYS;
}
static inline int phy_exit(struct phy *phy)
{
+ if (!phy)
+ return 0;
return -ENOSYS;
}
static inline int phy_power_on(struct phy *phy)
{
+ if (!phy)
+ return 0;
return -ENOSYS;
}
static inline int phy_power_off(struct phy *phy)
{
+ if (!phy)
+ return 0;
return -ENOSYS;
}
--
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] uvc: update uvc_endpoint_max_bpi to handle USB_SPEED_WIRELESS devices
Hi Thomas, (CC'ing the linux-usb mailing list) On Tuesday 15 April 2014 16:45:28 Thomas Pugliese wrote: On Tue, 15 Apr 2014, Laurent Pinchart wrote: Hi Thomas, Could you please send me a proper revert patch with the above description in the commit message and CC Mauro Carvalho Chehab m.che...@samsung.com ? Hi Laurent, I can submit a patch to revert but I should make a correction first. I had backported this change to an earlier kernel (2.6.39) which was before super speed support was added and the regression I described was based on that kernel. It was actually the addition of super speed support that broke windows compatible devices. My previous change fixed spec compliant devices but left windows compatible devices broken. Basically, the timeline of changes is this: 1. Prior to the addition of super speed support (commit 6fd90db8df379e215): all WUSB devices were treated as HIGH_SPEED devices. This is how Windows works so Windows compatible devices would work. For spec compliant WUSB devices, the max packet size would be incorrectly calculated which would result in high-bandwidth isoc streams being unable to find an alt setting that provided enough bandwidth. 2. After super speed support: all WUSB devices fell through to the default case of uvc_endpoint_max_bpi which would mask off the upper bits of the max packet size. This broke both WUSB spec compliant and non compliant devices because no endpoint with a large enough bpi would be found. 3. After 79af67e77f86404e77e: Spec compliant devices are fixed but non-spec compliant (although Windows compatible) devices are broken. Basically, this is the opposite of how it worked prior to super speed support. Given that, I can submit a patch to revert 79af67e77f86404e77e but that would go back to having all WUSB devices broken. Alternatively, the change below will revert the behavior back to scenario 1 where Windows compatible devices work but strictly spec complaint devices may not. I can send a proper patch for whichever scenario you prefer. Thank you for the explanation. Reverting 79af67e77f86404e77e doesn't seem like a very good idea, given that all WUSB devices will be broken. We thus have two options: - leaving the code as-is, with support for spec-compliant WUSB devices but not for microsoft-specific devices - applying the patch below, with support for microsoft-specific USB devices but not for spec-compliant devices This isn't the first time this kind of situation occurs. Microsoft didn't support multiple configurations before Windows 8, making vendors come up with lots of creative MS-specific solutions. I consider those devices non USB compliant, and they should not be allowed to use the USB logo, but that would require a strong political move from the USB Implementers Forum which is more or less controlled by Microsoft... Welcome to the USB mafia. Anyway, I have no experience with WUSB devices, so I don't know what's more common in the wild. What would you suggest ? Would there be a way to support both categories of devices ? diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c index 8d52baf..ed594d6 100644 --- a/drivers/media/usb/uvc/uvc_video.c +++ b/drivers/media/usb/uvc/uvc_video.c @@ -1451,11 +1451,9 @@ static unsigned int uvc_endpoint_max_bpi(struct usb_device *dev, case USB_SPEED_SUPER: return ep-ss_ep_comp.wBytesPerInterval; case USB_SPEED_HIGH: - psize = usb_endpoint_maxp(ep-desc); - return (psize 0x07ff) * (1 + ((psize 11) 3)); case USB_SPEED_WIRELESS: psize = usb_endpoint_maxp(ep-desc); - return psize; + return (psize 0x07ff) * (1 + ((psize 11) 3)); default: psize = usb_endpoint_maxp(ep-desc); return psize 0x07ff; -- 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: USB OTG support on mx27pdk
On Wed, Apr 16, 2014 at 2:55 AM, Alexander Shiyan shc_w...@mail.ru wrote: ci_hdrc ci_hdrc.0: EHCI Host Controller ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.15.0-rc1-next-20140415-dirty ehci_hcd usb usb1: SerialNumber: ci_hdrc.0 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected Thanks for testing, Alexander. Does your bootloader have USB support? If so, would it be possible to remove the USB support from the bootloader, please? I am wondering if the bootloader is doing some USB related init that the kernel is missing. Thanks, Fabio Estevam -- 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: USB OTG support on mx27pdk
Wed, 16 Apr 2014 08:32:55 -0300 от Fabio Estevam feste...@gmail.com: On Wed, Apr 16, 2014 at 2:55 AM, Alexander Shiyan shc_w...@mail.ru wrote: ci_hdrc ci_hdrc.0: EHCI Host Controller ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.15.0-rc1-next-20140415-dirty ehci_hcd usb usb1: SerialNumber: ci_hdrc.0 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected Thanks for testing, Alexander. Does your bootloader have USB support? If so, would it be possible to remove the USB support from the bootloader, please? I am wondering if the bootloader is doing some USB related init that the kernel is missing. I can tell immediately without further testing, this will not work without the USB support in the bootoader because we do not have DT support for ULPI. ---
Re: USB OTG support on mx27pdk
On Wed, Apr 16, 2014 at 8:58 AM, Alexander Shiyan shc_w...@mail.ru wrote: I can tell immediately without further testing, this will not work without the USB support in the bootoader because we do not have DT support for ULPI. The generic nop usb phy should work just fine. I have tried Uwe's suggestion from a previous post and reverted: commit cd0b42c2a6d2a74244f0053f8960f5dad5842278 Author: Chris Ruehl chris.ru...@gtsys.com.hk Date: Fri Jan 10 13:51:30 2014 +0800 usb: chipidea: put hw_phymode_configure before ci_usb_phy_init hw_phymode_configure configures the PORTSC registers and allow the following phy_inits to operate on the right parameters. This fix a problem where the UPLI (ISP1504) could not be detected, because the Viewport was not available and read the viewport return 0's only. Signed-off-by: Chris Ruehl chris.ru...@gtsys.com.hk Signed-off-by: Peter Chen peter.c...@freescale.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Then USB OTG port detected the USB pen driver fine: usbcore: registered new interface driver usb-storage 10024000.usb supply vbus not found, using dummy regulator ci_hdrc ci_hdrc.0: EHCI Host Controller ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected ... scsi 0:0:0:0: Direct-Access ChipsBnk Flash Disk 2.00 PQ: 0 ANSI: 2 sd 0:0:0:0: [sda] 1035200 512-byte logical blocks: (530 MB/505 MiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] No Caching mode page found sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 0:0:0:0: [sda] Attached SCSI removable disk If I understand correctly commit cd0b42c2a was only needed because Chris was trying to add DT support for ULPI, which never got merged into mainline. If we use the generic nop usb phy instead, we should just revert this commit. Any objections? Regards, Fabio Estevam -- 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 v3 3/4] USB: ohci-pxa27x: Add support for external vbus regulators
Override the hub control operation to enable and disable external
regulators for the ports vbus power supply in response to clear/set
USB_PORT_FEAT_POWER requests.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/usb/host/ohci-pxa27x.c | 67 ++
1 file changed, 67 insertions(+)
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index d21d5fe..0c31265 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -30,6 +30,7 @@
#include linux/platform_data/usb-ohci-pxa27x.h
#include linux/platform_data/usb-pxa3xx-ulpi.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/signal.h
#include linux/usb.h
#include linux/usb/hcd.h
@@ -120,6 +121,8 @@ static struct hc_driver __read_mostly ohci_pxa27x_hc_driver;
struct pxa27x_ohci {
struct clk *clk;
void __iomem*mmio_base;
+ struct regulator *vbus[3];
+ boolvbus_enabled[3];
};
#define to_pxa27x_ohci(hcd)(struct pxa27x_ohci *)(hcd_to_ohci(hcd)-priv)
@@ -166,6 +169,52 @@ static int pxa27x_ohci_select_pmm(struct pxa27x_ohci
*pxa_ohci, int mode)
return 0;
}
+static int pxa27x_ohci_set_vbus_power(struct pxa27x_ohci *pxa_ohci,
+ unsigned int port, bool enable)
+{
+ struct regulator *vbus = pxa_ohci-vbus[port];
+ int ret = 0;
+
+ if (IS_ERR_OR_NULL(vbus))
+ return 0;
+
+ if (enable !pxa_ohci-vbus_enabled[port])
+ ret = regulator_enable(vbus);
+ else if (!enable pxa_ohci-vbus_enabled[port])
+ ret = regulator_disable(vbus);
+
+ if (ret 0)
+ return ret;
+
+ pxa_ohci-vbus_enabled[port] = enable;
+
+ return 0;
+}
+
+static int pxa27x_ohci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
+ u16 wIndex, char *buf, u16 wLength)
+{
+ struct pxa27x_ohci *pxa_ohci = to_pxa27x_ohci(hcd);
+ int ret;
+
+ switch (typeReq) {
+ case SetPortFeature:
+ case ClearPortFeature:
+ if (!wIndex || wIndex 3)
+ return -EPIPE;
+
+ if (wValue != USB_PORT_FEAT_POWER)
+ break;
+
+ ret = pxa27x_ohci_set_vbus_power(pxa_ohci, wIndex - 1,
+typeReq == SetPortFeature);
+ if (ret)
+ return ret;
+ break;
+ }
+
+ return ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+}
/*-*/
static inline void pxa27x_setup_hc(struct pxa27x_ohci *pxa_ohci,
@@ -372,6 +421,7 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver,
struct platform_device
struct ohci_hcd *ohci;
struct resource *r;
struct clk *usb_clk;
+ unsigned int i;
retval = ohci_pxa_of_init(pdev);
if (retval)
@@ -417,6 +467,16 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver,
struct platform_device
pxa_ohci-clk = usb_clk;
pxa_ohci-mmio_base = (void __iomem *)hcd-regs;
+ for (i = 0; i 3; ++i) {
+ char name[6];
+
+ if (!(inf-flags (ENABLE_PORT1 i)))
+ continue;
+
+ sprintf(name, vbus%u, i + 1);
+ pxa_ohci-vbus[i] = devm_regulator_get(pdev-dev, name);
+ }
+
retval = pxa27x_start_hc(pxa_ohci, pdev-dev);
if (retval 0) {
pr_debug(pxa27x_start_hc failed);
@@ -462,6 +522,10 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver,
struct platform_device
void usb_hcd_pxa27x_remove (struct usb_hcd *hcd, struct platform_device *pdev)
{
struct pxa27x_ohci *pxa_ohci = to_pxa27x_ohci(hcd);
+ unsigned int i;
+
+ for (i = 0; i 3; ++i)
+ pxa27x_ohci_set_vbus_power(pxa_ohci, i, false);
usb_remove_hcd(hcd);
pxa27x_stop_hc(pxa_ohci, pdev-dev);
@@ -563,7 +627,10 @@ static int __init ohci_pxa27x_init(void)
return -ENODEV;
pr_info(%s: DRIVER_DESC \n, hcd_name);
+
ohci_init_driver(ohci_pxa27x_hc_driver, pxa27x_overrides);
+ ohci_pxa27x_hc_driver.hub_control = pxa27x_ohci_hub_control;
+
return platform_driver_register(ohci_hcd_pxa27x_driver);
}
module_init(ohci_pxa27x_init);
--
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 v3 4/4] ARM: pxa: zeus: Replace OHCI init/exit functions with a regulator
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-pxa/zeus.c | 89 ++--
1 file changed, 48 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index b19d1c3..205f9bf 100644
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -413,7 +413,7 @@ static struct fixed_voltage_config can_regulator_pdata = {
static struct platform_device can_regulator_device = {
.name = reg-fixed-volage,
- .id = -1,
+ .id = 0,
.dev= {
.platform_data = can_regulator_pdata,
},
@@ -510,18 +510,6 @@ struct platform_device zeus_max6369_device = {
.num_resources = 1,
};
-static struct platform_device *zeus_devices[] __initdata = {
- zeus_serial_device,
- zeus_mtd_devices[0],
- zeus_dm9k0_device,
- zeus_dm9k1_device,
- zeus_sram_device,
- zeus_leds_device,
- zeus_pcmcia_device,
- zeus_max6369_device,
- can_regulator_device,
-};
-
/* AC'97 */
static pxa2xx_audio_ops_t zeus_ac97_info = {
.reset_gpio = 95,
@@ -532,44 +520,50 @@ static pxa2xx_audio_ops_t zeus_ac97_info = {
* USB host
*/
-static int zeus_ohci_init(struct device *dev)
-{
- int err;
-
- /* Switch on port 2. */
- if ((err = gpio_request(ZEUS_USB2_PWREN_GPIO, USB2_PWREN))) {
- dev_err(dev, Can't request USB2_PWREN\n);
- return err;
- }
-
- if ((err = gpio_direction_output(ZEUS_USB2_PWREN_GPIO, 1))) {
- gpio_free(ZEUS_USB2_PWREN_GPIO);
- dev_err(dev, Can't enable USB2_PWREN\n);
- return err;
- }
+static struct regulator_consumer_supply zeus_ohci_regulator_supplies[] = {
+ REGULATOR_SUPPLY(vbus2, pxa27x-ohci),
+};
- /* Port 2 is shared between host and client interface. */
- UP2OCR = UP2OCR_HXOE | UP2OCR_HXS | UP2OCR_DMPDE | UP2OCR_DPPDE;
+static struct regulator_init_data zeus_ohci_regulator_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(zeus_ohci_regulator_supplies),
+ .consumer_supplies = zeus_ohci_regulator_supplies,
+};
- return 0;
-}
+static struct fixed_voltage_config zeus_ohci_regulator_config = {
+ .supply_name= vbus2,
+ .microvolts = 500, /* 5.0V */
+ .gpio = ZEUS_USB2_PWREN_GPIO,
+ .enable_high= 1,
+ .startup_delay = 0,
+ .init_data = zeus_ohci_regulator_data,
+};
-static void zeus_ohci_exit(struct device *dev)
-{
- /* Power-off port 2 */
- gpio_direction_output(ZEUS_USB2_PWREN_GPIO, 0);
- gpio_free(ZEUS_USB2_PWREN_GPIO);
-}
+static struct platform_device zeus_ohci_regulator_device = {
+ .name = reg-fixed-voltage,
+ .id = 1,
+ .dev = {
+ .platform_data = zeus_ohci_regulator_config,
+ },
+};
static struct pxaohci_platform_data zeus_ohci_platform_data = {
.port_mode = PMM_NPS_MODE,
/* Clear Power Control Polarity Low and set Power Sense
* Polarity Low. Supply power to USB ports. */
.flags = ENABLE_PORT_ALL | POWER_SENSE_LOW,
- .init = zeus_ohci_init,
- .exit = zeus_ohci_exit,
};
+static void zeus_register_ohci(void)
+{
+ /* Port 2 is shared between host and client interface. */
+ UP2OCR = UP2OCR_HXOE | UP2OCR_HXS | UP2OCR_DMPDE | UP2OCR_DPPDE;
+
+ pxa_set_ohci_info(zeus_ohci_platform_data);
+}
+
/*
* Flat Panel
*/
@@ -677,6 +671,19 @@ static struct pxa2xx_udc_mach_info zeus_udc_info = {
.udc_command = zeus_udc_command,
};
+static struct platform_device *zeus_devices[] __initdata = {
+ zeus_serial_device,
+ zeus_mtd_devices[0],
+ zeus_dm9k0_device,
+ zeus_dm9k1_device,
+ zeus_sram_device,
+ zeus_leds_device,
+ zeus_pcmcia_device,
+ zeus_max6369_device,
+ can_regulator_device,
+ zeus_ohci_regulator_device,
+};
+
#ifdef CONFIG_PM
static void zeus_power_off(void)
{
@@ -847,7 +854,7 @@ static void __init zeus_init(void)
platform_add_devices(zeus_devices, ARRAY_SIZE(zeus_devices));
- pxa_set_ohci_info(zeus_ohci_platform_data);
+ zeus_register_ohci();
if (zeus_setup_fb_gpios())
pr_err(Failed to setup fb gpios\n);
--
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 v3 0/4] Allow OHCI/EHCI drivers to override more hub operations
Hello, The PXA27x OHCI implementation doesn't perform automatic control of port power supplies for all ports. While the PPS and LSDA bits of the HcRhPortStatus register are implemented, only a subset of ports have an external power enable pin controlled by the port status register. Other ports need their power supply to be controlled manually. In order to do so I've implemented manual regulator control in the ohci-pxa27x driver. This requires overriding the default behaviour of the CLEAR_FEATURE and SET_FEATURE requests for USB_PORT_FEAT_POWER with a custom hub control operation. In turn this requires calling the currently static ohci_hub_control function from the ohci-pxa27x driver. The ohci-at91 and ohci-s3c2410 drivers already implement a similar feature, and access the ohci_hub_control and ohci_hub_status_data functions by saving the struct hc_driver hub_control and hub_status_data values to a variables right after calling ohci_init_driver. This vtable-like implementation can be optimized by exporting the ohci_hub_control and ohci_hub_status_data functions and calling them directly. As the ohci-pxa27x driver needs to override hub control operations as well I've decided to export the functions. For the sake of completeness I've also exported the ehci_hub_control function and modified the ehci-tegra driver to call it directly. As a side note regarding the ohci-at91 driver, the atmel,vbus-gpio DT property should really have referenced a regulator instead of a GPIO. Fixing this in a backward-compatible way would be messy :-( Please note that I haven't been able to test the third and fourth patches due to lack of hardware. I've however tested a similar implementation for OHCI on an out of tree PXA270 board. Changes compared to v2: - Export ohci_hub_status_data() - Call ohci_hub_status_data() directly from ohci-at91 and ohci-s3c2410 Changes compared to v1: - Export ehci_hub_control() - Call ehci_hub_control() directly from ehci-tegra - Call ohci_hub_control() directly from ohci-at91 Laurent Pinchart (4): USB: OHCI: Export the OHCI hub control and status_data functions USB: EHCI: Export the ehci_hub_control function USB: ohci-pxa27x: Add support for external vbus regulators ARM: pxa: zeus: Replace OHCI init/exit functions with a regulator arch/arm/mach-pxa/zeus.c| 89 ++--- drivers/usb/host/ehci-hub.c | 12 +- drivers/usb/host/ehci-tegra.c | 8 +--- drivers/usb/host/ehci.h | 3 ++ drivers/usb/host/ohci-at91.c| 11 + drivers/usb/host/ohci-hub.c | 8 ++-- drivers/usb/host/ohci-pxa27x.c | 67 +++ drivers/usb/host/ohci-s3c2410.c | 13 ++ drivers/usb/host/ohci.h | 3 ++ 9 files changed, 133 insertions(+), 81 deletions(-) -- 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
[PATCH v3 2/4] USB: EHCI: Export the ehci_hub_control function
Platform drivers sometimes need to perform specific handling of hub
control requests. Make this possible by exporting the ehci_hub_control()
function which can then be called from a custom hub control handler in
the default case.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/usb/host/ehci-hub.c | 12 ++--
drivers/usb/host/ehci-tegra.c | 8 +---
drivers/usb/host/ehci.h | 3 +++
3 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 7ae0c4d..cc305c7 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -33,15 +33,6 @@
#ifdef CONFIG_PM
-static int ehci_hub_control(
- struct usb_hcd *hcd,
- u16 typeReq,
- u16 wValue,
- u16 wIndex,
- char*buf,
- u16 wLength
-);
-
static int persist_enabled_on_companion(struct usb_device *udev, void *unused)
{
return !udev-maxchild udev-persist_enabled
@@ -865,7 +856,7 @@ cleanup:
#endif /* CONFIG_USB_HCD_TEST_MODE */
/*-*/
-static int ehci_hub_control (
+int ehci_hub_control(
struct usb_hcd *hcd,
u16 typeReq,
u16 wValue,
@@ -1285,6 +1276,7 @@ error_exit:
spin_unlock_irqrestore (ehci-lock, flags);
return retval;
}
+EXPORT_SYMBOL_GPL(ehci_hub_control);
static void ehci_relinquish_port(struct usb_hcd *hcd, int portnum)
{
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index af28b74..f64653f 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -55,10 +55,6 @@ struct tegra_ehci_soc_config {
bool has_hostpc;
};
-static int (*orig_hub_control)(struct usb_hcd *hcd,
- u16 typeReq, u16 wValue, u16 wIndex,
- char *buf, u16 wLength);
-
struct tegra_ehci_hcd {
struct tegra_usb_phy *phy;
struct clk *clk;
@@ -240,7 +236,7 @@ static int tegra_ehci_hub_control(
spin_unlock_irqrestore(ehci-lock, flags);
/* Handle the hub control events here */
- return orig_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+ return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
done:
spin_unlock_irqrestore(ehci-lock, flags);
@@ -535,8 +531,6 @@ static int __init ehci_tegra_init(void)
* too easy.
*/
- orig_hub_control = tegra_ehci_hc_driver.hub_control;
-
tegra_ehci_hc_driver.map_urb_for_dma = tegra_ehci_map_urb_for_dma;
tegra_ehci_hc_driver.unmap_urb_for_dma = tegra_ehci_unmap_urb_for_dma;
tegra_ehci_hc_driver.hub_control = tegra_ehci_hub_control;
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 9dfc6c1..eee228a 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -872,4 +872,7 @@ extern int ehci_suspend(struct usb_hcd *hcd, bool
do_wakeup);
extern int ehci_resume(struct usb_hcd *hcd, bool hibernated);
#endif /* CONFIG_PM */
+extern int ehci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
+u16 wIndex, char *buf, u16 wLength);
+
#endif /* __LINUX_EHCI_HCD_H */
--
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 v3 1/4] USB: OHCI: Export the OHCI hub control and status_data functions
Platform drivers sometimes need to perform specific handling of hub
control requests and status data. Make this possible by exporting the
ohci_hub_control() and ohci_hub_status_data() functions which can then
be called from custom hub operations in the default case.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/usb/host/ohci-at91.c| 11 ++-
drivers/usb/host/ohci-hub.c | 8
drivers/usb/host/ohci-s3c2410.c | 13 +++--
drivers/usb/host/ohci.h | 3 +++
4 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 091ae49..e49eb4f 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -46,9 +46,6 @@ static const char hcd_name[] = ohci-atmel;
static struct hc_driver __read_mostly ohci_at91_hc_driver;
static int clocked;
-static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq,
- u16 wValue, u16 wIndex, char *buf, u16 wLength);
-static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
extern int usb_disabled(void);
@@ -262,7 +259,7 @@ static int ohci_at91_usb_get_power(struct at91_usbh_data
*pdata, int port)
static int ohci_at91_hub_status_data(struct usb_hcd *hcd, char *buf)
{
struct at91_usbh_data *pdata = hcd-self.controller-platform_data;
- int length = orig_ohci_hub_status_data(hcd, buf);
+ int length = ohci_hub_status_data(hcd, buf);
int port;
at91_for_each_port(port) {
@@ -340,8 +337,7 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
break;
}
- ret = orig_ohci_hub_control(hcd, typeReq, wValue, wIndex + 1,
- buf, wLength);
+ ret = ohci_hub_control(hcd, typeReq, wValue, wIndex + 1, buf, wLength);
if (ret)
goto out;
@@ -690,9 +686,6 @@ static int __init ohci_at91_init(void)
* too easy.
*/
- orig_ohci_hub_control = ohci_at91_hc_driver.hub_control;
- orig_ohci_hub_status_data = ohci_at91_hc_driver.hub_status_data;
-
ohci_at91_hc_driver.hub_status_data = ohci_at91_hub_status_data;
ohci_at91_hc_driver.hub_control = ohci_at91_hub_control;
diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
index c81c872..3d53208 100644
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -438,8 +438,7 @@ static int ohci_root_hub_state_changes(struct ohci_hcd
*ohci, int changed,
/* build status change packet (one or two bytes) from HC registers */
-static int
-ohci_hub_status_data (struct usb_hcd *hcd, char *buf)
+int ohci_hub_status_data(struct usb_hcd *hcd, char *buf)
{
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
int i, changed = 0, length = 1;
@@ -504,6 +503,7 @@ done:
return changed ? length : 0;
}
+EXPORT_SYMBOL_GPL(ohci_hub_status_data);
/*-*/
@@ -646,7 +646,7 @@ static inline int root_port_reset (struct ohci_hcd *ohci,
unsigned port)
return 0;
}
-static int ohci_hub_control (
+int ohci_hub_control(
struct usb_hcd *hcd,
u16 typeReq,
u16 wValue,
@@ -772,4 +772,4 @@ error:
}
return retval;
}
-
+EXPORT_SYMBOL_GPL(ohci_hub_control);
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index ff7c8f1..3d753a9 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -45,10 +45,6 @@ static struct clk *usb_clk;
/* forward definitions */
-static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq,
- u16 wValue, u16 wIndex, char *buf, u16 wLength);
-static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
-
static void s3c2410_hcd_oc(struct s3c2410_hcd_info *info, int port_oc);
/* conversion functions */
@@ -110,7 +106,7 @@ ohci_s3c2410_hub_status_data(struct usb_hcd *hcd, char *buf)
int orig;
int portno;
- orig = orig_ohci_hub_status_data(hcd, buf);
+ orig = ohci_hub_status_data(hcd, buf);
if (info == NULL)
return orig;
@@ -181,7 +177,7 @@ static int ohci_s3c2410_hub_control(
* process the request straight away and exit */
if (info == NULL) {
- ret = orig_ohci_hub_control(hcd, typeReq, wValue,
+ ret = ohci_hub_control(hcd, typeReq, wValue,
wIndex, buf, wLength);
goto out;
}
@@ -231,7 +227,7 @@ static int ohci_s3c2410_hub_control(
break;
}
- ret = orig_ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+ ret = ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
if (ret)
goto out;
@@ -489,9
Re: [PATCH V4 5/5] usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver
Hi Vivek, 2014-04-09 13:34 GMT+02:00 Vivek Gautam gautam.vi...@samsung.com: Hi Tomasz, ' On Wed, Apr 9, 2014 at 4:43 PM, Tomasz Figa t.f...@samsung.com wrote: Hi Vivek, Thanks for reviewing the patch series. On 08.04.2014 16:36, Vivek Gautam wrote: Removing this older USB 3.0 DRD controller PHY driver, since a new driver based on generic phy framework is now available. Also removing the dt node for older driver from Exynos5250 device tree and updating the dt node for DWC3 controller. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- NOTE: This patch should be merged only when the new USB 3.0 DRD phy controller driver is available in the tree from the patches: phy: Add new Exynos5 USB 3.0 PHY driver; and dt: exynos5250: Enable support for generic USB DRD phy arch/arm/boot/dts/exynos5250.dtsi | 17 +- drivers/usb/phy/phy-samsung-usb.h | 83 - drivers/usb/phy/phy-samsung-usb3.c | 350 3 files changed, 2 insertions(+), 448 deletions(-) delete mode 100644 drivers/usb/phy/phy-samsung-usb3.c diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 92c6fcd..1cb1e91 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi IMHO driver and dts changes should be separated into two patches, first updating device tree to use the new driver and second removing the driver. Sure will separate the patch into driver and dts change. After fixing this issue, Reviewed-by: Tomasz Figa t.f...@samsung.com I guess you should also remove phy-samsung-usb3.c references in the Makefile, Kconfig and exynos_defconfig Richard. -- 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 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Vivek,
On 15.04.2014 08:09, Vivek Gautam wrote:
Hi Tomasz,
On Thu, Apr 10, 2014 at 5:09 PM, Vivek Gautam gautamvivek1...@gmail.com wrote:
On Wed, Apr 9, 2014 at 7:03 PM, Tomasz Figa t.f...@samsung.com wrote:
On 09.04.2014 13:49, Vivek Gautam wrote:
Hi,
On Wed, Apr 9, 2014 at 4:36 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Vivek,
Please see my comments inline.
On 08.04.2014 16:36, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 668
4 files changed, 722 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
[snip]
+ Additional clock required for Exynos5420:
+ - usb30_sclk_100m: Additional special clock used for PHY
operation
+ depicted as 'sclk_usbphy30' in CMU of
Exynos5420.
Are you sure this isn't simply a gate for the ref clock, as it can be
found
on another SoC that is not upstream yet? I don't have documentation for
Exynos 5420 so I can't tell, but I'd like to ask you to recheck this.
From what i can see in the manual :
sclk_usbphy30 is derived from OSCCLK.
It is coming from a MUX (default input line to this is OSCCLK) and
then through a DIV
there's this gate.
{OSCCLK + other sources} ---[MUX] --- [DIV] -- [GATE for
sclk_usbphy30]
the {rate of sclk_usbphy30} == OSCCLK
However the 'ref' clock that we have been using is the actual oscillator
clock.
And on SoC Exynos5250, we don't have any such gate (sclk_usbphy30).
So should this mean that ref clock and sclk_usbphy30 are still be
controlled by
two different gates ?
Is there maybe a diagram of PHY input clocks in the datasheet, like for USB
2.0 PHY in Exynos4210/4412/5250 datasheets in the chapter about USB2.0
Device? Something like:
||
| ___|
XusbXTI | Phy_fsel[2:0]| ___ |
___[X]___|| __|_|___|\__|_|
| | _v___ | _ ^ | |/ | |
_ | | || | | | | ___ | |
___| | || | | | | | |_|_|
|___| | | X 0 ||_| PLL |__|_|_|CLK|_|_|
_ | | | | || |DIV|_|_|
|___[X] | |_| 12 |_|480 | |___| | |
| MHz MHz |Digital| |
XusbXTO | USB PHY|___| |
||
Below is the block diagram given for DRD controller.
___
||
| |
| | PHY | |
| | controller |-|---
| |__ | | |
||
|
| USB 3.0 | V
| DRD |
---
|Controller | |
|
||USB30_SCLK_100M| USB 3.0 DRD |
| | ---
| PHY |
| | Link cont. | | |
|
| - |
| |
|___| |_|
Does this help ?
So, USB30_SCLK_100M is the SCLK that we are talking in the driver. I
don't see any reference to XXTI in the USB 3.0 DRD controller chapter
(in both Exynos5250 and 5420)
In addition to this there's one more point to be noticed here.
On Exynos5420 system, the sclk_usbphy300 (which is the sclk_usbphy30
for USB DRD channel 0), is also the PICO phy clock, i.e. USB 2.0 phy
clock.
So we should add a similar clk_get() for this clock in the
phy-exynos5250-usb2 driver too, to support Exynos5420.
Is something clear from the above block diagram ? (although the
diagram looks weird - space and tabs problem :-( )
Basically there's the clock USB30_SCLK_100M which is going into the
USB 3.0 DRD PHY controller.
And this is the only sclk mentioned in the block diagram for USB 3.0
DRD controller in Exynos5420.
Same is not
Re: [PATCH RFC 3/4] xhci: Tune PHY for the DWC3-Exynos host controller
Hi,
On Tue, Apr 15, 2014 at 06:24:11PM +0530, Vivek Gautam wrote:
I had seen your patches in the mailing list, but i don't see any
updated version of these patches.
Are you planning to work on this above mentioned patch-series any time soon ?
I'm sorry, I forgot this completely. I have not prepared new version
of those patches as the drivers I need them for are not ready yet, but
I guess I can also use this case as justification for them.
Or, should i try to find a different approach for handling the phy
from the host controller (child of DWC3 in this case, which has the
phys).
Well, there is now an issue with the lookup method I'm suggesting in
this case. Since the device ID is now generated automatically for
xhci-hcd in dwc3, we don't know the xhci-hcd device name before
platform_device_add(), and that is too late. I don't see why the
device could not be named when platform_device_alloc() is called, so I
think I'll suggest something like the attached patch to fix this
issue.
In any case, I'll send an updated version of the phy patches soon.
Thanks,
--
heikki
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index e714709..13f8edb 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -169,11 +169,47 @@ struct platform_object {
*/
void platform_device_put(struct platform_device *pdev)
{
- if (pdev)
- put_device(pdev-dev);
+ if (!pdev)
+ return;
+
+ if (pdev-id_auto) {
+ ida_simple_remove(platform_devid_ida, pdev-id);
+ pdev-id = PLATFORM_DEVID_AUTO;
+ }
+
+ put_device(pdev-dev);
}
EXPORT_SYMBOL_GPL(platform_device_put);
+static int pdev_set_name(struct platform_device *pdev)
+{
+ int ret;
+
+ switch (pdev-id) {
+ default:
+ dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ break;
+ case PLATFORM_DEVID_NONE:
+ dev_set_name(pdev-dev, %s, pdev-name);
+ break;
+ case PLATFORM_DEVID_AUTO:
+ /*
+ * Automatically allocated device ID. We mark it as such so
+ * that we remember it must be freed, and we append a suffix
+ * to avoid namespace collision with explicit IDs.
+ */
+ ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
+ if (ret 0)
+ return ret;
+ pdev-id = ret;
+ pdev-id_auto = true;
+ dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
+ break;
+ }
+
+ return 0;
+}
+
static void platform_device_release(struct device *dev)
{
struct platform_object *pa = container_of(dev, struct platform_object,
@@ -206,6 +242,10 @@ struct platform_device *platform_device_alloc(const char *name, int id)
device_initialize(pa-pdev.dev);
pa-pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(pa-pdev);
+ if (pdev_set_name(pa-pdev)) {
+ kfree(pa);
+ return NULL;
+ }
}
return pa ? pa-pdev : NULL;
@@ -286,28 +326,6 @@ int platform_device_add(struct platform_device *pdev)
pdev-dev.bus = platform_bus_type;
- switch (pdev-id) {
- default:
- dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
- break;
- case PLATFORM_DEVID_NONE:
- dev_set_name(pdev-dev, %s, pdev-name);
- break;
- case PLATFORM_DEVID_AUTO:
- /*
- * Automatically allocated device ID. We mark it as such so
- * that we remember it must be freed, and we append a suffix
- * to avoid namespace collision with explicit IDs.
- */
- ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
- if (ret 0)
- goto err_out;
- pdev-id = ret;
- pdev-id_auto = true;
- dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
- break;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *p, *r = pdev-resource[i];
@@ -350,7 +368,6 @@ int platform_device_add(struct platform_device *pdev)
release_resource(r);
}
- err_out:
return ret;
}
EXPORT_SYMBOL_GPL(platform_device_add);
@@ -370,11 +387,6 @@ void platform_device_del(struct platform_device *pdev)
if (pdev) {
device_del(pdev-dev);
- if (pdev-id_auto) {
- ida_simple_remove(platform_devid_ida, pdev-id);
- pdev-id = PLATFORM_DEVID_AUTO;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *r = pdev-resource[i];
unsigned long type = resource_type(r);
@@ -392,8 +404,15 @@ EXPORT_SYMBOL_GPL(platform_device_del);
*/
int platform_device_register(struct platform_device *pdev)
{
+ int ret;
+
device_initialize(pdev-dev);
arch_setup_pdev_archdata(pdev);
+
+ ret = pdev_set_name(pdev);
+ if (ret)
+ return ret;
+
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
Re: [PATCH] usb/serial/ch341: Add parity support
On Wed, Apr 16, 2014 at 10:42:41AM +, Karl Palsson wrote: On Wed, Apr 16, 2014 at 10:17:29AM +0200, Johan Hovold wrote: Fair enough. I don't mind keeping some of those magic constants for now, but I think we should at least assume that we're dealing with a fairly standard LCR register and use appropriate names and defines for that bit that you patch is changing. That is, something like: u8 lcr; and #define UART_LCR_DLAB 0x80 /* Divisor latch access bit (?) */ #define UART_LCR_SBC0x40 /* Set break control (?) */ #define UART_LCR_SPAR 0x20 /* Stick parity */ #define UART_LCR_EPAR 0x10 /* Even parity select */ #define UART_LCR_PARITY 0x08 /* Parity Enable */ #define UART_LCR_STOP 0x04 /* Stop bits: 0=1 bit, 1=2 bits */ #define UART_LCR_WLEN5 0x00 /* Wordlength: 5 bits */ #define UART_LCR_WLEN6 0x01 /* Wordlength: 6 bits */ #define UART_LCR_WLEN7 0x02 /* Wordlength: 7 bits */ #define UART_LCR_WLEN8 0x03 /* Wordlength: 8 bits */ Could you redo your patch using those defines? It's up to you if you want to implement stop and data bit support at once or do that as a follow-up patch (but please still use UART_LCR_WLEN8 if you choose to keep the data bits hard-coded). Yes, I can do that, but I don't have any good devices handy to test variable databits. I can maybe test out variable stop bit, I think I have some hardware for that, but parity is my primary (really, only) concern. Are those already defined somewhere else, or are you proposing (re) defining them again in this driver? Good question. They can be made available by #include linux/serial_reg.h But until we know (or are reasonably sure) what the bits are for, perhaps it is better to redefine them in the driver with a CH341_-prefix (instead of UART_) and comment on those that are left to be verified? Could you also see if everything appears to be working even if you leave DLAB and SBC unset? Yeah, I kinda took that as required testing :) Good. :) Do you have access to both ch340 and ch341 devices in order to verify that both types keep working? This is also why I don't want to go too far with trying to test stop bits and data bits. I have a CH340, which doesn't support variable stop/data bits, and another device with the chip labels scratched off, that could be either. Well, if you really want to make a minimal implementation of only parity, then only modify bits 0x38 and keep bit 0x40 (SBC) set use UART_LCR_WLEN5 as the driver used to (it set 0x50). If the device with scratched of label still works then it should also be a ch340? I am a little worried that the magic happening in ch341_break_ctl also messes with this very same register (CH341_NBREAK_BITS_REG2 is 0x40, that is, UART_LCR_SBC)... I guess such things could be verified by reading back LCR after setting and clearing break (as appears to be done in ch341_configure()). This is going to take a while longer to redo unfortunately. Yeah, reverse engineering can be a PITA, and especially as we also try to avoid regressions. Johan -- 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 5/5] usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver
Hi Richard, On Wed, Apr 16, 2014 at 7:03 PM, Richard Genoud richard.gen...@gmail.com wrote: Hi Vivek, 2014-04-09 13:34 GMT+02:00 Vivek Gautam gautam.vi...@samsung.com: Hi Tomasz, ' On Wed, Apr 9, 2014 at 4:43 PM, Tomasz Figa t.f...@samsung.com wrote: Hi Vivek, Thanks for reviewing the patch series. On 08.04.2014 16:36, Vivek Gautam wrote: Removing this older USB 3.0 DRD controller PHY driver, since a new driver based on generic phy framework is now available. Also removing the dt node for older driver from Exynos5250 device tree and updating the dt node for DWC3 controller. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- NOTE: This patch should be merged only when the new USB 3.0 DRD phy controller driver is available in the tree from the patches: phy: Add new Exynos5 USB 3.0 PHY driver; and dt: exynos5250: Enable support for generic USB DRD phy arch/arm/boot/dts/exynos5250.dtsi | 17 +- drivers/usb/phy/phy-samsung-usb.h | 83 - drivers/usb/phy/phy-samsung-usb3.c | 350 3 files changed, 2 insertions(+), 448 deletions(-) delete mode 100644 drivers/usb/phy/phy-samsung-usb3.c diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 92c6fcd..1cb1e91 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi IMHO driver and dts changes should be separated into two patches, first updating device tree to use the new driver and second removing the driver. Sure will separate the patch into driver and dts change. After fixing this issue, Reviewed-by: Tomasz Figa t.f...@samsung.com I guess you should also remove phy-samsung-usb3.c references in the Makefile, Kconfig and exynos_defconfig You are correct. In fact i identified this issue once i submitted the patch :-( I have amended the things in my next series which i will be posting soon. Thanks Vivek -- 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: Deadlock v3.10.35 with FTD_SIO usb-serial adapter
On Tue, 15 Apr 2014, Matteo Fortini wrote: Yes, we tried with 3.14 and after less than 24hrs. What could we do to fix the issue? Thank you, Matteo Here's dmesg output: [103200.145660] INFO: task :2341 blocked for more than 120 seconds. [103200.145774] Not tainted 3.14.0-+ #3 [103200.145844] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [103200.145950] X D de7a 0 2341 2263 0x [103200.146163] de79be5c 00200086 c17d8de0 de7a de79be00 c17d8de0 00200246 c17d8e00 [103200.146357] de79be44 de7a de79bfec de7a c179b560 00200246 c17d8e00 de79be44 [103200.146661] de7a 007b c104eb7e c17d ffcf c154c2d5 de79be44 [103200.146853] Call Trace: [103200.146948] [c104eb7e] ? preempt_count_sub+0xb/0xac [103200.147103] [c154c2d5] ? _raw_spin_unlock_irqrestore+0x27/0x45 [103200.147200] [c154c2df] ? _raw_spin_unlock_irqrestore+0x31/0x45 [103200.147308] [c1055899] ? prepare_to_wait_event+0x60/0xb5 [103200.147432] [c134af26] ? usb_put_dev+0x14/0x16 [103200.147525] [c1548be3] schedule+0x22/0x54 [103200.147611] [c1353ac1] usb_kill_urb+0x51/0x80 A process hanging in usb_kill_urb indicates something is wrong with the host controller driver. Which host controller driver does this device use? 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 V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi,
On Wed, Apr 16, 2014 at 7:14 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Vivek,
On 15.04.2014 08:09, Vivek Gautam wrote:
Hi Tomasz,
On Thu, Apr 10, 2014 at 5:09 PM, Vivek Gautam gautamvivek1...@gmail.com
wrote:
On Wed, Apr 9, 2014 at 7:03 PM, Tomasz Figa t.f...@samsung.com wrote:
On 09.04.2014 13:49, Vivek Gautam wrote:
Hi,
On Wed, Apr 9, 2014 at 4:36 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Vivek,
Please see my comments inline.
On 08.04.2014 16:36, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 668
4 files changed, 722 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
[snip]
+ Additional clock required for Exynos5420:
+ - usb30_sclk_100m: Additional special clock used for PHY
operation
+ depicted as 'sclk_usbphy30' in CMU of
Exynos5420.
Are you sure this isn't simply a gate for the ref clock, as it can be
found
on another SoC that is not upstream yet? I don't have documentation
for
Exynos 5420 so I can't tell, but I'd like to ask you to recheck this.
From what i can see in the manual :
sclk_usbphy30 is derived from OSCCLK.
It is coming from a MUX (default input line to this is OSCCLK) and
then through a DIV
there's this gate.
{OSCCLK + other sources} ---[MUX] --- [DIV] -- [GATE for
sclk_usbphy30]
the {rate of sclk_usbphy30} == OSCCLK
However the 'ref' clock that we have been using is the actual
oscillator
clock.
And on SoC Exynos5250, we don't have any such gate (sclk_usbphy30).
So should this mean that ref clock and sclk_usbphy30 are still be
controlled by
two different gates ?
Is there maybe a diagram of PHY input clocks in the datasheet, like for
USB
2.0 PHY in Exynos4210/4412/5250 datasheets in the chapter about USB2.0
Device? Something like:
||
| ___|
XusbXTI | Phy_fsel[2:0]| ___ |
___[X]___|| __|_|___|\__|_|
| | _v___ | _ ^ | |/ | |
_ | | || | | | | ___ | |
___| | || | | | | | |_|_|
|___| | | X 0 ||_| PLL |__|_|_|CLK|_|_|
_ | | | | || |DIV|_|_|
|___[X] | |_| 12 |_|480 | |___| | |
| MHz MHz |Digital| |
XusbXTO | USB PHY|___| |
||
Below is the block diagram given for DRD controller.
___
||
| |
| | PHY | |
| | controller
|-|---
| |__ | |
|
||
|
| USB 3.0 |
V
| DRD |
---
|Controller | |
|
||USB30_SCLK_100M| USB 3.0 DRD |
| | ---
| PHY |
| | Link cont. | | |
|
| - |
| |
|___| |_|
Does this help ?
So, USB30_SCLK_100M is the SCLK that we are talking in the driver. I
don't see any reference to XXTI in the USB 3.0 DRD controller chapter
(in both Exynos5250 and 5420)
In addition to this there's one more point to be noticed here.
On Exynos5420 system, the sclk_usbphy300 (which is the sclk_usbphy30
for USB DRD channel 0), is also the PICO phy clock, i.e. USB 2.0 phy
clock.
So we should add a similar clk_get() for this clock in the
phy-exynos5250-usb2 driver too, to support Exynos5420.
Is something clear from the above block diagram ? (although the
diagram looks weird - space and tabs problem :-( )
Basically there's the clock USB30_SCLK_100M which is going into the
USB 3.0 DRD PHY controller.
And this is the only sclk
Re: [PATCH v3 0/4] Allow OHCI/EHCI drivers to override more hub operations
On Wed, 16 Apr 2014, Laurent Pinchart wrote: Hello, The PXA27x OHCI implementation doesn't perform automatic control of port power supplies for all ports. While the PPS and LSDA bits of the HcRhPortStatus register are implemented, only a subset of ports have an external power enable pin controlled by the port status register. Other ports need their power supply to be controlled manually. In order to do so I've implemented manual regulator control in the ohci-pxa27x driver. This requires overriding the default behaviour of the CLEAR_FEATURE and SET_FEATURE requests for USB_PORT_FEAT_POWER with a custom hub control operation. In turn this requires calling the currently static ohci_hub_control function from the ohci-pxa27x driver. The ohci-at91 and ohci-s3c2410 drivers already implement a similar feature, and access the ohci_hub_control and ohci_hub_status_data functions by saving the struct hc_driver hub_control and hub_status_data values to a variables right after calling ohci_init_driver. This vtable-like implementation can be optimized by exporting the ohci_hub_control and ohci_hub_status_data functions and calling them directly. As the ohci-pxa27x driver needs to override hub control operations as well I've decided to export the functions. For the sake of completeness I've also exported the ehci_hub_control function and modified the ehci-tegra driver to call it directly. As a side note regarding the ohci-at91 driver, the atmel,vbus-gpio DT property should really have referenced a regulator instead of a GPIO. Fixing this in a backward-compatible way would be messy :-( Please note that I haven't been able to test the third and fourth patches due to lack of hardware. I've however tested a similar implementation for OHCI on an out of tree PXA270 board. Changes compared to v2: - Export ohci_hub_status_data() - Call ohci_hub_status_data() directly from ohci-at91 and ohci-s3c2410 Changes compared to v1: - Export ehci_hub_control() - Call ehci_hub_control() directly from ehci-tegra - Call ohci_hub_control() directly from ohci-at91 For patches 1 and 2: Acked-by: Alan Stern st...@rowland.harvard.edu Comments on patch 3 sent separately. 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: USB OTG support on mx27pdk
Hi, On Wed, Apr 16, 2014 at 09:53:34AM -0300, Fabio Estevam wrote: On Wed, Apr 16, 2014 at 8:58 AM, Alexander Shiyan shc_w...@mail.ru wrote: I can tell immediately without further testing, this will not work without the USB support in the bootoader because we do not have DT support for ULPI. The generic nop usb phy should work just fine. I have tried Uwe's suggestion from a previous post and reverted: commit cd0b42c2a6d2a74244f0053f8960f5dad5842278 Author: Chris Ruehl chris.ru...@gtsys.com.hk Date: Fri Jan 10 13:51:30 2014 +0800 usb: chipidea: put hw_phymode_configure before ci_usb_phy_init hw_phymode_configure configures the PORTSC registers and allow the following phy_inits to operate on the right parameters. This fix a problem where the UPLI (ISP1504) could not be detected, because the Viewport was not available and read the viewport return 0's only. Signed-off-by: Chris Ruehl chris.ru...@gtsys.com.hk Signed-off-by: Peter Chen peter.c...@freescale.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Then USB OTG port detected the USB pen driver fine: usbcore: registered new interface driver usb-storage 10024000.usb supply vbus not found, using dummy regulator ci_hdrc ci_hdrc.0: EHCI Host Controller ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected ... scsi 0:0:0:0: Direct-Access ChipsBnk Flash Disk 2.00 PQ: 0 ANSI: 2 sd 0:0:0:0: [sda] 1035200 512-byte logical blocks: (530 MB/505 MiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] No Caching mode page found sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 0:0:0:0: [sda] Attached SCSI removable disk If I understand correctly commit cd0b42c2a was only needed because Chris was trying to add DT support for ULPI, which never got merged into mainline. If we use the generic nop usb phy instead, we should just revert this commit. Any objections? Yes, when this patch got reverted it will probably break usb support on mx6 machines. We have seen different behaviour on several mxc/mxs machines regarding the order of PORTSC and phy configuration. We will probably need to test all platforms before reordering this function call again and again for every machine using this driver. Regards, Michael -- 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 v3 3/4] USB: ohci-pxa27x: Add support for external vbus regulators
On Wed, 16 Apr 2014, Laurent Pinchart wrote:
Override the hub control operation to enable and disable external
regulators for the ports vbus power supply in response to clear/set
USB_PORT_FEAT_POWER requests.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
@@ -417,6 +467,16 @@ int usb_hcd_pxa27x_probe (const struct hc_driver
*driver, struct platform_device
pxa_ohci-clk = usb_clk;
pxa_ohci-mmio_base = (void __iomem *)hcd-regs;
+ for (i = 0; i 3; ++i) {
+ char name[6];
+
+ if (!(inf-flags (ENABLE_PORT1 i)))
+ continue;
+
+ sprintf(name, vbus%u, i + 1);
+ pxa_ohci-vbus[i] = devm_regulator_get(pdev-dev, name);
+ }
+
retval = pxa27x_start_hc(pxa_ohci, pdev-dev);
if (retval 0) {
pr_debug(pxa27x_start_hc failed);
@@ -462,6 +522,10 @@ int usb_hcd_pxa27x_probe (const struct hc_driver
*driver, struct platform_device
void usb_hcd_pxa27x_remove (struct usb_hcd *hcd, struct platform_device
*pdev)
{
struct pxa27x_ohci *pxa_ohci = to_pxa27x_ohci(hcd);
+ unsigned int i;
+
+ for (i = 0; i 3; ++i)
+ pxa27x_ohci_set_vbus_power(pxa_ohci, i, false);
usb_remove_hcd(hcd);
pxa27x_stop_hc(pxa_ohci, pdev-dev);
You probably should leave the port power enabled until after
usb_remove_hcd() returns. Apart from that,
Acked-by: Alan Stern st...@rowland.harvard.edu
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] phy: core: make NULL a valid phy reference if !CONFIG_GENERIC_PHY
On Wed, Apr 16, 2014 at 02:48:21PM +0300, Grygorii Strashko wrote: This fixes a regression on Keystone 2 platforms caused by patch 57303488cd37da58263e842de134dc65f7c626d5 usb: dwc3: adapt dwc3 core to use Generic PHY Framework which adds optional support of generic phy in DWC3 core. On Keystone 2 platforms the USB is not working now because CONFIG_GENERIC_PHY isn't set and, as result, Generic PHY APIs stubs return -ENOSYS always. The log shows: dwc3 269.dwc3: failed to initialize core dwc3: probe of 269.dwc3 failed with error -38 Hence, fix it by making NULL a valid phy reference in Generic PHY APIs stubs in the same way as it was done by the patch 04c2facad8fee66c981a51852806d8923336f362 drivers: phy: Make NULL a valid phy reference. CC: Kishon Vijay Abraham I kis...@ti.com CC: Felipe Balbi ba...@ti.com CC: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com I thought I'd already acked this one... oh well, need more coffee: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: Deadlock v3.10.35 with FTD_SIO usb-serial adapter
It's and AMD Geode single board computer, using CS5535 companion chip. Here's the pertaining lspci -vvv section: 00:0f.4 Class 0c03: Device 1022:2094 (rev 02) (prog-if 10) Subsystem: Device 1022:2094 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 11 Region 0: Memory at efffd000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: ohci-pci 00:0f.5 Class 0c03: Device 1022:2095 (rev 02) (prog-if 20) Subsystem: Device 1022:2095 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 11 Region 0: Memory at efffc000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: ehci-pci Il 16/04/2014 16:45, Alan Stern ha scritto: On Tue, 15 Apr 2014, Matteo Fortini wrote: Yes, we tried with 3.14 and after less than 24hrs. What could we do to fix the issue? Thank you, Matteo Here's dmesg output: [103200.145660] INFO: task :2341 blocked for more than 120 seconds. [103200.145774] Not tainted 3.14.0-+ #3 [103200.145844] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [103200.145950] X D de7a 0 2341 2263 0x [103200.146163] de79be5c 00200086 c17d8de0 de7a de79be00 c17d8de0 00200246 c17d8e00 [103200.146357] de79be44 de7a de79bfec de7a c179b560 00200246 c17d8e00 de79be44 [103200.146661] de7a 007b c104eb7e c17d ffcf c154c2d5 de79be44 [103200.146853] Call Trace: [103200.146948] [c104eb7e] ? preempt_count_sub+0xb/0xac [103200.147103] [c154c2d5] ? _raw_spin_unlock_irqrestore+0x27/0x45 [103200.147200] [c154c2df] ? _raw_spin_unlock_irqrestore+0x31/0x45 [103200.147308] [c1055899] ? prepare_to_wait_event+0x60/0xb5 [103200.147432] [c134af26] ? usb_put_dev+0x14/0x16 [103200.147525] [c1548be3] schedule+0x22/0x54 [103200.147611] [c1353ac1] usb_kill_urb+0x51/0x80 A process hanging in usb_kill_urb indicates something is wrong with the host controller driver. Which host controller driver does this device use? 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 v3 3/4] USB: ohci-pxa27x: Add support for external vbus regulators
Hi Alan,
On Wednesday 16 April 2014 11:07:34 Alan Stern wrote:
On Wed, 16 Apr 2014, Laurent Pinchart wrote:
Override the hub control operation to enable and disable external
regulators for the ports vbus power supply in response to clear/set
USB_PORT_FEAT_POWER requests.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
@@ -417,6 +467,16 @@ int usb_hcd_pxa27x_probe (const struct hc_driver
*driver, struct platform_device
pxa_ohci-clk = usb_clk;
pxa_ohci-mmio_base = (void __iomem *)hcd-regs;
+ for (i = 0; i 3; ++i) {
+ char name[6];
+
+ if (!(inf-flags (ENABLE_PORT1 i)))
+ continue;
+
+ sprintf(name, vbus%u, i + 1);
+ pxa_ohci-vbus[i] = devm_regulator_get(pdev-dev, name);
+ }
+
retval = pxa27x_start_hc(pxa_ohci, pdev-dev);
if (retval 0) {
pr_debug(pxa27x_start_hc failed);
@@ -462,6 +522,10 @@ int usb_hcd_pxa27x_probe (const struct hc_driver
*driver, struct platform_device
void usb_hcd_pxa27x_remove (struct usb_hcd *hcd, struct platform_device
*pdev) {
struct pxa27x_ohci *pxa_ohci = to_pxa27x_ohci(hcd);
+ unsigned int i;
+
+ for (i = 0; i 3; ++i)
+ pxa27x_ohci_set_vbus_power(pxa_ohci, i, false);
usb_remove_hcd(hcd);
pxa27x_stop_hc(pxa_ohci, pdev-dev);
You probably should leave the port power enabled until after
usb_remove_hcd() returns. Apart from that,
Acked-by: Alan Stern st...@rowland.harvard.edu
Good point, I'll fix that and submit v4. Thank you.
--
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: USB OTG support on mx27pdk
On Wed, Apr 16, 2014 at 12:03 PM, Michael Grzeschik m...@pengutronix.de wrote: Yes, when this patch got reverted it will probably break usb support on mx6 machines. We have seen different behaviour on several mxc/mxs machines regarding the order of PORTSC and phy configuration. We will probably need to test all platforms before reordering this function call again and again for every machine using this driver. Ok, I managed to fix the issue on mx27 without touching the chipidea driver. Will submit the fix later today. Regards, Fabio Estevam -- 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] ARM: pxa: zeus: Replace OHCI init/exit functions with a regulator
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-pxa/zeus.c | 89 ++--
1 file changed, 48 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index b19d1c3..205f9bf 100644
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -413,7 +413,7 @@ static struct fixed_voltage_config can_regulator_pdata = {
static struct platform_device can_regulator_device = {
.name = reg-fixed-volage,
- .id = -1,
+ .id = 0,
.dev= {
.platform_data = can_regulator_pdata,
},
@@ -510,18 +510,6 @@ struct platform_device zeus_max6369_device = {
.num_resources = 1,
};
-static struct platform_device *zeus_devices[] __initdata = {
- zeus_serial_device,
- zeus_mtd_devices[0],
- zeus_dm9k0_device,
- zeus_dm9k1_device,
- zeus_sram_device,
- zeus_leds_device,
- zeus_pcmcia_device,
- zeus_max6369_device,
- can_regulator_device,
-};
-
/* AC'97 */
static pxa2xx_audio_ops_t zeus_ac97_info = {
.reset_gpio = 95,
@@ -532,44 +520,50 @@ static pxa2xx_audio_ops_t zeus_ac97_info = {
* USB host
*/
-static int zeus_ohci_init(struct device *dev)
-{
- int err;
-
- /* Switch on port 2. */
- if ((err = gpio_request(ZEUS_USB2_PWREN_GPIO, USB2_PWREN))) {
- dev_err(dev, Can't request USB2_PWREN\n);
- return err;
- }
-
- if ((err = gpio_direction_output(ZEUS_USB2_PWREN_GPIO, 1))) {
- gpio_free(ZEUS_USB2_PWREN_GPIO);
- dev_err(dev, Can't enable USB2_PWREN\n);
- return err;
- }
+static struct regulator_consumer_supply zeus_ohci_regulator_supplies[] = {
+ REGULATOR_SUPPLY(vbus2, pxa27x-ohci),
+};
- /* Port 2 is shared between host and client interface. */
- UP2OCR = UP2OCR_HXOE | UP2OCR_HXS | UP2OCR_DMPDE | UP2OCR_DPPDE;
+static struct regulator_init_data zeus_ohci_regulator_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(zeus_ohci_regulator_supplies),
+ .consumer_supplies = zeus_ohci_regulator_supplies,
+};
- return 0;
-}
+static struct fixed_voltage_config zeus_ohci_regulator_config = {
+ .supply_name= vbus2,
+ .microvolts = 500, /* 5.0V */
+ .gpio = ZEUS_USB2_PWREN_GPIO,
+ .enable_high= 1,
+ .startup_delay = 0,
+ .init_data = zeus_ohci_regulator_data,
+};
-static void zeus_ohci_exit(struct device *dev)
-{
- /* Power-off port 2 */
- gpio_direction_output(ZEUS_USB2_PWREN_GPIO, 0);
- gpio_free(ZEUS_USB2_PWREN_GPIO);
-}
+static struct platform_device zeus_ohci_regulator_device = {
+ .name = reg-fixed-voltage,
+ .id = 1,
+ .dev = {
+ .platform_data = zeus_ohci_regulator_config,
+ },
+};
static struct pxaohci_platform_data zeus_ohci_platform_data = {
.port_mode = PMM_NPS_MODE,
/* Clear Power Control Polarity Low and set Power Sense
* Polarity Low. Supply power to USB ports. */
.flags = ENABLE_PORT_ALL | POWER_SENSE_LOW,
- .init = zeus_ohci_init,
- .exit = zeus_ohci_exit,
};
+static void zeus_register_ohci(void)
+{
+ /* Port 2 is shared between host and client interface. */
+ UP2OCR = UP2OCR_HXOE | UP2OCR_HXS | UP2OCR_DMPDE | UP2OCR_DPPDE;
+
+ pxa_set_ohci_info(zeus_ohci_platform_data);
+}
+
/*
* Flat Panel
*/
@@ -677,6 +671,19 @@ static struct pxa2xx_udc_mach_info zeus_udc_info = {
.udc_command = zeus_udc_command,
};
+static struct platform_device *zeus_devices[] __initdata = {
+ zeus_serial_device,
+ zeus_mtd_devices[0],
+ zeus_dm9k0_device,
+ zeus_dm9k1_device,
+ zeus_sram_device,
+ zeus_leds_device,
+ zeus_pcmcia_device,
+ zeus_max6369_device,
+ can_regulator_device,
+ zeus_ohci_regulator_device,
+};
+
#ifdef CONFIG_PM
static void zeus_power_off(void)
{
@@ -847,7 +854,7 @@ static void __init zeus_init(void)
platform_add_devices(zeus_devices, ARRAY_SIZE(zeus_devices));
- pxa_set_ohci_info(zeus_ohci_platform_data);
+ zeus_register_ohci();
if (zeus_setup_fb_gpios())
pr_err(Failed to setup fb gpios\n);
--
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 v4 3/4] USB: ohci-pxa27x: Add support for external vbus regulators
Override the hub control operation to enable and disable external
regulators for the ports vbus power supply in response to clear/set
USB_PORT_FEAT_POWER requests.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ohci-pxa27x.c | 68 ++
1 file changed, 68 insertions(+)
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index d21d5fe..e68f3d0 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -30,6 +30,7 @@
#include linux/platform_data/usb-ohci-pxa27x.h
#include linux/platform_data/usb-pxa3xx-ulpi.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/signal.h
#include linux/usb.h
#include linux/usb/hcd.h
@@ -120,6 +121,8 @@ static struct hc_driver __read_mostly ohci_pxa27x_hc_driver;
struct pxa27x_ohci {
struct clk *clk;
void __iomem*mmio_base;
+ struct regulator *vbus[3];
+ boolvbus_enabled[3];
};
#define to_pxa27x_ohci(hcd)(struct pxa27x_ohci *)(hcd_to_ohci(hcd)-priv)
@@ -166,6 +169,52 @@ static int pxa27x_ohci_select_pmm(struct pxa27x_ohci
*pxa_ohci, int mode)
return 0;
}
+static int pxa27x_ohci_set_vbus_power(struct pxa27x_ohci *pxa_ohci,
+ unsigned int port, bool enable)
+{
+ struct regulator *vbus = pxa_ohci-vbus[port];
+ int ret = 0;
+
+ if (IS_ERR_OR_NULL(vbus))
+ return 0;
+
+ if (enable !pxa_ohci-vbus_enabled[port])
+ ret = regulator_enable(vbus);
+ else if (!enable pxa_ohci-vbus_enabled[port])
+ ret = regulator_disable(vbus);
+
+ if (ret 0)
+ return ret;
+
+ pxa_ohci-vbus_enabled[port] = enable;
+
+ return 0;
+}
+
+static int pxa27x_ohci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
+ u16 wIndex, char *buf, u16 wLength)
+{
+ struct pxa27x_ohci *pxa_ohci = to_pxa27x_ohci(hcd);
+ int ret;
+
+ switch (typeReq) {
+ case SetPortFeature:
+ case ClearPortFeature:
+ if (!wIndex || wIndex 3)
+ return -EPIPE;
+
+ if (wValue != USB_PORT_FEAT_POWER)
+ break;
+
+ ret = pxa27x_ohci_set_vbus_power(pxa_ohci, wIndex - 1,
+typeReq == SetPortFeature);
+ if (ret)
+ return ret;
+ break;
+ }
+
+ return ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+}
/*-*/
static inline void pxa27x_setup_hc(struct pxa27x_ohci *pxa_ohci,
@@ -372,6 +421,7 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver,
struct platform_device
struct ohci_hcd *ohci;
struct resource *r;
struct clk *usb_clk;
+ unsigned int i;
retval = ohci_pxa_of_init(pdev);
if (retval)
@@ -417,6 +467,16 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver,
struct platform_device
pxa_ohci-clk = usb_clk;
pxa_ohci-mmio_base = (void __iomem *)hcd-regs;
+ for (i = 0; i 3; ++i) {
+ char name[6];
+
+ if (!(inf-flags (ENABLE_PORT1 i)))
+ continue;
+
+ sprintf(name, vbus%u, i + 1);
+ pxa_ohci-vbus[i] = devm_regulator_get(pdev-dev, name);
+ }
+
retval = pxa27x_start_hc(pxa_ohci, pdev-dev);
if (retval 0) {
pr_debug(pxa27x_start_hc failed);
@@ -462,9 +522,14 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver,
struct platform_device
void usb_hcd_pxa27x_remove (struct usb_hcd *hcd, struct platform_device *pdev)
{
struct pxa27x_ohci *pxa_ohci = to_pxa27x_ohci(hcd);
+ unsigned int i;
usb_remove_hcd(hcd);
pxa27x_stop_hc(pxa_ohci, pdev-dev);
+
+ for (i = 0; i 3; ++i)
+ pxa27x_ohci_set_vbus_power(pxa_ohci, i, false);
+
usb_put_hcd(hcd);
}
@@ -563,7 +628,10 @@ static int __init ohci_pxa27x_init(void)
return -ENODEV;
pr_info(%s: DRIVER_DESC \n, hcd_name);
+
ohci_init_driver(ohci_pxa27x_hc_driver, pxa27x_overrides);
+ ohci_pxa27x_hc_driver.hub_control = pxa27x_ohci_hub_control;
+
return platform_driver_register(ohci_hcd_pxa27x_driver);
}
module_init(ohci_pxa27x_init);
--
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 v4 1/4] USB: OHCI: Export the OHCI hub control and status_data functions
Platform drivers sometimes need to perform specific handling of hub
control requests and status data. Make this possible by exporting the
ohci_hub_control() and ohci_hub_status_data() functions which can then
be called from custom hub operations in the default case.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ohci-at91.c| 11 ++-
drivers/usb/host/ohci-hub.c | 8
drivers/usb/host/ohci-s3c2410.c | 13 +++--
drivers/usb/host/ohci.h | 3 +++
4 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 091ae49..e49eb4f 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -46,9 +46,6 @@ static const char hcd_name[] = ohci-atmel;
static struct hc_driver __read_mostly ohci_at91_hc_driver;
static int clocked;
-static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq,
- u16 wValue, u16 wIndex, char *buf, u16 wLength);
-static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
extern int usb_disabled(void);
@@ -262,7 +259,7 @@ static int ohci_at91_usb_get_power(struct at91_usbh_data
*pdata, int port)
static int ohci_at91_hub_status_data(struct usb_hcd *hcd, char *buf)
{
struct at91_usbh_data *pdata = hcd-self.controller-platform_data;
- int length = orig_ohci_hub_status_data(hcd, buf);
+ int length = ohci_hub_status_data(hcd, buf);
int port;
at91_for_each_port(port) {
@@ -340,8 +337,7 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
break;
}
- ret = orig_ohci_hub_control(hcd, typeReq, wValue, wIndex + 1,
- buf, wLength);
+ ret = ohci_hub_control(hcd, typeReq, wValue, wIndex + 1, buf, wLength);
if (ret)
goto out;
@@ -690,9 +686,6 @@ static int __init ohci_at91_init(void)
* too easy.
*/
- orig_ohci_hub_control = ohci_at91_hc_driver.hub_control;
- orig_ohci_hub_status_data = ohci_at91_hc_driver.hub_status_data;
-
ohci_at91_hc_driver.hub_status_data = ohci_at91_hub_status_data;
ohci_at91_hc_driver.hub_control = ohci_at91_hub_control;
diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
index c81c872..3d53208 100644
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -438,8 +438,7 @@ static int ohci_root_hub_state_changes(struct ohci_hcd
*ohci, int changed,
/* build status change packet (one or two bytes) from HC registers */
-static int
-ohci_hub_status_data (struct usb_hcd *hcd, char *buf)
+int ohci_hub_status_data(struct usb_hcd *hcd, char *buf)
{
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
int i, changed = 0, length = 1;
@@ -504,6 +503,7 @@ done:
return changed ? length : 0;
}
+EXPORT_SYMBOL_GPL(ohci_hub_status_data);
/*-*/
@@ -646,7 +646,7 @@ static inline int root_port_reset (struct ohci_hcd *ohci,
unsigned port)
return 0;
}
-static int ohci_hub_control (
+int ohci_hub_control(
struct usb_hcd *hcd,
u16 typeReq,
u16 wValue,
@@ -772,4 +772,4 @@ error:
}
return retval;
}
-
+EXPORT_SYMBOL_GPL(ohci_hub_control);
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index ff7c8f1..3d753a9 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -45,10 +45,6 @@ static struct clk *usb_clk;
/* forward definitions */
-static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq,
- u16 wValue, u16 wIndex, char *buf, u16 wLength);
-static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
-
static void s3c2410_hcd_oc(struct s3c2410_hcd_info *info, int port_oc);
/* conversion functions */
@@ -110,7 +106,7 @@ ohci_s3c2410_hub_status_data(struct usb_hcd *hcd, char *buf)
int orig;
int portno;
- orig = orig_ohci_hub_status_data(hcd, buf);
+ orig = ohci_hub_status_data(hcd, buf);
if (info == NULL)
return orig;
@@ -181,7 +177,7 @@ static int ohci_s3c2410_hub_control(
* process the request straight away and exit */
if (info == NULL) {
- ret = orig_ohci_hub_control(hcd, typeReq, wValue,
+ ret = ohci_hub_control(hcd, typeReq, wValue,
wIndex, buf, wLength);
goto out;
}
@@ -231,7 +227,7 @@ static int ohci_s3c2410_hub_control(
break;
}
- ret = orig_ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+ ret = ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
if
[PATCH v4 2/4] USB: EHCI: Export the ehci_hub_control function
Platform drivers sometimes need to perform specific handling of hub
control requests. Make this possible by exporting the ehci_hub_control()
function which can then be called from a custom hub control handler in
the default case.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-hub.c | 12 ++--
drivers/usb/host/ehci-tegra.c | 8 +---
drivers/usb/host/ehci.h | 3 +++
3 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 7ae0c4d..cc305c7 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -33,15 +33,6 @@
#ifdef CONFIG_PM
-static int ehci_hub_control(
- struct usb_hcd *hcd,
- u16 typeReq,
- u16 wValue,
- u16 wIndex,
- char*buf,
- u16 wLength
-);
-
static int persist_enabled_on_companion(struct usb_device *udev, void *unused)
{
return !udev-maxchild udev-persist_enabled
@@ -865,7 +856,7 @@ cleanup:
#endif /* CONFIG_USB_HCD_TEST_MODE */
/*-*/
-static int ehci_hub_control (
+int ehci_hub_control(
struct usb_hcd *hcd,
u16 typeReq,
u16 wValue,
@@ -1285,6 +1276,7 @@ error_exit:
spin_unlock_irqrestore (ehci-lock, flags);
return retval;
}
+EXPORT_SYMBOL_GPL(ehci_hub_control);
static void ehci_relinquish_port(struct usb_hcd *hcd, int portnum)
{
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index af28b74..f64653f 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -55,10 +55,6 @@ struct tegra_ehci_soc_config {
bool has_hostpc;
};
-static int (*orig_hub_control)(struct usb_hcd *hcd,
- u16 typeReq, u16 wValue, u16 wIndex,
- char *buf, u16 wLength);
-
struct tegra_ehci_hcd {
struct tegra_usb_phy *phy;
struct clk *clk;
@@ -240,7 +236,7 @@ static int tegra_ehci_hub_control(
spin_unlock_irqrestore(ehci-lock, flags);
/* Handle the hub control events here */
- return orig_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+ return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
done:
spin_unlock_irqrestore(ehci-lock, flags);
@@ -535,8 +531,6 @@ static int __init ehci_tegra_init(void)
* too easy.
*/
- orig_hub_control = tegra_ehci_hc_driver.hub_control;
-
tegra_ehci_hc_driver.map_urb_for_dma = tegra_ehci_map_urb_for_dma;
tegra_ehci_hc_driver.unmap_urb_for_dma = tegra_ehci_unmap_urb_for_dma;
tegra_ehci_hc_driver.hub_control = tegra_ehci_hub_control;
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 9dfc6c1..eee228a 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -872,4 +872,7 @@ extern int ehci_suspend(struct usb_hcd *hcd, bool
do_wakeup);
extern int ehci_resume(struct usb_hcd *hcd, bool hibernated);
#endif /* CONFIG_PM */
+extern int ehci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
+u16 wIndex, char *buf, u16 wLength);
+
#endif /* __LINUX_EHCI_HCD_H */
--
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 v4 0/4] Allow OHCI/EHCI drivers to override more hub operations
Hello, The PXA27x OHCI implementation doesn't perform automatic control of port power supplies for all ports. While the PPS and LSDA bits of the HcRhPortStatus register are implemented, only a subset of ports have an external power enable pin controlled by the port status register. Other ports need their power supply to be controlled manually. In order to do so I've implemented manual regulator control in the ohci-pxa27x driver. This requires overriding the default behaviour of the CLEAR_FEATURE and SET_FEATURE requests for USB_PORT_FEAT_POWER with a custom hub control operation. In turn this requires calling the currently static ohci_hub_control function from the ohci-pxa27x driver. The ohci-at91 and ohci-s3c2410 drivers already implement a similar feature, and access the ohci_hub_control and ohci_hub_status_data functions by saving the struct hc_driver hub_control and hub_status_data values to a variables right after calling ohci_init_driver. This vtable-like implementation can be optimized by exporting the ohci_hub_control and ohci_hub_status_data functions and calling them directly. As the ohci-pxa27x driver needs to override hub control operations as well I've decided to export the functions. For the sake of completeness I've also exported the ehci_hub_control function and modified the ehci-tegra driver to call it directly. As a side note regarding the ohci-at91 driver, the atmel,vbus-gpio DT property should really have referenced a regulator instead of a GPIO. Fixing this in a backward-compatible way would be messy Please note that I haven't been able to test the third and fourth patches due to lack of hardware. I've however tested a similar implementation for OHCI on an out of tree PXA270 board. Changes compared to v3: - Turn vbus off only after removing the hcd in ohci-pxa27x - Added Alan Stern's acked-by for patches 1 to 3 Changes compared to v2: - Export ohci_hub_status_data() - Call ohci_hub_status_data() directly from ohci-at91 and ohci-s3c2410 Changes compared to v1: - Export ehci_hub_control() - Call ehci_hub_control() directly from ehci-tegra - Call ohci_hub_control() directly from ohci-at91 Laurent Pinchart (4): USB: OHCI: Export the OHCI hub control and status_data functions USB: EHCI: Export the ehci_hub_control function USB: ohci-pxa27x: Add support for external vbus regulators ARM: pxa: zeus: Replace OHCI init/exit functions with a regulator arch/arm/mach-pxa/zeus.c| 89 ++--- drivers/usb/host/ehci-hub.c | 12 +- drivers/usb/host/ehci-tegra.c | 8 +--- drivers/usb/host/ehci.h | 3 ++ drivers/usb/host/ohci-at91.c| 11 + drivers/usb/host/ohci-hub.c | 8 ++-- drivers/usb/host/ohci-pxa27x.c | 68 +++ drivers/usb/host/ohci-s3c2410.c | 13 ++ drivers/usb/host/ohci.h | 3 ++ 9 files changed, 134 insertions(+), 81 deletions(-) -- 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: Deadlock v3.10.35 with FTD_SIO usb-serial adapter
On Wed, 16 Apr 2014, Matteo Fortini wrote: It's and AMD Geode single board computer, using CS5535 companion chip. Here's the pertaining lspci -vvv section: 00:0f.4 Class 0c03: Device 1022:2094 (rev 02) (prog-if 10) Subsystem: Device 1022:2094 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 11 Region 0: Memory at efffd000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: ohci-pci 00:0f.5 Class 0c03: Device 1022:2095 (rev 02) (prog-if 20) Subsystem: Device 1022:2095 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 11 Region 0: Memory at efffc000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: ehci-pci This doesn't answer my question. Which controller was the device attached to when the hang occurred? Was it the EHCI controller or the OHCI controller? If you enable CONFIG_USB_DEBUG, what shows up in the files under the corresponding directory in /sys/kernel/debug/usb/ehci/ or /sys/kernel/debug/usb/ohci/ when the hang occurs? 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
[no subject]
Optimieren Sie Ihren 500,000,00 Euro -- 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 2/4] USB: EHCI: Export the ehci_hub_control function
On 04/16/2014 10:00 AM, Laurent Pinchart wrote: Platform drivers sometimes need to perform specific handling of hub control requests. Make this possible by exporting the ehci_hub_control() function which can then be called from a custom hub control handler in the default case. The Tegra parts, Acked-by: Stephen Warren swar...@nvidia.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvc: update uvc_endpoint_max_bpi to handle USB_SPEED_WIRELESS devices
On Wed, 16 Apr 2014, Laurent Pinchart wrote: Hi Thomas, (CC'ing the linux-usb mailing list) On Tuesday 15 April 2014 16:45:28 Thomas Pugliese wrote: On Tue, 15 Apr 2014, Laurent Pinchart wrote: Hi Thomas, Could you please send me a proper revert patch with the above description in the commit message and CC Mauro Carvalho Chehab m.che...@samsung.com ? Hi Laurent, I can submit a patch to revert but I should make a correction first. I had backported this change to an earlier kernel (2.6.39) which was before super speed support was added and the regression I described was based on that kernel. It was actually the addition of super speed support that broke windows compatible devices. My previous change fixed spec compliant devices but left windows compatible devices broken. Basically, the timeline of changes is this: 1. Prior to the addition of super speed support (commit 6fd90db8df379e215): all WUSB devices were treated as HIGH_SPEED devices. This is how Windows works so Windows compatible devices would work. For spec compliant WUSB devices, the max packet size would be incorrectly calculated which would result in high-bandwidth isoc streams being unable to find an alt setting that provided enough bandwidth. 2. After super speed support: all WUSB devices fell through to the default case of uvc_endpoint_max_bpi which would mask off the upper bits of the max packet size. This broke both WUSB spec compliant and non compliant devices because no endpoint with a large enough bpi would be found. 3. After 79af67e77f86404e77e: Spec compliant devices are fixed but non-spec compliant (although Windows compatible) devices are broken. Basically, this is the opposite of how it worked prior to super speed support. Given that, I can submit a patch to revert 79af67e77f86404e77e but that would go back to having all WUSB devices broken. Alternatively, the change below will revert the behavior back to scenario 1 where Windows compatible devices work but strictly spec complaint devices may not. I can send a proper patch for whichever scenario you prefer. Thank you for the explanation. Reverting 79af67e77f86404e77e doesn't seem like a very good idea, given that all WUSB devices will be broken. We thus have two options: - leaving the code as-is, with support for spec-compliant WUSB devices but not for microsoft-specific devices - applying the patch below, with support for microsoft-specific USB devices but not for spec-compliant devices This isn't the first time this kind of situation occurs. Microsoft didn't support multiple configurations before Windows 8, making vendors come up with lots of creative MS-specific solutions. I consider those devices non USB compliant, and they should not be allowed to use the USB logo, but that would require a strong political move from the USB Implementers Forum which is more or less controlled by Microsoft... Welcome to the USB mafia. Anyway, I have no experience with WUSB devices, so I don't know what's more common in the wild. What would you suggest ? I think that almost all current devices support the Windows/USB 2.0 format rather than stricty follow the WUSB spec. Even the prototype device that I initially used to test UVC with Wireless USB has been updated to use the USB 2.0 format prior to shipping in order to remain compatible with Windows. That being said, these devices are not very common at all in the consumer market. They are mostly used in embedded/industrial settings so that may factor in as to which direction you want to go. Would there be a way to support both categories of devices ? As you had mentioned previously, it should be possible to support both formats by ignoring the endpoint descriptor and looking at the bMaxBurst, bOverTheAirInterval and wOverTheAirPacketSize fields in the WUSB endpoint companion descriptor. That is a more involved change to the UVC driver and also would require changes to USB core to store the WUSB endpoint companion descriptor in struct usb_host_endpoint similar to what is done for super speed devices. Regards, Thomas -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] usb: gadget: Add xilinx axi usb2 device support
Hi,
On Wed, Apr 16, 2014 at 04:09:28PM +0530, sundeep subbaraya wrote:
Hi Felipe,
On Thu, Apr 3, 2014 at 8:28 PM, Felipe Balbi ba...@ti.com wrote:
+static int start_dma(struct xusb_ep *ep, u32 src, u32 dst, u32 length)
please prepend this with xudc_, it makes tracing a lot easier.
+{
+ struct xusb_udc *udc;
+ int rc = 0;
+ unsigned long timeout;
+
+ udc = ep-udc;
+ /*
+ * Set the addresses in the DMA source and
+ * destination registers and then set the length
+ * into the DMA length register.
+ */
+ udc-write_fn(udc-base_address, XUSB_DMA_DSAR_ADDR_OFFSET, src);
+ udc-write_fn(udc-base_address, XUSB_DMA_DDAR_ADDR_OFFSET, dst);
+ udc-write_fn(udc-base_address, XUSB_DMA_LENGTH_OFFSET, length);
+
+ /*
+ * Wait till DMA transaction is complete and
+ * check whether the DMA transaction was
+ * successful.
+ */
+ while ((udc-read_fn(ep-udc-base_address + XUSB_DMA_STATUS_OFFSET)
+ XUSB_DMA_DMASR_BUSY) == XUSB_DMA_DMASR_BUSY) {
+ timeout = jiffies + 1;
+
+ if (time_after(jiffies, timeout)) {
+ rc = -ETIMEDOUT;
+ goto clean;
+ }
+ }
don't you get an IRQ for DMA completion ? If you do, you could be using
wait_for_completion()
This function is called in interrupt context when buffer is ready or
free. It initiates DMA to transfer data from IP buffer to memory.
Hence it waits in busy loop till DMA completes
wait, so you start_dma() before your gadget driver asks you to ?
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH v2 2/2] usb: gadget: Add xilinx axi usb2 device support
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of sundeep subbaraya
Sent: Wednesday, April 16, 2014 3:39 AM
Hi Felipe,
On Thu, Apr 3, 2014 at 8:28 PM, Felipe Balbi ba...@ti.com wrote:
+static int start_dma(struct xusb_ep *ep, u32 src, u32 dst, u32 length)
please prepend this with xudc_, it makes tracing a lot easier.
+{
+ struct xusb_udc *udc;
+ int rc = 0;
+ unsigned long timeout;
+
+ udc = ep-udc;
+ /*
+ * Set the addresses in the DMA source and
+ * destination registers and then set the length
+ * into the DMA length register.
+ */
+ udc-write_fn(udc-base_address, XUSB_DMA_DSAR_ADDR_OFFSET, src);
+ udc-write_fn(udc-base_address, XUSB_DMA_DDAR_ADDR_OFFSET, dst);
+ udc-write_fn(udc-base_address, XUSB_DMA_LENGTH_OFFSET, length);
+
+ /*
+ * Wait till DMA transaction is complete and
+ * check whether the DMA transaction was
+ * successful.
+ */
+ while ((udc-read_fn(ep-udc-base_address + XUSB_DMA_STATUS_OFFSET)
+ XUSB_DMA_DMASR_BUSY) == XUSB_DMA_DMASR_BUSY) {
+ timeout = jiffies + 1;
+
+ if (time_after(jiffies, timeout)) {
+ rc = -ETIMEDOUT;
+ goto clean;
+ }
+ }
don't you get an IRQ for DMA completion ? If you do, you could be using
wait_for_completion()
This function is called in interrupt context when buffer is ready or
free. It initiates
DMA to transfer data from IP buffer to memory. Hence it waits in busy
loop till DMA
completes
If this function is called in interrupt context, then you can't use
jiffies for your timeout, since jiffies may not get updated while in
interrupt context.
--
Paul
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: move ZTE CDMA device pid from zte_ev.c back to option.c
On Tue, Apr 08, 2014 at 07:59:28PM +0800, 刘磊 wrote:
dear linuxfoundation:
I'm not sure if you receive our mails in lase week , i resend it now.
Please confirm whether it is correct format for submit.
Looking forward to your reply.
modify reason:
1. Move device pid fffe from zte_ev.c back to option.c for our company.
2. Modify the parameter from 0x0003 to 0x. the problem may cause the
device can not be close.
these two points are in the patch, please submit it for me. thanks.
Signed-off-by:lei liuliu.le...@zte.com.cn
diff -u -r drivers-old/usb/serial/option.c drivers/usb/serial/option.c
--- drivers-old/usb/serial/option.c 2014-03-24 12:45:42.0 +0800
+++ drivers/usb/serial/option.c 2014-03-26 15:13:02.232956251 +0800
@@ -1462,6 +1462,7 @@
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff92, 0xff, 0xff,
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff93, 0xff, 0xff,
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff94, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffe, 0xff, 0xff,
0xff) },
/* NOTE: most ZTE CDMA devices should be driven by zte_ev, not option */
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718,
0xff, 0xff, 0xff),
diff -u -r drivers-old/usb/serial/zte_ev.c drivers/usb/serial/zte_ev.c
--- drivers-old/usb/serial/zte_ev.c 2014-03-24 12:45:42.0 +0800
+++ drivers/usb/serial/zte_ev.c 2014-03-26 16:08:52.916827643 +0800
@@ -258,12 +258,12 @@
/* send 8 cmd */
/*
- * 16.0 CTL 21 22 03 00 00 00 00 00
+ * 16.0 CTL 21 22 00 00 00 00 00 00
*/
len = 0;
result = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
0x22, 0x21,
- 0x0003, 0x, NULL, len,
+ 0x, 0x, NULL, len,
USB_CTRL_GET_TIMEOUT);
dev_dbg(dev, result = %d\n, result);
@@ -276,7 +276,6 @@
/* AC8710, AC8710T */
{ USB_DEVICE_AND_INTERFACE_INFO(0x19d2, 0x, 0xff, 0xff, 0xff) },
/* AC8700 */
- { USB_DEVICE_AND_INTERFACE_INFO(0x19d2, 0xfffe, 0xff, 0xff, 0xff) },
/* MG880 */
{ USB_DEVICE(0x19d2, 0xfffd) },
{ USB_DEVICE(0x19d2, 0xfffc) },
thanks.
lei liu
This patch doesn't apply to the tree at all, sorry. Please read
Documentation/SubmittingPatches for how to do this, and make it against
the 3.15-rc1 kernel release and resend.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] usb: generic cleanup patches
Hi folks,
I have been playing with following patches today and
I think they're ready to be queued up for v3.16 but
I wanted to get some comments/test results before
I apply them to my 'next' branch.
Thanks
Felipe Balbi (8):
usb: dwc3: gadget: clear stall when disabling endpoint
usb: dwc3: core: refactor PHY initialization
usb: dwc3: core: refactor mode initialization to its own function
usb: gadget: only GPL drivers in the gadget and phy framework
usb: phy: rename usb_nop_xceiv to usb_phy_generic
usb: phy: rename linux/usb/usb_phy_gen_xceiv.h to
linux/usb/usb_phy_generic.h
usb: musb: move usb_phy_generic_{un,}register calls to
probe()/remove()
usb: phy: generic: allow multiples calls to usb_phy_generic_register()
drivers/usb/dwc3/core.c| 253 +++--
drivers/usb/dwc3/dwc3-exynos.c | 8 +-
drivers/usb/dwc3/dwc3-pci.c| 8 +-
drivers/usb/dwc3/gadget.c | 4 +
drivers/usb/gadget/configfs.c | 2 +-
drivers/usb/gadget/f_fs.c | 6 +-
drivers/usb/gadget/f_rndis.c | 2 +-
drivers/usb/gadget/rndis.c | 28 +--
drivers/usb/gadget/storage_common.c| 52 ++---
drivers/usb/gadget/u_ether.c | 32 +--
drivers/usb/gadget/u_f.c | 2 +-
drivers/usb/musb/am35x.c | 14 +-
drivers/usb/musb/blackfin.c| 14 +-
drivers/usb/musb/da8xx.c | 16 +-
drivers/usb/musb/davinci.c | 8 +-
drivers/usb/musb/musb_dsps.c | 2 +-
drivers/usb/musb/tusb6010.c| 8 +-
drivers/usb/phy/phy-am335x.c | 4 +-
drivers/usb/phy/phy-generic.c | 65 +++---
drivers/usb/phy/phy-generic.h | 8 +-
drivers/usb/phy/phy-keystone.c | 4 +-
.../usb/{usb_phy_gen_xceiv.h = usb_phy_generic.h} | 10 +-
22 files changed, 289 insertions(+), 261 deletions(-)
rename include/linux/usb/{usb_phy_gen_xceiv.h = usb_phy_generic.h} (62%)
--
1.9.2.459.g68773ac
--
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 5/8] usb: phy: rename usb_nop_xceiv to usb_phy_generic
no functional changes, just renaming the function
in order to make it slightly clearer what it should
be used for, also matching the driver name.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-exynos.c| 6 ++---
drivers/usb/dwc3/dwc3-pci.c | 6 ++---
drivers/usb/musb/am35x.c | 4 +--
drivers/usb/musb/blackfin.c | 4 +--
drivers/usb/musb/da8xx.c | 4 +--
drivers/usb/musb/davinci.c| 6 ++---
drivers/usb/musb/tusb6010.c | 6 ++---
drivers/usb/phy/phy-am335x.c | 2 +-
drivers/usb/phy/phy-generic.c | 50 +--
drivers/usb/phy/phy-generic.h | 6 ++---
drivers/usb/phy/phy-keystone.c| 2 +-
include/linux/usb/usb_phy_gen_xceiv.h | 10 +++
12 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 28c8ad7..821cc59 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -38,13 +38,13 @@ struct dwc3_exynos {
static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
{
- struct usb_phy_gen_xceiv_platform_data pdata;
+ struct usb_phy_generic_platform_data pdata;
struct platform_device *pdev;
int ret;
memset(pdata, 0x00, sizeof(pdata));
- pdev = platform_device_alloc(usb_phy_gen_xceiv, PLATFORM_DEVID_AUTO);
+ pdev = platform_device_alloc(usb_phy_generic, PLATFORM_DEVID_AUTO);
if (!pdev)
return -ENOMEM;
@@ -56,7 +56,7 @@ static int dwc3_exynos_register_phys(struct dwc3_exynos
*exynos)
if (ret)
goto err1;
- pdev = platform_device_alloc(usb_phy_gen_xceiv, PLATFORM_DEVID_AUTO);
+ pdev = platform_device_alloc(usb_phy_generic, PLATFORM_DEVID_AUTO);
if (!pdev) {
ret = -ENOMEM;
goto err1;
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index f393c18..8b162f0 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -40,13 +40,13 @@ struct dwc3_pci {
static int dwc3_pci_register_phys(struct dwc3_pci *glue)
{
- struct usb_phy_gen_xceiv_platform_data pdata;
+ struct usb_phy_generic_platform_data pdata;
struct platform_device *pdev;
int ret;
memset(pdata, 0x00, sizeof(pdata));
- pdev = platform_device_alloc(usb_phy_gen_xceiv, 0);
+ pdev = platform_device_alloc(usb_phy_generic, 0);
if (!pdev)
return -ENOMEM;
@@ -58,7 +58,7 @@ static int dwc3_pci_register_phys(struct dwc3_pci *glue)
if (ret)
goto err1;
- pdev = platform_device_alloc(usb_phy_gen_xceiv, 1);
+ pdev = platform_device_alloc(usb_phy_generic, 1);
if (!pdev) {
ret = -ENOMEM;
goto err1;
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index b3aa018..77ed664 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -360,7 +360,7 @@ static int am35x_musb_init(struct musb *musb)
if (!rev)
return -ENODEV;
- usb_nop_xceiv_register();
+ usb_phy_generic_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
return -EPROBE_DEFER;
@@ -402,7 +402,7 @@ static int am35x_musb_exit(struct musb *musb)
data-set_phy_power(0);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_phy_generic_unregister();
return 0;
}
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 796677f..607f3ae 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -401,7 +401,7 @@ static int bfin_musb_init(struct musb *musb)
}
gpio_direction_output(musb-config-gpio_vrsel, 0);
- usb_nop_xceiv_register();
+ usb_phy_generic_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
gpio_free(musb-config-gpio_vrsel);
@@ -426,7 +426,7 @@ static int bfin_musb_exit(struct musb *musb)
gpio_free(musb-config-gpio_vrsel);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_phy_generic_unregister();
return 0;
}
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index e3486de..bcdce8e 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -418,7 +418,7 @@ static int da8xx_musb_init(struct musb *musb)
if (!rev)
goto fail;
- usb_nop_xceiv_register();
+ usb_phy_generic_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
ret = -EPROBE_DEFER;
@@ -453,7 +453,7 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
[PATCH 2/8] usb: dwc3: core: refactor PHY initialization
our probe() routine is too large and we can
easily refactor PHY-related code out to another
function to make it slightly less painful to read.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/core.c | 120 ++--
1 file changed, 66 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index d001417..38976f3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -486,70 +486,20 @@ static void dwc3_core_exit(struct dwc3 *dwc)
phy_exit(dwc-usb3_generic_phy);
}
-#define DWC3_ALIGN_MASK(16 - 1)
-
-static int dwc3_probe(struct platform_device *pdev)
+static int dwc3_core_get_phy(struct dwc3 *dwc)
{
- struct device *dev = pdev-dev;
- struct dwc3_platform_data *pdata = dev_get_platdata(dev);
+ struct device *dev = dwc-dev;
struct device_node *node = dev-of_node;
- struct resource *res;
- struct dwc3 *dwc;
-
- int ret = -ENOMEM;
-
- void __iomem*regs;
- void*mem;
-
- mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL);
- if (!mem) {
- dev_err(dev, not enough memory\n);
- return -ENOMEM;
- }
- dwc = PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1);
- dwc-mem = mem;
-
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!res) {
- dev_err(dev, missing IRQ\n);
- return -ENODEV;
- }
- dwc-xhci_resources[1].start = res-start;
- dwc-xhci_resources[1].end = res-end;
- dwc-xhci_resources[1].flags = res-flags;
- dwc-xhci_resources[1].name = res-name;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, missing memory resource\n);
- return -ENODEV;
- }
+ int ret;
if (node) {
- dwc-maximum_speed = of_usb_get_maximum_speed(node);
-
dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
-
- dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
- dwc-dr_mode = of_usb_get_dr_mode(node);
- } else if (pdata) {
- dwc-maximum_speed = pdata-maximum_speed;
-
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
-
- dwc-needs_fifo_resize = pdata-tx_fifo_resize;
- dwc-dr_mode = pdata-dr_mode;
} else {
dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
- /* default to superspeed if no maximum_speed passed */
- if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
- dwc-maximum_speed = USB_SPEED_SUPER;
-
if (IS_ERR(dwc-usb2_phy)) {
ret = PTR_ERR(dwc-usb2_phy);
if (ret == -ENXIO || ret == -ENODEV) {
@@ -600,6 +550,69 @@ static int dwc3_probe(struct platform_device *pdev)
}
}
+ return 0;
+}
+
+#define DWC3_ALIGN_MASK(16 - 1)
+
+static int dwc3_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct dwc3_platform_data *pdata = dev_get_platdata(dev);
+ struct device_node *node = dev-of_node;
+ struct resource *res;
+ struct dwc3 *dwc;
+
+ int ret = -ENOMEM;
+
+ void __iomem*regs;
+ void*mem;
+
+ mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL);
+ if (!mem) {
+ dev_err(dev, not enough memory\n);
+ return -ENOMEM;
+ }
+ dwc = PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1);
+ dwc-mem = mem;
+ dwc-dev = dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!res) {
+ dev_err(dev, missing IRQ\n);
+ return -ENODEV;
+ }
+ dwc-xhci_resources[1].start = res-start;
+ dwc-xhci_resources[1].end = res-end;
+ dwc-xhci_resources[1].flags = res-flags;
+ dwc-xhci_resources[1].name = res-name;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(dev, missing memory resource\n);
+ return -ENODEV;
+ }
+
+ if (node) {
+ dwc-maximum_speed = of_usb_get_maximum_speed(node);
+
+ dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
+ dwc-dr_mode = of_usb_get_dr_mode(node);
+ } else if (pdata) {
+ dwc-maximum_speed = pdata-maximum_speed;
+
+ dwc-needs_fifo_resize
[PATCH 1/8] usb: dwc3: gadget: clear stall when disabling endpoint
so it seems like DWC3 IP doesn't clear stalls automatically when we disable an endpoint, because of that, we _must_ make sure stalls are cleared before clearing the proper bit in DALEPENA register. Cc: sta...@vger.kernel.org # v3.4+ Reported-by: Johannes Stezenbach j...@sig21.net Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/dwc3/gadget.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index a740eac..f0dc0ee 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -608,6 +608,10 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep) dwc3_remove_requests(dwc, dep); + /* make sure HW endpoint isn't stalled */ + if (dep-flags DWC3_EP_STALL) + __dwc3_gadget_ep_set_halt(dep, 0); + reg = dwc3_readl(dwc-regs, DWC3_DALEPENA); reg = ~DWC3_DALEPENA_EP(dep-number); dwc3_writel(dwc-regs, DWC3_DALEPENA, reg); -- 1.9.2.459.g68773ac -- 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 6/8] usb: phy: rename linux/usb/usb_phy_gen_xceiv.h to linux/usb/usb_phy_generic.h
now that all functions match the driver name,
the only missing piece is to rename the header
file itself.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-exynos.c | 2 +-
drivers/usb/dwc3/dwc3-pci.c | 2 +-
drivers/usb/musb/am35x.c | 2 +-
drivers/usb/musb/blackfin.c | 2 +-
drivers/usb/musb/da8xx.c | 2 +-
drivers/usb/musb/davinci.c | 2 +-
drivers/usb/musb/musb_dsps.c | 2 +-
drivers/usb/musb/tusb6010.c | 2 +-
drivers/usb/phy/phy-am335x.c | 2 +-
drivers/usb/phy/phy-generic.c| 2 +-
drivers/usb/phy/phy-generic.h| 2 +-
drivers/usb/phy/phy-keystone.c | 2 +-
include/linux/usb/{usb_phy_gen_xceiv.h = usb_phy_generic.h} | 0
13 files changed, 12 insertions(+), 12 deletions(-)
rename include/linux/usb/{usb_phy_gen_xceiv.h = usb_phy_generic.h} (100%)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 821cc59..ed22d72 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -24,7 +24,7 @@
#include linux/dma-mapping.h
#include linux/clk.h
#include linux/usb/otg.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
#include linux/of.h
#include linux/of_platform.h
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 8b162f0..1ed95e0 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -23,7 +23,7 @@
#include linux/platform_device.h
#include linux/usb/otg.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
/* FIXME define these in linux/pci_ids.h */
#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 77ed664..044cd82 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -32,7 +32,7 @@
#include linux/io.h
#include linux/platform_device.h
#include linux/dma-mapping.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
#include linux/platform_data/usb-omap.h
#include musb_core.h
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 607f3ae..c9992a2 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -18,7 +18,7 @@
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/prefetch.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
#include asm/cacheflush.h
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index bcdce8e..a0dabb0 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -32,7 +32,7 @@
#include linux/io.h
#include linux/platform_device.h
#include linux/dma-mapping.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
#include mach/da8xx.h
#include linux/platform_data/usb-davinci.h
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index c0e07ed..7370354 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -32,7 +32,7 @@
#include linux/gpio.h
#include linux/platform_device.h
#include linux/dma-mapping.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
#include mach/cputype.h
#include mach/hardware.h
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 3372ded..1888292 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -35,7 +35,7 @@
#include linux/dma-mapping.h
#include linux/pm_runtime.h
#include linux/module.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
#include linux/platform_data/usb-omap.h
#include linux/sizes.h
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 0c0f5ee..8d4a819 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -24,7 +24,7 @@
#include linux/io.h
#include linux/platform_device.h
#include linux/dma-mapping.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
#include musb_core.h
diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c
index bb866e4..585e50c 100644
--- a/drivers/usb/phy/phy-am335x.c
+++ b/drivers/usb/phy/phy-am335x.c
@@ -2,7 +2,7 @@
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
#include linux/slab.h
#include linux/clk.h
#include linux/regulator/consumer.h
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index e76ca4c..2c49cd8 100644
--- a/drivers/usb/phy/phy-generic.c
+++
[PATCH 4/8] usb: gadget: only GPL drivers in the gadget and phy framework
We only support GPL drivers in the USB Gadget Framework,
it sounds correct to make all exported symbols GPL too.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/configfs.c | 2 +-
drivers/usb/gadget/f_fs.c | 6 ++---
drivers/usb/gadget/f_rndis.c| 2 +-
drivers/usb/gadget/rndis.c | 28 ++--
drivers/usb/gadget/storage_common.c | 52 ++---
drivers/usb/gadget/u_ether.c| 32 +++
drivers/usb/gadget/u_f.c| 2 +-
drivers/usb/phy/phy-generic.c | 4 +--
8 files changed, 64 insertions(+), 64 deletions(-)
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 7d1cc01..dcead55 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1005,7 +1005,7 @@ void unregister_gadget_item(struct config_item *item)
unregister_gadget(gi);
}
-EXPORT_SYMBOL(unregister_gadget_item);
+EXPORT_SYMBOL_GPL(unregister_gadget_item);
static int __init gadget_cfs_init(void)
{
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 2e164dc..a01b3bd 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -190,7 +190,7 @@ ffs_sb_create_file(struct super_block *sb, const char
*name, void *data,
/* Devices management ***/
DEFINE_MUTEX(ffs_lock);
-EXPORT_SYMBOL(ffs_lock);
+EXPORT_SYMBOL_GPL(ffs_lock);
static struct ffs_dev *_ffs_find_dev(const char *name);
static struct ffs_dev *_ffs_alloc_dev(void);
@@ -2876,7 +2876,7 @@ int ffs_name_dev(struct ffs_dev *dev, const char *name)
return ret;
}
-EXPORT_SYMBOL(ffs_name_dev);
+EXPORT_SYMBOL_GPL(ffs_name_dev);
int ffs_single_dev(struct ffs_dev *dev)
{
@@ -2893,7 +2893,7 @@ int ffs_single_dev(struct ffs_dev *dev)
ffs_dev_unlock();
return ret;
}
-EXPORT_SYMBOL(ffs_single_dev);
+EXPORT_SYMBOL_GPL(ffs_single_dev);
/*
* ffs_lock must be taken by the caller of this function
diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
index c11761c..139bc9c 100644
--- a/drivers/usb/gadget/f_rndis.c
+++ b/drivers/usb/gadget/f_rndis.c
@@ -834,7 +834,7 @@ void rndis_borrow_net(struct usb_function_instance *f,
struct net_device *net)
opts-borrowed_net = opts-bound = true;
opts-net = net;
}
-EXPORT_SYMBOL(rndis_borrow_net);
+EXPORT_SYMBOL_GPL(rndis_borrow_net);
static inline struct f_rndis_opts *to_f_rndis_opts(struct config_item *item)
{
diff --git a/drivers/usb/gadget/rndis.c b/drivers/usb/gadget/rndis.c
index d822d82..4c36694 100644
--- a/drivers/usb/gadget/rndis.c
+++ b/drivers/usb/gadget/rndis.c
@@ -760,7 +760,7 @@ int rndis_signal_connect(int configNr)
return rndis_indicate_status_msg(configNr,
RNDIS_STATUS_MEDIA_CONNECT);
}
-EXPORT_SYMBOL(rndis_signal_connect);
+EXPORT_SYMBOL_GPL(rndis_signal_connect);
int rndis_signal_disconnect(int configNr)
{
@@ -769,7 +769,7 @@ int rndis_signal_disconnect(int configNr)
return rndis_indicate_status_msg(configNr,
RNDIS_STATUS_MEDIA_DISCONNECT);
}
-EXPORT_SYMBOL(rndis_signal_disconnect);
+EXPORT_SYMBOL_GPL(rndis_signal_disconnect);
void rndis_uninit(int configNr)
{
@@ -784,13 +784,13 @@ void rndis_uninit(int configNr)
while ((buf = rndis_get_next_response(configNr, length)))
rndis_free_response(configNr, buf);
}
-EXPORT_SYMBOL(rndis_uninit);
+EXPORT_SYMBOL_GPL(rndis_uninit);
void rndis_set_host_mac(int configNr, const u8 *addr)
{
rndis_per_dev_params[configNr].host_mac = addr;
}
-EXPORT_SYMBOL(rndis_set_host_mac);
+EXPORT_SYMBOL_GPL(rndis_set_host_mac);
/*
* Message Parser
@@ -873,7 +873,7 @@ int rndis_msg_parser(u8 configNr, u8 *buf)
return -ENOTSUPP;
}
-EXPORT_SYMBOL(rndis_msg_parser);
+EXPORT_SYMBOL_GPL(rndis_msg_parser);
int rndis_register(void (*resp_avail)(void *v), void *v)
{
@@ -895,7 +895,7 @@ int rndis_register(void (*resp_avail)(void *v), void *v)
return -ENODEV;
}
-EXPORT_SYMBOL(rndis_register);
+EXPORT_SYMBOL_GPL(rndis_register);
void rndis_deregister(int configNr)
{
@@ -904,7 +904,7 @@ void rndis_deregister(int configNr)
if (configNr = RNDIS_MAX_CONFIGS) return;
rndis_per_dev_params[configNr].used = 0;
}
-EXPORT_SYMBOL(rndis_deregister);
+EXPORT_SYMBOL_GPL(rndis_deregister);
int rndis_set_param_dev(u8 configNr, struct net_device *dev, u16 *cdc_filter)
{
@@ -918,7 +918,7 @@ int rndis_set_param_dev(u8 configNr, struct net_device
*dev, u16 *cdc_filter)
return 0;
}
-EXPORT_SYMBOL(rndis_set_param_dev);
+EXPORT_SYMBOL_GPL(rndis_set_param_dev);
int rndis_set_param_vendor(u8 configNr, u32 vendorID, const char *vendorDescr)
{
@@ -931,7 +931,7 @@ int rndis_set_param_vendor(u8 configNr, u32 vendorID, const
char *vendorDescr)
return 0;
}
[PATCH 8/8] usb: phy: generic: allow multiples calls to usb_phy_generic_register()
it's now very easy to return a platform_device pointer
and have the caller pass it as argument when calling
usb_phy_generic_unregister().
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/am35x.c| 12 +---
drivers/usb/musb/blackfin.c | 10 --
drivers/usb/musb/da8xx.c| 14 +++---
drivers/usb/musb/tusb6010.c | 3 ++-
drivers/usb/phy/phy-generic.c | 19 +--
include/linux/usb/usb_phy_generic.h | 8
6 files changed, 39 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 05459b5..0a34dd8 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -85,6 +85,7 @@
struct am35x_glue {
struct device *dev;
struct platform_device *musb;
+ struct platform_device *phy;
struct clk *phy_clk;
struct clk *clk;
};
@@ -503,7 +504,9 @@ static int am35x_probe(struct platform_device *pdev)
pdata-platform_ops = am35x_ops;
- usb_phy_generic_register();
+ glue-phy = usb_phy_generic_register();
+ if (IS_ERR(glue-phy))
+ goto err7;
platform_set_drvdata(pdev, glue);
pinfo = am35x_dev_info;
@@ -517,11 +520,14 @@ static int am35x_probe(struct platform_device *pdev)
if (IS_ERR(musb)) {
ret = PTR_ERR(musb);
dev_err(pdev-dev, failed to register musb device: %d\n,
ret);
- goto err7;
+ goto err8;
}
return 0;
+err8:
+ usb_phy_generic_unregister(glue-phy);
+
err7:
clk_disable(clk);
@@ -546,7 +552,7 @@ static int am35x_remove(struct platform_device *pdev)
struct am35x_glue *glue = platform_get_drvdata(pdev);
platform_device_unregister(glue-musb);
- usb_phy_generic_unregister();
+ usb_phy_generic_unregister(glue-phy);
clk_disable(glue-clk);
clk_disable(glue-phy_clk);
clk_put(glue-clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 53acffe..d40d5f0 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -29,6 +29,7 @@
struct bfin_glue {
struct device *dev;
struct platform_device *musb;
+ struct platform_device *phy;
};
#define glue_to_musb(g)platform_get_drvdata(g-musb)
@@ -475,7 +476,9 @@ static int bfin_probe(struct platform_device *pdev)
pdata-platform_ops = bfin_ops;
- usb_phy_generic_register();
+ glue-phy = usb_phy_generic_register();
+ if (IS_ERR(glue-phy))
+ goto err2;
platform_set_drvdata(pdev, glue);
memset(musb_resources, 0x00, sizeof(*musb_resources) *
@@ -513,6 +516,9 @@ static int bfin_probe(struct platform_device *pdev)
return 0;
err3:
+ usb_phy_generic_unregister(glue-phy);
+
+err2:
platform_device_put(musb);
err1:
@@ -527,7 +533,7 @@ static int bfin_remove(struct platform_device *pdev)
struct bfin_glue*glue = platform_get_drvdata(pdev);
platform_device_unregister(glue-musb);
- usb_phy_generic_unregister();
+ usb_phy_generic_unregister(glue-phy);
kfree(glue);
return 0;
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 024751f..058775e 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -85,6 +85,7 @@
struct da8xx_glue {
struct device *dev;
struct platform_device *musb;
+ struct platform_device *phy;
struct clk *clk;
};
@@ -510,7 +511,11 @@ static int da8xx_probe(struct platform_device *pdev)
pdata-platform_ops = da8xx_ops;
- usb_phy_generic_register();
+ glue-phy = usb_phy_generic_register();
+ if (IS_ERR(glue-phy)) {
+ ret = PTR_ERR(glue-phy);
+ goto err5;
+ }
platform_set_drvdata(pdev, glue);
memset(musb_resources, 0x00, sizeof(*musb_resources) *
@@ -537,11 +542,14 @@ static int da8xx_probe(struct platform_device *pdev)
if (IS_ERR(musb)) {
ret = PTR_ERR(musb);
dev_err(pdev-dev, failed to register musb device: %d\n,
ret);
- goto err5;
+ goto err6;
}
return 0;
+err6:
+ usb_phy_generic_unregister(glue-phy);
+
err5:
clk_disable(clk);
@@ -560,7 +568,7 @@ static int da8xx_remove(struct platform_device *pdev)
struct da8xx_glue *glue = platform_get_drvdata(pdev);
platform_device_unregister(glue-musb);
- usb_phy_generic_unregister();
+ usb_phy_generic_unregister(glue-phy);
clk_disable(glue-clk);
clk_put(glue-clk);
kfree(glue);
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index e1da199..f38a8db 100644
[PATCH 7/8] usb: musb: move usb_phy_generic_{un,}register calls to probe()/remove()
This patch is in preparation to supporting
calling those functions multiple times.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/am35x.c| 4 ++--
drivers/usb/musb/blackfin.c | 6 +++---
drivers/usb/musb/da8xx.c| 4 ++--
drivers/usb/musb/davinci.c | 4 ++--
drivers/usb/musb/tusb6010.c | 5 ++---
5 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 044cd82..05459b5 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -360,7 +360,6 @@ static int am35x_musb_init(struct musb *musb)
if (!rev)
return -ENODEV;
- usb_phy_generic_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
return -EPROBE_DEFER;
@@ -402,7 +401,6 @@ static int am35x_musb_exit(struct musb *musb)
data-set_phy_power(0);
usb_put_phy(musb-xceiv);
- usb_phy_generic_unregister();
return 0;
}
@@ -505,6 +503,7 @@ static int am35x_probe(struct platform_device *pdev)
pdata-platform_ops = am35x_ops;
+ usb_phy_generic_register();
platform_set_drvdata(pdev, glue);
pinfo = am35x_dev_info;
@@ -547,6 +546,7 @@ static int am35x_remove(struct platform_device *pdev)
struct am35x_glue *glue = platform_get_drvdata(pdev);
platform_device_unregister(glue-musb);
+ usb_phy_generic_unregister();
clk_disable(glue-clk);
clk_disable(glue-phy_clk);
clk_put(glue-clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c9992a2..53acffe 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -401,7 +401,6 @@ static int bfin_musb_init(struct musb *musb)
}
gpio_direction_output(musb-config-gpio_vrsel, 0);
- usb_phy_generic_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
gpio_free(musb-config-gpio_vrsel);
@@ -424,9 +423,8 @@ static int bfin_musb_init(struct musb *musb)
static int bfin_musb_exit(struct musb *musb)
{
gpio_free(musb-config-gpio_vrsel);
-
usb_put_phy(musb-xceiv);
- usb_phy_generic_unregister();
+
return 0;
}
@@ -477,6 +475,7 @@ static int bfin_probe(struct platform_device *pdev)
pdata-platform_ops = bfin_ops;
+ usb_phy_generic_register();
platform_set_drvdata(pdev, glue);
memset(musb_resources, 0x00, sizeof(*musb_resources) *
@@ -528,6 +527,7 @@ static int bfin_remove(struct platform_device *pdev)
struct bfin_glue*glue = platform_get_drvdata(pdev);
platform_device_unregister(glue-musb);
+ usb_phy_generic_unregister();
kfree(glue);
return 0;
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index a0dabb0..024751f 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -418,7 +418,6 @@ static int da8xx_musb_init(struct musb *musb)
if (!rev)
goto fail;
- usb_phy_generic_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
ret = -EPROBE_DEFER;
@@ -453,7 +452,6 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_phy_generic_unregister();
return 0;
}
@@ -512,6 +510,7 @@ static int da8xx_probe(struct platform_device *pdev)
pdata-platform_ops = da8xx_ops;
+ usb_phy_generic_register();
platform_set_drvdata(pdev, glue);
memset(musb_resources, 0x00, sizeof(*musb_resources) *
@@ -561,6 +560,7 @@ static int da8xx_remove(struct platform_device *pdev)
struct da8xx_glue *glue = platform_get_drvdata(pdev);
platform_device_unregister(glue-musb);
+ usb_phy_generic_unregister();
clk_disable(glue-clk);
clk_put(glue-clk);
kfree(glue);
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 7370354..de8492b 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -381,7 +381,6 @@ static int davinci_musb_init(struct musb *musb)
u32 revision;
int ret = -ENODEV;
- usb_phy_generic_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
ret = -EPROBE_DEFER;
@@ -487,7 +486,6 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_phy_generic_unregister();
return 0;
}
@@ -545,6 +543,7 @@ static int davinci_probe(struct platform_device *pdev)
pdata-platform_ops = davinci_ops;
+ usb_phy_generic_register();
platform_set_drvdata(pdev, glue);
memset(musb_resources, 0x00,
[PATCH 3/8] usb: dwc3: core: refactor mode initialization to its own function
Move mode (Host, Peripheral, OTG) initialization
to its own function in order to decrease the size
of our probe() routine.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/core.c | 133
1 file changed, 67 insertions(+), 66 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 38976f3..2a68aea 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -553,6 +553,69 @@ static int dwc3_core_get_phy(struct dwc3 *dwc)
return 0;
}
+static int dwc3_core_init_mode(struct dwc3 *dwc)
+{
+ struct device *dev = dwc-dev;
+ int ret;
+
+ switch (dwc-dr_mode) {
+ case USB_DR_MODE_PERIPHERAL:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
+ ret = dwc3_gadget_init(dwc);
+ if (ret) {
+ dev_err(dev, failed to initialize gadget\n);
+ return ret;
+ }
+ break;
+ case USB_DR_MODE_HOST:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
+ ret = dwc3_host_init(dwc);
+ if (ret) {
+ dev_err(dev, failed to initialize host\n);
+ return ret;
+ }
+ break;
+ case USB_DR_MODE_OTG:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+ ret = dwc3_host_init(dwc);
+ if (ret) {
+ dev_err(dev, failed to initialize host\n);
+ return ret;
+ }
+
+ ret = dwc3_gadget_init(dwc);
+ if (ret) {
+ dev_err(dev, failed to initialize gadget\n);
+ return ret;
+ }
+ break;
+ default:
+ dev_err(dev, Unsupported mode of operation %d\n,
dwc-dr_mode);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void dwc3_core_exit_mode(struct dwc3 *dwc)
+{
+ switch (dwc-dr_mode) {
+ case USB_DR_MODE_PERIPHERAL:
+ dwc3_gadget_exit(dwc);
+ break;
+ case USB_DR_MODE_HOST:
+ dwc3_host_exit(dwc);
+ break;
+ case USB_DR_MODE_OTG:
+ dwc3_host_exit(dwc);
+ dwc3_gadget_exit(dwc);
+ break;
+ default:
+ /* do nothing */
+ break;
+ }
+}
+
#define DWC3_ALIGN_MASK(16 - 1)
static int dwc3_probe(struct platform_device *pdev)
@@ -682,41 +745,9 @@ static int dwc3_probe(struct platform_device *pdev)
goto err_usb3phy_power;
}
- switch (dwc-dr_mode) {
- case USB_DR_MODE_PERIPHERAL:
- dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
- ret = dwc3_gadget_init(dwc);
- if (ret) {
- dev_err(dev, failed to initialize gadget\n);
- goto err2;
- }
- break;
- case USB_DR_MODE_HOST:
- dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
- ret = dwc3_host_init(dwc);
- if (ret) {
- dev_err(dev, failed to initialize host\n);
- goto err2;
- }
- break;
- case USB_DR_MODE_OTG:
- dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
- ret = dwc3_host_init(dwc);
- if (ret) {
- dev_err(dev, failed to initialize host\n);
- goto err2;
- }
-
- ret = dwc3_gadget_init(dwc);
- if (ret) {
- dev_err(dev, failed to initialize gadget\n);
- goto err2;
- }
- break;
- default:
- dev_err(dev, Unsupported mode of operation %d\n,
dwc-dr_mode);
+ ret = dwc3_core_init_mode(dwc);
+ if (ret)
goto err2;
- }
ret = dwc3_debugfs_init(dwc);
if (ret) {
@@ -729,21 +760,7 @@ static int dwc3_probe(struct platform_device *pdev)
return 0;
err3:
- switch (dwc-dr_mode) {
- case USB_DR_MODE_PERIPHERAL:
- dwc3_gadget_exit(dwc);
- break;
- case USB_DR_MODE_HOST:
- dwc3_host_exit(dwc);
- break;
- case USB_DR_MODE_OTG:
- dwc3_host_exit(dwc);
- dwc3_gadget_exit(dwc);
- break;
- default:
- /* do nothing */
- break;
- }
+ dwc3_core_exit_mode(dwc);
err2:
dwc3_event_buffers_cleanup(dwc);
@@ -778,23 +795,7 @@ static int dwc3_remove(struct platform_device *pdev)
pm_runtime_disable(pdev-dev);
dwc3_debugfs_exit(dwc);
-
- switch (dwc-dr_mode) {
- case USB_DR_MODE_PERIPHERAL:
- dwc3_gadget_exit(dwc);
- break;
- case
Re: problem with resume after s2ram
On Mon, Apr 14 2014, Alan Stern wrote: How many diagnostic patches have you tried so far? I've lost track. Hi Alan, diag1: the one with the alan-timer diag2: reverts commit 0aa2832dd0d9d860 and instead, prints out information showing what the commit would do diag3: partially reverts e583d9db9960 and prints some information to the kernel log If you like, you can also apply the diagnostic patch that adds stuff to ohci-hcd. Yes, I've applied diag1 and diag3. The question is: With this patch present and no devices attached to the rear ports, do the front ports work with system suspend? Yes. Please find attached the log. -- Peter 2014-04-16T23:34:31.259973+02:00 micropit kernel: [ 370.035797] PM: Syncing filesystems ... done. 2014-04-16T23:34:31.260016+02:00 micropit kernel: [ 370.549062] PM: Preparing system for mem sleep 2014-04-16T23:34:52.719671+02:00 micropit kernel: [ 370.552283] Freezing user space processes ... (elapsed 0.001 seconds) done. 2014-04-16T23:34:52.719694+02:00 micropit kernel: [ 370.554235] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. 2014-04-16T23:34:52.719695+02:00 micropit kernel: [ 370.555800] PM: Entering mem sleep 2014-04-16T23:34:52.719696+02:00 micropit kernel: [ 370.556327] ohci-pci :00:13.1: Dequeue: 8801240d0680 count 1 2014-04-16T23:34:52.719697+02:00 micropit kernel: [ 370.556363] usb 6-3: w-e-d 0 2014-04-16T23:34:52.719698+02:00 micropit kernel: [ 370.556370] usb 6-3: usb suspend, wakeup 0 2014-04-16T23:34:52.719698+02:00 micropit kernel: [ 370.556665] usb 2-3: w-e-d 0 2014-04-16T23:34:52.719699+02:00 micropit kernel: [ 370.556704] sd 2:0:0:0: [sdb] Synchronizing SCSI cache 2014-04-16T23:34:52.719701+02:00 micropit kernel: [ 370.556759] ohci-pci :00:13.1: IRQ: count 1 intr-en 805e intr-stat 24 frame f1a3 2014-04-16T23:34:52.719701+02:00 micropit kernel: [ 370.556765] sd 0:0:0:0: [sda] Synchronizing SCSI cache 2014-04-16T23:34:52.719702+02:00 micropit kernel: [ 370.556771] ohci-pci :00:13.1: Giveback: 8801240d0680 count 1 2014-04-16T23:34:52.719703+02:00 micropit kernel: [ 370.556867] sd 2:0:0:0: [sdb] Stopping disk 2014-04-16T23:34:52.719704+02:00 micropit kernel: [ 370.556958] usb usb7: usb auto-resume 2014-04-16T23:34:52.719705+02:00 micropit kernel: [ 370.556966] ohci-pci :00:14.5: resume root hub 2014-04-16T23:34:52.719706+02:00 micropit kernel: [ 370.557121] usb 2-3: usb suspend, wakeup 0 2014-04-16T23:34:52.719707+02:00 micropit kernel: [ 370.557225] usb usb5: usb auto-resume 2014-04-16T23:34:52.719708+02:00 micropit kernel: [ 370.557316] ohci-pci :00:13.0: resume root hub 2014-04-16T23:34:52.719708+02:00 micropit kernel: [ 370.557360] usb usb4: usb auto-resume 2014-04-16T23:34:52.719709+02:00 micropit kernel: [ 370.557372] ohci-pci :00:12.1: resume root hub 2014-04-16T23:34:52.719710+02:00 micropit kernel: [ 370.557447] usb usb3: usb auto-resume 2014-04-16T23:34:52.719711+02:00 micropit kernel: [ 370.557455] ohci-pci :00:12.0: resume root hub 2014-04-16T23:34:52.719712+02:00 micropit kernel: [ 370.557532] hub 2-0:1.0: hub_suspend 2014-04-16T23:34:52.719712+02:00 micropit kernel: [ 370.557542] usb usb2: bus suspend, wakeup 0 2014-04-16T23:34:52.719713+02:00 micropit kernel: [ 370.557546] ehci-pci :00:13.2: suspend root hub 2014-04-16T23:34:52.719714+02:00 micropit kernel: [ 370.557603] usb usb1: usb auto-resume 2014-04-16T23:34:52.719715+02:00 micropit kernel: [ 370.557611] ehci-pci :00:12.2: resume root hub 2014-04-16T23:34:52.719715+02:00 micropit kernel: [ 370.557798] usb 6-2: w-e-d 1 2014-04-16T23:34:52.719716+02:00 micropit kernel: [ 370.557805] usb 6-2: usb suspend, wakeup 1 2014-04-16T23:34:52.719717+02:00 micropit kernel: [ 370.557833] hub 6-0:1.0: hub_suspend 2014-04-16T23:34:52.719718+02:00 micropit kernel: [ 370.557839] usb usb6: bus suspend, wakeup 0 2014-04-16T23:34:52.719719+02:00 micropit kernel: [ 370.557850] ohci-pci :00:13.1: suspend root hub 2014-04-16T23:34:52.719719+02:00 micropit kernel: [ 370.601094] sd 0:0:0:0: [sda] Stopping disk 2014-04-16T23:34:52.719720+02:00 micropit kernel: [ 370.605358] hub 7-0:1.0: hub_resume 2014-04-16T23:34:52.719721+02:00 micropit kernel: [ 370.605514] hub 7-0:1.0: hub_suspend 2014-04-16T23:34:52.719722+02:00 micropit kernel: [ 370.605632] usb usb7: bus suspend, wakeup 0 2014-04-16T23:34:52.719722+02:00 micropit kernel: [ 370.605745] ohci-pci :00:14.5: suspend root hub 2014-04-16T23:34:52.719723+02:00 micropit kernel: [ 370.606397] hub 3-0:1.0: hub_resume 2014-04-16T23:34:52.719724+02:00 micropit kernel: [ 370.606410] hub 4-0:1.0: hub_resume 2014-04-16T23:34:52.719725+02:00 micropit kernel: [ 370.606438] hub 4-0:1.0: hub_suspend 2014-04-16T23:34:52.719726+02:00 micropit kernel: [ 370.606450] usb usb4: bus suspend, wakeup 0 2014-04-16T23:34:52.719726+02:00 micropit kernel: [ 370.606455] ohci-pci :00:12.1: suspend root hub
Re: [PATCH] Adds power management support to the atmel ehci driver.
On Wed, Apr 16, 2014 at 10:54:26AM -0400, Alan Stern wrote:
On Tue, 15 Apr 2014, Michael Welling wrote:
Allows the driver to turn off the clock during suspend for additional power
savings.
Signed-off-by: Michael Welling mwell...@ieee.org
@@ -181,6 +182,40 @@ static int ehci_atmel_drv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int
+ehci_atmel_drv_suspend(struct platform_device *pdev, pm_message_t mesg)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+
+ if (device_may_wakeup(pdev-dev))
+ enable_irq_wake(hcd-irq);
This is peculiar. Wny isn't the IRQ enabled all the time? As I
understand it, the proper way to disable wakeups is to tell the
controller not to issue any wakeup signal at all. Not to tell the
kernel that the IRQ shouldn't be used for wakeups. That sort of
approach fails when shared IRQs are used.
I was just following the lead of the at91 ohci driver. I have cc'd
the author of the driver to see if he has an insight as to why the
wake is being turned on and off for the Atmel processors.
After a little feedback I will update the patch as necessary.
Otherwise the patch looks okay.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] Support for Super Speed Link Layer Test
On Tue, Apr 15, 2014 at 10:05:42PM +0800, Alan Stern wrote: On Tue, 15 Apr 2014, Pratyush Anand wrote: How about just creating a normal USB device instead of a platform device? I think all you have to do is make usb_new_device() avoid calling usb_enumerate_device() when the new flag is set. I had thought of this. But, I had found that even hub_port_reset creates issue for LVS device. hub_port_reset forces USB SS link to go into recovery very soon, which is not expected as per Link Layer Test specification. So, we can not even allow to execute hub_port_init when a LVS device is connected. Also, instead of adding a new quirk flag to every single USB device, you probably should use something that is hcd-specific. Then xhci-hcd could register the new sysfs file, and it wouldn't be present for other controller types or non-root hubs. That I will look into. Should be doable. Here's another idea: Unbind the hub driver from the root hub and replace it with an LVS-specific driver. That would require essentially no changes to the existing code in usbcore. Great!!! Seems cleanest approach. Thanks a lot. Will change my implementation as suggested. Regards Pratyush 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
