usbmisc driver handles the SoC specific non-core usb registers.
Changes since last version:
- add missing ci13xxx_imx.h
Changes v3 -> v4:
- rebase onto torvalds latest git tree
- use phandle linke usb controllers and usbmisc device.
It also make usbmisc driver possible to be kernel modules.
Signed-off-by: Richard Zhao
---
arch/arm/mach-imx/clk-imx6q.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index ea89520..660fcbb 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -405,6 +405,7
- add usbmisc device
- set property fsl,usbmisc for usb controllers
- set disable-over-current for imx6q-sabrelite usb otg
Signed-off-by: Richard Zhao
---
arch/arm/boot/dts/imx6q-sabrelite.dts |1 +
arch/arm/boot/dts/imx6q.dtsi | 10 ++
2 files changed, 11 insertions(+)
d
i.MX usb controllers shares non-core registers, which may include
SoC specific controls. We take it as a usbmisc device and usbmisc
driver set operations needed by ci13xxx_imx driver.
For example, Sabrelite board has bad over-current design, we can
usbmisc to disable over-current detect.
Signed-o
BTW: now that the patch has been submitted, will appropriate updates
also be made to the corresponding issue in bugzilla?
https://bugzilla.kernel.org/show_bug.cgi?id=44191
There's also an Ubuntu launchpad bug tied to this kernel bug report.
The original patch already fell by the wayside,
>
> From: Alan Stern
>To: Joao Bonina
>Cc: Daniel Mack ; "alsa-de...@alsa-project.org"
>; linux-usb
>Sent: Tuesday, 31 July 2012, 15:35
>Subject: Re: [alsa-devel] Alsa: USB Class 2 Audio soundcard device disappears
>suddenly
>
>On Tue, 31 Jul 2012, Joao
On Fri, Jul 27, 2012 at 02:02:00PM +0530, Ravi B wrote:
> +static void nop_put_id(int id)
> +{
> +
> + pr_info("removing id %d\n", id);
not pr_info. I guess pr_vdebug() is better. We don't want to know about
every new nop ID requested.
--
balbi
signature.asc
Description: Digital signature
Hi
> Subject: Re: [PATCH v6 04/11] usb: otg: nop: add support for
> multiple tranceiver
>
> On Fri, Jul 27, 2012 at 02:02:00PM +0530, Ravi B wrote:
> > +static void nop_put_id(int id)
> > +{
> > +
> > + pr_info("removing id %d\n", id);
>
> not pr_info. I guess pr_vdebug() is better. We don'
my neukum.name address has run out
Signed-off-by: Oliver Neukum
---
MAINTAINERS | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9b8a5da..c7cc810 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2202,7 +2202,7 @@ S:Maintained
This patch set introduces a phy driver for samsung SoCs. It uses the existing
transceiver infrastructure to provide phy control functions. Use of this driver
can be extended for usb host phy as well. Over the period of time all the phy
related code for most of the samsung SoCs can be integrated her
This driver uses usb_phy interface to interact with s3c-hsotg. Supports
phy_init and phy_shutdown functions to enable/disable phy. Tested with
smdk6410 and smdkv310. More SoCs can be brought under later.
Signed-off-by: Praveen Paneri
---
.../devicetree/bindings/usb/samsung-usbphy.txt |9
Adding the transceiver to hsotg driver. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Praveen Paneri
---
drivers/usb/gadget/s3c-hsotg.c | 38 --
1 files changed, 28 insertions(+), 10 deletions(-)
Hi,
These 6 patches clean up the UVC gadget driver after Bhupesh Sharma's "UVC
webcam gadget related changes" patch series. They're what I would have asked
during patch review if the original patches hadn't been merged before I got a
change to review them.
Bhupesh, would you mind testing the patc
Signed-off-by: Laurent Pinchart
---
drivers/usb/gadget/f_uvc.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index 2a8bf06..1cf336b 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -8
Call the appropriate usb_ep_autoconf*() function depending on the device
speed, and pass it the corresponding streaming endpoint.
Signed-off-by: Laurent Pinchart
---
drivers/usb/gadget/f_uvc.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/f_u
Adding platform device for sec_usbphy driver. Enabling it for s3c64xx
based machines using s3c-hsotg.
Signed-off-by: Praveen Paneri
---
arch/arm/mach-s3c64xx/include/mach/map.h |2 +
arch/arm/mach-s3c64xx/mach-crag6410.c|3 ++
arch/arm/mach-s3c64xx/mach-smartq.c |
This patch removes old phy code from platform side. 'setup-usb-phy.c'
will be used for providing transceiver platform data in next
patch. Not all of the platform data code is removed as there are others
making use of platform_data defined for hsotg. That can be removed once
all the SoCs start using
Compute the multiplier from the maximum packet size based on the speed.
Signed-off-by: Laurent Pinchart
---
drivers/usb/gadget/f_uvc.c | 116 +---
1 files changed, 55 insertions(+), 61 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/ga
Adding usbphy node for Exynos4210 along with the platform data.
Signed-off-by: Praveen Paneri
---
arch/arm/boot/dts/exynos4210.dtsi |5 +
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos4-dt.c |8
arch/arm/mach-exynos/setup-usb-phy.c
Signed-off-by: Laurent Pinchart
---
drivers/usb/gadget/f_uvc.c | 58 ++--
drivers/usb/gadget/f_uvc.h | 12
2 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index 6c97021..2
Signed-off-by: Laurent Pinchart
---
drivers/usb/gadget/f_uvc.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index 1cf336b..6c97021 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
The descriptors are identical, there's no need to have several copies of
them.
Signed-off-by: Laurent Pinchart
---
drivers/usb/gadget/f_uvc.c | 52 +++
1 files changed, 18 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/
Hi Bhupesh,
Thanks for the patch. Just a couple of small comments.
On Tuesday 31 July 2012 06:24:52 Bhupesh Sharma wrote:
> This patch adds the support in UVC webcam gadget design for providing
> USB_GADGET_DELAYED_STATUS in response to a set_interface(alt setting 1)
> command issue by the Host.
Hi Laurent,
Thanks for the patchset.
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Wednesday, August 01, 2012 6:27 PM
> To: linux-usb@vger.kernel.org
> Cc: Bhupesh SHARMA
> Subject: [PATCH 0/6] UVC gadget cleanup
>
> Hi,
>
> These 6 pat
Hi Bhupesh,
On Wednesday 01 August 2012 14:26:33 Bhupesh SHARMA wrote:
> Hi Laurent,
>
> I have a query for you regarding the support and testing of MJPEG frame type
> in the UVC webcam gadget.
>
> I see that in the webcam.c gadget, the 720p and VGA MJPEG uvc formats are
> supported. I was tryin
Hi Bhupesh,
On Wednesday 01 August 2012 21:12:51 Bhupesh SHARMA wrote:
> On Wednesday, August 01, 2012 6:27 PM Laurent Pinchart wrote:
> >
> > Hi,
> >
> > These 6 patches clean up the UVC gadget driver after Bhupesh Sharma's
> > "UVC webcam gadget related changes" patch series. They're what I wo
Hi Laurent,
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Wednesday, August 01, 2012 6:48 PM
> To: Bhupesh SHARMA
> Cc: linux-usb@vger.kernel.org
> Subject: Re: [PATCH 0/6] UVC gadget cleanup
>
> Hi Bhupesh,
>
> On Wednesday 01 August 20
When the scsi mass storage device is disconnected, the current urbs
queued to hcd driver must be cancelled, otherwise the current urbs
are pending at hcd driver and the active urb programmed at host
controller will never be completed. The class driver shall dequeue
or cancel all the urb request sub
Hi Laurent,
Thanks for your review.
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Wednesday, August 01, 2012 6:40 PM
> To: Bhupesh SHARMA
> Cc: linux-usb@vger.kernel.org; ba...@ti.com
> Subject: Re: [PATCH V2 2/2] usb: gadget/uvc: Add sup
Hi Laurent,
Thanks for clearing this doubt..
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Wednesday, August 01, 2012 6:46 PM
> To: Bhupesh SHARMA
> Cc: linux-usb@vger.kernel.org; linux-me...@vger.kernel.org
> Subject: Re: Query regarding
Hi Paul,
On Mon, July 30, 2012 12:00 pm, Paul Zimmerman wrote:
>> From: Ido Shayevitz [mailto:i...@codeaurora.org]
>> Sent: Monday, July 30, 2012 3:15 AM
>>
>> On Thu, July 26, 2012 4:38 pm, Paul Zimmerman wrote:
>> >> From: linux-usb-ow...@vger.kernel.org
>> >> [mailto:linux-usb-ow...@vger.kerne
On 2012/8/1 4:40, Bjørn Mork wrote:
Sarah Sharp writes:
No. Some internal ports can be pluggable, like your card reader, or
those ones behind an rfkill switch. But only internal ports can be
"unpluggable".
I'm apparently not explaining the ACPI methods very well. Can you
please take a look
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
> On Tuesday, July 31, 2012, Alan Stern wrote:
> > [CC: list trimmed]
> >
> > On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
> >
> > > Now it occured to me that perhaps we don't need the current asynchronous
> > > pm_runtime_get() at all. The usefuln
On Tue, 31 Jul 2012, Don Zickus wrote:
> We ran into an interesting deadlock on RHEL-5 (2.6.18) that I believe
> still appiles to the current kernel involving the ehci->lock.
>
> CPU A:
> submits a bulk transfer urb
> ehci_urb_enqueue calls submit_async
> submit_async blocks on ehci->lock with ir
Hi Anton,
On Tue, July 31, 2012 11:27 pm, Anton Tikhomirov wrote:
> Hi Ido,
>
>> -Original Message-
>> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
>> ow...@vger.kernel.org] On Behalf Of Ido Shayevitz
>> Sent: Monday, July 30, 2012 10:16 PM
>> To: Anton Tikhomirov
>> Cc: 'Ido
On 2012/7/31 22:39, Alan Stern wrote:
On Tue, 31 Jul 2012, Lan Tianyu wrote:
How about checking RESET_MORPHS before doing reset_resume, set reset_resume
to 0 and do resume when RESET_MORPHS is set.
No, that won't work. When we do a reset-resume it is because we _know_
that a regular resume w
On Wednesday 01 August 2012 22:46:51 Lan Tianyu wrote:
> > No, that won't work. When we do a reset-resume it is because we know
> > that a regular resume will fail.
> persist is default to be enabled. When user space set a device's
> avoid_reset_quirk, they also should set persist to 0. Since the
On Tue, 31 Jul 2012, Kuninori Morimoto wrote:
> Hi Alan
> Cc Magnus, Rafael
>
> > > > this patch enable to use pm_runtime_xxx() on ehci-platform
> > > > if .config has CONFIG_PM_RUNTIME, otherwise, these are ignored
> > > >
> > > > Signed-off-by: Kuninori Morimoto
> > > > ---
> > > > drivers/u
On Wed, 1 Aug 2012, James wrote:
> On 07/29/12 17:36, Alan Stern wrote:
> > On Sun, 29 Jul 2012, James wrote:
> >
> It noticeably slows down booting.
> >>>
> >>> It shouldn't interfere appreciably with booting, unless you're waiting
> >>> for some other USB device to be detected. All the US
On 2012/8/1 22:48, Oliver Neukum wrote:
On Wednesday 01 August 2012 22:46:51 Lan Tianyu wrote:
No, that won't work. When we do a reset-resume it is because we know
that a regular resume will fail.
persist is default to be enabled. When user space set a device's
avoid_reset_quirk, they also sho
On Wed, 1 Aug 2012, Ravi Babu wrote:
> When the scsi mass storage device is disconnected, the current urbs
> queued to hcd driver must be cancelled, otherwise the current urbs
> are pending at hcd driver and the active urb programmed at host
> controller will never be completed. The class driver s
On Wednesday 01 August 2012, Praveen Paneri wrote:
> This patch set introduces a phy driver for samsung SoCs. It uses the existing
> transceiver infrastructure to provide phy control functions. Use of this
> driver
> can be extended for usb host phy as well. Over the period of time all the phy
> r
On Wed, 1 Aug 2012, Lan Tianyu wrote:
> On 2012/7/31 22:39, Alan Stern wrote:
> > On Tue, 31 Jul 2012, Lan Tianyu wrote:
> >
> >> How about checking RESET_MORPHS before doing reset_resume, set reset_resume
> >> to 0 and do resume when RESET_MORPHS is set.
> >
> > No, that won't work. When we do a
On Wed, Aug 01, 2012 at 10:42:37AM -0400, Alan Stern wrote:
> On Tue, 31 Jul 2012, Don Zickus wrote:
>
> > We ran into an interesting deadlock on RHEL-5 (2.6.18) that I believe
> > still appiles to the current kernel involving the ehci->lock.
> >
> > CPU A:
> > submits a bulk transfer urb
> > ehc
Hi All,
I am working on linux kernel 3.4.
we have added suspend / resume functionality for USB XHCI stack.
But during xhci_resume() i get crash prints as below and USB 3.0 port becomes
dead after that.
55.611666] __dma_free_remap: trying to free invalid coherent area: f0012000
[ 55.618694]
> On Wed, 1 Aug 2012, James wrote:
>
>> On 07/29/12 17:36, Alan Stern wrote:
>> > On Sun, 29 Jul 2012, James wrote:
>> >
>> It noticeably slows down booting.
>> >>>
>> >>> It shouldn't interfere appreciably with booting, unless you're
>> waiting
>> >>> for some other USB device to be detected.
On Wed, 1 Aug 2012 bjloc...@lockie.ca wrote:
> > That's progress. Have you checked to see whether ehci-hcd is loaded
> > before or after ohci-hcd?
>
> Is there a way to tell besides watching the screen (which scrolls too
> fast) during boot?
Run the dmesg command.
> > Have you checked to see w
On Wed, Aug 01, 2012 at 04:48:43PM +, VIKAS SAJJAN C wrote:
> Hi All,
>
> I am working on linux kernel 3.4.
> we have added suspend / resume functionality for USB XHCI stack.
You have? From where? Have you tried 3.5?
> But during xhci_resume() i get crash prints as below and USB 3.0 port b
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout,
and if that happens on the first insertion, the host controller
port will enter in Compliance Mode as per xHCI Spe
Hi Alexis,
Did you run the patch through checkpatch.pl before submitting it?
I think you will get a bunch of important and completely automatic
feedback when you do that. Please fix everything that the script
mentions.
Alexis R. Cortes wrote:
> This patch is intended to work around a known issu
> From: Ido Shayevitz [mailto:i...@codeaurora.org]
> Sent: Wednesday, August 01, 2012 7:25 AM
>
> On Mon, July 30, 2012 12:00 pm, Paul Zimmerman wrote:
> >> From: Ido Shayevitz [mailto:i...@codeaurora.org]
> >> Sent: Monday, July 30, 2012 3:15 AM
> >>
> >> If the USB_DWC3 is not selected then even
On Tue, Jul 31, 2012 at 10:40:04PM +0200, Bjørn Mork wrote:
> Sarah Sharp writes:
> No, I wouldn't mind if PRT5 was powered off. But I do wonder what the
> actual power savings could possibly be. I assume the pins are
> unconnected so that there couldn't be any power lost there, and the
> contro
On Wednesday, August 01, 2012, Alan Stern wrote:
> On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
>
> > On Tuesday, July 31, 2012, Alan Stern wrote:
> > > [CC: list trimmed]
> > >
> > > On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
> > >
> > > > Now it occured to me that perhaps we don't need the
On Wed, Aug 01, 2012 at 10:01:31PM +0200, Peter Stuge wrote:
> Hi Alexis,
>
> Did you run the patch through checkpatch.pl before submitting it?
>
> I think you will get a bunch of important and completely automatic
> feedback when you do that. Please fix everything that the script
> mentions.
>
Hello,
I am working on a user-level USB peripheral device driver with a single
pair of bulk in/out endpoints. It uses the gadgetfs() driver.
I am initially running the usb.c example test program on gadgetfs, using
the Windows USB 2.0 Command Verifier from usb.org.
My target is a CM-T3730 board
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout,
and if that happens on the first insertion, the host controller
port will enter in Compliance Mode as per xHCI Spe
Alexis R. Cortes wrote:
> This patch is intended to work around a known issue on the
> SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
> between a device and the host past the usual handshake timeout,
> and if that happens on the first insertion, the host controller
> port will enter
On Wed, Aug 01, 2012 at 04:46:27PM -0500, Alexis R. Cortes wrote:
> Hi Sarah,
>
> Sure!! I'll update the patch's description and will send another patch in a
> few moments.
>
> As an additional comment, I ran the 'checkpatch.pl' script and verified
> there were no errors before submitting the pat
On Wed, Aug 01, 2012 at 05:36:52PM -0500, Alexis R. Cortes wrote:
> This patch is intended to work around a known issue on the
> SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
> between a device and the host past the usual handshake timeout,
Paragraphs, please. :)
> if that happe
Hi Alan, Rafael, Magnus
Thank you for your reply
> The problem is that the ehci-platform driver currently doesn't know
> anything about clocks or power sources. We need to add that
> information in a generic fashion, somehow. Until that's done, you
> can't really use ehci-platform as your driv
Hi Morimoto-san,
On Thu, Aug 2, 2012 at 9:09 AM, wrote:
>
> Hi Alan, Rafael, Magnus
>
> Thank you for your reply
>
>> The problem is that the ehci-platform driver currently doesn't know
>> anything about clocks or power sources. We need to add that
>> information in a generic fashion, somehow.
Hi Alan, Magnus
Thank you for your reply
> > -- probe --
> >if (pdata->power)
> > pdata->power(xxx, 1)
> >
> >usb_add_hcd()
> >
> >-- remove --
> >usb_remove_hcd()
> >
> >if (pdata->power)
> > pdata->power(xxx, 0)
>
> From my point of view this all depend
On 2012/8/1 1:02, Alan Stern wrote:
On Tue, 31 Jul 2012, Oliver Neukum wrote:
On Monday 30 July 2012 17:03:27 Alan Stern wrote:
On Mon, 30 Jul 2012, Sarah Sharp wrote:
I'm not even sure that RESET_MORPHS is the right thing to look at here.
It's possible for a device to retain important sett
Hi Arnd,
On Wed, Aug 1, 2012 at 8:50 PM, Arnd Bergmann wrote:
> On Wednesday 01 August 2012, Praveen Paneri wrote:
>> This patch set introduces a phy driver for samsung SoCs. It uses the existing
>> transceiver infrastructure to provide phy control functions. Use of this
>> driver
>> can be exte
A summary about what we should do now after such long discussion. If I
lost something or miss something, please correct me.
1) Add "auto" option to each port's power policy sysfs attribute. When
set to "auto", those ports which have never been attached with devices
will be power off immediately.
In case of USB bulk transfer, when himem page
is received, the usb_sg_init function sets the
urb transfer buffer to NULL. When such URB
transfer is handled, kernel crashes in PIO mode.
Handle this by mapping the highmem buffer in PIO mode.
Signed-off-by: Virupax Sadashivpetimath
---
drivers/usb
66 matches
Mail list logo
