Since we can now use hypervisor doorbells for host IPIs, this makes
sure we clear the host IPI flag when taking a doorbell interrupt, and
clears any pending doorbell IPI in pnv_smp_cpu_kill_self() (as we
already do for IPIs sent via the XICS interrupt controller). Otherwise
if there did happen to
On 19/03/15 08:45, Michael Ellerman wrote:
On Fri, 2015-13-03 at 18:14:46 UTC, Alex Dowad wrote:
The 'arg' argument to copy_thread() is only ever used when forking a new
kernel thread. Hence, rename it to 'kthread_arg' for clarity (and consistency
with do_fork() and other arch-specific
On Fri, 2015-13-03 at 18:14:46 UTC, Alex Dowad wrote:
The 'arg' argument to copy_thread() is only ever used when forking a new
kernel thread. Hence, rename it to 'kthread_arg' for clarity (and consistency
with do_fork() and other arch-specific implementations of copy_thread()).
I don't
The power7_nap(), power7_sleep() and power7_winkle() functions are
called from pnv_smp_cpu_kill_self(), which expects them to return the
SRR1 value set by the hardware on wakeup, or 0 if no nap/sleep/winkle
occurred. However, in the case where an interrupt needs to be
replayed, the logic in
2015-03-20 1:54 GMT+08:00 Bjorn Helgaas bhelg...@google.com:
On Thu, Mar 19, 2015 at 11:18 AM, Wei Yang weiyang.ker...@gmail.com wrote:
Oh, I thought you are not comfortable with the Patch v12 10/21 PCI:
Consider additional PF's IOV BAR alignment ...
V14 is ready to send which is based on
On Thu, Mar 19, 2015 at 02:41:48PM -0700, Linus Torvalds wrote:
On Wed, Mar 18, 2015 at 10:31 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
So I think there's something I'm missing. For non-shared mappings, I
still have the idea that pte_dirty should be the same as pte_write.
On Thu, Mar 19, 2015 at 04:05:46PM -0700, Linus Torvalds wrote:
On Thu, Mar 19, 2015 at 3:41 PM, Dave Chinner da...@fromorbit.com wrote:
My recollection wasn't faulty - I pulled it from an earlier email.
That said, the original measurement might have been faulty. I ran
the numbers again
On Thu, Mar 19, 2015 at 04:05:46PM -0700, Linus Torvalds wrote:
Can you try Mel's change to make it use
if (!(vma-vm_flags VM_WRITE))
instead of the pte details? Again, on otherwise plain 3.19, just so
that we have a baseline. I'd be *so* much happer with checking the vma
details
On Wed, Feb 25, 2015 at 05:23:53PM -0600, Suresh E. Warrier wrote:
Export __spin_yield so that the arch_spin_unlock() function can
be invoked from a module. This will be required for modules where
we want to take a lock that is also is acquired in hypervisor
real mode. Because we want to avoid
Since we can now use hypervisor doorbells for host IPIs, this makes
sure we clear the host IPI flag when taking a doorbell interrupt, and
clears any pending doorbell IPI in pnv_smp_cpu_kill_self() (as we
already do for IPIs sent via the XICS interrupt controller). Otherwise
if there did happen to
At Wed, 18 Mar 2015 17:48:56 +0100,
Fabian Frederick wrote:
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick f...@skynet.be
Thanks, applied this one.
The rest ASoC patches are left to Mark.
Takashi
---
Vasant Hegde hegdevas...@linux.vnet.ibm.com writes:
From: Anshuman Khandual khand...@linux.vnet.ibm.com
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework. It registers classdev structures for all
individual LEDs detected on the system
Previously the iommu_table had the same lifetime as a struct pnv_ioda_pe
and was embedded in it. The pnv_ioda_pe was assigned to a PE on the bootup
stage. Since PEs are based on the hardware layout which is static in the
system, they will never get released. This means the iommu_table in the
Flag PCI_REASSIGN_ALL_RSRC is used to ignore resources information setup by
firmware, so that kernel would re-assign all resources of pci devices.
On powerpc arch, this happens in a header fixup function
pcibios_fixup_resources(), which will clean up the resources if this flag
is set. This works
On Fri, 2015-03-20 at 11:55 +0700, Arseny Solokha wrote:
And by the way, while revisiting the series I've noticed that though the patch
4/4 basically reverts [1], it leaves
#define MPIC_GREG_GLOBAL_CONF_1 0x00030
in arch/powerpc/include/asm/mpic.h untouched. That define
On Fri, Mar 20, 2015 at 11:06:16AM +0800, Wei Yang wrote:
[snip]
---
v14:
* call ppc_md.pcibios_fixup_sriov() in pcibios_add_device
* add more explanation in change log
* Following patches have been reordered to the beginning.
EEH refactor to use pci_dn:
8ec20d6
On Fri, Mar 20, 2015 at 11:06:26AM +0800, Wei Yang wrote:
VFs are dynamically created when a driver enables them. On some platforms,
like PowerNV, special resources are necessary to enable VFs.
Add platform hooks for enabling and disabling VFs.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
On PowerNV, some resource reservation is needed for SR-IOV VFs that don't
exist at the bootup stage. To do the match between resources and VFs, the
code need to get the VF's BDF in advance.
Rename virtfn_bus() and virtfn_devfn() to pci_iov_virtfn_bus() and
pci_iov_virtfn_devfn() and export them.
VFs are dynamically created when a driver enables them. On some platforms,
like PowerNV, special resources are necessary to enable VFs.
Add platform hooks for enabling and disabling VFs.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
drivers/pci/iov.c | 19 +++
1 file
In order to enable SRIOV on PowerNV platform, the PF's IOV BAR needs to be
adjusted:
1. size expanded
2. aligned to M64BT size
This patch documents this change on the reason and how.
[bhelgaas: reformat, clarify, expand]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
M64 aperture size is limited on PHB3. When the IOV BAR is too big, this
will exceed the limitation and failed to be assigned.
Introduce a different mechanism based on the IOV BAR size:
- if IOV BAR size is smaller than 64MB, expand to total_pe
- if IOV BAR size is bigger than 64MB, roundup
On Fri, 2015-03-20 at 10:56 +0700, Arseny Solokha wrote:
This series removes unused functions from powerpc tree that I've been able
to discover.
Two machines at hands, e300 and e500 based, boot and run without regressions
on my workload with this series applied. The removed code seems also
This patchset enables the SRIOV on POWER8.
The general idea is put each VF into one individual PE and allocate required
resources like MMIO/DMA/MSI. The major difficulty comes from the MMIO
allocation and adjustment for PF's IOV BAR.
On P8, we use M64BT to cover a PF's IOV BAR, which could make
An SR-IOV device can change its First VF Offset and VF Stride based on the
values of ARI Capable Hierarchy and NumVFs. The number of buses required
for all VFs is determined by NumVFs, First VF Offset, and VF Stride (see
SR-IOV spec r1.1, sec 2.1.2).
Previously pci_iov_bus_range() computed how
The First VF Offset and VF Stride fields depend on the NumVFs setting, so
refresh the cached fields in struct pci_sriov when updating NumVFs. See
the SR-IOV spec r1.1, sec 3.3.9 and 3.3.10.
[bhelgaas: changelog, remove kernel-doc comment marker]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
When IOV BAR is big, each is covered by 4 M64 windows. This leads to
several VF PE sits in one PE in terms of M64.
Group VF PEs according to the M64 allocation.
[bhelgaas: use dev_printk() when possible]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
In struct pci_dn, the pcidev field is assigned but not used, so remove it.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Acked-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/pci-bridge.h |1 -
arch/powerpc/platforms/powernv/pci-ioda.c |1 -
2 files
On Thu, Mar 19, 2015 at 5:23 PM, Dave Chinner da...@fromorbit.com wrote:
Bit more variance there than the pte checking, but runtime
difference is in the noise - 5m4s vs 4m54s - and profiles are
identical to the pte checking version.
Ahh, so that !(vma-vm_flags VM_WRITE) test works _almost_
From: Gavin Shan gws...@linux.vnet.ibm.com
pci_dn is the extension of PCI device node and is created from device node.
Unfortunately, VFs are enabled dynamically by PF's driver and they don't
have corresponding device nodes, and pci_dn. Refactor pci_dn to support
VFs:
* pci_dn is organized
The PCI config accessors previously relied on device_node. Unfortunately,
VFs don't have a corresponding device_node, so change the accessors to use
pci_dn instead.
[bhelgaas: changelog]
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 14
On PowerNV platform, resource position in M64 BAR implies the PE# the
resource belongs to. In some cases, adjustment of a resource is necessary
to locate it to a correct position in M64 BAR .
This patch adds pnv_pci_vf_resource_shift() to shift the 'real' PF IOV BAR
address according to an
Drop unused static procedure which doesn't have callers within its
translation unit. It had been already removed independently in QEMU[1]
from the OpenPIC implementation borrowed from the kernel.
[1] https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01812.html
Signed-off-by: Arseny
Drop planetcore_set_serial_speed() which had no users since its
inception in commit fec6047047fd ([POWERPC] bootwrapper: Add PlanetCore
firmware support) in 2007.
Signed-off-by: Arseny Solokha asolo...@kb.kras.ru
---
arch/powerpc/boot/planetcore.c | 33 -
Drop unused mpic_set_clk_ratio() and mpic_set_serial_int().
Both functions are almost nine years old[1] but still have no chance
to be called even from out-of-tree modules because they both are __init
and of course aren't exported.
[1]
Drop ucc_slow_poll_transmitter_now() which has no users since its
inception in 2007 in commit 986585385131 ([POWERPC] Add QUICC
Engine (QE) infrastructure).
Signed-off-by: Arseny Solokha asolo...@kb.kras.ru
---
arch/powerpc/include/asm/ucc_slow.h | 13 -
On Thu, Mar 19, 2015 at 06:29:47PM -0700, Linus Torvalds wrote:
On Thu, Mar 19, 2015 at 5:23 PM, Dave Chinner da...@fromorbit.com wrote:
Bit more variance there than the pte checking, but runtime
difference is in the noise - 5m4s vs 4m54s - and profiles are
identical to the pte checking
From: Bjorn Helgaas bhelg...@google.com
Most of PCI uses res = dev-resource[i], not res = dev-resource + i.
Use that style in iov.c also.
No functional change.
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
drivers/pci/iov.c |8
1 file changed, 4 insertions(+), 4
Currently we don't store the individual VF BAR size. We calculate it when
needed by dividing the PF's IOV resource size (which contains space for
*all* the VFs) by total_VFs or by reading the BAR in the SR-IOV capability
again.
Keep the individual VF BAR size in struct pci_sriov.barsz[], add
Implement pcibios_iov_resource_alignment() on powernv platform.
On PowerNV platform, there are 3 cases for the IOV BAR:
1. initial state, the IOV BAR size is multiple times of VF BAR size
2. after expanded, the IOV BAR size is expanded to meet the M64 segment size
3. sizing stage, the IOV BAR is
This series removes unused functions from powerpc tree that I've been able
to discover.
Two machines at hands, e300 and e500 based, boot and run without regressions
on my workload with this series applied. The removed code seems also been
rarely touched, so it seems the series is safe at least in
On Fri, 2015-03-20 at 10:56 +0700, Arseny Solokha wrote:
This series removes unused functions from powerpc tree that I've been able
to discover.
Two machines at hands, e300 and e500 based, boot and run without regressions
on my workload with this series applied. The removed code seems also
Benjamin Herrenschmidt b...@kernel.crashing.org writes:
On Wed, 2015-03-18 at 19:49 +0530, Aneesh Kumar K.V wrote:
Why not do it also for DMA32 as below. We call limit_zone_pfn() only
for few
platforms. They can select ZONE_DMA32. Everywhere else ZONE_DMA32 is
same as ZONE_NORMAL ? So
When we size VF BAR0, VF BAR1, etc., from the SR-IOV Capability of a PF, we
learn the alignment requirement and amount of space consumed by a single
VF. But when VFs are enabled, *each* of the NumVFs consumes that amount of
space, so the total size of the PF resource is VF BAR size * NumVFs.
Add
From: Bjorn Helgaas bhelg...@google.com
If we don't have space for all the bus numbers required to enable VFs,
print the largest bus number required and the range available.
No functional change; improved error message only.
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
When sizing and assigning resources, we divide the resources into two
lists: the requested list and the additional list. We don't consider the
alignment of additional VF(n) BAR space.
This is because the alignment required for the VF(n) BAR space is the size
of an individual VF BAR, not the size
Per the SR-IOV spec r1.1, sec 3.3.14, the required alignment of a PF's IOV
BAR is the size of an individual VF BAR, and the size consumed is the
individual VF BAR size times NumVFs.
The PowerNV platform has additional alignment requirements to help support
its Partitionable Endpoint device
On Thu, Mar 19, 2015 at 3:41 PM, Dave Chinner da...@fromorbit.com wrote:
My recollection wasn't faulty - I pulled it from an earlier email.
That said, the original measurement might have been faulty. I ran
the numbers again on the 3.19 kernel I saved away from the original
testing. That came
On Thu, 2015-03-19 at 09:22 +0200, Alex Dowad wrote:
On 19/03/15 08:45, Michael Ellerman wrote:
On Fri, 2015-13-03 at 18:14:46 UTC, Alex Dowad wrote:
The 'arg' argument to copy_thread() is only ever used when forking a new
kernel thread. Hence, rename it to 'kthread_arg' for clarity (and
It simplifies the creation of the hwmon attributes and will help when
support for a new device tree layout is added. The patch also changes
the name of the routine to parse_opal_node_name().
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
Changes since v1:
- changed returned value of
On Wed, Mar 18, 2015 at 10:31:28AM -0700, Linus Torvalds wrote:
- something completely different that I am entirely missing
So I think there's something I'm missing. For non-shared mappings, I
still have the idea that pte_dirty should be the same as pte_write.
And yet, your testing of 3.19
Hello !
The current implementation of the driver uses an index for the hwmon
attribute which is extracted from the device node name. This index
is calculated by the OPAL firmware and its usage creates a dependency
with the driver which makes changes a little more complex in OPAL.
This patchset
The current OPAL firmware exposes the different sensors of an IBM Power
system using node names such as :
sensors/amb-temp#1-data
sensors/amb-temp#1-thrs
cooling-fan#1-data
cooling-fan#1-faulted
cooling-fan#1-thrs
cooling-fan#2-data
...
The
On Thu, Mar 19, 2015 at 7:10 AM, Mel Gorman mgor...@suse.de wrote:
- if (!pmd_dirty(pmd))
+ /* See similar comment in do_numa_page for explanation */
+ if (!(vma-vm_flags VM_WRITE))
Yeah, that would certainly be a whole lot more obvious than all the
if this particular
Ambient is too restrictive as there can be other temperature channels :
core, memory, etc.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
drivers/hwmon/ibmpowernv.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux.git/drivers/hwmon/ibmpowernv.c
It simplifies the create_hwmon_attr_name() routine and it clearly isolates
the conversion done between the OPAL node names and hwmon attributes names.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
Changes since v1:
- fixed alignment
- killed a couple of useless return NULL
On Thu, Mar 19, 2015 at 11:18 AM, Wei Yang weiyang.ker...@gmail.com wrote:
Oh, I thought you are not comfortable with the Patch v12 10/21 PCI:
Consider additional PF's IOV BAR alignment ...
V14 is ready to send which is based on v4.0-rc1.
Unless I missed something, the last email in that
It will help in adding different compatible properties, coming from a
new device tree layout for example.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
drivers/hwmon/ibmpowernv.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
Index:
On Thu, Mar 12, 2015 at 09:15:17AM +0800, Wei Yang wrote:
On Wed, Mar 11, 2015 at 08:55:07AM -0500, Bjorn Helgaas wrote:
On Wed, Mar 04, 2015 at 01:19:07PM +0800, Wei Yang wrote:
On PHB3, PF IOV BAR will be covered by M64 window to have better PE
isolation. The total_pe number is usually
On Thu, 19 Mar 2015 17:56:57 +0200
Horia Geantă horia.gea...@freescale.com wrote:
On 3/18/2015 12:03 AM, Kim Phillips wrote:
On Tue, 17 Mar 2015 19:58:55 +0200
Horia Geantă horia.gea...@freescale.com wrote:
On 3/17/2015 2:19 AM, Kim Phillips wrote:
On Mon, 16 Mar 2015 12:02:51 +0200
Oh, I thought you are not comfortable with the Patch v12 10/21 PCI:
Consider additional PF's IOV BAR alignment ...
V14 is ready to send which is based on v4.0-rc1.
2015-03-19 23:08 GMT+08:00 Bjorn Helgaas bhelg...@google.com:
On Thu, Mar 12, 2015 at 09:15:17AM +0800, Wei Yang wrote:
On Wed,
Switch on -mprofile-kernel, and remove it again
from directories involved in exception handling.
This needs to be done more fine grained, of course.
diff --git a/Makefile b/Makefile
index 1a60bdd..72644e6 100644
--- a/Makefile
+++ b/Makefile
@@ -732,7 +732,10 @@ ifdef CONFIG_FUNCTION_TRACER
On Fri, Mar 13 2015, Nishanth Aravamudan n...@linux.vnet.ibm.com wrote:
On 13.03.2015 [00:09:19 +0100], Rasmus Villemoes wrote:
Since the new code plays a little endianness game I would really
appreciate it if someone here would run the test and verification code
on ppc.
On a ppc64le box:
Here's an initial version of dynamic ftrace for ABIv2 (ppc64le),
the code maturity is somewhere between proof of concept and pre-alpha.
I have split it into 4 parts, for ftrace and kgraft, a configuration
enablement and the actual code, respectively.
Please have a look and tell me whether this is
I'm pretty sure not everything is ifdef'd properly,
and the FIXME needs to be solved in order to disable
ftracing again. Built upon some original code by
Vojtech Pavlik.
diff --git a/arch/powerpc/include/asm/ftrace.h
b/arch/powerpc/include/asm/ftrace.h
index e366187..a69d47e 100644
---
The kgraft hooks for ppc64. Just massaged a bit to
get them to compile and not interfere.
Feel free to test them if you're daring ;)
diff --git a/arch/powerpc/include/asm/kgraft.h
b/arch/powerpc/include/asm/kgraft.h
new file mode 100644
index 000..7f8600d
--- /dev/null
+++
On 03/19/2015 02:01 PM, Benjamin Herrenschmidt wrote:
Ben One thing I noticed is the asymetry in your code between the alloc
Ben and the free path. The alloc path is similar to us in that the lock
Ben covers the allocation and that's about it, there's no actual mapping to
Ben the HW done, it's
Enable kgraft on ppc, fairly trivial.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4bc7b62..d82d7c8 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -102,6 +104,7 @@ config PPC
select HAVE_IOREMAP_PROT
select HAVE_EFFICIENT_UNALIGNED_ACCESS if
Vasant Hegde hegdevas...@linux.vnet.ibm.com writes:
From: Anshuman Khandual khand...@linux.vnet.ibm.com
This patch registers the following two new OPAL interfaces calls
for the platform LED subsystem. With the help of these new OPAL calls,
the kernel will be able to get or set the state of
On Friday, March 13, 2015 12:39:02 PM yuantian.t...@freescale.com wrote:
From: Tang Yuantian yuantian.t...@freescale.com
This driver works on all QorIQ platforms which include
ARM-based cores and PPC-based cores.
Rename it in order to represent better.
Signed-off-by: Tang Yuantian
On Wed, Mar 18, 2015 at 10:31 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
So I think there's something I'm missing. For non-shared mappings, I
still have the idea that pte_dirty should be the same as pte_write.
And yet, your testing of 3.19 shows that it's a big difference.
On 3/18/2015 12:03 AM, Kim Phillips wrote:
On Tue, 17 Mar 2015 19:58:55 +0200
Horia Geantă horia.gea...@freescale.com wrote:
On 3/17/2015 2:19 AM, Kim Phillips wrote:
On Mon, 16 Mar 2015 12:02:51 +0200
Horia Geantă horia.gea...@freescale.com wrote:
On 3/4/2015 2:23 AM, Kim Phillips wrote:
71 matches
Mail list logo
