Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 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 something. > >>> > >>> For now I propose to make my driver built-in only while I sort out the > >>> right > >>> solution for the module build. Does this seem reasonable to everyone? > >> > >> Of-course i am missing something here. Why would anybody want to insert > >> acpi-cpufreq module when the system supports the pstate driver. > >> > >> In case they are mutually exclusive, then we can have something like > >> depends on !ACPI-DRIVER in the kconfig option of pstate driver. > > > > Yes. Or the other way around (i.e. make acpi_cpufreq depend on > > !X86_INTEL_PSTATE). > > > > The issue is that acpi-cpufreq still needs to be available for Intel > processors > before SandyBridge and for other x86 compatible processors we can't make > intel_pstate and acpi-cpufreq mutually exclusive. Right, I forgot about that and recalled it just a minute after sending that message. > Having intel_pstate built-in solves the issue without the need to patch > acpi-cpufreq. I believe that most distros build the scaling drivers in > so the distro/user will make the explicit decision to use intel_pstate. But then we need to allow the user to choose acpi_cpufreq anyway if it's preferred whatever the reason. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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(). For the case where both are a module (which I was sure I tested) you are right I will have to do something. For now I propose to make my driver built-in only while I sort out the right solution for the module build. Does this seem reasonable to everyone? Of-course i am missing something here. Why would anybody want to insert acpi-cpufreq module when the system supports the pstate driver. In case they are mutually exclusive, then we can have something like depends on !ACPI-DRIVER in the kconfig option of pstate driver. Yes. Or the other way around (i.e. make acpi_cpufreq depend on !X86_INTEL_PSTATE). The issue is that acpi-cpufreq still needs to be available for Intel processors before SandyBridge and for other x86 compatible processors we can't make intel_pstate and acpi-cpufreq mutually exclusive. Having intel_pstate built-in solves the issue without the need to patch acpi-cpufreq. I believe that most distros build the scaling drivers in so the distro/user will make the explicit decision to use intel_pstate. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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(). For the case where both are a module (which I was sure I tested) you are right I will have to do something. For now I propose to make my driver built-in only while I sort out the right solution for the module build. Does this seem reasonable to everyone? Of-course i am missing something here. Why would anybody want to insert acpi-cpufreq module when the system supports the pstate driver. In case they are mutually exclusive, then we can have something like depends on !ACPI-DRIVER in the kconfig option of pstate driver. Yes. Or the other way around (i.e. make acpi_cpufreq depend on !X86_INTEL_PSTATE). The issue is that acpi-cpufreq still needs to be available for Intel processors before SandyBridge and for other x86 compatible processors we can't make intel_pstate and acpi-cpufreq mutually exclusive. Having intel_pstate built-in solves the issue without the need to patch acpi-cpufreq. I believe that most distros build the scaling drivers in so the distro/user will make the explicit decision to use intel_pstate. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 module (which I was sure I tested) you are > > right > > I will have to do something. > > > > For now I propose to make my driver built-in only while I sort out the right > > solution for the module build. Does this seem reasonable to everyone? > > Of-course i am missing something here. Why would anybody want to insert > acpi-cpufreq module when the system supports the pstate driver. > > In case they are mutually exclusive, then we can have something like > depends on !ACPI-DRIVER in the kconfig option of pstate driver. Yes. Or the other way around (i.e. make acpi_cpufreq depend on !X86_INTEL_PSTATE). Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 where both are a module (which I was sure I tested) you are right I will have to do something. For now I propose to make my driver built-in only while I sort out the right solution for the module build. Does this seem reasonable to everyone? Of-course i am missing something here. Why would anybody want to insert acpi-cpufreq module when the system supports the pstate driver. In case they are mutually exclusive, then we can have something like depends on !ACPI-DRIVER in the kconfig option of pstate driver. Yes. Or the other way around (i.e. make acpi_cpufreq depend on !X86_INTEL_PSTATE). Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 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 something. For now I propose to make my driver built-in only while I sort out the right solution for the module build. Does this seem reasonable to everyone? Of-course i am missing something here. Why would anybody want to insert acpi-cpufreq module when the system supports the pstate driver. In case they are mutually exclusive, then we can have something like depends on !ACPI-DRIVER in the kconfig option of pstate driver. Yes. Or the other way around (i.e. make acpi_cpufreq depend on !X86_INTEL_PSTATE). The issue is that acpi-cpufreq still needs to be available for Intel processors before SandyBridge and for other x86 compatible processors we can't make intel_pstate and acpi-cpufreq mutually exclusive. Having intel_pstate built-in solves the issue without the need to patch acpi-cpufreq. I believe that most distros build the scaling drivers in so the distro/user will make the explicit decision to use intel_pstate. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 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 something. For now I propose to make my driver built-in only while I sort out the right solution for the module build. Does this seem reasonable to everyone? Of-course i am missing something here. Why would anybody want to insert acpi-cpufreq module when the system supports the pstate driver. In case they are mutually exclusive, then we can have something like depends on !ACPI-DRIVER in the kconfig option of pstate driver. Yes. Or the other way around (i.e. make acpi_cpufreq depend on !X86_INTEL_PSTATE). The issue is that acpi-cpufreq still needs to be available for Intel processors before SandyBridge and for other x86 compatible processors we can't make intel_pstate and acpi-cpufreq mutually exclusive. Having intel_pstate built-in solves the issue without the need to patch acpi-cpufreq. I believe that most distros build the scaling drivers in so the distro/user will make the explicit decision to use intel_pstate. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 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 something. For now I propose to make my driver built-in only while I sort out the right solution for the module build. Does this seem reasonable to everyone? Of-course i am missing something here. Why would anybody want to insert acpi-cpufreq module when the system supports the pstate driver. In case they are mutually exclusive, then we can have something like depends on !ACPI-DRIVER in the kconfig option of pstate driver. Yes. Or the other way around (i.e. make acpi_cpufreq depend on !X86_INTEL_PSTATE). The issue is that acpi-cpufreq still needs to be available for Intel processors before SandyBridge and for other x86 compatible processors we can't make intel_pstate and acpi-cpufreq mutually exclusive. Right, I forgot about that and recalled it just a minute after sending that message. Having intel_pstate built-in solves the issue without the need to patch acpi-cpufreq. I believe that most distros build the scaling drivers in so the distro/user will make the explicit decision to use intel_pstate. But then we need to allow the user to choose acpi_cpufreq anyway if it's preferred whatever the reason. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 something. > > For now I propose to make my driver built-in only while I sort out the right > solution for the module build. Does this seem reasonable to everyone? Of-course i am missing something here. Why would anybody want to insert acpi-cpufreq module when the system supports the pstate driver. In case they are mutually exclusive, then we can have something like depends on !ACPI-DRIVER in the kconfig option of pstate driver. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 you want this driver to run on ? > > > > Dave > > > > 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 something. > > For now I propose to make my driver built-in only while I sort out the right > solution for the module build. Does this seem reasonable to everyone? Well, I've been saying I think your driver should be non-modular from the start. :-) May I ask for a kernel command line switch to prevent it from registering if the user doesn't actually want it, though, if it's going to be non-modular? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 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 something. For now I propose to make my driver built-in only while I sort out the right solution for the module build. Does this seem reasonable to everyone? --Dirk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 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 something. For now I propose to make my driver built-in only while I sort out the right solution for the module build. Does this seem reasonable to everyone? --Dirk -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 you want this driver to run on ? Dave 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 something. For now I propose to make my driver built-in only while I sort out the right solution for the module build. Does this seem reasonable to everyone? Well, I've been saying I think your driver should be non-modular from the start. :-) May I ask for a kernel command line switch to prevent it from registering if the user doesn't actually want it, though, if it's going to be non-modular? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 will have to do something. For now I propose to make my driver built-in only while I sort out the right solution for the module build. Does this seem reasonable to everyone? Of-course i am missing something here. Why would anybody want to insert acpi-cpufreq module when the system supports the pstate driver. In case they are mutually exclusive, then we can have something like depends on !ACPI-DRIVER in the kconfig option of pstate driver. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 the setpolicy() > instead of target(). Scaling drivers that implement setpolicy() are > assmuned to implement internal governors by the cpufreq core. All the > logic for selecting the current P state is contained within the driver > no external governor is used by the cpufreq core. > > At the moment only Intel SandyBridge processors are supported. As > testing on SandyBridge+ processors is completed support will be added > to the driver. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 (longrun.c) and implements the setpolicy() instead of target(). Scaling drivers that implement setpolicy() are assmuned to implement internal governors by the cpufreq core. All the logic for selecting the current P state is contained within the driver no external governor is used by the cpufreq core. At the moment only Intel SandyBridge processors are supported. As testing on SandyBridge+ processors is completed support will be added to the driver. 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 the patches (as mentioned in the other mail). > > > > You can pick these from: dirk-patches > > > > http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/dirk-patches > > Hi Rafael, > > I have got few sparse fixes for these patches. Updated the branch, > please pick it up again. I haven't picked it up yet, so thanks a lot for that work! Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 from: dirk-patches > > http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/dirk-patches Hi Rafael, I have got few sparse fixes for these patches. Updated the branch, please pick it up again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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(). Scaling drivers that implement setpolicy() are > assmuned to implement internal governors by the cpufreq core. All the > logic for selecting the current P state is contained within the driver > no external governor is used by the cpufreq core. Hi Dirk, All look good now :) Acked-by: Viresh Kumar @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 from: dirk-patches http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/dirk-patches -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 minor thing in one of the patches (as mentioned in the other mail). You can pick these from: dirk-patches http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/dirk-patches Hi Rafael, I have got few sparse fixes for these patches. Updated the branch, please pick it up again. I haven't picked it up yet, so thanks a lot for that work! Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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 implements the setpolicy() instead of target(). Scaling drivers that implement setpolicy() are assmuned to implement internal governors by the cpufreq core. All the logic for selecting the current P state is contained within the driver no external governor is used by the cpufreq core. Hi Dirk, All look good now :) Acked-by: Viresh Kumar viresh.ku...@linaro.org @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 from: dirk-patches http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/dirk-patches -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add P state driver for Intel Core Processors
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). You can pick these from: dirk-patches http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/dirk-patches Hi Rafael, I have got few sparse fixes for these patches. Updated the branch, please pick it up again. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] Add P state driver for Intel Core Processors
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 assmuned to implement internal governors by the cpufreq core. All the logic for selecting the current P state is contained within the driver no external governor is used by the cpufreq core. At the moment only Intel SandyBridge processors are supported. As testing on SandyBridge+ processors is completed support will be added to the driver. New sysfs files for controlling P state selection have been added to /sys/devices/system/cpu/intel_pstate/ max_perf_pct: limits the maximum P state that will be requested by the driver stated as a percentage of the avail performance. min_perf_pct: limits the minimum P state that will be requested by the driver stated as a percentage of the avail performance. no_turbo: limits the driver to selecting P states below the turbo frequency range. The units for these for these files are purposely abstract and stated in terms of available performance and not frequency. In idea that frequency can be set to a single frequency is a fiction for Intel Core processors. Even if the scaling driver selects a single P state the actual frequency the processor will run at is selected by the processor Changes since last version: Dropped unneeded patches. Rebased on bleeding edge 1071b3b Patch 1: updated per Viresh's comments, added his ack. Patch 2: updated description to be more informative and move the check as to whether the scaling driver implements target() to only effect whether cpufreq_out_of_sync() is called Patch 3: Added Viresh's Ack Patch 4: Upadted to not use unneeded local variable Dirk Brandewie (5): cpufreq: Retrieve current frequency from scaling drivers with internal governors cpufreq: Only call cpufreq_out_of_sync() with drivers that implement cpufreq_driver.target() cpufreq: Do not track governor name for scaling drivers with internal governors. cpufreq_stats: do not remove sysfs files if frequency table is not present cpufreq/x86: Add P-state driver for sandy bridge. drivers/cpufreq/Kconfig.x86 | 18 + drivers/cpufreq/Makefile|1 + drivers/cpufreq/cpufreq.c | 13 +- drivers/cpufreq/cpufreq_stats.c |4 + drivers/cpufreq/intel_pstate.c | 829 +++ 5 files changed, 862 insertions(+), 3 deletions(-) create mode 100644 drivers/cpufreq/intel_pstate.c -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] Add P state driver for Intel Core Processors
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 implement setpolicy() are assmuned to implement internal governors by the cpufreq core. All the logic for selecting the current P state is contained within the driver no external governor is used by the cpufreq core. At the moment only Intel SandyBridge processors are supported. As testing on SandyBridge+ processors is completed support will be added to the driver. New sysfs files for controlling P state selection have been added to /sys/devices/system/cpu/intel_pstate/ max_perf_pct: limits the maximum P state that will be requested by the driver stated as a percentage of the avail performance. min_perf_pct: limits the minimum P state that will be requested by the driver stated as a percentage of the avail performance. no_turbo: limits the driver to selecting P states below the turbo frequency range. The units for these for these files are purposely abstract and stated in terms of available performance and not frequency. In idea that frequency can be set to a single frequency is a fiction for Intel Core processors. Even if the scaling driver selects a single P state the actual frequency the processor will run at is selected by the processor Changes since last version: Dropped unneeded patches. Rebased on bleeding edge 1071b3b Patch 1: updated per Viresh's comments, added his ack. Patch 2: updated description to be more informative and move the check as to whether the scaling driver implements target() to only effect whether cpufreq_out_of_sync() is called Patch 3: Added Viresh's Ack Patch 4: Upadted to not use unneeded local variable Dirk Brandewie (5): cpufreq: Retrieve current frequency from scaling drivers with internal governors cpufreq: Only call cpufreq_out_of_sync() with drivers that implement cpufreq_driver.target() cpufreq: Do not track governor name for scaling drivers with internal governors. cpufreq_stats: do not remove sysfs files if frequency table is not present cpufreq/x86: Add P-state driver for sandy bridge. drivers/cpufreq/Kconfig.x86 | 18 + drivers/cpufreq/Makefile|1 + drivers/cpufreq/cpufreq.c | 13 +- drivers/cpufreq/cpufreq_stats.c |4 + drivers/cpufreq/intel_pstate.c | 829 +++ 5 files changed, 862 insertions(+), 3 deletions(-) create mode 100644 drivers/cpufreq/intel_pstate.c -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
