Re: Power-managing devices that are not of interest at some point in time

On Friday, July 18, 2014 04:16:50 PM Dmitry Torokhov wrote: > On Saturday, July 19, 2014 12:55:09 AM Rafael J. Wysocki wrote: > > On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote: > > > On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote: > > > > On Friday, July 18, 2014 11:59:

Re: Power-managing devices that are not of interest at some point in time

On Saturday, July 19, 2014 12:55:09 AM Rafael J. Wysocki wrote: > On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote: > > On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote: > > > On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote: > > > > On Friday, July 18, 2014 02:2

Re: [PATCH 1/2] input: wacom: Support up to 2048 pressure levels with ISDv4

On Mon, Jun 30, 2014 at 2:46 PM, Jason Gerecke wrote: > Signed-off-by: Jason Gerecke > --- > drivers/input/tablet/wacom_wac.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/input/tablet/wacom_wac.c > b/drivers/input/tablet/wacom_wac.c > index 977d05c..61a45a5 1

Re: Power-managing devices that are not of interest at some point in time

On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote: > On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote: > > On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote: > > > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote: > > > > On Friday, July 18, 2014 04:09:46

Re: Power-managing devices that are not of interest at some point in time

On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote: > On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote: > > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote: > > > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote: > > > > On Fri, 18 Jul 2014, Patrik Fimml wrote: >

Re: Power-managing devices that are not of interest at some point in time

On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote: > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote: > > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote: > > > On Fri, 18 Jul 2014, Patrik Fimml wrote: > > > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote: >

Re: Power-managing devices that are not of interest at some point in time

On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote: > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote: > > On Fri, 18 Jul 2014, Patrik Fimml wrote: > > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote: [cut] > > > I'm not sure what the appropriate action for a video came

Re: Power-managing devices that are not of interest at some point in time

On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote: > On Fri, 18 Jul 2014, Patrik Fimml wrote: > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote: > > > "Quiescing" is the wrong word. "Quiescing a device" means stopping the > > > device from doing anything, which isn't what you want

Re: Power-managing devices that are not of interest at some point in time

On Fri, 18 Jul 2014, Patrik Fimml wrote: > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote: > > "Quiescing" is the wrong word. "Quiescing a device" means stopping the > > device from doing anything, which isn't what you want. You want to > > ignore any activity the device may generate

Re: Power-managing devices that are not of interest at some point in time

On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote: > "Quiescing" is the wrong word. "Quiescing a device" means stopping the > device from doing anything, which isn't what you want. You want to > ignore any activity the device may generate and reduce the device's > power consumption as mu

Re: Power-managing devices that are not of interest at some point in time

On Fri, 18 Jul 2014, Patrik Fimml wrote: > 2. Give userspace a way of quiescing a device. Handles to the device > stay open, but the device will no longer perform its function and, > if possible, power down. "Quiescing" is the wrong word. "Quiescing a device" means stopping the device f

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

On 07/18/2014 11:37 PM, Lennox Wu wrote: > Score can provide dummy functions if HAS_IOMEM and NO_IOMEM will be > removed, even if we indeed have no IOMEM. > Thank you for your reply, for score, your ideas is OK to me. And for the COMPILE_TEST needs still discussing below: > 2014-07-18 18:51 G

Re: Power-managing devices that are not of interest at some point in time

On Fri, Jul 18, 2014 at 02:43:02AM +0200, Rafael J. Wysocki wrote: > From past discussions on similar topics it followed that there really was > no generic way for individual drivers to quiesce devices on demand as long as > user space was running. Everything we could come up with was racy, this w

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

Score can provide dummy functions if HAS_IOMEM and NO_IOMEM will be removed, even if we indeed have no IOMEM. Best, Lennox 2014-07-18 18:51 GMT+08:00 Richard Weinberger : > Am 18.07.2014 12:44, schrieb Chen Gang: >> On 07/18/2014 03:35 PM, Richard Weinberger wrote: >>> Am 18.07.2014 02:36, schri

Re: Power-managing devices that are not of interest at some point in time

On Fri, 18 Jul 2014, Rafael J. Wysocki wrote: > > > the problem really seems to be that drivers are not > > > aggressive enough with starting PM transitions (using runtime PM) when > > > they > > > see no activity. Thus it seems that when the lid is closed, it'll be good > > > to switch the driv

Re: [PATCH] HID: rmi: only bind the hid-rmi driver to the mouse interface of composite USB devices

On Jul 17 2014 or thereabouts, Andrew Duggan wrote: > On composite HID devices there may be multiple HID devices on separate > interfaces, but hid-rmi > should only bind to the mouse interface. One example is the Dell Venue 11 > Pro's keyboard dock > which contains a composite USB device with a H

Re: [PATCH v2] HID: rmi: check that report ids exist in the report_id_hash before accessing their size

On Jul 17 2014 or thereabouts, Andrew Duggan wrote: > It is possible that the hid-rmi driver could get loaded onto a device which > does not have the > expected report ids. This should not happen because it would indicate that > the hid-rmi driver is > not compatible with that device. However, if

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

Am 18.07.2014 12:44, schrieb Chen Gang: > On 07/18/2014 03:35 PM, Richard Weinberger wrote: >> Am 18.07.2014 02:36, schrieb Chen Gang: >>> >>> On 07/18/2014 02:09 AM, Richard Weinberger wrote: Am 17.07.2014 12:48, schrieb Arnd Bergmann: > AFAICT, NO_IOMEM only has a real purpose on UML the

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

On 07/18/2014 03:35 PM, Richard Weinberger wrote: > Am 18.07.2014 02:36, schrieb Chen Gang: >> >> On 07/18/2014 02:09 AM, Richard Weinberger wrote: >>> Am 17.07.2014 12:48, schrieb Arnd Bergmann: AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and

Re: [PATCH v4 1/4] Rename hid-lenovo-tpkbd to hid-lenovo

On Mon, 14 Jul 2014, Antonio Ospite wrote: On Sun, 13 Jul 2014 08:24:19 +0100 Jamie Lentin wrote: Rename module and all functions within so we can add support for other keyboards in the same file. Rename the _tp postfix to _tpkbd, to signify functions relevant to the TP USB keyboard. Signed-

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

Am 18.07.2014 02:36, schrieb Chen Gang: > > On 07/18/2014 02:09 AM, Richard Weinberger wrote: >> Am 17.07.2014 12:48, schrieb Arnd Bergmann: >>> AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take >>> a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff