headers
Eduardo Valentin | 1 Apr 2012 21:13
Picon
Favicon

Re: [PATCH 17/76] thermal_sys: convert printks to pr_<level>

Hello Joe,

On Fri, Mar 30, 2012 at 12:08:50PM -0700, Joe Perches wrote:
> On Fri, 2012-03-30 at 16:41 +0300, Eduardo Valentin wrote:
> > On Fri, Mar 30, 2012 at 06:13:20AM -0400, Len Brown wrote:
> > > From: Joe Perches <joe <at> perches.com>
> > > Use the current logging style.
> []
> > We should get the struct dev in thermal_zone_device, I think it makes
> > more sense to use the dev_* helper functions.
> []
> > The orig argument could probably be changed to a thermal zone device
> > and the we use it's id as orig for the message.
> > What do you think?
> 
> dev_<level> should be used instead of pr_<level> when
> an appropriate struct device * is available.

Agreed that we need a struct device *. My comments are based on the fact
that you have one of it inside the struct therma_zone_device, field device.

Isn't that struct device appropriated enough to be used by the dev_* functions?

> 
> cheers, Joe
> 

Cheers,

Eduardo
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Lezcano | 2 Apr 2012 14:48
Favicon

[PATCH][V2] cpuidle : use percpu cpuidle in the core code

The usual cpuidle initialization routines are to register the
driver, then register a cpuidle device per cpu.

With the device's state count default initialization with the
driver's state count, the code initialization remains mostly the
same in the different drivers.

We can then add a new function 'cpuidle_register' where we register
the driver and the devices. These devices can be defined in a global
static variable in cpuidle.c. We will be able to factor out and
remove a lot of duplicate lines of code.

As we still have some drivers, with different initialization routines,
we keep 'cpuidle_register_driver' and 'cpuidle_register_device' as low
level initialization routines to do some specific operations on the
cpuidle devices.

Signed-off-by: Daniel Lezcano <daniel.lezcano <at> linaro.org>
---
 drivers/cpuidle/cpuidle.c |   42 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/cpuidle.h   |    3 +++
 2 files changed, 45 insertions(+), 0 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 87411ce..151c55a 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
 <at>  <at>  -23,6 +23,7  <at>  <at> 
 #include "cpuidle.h"
(Continue reading)

Permalink | Reply | 3 comments |
headers
Srivatsa S. Bhat | 2 Apr 2012 15:21
Picon

Re: [PATCH][V2] cpuidle : use percpu cpuidle in the core code

On 04/02/2012 06:18 PM, Daniel Lezcano wrote:

> The usual cpuidle initialization routines are to register the
> driver, then register a cpuidle device per cpu.
> 
> With the device's state count default initialization with the
> driver's state count, the code initialization remains mostly the
> same in the different drivers.
> 
> We can then add a new function 'cpuidle_register' where we register
> the driver and the devices. These devices can be defined in a global
> static variable in cpuidle.c. We will be able to factor out and
> remove a lot of duplicate lines of code.
> 
> As we still have some drivers, with different initialization routines,
> we keep 'cpuidle_register_driver' and 'cpuidle_register_device' as low
> level initialization routines to do some specific operations on the
> cpuidle devices.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano <at> linaro.org>

> +/*
> + * cpuidle_register : register cpuidle driver and devices
> + * Note this function must be called after smp_init.
> + *  <at> drv : the cpuidle driver
> + * Returns 0 on success, < 0 otherwise
> + */
> +int cpuidle_register(struct cpuidle_driver *drv)
> +{
> +	int ret, cpu, i;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Lezcano | 2 Apr 2012 15:46
Favicon

Re: [PATCH][V2] cpuidle : use percpu cpuidle in the core code

On 04/02/2012 03:21 PM, Srivatsa S. Bhat wrote:
> On 04/02/2012 06:18 PM, Daniel Lezcano wrote:
>
>> The usual cpuidle initialization routines are to register the
>> driver, then register a cpuidle device per cpu.
>>
>> With the device's state count default initialization with the
>> driver's state count, the code initialization remains mostly the
>> same in the different drivers.
>>
>> We can then add a new function 'cpuidle_register' where we register
>> the driver and the devices. These devices can be defined in a global
>> static variable in cpuidle.c. We will be able to factor out and
>> remove a lot of duplicate lines of code.
>>
>> As we still have some drivers, with different initialization routines,
>> we keep 'cpuidle_register_driver' and 'cpuidle_register_device' as low
>> level initialization routines to do some specific operations on the
>> cpuidle devices.
>>
>> Signed-off-by: Daniel Lezcano<daniel.lezcano <at> linaro.org>
>
>> +/*
>> + * cpuidle_register : register cpuidle driver and devices
>> + * Note this function must be called after smp_init.
>> + *  <at> drv : the cpuidle driver
>> + * Returns 0 on success,<  0 otherwise
>> + */
>> +int cpuidle_register(struct cpuidle_driver *drv)
>> +{
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Lezcano | 2 Apr 2012 21:20
Favicon

[PATCH][V3] cpuidle : use percpu cpuidle in the core code

The usual cpuidle initialization routines register the driver and
then register a cpuidle device per cpu.

By default, most drivers initialize the device state count with the
driver state count.

We can then add a new function 'cpuidle_register' where we register
the driver and the devices. These devices can be defined in a global
static variable in cpuidle.c. We will be able to factor out and
remove a lot of duplicate lines of code.

As we still have some drivers, with different initialization routines,
we keep 'cpuidle_register_driver' and 'cpuidle_register_device' as low
level initialization routines to do some specific operations on the
cpuidle devices.

Signed-off-by: Daniel Lezcano <daniel.lezcano <at> linaro.org>
---
 drivers/cpuidle/cpuidle.c |   42 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/cpuidle.h   |    3 +++
 2 files changed, 45 insertions(+), 0 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 87411ce..4d1f79b 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
 <at>  <at>  -23,6 +23,7  <at>  <at> 
 #include "cpuidle.h"

 DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
(Continue reading)

Permalink | Reply | 2 comments |
headers
Srivatsa S. Bhat | 3 Apr 2012 07:49
Picon

Re: [PATCH][V3] cpuidle : use percpu cpuidle in the core code

On 04/03/2012 12:50 AM, Daniel Lezcano wrote:

> The usual cpuidle initialization routines register the driver and
> then register a cpuidle device per cpu.
> 
> By default, most drivers initialize the device state count with the
> driver state count.
> 
> We can then add a new function 'cpuidle_register' where we register
> the driver and the devices. These devices can be defined in a global
> static variable in cpuidle.c. We will be able to factor out and
> remove a lot of duplicate lines of code.
> 
> As we still have some drivers, with different initialization routines,
> we keep 'cpuidle_register_driver' and 'cpuidle_register_device' as low
> level initialization routines to do some specific operations on the
> cpuidle devices.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano <at> linaro.org>

Looks good to me now.
Acked-by: Srivatsa S. Bhat <srivatsa.bhat <at> linux.vnet.ibm.com>

Regards,
Srivatsa S. Bhat

> ---
>  drivers/cpuidle/cpuidle.c |   42 ++++++++++++++++++++++++++++++++++++++++++
>  include/linux/cpuidle.h   |    3 +++
>  2 files changed, 45 insertions(+), 0 deletions(-)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Amit Kachhap | 4 Apr 2012 06:32
Favicon

Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform

Hi Len/Rui,

Any comment or feedback from your side about the status of this patch?
Is it merge-able or major re-work is needed? I have fixed most of the
comments in this patchset and currently working on some of the minor
comments received and will submit them shortly.

Regards,
Amit Daniel

On 19 March 2012 11:47, Amit Daniel Kachhap <amit.kachhap <at> linaro.org> wrote:
> Changes since V1:
> *Moved the sensor driver to driver/thermal folder from driver/hwmon folder
>  as suggested by Mark Brown and Guenter Roeck
> *Added notifier support to notify the registered drivers of any cpu cooling
>  action. The driver can modify the default cooling behaviour(eg set different
>  max clip frequency).
> *The percentage based frequency replaced with absolute clipped frequency.
> *Some more conditional checks when setting max frequency.
> *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
>  THERMAL_TRIP_STATE_INSTANCE
> *Many review comments from R, Durgadoss <durgadoss.r <at> intel.com> and
>  eduardo.valentin <at> ti.com implemented.
> *Removed cooling stats through debugfs patch
> *The V1 based can be found here,
>  https://lkml.org/lkml/2012/2/22/123
>  http://lkml.org/lkml/2012/3/3/32
>
> Changes since RFC:
> *Changed the cpu cooling registration/unregistration API's to instance based
(Continue reading)

Permalink | Reply | 4 comments |
headers
Eduardo Valentin | 4 Apr 2012 08:27
Picon
Favicon

Re: [PATCH 1/4] thermal: Add a new trip type to use cooling device instance number

Hello,

On Wed, Apr 04, 2012 at 09:53:15AM +0530, Amit Kachhap wrote:
> Hi Eduardo,
> 
> On 3 April 2012 19:45, Eduardo Valentin <eduardo.valentin <at> ti.com> wrote:
> > Hello,
> >
> > On Thu, Feb 23, 2012 at 04:50:14PM +0530, Amit Kachhap wrote:
> >> On 23 February 2012 12:16, R, Durgadoss <durgadoss.r <at> intel.com> wrote:
> >> > Hi Amit,
> >> >
> >> >> -----Original Message-----
> >> >> From: amit kachhap [mailto:amitdanielk <at> gmail.com] On Behalf Of Amit Daniel
> >> >> Kachhap
> >> >> Sent: Wednesday, February 22, 2012 3:44 PM
> >> >> To: linux-pm <at> lists.linux-foundation.org
> >> >> Cc: linux-kernel <at> vger.kernel.org; mjg59 <at> srcf.ucam.org; linux-
> >> >> acpi <at> vger.kernel.org; lenb <at> kernel.org; linaro-dev <at> lists.linaro.org;
> >> >> amit.kachhap <at> linaro.org; R, Durgadoss; rob.lee <at> linaro.org; patches <at> linaro.org
> >> >> Subject: [PATCH 1/4] thermal: Add a new trip type to use cooling device
> >> >> instance number
> >> >>
> >> >> This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
> >> >> trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
> >> >> device instance number. This helps the cooling device registered as
> >> >> different instances to perform appropriate cooling action decision in
> >> >> the set_cur_state call back function.
> >> >>
> >> >> Also since the trip temperature's are in ascending order so some logic
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg Kroah-Hartman | 4 Apr 2012 20:58
Gravatar

Re: [3.0.y, 3.2.y, 3.3.y] Re: [PATCH 04/76] ACPICA: Fix regression in FADT revision checks

On Tue, Apr 03, 2012 at 04:15:32PM -0400, Josh Boyer wrote:
> On Tue, Apr 3, 2012 at 3:58 PM, Jonathan Nieder <jrnieder <at> gmail.com> wrote:
> > Hi Greg,
> >
> > Josh Boyer wrote:
> >> On Fri, Mar 30, 2012 at 6:13 AM, Len Brown <lenb <at> kernel.org> wrote:
> >
> >>> From: Julian Anastasov <ja <at> ssi.bg>
> >>>
> >>>        commit 64b3db22c04586997ab4be46dd5a5b99f8a2d390 (2.6.39),
> >>> "Remove use of unreliable FADT revision field" causes regression
> >>> for old P4 systems because now cst_control and other fields are
> >>> not reset to 0.
> > [...]
> >>>        The fix is to update acpi_gbl_FADT.header.length after
> >>> the original value is used to check for old revisions.
> >>>
> >>> https://bugzilla.kernel.org/show_bug.cgi?id=42700
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=727865
> >>>
> >>> Signed-off-by: Julian Anastasov <ja <at> ssi.bg>
> >>> Acked-by: Bob Moore <robert.moore <at> intel.com>
> >>> Signed-off-by: Len Brown <len.brown <at> intel.com>
> >>
> >> This one should go into the stable trees.
> >
> > Please apply
> >
> >  3e80acd1af40 "ACPICA: Fix regression in FADT revision checks"
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Len Brown | 6 Apr 2012 19:18

[PATCH 1/1] Remove "mrst_pmu: driver for Intel Moorestown Power Management Unit"

From: Len Brown <len.brown <at> intel.com>

This reverts commit 22f4521d664030e417f41953e922f61c65f2e189.
and
This reverts commit 6dccf9c508d5d773859df1cc2dce75c5b19e35a0.

All customers of this product line are using a different driver,
currently out-of-tree, so there is no purpose in supporting
this version upstream.

Signed-off-by: Len Brown <len.brown <at> intel.com>
---
 MAINTAINERS                     |    6 -
 arch/x86/platform/mrst/Makefile |    1 -
 arch/x86/platform/mrst/pmu.c    |  817 ---------------------------------------
 arch/x86/platform/mrst/pmu.h    |  234 -----------
 4 files changed, 1058 deletions(-)
 delete mode 100644 arch/x86/platform/mrst/pmu.c
 delete mode 100644 arch/x86/platform/mrst/pmu.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 9c63a43..b741c2f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
 <at>  <at>  -3513,12 +3513,6  <at>  <at>  F:	Documentation/networking/ixgbe.txt
 F:	Documentation/networking/ixgbevf.txt
 F:	drivers/net/ethernet/intel/
 
-INTEL MRST PMU DRIVER
-M:	Len Brown <len.brown <at> intel.com>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane