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
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
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
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
On Thursday, February 14, 2013 09:38:21 AM Viresh Kumar wrote:
On Wed, Feb 13, 2013 at 10:08 PM, Dirk Brandewie
dirk.brande...@gmail.com 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
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
dirk.brande...@gmail.com wrote:
For the case where both are built-in the load order works my driver uses
device_initcall() and
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
dirk.brande...@gmail.com wrote:
For the case where both are built-in the load order works my driver uses
device_initcall() and
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
dirk.brande...@gmail.com wrote:
For the case where both are
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
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
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
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
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 processors that
On Wed, Feb 13, 2013 at 10:08 PM, Dirk Brandewie
dirk.brande...@gmail.com 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
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 Wed, Feb 06, 2013 at 09:02:07AM -0800, dirk.brande...@gmail.com wrote:
From: Dirk Brandewie dirk.brande...@gmail.com
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
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
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
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
On Thursday, February 07, 2013 07:32:26 PM Viresh Kumar wrote:
On Thu, Feb 7, 2013 at 4:12 PM, Viresh Kumar viresh.ku...@linaro.org 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
On Wed, Feb 6, 2013 at 10:32 PM, dirk.brande...@gmail.com wrote:
From: Dirk Brandewie dirk.brande...@gmail.com
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
On Thu, Feb 7, 2013 at 4:12 PM, Viresh Kumar viresh.ku...@linaro.org 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).
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
From: Dirk Brandewie dirk.brande...@gmail.com
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
24 matches
Mail list logo
