On 05/28/2014 12:53 PM, Guenter Roeck wrote:
On 05/19/2014 07:26 AM, Neelesh Gupta wrote:
This patch adds basic kernel enablement for reading power values, fan
speed rpm and temperature values on powernv platforms which will
be exported to user space through sysfs interface.
Test results:
EEH information fetched from OPAL need fix before using in LE environment.
To be included in sparse's endian check, declare them as __beXX and
access them by accessors.
Cc: Gavin Shan gws...@linux.vnet.ibm.com
Signed-off-by: Guo Chao y...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h
On 06/09/2014 01:18 AM, Ben Dooks wrote:
On Fri, May 30, 2014 at 08:16:59PM +0200, Lars-Peter Clausen wrote:
On 05/30/2014 07:33 PM, David Daney wrote:
On 05/30/2014 04:39 AM, Geert Uytterhoeven wrote:
On Fri, May 30, 2014 at 1:30 PM, abdoulaye berthe berthe...@gmail.com
wrote:
---
How's the fsl,qman-channel-id value different for different targets ?
Is there any document on how this value is achieved ?
Or can it be any value ???
Alan.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Hello Tony,
On 06/09/2014 06:43 AM, Tony wrote:
How's the fsl,qman-channel-id value different for different targets ?
Channel ids are assigned in hardware
Is there any document on how this value is achieved ?
They are described in the RM of each SoC and in the DPAA RM
Or can it be any
The FCC_GFMR_TTX define is cut and pasted twice so we can remove the
second instance.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/arch/powerpc/include/asm/cpm2.h b/arch/powerpc/include/asm/cpm2.h
index f42e9ba..7c8608b 100644
--- a/arch/powerpc/include/asm/cpm2.h
+++
The SPUFS_CNTL_MAP_SIZE define is cut and pasted twice so we can delete
the second instance.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/arch/powerpc/platforms/cell/spufs/spufs.h
b/arch/powerpc/platforms/cell/spufs/spufs.h
index 0ba3c95..bcfd6f0 100644
---
On Mon, 9 Jun 2014, Geert Uytterhoeven wrote:
JFYI, when comparing v3.15-rc8[1] to v3.15-rc7[3], the summaries are:
- build errors: +4/-4
+ /scratch/kisskb/src/kernel/bounds.c: error: -mcall-aixdesc must be big
endian: = 1:0
+ /scratch/kisskb/src/scripts/mod/devicetable-offsets.c:
Thank Emil.
Where can i find the details about a 'diff' of qman revisions ? The code i
ported doesnt support latest qman revision (REV3). Can i still work on qman
REV1.1 for all the latest targets ? (read t-series)
Regards
On Mon, Jun 9, 2014 at 8:32 PM, Emil Medve emilian.me...@freescale.com
On Fri, 23 May 2014, Srivatsa S. Bhat wrote:
diff --git a/arch/powerpc/include/asm/topology.h
b/arch/powerpc/include/asm/topology.h
index c920215..58e6469 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -18,6 +18,7 @@ struct device_node;
*/
On Wed, 21 May 2014, Nishanth Aravamudan wrote:
For context: I was looking at why N_ONLINE was statically setting Node 0
to be online, whether or not the topology is that way -- I've been
getting several bugs lately where Node 0 is online, but has no CPUs and
no memory on it, on powerpc.
Hi Dan,
The SPUFS_CNTL_MAP_SIZE define is cut and pasted twice so we can delete
the second instance.
Looks good to me.
Acked-by: Jeremy Kerr j...@ozlabs.org
Cheers,
Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On Fri, Jun 06, 2014 at 12:20:04PM -0600, Alex Williamson wrote:
On Fri, 2014-06-06 at 15:00 +1000, Gavin Shan wrote:
The patch adds new IOCTL commands for sPAPR VFIO container device
to support EEH functionality for PCI devices, which have been passed
through from host to somebody else via
On Mon, Jun 09, 2014 at 04:58:51PM +0800, Guo Chao wrote:
EEH information fetched from OPAL need fix before using in LE environment.
To be included in sparse's endian check, declare them as __beXX and
access them by accessors.
Cc: Gavin Shan gws...@linux.vnet.ibm.com
Signed-off-by: Guo Chao
EEH Support for VFIO PCI Device
The series of patches adds support EEH for PCI devices, which are passed
through to PowerKVM based guest via VFIO. The implementation is straightforward
based on the issues or problems we have to resolve to support EEH for PowerKVM
based guest.
- Emulation for EEH
We must not handle EEH error on devices which are passed to somebody
else. Instead, we expect that the frozen device owner detects an EEH
error and recovers from it.
This avoids EEH error handling on passed through devices so the device
owner gets a chance to handle them.
Signed-off-by: Gavin
The patch exports functions to be used by new VFIO ioctl command,
which will be introduced in subsequent patch, to support EEH
functinality for VFIO PCI devices.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
Acked-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/eeh.h | 12 ++
The patch adds new IOCTL commands for sPAPR VFIO container device
to support EEH functionality for PCI devices, which have been passed
through from host to somebody else via VFIO.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
Acked-by: Alexander Graf ag...@suse.de
---
This patch set enable the SRIOV on POWER8. This is not the final version, some
patches rely on un-merged patches.
The gerneral idea is put each VF in their own PE and allocated necessary
resources, like DMA/IOMMU_TABLE.
One thing special for VF PE is we use M64BT to cover the IOV BAR. This means
When implementing the SR-IOV on PowerNV platform, some resource reservation is
needed for VFs which 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.
In this patch, it exports the interface to retrieve VF's BDF:
* Make the
As introduced by commit 98d9f30c82 (pci/of: Match PCI devices to dev-tree nodes
dynamically), we need to match PCI devices to their corresponding dev-tree
nodes. While for VFs, this step was missed.
This patch matches VFs' PCI devices to dev-tree nodes dynamically.
Signed-off-by: Wei Yang
VFs are dynamically created/released when driver enable them. On some
platforms, like PowerNV, special resources are necessary to enable VFs.
This patch adds two hooks for platform initialization before creating the VFs.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
drivers/pci/iov.c |
When the PCI_REASSIGN_ALL_RSRC is set, each resource for a pci_dev will be
unset. which means the pci core will reassign those resources.
While this behavior will clean up the resources information for VFs, whose
value is calculated in virtfn_add.
This patch adds a condition. If the pci_dev is a
During the initialization of the TVT/TCE, it uses digits to specify the TCE IO
Page Size, TCE Table Size, TCE Entry Size, etc.
This patch replaces those digits with macros, which will be more meaningful and
easy to read.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
Current iommu_table of a PE is a static field. This will have a problem when
iommu_free_table is called.
This patch allocate iommu_table dynamically.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/iommu.h |3 +++
On PowerNV platform, it will support dynamic PE allocation and deallocation.
This patch adds a function to release those resources related to a PE.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-ioda.c | 77 +
1 file
When retrieving sriov resource size in pci_sriov_resource_size(), it will
divide the total IOV resource size with the totalVF number. This is true for
most cases, while may not be correct on some specific platform.
For example on powernv platform, in order to fix the IOV BAR into a hardware
The sriov resource alignment is designed to be the individual size of a sriov
resource. This works fine for many platforms, but on powernv platform it needs
some change.
The original alignment works, since at sizing and assigning stage the
requirement is from an individual VF's resource size
At resource sizing/assigning stage, resources are divided into two lists,
requested list and additional list, while the alignement of the additional
IOV BAR is not taken into the sizeing and assigning procedure.
This is reasonable in the original implementation, since IOV BAR's alignment is
This patch implements the pcibios_sriov_resource_alignment() on powernv
platform.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/machdep.h|1 +
arch/powerpc/kernel/pci-common.c |8
arch/powerpc/platforms/powernv/pci-ioda.c | 17
On PHB3, VF resources will be covered by M64 BAR to have better PE isolation.
Mostly the total_pe number is different from the total_VFs, which will lead to
a conflict between MMIO space and the PE number.
This patch expands the VF resource size to reserve total_pe number of VFs'
resource, which
On powrnv platform, resource position in M64 implies the PE# the resource
belongs to. In some particular case, adjustment of a resource is necessary to
locate it to a correct position in M64.
This patch introduce a function to shift the 'real' VF BAR address according to
an offset.
M64 aperture size is limited on PHB3. When the IOV BAR is too big, this will
exceed the limitation and failed to be assigned.
This patch introduce a different expanding based on the IOV BAR size:
IOV BAR size is smaller than 64M, expand to total_pe.
IOV BAR size is bigger than 64M, roundup
VFs are created, when driver intends to enable sriov.
This patch assign related resources and allocate PEs for VF at this moment.
This patch allocate enough M64 for IOV BAR and shift the VF resource to meet
the PE# indicated by M64.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
When IOV BAR is big, each of it is covered by 4 M64 window. This leads to
several VF PE sits in one PE in terms of M64.
This patch group VF PEs according to the M64 allocation.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/pci-bridge.h |2 +-
On Tue, Jun 03, 2014 at 08:56:00AM +0200, Michal Nazarewicz wrote:
On Tue, Jun 03 2014, Joonsoo Kim wrote:
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they
On Tue, Jun 03, 2014 at 09:00:48AM +0200, Michal Nazarewicz wrote:
On Tue, Jun 03 2014, Joonsoo Kim wrote:
Now, we have general CMA reserved area management framework,
so use it for future maintainabilty. There is no functional change.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
On Thu, Jun 05, 2014 at 11:09:05PM +0530, Aneesh Kumar K.V wrote:
Joonsoo Kim iamjoonsoo@lge.com writes:
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they
The Vector Crypto category instructions are supported by current POWER8
chips, advertise them to userspace using a specific bit to properly
differentiate with chips of the same architecture level that might not
have them.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
CC:
39 matches
Mail list logo
