On 07/03/2013 04:14 AM, Paul Zimmerman wrote:
> Well, I'm really confused. Not for the first time :)
>
> This patch series removes the dual license from all of the dwc3
> source files, and replaces it with the GPL only. So how can you
> say "the driver as a whole is dual BSD/GPL"? What am I missin
Hi,
> I can't tell what's going on in your log. Look at the
> FSG_STATE_CONFIG_CHANGE case in handle_exception(). Here's the code:
>
> rc = do_set_config(fsg, new_config);
> if (fsg->ep0_req_tag != exception_req_tag)
> break;
>
Hi,
>> I can't tell what's going on in your log. Look at the
>> FSG_STATE_CONFIG_CHANGE case in handle_exception(). Here's the code:
>>
>> rc = do_set_config(fsg, new_config);
>> if (fsg->ep0_req_tag != exception_req_tag)
>> break;
>>
On 07/02/2013 08:17 PM, Alan Stern wrote:
> On Tue, 2 Jul 2013, Roger Quadros wrote:
>
>> On 07/02/2013 12:01 AM, Alan Stern wrote:
>>> On Mon, 1 Jul 2013, Felipe Balbi wrote:
>>>
> I don't know what Pad wakeup is. The wakeup signal has to originate
> from the EHCI controller, doesn't it
Hi Kishon,
> -Original Message-
> From: ABRAHAM, KISHON VIJAY
> Sent: Wednesday, June 26, 2013 5:17 PM
> To: grant.lik...@linaro.org; t...@atomide.com; Balbi, Felipe; ABRAHAM,
> KISHON VIJAY; a...@arndb.de; swar...@nvidia.com;
> sylvester.nawro...@gmail.com; linux-ker...@vger.kernel.org; l
On Tue, Jul 02, 2013 at 05:44:01PM +0200, Frank Schäfer wrote:
> > - /* NOTE: Only the values defined in baud_sup are supported !
> > + /*
> > +* NOTE: Only the values defined in baud_sup are supported!
> > * => if unsupported values are set, the PL2303 seems to use
> > *
Hello,
I recently got a Intel Dual Band Wireless-AC 7260 card, which works very
well as a 802.11 wlan module. So I am now trying to break the Bluetooth
part of it instead :)
And I do find some issues with that... The most important one is that I
cannot get it to work properly with autosuspend en
On Wednesday 03 July 2013 14:08:00 Bjørn Mork wrote:
> But this just does not seem right? Any modern USB device is supposed to
> support autosuspend, right? I am using the firmware patch included in
What should be and what is may be different although it oughn't be.
> the latest public firmware r
Oliver Neukum writes:
> On Wednesday 03 July 2013 14:08:00 Bjørn Mork wrote:
>> But this just does not seem right? Any modern USB device is supposed to
>> support autosuspend, right? I am using the firmware patch included in
>
> What should be and what is may be different although it oughn't be.
Hi,
On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote:
> A PCI-based EHCI controller has two power sources: the core well (which
> is turned off during suspend) and the auxiliary well (which remains
> powered). That's how remote wakeup works; it uses the auxiliary well.
This, kinda, mat
On 07/03/2013 03:57 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote:
>> A PCI-based EHCI controller has two power sources: the core well (which
>> is turned off during suspend) and the auxiliary well (which remains
>> powered). That's how remote wakeup
Hi,
On Tue, Jul 02, 2013 at 12:22:05PM -0700, Greg Kroah-Hartman wrote:
> None of these USB files need idr.h, so don't include it.
>
> Cc: Alexander Shishkin
> Cc: Felipe Balbi
> Signed-off-by: Greg Kroah-Hartman
> ---
> drivers/usb/chipidea/core.c | 1 -
> drivers/usb/core/endpoint.c | 1 -
On Tue, Jul 02, 2013 at 12:22:06PM -0700, Greg Kroah-Hartman wrote:
> Drivers should not be putting debug files in /proc/ that is what debugfs
> is for, so move the sl811 driver's debug file to debugfs.
>
> Cc: Felipe Balbi
> Signed-off-by: Greg Kroah-Hartman
this one builds fine
Reviewed-by:
Hi,
On Tue, Jul 02, 2013 at 12:22:07PM -0700, Greg Kroah-Hartman wrote:
> Drivers should not be putting debug files in /proc/ that is what debugfs
> is for, so move the isp1362 driver's debug file to debugfs.
>
> Cc: Felipe Balbi
> Signed-off-by: Greg Kroah-Hartman
> ---
> drivers/usb/host/isp
On Wed, Jul 03, 2013 at 04:06:04PM +0300, Roger Quadros wrote:
> On 07/03/2013 03:57 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote:
> >> A PCI-based EHCI controller has two power sources: the core well (which
> >> is turned off during suspend) a
Bjørn Mork writes:
> Ah, this is probably a timing issue.
It definitely is, and I believe it is a generic problem with the btusb
driver and not with this particular device. That's just where I was
"lucky" enough to see it.
Enabling a bit of debugging in btusb, I see this for a hci version
com
On Wed, 3 Jul 2013, Ming Lei wrote:
> On Wed, Jul 3, 2013 at 1:46 AM, Alan Stern wrote:
> >>
> >> -
> >> /* Poll the STS_ASS status bit; see when it agrees with CMD_ASE */
> >> static void ehci_poll_ASS(struct ehci_hcd *ehci)
> >> {
> >
> > This blank line should remain intact. Apart from tha
On Tue, 2 Jul 2013, Sarah Sharp wrote:
> > On the other hand, I know from personal experience that some companies
> > are worried about this race and insist on avoiding it. Should I add a
> > Kconfig option to force global suspend always?
>
> If we add a Kconfig option, I worry about a) confusin
On Wed, 3 Jul 2013, Ming Lei wrote:
> >> Yes, that is the change tasklet is bringing, so looks we need to find a way
> >> to distinguish streaming-on from underrun when stream->td_list becomes
> >> empty in iso_stream_schedule().
> >
> > The difference will be the URB_ISO_ASAP flag. The flag shou
On Wed, 3 Jul 2013, Laurent Pinchart wrote:
> > Of course, it has been true all along that the status fields in the URB's
> > individual usb_iso_packet_descriptor structures indicate any errors. But
> > HCDs tend to set urb->status to 0 always, for isochronous URBs. Is there
> > any advantage to
On Wed, 3 Jul 2013, Felipe Balbi wrote:
> On Wed, Jul 03, 2013 at 04:06:04PM +0300, Roger Quadros wrote:
> > On 07/03/2013 03:57 PM, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote:
> > >> A PCI-based EHCI controller has two power sources: the
On Wed, 3 Jul 2013, Bjørn Mork wrote:
> Bjørn Mork writes:
>
> > Ah, this is probably a timing issue.
>
> It definitely is, and I believe it is a generic problem with the btusb
> driver and not with this particular device. That's just where I was
> "lucky" enough to see it.
>
> Enabling a bi
Hi,
The patchset supports to run giveback of URB in tasklet context, so that
DMA unmapping/mapping on transfer buffer and compelte() callback can be
run with interrupt enabled, then time of HCD interrupt handler(IRQs
disabled time) can be saved much. Also this approach may simplify HCD
since HCD l
This patch implements the mechanism of giveback of URB in
tasklet context, so that hardware interrupt handling time for
usb host controller can be saved much, and HCD interrupt handling
can be simplified.
Motivations:
1), on some arch(such as ARM), DMA mapping/unmapping is a bit
time-consuming, f
The patch does the below improvement:
- think QH_STATE_COMPLETING as unlinking state since all URBs on the
endpoint should be in unlinking or unlinked when doing endpoint_disable()
- add "WARN_ON(!list_empty(&qh->qtd_list));" if qh->qh_state is
QH_STATE_LINKED because there shouldn't be any activ
There is no good reason to run complete() in hard interrupt
disabled context.
After switch to run complete() in tasklet, we will enable local IRQs
when calling complete() since we can do it at that time.
Even though we still disable IRQs now when calling complete()
in tasklet, the URB documentati
ehci-hcd currently unlinks an interrupt QH when it becomes empty, that
is, after its last URB completes. This works well because in almost
all cases, the completion handler for an interrupt URB resubmits the
URB; therefore the QH doesn't become empty and doesn't get unlinked.
When we start using
All 4 transfer types can work well on EHCI HCD after switching to run
URB giveback in tasklet context, so mark all HCD drivers to support
it.
Also we don't need to release ehci->lock during URB giveback any more.
>From below test results on 3 machines(2 ARM and one x86), time
consumed by EHCI int
On Wed, 3 Jul 2013, Victor Yeo wrote:
> Hi,
>
> > I can't tell what's going on in your log. Look at the
> > FSG_STATE_CONFIG_CHANGE case in handle_exception(). Here's the code:
> >
> > rc = do_set_config(fsg, new_config);
> > if (fsg->ep0_req_tag != exception_req
On Wed, Jul 03, 2013 at 04:12:02PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 02, 2013 at 12:22:07PM -0700, Greg Kroah-Hartman wrote:
> > Drivers should not be putting debug files in /proc/ that is what debugfs
> > is for, so move the isp1362 driver's debug file to debugfs.
> >
> > Cc: Feli
On Wed, Jul 03, 2013 at 04:08:42PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 02, 2013 at 12:22:05PM -0700, Greg Kroah-Hartman wrote:
> > None of these USB files need idr.h, so don't include it.
> >
> > Cc: Alexander Shishkin
> > Cc: Felipe Balbi
> > Signed-off-by: Greg Kroah-Hartman
> >
On Wed, 3 Jul 2013, Peter Chen wrote:
> Hi Jiri and Alan,
>
> I have run below below at 3.5.7 kernel, but after checking upstream
> kernel, it may also be existed.
>
> 1. evtest /dev/input/event1 &
> 2. Let mouse auto suspend, enable mouse as wakeup source, and let
> the system enters suspend.
>
On Wed, Jul 03, 2013 at 09:25:06AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Jul 03, 2013 at 04:08:42PM +0300, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Jul 02, 2013 at 12:22:05PM -0700, Greg Kroah-Hartman wrote:
> > > None of these USB files need idr.h, so don't include it.
> > >
> > > Cc: Al
On Wed, Jun 19, 2013 at 4:06 PM, Paul Gortmaker
wrote:
> Hi guys,
>
> This was seen on a linux-next (Jun18th tree) allmodconfig build:
>
> WARNING: drivers/usb/gadget/fotg210-udc.o(.data+0x0): Section mismatch in
> reference from the variable fotg210_driver to the function
> .init.text:fotg210_u
On Wed, Jul 3, 2013 at 1:00 PM, Paul Gortmaker
wrote:
> On Wed, Jun 19, 2013 at 4:06 PM, Paul Gortmaker
> wrote:
>> Hi guys,
>>
>> This was seen on a linux-next (Jun18th tree) allmodconfig build:
>>
>> WARNING: drivers/usb/gadget/fotg210-udc.o(.data+0x0): Section mismatch in
>> reference from th
Hi,
> Than either there is a bug in the UDC (or the UDC driver), or else the
> host doesn't wait for the Set-Config request to complete before sending
> the next request. What were the values of fsg->ep0_req_tag and
> exception_req_tag?
>From the printk added, the values of fsg->ep0_req_tag and
On Wed, Jul 03, 2013 at 10:42:10AM +0800, Huang Rui wrote:
> Hi,
>
> Sometimes I was encounterd an issue that auto-wakeup at second time
> from S3 if use mouse to wakeup OS at first time.
I'm confused by this sentence. Are you trying to get the system to come
out of S3 by using your mouse (e.g.
On Thu, 4 Jul 2013, Victor Yeo wrote:
> Hi,
>
> > Than either there is a bug in the UDC (or the UDC driver), or else the
> > host doesn't wait for the Set-Config request to complete before sending
> > the next request. What were the values of fsg->ep0_req_tag and
> > exception_req_tag?
>
> From
On Wed, Jul 03, 2013 at 07:57:16PM +0300, Felipe Balbi wrote:
> On Wed, Jul 03, 2013 at 09:25:06AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Jul 03, 2013 at 04:08:42PM +0300, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Tue, Jul 02, 2013 at 12:22:05PM -0700, Greg Kroah-Hartman wrote:
> > > > No
Hey all,
Whenever I use my (USB2) webcam, the following message is spammed in the
log a couple of times per second:
xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part of
current TD
This only happens when I actively use the cam, e.g. running mplayer
tv://, which is showing the cam's
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Tuesday, July 02, 2013 7:41 PM
>
> On 07/02/2013 07:47 PM, Stephen Warren wrote:
> > On 06/26/2013 02:20 PM, Paul Zimmerman wrote:
> >> I hope whoever is supporting the Pi in the mainline kernel will try adding
> >> dwc2 support now tha
Toralf:
Here's a patch you can try out. It does more or less what I've been
discussing, but with no new Kconfig option.
Alan Stern
Index: usb-3.10/drivers/usb/core/hub.c
===
--- usb-3.10.orig/drivers/usb/core/hub.c
+++ usb-3.10/
On 07/03/2013 08:35 PM, Alan Stern wrote:
> Here's a patch you can try out. It does more or less what I've been
> discussing, but with no new Kconfig option.
works fine :-)
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from
From: Fabio Estevam
stmp_reset_block() may fail, so let's check its return value and propagate it in
the case of error.
Signed-off-by: Fabio Estevam
---
drivers/usb/phy/phy-mxs-usb.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy-mxs-usb.c
On Tue, 2 Jul 2013 at 18:31, Frank Schäfer wrote:
I've set up a test environment (currently limited to 115.2 kbps) and
can confirm that this works ONLY with the following (currently
supported) baud rates: 75, 150, 300, 600, 1200, 1800, 2400, 3600,
4800, 7200, 9600, 14400, 19200, 28800, 38400,
Hi Pratyush,
On Tuesday 02 July 2013 17:24:41 Pratyush Anand wrote:
> On 6/20/2013 11:20 AM, Chetan Nanda wrote:
> > On Tue, Jun 18, 2013 at 6:12 PM, Laurent Pinchart wrote:
> >> On Tuesday 18 June 2013 11:17:40 Chetan Nanda wrote:
> >>> Hi,
> >>>
> >>> I am currently working with UVC camera devi
I wrote:
> I'll fix this in the driver.
James, please test this patch.
Regards,
Clemens
--8<>8--
ALSA: usb-audio: do not trust too-big wMaxPacketSize values
The driver used to assume that the streaming endpoint's wMaxPacketSize
va
Am 03.07.2013 12:45, schrieb Johan Hovold:
> On Tue, Jul 02, 2013 at 05:44:01PM +0200, Frank Schäfer wrote:
>>> - /* NOTE: Only the values defined in baud_sup are supported !
>>> + /*
>>> +* NOTE: Only the values defined in baud_sup are supported!
>>> * => if unsupported values a
Am 03.07.2013 22:07, schrieb Reinhard Max:
> On Tue, 2 Jul 2013 at 18:31, Frank Schäfer wrote:
>
>> I've set up a test environment (currently limited to 115.2 kbps) and
>> can confirm that this works ONLY with the following (currently
>> supported) baud rates: 75, 150, 300, 600, 1200, 1800, 2400, 3
Hi,
I was trying to read raw HID input reports of a laptop touchpad (USB
HID device) using /dev/hidraw* device file. I'm using Ubuntu 10.04 and
looks like hidraw* file is not available for the touchpad. Also my
laptop has a USB HID keyboard and corresponding hidraw file was
successfully created fo
Sorry, message subject was missing.
2013/7/4 Bohdan Koval :
> Hi,
>
> I was trying to read raw HID input reports of a laptop touchpad (USB
> HID device) using /dev/hidraw* device file. I'm using Ubuntu 10.04 and
> looks like hidraw* file is not available for the touchpad. Also my
> laptop has a US
On Wed, 3 Jul 2013 at 23:35, Frank Schäfer wrote:
When I wrote the patch in 2009, only the first baud rate programming
method was in place.
The second method has been added later with commit 8d48fdf6.
Hmm - it would be interesting to know what device and tests that
change was based on.
Hmm
On Wed, Jul 3, 2013 at 10:15 PM, Alan Stern wrote:
> On Wed, 3 Jul 2013, Ming Lei wrote:
>
>> >> Yes, that is the change tasklet is bringing, so looks we need to find a
>> >> way
>> >> to distinguish streaming-on from underrun when stream->td_list becomes
>> >> empty in iso_stream_schedule().
>>
On Thu, 4 Jul 2013, James Stone wrote:
> Just tested, and it doesn't seem to work for fixing the problem on my
> system. Device still locks up when trying jack frames/period of less than
> 512.
Can you post a short (a few hundred lines will be enough) usbmon trace
showing what happens with frames
On Thu, 4 Jul 2013, Ming Lei wrote:
> On Wed, Jul 3, 2013 at 10:15 PM, Alan Stern wrote:
> > On Wed, 3 Jul 2013, Ming Lei wrote:
> >
> >> >> Yes, that is the change tasklet is bringing, so looks we need to find a
> >> >> way
> >> >> to distinguish streaming-on from underrun when stream->td_list
On Thu, Jul 4, 2013 at 10:02 AM, Alan Stern wrote:
> On Thu, 4 Jul 2013, Ming Lei wrote:
>
>> On Wed, Jul 3, 2013 at 10:15 PM, Alan Stern
>> wrote:
>> > On Wed, 3 Jul 2013, Ming Lei wrote:
>> >
>> >> >> Yes, that is the change tasklet is bringing, so looks we need to find
>> >> >> a way
>> >> >
Hi,
> On Thu, Jul 4, 2013 at 1:53 AM, Laurent Pinchart
> wrote:
> Hi Pratyush,
> On Tuesday 02 July 2013 17:24:41 Pratyush Anand wrote:
>> On 6/20/2013 11:20 AM, Chetan Nanda wrote:
> >> On Tue, Jun 18, 2013 at 6:12 PM, Laurent Pinchart wrote:
> >>> On Tuesday 18 June 2013 11:17:40 Chetan Nand
On Thu, Jul 04, 2013 at 01:30:48AM +0300, Bohdan Koval wrote:
> Sorry, message subject was missing.
>
> 2013/7/4 Bohdan Koval :
> > Hi,
> >
> > I was trying to read raw HID input reports of a laptop touchpad (USB
> > HID device) using /dev/hidraw* device file. I'm using Ubuntu 10.04 and
> > looks
Correction of the omap_usb3_dpll_params array when the sys_clk_rate is
20MHz.
Signed-off-by: Nikhil Devshatwar
Signed-off-by: Ruchika Kharwar
---
drivers/usb/phy/phy-omap-usb3.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/usb/
When there is an error with the usb3_phy probe or absence, the error returned
is erroneously for usb2_phy.
Signed-off-by: Ruchika Kharwar
---
drivers/usb/dwc3/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35
DRA7XX has several USB OTG subsystems. USB_OTG_SS1 includes a USB1 and USB2
phy. USB_OTG_SS2 includes only a USB2 phy.
This patch allows the dwc3 probe to continue if a usb3_phy is not found.
This patch currently works for DRA7XX and submitted in the interim a nicer
method emerges.
Signed-off-by:
On Wed, Jul 03, 2013 at 04:34:13PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> stmp_reset_block() may fail, so let's check its return value and propagate it
> in
> the case of error.
>
> Signed-off-by: Fabio Estevam
Acked-by: Shawn Guo
--
To unsubscribe from this list: send the li
62 matches
Mail list logo
