On Fri, Jan 18, 2013 at 07:38:34PM +, Matthew Garrett wrote:
> On Fri, Jan 18, 2013 at 08:36:56PM +0100, Borislav Petkov wrote:
>
> > Ok, how much can we rely on ACPI to have this ACPI_ADR_SPACE_SYSTEM_IO
> > properly set on K8? Because the thing is, we want to use acpi-cpufreq on
> > F10h onw
On Fri, Jan 18, 2013 at 08:36:56PM +0100, Borislav Petkov wrote:
> Ok, how much can we rely on ACPI to have this ACPI_ADR_SPACE_SYSTEM_IO
> properly set on K8? Because the thing is, we want to use acpi-cpufreq on
> F10h onwards and leave powernow-k8 to K8s.
SYSTEM_IO only supports single processo
On Fri, Jan 18, 2013 at 07:06:59PM +, Matthew Garrett wrote:
> On Fri, Jan 18, 2013 at 08:00:21PM +0100, Borislav Petkov wrote:
>
> > ##
> > # x86 drivers.
> > # Link order matters. K8 is preferred to ACPI because
On Fri, Jan 18, 2013 at 08:00:21PM +0100, Borislav Petkov wrote:
> ##
> # x86 drivers.
> # Link order matters. K8 is preferred to ACPI because of firmware bugs in
> early
> # K8 systems.
> ...
>
> Great. :(
The only
On Fri, Jan 18, 2013 at 06:07:55PM +0100, Borislav Petkov wrote:
> > Just flip the link order? It's only the way it is because in the
> > past we wanted to try hardware-specific drivers before more generic
> > ones, and I don't think that's a concern in this case now.
>
> Yeah, I heard that the acp
On Fri, Jan 18, 2013 at 04:23:47PM +, Matthew Garrett wrote:
> On Thu, Jan 17, 2013 at 12:54:37PM +0100, Borislav Petkov wrote:
>
> > So, handoff to acpi-cpufreq still has some issues. When both are
> > built-in, the module_init functions turn into normal initcalls and
> > in that case, they'r
On Thu, Jan 17, 2013 at 12:54:37PM +0100, Borislav Petkov wrote:
> So, handoff to acpi-cpufreq still has some issues. When both are
> built-in, the module_init functions turn into normal initcalls and
> in that case, they're executed in link order and it can happen that
> powernowk8_init() runs be
On Fri, Jan 11, 2013 at 07:03:35PM +, Gopalakrishnan, Aravind wrote:
> So, I had tried out the case when acpi-cpufreq was compiled into the
> kernel and looked at the return values from request_module(); it
> returns a positive value (255) both when acpi-cpufreq was compiled-in
> and when not c
: Gopalakrishnan, Aravind; Andre Przywara; r...@sisk.pl;
cpuf...@vger.kernel.org; linux...@vger.kernel.org; linux-kernel@vger.kernel.org
Cc: Andreas
Subject: Re: [PATCH] drivers/cpufreq: Warn user when powernow-k8 tries to fall
back to acpi-cpufreq and it is unavailable.
Adding bugreporter from BZ to CC.
On
, Aravind; Andre Przywara; r...@sisk.pl;
cpuf...@vger.kernel.org; linux...@vger.kernel.org; linux-kernel@vger.kernel.org
Cc: Andreas
Subject: Re: [PATCH] drivers/cpufreq: Warn user when powernow-k8 tries to fall
back to acpi-cpufreq and it is unavailable.
Adding bugreporter from BZ to CC.
On Fri
Adding bugreporter from BZ to CC.
On Fri, Jan 11, 2013 at 03:49:40PM +0100, Borislav Petkov wrote:
> + Andre.
>
> On Wed, Jan 09, 2013 at 07:09:21PM -0600, Aravind Gopalakrishnan wrote:
> > This patch is in reference to bug#:51741.
> > (https://bugzilla.kernel.org/show_bug.cgi?id=51741)
> > powe
+ Andre.
On Wed, Jan 09, 2013 at 07:09:21PM -0600, Aravind Gopalakrishnan wrote:
> This patch is in reference to bug#:51741.
> (https://bugzilla.kernel.org/show_bug.cgi?id=51741)
> powernow-k8 falls back to acpi-cpufreq if CPU is not supported. However, it
> states that acpi-cpufreq
> has taken
This patch is in reference to bug#:51741.
(https://bugzilla.kernel.org/show_bug.cgi?id=51741)
powernow-k8 falls back to acpi-cpufreq if CPU is not supported. However, it
states that acpi-cpufreq
has taken over even if acpi-cpufreq is not compiled in. This patch rewords the
warning message to
cla
13 matches
Mail list logo
