Today cpus go to winkle when they are offlined. Since it is the deepest
idle state that we have, it is expected to save good amount of power as compared
to online state, where cores can enter nap/fastsleep only which are
shallower idle states.
However we observed no powersavings with winkle as
Commit 367dc4aa932bfb3 (cpufreq: Add stop CPU callback to
cpufreq_driver interface) introduced the stop CPU callback for
intel_pstate drivers. During the CPU_DOWN_PREPARE stage, this
callback is invoked so that drivers can take some action on the
pstate of the cpu before it is taken offline. This
Its possible today that the pstate of a core is held at a high even after the
entire core is hotplugged out if a load had just run on the hotplugged cpu.
This is
fair, since it is assumed that the pstate does not matter to a cpu in a deep
idle
state, which is the expected state of a hotplugged
On 5 September 2014 13:09, Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
Today cpus go to winkle when they are offlined. Since it is the deepest
idle state that we have, it is expected to save good amount of power as
compared
to online state, where cores can enter nap/fastsleep only which
On Fri, Sep 05, 2014 at 03:28:47PM +1000, Michael Neuling wrote:
The Debian powerpc little endian architecture is called ppc64le. This
Huh? ppc64le or ppc64el?
is the default architecture used by Ubuntu for powerpc.
The below checks the kernel config to see if we are compiling little
On Fri, 2014-09-05 at 09:13 +0200, Gabriel Paubert wrote:
On Fri, Sep 05, 2014 at 03:28:47PM +1000, Michael Neuling wrote:
The Debian powerpc little endian architecture is called ppc64le. This
Huh? ppc64le or ppc64el?
ppc64el. Commit message is wrong. Fixed below.
Mikey
From: Michael
From: Paul E. McKenney
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected
From: Bharata B Rao bhar...@linux.vnet.ibm.com
- ibm,rtas-configure-connector should treat the RTAS data as big endian.
- Treat ibm,ppc-interrupt-server#s as big-endian when setting
smp_processor_id during hotplug.
Signed-off-by: Bharata B Rao bhar...@linux.vnet.ibm.com
---
Introduce weak arch_find_msi_chip() to find the match msi_chip.
Currently, MSI chip associates pci bus to msi_chip. Because in
ARM platform, there may be more than one MSI controller in system.
Associate pci bus to msi_chip help pci device to find the match
msi_chip and setup MSI/MSI-X irq
Currently, pcie-designware, pcie-rcar, pci-tegra drivers
use irq chip_data to save the msi_chip pointer. They
already call irq_set_chip_data() in their own MSI irq map
functions. So irq_set_chip_data() in arch_setup_msi_irq()
is useless.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
Commit 0e4ccb150 added two __weak arch functions arch_msix_mask_irq()
and arch_msi_mask_irq() to fix a bug found when running xen in x86.
Introduced these two funcntions make MSI code complex. And mask/unmask
is the irq actions related to interrupt controller, should not use
weak arch functions to
This series is based Bjorn's pci-next branch + Alexander Gordeev's two patches
Remove arch_msi_check_device() link: https://lkml.org/lkml/2014/7/12/41
Currently, there are a lot of weak arch functions in MSI code.
Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
This
Now we can clean up MSI weak arch functions in x86.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/x86/include/asm/pci.h |3 ---
arch/x86/include/asm/x86_init.h |4
arch/x86/kernel/apic/io_apic.c |2 +-
arch/x86/kernel/x86_init.c | 24
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/mips/pci/msi-octeon.c | 35 ++-
1 files changed, 22 insertions(+),
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/iommu/irq_remapping.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/x86/include/asm/pci.h |1 +
arch/x86/kernel/apic/io_apic.c | 12
2 files
Now there are a lot of __weak arch functions in MSI code.
These functions make MSI driver complex. Thierry Reding Introduced
a new MSI chip framework to configure MSI/MSI-X irq in ARM. Use
the new MSI chip framework to refactor all other platform MSI
arch code to eliminate weak arch MSI functions.
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
arch/x86/pci/xen.c | 46
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/s390/pci/pci.c | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
diff
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/powerpc/kernel/msi.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff
Currently, PCI drivers will initialize bus-msi in
pcibios_add_bus(). pcibios_add_bus() will be called
in every pci bus initialization. So the bus-msi
assignment in pci_alloc_child_bus() is useless.
Signed-off-by: Yijing Wang wangyij...@huawei.com
CC: Thierry Reding
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/arm/mach-iop13xx/include/mach/pci.h |2 ++
arch/arm/mach-iop13xx/iq81340mc.c|1 +
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/sparc/kernel/pci.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/mips/pci/msi-xlp.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/ia64/kernel/msi_ia64.c | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
Commit 465665f78a7 (mips: Kill pointless destroy_irq()) removed
the destroy_irq(). So remove the leftover one in xlp_setup_msix()
to fix build error.
arch/mips/pci/msi-xlp.c: In function 'xlp_setup_msix':
arch/mips/pci/msi-xlp.c:447:3: error: implicit declaration of function
'destroy_irq'..
cc1:
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/mips/pci/pci-xlr.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff
Now we use struct msi_chip in all platforms to configure
MSI/MSI-X. We can clean up the unused arch functions.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/iommu/irq_remapping.c |2 +-
drivers/pci/msi.c | 99 -
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/tile/kernel/pci_gx.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff
Msi_chip functions setup_irq/teardown_irq rarely use msi_chip
argument. We can look up msi_chip pointer by the device pointer
or irq number, so clean up msi_chip argument.
Signed-off-by: Yijing Wang wangyij...@huawei.com
CC: Thierry Reding thierry.red...@gmail.com
CC: Thomas Petazzoni
Hello.
On 9/5/2014 2:09 PM, Yijing Wang wrote:
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/iommu/irq_remapping.c |8 +++-
1
Hello.
On 9/5/2014 2:10 PM, Yijing Wang wrote:
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/powerpc/kernel/msi.c | 14 --
1
T1040/T1042RDB is Freescale Reference Design Board.
The board can support both T1040/T1042 QorIQ Power Architecture™ processor.
T1040/T1042RDB board Overview
---
- SERDES Connections, 8 lanes supporting:
- PCI
- SGMII
- QSGMII
- SATA 2.0
- DDR
T1042RDB_PI is Freescale Reference Design Board supporting the T1042
QorIQ Power Architecture™ processor. T1042 is a reduced personality
of T1040 SoC without Integrated 8-port Gigabit. The board is designed
with low power features targeted for Printing Image Market.
T1042RDB_PI is similar to
On 9/5/2014 3:33 PM, wangyijing wrote:
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/powerpc/kernel/msi.c | 14 --
1 files
On Fri, Sep 05, 2014 at 05:55:18PM +1000, Michael Neuling wrote:
On Fri, 2014-09-05 at 09:13 +0200, Gabriel Paubert wrote:
On Fri, Sep 05, 2014 at 03:28:47PM +1000, Michael Neuling wrote:
The Debian powerpc little endian architecture is called ppc64le. This
Huh? ppc64le or ppc64el?
On Fri, Sep 5, 2014 at 3:55 AM, Michael Neuling mi...@neuling.org wrote:
On Fri, 2014-09-05 at 09:13 +0200, Gabriel Paubert wrote:
On Fri, Sep 05, 2014 at 03:28:47PM +1000, Michael Neuling wrote:
The Debian powerpc little endian architecture is called ppc64le. This
Huh? ppc64le or ppc64el?
[ +cc linux-arm ]
Hi David,
On 09/05/2014 04:30 AM, David Laight wrote:
I've seen gcc generate 32bit accesses for 16bit structure members on arm.
It does this because of the more limited range of the offsets for the 16bit
access.
OTOH I don't know if it ever did this for writes - so it may
From: Peter Hurley
[ +cc linux-arm ]
Hi David,
On 09/05/2014 04:30 AM, David Laight wrote:
I've seen gcc generate 32bit accesses for 16bit structure members on arm.
It does this because of the more limited range of the offsets for the 16bit
access.
OTOH I don't know if it ever did
On 09/05/2014 04:16 AM, bharata@gmail.com wrote:
From: Bharata B Rao bhar...@linux.vnet.ibm.com
- ibm,rtas-configure-connector should treat the RTAS data as big endian.
- Treat ibm,ppc-interrupt-server#s as big-endian when setting
smp_processor_id during hotplug.
Signed-off-by:
On 05/09/14 11:09, Yijing Wang wrote:
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
[...]
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
[...]
@@ -418,9 +430,9 @@ int __init pci_xen_init(void)
On 09/04/2014 10:08 PM, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the
On Fri, Sep 5, 2014 at 7:38 PM, Nathan Fontenot
nf...@linux.vnet.ibm.com wrote:
On 09/05/2014 04:16 AM, bharata@gmail.com wrote:
From: Bharata B Rao bhar...@linux.vnet.ibm.com
- ibm,rtas-configure-connector should treat the RTAS data as big endian.
- Treat ibm,ppc-interrupt-server#s as
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on Alpha/NT.
Right, because the x86 architecture was obsolete and would never scale...
-hpa
On 09/05/2014 08:37 AM, David Laight wrote:
From: Peter Hurley
On 09/05/2014 04:30 AM, David Laight wrote:
I've seen gcc generate 32bit accesses for 16bit structure members on arm.
It does this because of the more limited range of the offsets for the 16bit
access.
OTOH I don't know if it
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
On Fri, Sep 05, 2014 at 11:09:50AM -0700, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no
This patch attempts to ensure that all values are in the proper
endianness format when both hotadding and hotremoving cpus.
Signed-off-by: Thomas Falcon tlfal...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/dlpar.c | 56 ++--
On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
[cut]
documentation: Record limitations of bitfields and
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
CPUs without single-byte and double-byte loads and stores place some
interesting requirements on concurrent code. For example (adapted
from Peter
On 09/05/2014 03:52 PM, Peter Zijlstra wrote:
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
CPUs without single-byte and double-byte loads and stores place some
interesting requirements on concurrent
On Fri, Sep 05, 2014 at 03:24:35PM -0400, Peter Hurley wrote:
On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
[cut]
On 09/05/2014 03:38 PM, Marc Gauthier wrote:
Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
This commit documents the fact that it is not safe to use bitfields as
shared variables in synchronization
On 09/05/2014 01:12 PM, Peter Zijlstra wrote:
... and I'm wondering if I should _remove_ pre-EV56 configurations or
move the default choice and produce a warning about unsupported Alpha
CPUs instead?
depends BROKEN
or is that deprecated?
Just rip it out, like I did for the i386.
On Fri, Sep 05, 2014 at 04:01:35PM -0400, Peter Hurley wrote:
On 09/05/2014 03:52 PM, Peter Zijlstra wrote:
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
CPUs without single-byte and double-byte
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the Linux kernel]
_must provide_ atomic one-byte and two-byte naturally aligned loads and
stores.
Second, in the body of
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
Second, in the body of the document:
The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
older CPUs _do not provide_ atomic one-byte and two-byte loads and stores.
Let's be clear here, the pre-EV56 Alpha CPUs do
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
On 09/05/2014 03:38 PM, Marc Gauthier wrote:
Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
This commit documents the fact that it is not
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the Linux kernel]
_must provide_ atomic one-byte and
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the Linux kernel]
_must provide_ atomic one-byte and
On Fri, 5 Sep 2014, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the
On Fri, Sep 05, 2014 at 10:48:34PM +0200, Thomas Gleixner wrote:
On Fri, 5 Sep 2014, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit
On 09/05/2014 04:39 PM, Michael Cree wrote:
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
Second, in the body of the document:
The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
older CPUs _do not provide_ atomic one-byte and two-byte loads and stores.
On Sat, Jul 12, 2014 at 01:21:06PM +0200, Alexander Gordeev wrote:
Hello,
This is a cleanup effort to get rid of useless arch_msi_check_device().
I am not sure what were the reasons for its existence in the first place,
but at the moment it appears totally unnecessary.
Thanks!
Cc:
On Fri, Sep 5, 2014 at 3:25 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Sat, Jul 12, 2014 at 01:21:06PM +0200, Alexander Gordeev wrote:
Hello,
This is a cleanup effort to get rid of useless arch_msi_check_device().
I am not sure what were the reasons for its existence in the first place,
On Fri, Sep 05, 2014 at 05:12:28PM -0400, Peter Hurley wrote:
On 09/05/2014 04:39 PM, Michael Cree wrote:
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
Second, in the body of the document:
The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
older CPUs
On Thu, Aug 21, 2014 at 09:26:52AM +1000, Anton Blanchard wrote:
From: Douglas Lehr dll...@us.ibm.com
The Crocodile chip occasionally comes up with 4k and 8k BAR sizes.
Due to an errata, setting the SR-IOV page size causes the physical
function BARs to expand to the system page size. Since
70 matches
Mail list logo
