On Sun, 2015-03-08 at 16:44 +0530, Vasant Hegde wrote:
> From: Anshuman Khandual
>
> 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 various individual
>
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
>---
> drivers/pci/i
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 powerp
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 defi
Benjamin Herrenschmidt 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 instead of having conf
> 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 s
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 al
On Thu, Mar 19, 2015 at 06:29:47PM -0700, Linus Torvalds wrote:
> On Thu, Mar 19, 2015 at 5:23 PM, Dave Chinner 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.
>
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] https://lists.ozlabs.org/pipermail/linuxppc-dev/2006-June/023
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
---
arch/powerpc/include/asm/ucc_slow.h | 13 -
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 5 --
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
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
---
arch/powerpc/boot/planetcore.c | 33 -
arch/powerpc/boot/planetco
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 Solokha
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 p
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
---
.../powerpc/pci_iov_resource_on_power
In struct pci_dn, the pcidev field is assigned but not used, so remove it.
Signed-off-by: Wei Yang
Acked-by: Gavin Shan
---
arch/powerpc/include/asm/pci-bridge.h |1 -
arch/powerpc/platforms/powernv/pci-ioda.c |1 -
2 files changed, 2 deletions(-)
diff --git a/arch/powerpc/include/
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
---
arch/powerpc/include/asm/pci-bridge.h |2 +-
arch/powe
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 offset.
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 t
On PHB3, PF IOV BAR will be covered by M64 BAR to have better PE isolation.
M64 BAR is a type of hardware resource in PHB3, which could map a range of
MMIO to PE numbers on powernv platform. And this range is divided equally
by the number of total_pe with each divided range mapping to a PE number.
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
pnv_io
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 f
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 isolati
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
---
drivers/pci/iov.c | 19 +++
1 file changed, 19 insertions(+)
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.
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 ma
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
---
drivers/pci/iov.c |
From: Bjorn Helgaas
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
---
drivers/pci/iov.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/iov.
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
pci_
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".
Ad
From: Bjorn Helgaas
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
---
drivers/pci/iov.c |7 +--
1 file changed, 5 ins
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
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 14 +-
arch/powerpc/platf
From: Gavin Shan
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 as a hierarchy tree. VF's
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 a
Vasant Hegde writes:
> From: Anshuman Khandual
>
> 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 through LED specific device tree
> nodes. Device tree nodes
On Thu, Mar 19, 2015 at 5:23 PM, Dave Chinner 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_ as well
as th
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
>
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
2015-03-20 1:54 GMT+08:00 Bjorn Helgaas :
> On Thu, Mar 19, 2015 at 11:18 AM, Wei Yang 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 someth
On Thu, Mar 19, 2015 at 04:05:46PM -0700, Linus Torvalds wrote:
> On Thu, Mar 19, 2015 at 3:41 PM, Dave Chinner 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
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 power7
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 av
On Thu, Mar 19, 2015 at 3:41 PM, Dave Chinner 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 up at 235k, whi
On Thu, Mar 19, 2015 at 02:41:48PM -0700, Linus Torvalds wrote:
> On Wed, Mar 18, 2015 at 10:31 AM, Linus Torvalds
> 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
On Wed, Mar 18, 2015 at 10:31 AM, Linus Torvalds
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.
> There's clearly something I'm c
On Friday, March 13, 2015 12:39:02 PM yuantian.t...@freescale.com wrote:
> From: Tang Yuantian
>
> 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
> Acked-by: Viresh Kumar
Vasant Hegde writes:
> From: Anshuman Khandual
>
> 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 various individual
> LEDs on the system at any given lo
On Fri, Mar 13 2015, Nishanth Aravamudan 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:
[...]
>
> On a p
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 !CPU_
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
+++ b/arch/powerpc/incl
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
ifdef
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
--- a/arch/pow
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 t
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 :
> On Thu, Mar 12, 2015 at 09:15:17AM +0800, Wei Yang wrote:
> > On Wed, Mar 11, 2015 at
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'
On Thu, 19 Mar 2015 17:56:57 +0200
Horia Geantă wrote:
> On 3/18/2015 12:03 AM, Kim Phillips wrote:
> > On Tue, 17 Mar 2015 19:58:55 +0200
> > Horia Geantă wrote:
> >
> >> On 3/17/2015 2:19 AM, Kim Phillips wrote:
> >>> On Mon, 16 Mar 2015 12:02:51 +0200
> >>> Horia Geantă wrote:
> >>>
>
On Thu, Mar 19, 2015 at 7:10 AM, Mel Gorman 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 pte/pmd looks li
On Thu, Mar 19, 2015 at 11:18 AM, Wei Yang 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 thread [1] is from
you,
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
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
---
Changes since v1:
- fixed alignment
- killed a couple of useless "return NULL"
drivers/hwmon/ibmpowernv.
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
---
Changes since v1:
- changed returned value of parse_opal_node_name(
Ambient is too restrictive as there can be other temperature channels :
core, memory, etc.
Signed-off-by: Cédric Le Goater
---
drivers/hwmon/ibmpowernv.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux.git/drivers/hwmon/ibmpowernv.c
==
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
It will help in adding different compatible properties, coming from a
new device tree layout for example.
Signed-off-by: Cédric Le Goater
---
drivers/hwmon/ibmpowernv.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
Index: linux.git/drivers/hwmon/ibmpowernv
On 3/18/2015 12:03 AM, Kim Phillips wrote:
> On Tue, 17 Mar 2015 19:58:55 +0200
> Horia Geantă wrote:
>
>> On 3/17/2015 2:19 AM, Kim Phillips wrote:
>>> On Mon, 16 Mar 2015 12:02:51 +0200
>>> Horia Geantă wrote:
>>>
On 3/4/2015 2:23 AM, Kim Phillips wrote:
> Only potential problem is ge
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 us
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
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
Thanks, applied this one.
The rest ASoC patches are left to Mark.
Takashi
> ---
> sound/aoa/sou
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 implemen
71 matches
Mail list logo
