On Thursday, February 14, 2013 07:34:56 AM Dirk Brandewie wrote:
> On 02/14/2013 04:21 AM, Rafael J. Wysocki wrote:
> > On Thursday, February 14, 2013 09:38:21 AM Viresh Kumar wrote:
> >> On Wed, Feb 13, 2013 at 10:08 PM, Dirk Brandewie
> >> wrote:
> >>> For the case where both are built-in the lo
On 02/14/2013 04:21 AM, Rafael J. Wysocki wrote:
On Thursday, February 14, 2013 09:38:21 AM Viresh Kumar wrote:
On Wed, Feb 13, 2013 at 10:08 PM, Dirk Brandewie
wrote:
For the case where both are built-in the load order works my driver uses
device_initcall() and acpi_cpufreq uses late_initcall
On 02/14/2013 04:21 AM, Rafael J. Wysocki wrote:
On Thursday, February 14, 2013 09:38:21 AM Viresh Kumar wrote:
On Wed, Feb 13, 2013 at 10:08 PM, Dirk Brandewie
wrote:
For the case where both are built-in the load order works my driver uses
device_initcall() and acpi_cpufreq uses late_initcall
On Thursday, February 14, 2013 09:38:21 AM Viresh Kumar wrote:
> On Wed, Feb 13, 2013 at 10:08 PM, Dirk Brandewie
> wrote:
> > For the case where both are built-in the load order works my driver uses
> > device_initcall() and acpi_cpufreq uses late_initcall().
> >
> > For the case where both are a
On Wed, Feb 13, 2013 at 10:08 PM, Dirk Brandewie
wrote:
> For the case where both are built-in the load order works my driver uses
> device_initcall() and acpi_cpufreq uses late_initcall().
>
> For the case where both are a module (which I was sure I tested) you are
> right
> I will have to do som
On Wednesday, February 13, 2013 08:38:04 AM Dirk Brandewie wrote:
> Hi Dave,
>
> On 02/12/2013 01:49 PM, Dave Jones wrote:
> > On Wed, Feb 06, 2013 at 09:02:07AM -0800, dirk.brande...@gmail.com wrote:
> >
> > Won't you also need to patch drivers/cpufreq/acpi-cpufreq.c to not load
> > on the proces
Hi Dave,
On 02/12/2013 01:49 PM, Dave Jones wrote:
On Wed, Feb 06, 2013 at 09:02:07AM -0800, dirk.brande...@gmail.com wrote:
Won't you also need to patch drivers/cpufreq/acpi-cpufreq.c to not load
on the processors that you want this driver to run on ?
Dave
For the case where both a
On Wed, Feb 06, 2013 at 09:02:07AM -0800, dirk.brande...@gmail.com wrote:
> From: Dirk Brandewie
>
> This driver implements a scaling driver with an internal governor for
> Intel Core processors. The driver follows the same model as the
> Transmeta scaling driver (longrun.c) and implements
On Thursday, February 07, 2013 07:32:26 PM Viresh Kumar wrote:
> On Thu, Feb 7, 2013 at 4:12 PM, Viresh Kumar wrote:
> > @Rafael: I wasn't sure if these would apply over my patches without any
> > conflicts and so i applied them in my repo. Added my Acked-by's and fixed
> > a minor thing in one of
On Thu, Feb 7, 2013 at 4:12 PM, Viresh Kumar wrote:
> @Rafael: I wasn't sure if these would apply over my patches without any
> conflicts and so i applied them in my repo. Added my Acked-by's and fixed
> a minor thing in one of the patches (as mentioned in the other mail).
>
> You can pick these f
On Wed, Feb 6, 2013 at 10:32 PM, wrote:
> From: Dirk Brandewie
>
> This driver implements a scaling driver with an internal governor for
> Intel Core processors. The driver follows the same model as the
> Transmeta scaling driver (longrun.c) and implements the setpolicy()
> instead of target().
From: Dirk Brandewie
This driver implements a scaling driver with an internal governor for
Intel Core processors. The driver follows the same model as the
Transmeta scaling driver (longrun.c) and implements the setpolicy()
instead of target(). Scaling drivers that implement setpolicy() are
assm
12 matches
Mail list logo
