RE: [PATCH v2 2/3] powerpc/85xx: add hardware automatically enter altivec idle state
-Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, August 27, 2013 4:42 PM To: Wood Scott-B07421; ga...@kernel.crashing.org Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534 Subject: [PATCH v2 2/3] powerpc/85xx: add hardware automatically enter altivec idle state From: Wang Dongsheng dongsheng.w...@freescale.com Each core's AltiVec unit may be placed into a power savings mode by turning off power to the unit. Core hardware will automatically power down the AltiVec unit after no AltiVec instructions have executed in N cycles. The AltiVec power-control is triggered by hardware. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- *v2: Remove: delete setup_idle_hw_governor function. delete Fix erratum for rev1. Move: move setup_* into __setup/restore_cpu_e6500. diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index 86ede76..8364bbe 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -217,6 +217,9 @@ #define CCR1_DPC0x0100 /* Disable L1 I-Cache/D-Cache parity checking */ #define CCR1_TCS0x0080 /* Timer Clock Select */ +/* Bit definitions for PWRMGTCR0. */ +#define PWRMGTCR0_ALTIVEC_IDLE (1 22) /* Altivec idle enable */ + /* Bit definitions for the MCSR. */ #define MCSR_MCS 0x8000 /* Machine Check Summary */ #define MCSR_IB 0x4000 /* Instruction PLB Error */ diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S index bfb18c7..90bbb46 100644 --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S @@ -58,6 +58,7 @@ _GLOBAL(__setup_cpu_e6500) #ifdef CONFIG_PPC64 bl .setup_altivec_ivors #endif + bl setup_altivec_idle bl __setup_cpu_e5500 mtlrr6 blr @@ -119,6 +120,7 @@ _GLOBAL(__setup_cpu_e5500) _GLOBAL(__restore_cpu_e6500) mflrr5 bl .setup_altivec_ivors + bl setup_altivec_idle bl __restore_cpu_e5500 mtlrr5 blr diff --git a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c index d0861a0..93b563b 100644 --- a/arch/powerpc/platforms/85xx/common.c +++ b/arch/powerpc/platforms/85xx/common.c @@ -11,6 +11,16 @@ #include mpc85xx.h +#define MAX_BIT 64 + This should be change to 63, i will fix this in next patch. - dongsheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
On Wed, Aug 28, 2013 at 11:26:31AM +1000, Benjamin Herrenschmidt wrote: On Wed, 2013-08-28 at 10:51 +1000, Alexey Kardashevskiy wrote: The ioctl I made up is basically a copy of KVM_CREATE_SPAPR_TCE which does the same thing for emulated devices and it is there for quite a while but it is not really extensible. And these two ioctls share some bits of code. Now we will have 2 pieces of code which do almost the same thing but in a different way. Kinda sucks :( Right. Thus the question, Gleb, we can either: - Keep Alexey patch as-is allowing us to *finally* merge that stuff that's been around for monthes - Convert *both* existing TCE objects to the new KVM_CREATE_DEVICE, and have some backward compat code for the old one. I don't think it makes sense to have the emulated TCE and IOMMU TCE objects use a fundamentally different API and infrastructure. As a general rule we are not going to mandate converting old devices to new API, but if it make sense to do here I would much prefer that over adding another special ioctl So my stuff is not going to upstream again. Heh. Ok. I'll implement it. Thanks! Should I keep KVM_CAP_SPAPR_MULTITCE capability patch or can I drop it for now? Please keep it, it is unrelated to the IOMMU-VFIO thing. -- Gleb. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On 08/27/2013 07:35 PM, Mark Rutland wrote:
On Tue, Aug 27, 2013 at 11:42:02AM +0100, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 66
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 232 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..10fd031 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,72 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include fsl,elo3-dma
+- reg : registers specifier for DMA general status reg
+- ranges: describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+- compatible: must include fsl,eloplus-dma-channel
+- reg : registers specifier for channel
+- interrupts: interrupt specifier for DMA channel IRQ
+- interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elo3-dma;
+ reg = 0x100300 0x4 0x100600 0x4;
Is that one reg entry where #size-cells=2 and #address-cells=2?
That's what the binding implies (given it only describes a single reg
entry).
if it's two entries, we should make that explicit (both in the binding
and example):
reg = 0x100300 0x4,
0x100600 0x4;
Yes they are two entries, I will change it this way.
+ ranges = 0x0 0x100100 0x500;
If it is one reg entry then the example ranges property isn't big enough
to contain the parent-bus-address.
They are two reg entries, so the range is big enough.
+ dma-channel@0 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x0 0x80;
+ interrupts = 28 2 0 0;
+ };
+ dma-channel@80 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x80 0x80;
+ interrupts = 29 2 0 0;
+ };
+ dma-channel@100 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x100 0x80;
+ interrupts = 30 2 0 0;
+ };
+ dma-channel@180 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x180 0x80;
+ interrupts = 31 2 0 0;
+ };
+ dma-channel@300 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x300 0x80;
+ interrupts = 76 2 0 0;
+ };
+ dma-channel@380 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x380 0x80;
+ interrupts = 77 2 0 0;
+ };
+ dma-channel@400 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x400 0x80;
+ interrupts = 78 2 0 0;
+ };
+ dma-channel@480 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x480 0x80;
+ interrupts = 79 2 0 0;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must say
fsl,elo-dma-channel or fsl,eloplus-dma-channel to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = 0xe2000 0x1000;
};
-/include/ qoriq-dma-0.dtsi
+/include/ elo3-dma-0.dtsi
dma@100300 {
fsl,iommu-parent = pamu0;
fsl,liodn-reg = guts 0x580; /* DMA1LIODNR */
};
-/include/ qoriq-dma-1.dtsi
+/include/ elo3-dma-1.dtsi
dma@101300 {
fsl,iommu-parent = pamu0;
fsl,liodn-reg = guts 0x584; /* DMA2LIODNR */
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
Re: [PATCH v8 1/3] DMA: Freescale: revise device tree binding document
On 08/27/2013 07:25 PM, Mark Rutland wrote: On Tue, Aug 27, 2013 at 11:42:01AM +0100, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang hongbo.zh...@freescale.com This patch updates the discription of each type of DMA controller and its channels, it is preparation for adding another new DMA controller binding, it also fixes some defects of indent for text alignment at the same time. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com --- .../devicetree/bindings/powerpc/fsl/dma.txt| 62 +--- 1 file changed, 27 insertions(+), 35 deletions(-) diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt index 2a4b4bc..ddf17af 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt @@ -1,33 +1,29 @@ -* Freescale 83xx DMA Controller +* Freescale DMA Controllers -Freescale PowerPC 83xx have on chip general purpose DMA controllers. +** Freescale Elo DMA Controller + This is a little-endian DMA controller, used in Freescale mpc83xx series + chips such as mpc8315, mpc8349, mpc8379 etc. Required properties: -- compatible: compatible list, contains 2 entries, first is -fsl,CHIP-dma, where CHIP is the processor -(mpc8349, mpc8360, etc.) and the second is -fsl,elo-dma -- reg : registers mapping for DMA general status reg -- ranges : Should be defined as specified in 1) to describe the - DMA controller channels. +- compatible: must include fsl,elo-dma We should list the other values that may be in the list also, unless they are really of no consequence, in which case their presence in dt is questionable. Hmm. Stephen questioned here too, it seems this is a default rule. Although Scott@freescale had explained our thoughts, I'd like to edit this item like this: must include fsl,eloplus-dma, and a fsl,CHIP-dma is optional, where CHIP is the processor name We don't list all the chip name because we have tens of them and we cannot list all of them, and it is unnecessary to list them because we even don't use fsl,CHIP-dma in the new driver, add fsl,CHIP-dma here just make it questionable when it presents in example and old dts files. I remove the examples in bracket (mpc8349, mpc8360, etc.) because we can see the real example below. I don't say if fsl,CHIP-dma presents, it should be the first one, and the fsl,eloplus-dma should be the second because it is common rule. the description language should be clear and concise too I think. +- reg : registers specifier for DMA general status reg +- ranges: describes the mapping between the address space of the + DMA channels and the address space of the DMA controller - cell-index: controller index. 0 for controller @ 0x8100 -- interrupts: interrupt mapping for DMA IRQ +- interrupts: interrupt specifier for DMA IRQ - interrupt-parent : optional, if needed for interrupt mapping - - DMA channel nodes: -- compatible: compatible list, contains 2 entries, first is -fsl,CHIP-dma-channel, where CHIP is the processor -(mpc8349, mpc8350, etc.) and the second is -fsl,elo-dma-channel. However, see note below. -- reg : registers mapping for channel +- compatible: must include fsl,elo-dma-channel + However, see note below. Again, I think we should list the other entries that may be in the list. Otherwise it's not clear what the binding defines. Similarly for the other compatible list definitions below... +- reg : registers specifier for channel - cell-index: dma channel index starts at 0. I realise you haven't changed it, but it's unclear what the cell-index property is (and somewhat confusingly there seem to be multiple defnitions). It might be worth clarifying it while performing the other cleanup. not clear with your point multiple definitions, we really have multiple dma channels for one dma controller. cell-index is used as channel index, this is an old method used by old driver, my patch didn't touch this part. Optional properties: -- interrupts: interrupt mapping for DMA channel IRQ - (on 83xx this is expected to be identical to - the interrupts property of the parent node) +- interrupts: interrupt specifier for DMA channel IRQ + (on 83xx this is expected to be identical to + the interrupts property of the parent node) - interrupt-parent : optional, if needed for interrupt mapping Example: @@ -70,30 +66,26 @@ Example: };
[PATCH v9 00/13] KVM: PPC: IOMMU in-kernel handling of VFIO
This accelerates VFIO DMA operations on POWER by moving them into kernel. This depends on VFIO external API patch which is on its way to upstream. Changes: v9: * replaced the link logical bus number to IOMMU group ioctl to KVM with a KVM device doing the same thing, i.e. the actual changes are in these 3 patches: KVM: PPC: reserve a capability and KVM device type for realmode VFIO KVM: PPC: remove warning from kvmppc_core_destroy_vm KVM: PPC: Add support for IOMMU in-kernel handling * moved some VFIO external API bits to a separate patch to reduce the size of the KVM: PPC: Add support for IOMMU in-kernel handling patch * fixed code style problems reported by checkpatch.pl. v8: * fixed comments about capabilities numbers v7: * rebased on v3.11-rc3. * VFIO external user API will go through VFIO tree so it is excluded from this series. * As nobody ever reacted on hashtable: add hash_for_each_possible_rcu_notrace(), Ben suggested to push it via his tree so I included it to the series. * realmode_(get|put)_page is reworked. More details in the individual patch comments. Alexey Kardashevskiy (13): KVM: PPC: POWERNV: move iommu_add_device earlier hashtable: add hash_for_each_possible_rcu_notrace() KVM: PPC: reserve a capability number for multitce support KVM: PPC: reserve a capability and KVM device type for realmode VFIO powerpc: Prepare to support kernel handling of IOMMU map/unmap powerpc: add real mode support for dma operations on powernv KVM: PPC: enable IOMMU_API for KVM_BOOK3S_64 permanently KVM: PPC: Add support for multiple-TCE hcalls powerpc/iommu: rework to support realmode KVM: PPC: remove warning from kvmppc_core_destroy_vm KVM: PPC: add trampolines for VFIO external API KVM: PPC: Add support for IOMMU in-kernel handling KVM: PPC: Add hugepage support for IOMMU in-kernel handling Documentation/virtual/kvm/api.txt | 26 + .../virtual/kvm/devices/spapr_tce_iommu.txt| 37 ++ arch/powerpc/include/asm/iommu.h | 18 +- arch/powerpc/include/asm/kvm_host.h| 38 ++ arch/powerpc/include/asm/kvm_ppc.h | 16 +- arch/powerpc/include/asm/machdep.h | 12 + arch/powerpc/include/asm/pgtable-ppc64.h | 2 + arch/powerpc/include/uapi/asm/kvm.h| 8 + arch/powerpc/kernel/iommu.c| 243 + arch/powerpc/kvm/Kconfig | 1 + arch/powerpc/kvm/book3s_64_vio.c | 597 - arch/powerpc/kvm/book3s_64_vio_hv.c| 408 +- arch/powerpc/kvm/book3s_hv.c | 42 +- arch/powerpc/kvm/book3s_hv_rmhandlers.S| 8 +- arch/powerpc/kvm/book3s_pr_papr.c | 35 ++ arch/powerpc/kvm/powerpc.c | 4 + arch/powerpc/mm/init_64.c | 50 +- arch/powerpc/platforms/powernv/pci-ioda.c | 57 +- arch/powerpc/platforms/powernv/pci-p5ioc2.c| 2 +- arch/powerpc/platforms/powernv/pci.c | 75 ++- arch/powerpc/platforms/powernv/pci.h | 3 +- arch/powerpc/platforms/pseries/iommu.c | 8 +- include/linux/hashtable.h | 15 + include/linux/kvm_host.h | 1 + include/linux/mm.h | 14 + include/linux/page-flags.h | 4 +- include/uapi/linux/kvm.h | 3 + virt/kvm/kvm_main.c| 5 + 28 files changed, 1564 insertions(+), 168 deletions(-) create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt -- 1.8.4.rc4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v9 01/13] KVM: PPC: POWERNV: move iommu_add_device earlier
The current implementation of IOMMU on sPAPR does not use iommu_ops
and therefore does not call IOMMU API's bus_set_iommu() which
1) sets iommu_ops for a bus
2) registers a bus notifier
Instead, PCI devices are added to IOMMU groups from
subsys_initcall_sync(tce_iommu_init) which does basically the same
thing without using iommu_ops callbacks.
However Freescale PAMU driver (https://lkml.org/lkml/2013/7/1/158)
implements iommu_ops and when tce_iommu_init is called, every PCI device
is already added to some group so there is a conflict.
This patch does 2 things:
1. removes the loop in which PCI devices were added to groups and
adds explicit iommu_add_device() calls to add devices as soon as they get
the iommu_table pointer assigned to them.
2. moves a bus notifier to powernv code in order to avoid conflict with
the notifier from Freescale driver.
iommu_add_device() and iommu_del_device() are public now.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v8:
* added the check for iommu_group!=NULL before removing device from a group
as suggested by Wei Yang weiy...@linux.vnet.ibm.com
v2:
* added a helper - set_iommu_table_base_and_group - which does
set_iommu_table_base() and iommu_add_device()
---
arch/powerpc/include/asm/iommu.h| 9 +++
arch/powerpc/kernel/iommu.c | 41 +++--
arch/powerpc/platforms/powernv/pci-ioda.c | 8 +++---
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 2 +-
arch/powerpc/platforms/powernv/pci.c| 33 ++-
arch/powerpc/platforms/pseries/iommu.c | 8 +++---
6 files changed, 55 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index c34656a..19ad77f 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -103,6 +103,15 @@ extern struct iommu_table *iommu_init_table(struct
iommu_table * tbl,
int nid);
extern void iommu_register_group(struct iommu_table *tbl,
int pci_domain_number, unsigned long pe_num);
+extern int iommu_add_device(struct device *dev);
+extern void iommu_del_device(struct device *dev);
+
+static inline void set_iommu_table_base_and_group(struct device *dev,
+ void *base)
+{
+ set_iommu_table_base(dev, base);
+ iommu_add_device(dev);
+}
extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
struct scatterlist *sglist, int nelems,
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index b20ff17..15f8ca8 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1105,7 +1105,7 @@ void iommu_release_ownership(struct iommu_table *tbl)
}
EXPORT_SYMBOL_GPL(iommu_release_ownership);
-static int iommu_add_device(struct device *dev)
+int iommu_add_device(struct device *dev)
{
struct iommu_table *tbl;
int ret = 0;
@@ -1134,46 +1134,13 @@ static int iommu_add_device(struct device *dev)
return ret;
}
+EXPORT_SYMBOL_GPL(iommu_add_device);
-static void iommu_del_device(struct device *dev)
+void iommu_del_device(struct device *dev)
{
iommu_group_remove_device(dev);
}
-
-static int iommu_bus_notifier(struct notifier_block *nb,
- unsigned long action, void *data)
-{
- struct device *dev = data;
-
- switch (action) {
- case BUS_NOTIFY_ADD_DEVICE:
- return iommu_add_device(dev);
- case BUS_NOTIFY_DEL_DEVICE:
- iommu_del_device(dev);
- return 0;
- default:
- return 0;
- }
-}
-
-static struct notifier_block tce_iommu_bus_nb = {
- .notifier_call = iommu_bus_notifier,
-};
-
-static int __init tce_iommu_init(void)
-{
- struct pci_dev *pdev = NULL;
-
- BUILD_BUG_ON(PAGE_SIZE IOMMU_PAGE_SIZE);
-
- for_each_pci_dev(pdev)
- iommu_add_device(pdev-dev);
-
- bus_register_notifier(pci_bus_type, tce_iommu_bus_nb);
- return 0;
-}
-
-subsys_initcall_sync(tce_iommu_init);
+EXPORT_SYMBOL_GPL(iommu_del_device);
#else
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index d8140b1..756bb58 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -440,7 +440,7 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb,
struct pci_dev *pdev
return;
pe = phb-ioda.pe_array[pdn-pe_number];
- set_iommu_table_base(pdev-dev, pe-tce32_table);
+ set_iommu_table_base_and_group(pdev-dev, pe-tce32_table);
}
static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
@@ -448,7 +448,7 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe,
struct pci_bus *bus)
struct pci_dev *dev;
list_for_each_entry(dev,
[PATCH v9 02/13] hashtable: add hash_for_each_possible_rcu_notrace()
This adds hash_for_each_possible_rcu_notrace() which is basically a notrace clone of hash_for_each_possible_rcu() which cannot be used in real mode due to its tracing/debugging capability. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru --- Changes: v8: * fixed warnings from check_patch.pl --- include/linux/hashtable.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/include/linux/hashtable.h b/include/linux/hashtable.h index a9df51f..519b6e2 100644 --- a/include/linux/hashtable.h +++ b/include/linux/hashtable.h @@ -174,6 +174,21 @@ static inline void hash_del_rcu(struct hlist_node *node) member) /** + * hash_for_each_possible_rcu_notrace - iterate over all possible objects hashing + * to the same bucket in an rcu enabled hashtable in a rcu enabled hashtable + * @name: hashtable to iterate + * @obj: the type * to use as a loop cursor for each entry + * @member: the name of the hlist_node within the struct + * @key: the key of the objects to iterate over + * + * This is the same as hash_for_each_possible_rcu() except that it does + * not do any RCU debugging or tracing. + */ +#define hash_for_each_possible_rcu_notrace(name, obj, member, key) \ + hlist_for_each_entry_rcu_notrace(obj, \ + name[hash_min(key, HASH_BITS(name))], member) + +/** * hash_for_each_possible_safe - iterate over all possible objects hashing to the * same bucket safe against removals * @name: hashtable to iterate -- 1.8.4.rc4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v9 03/13] KVM: PPC: reserve a capability number for multitce support
This is to reserve a capablity number for upcoming support
of H_PUT_TCE_INDIRECT and H_STUFF_TCE pseries hypercalls
which support mulptiple DMA map/unmap operations per one call.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
2013/07/16:
* changed the number
---
include/uapi/linux/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index acccd08..99c2533 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -667,6 +667,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_PPC_RTAS 91
#define KVM_CAP_IRQ_XICS 92
#define KVM_CAP_ARM_EL1_32BIT 93
+#define KVM_CAP_SPAPR_MULTITCE 94
#ifdef KVM_CAP_IRQ_ROUTING
--
1.8.4.rc4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v9 04/13] KVM: PPC: reserve a capability and KVM device type for realmode VFIO
This reserves a capability number for upcoming support
of VFIO-IOMMU DMA operations in real mode.
This reserves a number for a new SPAPR TCE IOMMU KVM device
which is going to manage lifetime of SPAPR TCE IOMMU object.
This defines an attribute of the SPAPR TCE IOMMU KVM device
which is going to be used for initialization.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v9:
* KVM ioctl is replaced with SPAPR TCE IOMMU KVM device type with
KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE attribute
2013/08/15:
* fixed mistype in comments
* fixed commit message which says what uses ioctls 0xad and 0xae
2013/07/16:
* changed the number
2013/07/11:
* changed order in a file, added comment about a gap in ioctl number
---
arch/powerpc/include/uapi/asm/kvm.h | 8
include/uapi/linux/kvm.h| 2 ++
2 files changed, 10 insertions(+)
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
index 0fb1a6e..c1ae1e5 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -511,4 +511,12 @@ struct kvm_get_htab_header {
#define KVM_XICS_MASKED (1ULL 41)
#define KVM_XICS_PENDING (1ULL 42)
+/* SPAPR TCE IOMMU device specification */
+struct kvm_create_spapr_tce_iommu_linkage {
+ __u64 liobn;
+ __u32 fd;
+ __u32 flags;
+};
+#define KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE 0
+
#endif /* __LINUX_KVM_POWERPC_H */
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 99c2533..9d20630 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -668,6 +668,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_IRQ_XICS 92
#define KVM_CAP_ARM_EL1_32BIT 93
#define KVM_CAP_SPAPR_MULTITCE 94
+#define KVM_CAP_SPAPR_TCE_IOMMU 95
#ifdef KVM_CAP_IRQ_ROUTING
@@ -843,6 +844,7 @@ struct kvm_device_attr {
#define KVM_DEV_TYPE_FSL_MPIC_20 1
#define KVM_DEV_TYPE_FSL_MPIC_42 2
#define KVM_DEV_TYPE_XICS 3
+#define KVM_DEV_TYPE_SPAPR_TCE_IOMMU 4
/*
* ioctls for VM fds
--
1.8.4.rc4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v9 05/13] powerpc: Prepare to support kernel handling of IOMMU map/unmap
The current VFIO-on-POWER implementation supports only user mode
driven mapping, i.e. QEMU is sending requests to map/unmap pages.
However this approach is really slow, so we want to move that to KVM.
Since H_PUT_TCE can be extremely performance sensitive (especially with
network adapters where each packet needs to be mapped/unmapped) we chose
to implement that as a fast hypercall directly in real
mode (processor still in the guest context but MMU off).
To be able to do that, we need to provide some facilities to
access the struct page count within that real mode environment as things
like the sparsemem vmemmap mappings aren't accessible.
This adds an API function realmode_pfn_to_page() to get page struct when
MMU is off.
This adds to MM a new function put_page_unless_one() which drops a page
if counter is bigger than 1. It is going to be used when MMU is off
(for example, real mode on PPC64) and we want to make sure that page
release will not happen in real mode as it may crash the kernel in
a horrible way.
CONFIG_SPARSEMEM_VMEMMAP and CONFIG_FLATMEM are supported.
Cc: linux...@kvack.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Andrew Morton a...@linux-foundation.org
Reviewed-by: Paul Mackerras pau...@samba.org
Signed-off-by: Paul Mackerras pau...@samba.org
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
2013/07/25 (v7):
* removed realmode_put_page and added put_page_unless_one() instead.
The name has been chosen to conform the already existing
get_page_unless_zero().
* removed realmode_get_page. Instead, get_page_unless_zero() should be used
2013/07/10:
* adjusted comment (removed sentence about virtual mode)
* get_page_unless_zero replaced with atomic_inc_not_zero to minimize
effect of a possible get_page_unless_zero() rework (if it ever happens).
2013/06/27:
* realmode_get_page() fixed to use get_page_unless_zero(). If failed,
the call will be passed from real to virtual mode and safely handled.
* added comment to PageCompound() in include/linux/page-flags.h.
2013/05/20:
* PageTail() is replaced by PageCompound() in order to have the same checks
for whether the page is huge in realmode_get_page() and realmode_put_page()
---
arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++
arch/powerpc/mm/init_64.c| 50 +++-
include/linux/mm.h | 14 +
include/linux/page-flags.h | 4 ++-
4 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index 46db094..4a191c4 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -394,6 +394,8 @@ static inline void mark_hpte_slot_valid(unsigned char
*hpte_slot_array,
hpte_slot_array[index] = hidx 4 | 0x1 3;
}
+struct page *realmode_pfn_to_page(unsigned long pfn);
+
static inline char *get_hpte_slot_array(pmd_t *pmdp)
{
/*
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index d0cd9e4..8cf345a 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -300,5 +300,53 @@ void vmemmap_free(unsigned long start, unsigned long end)
{
}
-#endif /* CONFIG_SPARSEMEM_VMEMMAP */
+/*
+ * We do not have access to the sparsemem vmemmap, so we fallback to
+ * walking the list of sparsemem blocks which we already maintain for
+ * the sake of crashdump. In the long run, we might want to maintain
+ * a tree if performance of that linear walk becomes a problem.
+ *
+ * realmode_pfn_to_page functions can fail due to:
+ * 1) As real sparsemem blocks do not lay in RAM continously (they
+ * are in virtual address space which is not available in the real mode),
+ * the requested page struct can be split between blocks so get_page/put_page
+ * may fail.
+ * 2) When huge pages are used, the get_page/put_page API will fail
+ * in real mode as the linked addresses in the page struct are virtual
+ * too.
+ */
+struct page *realmode_pfn_to_page(unsigned long pfn)
+{
+ struct vmemmap_backing *vmem_back;
+ struct page *page;
+ unsigned long page_size = 1 mmu_psize_defs[mmu_vmemmap_psize].shift;
+ unsigned long pg_va = (unsigned long) pfn_to_page(pfn);
+ for (vmem_back = vmemmap_list; vmem_back; vmem_back = vmem_back-list) {
+ if (pg_va vmem_back-virt_addr)
+ continue;
+
+ /* Check that page struct is not split between real pages */
+ if ((pg_va + sizeof(struct page))
+ (vmem_back-virt_addr + page_size))
+ return NULL;
+
+ page = (struct page *) (vmem_back-phys + pg_va -
+ vmem_back-virt_addr);
+ return page;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(realmode_pfn_to_page);
+
+#elif defined(CONFIG_FLATMEM)
+
+struct page *realmode_pfn_to_page(unsigned long pfn)
+{
+
[PATCH v9 06/13] powerpc: add real mode support for dma operations on powernv
The existing TCE machine calls (tce_build and tce_free) only support
virtual mode as they call __raw_writeq for TCE invalidation what
fails in real mode.
This introduces tce_build_rm and tce_free_rm real mode versions
which do mostly the same but use Store Doubleword Caching Inhibited
Indexed instruction for TCE invalidation.
This new feature is going to be utilized by real mode support of VFIO.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v8:
* fixed check_patch.pl warnings
2013/11/07:
* added comment why stdcix cannot be used in virtual mode
2013/08/07:
* tested on p7ioc and fixed a bug with realmode addresses
---
arch/powerpc/include/asm/machdep.h| 12
arch/powerpc/platforms/powernv/pci-ioda.c | 49 +++
arch/powerpc/platforms/powernv/pci.c | 42 ++
arch/powerpc/platforms/powernv/pci.h | 3 +-
4 files changed, 87 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 8b48090..07dd3b1 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -78,6 +78,18 @@ struct machdep_calls {
long index);
void(*tce_flush)(struct iommu_table *tbl);
+ /* _rm versions are for real mode use only */
+ int (*tce_build_rm)(struct iommu_table *tbl,
+long index,
+long npages,
+unsigned long uaddr,
+enum dma_data_direction direction,
+struct dma_attrs *attrs);
+ void(*tce_free_rm)(struct iommu_table *tbl,
+ long index,
+ long npages);
+ void(*tce_flush_rm)(struct iommu_table *tbl);
+
void __iomem * (*ioremap)(phys_addr_t addr, unsigned long size,
unsigned long flags, void *caller);
void(*iounmap)(volatile void __iomem *token);
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 756bb58..8cba234 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -70,6 +70,16 @@ define_pe_printk_level(pe_err, KERN_ERR);
define_pe_printk_level(pe_warn, KERN_WARNING);
define_pe_printk_level(pe_info, KERN_INFO);
+/*
+ * stdcix is only supposed to be used in hypervisor real mode as per
+ * the architecture spec
+ */
+static inline void __raw_rm_writeq(u64 val, volatile void __iomem *paddr)
+{
+ __asm__ __volatile__(stdcix %0,0,%1
+ : : r (val), r (paddr) : memory);
+}
+
static int pnv_ioda_alloc_pe(struct pnv_phb *phb)
{
unsigned long pe;
@@ -454,10 +464,13 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe
*pe, struct pci_bus *bus)
}
}
-static void pnv_pci_ioda1_tce_invalidate(struct iommu_table *tbl,
-u64 *startp, u64 *endp)
+static void pnv_pci_ioda1_tce_invalidate(struct pnv_ioda_pe *pe,
+struct iommu_table *tbl,
+u64 *startp, u64 *endp, bool rm)
{
- u64 __iomem *invalidate = (u64 __iomem *)tbl-it_index;
+ u64 __iomem *invalidate = rm ?
+ (u64 __iomem *)pe-tce_inval_reg_phys :
+ (u64 __iomem *)tbl-it_index;
unsigned long start, end, inc;
start = __pa(startp);
@@ -484,7 +497,10 @@ static void pnv_pci_ioda1_tce_invalidate(struct
iommu_table *tbl,
mb(); /* Ensure above stores are visible */
while (start = end) {
-__raw_writeq(start, invalidate);
+ if (rm)
+ __raw_rm_writeq(start, invalidate);
+ else
+ __raw_writeq(start, invalidate);
start += inc;
}
@@ -496,10 +512,12 @@ static void pnv_pci_ioda1_tce_invalidate(struct
iommu_table *tbl,
static void pnv_pci_ioda2_tce_invalidate(struct pnv_ioda_pe *pe,
struct iommu_table *tbl,
-u64 *startp, u64 *endp)
+u64 *startp, u64 *endp, bool rm)
{
unsigned long start, end, inc;
- u64 __iomem *invalidate = (u64 __iomem *)tbl-it_index;
+ u64 __iomem *invalidate = rm ?
+ (u64 __iomem *)pe-tce_inval_reg_phys :
+ (u64 __iomem *)tbl-it_index;
/* We'll invalidate DMA address in PE scope */
start = 0x2ul 60;
@@ -515,22 +533,25 @@ static void pnv_pci_ioda2_tce_invalidate(struct
pnv_ioda_pe *pe,
mb();
while (start = end) {
- __raw_writeq(start, invalidate);
+ if (rm)
+
[PATCH v9 07/13] KVM: PPC: enable IOMMU_API for KVM_BOOK3S_64 permanently
It does not make much sense to have KVM in book3s-64bit and not to have IOMMU bits for PCI pass through support as it costs little and allows VFIO to function on book3s-kvm. Having IOMMU_API always enabled makes it unnecessary to have a lot of #ifdef IOMMU_API in arch/powerpc/kvm/book3s_64_vio*. With those ifdef's we could have only user space emulated devices accelerated (but not VFIO) which do not seem to be very useful. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru --- arch/powerpc/kvm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index c55c538..3b2b761 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -59,6 +59,7 @@ config KVM_BOOK3S_64 depends on PPC_BOOK3S_64 select KVM_BOOK3S_64_HANDLER select KVM + select SPAPR_TCE_IOMMU ---help--- Support running unmodified book3s_64 and book3s_32 guest kernels in virtual machines on book3s_64 host processors. -- 1.8.4.rc4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v9 08/13] KVM: PPC: Add support for multiple-TCE hcalls
This adds real mode handlers for the H_PUT_TCE_INDIRECT and
H_STUFF_TCE hypercalls for user space emulated devices such as IBMVIO
devices or emulated PCI. These calls allow adding multiple entries
(up to 512) into the TCE table in one call which saves time on
transition to/from real mode.
This adds a tce_tmp cache to kvm_vcpu_arch to save valid TCEs
(copied from user and verified) before writing the whole list into
the TCE table. This cache will be utilized more in the upcoming
VFIO/IOMMU support to continue TCE list processing in the virtual
mode in the case if the real mode handler failed for some reason.
This adds a function to convert a guest physical address to a host
virtual address in order to parse a TCE list from H_PUT_TCE_INDIRECT.
This also implements the KVM_CAP_PPC_MULTITCE capability. When present,
the hypercalls mentioned above may or may not be processed successfully
in the kernel based fast path. If they can not be handled by the kernel,
they will get passed on to user space. So user space still has to have
an implementation for these despite the in kernel acceleration.
Signed-off-by: Paul Mackerras pau...@samba.org
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changelog:
v8:
* fixed warnings from check_patch.pl
2013/08/01 (v7):
* realmode_get_page/realmode_put_page use was replaced with
get_page_unless_zero/put_page_unless_one
2013/07/11:
* addressed many, many comments from maintainers
2013/07/06:
* fixed number of wrong get_page()/put_page() calls
2013/06/27:
* fixed clear of BUSY bit in kvmppc_lookup_pte()
* H_PUT_TCE_INDIRECT does realmode_get_page() now
* KVM_CAP_SPAPR_MULTITCE now depends on CONFIG_PPC_BOOK3S_64
* updated doc
2013/06/05:
* fixed mistype about IBMVIO in the commit message
* updated doc and moved it to another section
* changed capability number
2013/05/21:
* added kvm_vcpu_arch::tce_tmp
* removed cleanup if put_indirect failed, instead we do not even start
writing to TCE table if we cannot get TCEs from the user and they are
invalid
* kvmppc_emulated_h_put_tce is split to kvmppc_emulated_put_tce
and kvmppc_emulated_validate_tce (for the previous item)
* fixed bug with failthrough for H_IPI
* removed all get_user() from real mode handlers
* kvmppc_lookup_pte() added (instead of making lookup_linux_pte public)
---
Documentation/virtual/kvm/api.txt | 26 +++
arch/powerpc/include/asm/kvm_host.h | 9 ++
arch/powerpc/include/asm/kvm_ppc.h | 16 +-
arch/powerpc/kvm/book3s_64_vio.c| 132 +++-
arch/powerpc/kvm/book3s_64_vio_hv.c | 270
arch/powerpc/kvm/book3s_hv.c| 41 -
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 8 +-
arch/powerpc/kvm/book3s_pr_papr.c | 35 +
arch/powerpc/kvm/powerpc.c | 3 +
9 files changed, 506 insertions(+), 34 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index ef925ea..1c8942a 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2382,6 +2382,32 @@ calls by the guest for that service will be passed to
userspace to be
handled.
+4.86 KVM_CAP_PPC_MULTITCE
+
+Capability: KVM_CAP_PPC_MULTITCE
+Architectures: ppc
+Type: vm
+
+This capability means the kernel is capable of handling hypercalls
+H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user
+space. This significantly accelerates DMA operations for PPC KVM guests.
+User space should expect that its handlers for these hypercalls
+are not going to be called if user space previously registered LIOBN
+in KVM (via KVM_CREATE_SPAPR_TCE or similar calls).
+
+In order to enable H_PUT_TCE_INDIRECT and H_STUFF_TCE use in the guest,
+user space might have to advertise it for the guest. For example,
+IBM pSeries (sPAPR) guest starts using them if hcall-multi-tce is
+present in the ibm,hypertas-functions device-tree property.
+
+The hypercalls mentioned above may or may not be processed successfully
+in the kernel based fast path. If they can not be handled by the kernel,
+they will get passed on to user space. So user space still has to have
+an implementation for these despite the in kernel acceleration.
+
+This capability is always enabled.
+
+
5. The kvm_run structure
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index af326cd..a23f132 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -30,6 +30,7 @@
#include linux/kvm_para.h
#include linux/list.h
#include linux/atomic.h
+#include linux/tracepoint.h
#include asm/kvm_asm.h
#include asm/processor.h
#include asm/page.h
@@ -609,6 +610,14 @@ struct kvm_vcpu_arch {
spinlock_t tbacct_lock;
u64 busy_stolen;
u64 busy_preempt;
+
+ unsigned long *tce_tmp_hpas;/* TCE cache for TCE_PUT_INDIRECT */
+ enum {
+ TCERM_NONE,
+ TCERM_GETPAGE,
+
[PATCH v9 09/13] powerpc/iommu: rework to support realmode
The TCE tables handling may differ for real and virtual modes so
additional ppc_md.tce_build_rm/ppc_md.tce_free_rm/ppc_md.tce_flush_rm
handlers were introduced earlier.
So this adds the following:
1. support for the new ppc_md calls;
2. ability to iommu_tce_build to process mupltiple entries per
call;
3. arch_spin_lock to protect TCE table from races in both real and virtual
modes;
4. proper TCE table protection from races with the existing IOMMU code
in iommu_take_ownership/iommu_release_ownership;
5. hwaddr variable renamed to hpa as it better describes what it
actually represents;
6. iommu_tce_direction is static now as it is not called from anywhere else.
This will be used by upcoming real mode support of VFIO on POWER.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v8:
* fixed warnings from check_patch.pl
---
arch/powerpc/include/asm/iommu.h | 9 +-
arch/powerpc/kernel/iommu.c | 198 ++-
2 files changed, 136 insertions(+), 71 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 19ad77f..71ee525 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -78,6 +78,7 @@ struct iommu_table {
unsigned long *it_map; /* A simple allocation bitmap for now */
#ifdef CONFIG_IOMMU_API
struct iommu_group *it_group;
+ arch_spinlock_t it_rm_lock;
#endif
};
@@ -161,9 +162,9 @@ extern int iommu_tce_clear_param_check(struct iommu_table
*tbl,
extern int iommu_tce_put_param_check(struct iommu_table *tbl,
unsigned long ioba, unsigned long tce);
extern int iommu_tce_build(struct iommu_table *tbl, unsigned long entry,
- unsigned long hwaddr, enum dma_data_direction direction);
-extern unsigned long iommu_clear_tce(struct iommu_table *tbl,
- unsigned long entry);
+ unsigned long *hpas, unsigned long npages, bool rm);
+extern int iommu_free_tces(struct iommu_table *tbl, unsigned long entry,
+ unsigned long npages, bool rm);
extern int iommu_clear_tces_and_put_pages(struct iommu_table *tbl,
unsigned long entry, unsigned long pages);
extern int iommu_put_tce_user_mode(struct iommu_table *tbl,
@@ -173,7 +174,5 @@ extern void iommu_flush_tce(struct iommu_table *tbl);
extern int iommu_take_ownership(struct iommu_table *tbl);
extern void iommu_release_ownership(struct iommu_table *tbl);
-extern enum dma_data_direction iommu_tce_direction(unsigned long tce);
-
#endif /* __KERNEL__ */
#endif /* _ASM_IOMMU_H */
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 15f8ca8..ff0cd90 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -903,7 +903,7 @@ void iommu_register_group(struct iommu_table *tbl,
kfree(name);
}
-enum dma_data_direction iommu_tce_direction(unsigned long tce)
+static enum dma_data_direction iommu_tce_direction(unsigned long tce)
{
if ((tce TCE_PCI_READ) (tce TCE_PCI_WRITE))
return DMA_BIDIRECTIONAL;
@@ -914,7 +914,6 @@ enum dma_data_direction iommu_tce_direction(unsigned long
tce)
else
return DMA_NONE;
}
-EXPORT_SYMBOL_GPL(iommu_tce_direction);
void iommu_flush_tce(struct iommu_table *tbl)
{
@@ -972,73 +971,117 @@ int iommu_tce_put_param_check(struct iommu_table *tbl,
}
EXPORT_SYMBOL_GPL(iommu_tce_put_param_check);
-unsigned long iommu_clear_tce(struct iommu_table *tbl, unsigned long entry)
-{
- unsigned long oldtce;
- struct iommu_pool *pool = get_pool(tbl, entry);
-
- spin_lock((pool-lock));
-
- oldtce = ppc_md.tce_get(tbl, entry);
- if (oldtce (TCE_PCI_WRITE | TCE_PCI_READ))
- ppc_md.tce_free(tbl, entry, 1);
- else
- oldtce = 0;
-
- spin_unlock((pool-lock));
-
- return oldtce;
-}
-EXPORT_SYMBOL_GPL(iommu_clear_tce);
-
int iommu_clear_tces_and_put_pages(struct iommu_table *tbl,
unsigned long entry, unsigned long pages)
{
- unsigned long oldtce;
- struct page *page;
-
- for ( ; pages; --pages, ++entry) {
- oldtce = iommu_clear_tce(tbl, entry);
- if (!oldtce)
- continue;
-
- page = pfn_to_page(oldtce PAGE_SHIFT);
- WARN_ON(!page);
- if (page) {
- if (oldtce TCE_PCI_WRITE)
- SetPageDirty(page);
- put_page(page);
- }
- }
-
- return 0;
+ return iommu_free_tces(tbl, entry, pages, false);
}
EXPORT_SYMBOL_GPL(iommu_clear_tces_and_put_pages);
-/*
- * hwaddr is a kernel virtual address here (0xc... bazillion),
- * tce_build converts it to a physical address.
- */
+int iommu_free_tces(struct iommu_table *tbl, unsigned long entry,
+ unsigned long npages, bool rm)
+{
+ int i, ret = 0, to_free = 0;
+
+
[PATCH v9 10/13] KVM: PPC: remove warning from kvmppc_core_destroy_vm
Book3S KVM implements in-kernel TCE tables via kvmppc_spapr_tce_table structs list (created per KVM). Entries in the list are per LIOBN (logical bus number) and have a TCE table so DMA hypercalls (such as H_PUT_TCE) can convert LIOBN to a TCE table. The entry in the list is created via KVM_CREATE_SPAPR_TCE ioctl which returns an anonymous fd. This fd is used to map the TCE table to the user space and it also defines the lifetime of the TCE table in the kernel. Every list item also hold the link to KVM so when KVM is about to be destroyed, all kvmppc_spapr_tce_table objects are expected to be released and removed from the global list. And this is what the warning verifies. The upcoming support of VFIO IOMMU will extend kvmppc_spapr_tce_table use. Unlike emulated devices, it will create kvmppc_spapr_tce_table structs via new KVM device API which opens an anonymous fd (as KVM_CREATE_SPAPR_TCE) but the release callback does not call KVM Device's destroy callback immediately. Instead, KVM devices destruction is postponed this till KVM destruction but this happens after arch-specific KVM destroy function so the warning does a false alarm. This removes the warning as it never happens in real life and there is no any obvious place to put it. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru --- arch/powerpc/kvm/book3s_hv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index 9e823ad..5f15ff7 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -1974,7 +1974,6 @@ void kvmppc_core_destroy_vm(struct kvm *kvm) kvmppc_rtas_tokens_free(kvm); kvmppc_free_hpt(kvm); - WARN_ON(!list_empty(kvm-arch.spapr_tce_tables)); } /* These are stubs for now */ -- 1.8.4.rc4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v9 11/13] KVM: PPC: add trampolines for VFIO external API
KVM is going to use VFIO's external API. However KVM can operate even VFIO
is not compiled or loaded so KVM is linked to VFIO dynamically.
This adds proxy functions for VFIO external API.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/kvm/book3s_64_vio.c | 49
1 file changed, 49 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index cae1099..047b94c 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -27,6 +27,8 @@
#include linux/hugetlb.h
#include linux/list.h
#include linux/anon_inodes.h
+#include linux/module.h
+#include linux/vfio.h
#include asm/tlbflush.h
#include asm/kvm_ppc.h
@@ -42,6 +44,53 @@
#define ERROR_ADDR ((void *)~(unsigned long)0x0)
+/*
+ * Dynamically linked version of the external user VFIO API.
+ *
+ * As a IOMMU group access control is implemented by VFIO,
+ * there is some API to vefiry that specific process can own
+ * a group. As KVM may run when VFIO is not loaded, KVM is not
+ * linked statically to VFIO, instead wrappers are used.
+ */
+struct vfio_group *kvmppc_vfio_group_get_external_user(struct file *filep)
+{
+ struct vfio_group *ret;
+ struct vfio_group * (*proc)(struct file *) =
+ symbol_get(vfio_group_get_external_user);
+ if (!proc)
+ return NULL;
+
+ ret = proc(filep);
+ symbol_put(vfio_group_get_external_user);
+
+ return ret;
+}
+
+void kvmppc_vfio_group_put_external_user(struct vfio_group *group)
+{
+ void (*proc)(struct vfio_group *) =
+ symbol_get(vfio_group_put_external_user);
+ if (!proc)
+ return;
+
+ proc(group);
+ symbol_put(vfio_group_put_external_user);
+}
+
+int kvmppc_vfio_external_user_iommu_id(struct vfio_group *group)
+{
+ int ret;
+ int (*proc)(struct vfio_group *) =
+ symbol_get(vfio_external_user_iommu_id);
+ if (!proc)
+ return -EINVAL;
+
+ ret = proc(group);
+ symbol_put(vfio_external_user_iommu_id);
+
+ return ret;
+}
+
static long kvmppc_stt_npages(unsigned long window_size)
{
return ALIGN((window_size SPAPR_TCE_SHIFT)
--
1.8.4.rc4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
them to user space which saves time on switching to user space and back.
Both real and virtual modes are supported. The kernel tries to
handle a TCE request in the real mode, if fails it passes the request
to the virtual mode to complete the operation. If it a virtual mode
handler fails, the request is passed to user space.
The first user of this is VFIO on POWER. Trampolines to the VFIO external
user API functions are required for this patch.
This adds a SPAPR TCE IOMMU KVM device to associate a logical bus
number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel handling
of map/unmap requests. The device supports a single attribute which is
a struct with LIOBN and IOMMU fd. When the attribute is set, the device
establishes the connection between KVM and VFIO.
Tests show that this patch increases transmission speed from 220MB/s
to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
Signed-off-by: Paul Mackerras pau...@samba.org
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v9:
* KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with SPAPR TCE IOMMU
KVM device
* release_spapr_tce_table() is not shared between different TCE types
* reduced the patch size by moving VFIO external API
trampolines to separate patche
* moved documentation from Documentation/virtual/kvm/api.txt to
Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
v8:
* fixed warnings from check_patch.pl
2013/07/11:
* removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
for KVM_BOOK3S_64
* kvmppc_gpa_to_hva_and_get also returns host phys address. Not much sense
for this here but the next patch for hugepages support will use it more.
2013/07/06:
* added realmode arch_spin_lock to protect TCE table from races
in real and virtual modes
* POWERPC IOMMU API is changed to support real mode
* iommu_take_ownership and iommu_release_ownership are protected by
iommu_table's locks
* VFIO external user API use rewritten
* multiple small fixes
2013/06/27:
* tce_list page is referenced now in order to protect it from accident
invalidation during H_PUT_TCE_INDIRECT execution
* added use of the external user VFIO API
2013/06/05:
* changed capability number
* changed ioctl number
* update the doc article number
2013/05/20:
* removed get_user() from real mode handlers
* kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
translated TCEs, tries realmode_get_page() on those and if it fails, it
passes control over the virtual mode handler which tries to finish
the request handling
* kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
on a page
* The only reason to pass the request to user mode now is when the user mode
did not register TCE table in the kernel, in all other cases the virtual mode
handler is expected to do the job
---
.../virtual/kvm/devices/spapr_tce_iommu.txt| 37 +++
arch/powerpc/include/asm/kvm_host.h| 4 +
arch/powerpc/kvm/book3s_64_vio.c | 310 -
arch/powerpc/kvm/book3s_64_vio_hv.c| 122
arch/powerpc/kvm/powerpc.c | 1 +
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c| 5 +
7 files changed, 477 insertions(+), 3 deletions(-)
create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
new file mode 100644
index 000..4bc8fc3
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
@@ -0,0 +1,37 @@
+SPAPR TCE IOMMU device
+
+Capability: KVM_CAP_SPAPR_TCE_IOMMU
+Architectures: powerpc
+
+Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
+
+Groups:
+ KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
+ Attributes: single attribute with pair { LIOBN, IOMMU fd}
+
+This is completely made up device which provides API to link
+logical bus number (LIOBN) and IOMMU group. The user space has
+to create a new SPAPR TCE IOMMU device per a logical bus.
+
+LIOBN is a PCI bus identifier from PPC64-server (sPAPR) DMA hypercalls
+(H_PUT_TCE, H_PUT_TCE_INDIRECT, H_STUFF_TCE).
+IOMMU group is a minimal isolated device set which can be passed to
+the user space via VFIO.
+
+Right after creation the device is in uninitlized state and requires
+a KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE attribute to be set.
+The attribute contains liobn, IOMMU fd and flags:
+
+struct kvm_create_spapr_tce_iommu_linkage {
+ __u64 liobn;
+ __u32 fd;
+ __u32 flags;
+};
+
+The user space creates the SPAPR TCE IOMMU device, obtains
+an IOMMU fd via VFIO ABI and sets the attribute to the SPAPR TCE IOMMU
+device. At the moment of setting the attribute, the SPAPR TCE IOMMU
+device links LIOBN to IOMMU group and makes
[PATCH v9 13/13] KVM: PPC: Add hugepage support for IOMMU in-kernel handling
This adds special support for huge pages (16MB) in real mode.
The reference counting cannot be easily done for such pages in real
mode (when MMU is off) so we added a hash table of huge pages.
It is populated in virtual mode and get_page is called just once
per a huge page. Real mode handlers check if the requested page is
in the hash table, then no reference counting is done, otherwise
an exit to virtual mode happens. The hash table is released at KVM
exit.
At the moment the fastest card available for tests uses up to 9 huge
pages so walking through this hash table does not cost much.
However this can change and we may want to optimize this.
Signed-off-by: Paul Mackerras pau...@samba.org
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
2013/07/12:
* removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
for KVM_BOOK3S_64
2013/06/27:
* list of huge pages replaces with hashtable for better performance
* spinlock removed from real mode and only protects insertion of new
huge [ages descriptors into the hashtable
2013/06/05:
* fixed compile error when CONFIG_IOMMU_API=n
2013/05/20:
* the real mode handler now searches for a huge page by gpa (used to be pte)
* the virtual mode handler prints warning if it is called twice for the same
huge page as the real mode handler is expected to fail just once - when a huge
page is not in the list yet.
* the huge page is refcounted twice - when added to the hugepage list and
when used in the virtual mode hcall handler (can be optimized but it will
make the patch less nice).
---
arch/powerpc/include/asm/kvm_host.h | 25
arch/powerpc/kernel/iommu.c | 6 +-
arch/powerpc/kvm/book3s_64_vio.c| 122 ++--
arch/powerpc/kvm/book3s_64_vio_hv.c | 32 +-
4 files changed, 176 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index c1a039d..b970d26 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -31,6 +31,7 @@
#include linux/list.h
#include linux/atomic.h
#include linux/tracepoint.h
+#include linux/hashtable.h
#include asm/kvm_asm.h
#include asm/processor.h
#include asm/page.h
@@ -184,9 +185,33 @@ struct kvmppc_spapr_tce_table {
struct iommu_group *grp;/* used for IOMMU groups */
struct kvm_create_spapr_tce_iommu_linkage link;
struct vfio_group *vfio_grp;/* used for IOMMU groups */
+ DECLARE_HASHTABLE(hash_tab, ilog2(64)); /* used for IOMMU groups */
+ spinlock_t hugepages_write_lock;/* used for IOMMU groups */
struct page *pages[0];
};
+/*
+ * The KVM guest can be backed with 16MB pages.
+ * In this case, we cannot do page counting from the real mode
+ * as the compound pages are used - they are linked in a list
+ * with pointers as virtual addresses which are inaccessible
+ * in real mode.
+ *
+ * The code below keeps a 16MB pages list and uses page struct
+ * in real mode if it is already locked in RAM and inserted into
+ * the list or switches to the virtual mode where it can be
+ * handled in a usual manner.
+ */
+#define KVMPPC_SPAPR_HUGEPAGE_HASH(gpa)hash_32(gpa 24, 32)
+
+struct kvmppc_spapr_iommu_hugepage {
+ struct hlist_node hash_node;
+ unsigned long gpa; /* Guest physical address */
+ unsigned long hpa; /* Host physical address */
+ struct page *page; /* page struct of the very first subpage */
+ unsigned long size; /* Huge page size (always 16MB at the moment) */
+};
+
struct kvmppc_linear_info {
void*base_virt;
unsigned longbase_pfn;
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index ff0cd90..d0593c9 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -999,7 +999,8 @@ int iommu_free_tces(struct iommu_table *tbl, unsigned long
entry,
if (!pg) {
ret = -EAGAIN;
} else if (PageCompound(pg)) {
- ret = -EAGAIN;
+ /* Hugepages will be released at KVM exit */
+ ret = 0;
} else {
if (oldtce TCE_PCI_WRITE)
SetPageDirty(pg);
@@ -1010,6 +1011,9 @@ int iommu_free_tces(struct iommu_table *tbl, unsigned
long entry,
struct page *pg = pfn_to_page(oldtce PAGE_SHIFT);
if (!pg) {
ret = -EAGAIN;
+ } else if (PageCompound(pg)) {
+ /* Hugepages will be released at KVM exit */
+ ret = 0;
} else {
if (oldtce TCE_PCI_WRITE)
SetPageDirty(pg);
[PATCH][RFC][v2] pci: fsl: rework PCIe driver compatible with Layerscape
The Freescale's Layerscape series processors will use ARM cores.
The LS1's PCIe controllers is the same as T4240's. So it's better
the PCIe controller driver can support PowerPC and ARM
simultaneously. This patch is for this purpose. It derives
the common functions from arch/powerpc/sysdev/fsl_pci.c to
drivers/pci/host/pcie-fsl.c and leaves several platform-dependent
functions which should be implemented in platform files.
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
---
Based on upstream master 3.11-rc7
The function has been tested on MPC8315ERDB MPC8572DS P5020DS P3041DS
and T4240QDS boards
Change log:
v2:
1. Use 'pci' instead of 'pcie' in new file name and file contents.
2. Use iowrite32be()/iowrite32() instead of out_be32/le32()
3. Fix ppc_md.dma_set_mask setting
4. Synchronizes host-first_busno and pci-first_busno.
5. Fix PCI IO space settings
6. Some small changes according to Scott's comments.
arch/powerpc/Kconfig | 1 +
arch/powerpc/sysdev/fsl_pci.c | 610 -
arch/powerpc/sysdev/fsl_pci.h | 91 ---
drivers/edac/mpc85xx_edac.c| 10 -
drivers/pci/host/Kconfig | 4 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-fsl.c | 736 +
.../sysdev/fsl_pci.h = include/linux/fsl/pci.h| 107 ++-
8 files changed, 932 insertions(+), 628 deletions(-)
create mode 100644 drivers/pci/host/pci-fsl.c
copy arch/powerpc/sysdev/fsl_pci.h = include/linux/fsl/pci.h (67%)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9cf59816d..f78484c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -671,6 +671,7 @@ config FSL_SOC
config FSL_PCI
bool
+ select PCI_FSL if FSL_SOC_BOOKE || PPC_86xx
select PPC_INDIRECT_PCI
select PCI_QUIRKS
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..b3ff28b 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -1,7 +1,7 @@
/*
* MPC83xx/85xx/86xx PCI/PCIE support routing.
*
- * Copyright 2007-2012 Freescale Semiconductor, Inc.
+ * Copyright 2007-2013 Freescale Semiconductor, Inc.
* Copyright 2008-2009 MontaVista Software, Inc.
*
* Initial author: Xianghua Xiao x.x...@freescale.com
@@ -26,6 +26,7 @@
#include linux/memblock.h
#include linux/log2.h
#include linux/slab.h
+#include linux/fsl/pci.h
#include asm/io.h
#include asm/prom.h
@@ -54,60 +55,17 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
return;
}
-static int fsl_indirect_read_config(struct pci_bus *, unsigned int,
- int, int, u32 *);
-
-static int fsl_pcie_check_link(struct pci_controller *hose)
-{
- u32 val = 0;
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
quirk_fsl_pcie_header);
- if (hose-indirect_type PPC_INDIRECT_TYPE_FSL_CFG_REG_LINK) {
- if (hose-ops-read == fsl_indirect_read_config) {
- struct pci_bus bus;
- bus.number = 0;
- bus.sysdata = hose;
- bus.ops = hose-ops;
- indirect_read_config(bus, 0, PCIE_LTSSM, 4, val);
- } else
- early_read_config_dword(hose, 0, 0, PCIE_LTSSM, val);
- if (val PCIE_LTSSM_L0)
- return 1;
- } else {
- struct ccsr_pci __iomem *pci = hose-private_data;
- /* for PCIe IP rev 3.0 or greater use CSR0 for link state */
- val = (in_be32(pci-pex_csr0) PEX_CSR0_LTSSM_MASK)
-PEX_CSR0_LTSSM_SHIFT;
- if (val != PEX_CSR0_LTSSM_L0)
- return 1;
- }
+#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
- return 0;
-}
+#define MAX_PHYS_ADDR_BITS 40
-static int fsl_indirect_read_config(struct pci_bus *bus, unsigned int devfn,
- int offset, int len, u32 *val)
+u64 fsl_pci64_dma_offset(void)
{
- struct pci_controller *hose = pci_bus_to_host(bus);
-
- if (fsl_pcie_check_link(hose))
- hose-indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
- else
- hose-indirect_type = ~PPC_INDIRECT_TYPE_NO_PCIE_LINK;
-
- return indirect_read_config(bus, devfn, offset, len, val);
+ return 1ull MAX_PHYS_ADDR_BITS;
}
-#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
-
-static struct pci_ops fsl_indirect_pcie_ops =
-{
- .read = fsl_indirect_read_config,
- .write = indirect_write_config,
-};
-
-#define MAX_PHYS_ADDR_BITS 40
-static u64 pci64_dma_offset = 1ull MAX_PHYS_ADDR_BITS;
-
static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
{
if (!dev-dma_mask || !dma_supported(dev, dma_mask))
@@
Re: [PATCH v4 09/31] powerpc/fsl-pci: improve clock API use
[ re-created the Cc: list, this is about the PCI clock exclusively ] Of all the preparation patches in the series (parts 01-14/31, forming the peripheral driver cleanup phase before the introduction of CCF support), this patch remains the last to get picked up. But I'd suggest to leave this patch for now (for v3.12, it's rather late). Either ignore this message and the patch, or see below for why application isn't required now, and an update of this patch is needed and will be appropriate for v3.13. I'm sorry for the confusion, the potentially perceived instability is a result of both widening the series' scope after initial submission as well as a recent extension of test coverage after the scope has been widened. Thank you for your patience! On Tue, Aug 06, 2013 at 22:43 +0200, Gerhard Sittig wrote: make the Freescale PCI driver get, prepare and enable the PCI clock during probe(); the clock gets put upon device close by the devm approach clock lookup is non-fatal as not all platforms may provide clock specs in their device tree, but failure to enable specified clocks are fatal the driver appears to not have a remove() routine, so no reference to the clock is kept during use, and the clock isn't released (the devm approach will put the clock, but it won't get disabled or unprepared) Signed-off-by: Gerhard Sittig g...@denx.de --- arch/powerpc/sysdev/fsl_pci.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c index 46ac1dd..549ff08 100644 --- a/arch/powerpc/sysdev/fsl_pci.c +++ b/arch/powerpc/sysdev/fsl_pci.c @@ -17,6 +17,8 @@ ... What this patch 09/31 does is add a non-fatal device tree based clock lookup in the fsl_pci_probe() routine, to acquire the PCI clock item appropriately if there is a provider and a DT spec. The patch in v4 has a bug, which has an obvious fix while an update wasn't sent yet, for neither the patch nor the series. There is one more known issue in the series (not with functionality but with policy, specifically in a multi platform configuration), while I don't want to resend the series while known issues are pending. But this is not the problem here. First of all the patch is a NOP in the forseeable future. It won't harm yet its content isn't urgently needed either, to unbreak stuff or to support upcoming features that were communicated before. Further analysis has shown that the patch is incomplete. The 85xx and 86xx platforms will pass through the fsl_pci_probe() routine. That these platforms don't have OF clock providers is not a problem, the patch will remain a NOP then. Its function will kick in when these platforms may grow clock providers (things will transparently keep working, this was the actual intent of the patch). Since the series is about 512x CCF support, the patch will remain a NOP throughout the whole series, but won't harm either. The 83xx and 512x platforms in contrast _don't_ pass through the fsl_pci_probe() routine, instead they call mpc83xx_add_bridge() from within the .setup_arch() callback in platform initialization code, which iterates over the compatible OF nodes, and runs at a point in time where the platform's clock provider has not yet been setup and thus is not available. In this situation any clock lookup will fail, which is not fatal during PCI setup yet won't acquire the clock item and thus will have the common infrastructure disable the unused clock much later. There is a workaround for this lack of proper clock acquisition in the peripheral driver. The clock provider needs to pre-enable the PCI clock item upon its initialization, because the peripheral driver can't when it initializes. Checking the same condition in the provider's pre-enable workaround which the .setup_arch() routine is checking before the add_bridge() calls (the presence of compatible nodes) results in correct operation as well as most appropriate resource use (clock enabled when PCI hardware was attached to, and clock disabled in the absence of PCI hardware or driver attachment). So the update of this patch 09/31 will contain - the fix for the copy'n'paste bug in the probe() routine - an appropriate comment in the add_bridge() routine - no change in its nature, the idea remains unaffected The backend (clock provider) will contain the pre-enable workaround for the PCI clock item. As a result, the 83xx, 85xx, and 86xx platforms won't see any change (there is a NOP in probe() and a comment in add_bridge(), neither of which break any operation). The 512x platform will have proper PCI operation in the presence of common clock support. Should 8xxx platforms grow CCF support later, they will transparently keep working (85xx, 86xx), or may add the same simple yet appropriate workaround (83xx). So the outline is there, the approach is straight forward and easily can get implemented, and the resulting code will work for all platforms while
Re: [PATCH v8 1/3] DMA: Freescale: revise device tree binding document
On Wed, Aug 28, 2013 at 09:18:55AM +0100, Hongbo Zhang wrote: On 08/27/2013 07:25 PM, Mark Rutland wrote: On Tue, Aug 27, 2013 at 11:42:01AM +0100, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang hongbo.zh...@freescale.com This patch updates the discription of each type of DMA controller and its channels, it is preparation for adding another new DMA controller binding, it also fixes some defects of indent for text alignment at the same time. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com --- .../devicetree/bindings/powerpc/fsl/dma.txt| 62 +--- 1 file changed, 27 insertions(+), 35 deletions(-) diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt index 2a4b4bc..ddf17af 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt @@ -1,33 +1,29 @@ -* Freescale 83xx DMA Controller +* Freescale DMA Controllers -Freescale PowerPC 83xx have on chip general purpose DMA controllers. +** Freescale Elo DMA Controller + This is a little-endian DMA controller, used in Freescale mpc83xx series + chips such as mpc8315, mpc8349, mpc8379 etc. Required properties: -- compatible: compatible list, contains 2 entries, first is - fsl,CHIP-dma, where CHIP is the processor - (mpc8349, mpc8360, etc.) and the second is - fsl,elo-dma -- reg : registers mapping for DMA general status reg -- ranges : Should be defined as specified in 1) to describe the -DMA controller channels. +- compatible: must include fsl,elo-dma We should list the other values that may be in the list also, unless they are really of no consequence, in which case their presence in dt is questionable. Hmm. Stephen questioned here too, it seems this is a default rule. Although Scott@freescale had explained our thoughts, I'd like to edit this item like this: must include fsl,eloplus-dma, and a fsl,CHIP-dma is optional, where CHIP is the processor name We don't list all the chip name because we have tens of them and we cannot list all of them, and it is unnecessary to list them because we even don't use fsl,CHIP-dma in the new driver, add fsl,CHIP-dma here just make it questionable when it presents in example and old dts files. I remove the examples in bracket (mpc8349, mpc8360, etc.) because we can see the real example below. I don't say if fsl,CHIP-dma presents, it should be the first one, and the fsl,eloplus-dma should be the second because it is common rule. the description language should be clear and concise too I think. Actually, you've convinced me for the form as you originally converted it (must include fsl,elo-dma), given that the other strings aren't used to give information anywhere and fsl,CHIP-dma doesn't fully define a valid string. +- reg : registers specifier for DMA general status reg +- ranges: describes the mapping between the address space of the + DMA channels and the address space of the DMA controller - cell-index: controller index. 0 for controller @ 0x8100 -- interrupts: interrupt mapping for DMA IRQ +- interrupts: interrupt specifier for DMA IRQ - interrupt-parent : optional, if needed for interrupt mapping - - DMA channel nodes: -- compatible: compatible list, contains 2 entries, first is - fsl,CHIP-dma-channel, where CHIP is the processor - (mpc8349, mpc8350, etc.) and the second is - fsl,elo-dma-channel. However, see note below. -- reg : registers mapping for channel +- compatible: must include fsl,elo-dma-channel + However, see note below. Again, I think we should list the other entries that may be in the list. Otherwise it's not clear what the binding defines. Similarly for the other compatible list definitions below... +- reg : registers specifier for channel - cell-index: dma channel index starts at 0. I realise you haven't changed it, but it's unclear what the cell-index property is (and somewhat confusingly there seem to be multiple defnitions). It might be worth clarifying it while performing the other cleanup. not clear with your point multiple definitions, we really have multiple dma channels for one dma controller. cell-index is used as channel index, this is an old method used by old driver, my patch didn't touch this part. Sorry, I'd misunderstood the cell-index property. More noise from me. Given that, this looks fine to me. Acked-by: Mark Rutland mark.rutl...@arm.com Optional properties: --
Re: [PATCH v8 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On Wed, Aug 28, 2013 at 07:54:01AM +0100, Hongbo Zhang wrote:
On 08/27/2013 07:35 PM, Mark Rutland wrote:
On Tue, Aug 27, 2013 at 11:42:02AM +0100, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch
adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 66
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 232 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..10fd031 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,72 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ This is EloPlus controller with 8 channels, used in Freescale Txxx and
Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include fsl,elo3-dma
+- reg : registers specifier for DMA general status reg
+- ranges: describes the mapping between the address space of
the
+ DMA channels and the address space of the DMA
controller
+
+- DMA channel nodes:
+- compatible: must include fsl,eloplus-dma-channel
+- reg : registers specifier for channel
+- interrupts: interrupt specifier for DMA channel IRQ
+- interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elo3-dma;
+ reg = 0x100300 0x4 0x100600 0x4;
Is that one reg entry where #size-cells=2 and #address-cells=2?
That's what the binding implies (given it only describes a single reg
entry).
if it's two entries, we should make that explicit (both in the binding
and example):
reg = 0x100300 0x4,
0x100600 0x4;
Yes they are two entries, I will change it this way.
Ok. Could you make sure you document what the two reg entries correspond
to? That's not clear from registers specifier for channel.
+ ranges = 0x0 0x100100 0x500;
If it is one reg entry then the example ranges property isn't big enough
to contain the parent-bus-address.
They are two reg entries, so the range is big enough.
Ok.
+ dma-channel@0 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x0 0x80;
+ interrupts = 28 2 0 0;
+ };
+ dma-channel@80 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x80 0x80;
+ interrupts = 29 2 0 0;
+ };
+ dma-channel@100 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x100 0x80;
+ interrupts = 30 2 0 0;
+ };
+ dma-channel@180 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x180 0x80;
+ interrupts = 31 2 0 0;
+ };
+ dma-channel@300 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x300 0x80;
+ interrupts = 76 2 0 0;
+ };
+ dma-channel@380 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x380 0x80;
+ interrupts = 77 2 0 0;
+ };
+ dma-channel@400 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x400 0x80;
+ interrupts = 78 2 0 0;
+ };
+ dma-channel@480 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x480 0x80;
+ interrupts = 79 2 0 0;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must
say
fsl,elo-dma-channel or fsl,eloplus-dma-channel to be used by the Elo
DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by
another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = 0xe2000 0x1000;
};
-/include/ qoriq-dma-0.dtsi
Re: [PATCH v4 00/31] add COMMON_CLK support for PowerPC MPC512x
[ summary for the busy or the impatient: this is a status update on the series - peripheral driver cleanup considered appropriate for v3.12 - common clock support introduction isn't ready yet - which in turn holds subsequent parts - while the overall shape of the series is looking good ] On Tue, Aug 06, 2013 at 22:43 +0200, Gerhard Sittig wrote: this series - fixes several drivers that are used in the MPC512x platform (UART, SPI, ethernet, PCI, USB, CAN, NAND flash, video capture) in how they handle clocks (appropriately acquire and setup them, hold references during use, release clocks after use) - introduces support for the common clock framework (CCF, COMMON_CLK Kconfig option) in the PowerPC based MPC512x platform, which brings device tree based clock lookup as well although the series does touch several subsystems -- tty (serial), spi, net (can, fs_enet), mtd (nfc), usb, i2c, media (viu), and dts -- all of the patches are strictly clock related or trivial it appears most appropriate to take this series through either the clk or the powerpc trees after it has passed review and other subsystem maintainers ACKed the clock setup related driver modifications Since the status of this series was questioned recently, I felt that I should officially and publicly provide a status update in the absence of a v5 submission update. The series has undergone some review and has received changes as concerns were raised and feedback was provided. While I consider the nature and frequency of the changes totally appropriate -- each revision addressed all of the issues raised, and did so in an appropriate manner, but could not forsee what else would be raised upon re-submission. Actually not sending another version before _all_ concerns are addressed appropriately is what held back submission of v5. See the phase overview below for details. Adding the cleanup of existing code before the introduction of new features did widen the scope of the series, yet has heavily improved the series, and the feedback was gratefully accepted and thoroughly got addressed. Actually this driver cleanup, which only was introduced after initial submission upon Mark's request, could be considered the most desirable part of the series at this very point in time. And as I write this, the patches of the peripheral driver cleanup phase are being picked up for v3.12 after they have become stable in the review iterations. Further extension of test coverage for the series after submission of v4 has led to minimal fixes in CAN, USB, and PCI, and has revealed one problem in multi platform configurations which currently is the only remaining blocker for phase 2 and subsequent steps. While phase 1 with its obvious cleanup is stable and has become desirable and acceptable and currently is being picked up. The current status of the v4 series in detail is: Phase 1, patches 01-14/31, peripheral driver cleanup and DTS improvement: has addressed all concerns raised, and can be applied via any subtree in any order since the parts are independent from each other, with a few minor additions - USB 03/31 received another adjustment of the clock lookup 'dev' parameter, the applied version works in all three cases of the PPC_CLOCK implementation where clock names are global, the CCF implementation with clkdev registration (during migration), and the CCF implementation with device tree based clock lookup (the end result of the series); the v4 patch wasn't broken but just in need of an addendum before/within phase 3, which now was folded into phase 1 - PCI 09/31 had a compile error on 85xx/86xx due to a copy'n'paste bug in an error path; since the (fixed) patch still remains a NOP for now and within the whole series, I have suggested to leave this patch for v3.12, and to address the remaining issue of the PCI driver patch being incomplete later, see the followup for 09/31 for details (what gets added in a future version is another comment in the PCI driver and a workaround in the clock provider backend, because in the given implementation the peripheral driver cannot appropriately acquire its clock item on some platforms) - CAN 11/31 could save one more instruction by adding another jump label in the error path instead of explicit undo of a setup step, Marc's suggestion was implemented and has been applied So all parts of phase 1 (with the exception of the PCI driver change which is and remains a NOP) were applied, and followup patches for fixup were avoided. Nothing was broken, no breakage was introduced, it's all about improvements. Phase 2, patches 15-18/31, introduction of CCF support for MPC512x: works correctly for MPC512x and doesn't break other platforms, but won't work in multi platform configurations with MPC52xx (PPC_CLOCK and COMMON_CLK will collide in the linker), shall not be considered for v3.12, multi platform needs to get sorted out before
[PATCH] powerpc/mpc8xx: Clearer Oops message for Software Emulation Exception
This patch modifies the Oops message in case of Software Emulation Exception.
The existing message is quite confusing because it refers to FPU Emulation
while most often the issue is due to either a non supported instruction
(not necessarily FPU related) or a stale instruction due to HW issues.
The new message tries to be more generic in order to make the user understand
that the Oops is due to something wrong with an instruction, not necessarily
due to an FPU instruction.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
diff -ur linux-3.11-rc6/arch/powerpc/kernel/traps.c
linux/arch/powerpc/kernel/traps.c
--- linux-3.11-rc6/arch/powerpc/kernel/traps.c 2013-08-25 15:20:33.0
+0200
+++ linux/arch/powerpc/kernel/traps.c 2013-08-25 15:31:29.0 +0200
@@ -1476,7 +1476,8 @@
if (!user_mode(regs)) {
debugger(regs);
- die(Kernel Mode Software FPU Emulation, regs, SIGFPE);
+ die(Kernel Mode Unimplemented Instruction or SW FPU Emulation,
+ regs, SIGFPE);
}
#ifdef CONFIG_MATH_EMULATION
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: powerpc: kvm: add signed type cast for comparation
On 05.08.2013, at 07:50, Chen Gang wrote: On 08/05/2013 12:34 PM, Paul Mackerras wrote: On Mon, Jul 22, 2013 at 02:32:35PM +0800, Chen Gang wrote: 'rmls' is 'unsigned long', lpcr_rmls() will return negative number when failure occurs, so it need a type cast for comparing. 'lpid' is 'unsigned long', kvmppc_alloc_lpid() return negative number when failure occurs, so it need a type cast for comparing. Signed-off-by: Chen Gang gang.c...@asianux.com Looks right, thanks. Acked-by: Paul Mackerras pau...@samba.org Thank you very much. Thanks, applied to kvm-ppc-queue. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: Book3S PR: return appropriate error when allocation fails
On 17.07.2013, at 17:10, Thadeu Lima de Souza Cascardo wrote: err was overwritten by a previous function call, and checked to be 0. If the following page allocation fails, 0 is going to be returned instead of -ENOMEM. Signed-off-by: Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com Thanks, applied to kvm-ppc-queue. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 09/31] powerpc/fsl-pci: improve clock API use
On Wed, Aug 28, 2013 at 14:08 +0200, Gerhard Sittig wrote: [ re-created the Cc: list, this is about the PCI clock exclusively ] I just noticed by coincidence that the message which I received back from the linuxppc-dev ML appeared to have dropped Benjamin Herrenschmidt and Kumar Gala from the Cc: list -- while they do appear in the header of the message that I have sent and I can't see what might have caused the loss of information. :-O Do you want me to re-send the message for the benefit of potential followups, or is it OK that you receive the message via the list but potentially without the Cc: attribute? The message was mostly for your information and contained a status update, while no action is required or problems need to get resolved. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3] i2c: move of helpers into the core
On Thu, 22 Aug 2013 18:00:14 +0200, Wolfram Sang w...@the-dreams.de wrote: I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Acked-by: Rob Herring rob.herr...@calxeda.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Tested-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Wolfram Sang w...@the-dreams.de Acked-by: Grant Likely grant.lik...@linaro.org --- V2-V3: Was trying to be too smart by only fixing includes needed. Took a more general approach this time, converting of_i2c.h to i2c.h in case i2c.h was not already there. Otherwise remove it. Improved my build scripts and no build failures, no complaints from buildbot as well. Documentation/acpi/enumeration.txt |1 - arch/powerpc/platforms/44x/warp.c |1 - drivers/gpu/drm/tilcdc/tilcdc_slave.c |1 - drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |1 - drivers/gpu/host1x/drm/output.c |2 +- drivers/i2c/busses/i2c-at91.c |3 - drivers/i2c/busses/i2c-cpm.c|6 -- drivers/i2c/busses/i2c-davinci.c|2 - drivers/i2c/busses/i2c-designware-platdrv.c |2 - drivers/i2c/busses/i2c-gpio.c |3 - drivers/i2c/busses/i2c-i801.c |2 - drivers/i2c/busses/i2c-ibm_iic.c|4 - drivers/i2c/busses/i2c-imx.c|3 - drivers/i2c/busses/i2c-mpc.c|2 - drivers/i2c/busses/i2c-mv64xxx.c|3 - drivers/i2c/busses/i2c-mxs.c|3 - drivers/i2c/busses/i2c-nomadik.c|3 - drivers/i2c/busses/i2c-ocores.c |3 - drivers/i2c/busses/i2c-octeon.c |3 - drivers/i2c/busses/i2c-omap.c |3 - drivers/i2c/busses/i2c-pnx.c|3 - drivers/i2c/busses/i2c-powermac.c |9 +- drivers/i2c/busses/i2c-pxa.c|2 - drivers/i2c/busses/i2c-s3c2410.c|2 - drivers/i2c/busses/i2c-sh_mobile.c |2 - drivers/i2c/busses/i2c-sirf.c |3 - drivers/i2c/busses/i2c-stu300.c |2 - drivers/i2c/busses/i2c-tegra.c |3 - drivers/i2c/busses/i2c-versatile.c |2 - drivers/i2c/busses/i2c-wmt.c|3 - drivers/i2c/busses/i2c-xiic.c |3 - drivers/i2c/i2c-core.c | 109 +- drivers/i2c/i2c-mux.c |3 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - drivers/i2c/muxes/i2c-mux-gpio.c|1 - drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - drivers/media/platform/exynos4-is/fimc-is-i2c.c |4 +- drivers/media/platform/exynos4-is/fimc-is.c |2 +- drivers/media/platform/exynos4-is/media-dev.c |1 - drivers/of/Kconfig |6 -- drivers/of/Makefile |1 - drivers/of/of_i2c.c | 114 --- drivers/staging/imx-drm/imx-tve.c |2 +- include/linux/i2c.h | 20 include/linux/of_i2c.h | 46 - sound/soc/fsl/imx-sgtl5000.c|2 +- sound/soc/fsl/imx-wm8962.c |2 +- 47 files changed, 138 insertions(+), 262 deletions(-) delete mode 100644 drivers/of/of_i2c.c delete mode 100644 include/linux/of_i2c.h diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a9..958266e 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: if (ret) /* handle error */ - of_i2c_register_devices(adapter); /* Enumerate the slave devices behind this bus via ACPI */ acpi_i2c_register_devices(adapter); diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c index 4cfa499..534574a 100644 --- a/arch/powerpc/platforms/44x/warp.c +++ b/arch/powerpc/platforms/44x/warp.c @@ -16,7 +16,6 @@ #include linux/interrupt.h #include linux/delay.h #include linux/of_gpio.h -#include linux/of_i2c.h #include linux/slab.h #include linux/export.h diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c b/drivers/gpu/drm/tilcdc/tilcdc_slave.c index dfffaf0..a19f657 100644 ---
Re: [RFC PATCH v2 3/4] powerpc: refactor of_get_cpu_node to support other architectures
On Thu, 22 Aug 2013 14:59:30 +0100, Mark Rutland mark.rutl...@arm.com wrote:
On Mon, Aug 19, 2013 at 02:56:10PM +0100, Sudeep KarkadaNagesha wrote:
On 19/08/13 14:02, Rob Herring wrote:
On 08/19/2013 05:19 AM, Mark Rutland wrote:
On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote:
On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote:
I wonder how would this handle uniprocessor ARM (pre-v7) cores, for
which
the updated bindings[1] define #address-cells = 0 and so no reg
property.
[1] - http://thread.gmane.org/gmane.linux.ports.arm.kernel/260795
Why did you do that in the binding ? That sounds like looking to create
problems ...
Traditionally, UP setups just used 0 as the reg property on other
architectures, why do differently ?
The decision was taken because we defined our reg property to refer to
the MPIDR register's Aff{2,1,0} bitfields, and on UP cores before v7
there's no MPIDR register at all. Given there can only be a single CPU
in that case, describing a register that wasn't present didn't seem
necessary or helpful.
What exactly reg represents is up to the binding definition, but it
still should be present IMO. I don't see any issue with it being
different for pre-v7.
Yes it's better to have 'reg' with value 0 than not having it.
Otherwise this generic of_get_cpu_node implementation would need some
_hack_ to handle that case.
I'm not sure that having some code to handle a difference in standard
between two architectures is a hack. If anything, I'd argue encoding a
reg of 0 that corresponds to a nonexistent MPIDR value (given that's
what the reg property is defined to map to on ARM) is more of a hack ;)
I'm not averse to having a reg value of 0 for this case, but given that
there are existing devicetrees without it, requiring a reg property will
break compatibility with them.
Then special cases those device trees, but you changing existing
convention really needs to be avoided. The referenced documentation
change is brand new, so we're not stuck with it.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 09/31] powerpc/fsl-pci: improve clock API use
On Wed, 2013-08-28 at 17:59 +0200, Gerhard Sittig wrote: On Wed, Aug 28, 2013 at 14:08 +0200, Gerhard Sittig wrote: [ re-created the Cc: list, this is about the PCI clock exclusively ] I just noticed by coincidence that the message which I received back from the linuxppc-dev ML appeared to have dropped Benjamin Herrenschmidt and Kumar Gala from the Cc: list -- while they do appear in the header of the message that I have sent and I can't see what might have caused the loss of information. :-O Don't bother with me. I haven't had the bandwidth to look at that at all. I'll leave Anatolij the responsibility here :-) Cheers, Ben. Do you want me to re-send the message for the benefit of potential followups, or is it OK that you receive the message via the list but potentially without the Cc: attribute? The message was mostly for your information and contained a status update, while no action is required or problems need to get resolved. virtually yours Gerhard Sittig ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -next] ASoC: fsl_spdif: remove redundant dev_err call in fsl_spdif_probe()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
sound/soc/fsl/fsl_spdif.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index a9798aa..e93dc0d 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -1113,10 +1113,8 @@ static int fsl_spdif_probe(struct platform_device *pdev)
}
regs = devm_ioremap_resource(pdev-dev, res);
- if (IS_ERR(regs)) {
- dev_err(pdev-dev, could not map device resources\n);
+ if (IS_ERR(regs))
return PTR_ERR(regs);
- }
spdif_priv-regmap = devm_regmap_init_mmio_clk(pdev-dev,
core, regs, fsl_spdif_regmap_config);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On 08/28/2013 08:51 PM, Mark Rutland wrote:
On Wed, Aug 28, 2013 at 07:54:01AM +0100, Hongbo Zhang wrote:
On 08/27/2013 07:35 PM, Mark Rutland wrote:
On Tue, Aug 27, 2013 at 11:42:02AM +0100, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 66
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 232 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..10fd031 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,72 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include fsl,elo3-dma
+- reg : registers specifier for DMA general status reg
+- ranges: describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+- compatible: must include fsl,eloplus-dma-channel
+- reg : registers specifier for channel
+- interrupts: interrupt specifier for DMA channel IRQ
+- interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elo3-dma;
+ reg = 0x100300 0x4 0x100600 0x4;
Is that one reg entry where #size-cells=2 and #address-cells=2?
That's what the binding implies (given it only describes a single reg
entry).
if it's two entries, we should make that explicit (both in the binding
and example):
reg = 0x100300 0x4,
0x100600 0x4;
Yes they are two entries, I will change it this way.
Ok. Could you make sure you document what the two reg entries correspond
to? That's not clear from registers specifier for channel.
Yes I am sure, we have reg for DMA controller and also reg for each DMA
channel.
these two reg entries are registers specifier for DMA general status
reg, not registers specifier for channel
because this is an 8-channel DMA controller, we have two general status
registers (vs. one status register for 4-chanel DMA controller previously )
+ ranges = 0x0 0x100100 0x500;
If it is one reg entry then the example ranges property isn't big enough
to contain the parent-bus-address.
They are two reg entries, so the range is big enough.
Ok.
+ dma-channel@0 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x0 0x80;
+ interrupts = 28 2 0 0;
+ };
+ dma-channel@80 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x80 0x80;
+ interrupts = 29 2 0 0;
+ };
+ dma-channel@100 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x100 0x80;
+ interrupts = 30 2 0 0;
+ };
+ dma-channel@180 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x180 0x80;
+ interrupts = 31 2 0 0;
+ };
+ dma-channel@300 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x300 0x80;
+ interrupts = 76 2 0 0;
+ };
+ dma-channel@380 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x380 0x80;
+ interrupts = 77 2 0 0;
+ };
+ dma-channel@400 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x400 0x80;
+ interrupts = 78 2 0 0;
+ };
+ dma-channel@480 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x480 0x80;
+ interrupts = 79 2 0 0;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must say
fsl,elo-dma-channel or fsl,eloplus-dma-channel to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
---
[PATCH] Powerpc/eSDCH: Specify voltage for T4240QDS
Freescale T4240QDS reference board has extra voltage shifters added
to allow 3.3V operation, so add 3.3v voltage support for T4240QDS.
1.8v and 3.3v is recommand for eMMC and SDHC card.
Signed-off-by: Haijun Zhang haijun.zh...@freescale.com
---
arch/powerpc/boot/dts/t4240qds.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/dts/t4240qds.dts
b/arch/powerpc/boot/dts/t4240qds.dts
index 0555976..eb3c3de 100644
--- a/arch/powerpc/boot/dts/t4240qds.dts
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -148,6 +148,10 @@
interrupts = 0x1 0x1 0 0;
};
};
+
+ sdhc@114000 {
+ voltage-ranges = 1800 1800 3300 3300;
+ };
};
pci0: pcie@ffe24 {
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 03/10] crypto: nx - fix limits to sg lists for AES-CBC
On Fri, Aug 23, 2013 at 05:01:07PM -0300, Marcelo Cerri wrote: This patch updates the nx-aes-cbc implementation to perform several hyper calls if needed in order to always respect the length limits for scatter/gather lists. Two different limits are considered: - ibm,max-sg-len: maximum number of bytes of each scatter/gather list. - ibm,max-sync-cop: - The total number of bytes that a scatter/gather list can hold. - The maximum number of elements that a scatter/gather list can have. Reviewed-by: Joy Latten jmlat...@linux.vnet.ibm.com Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com This patch does not apply against the current cryptodev tree. Please regenerate your pathces. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
