The Foundation model GIC mapping is wrong, as the GICC region should
be 8kB instead of 4kB (the model implements the GICv2 architecture).
This defect prevents the driver from switching to EOImode==1.
Signed-off-by: Andre Przywara
---
arch/arm64/boot/dts/arm/foundation-v8.dts | 2 +-
1 file
Hi Ming,
thanks for the answer!
On 15/12/15 11:54, Ming Lei wrote:
> On Tue, Dec 15, 2015 at 7:05 PM, Andre Przywara
> wrote:
>> Hi,
>>
>> I've been experiencing issues with at least 4.4-rc3 (including current
>
> I'd suggest you to test the latest
Hi,
I've been experiencing issues with at least 4.4-rc3 (including current
HEAD) on a Calxeda Midway (4*ARM Cortex-A15 (32-bit), 8GB RAM, SATA
spinning disk or SSD).
After some disk I/O load (kernel compile with -j6) I see the kernel
screaming:
[ 103.736982] ata1.00: exception Emask 0x0 SAct 0x3
On 23/10/15 02:41, Hanjun Guo wrote:
> Hi Brijesh,
>
> On 2015/10/22 22:46, Brijesh Singh wrote:
>> Hi Andre,
>>
>> On 10/21/2015 06:52 PM, Andre Przywara wrote:
>>> On 21/10/15 21:41, Brijesh Singh wrote:
>>>> Add support for Cortex A57 and A53 EDA
On 21/10/15 21:41, Brijesh Singh wrote:
> Add support for Cortex A57 and A53 EDAC driver.
Hi Brijesh,
thanks for the quick update! Some comments below.
>
> Signed-off-by: Brijesh Singh
> CC: robh...@kernel.org
> CC: pawel.m...@arm.com
> CC: mark.rutl...@arm.com
> CC: ijc+devicet...@hellion.org
Hi,
On 21/10/15 10:35, Borislav Petkov wrote:
> On Wed, Oct 21, 2015 at 09:55:43AM +0800, Hanjun Guo wrote:
>> So I think the meaning of those error register is the same, but the way
>> of handle it may different from SoCs, for single bit error:
>>
>> - SoC may trigger a interrupt;
>> - SoC may
Hi Marc,
On 13/10/15 11:44, Marc Zyngier wrote:
> On 13/10/15 10:37, Andre Przywara wrote:
>> The ARMv8 Foundation model sports a command line parameter to use
>> a GICv3 emulation instead of the default GICv2 interrupt controller.
>> Add a new .dts file which reuses most
To prepare the ARM foundation model to support GICv3, we adjust
the #address-cells property of the current GICv2 node to be
compatible with the two cells required for GICv3 later.
Signed-off-by: Andre Przywara
---
arch/arm64/boot/dts/arm/foundation-v8.dts | 88 +++
1
/foundation-model.php
Andre Przywara (4):
arm64: dts: prepare foundation-v8.dts to cope with GICv3
arm64: dts: Foundation model: increate GICC region to allow EOImode=1
arm64: dts: split Foundation model dts to put the GIC separately
arm64: dts: add .dts for GICv3 Foundation model
arch/arm64
Foundation model to run with a GICv3.
Signed-off-by: Andre Przywara
---
arch/arm64/boot/dts/arm/Makefile| 2 +-
arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts | 30 +
2 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot
Recent commits made the GIC driver use EOImode=1 for all GICs
that advertise the proper GICC region size.
To let the model benefit from the blessings of that mode, increase
the GICC region to its actual size of 8K.
Signed-off-by: Andre Przywara
---
arch/arm64/boot/dts/arm/foundation-v8.dts | 2
.dts.
Signed-off-by: Andre Przywara
---
arch/arm64/boot/dts/arm/foundation-v8.dts | 223 +
.../arm/{foundation-v8.dts => foundation-v8.dtsi} | 12 --
2 files changed, 2 insertions(+), 233 deletions(-)
copy arch/arm64/boot/dts/arm/{foundation-v8.dts => foundat
Hi,
On 08/10/15 11:38, Alexandre Belloni wrote:
> On 08/10/2015 at 10:37:49 +0100, Russell King - ARM Linux wrote :
>> On Thu, Oct 08, 2015 at 11:01:48AM +0200, Alexandre Belloni wrote:
>>> On 05/10/2015 at 18:00:52 +0100, Andre Przywara wrote :
>>>> Turning on KV
ize [-Wint-to-pointer-cast]
if ((void *)port->mapbase != ser->iomem_base)
^
Fix that by using the cast on the right hand side instead, as similar
code already does in other drivers.
Signed-off-by: Andre Przywara
---
drivers/tty/serial/atmel_serial.c | 2 +-
1 file changed, 1 insertio
Hi David,
On 21/09/15 18:17, Andre Przywara wrote:
> With DMA_ERROR_CODE now being dma_addr_t in most architectures, it
> turned out that iommu_tbl_range_alloc (defined in lib/iommu-common.c)
> is actually using a wrong return type.
> This was easily fixed in a previous patch, but n
Hi Michael,
On 23/09/15 10:55, Michael Ellerman wrote:
> On Tue, 2015-09-22 at 18:15 +0100, Andre Przywara wrote:
>> On 22/09/15 15:06, Andrea Arcangeli wrote:
>>> Andre, could you see if linux-next (which includes -mm) works for you
>>> by just running "cd too
Hi Shuah, Andrea,
On 22/09/15 15:06, Andrea Arcangeli wrote:
> On Tue, Sep 22, 2015 at 07:49:13AM -0600, Shuah Khan wrote:
>> On 09/22/2015 04:45 AM, Andre Przywara wrote:
>>> At the moment the userfaultfd test program only supports x86 and an
>>> architecture called
On 22/09/15 16:52, Will Deacon wrote:
> On Tue, Sep 22, 2015 at 11:52:19AM +0100, Andre Przywara wrote:
>> Enable the new userfaultfd syscall in the generic syscall table.
>> Briefly tested on arm64 with the selftest from the tools directory.
>
> Can you update the selftest t
Enable the new userfaultfd syscall in the generic syscall table.
Briefly tested on arm64 with the selftest from the tools directory.
Signed-off-by: Andre Przywara
---
include/uapi/asm-generic/unistd.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/uapi/asm
needed there, so we can
simply remove it to fix that issue.
Signed-off-by: Andre Przywara
---
include/uapi/linux/userfaultfd.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/uapi/linux/userfaultfd.h b/include/uapi/linux/userfaultfd.h
index df0e09b..9057d7a 100644
--- a/include/uapi
Hi Russell,
On 21/09/15 18:17, Russell King - ARM Linux wrote:
> On Mon, Sep 21, 2015 at 06:00:33PM +0100, Andre Przywara wrote:
>> Add the syscall numbers to the ARM syscall table. Both have
>> been briefly tested using the provided selftests from the tools
>> directory
guard the explicit
syscall number section below to avoid redefinitions.
Signed-off-by: Andre Przywara
---
tools/testing/selftests/vm/userfaultfd.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/vm/userfaultfd.c
b/tools/testing/se
-proof.
Tested on x86, arm and arm64.
Andre Przywara (2):
userfaultfd: remove kernel header include from uapi header
selftests/userfaultfd: improve syscall number definition
include/uapi/linux/userfaultfd.h | 2 --
tools/testing/selftests/vm/userfaultfd.c | 13 -
2 files
obvious mismatches to allow sane comparisons with
the error return value.
Compile-tested on sparc, sparc64, x86, ARM, arm64.
Signed-off-by: Andre Przywara
---
Hi David,
as promised my first naive try on fixing the callers of
iommu_tbl_range_alloc() as well. This goes on top of the return type
fix I
Add the syscall numbers to the ARM syscall table. Both have
been briefly tested using the provided selftests from the tools
directory.
Signed-off-by: Andre Przywara
---
Hi Russell,
I saw that Thierry sent something similar beginning of August already
(which is now outdated), is there any issue
Hi David,
On 18/09/15 18:09, David Miller wrote:
> From: Andre Przywara
> Date: Fri, 18 Sep 2015 10:03:40 +0100
>
>> Or do you know of a simpler way to fixing it properly which could make
>> it still into 4.3?
>
> All I worry about is that if you take it out of th
or the 4.3 release. I couldn't spot any warnings on
the architectures I managed to compile.
Compile tested on Sparc, Sparc64, PowerPC64, ARM, ARM64, x86.
Signed-off-by: Andre Przywara
---
include/linux/iommu-common.h | 12 ++--
lib/iommu-common.c | 15 ---
2 files
Hi David,
On 17/09/15 19:38, David Miller wrote:
> From: Andre Przywara
> Date: Thu, 17 Sep 2015 09:40:27 +0100
>
>> It seems the types used in this file are not really correct, but a
>> fix isn't trivial. So for the time being restrict this code to be
>> compil
y correct, but a
fix isn't trivial.
So for the time being restrict this code to be compiled only when we
actually need it.
Compile tested on Sparc, Sparc64, PPC64, ARM, ARM64, x86.
Signed-off-by: Andre Przywara
---
arch/sparc/Kconfig | 3 +++
lib/Makefile | 3 ++-
2 files changed, 5
of "ret" in
__iommu_create_mapping() and move the variable declaration inside the
for-loop to make the scope of this variable more clear.
Signed-off-by: Andre Przywara
---
arch/arm/mm/dma-mapping.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Hi Russell,
I hope that hasn&
Good morning Pavel,
On 07/07/15 08:16, Pavel Fedin wrote:
> Hello!
>
>> Wouldn't:
>> if (kvm_vm_check_extension(s, KVM_CAP_MSI_DEVID)) {
>> kroute.flags = KVM_MSI_VALID_DEVID;
>> kroute.u.msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn;
>> }
>>
>> be saner (without
On 06/07/15 16:54, Paolo Bonzini wrote:
>
>
> On 06/07/2015 17:37, Andre Przywara wrote:
>> Wouldn't:
>> if (kvm_vm_check_extension(s, KVM_CAP_MSI_DEVID)) {
>> kroute.flags = KVM_MSI_VALID_DEVID;
>> kroute.u.msi.devid = (pc
Salut Eric,
>> ITS code in qemu just does:
>>
>> ---cut ---
>> msi_supported = true;
>> kvm_msi_flags = KVM_MSI_VALID_DEVID;
>> kvm_msi_via_irqfd_allowed = kvm_has_gsi_routing();
>> kvm_gsi_routing_allowed = kvm_msi_via_irqfd_allowed;
>> --- cut ---
>>
>> I set KVM_MSI_VALI
Hi Pavel,
On 06/07/15 14:32, Pavel Fedin wrote:
> Hi!
>
>>> Well, as we are about to implement this: yes. But the issue is that MSI
>>> injection and GSI routing code is generic PCI code in userland (at least
>>> in kvmtool, guess in QEMU, too), so I don't want to pull in any kind of
>>> ARM spe
On 06/07/15 13:08, Christoffer Dall wrote:
> On Mon, Jul 06, 2015 at 12:23:19PM +0100, Andre Przywara wrote:
>> Hi Paolo,
>>
>> thanks for looking at this!
>>
>> On 06/07/15 12:07, Paolo Bonzini wrote:
>>>
>>>
>>> On 06/07/2015 12:37,
Hi Paolo,
thanks for looking at this!
On 06/07/15 12:07, Paolo Bonzini wrote:
>
>
> On 06/07/2015 12:37, Christoffer Dall wrote:
>> I don't view it as 'the kernel requires this' but as 'the kernel will
>> not complain with arbitrary error code if you set the devid flag'
>> capability, and it's
Hi Christoffer,
On 06/07/15 10:30, Christoffer Dall wrote:
> On Mon, Jul 06, 2015 at 09:30:20AM +0100, Andre Przywara wrote:
>> Hi Pavel,
>>
>> On 06/07/15 07:42, Pavel Fedin wrote:
>>> Hello!
>>>
>>>> I like this approach, but it run
Hi Pavel,
On 06/07/15 07:42, Pavel Fedin wrote:
> Hello!
>
>> I like this approach, but it runs into problems:
>> As you read above the current documentation says that the flags field
>> must be zero and the current KVM_SET_GSI_ROUTING handler bails out if it
>> isn't. So userland would need to
Hi,
On 03/07/15 10:05, Andre Przywara wrote:
> Hi Pavel,
>
> On 02/07/15 08:26, Pavel Fedin wrote:
>> Hello!
>>
>>> -Original Message-
>>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
>>> Behalf Of Eric Auge
Hi Pavel,
On 02/07/15 08:26, Pavel Fedin wrote:
> Hello!
>
>> -Original Message-
>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
>> Of Eric Auger
>> Sent: Monday, June 29, 2015 6:37 PM
>> To: eric.au...@st.com; eric.au...@linaro.org;
>> linux-arm-ker...@
Hi Eric,
On 29/06/15 16:37, Eric Auger wrote:
> If the ITS modality is not available, let's simply support MSI
> injection by transforming the MSI.data into an SPI ID.
>
> This becomes possible to use KVM_SIGNAL_MSI ioctl for arm too.
>
> Signed-off-by: Eric Auger
> ---
> arch/arm/kvm/Kconfig
Hi Eric,
just played a bit with the code and I could make things easier by the
following change:
On 29/06/15 16:37, Eric Auger wrote:
> Add a new kvm_extended_msi struct to store the additional device ID
> specific to ARM. kvm_kernel_irq_routing_entry union now encompasses
> this new struct.
>
>
Hi Eric,
On 02/07/15 15:49, Eric Auger wrote:
> Hi Pavel,
> On 07/02/2015 09:26 AM, Pavel Fedin wrote:
>> Hello!
>>
>>> -Original Message-
>>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
>>> Behalf Of Eric Auger
>>> Sent: Monday, June 29, 2015 6:37 PM
>>> To: er
Hi Eric,
On 29/06/15 16:37, Eric Auger wrote:
> This patch adds compilation and link against irqchip.
>
> On ARM, irqchip routing is not really useful since there is
> a single irqchip. However main motivation behind using irqchip
> code is to enable MSI routing code. With the support of in-kerne
_typeof__(*(ptr)))__cmpxchg_mb((ptr), \
^
kernel/acct.c:174:2: note: in expansion of macro 'cmpxchg'
cmpxchg(&acct->ns->bacct, pin, NULL);
^
Rearrange the macro along the lines of a similar patch for arm64
60010e508111 ("arm64: cmpxchg: update macros to prevent warnings&quo
auth_probe) {
^
This code was obviously using switch to make use of the fall-through
semantics (without the usual comment, though).
Rewrite that code using if statements to avoid the warning and make
the code a bit more readable on the way.
Signed-off-by: Andre Przywara
---
fs/nfs/nfs4pro
On Tue, 24 Feb 2015 18:57:49 +0100, Borislav Petkov wrote:
> On Mon, Feb 23, 2015 at 06:14:25PM +, Sudeep Holla wrote:
>> - Rebased on v4.0-rc1
>> - Fixed lockdep warning reported by Borislav
> You probably have fixed the lockdep splat but not the NULL pointer
> dereference which was there in
Hi Sasha,
thanks for taking a look!
On 19/02/15 10:56, Sasha Levin wrote:
> On 02/13/2015 05:39 AM, Andre Przywara wrote:
>> Hi,
>>
>> as I found it increasingly inconvenient to use kvmtool[1] as part of a
>> Linux repository, I decided to give it a go and make it a s
Hi Will,
On 18/02/15 15:50, Will Deacon wrote:
> Hi Andre,
>
> Thanks for doing this. Since it looks unlikely that kvmtool will ever be
> merged back into the kernel tree, it makes sense to cut the dependency
> in my opinion.
>
> On Fri, Feb 13, 2015 at 10:39:33AM +,
Ciao Claudio,
On 13/02/15 14:30, Claudio Fontana wrote:
> Hello Andre,
>
> On 13.02.2015 11:39, Andre Przywara wrote:
>> Hi,
>>
>> as I found it increasingly inconvenient to use kvmtool[1] as part of a
>> Linux repository, I decided to give it a go and make
Hi,
as I found it increasingly inconvenient to use kvmtool[1] as part of a
Linux repository, I decided to give it a go and make it a stand-alone
project. So I filtered all the respective commits, adjusted the paths in
there (while keeping authorship and commit date, of course) and then
added the m
mentation with a static inline function to
get rid of this warning.
Signed-off-by: Andre Przywara
---
Hi Andrew,
Mel mentioned that I should send that simple fix below to you to
merge it with his original mmotm patch:
mm-convert-p_mknonnuma-and-remaining-page-table-manipulations.patch
The commit me
mentation with a static inline function to
get rid of this warning.
Signed-off-by: Andre Przywara
---
arch/arm/include/asm/pgtable-3level.h |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/pgtable-3level.h
b/arch/arm/include/asm/pgtable-3level.h
index
g the patching in the module's code.
Signed-off-by: Andre Przywara
---
Hi Will,
so this patch make alternatives patching now work with modules. This
required some changes in the core alternatives code, so it would have
looked better when folded in (but it's already too late for this, I
Hi,
On 24/11/14 10:10, Eric Auger wrote:
> On 11/24/2014 10:47 AM, Christoffer Dall wrote:
>> On Sun, Nov 23, 2014 at 06:56:57PM +0100, Eric Auger wrote:
>>> This patch series enables irqfd on arm and arm64.
>>>
>>> Irqfd framework enables to inject a virtual IRQ into a guest upon an
>>> eventfd t
d CPU is detected at runtime.
Signed-off-by: Andre Przywara
---
arch/arm64/include/asm/alternative-asm.h | 13
arch/arm64/include/asm/cpufeature.h |8 +++-
arch/arm64/include/asm/cputype.h |5 +
arch/arm64/kernel/cpu_errat
accessors).
Signed-off-by: Andre Przywara
---
arch/arm64/include/asm/cpufeature.h | 20
arch/arm64/kernel/setup.c |3 +++
2 files changed, 23 insertions(+)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index cd4ac05
fected. By default
all of them are enabled.
Normal users or distribution kernels shouldn't bother to deselect any
bugs here, since the alternatives framework will take care of
patching them in only if needed.
Signed-off-by: Andre Przywara
---
arch/arm64/Kconfig
icial
means rather than provoking random hacks.
The code can be found also in the alternatives/v1 branch of:
http://www.linux-arm.org/git?p=linux-ap.git
git://linux-arm.org/linux-ap.git
Please review and comment!
Cheers,
Andre.
Andre Przywara (6):
arm64: add cpu_capabilities bitmap
arm64
: Andre Przywara
---
arch/arm64/include/asm/cpufeature.h |2 ++
arch/arm64/kernel/Makefile |2 +-
arch/arm64/kernel/cpu_errata.c | 59 +++
arch/arm64/kernel/cpuinfo.c |3 ++
4 files changed, 65 insertions(+), 1 deletion(-)
create
With a blatant copy of some x86 bits we introduce the alternative
runtime patching "framework" to arm64.
This is quite basic for now and we only provide the functions we need
at this time.
This is connected to the newly introduced feature bits.
Signed-off-by: Andre Przywara
---
The ARM erratum 832075 applies to certain revisions of Cortex-A57,
one of the workarounds is to change device loads into using
load-aquire semantics.
This is achieved using the alternatives framework.
Signed-off-by: Andre Przywara
---
arch/arm64/include/asm/cpufeature.h |5 +++--
arch/arm64
On 13/11/14 15:02, Nikolay Nikolaev wrote:
> On Thu, Nov 13, 2014 at 4:23 PM, Eric Auger wrote:
>> On 11/13/2014 03:16 PM, Eric Auger wrote:
>>> On 11/13/2014 11:45 AM, Nikolay Nikolaev wrote:
On Mon, Nov 10, 2014 at 6:27 PM, Christoffer Dall
wrote:
> On Mon, Nov 10, 2014 at 05:09
Hi Nikolay,
On 13/11/14 12:29, Nikolay Nikolaev wrote:
> On Thu, Nov 13, 2014 at 1:52 PM, Andre Przywara
> wrote:
>> Hi Nikolay,
>>
>> On 13/11/14 11:37, Marc Zyngier wrote:
>>> [fixing Andre's email address]
>>>
>>> On 13/11/14 11:20, Ch
Hi Nikolay,
On 13/11/14 11:37, Marc Zyngier wrote:
> [fixing Andre's email address]
>
> On 13/11/14 11:20, Christoffer Dall wrote:
>> On Thu, Nov 13, 2014 at 12:45:42PM +0200, Nikolay Nikolaev wrote:
>>
>> [...]
>>
>
> Going through the vgic_handle_mmio we see that it will require large
>
Hi,
On 24/10/14 11:31, Catalin Marinas wrote:
> On Thu, Oct 23, 2014 at 06:23:49PM +0100, Z Lim wrote:
>> On Thu, Oct 23, 2014 at 10:00 AM, Andre Przywara
>> wrote:
>>> I see a crash with 3.18-rc1 on a Juno board related to bpf_jit (see dump
>>> below). User
Hi,
I see a crash with 3.18-rc1 on a Juno board related to bpf_jit (see dump
below). Userland tries to carry on afterwards, but eventually hangs in
RCU stalls.
The kernel has just CONFIG_BPF_JIT enabled, I guess Ubuntu enables this
automatically if detected.
The backtrace doesn't make too much se
Hi Rob,
On 02/09/14 18:38, Rob Herring wrote:
> On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann wrote:
>> On Tuesday 02 September 2014 08:20:53 Rob Herring wrote:
>
> This alone is not okay. There is no such implementation of hardware.
But the SBSA explicitly allows this. I don't
On 02/09/14 20:34, Arnd Bergmann wrote:
> On Tuesday 02 September 2014 12:38:23 Rob Herring wrote:
>> On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann wrote:
>>> On Tuesday 02 September 2014 08:20:53 Rob Herring wrote:
>>
>> This alone is not okay. There is no such implementation of hardwar
Hi Arnd,
On 02/09/14 20:51, Arnd Bergmann wrote:
> On Saturday 30 August 2014 00:10:39 Andre Przywara wrote:
>> On 08/29/2014 07:59 PM, Arnd Bergmann wrote:
>>> On Friday 29 August 2014 17:13:23 Andre Przywara wrote:
>>>> The ARM Server Base System Architect
Hi Rob,
thanks for looking at this.
On 02/09/14 04:06, Rob Herring wrote:
> On Fri, Aug 29, 2014 at 11:13 AM, Andre Przywara
> wrote:
>> The ARM Server Base System Architecture (SBSA) describes a generic
>> UART which all compliant level 1 systems should implement. This is
&
On 28/07/14 11:46, Arnd Bergmann wrote:
> On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
>> The PL011 UART is the use-case I keep hitting, that IP block has a
>> variable input clock on pretty much everything I have seen in the wild.
>
> Ok, I see. What does ACPI-5.1 say about pl011?
>
>
Commit-ID: 2bbf0a1427c377350f001fbc6260995334739ad7
Gitweb: http://git.kernel.org/tip/2bbf0a1427c377350f001fbc6260995334739ad7
Author: Andre Przywara
AuthorDate: Wed, 31 Oct 2012 17:20:50 +0100
Committer: H. Peter Anvin
CommitDate: Wed, 31 Oct 2012 13:06:55 -0700
x86, amd: Disable way
From: Andre Przywara
The Way Access Filter in recent AMD CPUs may hurt the performance of
some workloads, caused by aliasing issues in the L1 cache.
This patch disables it on the affected CPUs.
The issue is similar to that one of last year:
http://lkml.indiana.edu/hypermail/linux/kernel/1107.3
Hi guys,
in case there are any inquiries regarding code of mine (e.g. triggered
by git annotate or commit messages), feel free to contact me via my
private address:
o...@andrep.de
My AMD email address is no longer valid.
Regards,
André Przywara
--
To unsubscribe from this list: send the line "u
On 10/24/2012 12:46 PM, Ingo Molnar wrote:
* Andre Przywara wrote:
The WAF may hurt the performance of some workloads, caused by
aliasing issues in the L1 cache.
Disable it on the affected CPUs.
Signed-off-by: Andre Przywara
---
arch/x86/kernel/cpu/amd.c | 14 ++
1 file
Commit-ID: bffd5fc26043cce33158d4e027576e79fab2f7bb
Gitweb: http://git.kernel.org/tip/bffd5fc26043cce33158d4e027576e79fab2f7bb
Author: Andre Przywara
AuthorDate: Tue, 9 Oct 2012 17:38:35 +0200
Committer: Ingo Molnar
CommitDate: Wed, 24 Oct 2012 08:53:13 +0200
x86/perf: Fix
The WAF may hurt the performance of some workloads, caused by
aliasing issues in the L1 cache.
Disable it on the affected CPUs.
Signed-off-by: Andre Przywara
---
arch/x86/kernel/cpu/amd.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86
On 10/09/2012 05:51 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Oct 09, 2012 at 05:38:34PM +0200, Andre Przywara wrote:
In check_hw_exists() we try to detect non-emulated MSR accesses
by writing an arbitrary value into one of the PMU registers
and check if it's value after a readout is stil
] ---[ end trace a7919e7f17c0a725 ]---
The new code will change every of the 16 low bits read from the
register and tries to write and read-back that modified number
from the MSR.
Signed-off-by: Andre Przywara
---
arch/x86/kernel/cpu/perf_event.c | 10 ++
1 file changed, 6 insertions(+), 4
] ---[ end trace a7919e7f17c0a725 ]---
The new code will change every of the 16 low bits read from the
register and tries to write and read-back that modified number
from the MSR.
Signed-off-by: Andre Przywara
---
arch/x86/kernel/cpu/perf_event.c | 10 ++
1 file changed, 6 insertions(+), 4
On 09/15/2012 01:20 PM, Konrad Rzeszutek Wilk wrote:
On Sep 4, 2012 4:26 AM, "Andre Przywara" mailto:andre.przyw...@amd.com>> wrote:
>
> To workaround some Windows specific behavior, the ACPI _PSD table
> on AMD desktop boards advertises all cores as dependent, mea
ufreq. So a dependency on the old driver does not help.
Are there still any problems with this patchset? Or are you only
wondering about the new config switch?
Thanks for testing!
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
--
To unsubscribe
On 09/05/2012 04:25 PM, Thomas Renninger wrote:
On Wednesday, September 05, 2012 03:46:22 PM Rafael J. Wysocki wrote:
On Tuesday, September 04, 2012, Andre Przywara wrote:
Hi,
I have applied the whole series to the linux-next branch of the linux-pm.git
Thanks!
tree, but I'm quite u
not succeed.
Signed-off-by: Andre Przywara
---
drivers/cpufreq/powernow-k8.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index 16c7fb6..8ff0621 100644
--- a/drivers/cpufreq/powernow-k8
control to acpi-cpufreq.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
---
arch/x86/include/asm/msr-index.h | 2 ++
drivers/cpufreq/Kconfig.x86 | 3 ++-
drivers/cpufreq/acpi-cpufreq.c | 43 ++--
3 files changed, 41 insertions(+), 7 deletions
tionale and the usage.
A following patch will re-introduce the cpb knob for compatibility
reasons on AMD CPUs.
Per-CPU boost switching is possible, but not trivial and is thus
postponed to a later patch series.
Signed-off-by: Andre Przywara
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 11 +
fig switch
I'd like to consider this feature obsolete. Lets keep it around for
some kernel versions and then phase it out.
Signed-off-by: Andre Przywara
---
drivers/cpufreq/Kconfig.x86| 12 +++
drivers/cpufreq/acpi-cpufreq.c | 46 --
2 fi
cpufreq support
after the transition.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
---
drivers/cpufreq/Makefile | 2 +-
drivers/cpufreq/powernow-k8.c | 392 +++---
drivers/cpufreq/powernow-k8.h | 32
3 files changed, 29 insertions
.
Signed-off-by: Andre Przywara
---
drivers/cpufreq/acpi-cpufreq.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 067a61f..70e7173 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
cpufreq modules are often loaded from init scripts that assume that
all recent AMD systems will use powernow-k8.
To inform the user of the change of support and ease the transition
to acpi-cpufreq, emit a warning message.
Signed-off-by: Andre Przywara
---
drivers/cpufreq/Kconfig.x86 | 3
From: Matthew Garrett
Some AMD systems may round the frequencies in ACPI tables to 100MHz
boundaries. We can obtain the real frequencies from MSRs, so add a quirk
to fix these frequencies up on AMD systems.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
---
arch/x86/include/asm
Hi,
now the second, revised version of the patch set. I now tested loading
both drivers after each other in several combinations, after two bug
fixes this now works as expected.
I added a patch to move messages from powernow-k8 after the initialization
phase, so it remains silent if driver loading
On 08/22/2012 03:00 AM, Thomas Renninger wrote:
On Monday 20 August 2012 22:49:16 Rafael J. Wysocki wrote:
On Monday, August 20, 2012, Andre Przywara wrote:
On 08/05/2012 11:33 PM, Rafael J. Wysocki wrote:
On Thursday, July 26, 2012, Andre Przywara wrote:
...
If you insist, I can keep the
On 08/05/2012 11:33 PM, Rafael J. Wysocki wrote:
On Thursday, July 26, 2012, Andre Przywara wrote:
From: Matthew Garrett
These chips are now supported by acpi-cpufreq, so we can delete all the
code handling them.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
Would it be
fig switch
I'd like to consider this feature obsolete. Lets keep it around for
some kernel versions and then phase it out.
Signed-off-by: Andre Przywara
---
drivers/cpufreq/Kconfig.x86| 12 ++
drivers/cpufreq/acpi-cpufreq.c | 46 ++-
2 fi
The new acpi-cpufreq driver supports a system global control switch
to disable the frequency boosting feature of some (x86) CPUs.
Provide documentation about the rationale and the usage.
Signed-off-by: Andre Przywara
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 12
From: Matthew Garrett
These chips are now supported by acpi-cpufreq, so we can delete all the
code handling them.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
---
drivers/cpufreq/Makefile |2 +-
drivers/cpufreq/powernow-k8.c | 385
control to acpi-cpufreq.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
---
arch/x86/include/asm/msr-index.h |2 +
drivers/cpufreq/acpi-cpufreq.c | 43 -
2 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/msr
will re-introduce the cpb knob for compatibility
reasons on AMD CPUs.
Per-CPU boost switching is possible, but not trivial and is thus
postponed to a later patch series.
Signed-off-by: Andre Przywara
---
drivers/cpufreq/acpi-cpufreq.c | 177
1 files chan
501 - 600 of 608 matches
Mail list logo
