Oliver Neukum writes:
> On Monday 30 July 2012 22:35:37 Bjørn Mork wrote:
>> Sarah Sharp writes:
>>
>> > Possible solutions
>> > --
>> >
>> > - We need a new interface driver flag to indicate a driver is fine with
>> >the port being powered off. Something like "supports_powe
On Tuesday 31 July 2012 09:09:06 Bjørn Mork wrote:
> Oliver Neukum writes:
> > On Monday 30 July 2012 22:35:37 Bjørn Mork wrote:
> >> Sarah Sharp writes:
> > uvc, some hid, some storage devices.
>
> I don't know anything about storage devices, but forcing them to power
> off sounds scary to me.
Alan Stern writes:
> On Mon, 30 Jul 2012, Sarah Sharp wrote:
>
>> - I'm not sure if it's true that all devices that need firmware will
>>have USB_QUIRK_RESET_MORPHS set. Alan, Oliver?
>
> Probably not, and in any case the situation is more complex than it
> first appears. (In fact, I wonde
On Tue, Jul 31, 2012 at 09:06:33AM +0800, Chen Peter-B29397 wrote:
>
> > >
> > > <&usbmisc 0> would then mean port 0 of the usbmisc device.
> > I didn't add the restriction that a usbmisc driver must have a usbmisc
> > device. I'm not sure whether all SoC and future SoC can be look as
> > a devic
Hi Sarah,
Attached dmidecode output of Intense-PC.
Denis Turischev
On 07/31/2012 01:34 AM, Sarah Sharp wrote:
> Hi Denis,
>
> Can you send me the output of `sudo dmidecode`? I'd like to see if I
> can make a more general patch apply to the Intense-PC.
>
> Sarah Sharp
>
# dmidecode 2.11
SMBI
On 07/20/2012 09:33 AM, Marc Kleine-Budde wrote:
> Since commit "5e0aa49 usb: chipidea: use generic map/unmap routines",
> the udc part of the chipidea driver needs the generic usb gadget helper
> functions. If the chipidea driver with udc support is built into the
> kernel and usb gadget is built
On 31.07.2012 12:12, Joao Bonina wrote:
>
>
> It doesn't show anything when that happens.
Well, it shows:
[ 349.789200] hub 1-0:1.0: port 4 disabled by hub (EMI?), re-enabling...
I guess this about the time when the streaming stops? How does your USB
wiring setup look like and what kind of sy
You're right about the EMI message, it's happening when the streaming stops.
I've tried different cables before, but that didn't solve the problem.
The motherboard is an Alix 1D, and I'm using the onboard USB 2.0 ports.
If this really is an EMI issue, guess I'll have to source some kind of
mini
On 07/30/2012 10:06 AM, Colin Ian King wrote:
> The default 10 microsecond delay for the controller to come out of
> halt in dbgp_ehci_startup is too short, so increase it to 1 millisecond.
>
> This is based on emperical testing on various USB debug ports on
> modern machines such as a Lenovo X220i
Hi,
On Fri, Jul 27, 2012 at 02:01:59PM +0530, Ravi B wrote:
> From: Ajay Kumar Gupta
>
> AM335x and TI81xx platform has dual musb controller so updating the
> musb_dspc.c to support the same.
>
> Changes:
> - Moved otg_workaround timer to glue structure
> - Moved static local variab
> Hi,
>
> On Fri, Jul 27, 2012 at 02:01:59PM +0530, Ravi B wrote:
> > From: Ajay Kumar Gupta
> >
> > AM335x and TI81xx platform has dual musb controller so updating the
> > musb_dspc.c to support the same.
> >
> > Changes:
> > - Moved otg_workaround timer to glue structure
> > - Moved
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 settings across a reset
> but lose them when power is removed.
True. So an addit
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in email?
On 31.07.2012 14:04, Joao Bonina wrote:
> You're right about the EMI message, it's happening when the streaming stops.
>
> I'v
On Tue, 31 Jul 2012, Joao Bonina wrote:
> You're right about the EMI message, it's happening when the streaming stops.
>
> I've tried different cables before, but that didn't solve the problem.
>
> The motherboard is an Alix 1D, and I'm using the onboard USB 2.0 ports.
>
> If this really is an
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 will fail.
> At the same time, print
On Tue, 31 Jul 2012, Bjørn Mork wrote:
> Alan Stern writes:
> > On Mon, 30 Jul 2012, Sarah Sharp wrote:
> >
> >> - I'm not sure if it's true that all devices that need firmware will
> >>have USB_QUIRK_RESET_MORPHS set. Alan, Oliver?
> >
> > Probably not, and in any case the situation is mor
Alan Stern writes:
> On Tue, 31 Jul 2012, Bjørn Mork wrote:
>
>> IMHO that should have been the default for any composite device, but
>> whatever.. I don't think it's very nice of usb-storage to reset the
>> device if there are drivers bound to other functions.
>
> That's why we have pre_reset an
On Tuesday 31 July 2012 16:54:13 Bjørn Mork wrote:
> Alan Stern writes:
> > On Tue, 31 Jul 2012, Bjørn Mork wrote:
> >
> >> IMHO that should have been the default for any composite device, but
> >> whatever.. I don't think it's very nice of usb-storage to reset the
> >> device if there are driver
On Tue, Jul 31, 2012 at 01:16:01PM +0200, Marc Kleine-Budde wrote:
> On 07/20/2012 09:33 AM, Marc Kleine-Budde wrote:
> > Since commit "5e0aa49 usb: chipidea: use generic map/unmap routines",
> > the udc part of the chipidea driver needs the generic usb gadget helper
> > functions. If the chipidea
On 07/31/2012 05:21 PM, Greg KH wrote:
[...]
>>> Hello Greg,
>>>
>>> rebased to your usb-next tree.
>>
>> ping
>
> You just pinged yourself? That's odd :)
You're on Cc, and it actually worked :)
>
> Anyway, I'll get to it after 3.6-rc1 is out.
tnx,
Marc
--
Pengutronix e.K.
On Tue, 31 Jul 2012, Bjørn Mork wrote:
> Alan Stern writes:
> > On Tue, 31 Jul 2012, Bjørn Mork wrote:
> >
> >> IMHO that should have been the default for any composite device, but
> >> whatever.. I don't think it's very nice of usb-storage to reset the
> >> device if there are drivers bound to
On Tue, 31 Jul 2012, Oliver Neukum wrote:
> > Well, you are then saying that usb-storage has priority over any other
> > function and that is often wrong IMHO. There are many newer composite
> > devices where the usb-storage function is thrown in as a bonus most
> > users never will touch, where
On Mon, 30 Jul 2012, Kuninori Morimoto wrote:
> 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/usb/host/ehci-platform.c |6 ++
> 1 files changed, 6 insertion
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 settings across a reset
> >
On Tue, Jul 31, 2012 at 06:49:50AM +0200, Oliver Neukum wrote:
> On Monday 30 July 2012 15:34:06 Sarah Sharp wrote:
> > Hi Denis,
> >
> > Can you send me the output of `sudo dmidecode`? I'd like to see if I
> > can make a more general patch apply to the Intense-PC.
>
> As this is for shutdown, w
On Tue, 31 Jul 2012, Huang Ying wrote:
> > What happens when you run lspci and the device is in D3cold? Then even
> > if the parent bridge is active, lspci will still fail.
> >
> > It seems that in this case you need to resume the device itself, not
> > just its parent.
>
> How about the foll
Hello,
I'm trying to get a Zytronic single-touch touchscreen to work with Linux
kernel 3.5; it previously worked on a 3.0 kernel. I'm happy to try git kernels
and patches, even if they're just intended to gather more information.
hid-multitouch is picking up the device because it has multitouch
On Mon, Jul 30, 2012 at 10:27:08PM +0200, Oliver Neukum wrote:
> On Monday 30 July 2012 13:00:18 Sarah Sharp wrote:
>
> > So far, the discussion on the mailing list seems to boil down to:
> >
> > Issues
> > --
> >
> > - We need to issue a reset resume for all suspended devices that have
> >
On Mon, Jul 30, 2012 at 10:35:37PM +0200, Bjørn Mork wrote:
> Sarah Sharp writes:
> > - In addition to the port power sysfs values of "on" or "off", we also
> >need an "auto" value that attempts to apply a smart in-kernel policy
> >to when to power off the port. That policy might look li
On Tuesday 31 July 2012 11:49:29 Alan Stern wrote:
> On Tue, 31 Jul 2012, Bjørn Mork wrote:
>
> > Well, you are then saying that usb-storage has priority over any other
> > function and that is often wrong IMHO.
>
> No, I'm not saying that at all. The situation is perfectly symmetric.
Well, th
On Mon, Jul 30, 2012 at 05:03:27PM -0400, Alan Stern wrote:
> On Mon, 30 Jul 2012, Sarah Sharp wrote:
> > Possible solutions
> > --
> >
> > - We need a new interface driver flag to indicate a driver is fine with
> >the port being powered off. Something like "supports_power_of
On Tue, Jul 31, 2012 at 10:06:34AM -0700, Sarah Sharp wrote:
> On Tue, Jul 31, 2012 at 06:49:50AM +0200, Oliver Neukum wrote:
> > On Monday 30 July 2012 15:34:06 Sarah Sharp wrote:
> > > Hi Denis,
> > >
> > > Can you send me the output of `sudo dmidecode`? I'd like to see if I
> > > can make a mo
On Tue, 31 Jul 2012, Sarah Sharp wrote:
> > It should also apply to ports of hubs in compound devices.
>
> The port power off behavior is different for those hubs,
Are you sure about that?
> so I want to
> address that later. For USB 2.0 hubs, doesn't it detect connect events
> if you power o
On Tue, Jul 31, 2012 at 01:02:43PM -0400, Alan Stern wrote:
> I don't know. I can't think of anything more, but there's a nagging
> feeling that if we use these then something will go wrong.
>
> How about if we start with only the first policy rule: Ports that can
> never have anything plugged
On Tuesday 31 July 2012 14:46:38 Alan Stern wrote:
> > > It is not obvious that external ports should be handled like internal
> > > ports.
>
> Why not? The important criterion is whether the port is connectable,
> not whether it is internal.
That doesn't mean it should be handled differently a
On Tue, 31 Jul 2012, Sarah Sharp wrote:
> > >1. If the device is internal and unpluggable, power off the port
> >
> > That doesn't sound right. Don't you mean: If the port is internal and
> > not pluggable and there is no device attached, power off the port?
>
> If there's a device attache
On Tue, 31 Jul 2012, Sarah Sharp wrote:
> On Tue, Jul 31, 2012 at 01:02:43PM -0400, Alan Stern wrote:
> > I don't know. I can't think of anything more, but there's a nagging
> > feeling that if we use these then something will go wrong.
> >
> > How about if we start with only the first policy r
On Tue, 31 Jul 2012, Oliver Neukum wrote:
> > Another alternative is for the other drivers to delay the reset (by
> > sleeping in their pre_reset callbacks) until they can handle the reset
> > safely.
>
> No! You must not ever do that!
>
> The reset is a part of the error handling path of the
On Tue, 31 Jul 2012, Oliver Neukum wrote:
> Which opens up an opportunity for optimisation. Should we disable
> polling for new media on card readers that are internal and connectable
> and have only one LUN?
Considering that we don't know which devices are card readers or
whether they disconnec
On Tuesday 31 July 2012 15:42:51 Alan Stern wrote:
> On Tue, 31 Jul 2012, Oliver Neukum wrote:
>
> > > Another alternative is for the other drivers to delay the reset (by
> > > sleeping in their pre_reset callbacks) until they can handle the reset
> > > safely.
> >
> > No! You must not ever do
On Sunday, July 29, 2012, Rafael J. Wysocki wrote:
> On Sunday, July 29, 2012, Alan Stern wrote:
> > On Sun, 29 Jul 2012, Rafael J. Wysocki wrote:
> >
> > > The difference is, if you use _put_sync(), you need to wait the extra 10
> > > ms
> > > for local_pci_probe() to return (if the parent is ac
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 at the Microsoft page on th
[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 usefulness of it is quite questionable, because
> either we want to resume the device immediately, for which
> pm_runtime_ge
On Tue, 31 Jul 2012, Alan Stern wrote:
> "PortIsConnectable" means it's possible for a device to be
> connected (either temporarily or permanently).
>
> "UserVisible" means the user can freely plug and unplug
> devices.
>
> In addition to these ACPI definitions, the USB
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
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 usefulness of it is quite questionable,
> > because
> > either we w
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 irq disabled (the result
of spin_lock_irqsave) for CPU B
On Tue, Jul 31, 2012 at 04:19:48PM -0500, Alexis Cortes wrote:
That's some "From:" line in your patch, are you sure that is right?
> 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
On Tuesday, July 31, 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 us
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
On Tue, Jul 31, 2012 at 05:54:04PM -0500, Alexis Cortes wrote:
> Hi Greg,
>
> I have resent the patch. Hopefully it know arrives properly. BTW, I'm using
> Thunderbird configured as described in Documentation/email-clients.txt for
> sending the patch.
The resend looks like it worked properly, tha
On Tue, Jul 31, 2012 at 05:48:38PM -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,
> and if that happens on the first inserti
On Tue, Jul 31, 2012 at 05:52:52PM +0100, Simon Farnsworth wrote:
> Hello,
>
> I'm trying to get a Zytronic single-touch touchscreen to work with Linux
> kernel 3.5; it previously worked on a 3.0 kernel. I'm happy to try git
> kernels
> and patches, even if they're just intended to gather more
From: fangxiaozhi
1. This patch is based on the kernel of 3.5
2. In this patch, we add new micro for matching the series USB devices with
vendor ID and interface information.
3. In this patch, we add new declarations into option.c to support the new
interfaces of Huawei Data Card devices. And
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/usb/host/ehci-platform.c |6 ++
> > 1 files changed, 6 insertions(+),
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/usb/host/ehci-platform.c |6 ++
> > > 1 files changed, 6
usbmisc driver handles the SoC specific non-core usb registers.
Changes since last version:
- rebase onto torvalds latest git tree
- use phandle linke usb controllers and usbmisc device.
It also make usbmisc driver possible to be kernel modules.
Richard Zhao (3):
USB: chipidea: add imx usb
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
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
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(+)
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts
b/ar
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 USB communication
>>> should happen in the backgro
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 trying the same
out and got confused because the data arriving from a real video capture
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 trying the same
out and got confused because the data arriving from a real video capture
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 Shayevitz'; 'Felipe Balbi'; linux-usb@vger.kernel.org
> Subject: RE: [RFC/PAT
On Wed, Aug 01, 2012 at 10:51:07AM +0800, Richard Zhao wrote:
> 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-
On Mon, Jul 30, 2012 at 2:57 AM, Alan Stern wrote:
>
> On Sun, 29 Jul 2012, Rajaram R wrote:
>
> > > The ep list doesn't belong to the gadget driver; it belongs to the UDC
> > > driver. The maxpacket has to be adjusted to match the value stored in
> > > the descriptor so that the UDC will tell th
> Could it be that something is missing in this patch? I don't see struct
> usbmisc_usb_device defined anywhere in this patch.
ah, Sorry I missed the header file. I'll send a new version.
Thanks
Richard
>
> Sascha
>
> --
> Pengutronix e.K. |
67 matches
Mail list logo
