On Sat, 10 Sep 2016, Wade Berrier wrote:
> On Thu Aug 11 16:18, Alan Stern wrote:
> > I never received any replies to this message. Should the patch I
> > suggested be merged?
> >
>
> Hello,
>
> I applied this updated patch to the fedora23 4.7.2 kernel and
fo/?l=mythtv-users&m=144131333703197&w=2
You should a check for ep_out to the probe routine.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
an 32 ms.
Signed-off-by: Alan Stern
Tested-by: Wade Berrier
CC:
---
[as1812]
drivers/usb/core/config.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
Index: usb-4.x/drivers/usb/core/con
On Thu, 15 Sep 2016, Wade Berrier wrote:
> On Thu Sep 15 15:13, Alan Stern wrote:
> > On Sat, 10 Sep 2016, Wade Berrier wrote:
> >
> > > On Thu Aug 11 16:18, Alan Stern wrote:
> > > > I never received any replies to this message. Should the
la kernel that gets plenty of video glitches?
Overall, this may be a very difficult problem to solve. The
4cd13c21b207 commit was intended to improve throughput at the cost of
increased latency. But then what do you do when the latency becomes
too high for the video subsystem to handle?
Alan Stern
to revert the kernel logic to prioritize latency instead of
> throughput.
It can't be done without pervasive changes to the USB subsystem, which
I would greatly prefer to avoid. Besides, this wouldn't really solve
the problem. Decreasing the latency for one device will cause it to be
increased for others.
Alan Stern
On Mon, 8 Jan 2018, Mauro Carvalho Chehab wrote:
> Em Sun, 7 Jan 2018 10:41:37 -0500 (EST)
> Alan Stern escreveu:
>
> > On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote:
> >
> > > > > It seems that the original patch were designed to solve some IRQ
> >
eduling parameters if needed, to adjust for
> > such use-cases (it was not really an admin choice before).
>
> Can't the ksoftirq patch be modified to only apply to the networking
> IRQ handling? That sounds less risky of affecting unrelated subsystems[1].
That might work. Or mo
dditional tcp load on raspberry.
>
> Unfortunately there's no usbmon or tshark on libreelec so I can't provide
> further logs.
Can you try running the same test on an x86_64 system?
Alan Stern
st? The post says that the testing was done on an x86_64
machine.
> Gesendet: Montag, 08. Januar 2018 um 17:31 Uhr
> Von: "Alan Stern"
> An: "Josef Griebichler"
> Cc: "Mauro Carvalho Chehab" , "Greg Kroah-Hartman"
> , linux-...@vger.kernel.
ol URBs. The DVB driver in question
uses bulk transfers.
xhci-hcd, on the other hand, does not use these tasklets (it doesn't
set the HCD_BH bit in the hc_driver's .flags member).
Alan Stern
after the structure has been
freed.
Clearly something is wrong, and I can't tell how this is all intended
to work. Is the deallocation supposed to occur at a later time?
Any ideas or suggestions?
Alan Stern
On Thu, 26 Sep 2019, syzbot wrote:
> Hello,
>
> syzbot has tested th
-ENOSPC is getting returned from
> drivers/usb/host/ehci-sched.c:iso_stream_schedule()
>
> I feel perhaps this is something basic I don't understand regarding
> USB URB scheduling but I don't get why it occurs on the IMX6 ci_hdrc
> controller on not an XHCI controller.
sts
beforehand. Note that vidioc_querycap() is protected by
usbvision->v4l2_lock, acquired in a higher layer of the V4L2
subsystem.
Reported-and-tested-by: syzbot+7fa38a608b1075dfd...@syzkaller.appspotmail.com
Signed-off-by: Alan Stern
CC:
---
[as1919]
drivers/media/usb/usbvision/usbvision-v
gs while the mutex is
still held and checking for pending removes before allowing an open to
succeed.
Signed-off-by: Alan Stern
CC:
---
[as1920]
drivers/media/usb/usbvision/usbvision-video.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
Index: usb-devel/
On Wed, 2 Oct 2019, Tim Harvey wrote:
> On Tue, Oct 1, 2019 at 12:19 PM Alan Stern wrote:
> >
> > On Tue, 1 Oct 2019, Tim Harvey wrote:
> >
> > > On Thu, Sep 26, 2019 at 3:47 PM Tim Harvey wrote:
> > > >
> > > > Greetings,
> > >
sts
beforehand. Note that vidioc_querycap() is protected by
usbvision->v4l2_lock, acquired in a higher layer of the V4L2
subsystem.
Reported-and-tested-by: syzbot+7fa38a608b1075dfd...@syzkaller.appspotmail.com
Signed-off-by: Alan Stern
CC:
---
[as1919]
drivers/media/usb/usbvision/usbvision-v
gs while the mutex is
still held and checking for pending removes before allowing an open to
succeed.
Signed-off-by: Alan Stern
CC:
---
[as1920]
drivers/media/usb/usbvision/usbvision-video.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
Index: usb-devel/
te "the buffer can be
continuous", but that is certainly not what he meant.
Alan Stern
On Thu, 30 Mar 2017, Mauro Carvalho Chehab wrote:
> Em Thu, 30 Mar 2017 10:26:32 -0400 (EDT)
> Alan Stern escreveu:
>
> > On Thu, 30 Mar 2017, Oliver Neukum wrote:
> >
> > > > Btw, I'm a lot more concerned about USB storage drivers. When I was
>
On Thu, 30 Mar 2017, Oliver Neukum wrote:
> Am Donnerstag, den 30.03.2017, 11:55 -0400 schrieb Alan Stern:
> >
> > I'm pretty sure that usb-storage does not do this, at least, not when
> > operating in its normal Bulk-Only-Transport mode. It never tries to
> >
On Wed, 2 Dec 2009, Sean wrote:
> Is there anything I can do to help? This is a show stopping bug for me.
Here's a patch you can try. It will add a _lot_ of debugging
information to the system log. Maybe it will help pin down the source
of the problem.
Alan Stern
Index: 2.6.31/dri
83&w=2
It probably won't make any difference, but including it anyway is
worthwhile.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t get the full output. Here's an enhanced
version of the patch. It will provide more information and perhaps a
smoking gun.
Alan Stern
Index: usb-2.6/drivers/usb/host/ohci-hcd.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-h
patch; this
one will stop printing the debug messages when an error is first
detected so maybe it won't overrun your log buffer.
Alan Stern
Index: usb-2.6/drivers/usb/host/ohci-hcd.c
===
--- usb-2.6.orig/drivers/usb/host/oh
ohci_dbg(hc, "(%d %d) %p -> %p [%p]\n", hash, n,
+ prev, *prev, td->td_hash);
If we find that the value of *prev differs from the value of
td->td_hash then we'll know for certain. (Or maybe the presence of the
barrie
Here is a completely new patch. This one is more directed, to catch
the sort of errors we now know to look for.
Alan Stern
Index: usb-2.6/drivers/usb/host/ohci-mem.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-mem.c
+++ u
to c6774800.
Try inserting a line saying:
td_check(ohci, hash, "#2c");
two lines above the #2b line, i.e., just after the wmb(). That'll help
narrow down the search for the bug.
And by the way, you don't need to post your entire dmesg log. Just the
portion containing
On Mon, 4 Jan 2010, Sean wrote:
> Alan Stern wrote:
> > Try inserting a line saying:
> >
> > td_check(ohci, hash, "#2c");
> >
> > two lines above the #2b line, i.e., just after the wmb(). That'll help
> > narrow down the search for
ried running the program on a different computer?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
(or DMA) address if it was malfunctioning.
Or it could be some bizarre timing problem with the memory bus, or
something else equally obscure. You didn't mention before that this
was a SoC rather than an ordinary PC.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linu
On Mon, 4 Jan 2010, Sean wrote:
> Alan Stern wrote:
> > Um, when you say it does the job, what do you mean?
> It traps the error and prevents the kernel from crashing.
As did some of the earlier patches, right?
> > The job it was _intended_ to do was to prove that your probl
On Tue, 5 Jan 2010, Sean wrote:
> Thanks so much for your help Alan. I also think this is definitely a bug
> in the hardware. Let's leave it at that, I'm happy.
Okay. You should mark the Bugzilla report as REJECTED and close it
out.
Alan Stern
--
To unsubscribe from this lis
ems, provided the
hardware is working correctly. (There was a case where the hardware
was _not_ working as expected.) Is any more information available
about this failure?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
end number. In fact, I
don't know anything about DVB in general... but I am familiar with
EHCI.
It's not obvious what could be causing this, so let's start out easy.
Try collecting two usbmon traces (instructions are in
Documentation/usb/usbmon.txt), showing what happens with and without
the reversion. Maybe some difference will stick out.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
running tcpdump over an ssh connection --
you end up dumping the packets containing the dump output!
But if not then this is a genuine bug and it should be reported
separately on the linux-usb mailing list.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-me
On Sun, 24 May 2009, David wrote:
> Alan Stern wrote:
> > It's not obvious what could be causing this, so let's start out easy.
> > Try collecting two usbmon traces (instructions are in
> > Documentation/usb/usbmon.txt), showing what happens with and without
On Sun, 24 May 2009, David wrote:
> Alan Stern wrote:
> > But if not then this is a genuine bug and it should be reported
> > separately on the linux-usb mailing list.
> >
> >
> >
>
> Stranger and stranger. I started usbmon on the quad core and (at the
On Sun, 24 May 2009, David wrote:
> Alan Stern wrote:
> > It's not obvious what could be causing this, so let's start out easy.
> > Try collecting two usbmon traces (instructions are in
> > Documentation/usb/usbmon.txt), showing what happens with and without
On Mon, 25 May 2009, David wrote:
> David wrote:
> > Alan Stern wrote:
> >
> >> Okay, here's a patch for you to try. It refreshes the toggle setting
> >> in a linked but otherwise idle QH when a new URB is queued.
> >>
> >> Alan Stern
ot be sure of it though, and it's
> going to take a lot of reboots.
>
> Unfortunately, although I have an Opteron, the issue does not
> occur here, so I'm at a loss for the moment. But I'll have to
> tackle it somehow. Not sure how though. Any suggestions are welcome.
nts.
To tell the truth, I'm not entirely certain this will work either. The
hardware may cache the endpoint state, so it may be necessary to unlink
the endpoint completely. Still, try this version and see what happens.
Alan Ste
hardware.
If it works okay for you, I'll submit it.
Alan Stern
Index: usb-2.6/drivers/usb/host/ehci-q.c
===
--- usb-2.6.orig/drivers/usb/host/ehci-q.c
+++ usb-2.6/drivers/usb/host/ehci-q.c
@@ -93,22 +93,6 @@ qh_update (struct e
ld be that the host controller isn't behaving correctly. But
even then, a timer should keep things running. So I don't know why the
system hanged.
BTW, all those extra debugging messages in your log made it very
difficult to read, and they didn't help much in pinpointing the
pr
sk.
That's when the hang occurred.
And that's why all those tasks are still in the refrigerator; they
remain there until the end of the resume from hibernation.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ed _before_ your system entered S4. In fact, it occurred before
the memory image was written out to the disk.
> Is there some other method I missed of testing?
How about echo disk >/sys/power/state with various settings in
/sys/power/disk?
Alan Stern
--
To unsubscribe from this list: s
make sure the bug is still present with the
lastest development kernel. That would be 2.6.29-rc7 together with
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.29-rc7.patch
If it is then we'll have to try some diagnostic patches to find out
what'
hilips/467317/khubd.timeout It only
> happened on that boot and I haven't seen those ehci_hcd/khubd errors
> again since.
I have no idea what caused that. Some brief glitch, apparently.
Okay, here's a diagnostic patch meant to apply on top of
gregkh-all-2.6.29-rc7. Let'
On Wed, 11 Mar 2009, Brandon Philips wrote:
> On 15:46 Wed 11 Mar 2009, Alan Stern wrote:
> > On Wed, 11 Mar 2009, Brandon Philips wrote:
> > Okay, here's a diagnostic patch meant to apply on top of
> > gregkh-all-2.6.29-rc7. Let's see what it says...
>
>
27;s happening. Here's yet another patch.
Alan Stern
Index: usb-2.6/drivers/usb/host/ehci-hcd.c
===
--- usb-2.6.orig/drivers/usb/host/ehci-hcd.c
+++ usb-2.6/drivers/usb/host/ehci-hcd.c
@@ -108,6 +108,8 @@ MODULE_PARM_
On Fri, 13 Mar 2009, Brandon Philips wrote:
> On 14:03 Fri 13 Mar 2009, Alan Stern wrote:
> > On Fri, 13 Mar 2009, Brandon Philips wrote:
> >
> > > > Okay, not much information there but it's a start. Here's a more
> > > > informative p
e the device back. I suggest using poll with POLLIN to signal this.
It seems as if you're trying to implement some notion of allowing a
device to have more than one driver at the same time. This is so far
out from the way the kernel behaves now, adopting it would be very
difficult if not impossible. Certainly the USB stack isn't the place
to start.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 10 Jun 2011, Mauro Carvalho Chehab wrote:
> Em 10-06-2011 11:48, Alan Stern escreveu:
> > On Fri, 10 Jun 2011, Hans de Goede wrote:
> >
> >
> > As Felipe has mentioned, this sounds like the sort of problem that
> > can better be solved in userspace.
iver. You certainly wouldn't want to put it in V4L2.
> Or, to move the libgphoto2 driver to kernel, combine it in the same
> driver that handles streaming. No ?
No. Something else is needed.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
r things like this and traditionally does resource
> management and things which come with that like refcounting: "unbind
> the driver from this device unless the device is currently in use".
Sure. At the moment the kernel does not keep track of whether a device
is currently in u
hci-hcd and uhci-hcd is correct.
ohci-hcd behaves the same way too. And they all agree with the
behavior described in the kerneldoc for struct urb in
include/linux/usb.h.
> According to Documentation/usb/error-codes.txt, host controller drivers
> should
> set the status to -EXDEV.
mean the device has been disconnected, not
-EPROTO. But usually HCD don't take these events into account when
determining URB status codes.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t take these events into account when
> > determining URB status codes.
>
> The xHCI driver will return -ESHUTDOWN as a status for URBs when the
> host controller is dying.
That's appropriate. But nobody should ever set an isochronous URB's
status field to -EPROTO, no ma
On Thu, 16 Jun 2011, Sarah Sharp wrote:
> On Thu, Jun 16, 2011 at 03:39:11PM -0400, Alan Stern wrote:
> > That's appropriate. But nobody should ever set an isochronous URB's
> > status field to -EPROTO, no matter whether the device is connected or
> > not
each microframe holds 7500 bytes (less if you count
bit-stuffing). 4% of that is 300 bytes, which is not enough for a
512-byte bulk packet. I think you'd run into trouble trying to do any
serious bulk transfers on such a tight schedule.
> Signed-off-by: Kirill Smelkov
> Cc
d never be less than 100 or
> > greater than 125.
>
> Ok. By the way, why should we limit it to be not less than 100?
> Likewise, a user who knows exactly what he/she is doing could limit
> periodic bandwidth to be less than 80% required by USB specification.
What's the poin
f880122d9d400 3527234708 C Zi:1:004:1 0:1:2600:0 32 0:0:12
> 0:1600:12 0:3200:12 0:4800:12 0:6400:12 51200 = 0c8c fa7e
> 012f1b05
>
> All are headed with 0c8c, see attached usbmon captures.
Maybe this device needs a USB_QUIRK_R
On Wed, 13 Jul 2011, Ming Lei wrote:
> Hi,
>
> On Tue, Jul 12, 2011 at 11:44 PM, Alan Stern
> wrote:
> > On Tue, 12 Jul 2011, Ming Lei wrote:
> >
> >> Hi Laurent,
> >>
> >> After resume from sleep, �all the ISO packets from camera are like
On Wed, 13 Jul 2011, Ming Lei wrote:
> Hi,
>
> On Wed, Jul 13, 2011 at 11:20 PM, Alan Stern
> wrote:
>
> > Why should system suspend be different from runtime suspend? �Have you
>
> This is also my puzzle, :-)
>
> > compared usbmon traces for the tw
On Thu, 14 Jul 2011, Ming Lei wrote:
> Hi,
>
> On Wed, Jul 13, 2011 at 11:59 PM, Alan Stern
> wrote:
> > On Wed, 13 Jul 2011, Ming Lei wrote:
>
> >> Almost same.
> >
> > Come on. �"Almost same" means they are different. �That difference
On Fri, 15 Jul 2011, Ming Lei wrote:
> Hi,
>
> On Thu, Jul 14, 2011 at 11:03 PM, Alan Stern
> wrote:
>
> > More likely, the reset erases some device setting that uvcvideo
> > installed while binding. �Evidently uvcvideo does not re-install the
> > setting duri
On Fri, 15 Jul 2011, Ming Lei wrote:
> Hi,
>
> On Fri, Jul 15, 2011 at 10:27 PM, Alan Stern
> wrote:
>
> > This is fine with me. �However, it is strange that the Set-Interface
> > request is necessary. �After being reset, the device should
> > automat
his long standing bug is really nasty and makes permanent high speed usb
> connections unusable on Linux,
> at least with this VIA hardware.
>
> No debug parms in modules, we need to ask linux-usb how to debug this.
You can start by building a kernel with CONFIG_USB_DEBUG enabled.
A
On Sun, 13 Jun 2010, thomas schorpp wrote:
> Am 13.06.2010 15:57, schrieb Alan Stern:
> > On Sun, 13 Jun 2010, thomas schorpp wrote:
> >
> >> ehci-hcd is broken and halts silently or disconnects after hours or a few
> >> days, with the wlan usb adapter
> >
and restore sensor registers before they are
> powered down and after they are powered up.
This patch is not correct as it stands. If you use runtime PM then the
system PM resume method has to be changed. See the discussion in
section 6 of Documentation/power/runtime_pm.txt.
Alan Stern
--
On Tue, 9 Feb 2010, Guennadi Liakhovetski wrote:
> On Tue, 9 Feb 2010, Alan Stern wrote:
>
> > On Mon, 8 Feb 2010, Guennadi Liakhovetski wrote:
> >
> > > To save power soc-camera powers subdevices down, when they are not in
> > > use,
> > > if th
; usb_set_interface() is called. That needs to be fixed in all the USB
> video drivers.
>
> I figured out how to patch the gspca driver, but not uvcvideo. The
> patch looks a bit hackish; can with experience with that driver look it
> over? Can anyone tell me where to look for th
camera mode
> switching because that code could potentially get called on any in use USB
> device and if it does even thing like lsusb don't work correctly afterwards
> and completely unrelated devices don't work if they are later plugged into
> the
> same USB port.
Th
and address
> 106
> [11080.688322] hub 1-0:1.0: unable to enumerate USB device on port 4
The dmesg log is relatively uninformative unless you enable
CONFIG_USB_DEBUG in the kernel build.
Have you tried running these tests on a different computer, preferably
one using a different chipset?
A
at Hans was suggesting, today we have to merge
two separate drivers... then tomorrow we would have to merge two others
and then later on even more. Before you know it, we would end up with
a single gigantic kernel driver to manage every USB device! Obviously
not a sustainable approach in the long run.
On Mon, 8 Aug 2011, Theodore Kilgore wrote:
> On Mon, 8 Aug 2011, Alan Stern wrote:
>
> > On Sun, 7 Aug 2011, Theodore Kilgore wrote:
> >
> > > This indirectly answers my question, above, about whatever device there
> > > may or may not be. What I get from t
st ask
the program.
> Incidentally, I think that in some respects the fact that webcam support
> is in the kernel and stillcam support is in userspace is a red herring.
No, this has some significant implications. In particular, there's no
good way for the kernel driver to ask the userspace driver if it is
busy. If both drivers were in the kernel, this would be easy to
arrange.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
rent devices use four different vendor-specific
drivers. Does it really make sense to combine 5 drivers into one? I
think some sort of sharing protocol would work out better.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message
On Tue, 9 Aug 2011, Hans de Goede wrote:
> Hi,
>
> On 08/09/2011 04:19 PM, Alan Stern wrote:
> > On Tue, 9 Aug 2011, Hans de Goede wrote:
> > According to Theodore, we have developed 5 drivers for them because the
> > stillcam modes in different devices use fou
,
resets, and disconnects. Assuming usbfs is the only driver that will
want to share a device in this way, we could handle them.
Hans, what do you think?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
re time, the program should be able to assume
the device's state hasn't changed.
I'm not claiming that this is a better solution than putting everything
in the kernel. Just that it is a workable alternative which would
involve a lot less coding.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
gt; at the appropriate times must be a lot easier than porting the entire
> > driver into the kernel.
>
> Again, applications that won't implement this control will take the lock
> forever.
No, because there is no lock. Programs that haven't been changed will
continue to
dentical too.
I'm not against moving the whole thing into the kernel. I'm just
pointing out that an easier-to-code-up solution will accomplish much
the same result.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
No, I'm not going to Vancouver. However I will attend the Linux
Plumbers conference in Santa Rosa.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
uess that what I'm trying to say here is, that if we are going to
> spend a significant amount of time on this, we might just as well
> go for the best solution we can come up with even if that is some
> more work.
Okay, go ahead. I have no objection.
Alan Stern
--
To unsubscribe from
On Sun, 18 Aug 2013, Geert Uytterhoeven wrote:
> On Thu, Jul 11, 2013 at 1:12 AM, Arnd Bergmann wrote:
> > On Wednesday 10 July 2013, Alan Stern wrote:
> >> This isn't right. There are USB host controllers that use PIO, not
> >> DMA. The HAS_DMA dependency shou
nded_time:5324088
> runtime_usage:0
This all looks correct.
> Any ideas?
You might get more information from a kernel with CONFIG_USB_DEBUG
enabled. Especially if you add
#define VERBOSE_DEBUG
to drivers/usb/core/driver.c before the first #include line.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 22 Sep 2013, Marc MERLIN wrote:
> On Sun, Sep 22, 2013 at 12:38:56PM -0400, Alan Stern wrote:
> > > gandalfthegreat:/sys/bus/usb/devices/3-1.6/power# grep . *
> > > active_duration:61227648
> > > async:enabled
> > > autosuspend:2
> > > au
w
parameters applied to an endpoint in several altsettings, it will have
to change each altsetting separately.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
o, then usb_change_ep_bandwidth() as a quirk, if bInterval
> or wMaxPacketSize were improperly filled.
>
> Right?
Or if the values are correct, but the driver wants to use something
different for its own reasons (for example, to get lower latency or
because it knows that it will never use pac
usting the streaming
> video resolution selected, right?
We haven't decided on the final API yet. However, note that
usb_alloc_urb() doesn't depend on the packet size. It requires you to
specify only the number of packets, not their sizes. Therefore it
doesn't matter whether you call us
iver unbinds, correct?
Absolutely. When the next driver binds, it should get the default
values (i.e., the ones stored in the descriptors). This would be
analogous to the way we currently set each interface back to altsetting
0 when a driver unbinds.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2 Oct 2013, Alan Stern wrote:
> > Ok, so it sounds like we want to keep the changes the endpoints across
> > alt setting changes.
>
> No, just the opposite. That was the point I was trying to make. Any
> changes to ep5 in altsetting 0 (for example) will
s this then
> still needed ?
We moved to handling URB completions in a tasklet, not a threaded
handler. (Similar idea, though.) And the change was made in only one
or two HCDs, not in all of them.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" i
On Wed, 9 Sep 2015, Hans de Goede wrote:
> Hi,
>
> On 08-09-15 16:36, Alan Stern wrote:
> > On Tue, 8 Sep 2015, Hans de Goede wrote:
> >
> >> Hi,
> >>
> >> On 09/07/2015 06:23 PM, Mian Yousaf Kaukab wrote:
> >>> urb completion callback
On Wed, 9 Sep 2015, Laurent Pinchart wrote:
> On Wednesday 09 September 2015 10:30:12 Hans de Goede wrote:
> > On 08-09-15 16:36, Alan Stern wrote:
> > > On Tue, 8 Sep 2015, Hans de Goede wrote:
> > >> On 09/07/2015 06:23 PM, Mian Yousaf Kaukab wrote:
> > >
rs to work queues when the long term goal is
> to use tasklets for URB completion anyway.
I'm not sure that this is a long-term goal for every HCD. For
instance, there probably isn't much incentive to convert a driver if
its host controllers can only run at low speed or full speed.
Alan
the best ways to ensure this are (1) audit the code, and
(2) actually try it.
I have a feeling this doesn't quite answer your question, however. :-)
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.ke
On Fri, 25 Nov 2016, Sakari Ailus wrote:
> Hi Alan and others,
>
> On Thu, Nov 24, 2016 at 09:15:39PM -0500, Alan Stern wrote:
> > On Fri, 25 Nov 2016, Laurent Pinchart wrote:
> >
> > > Dear linux-pm developers, what's the suggested way to ensure that a
>
On Fri, 25 Nov 2016, Laurent Pinchart wrote:
> Hi Alan,
Hello.
> On Friday 25 Nov 2016 10:21:21 Alan Stern wrote:
> > On Fri, 25 Nov 2016, Sakari Ailus wrote:
> > > On Thu, Nov 24, 2016 at 09:15:39PM -0500, Alan Stern wrote:
> > >> On Fri, 25 Nov 2016, Laurent P
1 - 100 of 150 matches
Mail list logo
