On 9/24/2012 12:13 AM, Alan Stern wrote:
> Therefore all we need is an API for individual devices, not for
> domains. Of course, userspace may want to know which devices all
> belong to the same power domain.
agreed on both.
I'd like PowerTOP to be able to report at least who keeps power alive a
On 9/23/2012 8:33 PM, Rafael J. Wysocki wrote:
> On Sunday, September 23, 2012, Peter Stuge wrote:
>> Rafael J. Wysocki wrote:
>>> Well, we actually need to handle power domains appropriately.
>> ..
>>> Some work in that direction has been done in the ARM space, where we have
>>> much more direct a
> -Original Message-
> From: ABRAHAM, KISHON VIJAY [mailto:kis...@ti.com]
> Sent: Monday, September 24, 2012 11:48 AM
> To: Venu Byravarasu
> Cc: Stephen Warren; ba...@ti.com; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; linux-usb@vger.kernel.org
> Subject: Re: [PATCH v3] US
Hi,
On Sat, Sep 22, 2012 at 2:08 PM, Venu Byravarasu wrote:
>> -Original Message-
>> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
>> Sent: Friday, September 21, 2012 9:45 PM
>> To: ABRAHAM, KISHON VIJAY
>> Cc: Venu Byravarasu; ba...@ti.com; gre...@linuxfoundation.org; linux-
>> ker
On Sun, 23 Sep 2012, Peter Stuge wrote:
> For starters I would like an API that sets a power domain on or off.
>
> I think that would be the simplest API, and maybe a good place to
> start. There is definitely room for more complex API as well, getting
> into various policies and so on, but to be
Rafael J. Wysocki wrote:
> > Is there already an API for power domains there? What does it look like?
>
> Yes, there is, as it turns out. :-)
>
> Please see drivers/base/power/domain.c and include/linux/pm_domain.h.
>
> Of course, this only covers a limited set of use cases at the moment, but I
Fixes the following NULL pointer dereference:
[7.74] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[7.81] Unable to handle kernel NULL pointer dereference at virtual
address 0028
[7.81] pgd = c3a38000
[7.81] [0028] *pgd=23a8c831, *pte=, *ppt
On Sunday 23 September 2012 12:23:40 Alan Stern wrote:
> It turns out that the USB-2 spec does not take into account the
> The race _was_ recognized in one of the errata documents published
> after the USB-2.0 spec came out. The solution recommended in that
link?
> document is exactly wrong!
On Sunday, September 23, 2012, Lan Tianyu wrote:
> 于 2012/9/22 20:08, Rafael J. Wysocki 写道:
> > So, my current idea is why don't we handle that through PM QoS? I mean we
> > have
> > a means to specify per-device PM QoS wakeup latency constraits and expose
> > it to
> > user space on a per-devic
On Sunday, September 23, 2012, Peter Stuge wrote:
> Rafael J. Wysocki wrote:
> > Well, we actually need to handle power domains appropriately.
> ..
> > Some work in that direction has been done in the ARM space, where we have
> > much more direct access to hardware, and I suppose it may be extended
On Sunday, September 23, 2012, Lan Tianyu wrote:
> 于 2012/9/23 3:54, Rafael J. Wysocki 写道:
> > On Friday, September 21, 2012, Peter Stuge wrote:
> >> Sarah Sharp wrote:
> > If userspace really wants the port off (e.g. to disconnect and
> > reconnect a misbehaving device), then it can set th
On Mon, Sep 24, 2012 at 12:51 AM, Alan Stern wrote:
> On Sun, 23 Sep 2012, Ming Lei wrote:
>
>> > In fact, sometimes new connected device _does_ mean there will be
>> > another new connection in the next few seconds. This happens because
>>
>> Looks I should have made it clearer, and I mean the p
On Sun, 23 Sep 2012, Ming Lei wrote:
> > In fact, sometimes new connected device _does_ mean there will be
> > another new connection in the next few seconds. This happens because
>
> Looks I should have made it clearer, and I mean the physical device
> connection or disconnection, eg, device pl
It turns out that the USB-2 spec does not take into account the
possibility of the race between a hub being suspended and one of its
ports receiving a remote wakeup request from downstream. The
flowcharts and discussions in Chapter 11 ignore the possibility
completely. Depending on how closely a
On Sun, 23 Sep 2012, Ming Lei wrote:
> >> @@ -3192,6 +3214,15 @@ static int hub_suspend(struct usb_interface *intf,
> >> pm_message_t msg)
> >>
> >> /* stop khubd and related activity */
> >> hub_quiesce(hub, HUB_SUSPEND);
> >> +
> >> + if (PMSG_IS_AUTO(msg) && hub->quirk_check_po
On Sun, 23 Sep 2012, Adrian Sandu wrote:
> Hi peeps,
>
> For the past day or so I've been trying to get my usb hub to work with
> my asrock 152d and failed.
> After a while it crossed my mind to try it out on my vaio vpcf13m1e's
> usb3 port .. worked like a charm.
> Both the nettop and my laptop
于 2012/9/23 3:54, Rafael J. Wysocki 写道:
On Friday, September 21, 2012, Peter Stuge wrote:
Sarah Sharp wrote:
If userspace really wants the port off (e.g. to disconnect and
reconnect a misbehaving device), then it can set the sysfs file
to off.
And unless all ganged ports are also off it will
于 2012/9/22 20:08, Rafael J. Wysocki 写道:
So, my current idea is why don't we handle that through PM QoS? I mean we have
a means to specify per-device PM QoS wakeup latency constraits and expose it to
user space on a per-device basis. I suppose we can we can handle the
"don't remove power from t
Hi peeps,
For the past day or so I've been trying to get my usb hub to work with
my asrock 152d and failed.
After a while it crossed my mind to try it out on my vaio vpcf13m1e's
usb3 port .. worked like a charm.
Both the nettop and my laptop seem to have the same usb3 chipset: "NEC
Corporation uPD
On Sun, Sep 23, 2012 at 12:01 AM, Alan Stern wrote:
> On Sat, 22 Sep 2012, Ming Lei wrote:
>
>> This patch sets hub device's default autosuspend delay as 0 to
>> speedup bus suspend, see comments in code for details.
>>
>> Signed-off-by: Ming Lei
>> ---
>> drivers/usb/core/hub.c | 38 +
On Sat, Sep 22, 2012 at 11:48 PM, Alan Stern wrote:
>
> This is basically okay. I have a couple of suggestions.
Thanks for your suggestion.
>
>> @@ -3192,6 +3214,15 @@ static int hub_suspend(struct usb_interface *intf,
>> pm_message_t msg)
>>
>> /* stop khubd and related activity */
>>
P4200: test ok:
udev/usbmodeswitch and this patch made the modem usable without user-interaction
# dmesg
[ 127.708165] usb 1-1: new high-speed USB device number 3 using ehci_hcd
[ 127.843187] usb 1-1: New USB device found, idVendor=106c, idProduct=3b14
[ 127.843201] usb 1-1: New USB device st
Rafael J. Wysocki wrote:
> Well, we actually need to handle power domains appropriately.
..
> Some work in that direction has been done in the ARM space, where we have
> much more direct access to hardware, and I suppose it may be extended to
> things like "ganged sets of ports" (which actually are
TIAO/DIYGADGET USB Multi-Protocol Adapter (TUMPA) is an FTDI FT2232H
based device which provides an easily accessible JTAG, SPI, I2C, serial
breakout.
http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
http://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User%27
24 matches
Mail list logo
