[PATCH][v4]: powerpc/perf: Sample only if SIAR-Valid bit is set in P7+
powerpc/perf: Sample only if SIAR-Valid bit is set in P7+
On POWER7+ two new bits (mmcra[35] and mmcra[36]) indicate whether the
contents of SIAR and SDAR are valid.
For marked instructions on P7+, we must save the contents of SIAR and
SDAR registers only if these new bits are set.
This code/check for the SIAR-Valid bit is specific to P7+, so rather than
waste a CPU-feature bit use the PVR flag.
Note that Carl Love proposed a similar change for oprofile:
https://lkml.org/lkml/2012/6/22/309
Changelog [v4]:
- Port to powerpc/next branch - where PV_POWER7p is now PVR_POWER7p
and __is_processor() is now pvr_version_is()
- Ensure patch doesn't break 32-bit build.
Changelog[v3]:
- Commit 5c093efa6f2 added checks to use SIAR only for kernel samples.
Extend that to use SIAR only if SIAR-valid bit is set (in processors
that implement that bit).
Changelog[v2]:
- [Gabriel Paubert] Rename PV_POWER7P to PV_POWER7p.
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/perf_event_server.h |1 +
arch/powerpc/include/asm/reg.h |4 ++
arch/powerpc/perf/core-book3s.c | 44 ++---
arch/powerpc/perf/power7-pmu.c |3 ++
4 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/perf_event_server.h
b/arch/powerpc/include/asm/perf_event_server.h
index 078019b..9710be3 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -49,6 +49,7 @@ struct power_pmu {
#define PPMU_ALT_SIPR 2 /* uses alternate posn for SIPR/HV */
#define PPMU_NO_SIPR 4 /* no SIPR/HV in MMCRA at all */
#define PPMU_NO_CONT_SAMPLING 8 /* no continuous sampling */
+#define PPMU_SIAR_VALID16 /* Processor has SIAR Valid bit
*/
/*
* Values for flags to get_alternatives()
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index a1096fb..d24c141 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -606,6 +606,10 @@
#define POWER6_MMCRA_SIPR 0x0200ULL
#define POWER6_MMCRA_THRM0x0020UL
#define POWER6_MMCRA_OTHER 0x000EUL
+
+#define POWER7P_MMCRA_SIAR_VALID 0x1000 /* P7+ SIAR contents valid */
+#define POWER7P_MMCRA_SDAR_VALID 0x0800 /* P7+ SDAR contents valid */
+
#define SPRN_PMC1 787
#define SPRN_PMC2 788
#define SPRN_PMC3 789
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index fb55da9..0db88f5 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -82,6 +82,11 @@ static inline int perf_intr_is_nmi(struct pt_regs *regs)
return 0;
}
+static inline int siar_valid(struct pt_regs *regs)
+{
+ return 1;
+}
+
#endif /* CONFIG_PPC32 */
/*
@@ -106,14 +111,20 @@ static inline unsigned long perf_ip_adjust(struct pt_regs
*regs)
* If we're not doing instruction sampling, give them the SDAR
* (sampled data address). If we are doing instruction sampling, then
* only give them the SDAR if it corresponds to the instruction
- * pointed to by SIAR; this is indicated by the [POWER6_]MMCRA_SDSYNC
- * bit in MMCRA.
+ * pointed to by SIAR; this is indicated by the [POWER6_]MMCRA_SDSYNC or
+ * the [POWER7P_]MMCRA_SDAR_VALID bit in MMCRA.
*/
static inline void perf_get_data_addr(struct pt_regs *regs, u64 *addrp)
{
unsigned long mmcra = regs-dsisr;
- unsigned long sdsync = (ppmu-flags PPMU_ALT_SIPR) ?
- POWER6_MMCRA_SDSYNC : MMCRA_SDSYNC;
+ unsigned long sdsync;
+
+ if (ppmu-flags PPMU_SIAR_VALID)
+ sdsync = POWER7P_MMCRA_SDAR_VALID;
+ else if (ppmu-flags PPMU_ALT_SIPR)
+ sdsync = POWER6_MMCRA_SDSYNC;
+ else
+ sdsync = MMCRA_SDSYNC;
if (!(mmcra MMCRA_SAMPLE_ENABLE) || (mmcra sdsync))
*addrp = mfspr(SPRN_SDAR);
@@ -230,6 +241,24 @@ static inline int perf_intr_is_nmi(struct pt_regs *regs)
return !regs-softe;
}
+/*
+ * On processors like P7+ that have the SIAR-Valid bit, marked instructions
+ * must be sampled only if the SIAR-valid bit is set.
+ *
+ * For unmarked instructions and for processors that don't have the SIAR-Valid
+ * bit, assume that SIAR is valid.
+ */
+static inline int siar_valid(struct pt_regs *regs)
+{
+ unsigned long mmcra = regs-dsisr;
+ int marked = mmcra MMCRA_SAMPLE_ENABLE;
+
+ if ((ppmu-flags PPMU_SIAR_VALID) marked)
+ return mmcra POWER7P_MMCRA_SIAR_VALID;
+
+ return 1;
+}
+
#endif /* CONFIG_PPC64 */
static void perf_event_interrupt(struct pt_regs *regs);
@@ -1291,6 +1320,7 @@ struct pmu power_pmu = {
.event_idx = power_pmu_event_idx,
};
+
/*
* A counter has overflowed; update its count and record
* things if
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
-Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Tuesday, September 18, 2012 1:04 PM To: Jia Hongtao-B38951 Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421 Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote: Power supply for PCI inbound/outbound window registers is off when system go to deep-sleep state. We save the values of registers before suspend and restore to registers after resume. Signed-off-by: Jiang Yutang b14...@freescale.com Signed-off-by: Jia Hongtao b38...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- Changes for V4: We just rebase the patch upon following patch: powerpc/fsl-pci: Unify pci/pcie initialization code arch/powerpc/include/asm/pci-bridge.h |2 +- arch/powerpc/sysdev/fsl_pci.c | 121 + 2 files changed, 122 insertions(+), 1 deletions(-) Did you ever compare this to just re-parsing device tree method? - k I tested the re-parsing way by using setup_pci_atmu() when resume. And I found out that re-parsing will *change* outbound IO translation address regitster. It seems that in the first bootup, after setup_atmu() pcibios_setup_phb_resources() may update hose-io_resource, but atmu is not updated according to the new hose-io_resource value. In resume from sleep setup_atmu() will reset atmu according to the new hose-io_resource value. So the setup_atmu() will cause different result on outbound IO register between first bootup and resume from sleep. So... There's a possibility that in the first bootup atmu is not setup properly. Anyway, if setup_pci_atmu() at resume is functionally right then re-parsing is a good way for PM. I also test the latency of re-parsing and save/restore, both way are acceptable. - Hongtao. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl-pci: use 'Header Type' to identify PCIE mode
The original code uses 'Programming Interface' field to judge if PCIE is
EP or RC mode, however, some latest silicons do not support this functionality.
According to PCIE specification, 'Header Type' offset 0x0e is used to
indicate header type, so change code to use 'Header Type' field to
judge PCIE mode. Because FSL PCI controller does not support 'Header Type',
patch still uses 'Programming Interface' to identify PCI mode.
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
---
arch/powerpc/sysdev/fsl_pci.c | 38 +++---
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index c37f461..43d30df 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -38,15 +38,15 @@ static int fsl_pcie_bus_fixup, is_mpc83xx_pci;
static void __devinit quirk_fsl_pcie_header(struct pci_dev *dev)
{
- u8 progif;
+ u8 hdr_type;
/* if we aren't a PCIe don't bother */
if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
return;
/* if we aren't in host mode don't bother */
- pci_read_config_byte(dev, PCI_CLASS_PROG, progif);
- if (progif 0x1)
+ pci_read_config_byte(dev, PCI_HEADER_TYPE, hdr_type);
+ if ((hdr_type 0x7f) != PCI_HEADER_TYPE_BRIDGE)
return;
dev-class = PCI_CLASS_BRIDGE_PCI 8;
@@ -425,7 +425,7 @@ int __init fsl_add_bridge(struct device_node *dev, int
is_primary)
struct pci_controller *hose;
struct resource rsrc;
const int *bus_range;
- u8 progif;
+ u8 hdr_type, progif;
if (!of_device_is_available(dev)) {
pr_warning(%s: disabled\n, dev-full_name);
@@ -457,25 +457,24 @@ int __init fsl_add_bridge(struct device_node *dev, int
is_primary)
setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4,
PPC_INDIRECT_TYPE_BIG_ENDIAN);
- early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, progif);
- if ((progif 1) == 1) {
- /* unmap cfg_data cfg_addr separately if not on same page */
- if (((unsigned long)hose-cfg_data PAGE_MASK) !=
- ((unsigned long)hose-cfg_addr PAGE_MASK))
- iounmap(hose-cfg_data);
- iounmap(hose-cfg_addr);
- pcibios_free_controller(hose);
- return -ENODEV;
- }
-
setup_pci_cmd(hose);
/* check PCI express link status */
if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) {
+ /* For PCIE read HEADER_TYPE to identify controler mode */
+ early_read_config_byte(hose, 0, 0, PCI_HEADER_TYPE, hdr_type);
+ if ((hdr_type 0x7f) != PCI_HEADER_TYPE_BRIDGE)
+ goto no_bridge;
+
hose-indirect_type |= PPC_INDIRECT_TYPE_EXT_REG |
PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS;
if (fsl_pcie_check_link(hose))
hose-indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
+ } else {
+ /* For PCI read PROG to identify controller mode */
+ early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, progif);
+ if ((progif 1) == 1)
+ goto no_bridge;
}
printk(KERN_INFO Found FSL PCI host bridge at 0x%016llx.
@@ -494,6 +493,15 @@ int __init fsl_add_bridge(struct device_node *dev, int
is_primary)
setup_pci_atmu(hose, rsrc);
return 0;
+
+no_bridge:
+ /* unmap cfg_data cfg_addr separately if not on same page */
+ if (((unsigned long)hose-cfg_data PAGE_MASK) !=
+ ((unsigned long)hose-cfg_addr PAGE_MASK))
+ iounmap(hose-cfg_data);
+ iounmap(hose-cfg_addr);
+ pcibios_free_controller(hose);
+ return -ENODEV;
}
#endif /* CONFIG_FSL_SOC_BOOKE || CONFIG_PPC_86xx */
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC][PATCH 0/3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Varun Sethi varun.se...@freescale.com This patchset provides the Freescale PAMU (Peripheral Access Management Unit) driver and the corresponding IOMMU API implementation. PAMU is the IOMMU present on Freescale QorIQ platforms. PAMU can authorize memory access, remap the memory address, and remap the I/O transaction type. This set consists of the following patches: 1. Addition of new field in the device (powerpc) archdata structure for storing iommu domain information pointer. This pointer is stored when the device is attached to a particular iommu domain. 2. Addition of domain attributes required by the PAMU driver IOMMU API. 3. PAMU driver and IOMMU API implementation. Varun Sethi (3): Store iommu domain information pointer in archdata. Add iommu domain attributes required by fsl PAMU driver. FSL PAMU driver and IOMMU API implementation. arch/powerpc/include/asm/device.h |4 + drivers/iommu/Kconfig |7 + drivers/iommu/Makefile|1 + drivers/iommu/fsl_pamu.c | 1033 + drivers/iommu/fsl_pamu.h | 377 ++ drivers/iommu/fsl_pamu_domain.c | 990 +++ drivers/iommu/fsl_pamu_domain.h | 94 drivers/iommu/fsl_pamu_proto.h| 49 ++ include/linux/iommu.h | 30 ++ 9 files changed, 2585 insertions(+), 0 deletions(-) create mode 100644 drivers/iommu/fsl_pamu.c create mode 100644 drivers/iommu/fsl_pamu.h create mode 100644 drivers/iommu/fsl_pamu_domain.c create mode 100644 drivers/iommu/fsl_pamu_domain.h create mode 100644 drivers/iommu/fsl_pamu_proto.h -- 1.7.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC][PATCH 1/3] iommu/fsl: Store iommu domain information pointer in archdata.
From: Varun Sethi varun.se...@freescale.com
Add a new field in the device (powerpc) archdata structure for storing iommu
domain
information pointer. This pointer is stored when the device is attached to a
particular
domain.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
arch/powerpc/include/asm/device.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 77e97dd..6dc79fe 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -28,6 +28,10 @@ struct dev_archdata {
void*iommu_table_base;
} dma_data;
+ /* IOMMU domain information pointer. This would be set
+* when this device is attached to an iommu_domain.
+*/
+ void*iommu_domain;
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
#endif
--
1.7.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
From: Varun Sethi varun.se...@freescale.com
Added the following domain attributes required by FSL PAMU driver:
1. Subwindows field added to the iommu domain geometry attribute.
2. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
3. Added an attribute for enabling/disabling DMA to a particular
memory window.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
include/linux/iommu.h | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7e83370..eaa40c6 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -44,6 +44,28 @@ struct iommu_domain_geometry {
dma_addr_t aperture_start; /* First address that can be mapped*/
dma_addr_t aperture_end; /* Last address that can be mapped */
bool force_aperture; /* DMA only allowed in mappable range? */
+
+ /* The subwindows field indicates number of DMA subwindows supported
+* by the geometry. Following is the interpretation of
+* values for this field:
+* 0 : This implies that the supported geometry size is 1 MB
+ * with each subwindow size being 4KB. Thus number of subwindows
+* being = 1MB/4KB = 256.
+* 1 : Only one DMA window i.e. no subwindows.
+* value other than 0 or 1 would indicate actual number of subwindows.
+*/
+ u32 subwindows;
+};
+
+/* This attribute corresponds to IOMMUs capable of generating
+ * a stash transaction. A stash transaction is typically a
+ * hardware initiated prefetch of data from memory to cache.
+ * This attribute allows configuring stashig specific parameters
+ * in the IOMMU hardware.
+ */
+struct iommu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
};
struct iommu_domain {
@@ -60,6 +82,14 @@ struct iommu_domain {
enum iommu_attr {
DOMAIN_ATTR_MAX,
DOMAIN_ATTR_GEOMETRY,
+ /* Set the IOMMU hardware stashing
+* parameters.
+*/
+ DOMAIN_ATTR_STASH,
+ /* Explicity enable/disable DMA for a
+ * particular memory window.
+ */
+ DOMAIN_ATTR_ENABLE,
};
#ifdef CONFIG_IOMMU_API
--
1.7.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH 0/3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
On Sep 19, 2012, at 8:17 AM, b16...@freescale.com b16...@freescale.com wrote: From: Varun Sethi varun.se...@freescale.com This patchset provides the Freescale PAMU (Peripheral Access Management Unit) driver and the corresponding IOMMU API implementation. PAMU is the IOMMU present on Freescale QorIQ platforms. PAMU can authorize memory access, remap the memory address, and remap the I/O transaction type. This set consists of the following patches: 1. Addition of new field in the device (powerpc) archdata structure for storing iommu domain information pointer. This pointer is stored when the device is attached to a particular iommu domain. 2. Addition of domain attributes required by the PAMU driver IOMMU API. 3. PAMU driver and IOMMU API implementation. Varun Sethi (3): Store iommu domain information pointer in archdata. Add iommu domain attributes required by fsl PAMU driver. FSL PAMU driver and IOMMU API implementation. arch/powerpc/include/asm/device.h |4 + drivers/iommu/Kconfig |7 + drivers/iommu/Makefile|1 + drivers/iommu/fsl_pamu.c | 1033 + drivers/iommu/fsl_pamu.h | 377 ++ drivers/iommu/fsl_pamu_domain.c | 990 +++ drivers/iommu/fsl_pamu_domain.h | 94 drivers/iommu/fsl_pamu_proto.h| 49 ++ include/linux/iommu.h | 30 ++ 9 files changed, 2585 insertions(+), 0 deletions(-) create mode 100644 drivers/iommu/fsl_pamu.c create mode 100644 drivers/iommu/fsl_pamu.h create mode 100644 drivers/iommu/fsl_pamu_domain.c create mode 100644 drivers/iommu/fsl_pamu_domain.h create mode 100644 drivers/iommu/fsl_pamu_proto.h I assume that another patch series will add device tree binding spec and update device trees for SoCs with PAMU? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
On Sep 19, 2012, at 8:17 AM, b16...@freescale.com b16...@freescale.com
wrote:
From: Varun Sethi varun.se...@freescale.com
Added the following domain attributes required by FSL PAMU driver:
1. Subwindows field added to the iommu domain geometry attribute.
2. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
3. Added an attribute for enabling/disabling DMA to a particular
memory window.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
include/linux/iommu.h | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7e83370..eaa40c6 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -44,6 +44,28 @@ struct iommu_domain_geometry {
dma_addr_t aperture_start; /* First address that can be mapped*/
dma_addr_t aperture_end; /* Last address that can be mapped */
bool force_aperture; /* DMA only allowed in mappable range? */
+
+ /* The subwindows field indicates number of DMA subwindows supported
+ * by the geometry. Following is the interpretation of
+ * values for this field:
+ * 0 : This implies that the supported geometry size is 1 MB
+ * with each subwindow size being 4KB. Thus number of subwindows
+ * being = 1MB/4KB = 256.
+ * 1 : Only one DMA window i.e. no subwindows.
+ * value other than 0 or 1 would indicate actual number of subwindows.
+ */
+ u32 subwindows;
+};
+
+/* This attribute corresponds to IOMMUs capable of generating
+ * a stash transaction. A stash transaction is typically a
+ * hardware initiated prefetch of data from memory to cache.
+ * This attribute allows configuring stashig specific parameters
+ * in the IOMMU hardware.
+ */
+struct iommu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
seems like this should be enum instead of u32 for cache
With enum being something like:
enum iommu_attr_stash_cache {
IOMMU_ATTR_CACHE_L1,
IOMMU_ATTR_CACHE_L2,
IOMMU_ATTR_CACHE_L3,
};
};
struct iommu_domain {
@@ -60,6 +82,14 @@ struct iommu_domain {
enum iommu_attr {
DOMAIN_ATTR_MAX,
DOMAIN_ATTR_GEOMETRY,
+ /* Set the IOMMU hardware stashing
+ * parameters.
+ */
+ DOMAIN_ATTR_STASH,
+ /* Explicity enable/disable DMA for a
+ * particular memory window.
+ */
+ DOMAIN_ATTR_ENABLE,
};
#ifdef CONFIG_IOMMU_API
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl-pci: use 'Header Type' to identify PCIE mode
On Sep 19, 2012, at 2:23 AM, Minghuan Lian wrote:
The original code uses 'Programming Interface' field to judge if PCIE is
EP or RC mode, however, some latest silicons do not support this
functionality.
According to PCIE specification, 'Header Type' offset 0x0e is used to
indicate header type, so change code to use 'Header Type' field to
judge PCIE mode. Because FSL PCI controller does not support 'Header Type',
patch still uses 'Programming Interface' to identify PCI mode.
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
---
arch/powerpc/sysdev/fsl_pci.c | 38 +++---
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index c37f461..43d30df 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -38,15 +38,15 @@ static int fsl_pcie_bus_fixup, is_mpc83xx_pci;
static void __devinit quirk_fsl_pcie_header(struct pci_dev *dev)
{
- u8 progif;
+ u8 hdr_type;
/* if we aren't a PCIe don't bother */
if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
return;
/* if we aren't in host mode don't bother */
- pci_read_config_byte(dev, PCI_CLASS_PROG, progif);
- if (progif 0x1)
+ pci_read_config_byte(dev, PCI_HEADER_TYPE, hdr_type);
+ if ((hdr_type 0x7f) != PCI_HEADER_TYPE_BRIDGE)
return;
dev-class = PCI_CLASS_BRIDGE_PCI 8;
@@ -425,7 +425,7 @@ int __init fsl_add_bridge(struct device_node *dev, int
is_primary)
struct pci_controller *hose;
struct resource rsrc;
const int *bus_range;
- u8 progif;
+ u8 hdr_type, progif;
if (!of_device_is_available(dev)) {
pr_warning(%s: disabled\n, dev-full_name);
@@ -457,25 +457,24 @@ int __init fsl_add_bridge(struct device_node *dev, int
is_primary)
setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4,
PPC_INDIRECT_TYPE_BIG_ENDIAN);
- early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, progif);
- if ((progif 1) == 1) {
- /* unmap cfg_data cfg_addr separately if not on same page */
- if (((unsigned long)hose-cfg_data PAGE_MASK) !=
- ((unsigned long)hose-cfg_addr PAGE_MASK))
- iounmap(hose-cfg_data);
- iounmap(hose-cfg_addr);
- pcibios_free_controller(hose);
- return -ENODEV;
- }
-
setup_pci_cmd(hose);
I think we should be doing the check before we call setup_pci_cmd(). The old
code didn't touch the controller registers if we where and end-point. We
should maintain that.
/* check PCI express link status */
if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) {
+ /* For PCIE read HEADER_TYPE to identify controler mode */
+ early_read_config_byte(hose, 0, 0, PCI_HEADER_TYPE, hdr_type);
+ if ((hdr_type 0x7f) != PCI_HEADER_TYPE_BRIDGE)
+ goto no_bridge;
+
hose-indirect_type |= PPC_INDIRECT_TYPE_EXT_REG |
PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS;
if (fsl_pcie_check_link(hose))
hose-indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
+ } else {
+ /* For PCI read PROG to identify controller mode */
+ early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, progif);
+ if ((progif 1) == 1)
+ goto no_bridge;
}
printk(KERN_INFO Found FSL PCI host bridge at 0x%016llx.
@@ -494,6 +493,15 @@ int __init fsl_add_bridge(struct device_node *dev, int
is_primary)
setup_pci_atmu(hose, rsrc);
return 0;
+
+no_bridge:
+ /* unmap cfg_data cfg_addr separately if not on same page */
+ if (((unsigned long)hose-cfg_data PAGE_MASK) !=
+ ((unsigned long)hose-cfg_addr PAGE_MASK))
+ iounmap(hose-cfg_data);
+ iounmap(hose-cfg_addr);
+ pcibios_free_controller(hose);
+ return -ENODEV;
}
#endif /* CONFIG_FSL_SOC_BOOKE || CONFIG_PPC_86xx */
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
On Sep 19, 2012, at 2:10 AM, Jia Hongtao-B38951 wrote: -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Tuesday, September 18, 2012 1:04 PM To: Jia Hongtao-B38951 Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421 Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote: Power supply for PCI inbound/outbound window registers is off when system go to deep-sleep state. We save the values of registers before suspend and restore to registers after resume. Signed-off-by: Jiang Yutang b14...@freescale.com Signed-off-by: Jia Hongtao b38...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- Changes for V4: We just rebase the patch upon following patch: powerpc/fsl-pci: Unify pci/pcie initialization code arch/powerpc/include/asm/pci-bridge.h |2 +- arch/powerpc/sysdev/fsl_pci.c | 121 + 2 files changed, 122 insertions(+), 1 deletions(-) Did you ever compare this to just re-parsing device tree method? - k I tested the re-parsing way by using setup_pci_atmu() when resume. And I found out that re-parsing will *change* outbound IO translation address regitster. It seems that in the first bootup, after setup_atmu() pcibios_setup_phb_resources() may update hose-io_resource, but atmu is not updated according to the new hose-io_resource value. In resume from sleep setup_atmu() will reset atmu according to the new hose-io_resource value. So the setup_atmu() will cause different result on outbound IO register between first bootup and resume from sleep. So... There's a possibility that in the first bootup atmu is not setup properly. Are you seeing this happen in your testing? If so its a bug we need to look at fixing. Anyway, if setup_pci_atmu() at resume is functionally right then re-parsing is a good way for PM. I also test the latency of re-parsing and save/restore, both way are acceptable. - Hongtao. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 5/7] ASoC: fsl: convert pcm030-audio-fabric to a platform-driver
On 2012-09-18 Mark Brown wrote:
On Thu, Sep 13, 2012 at 05:43:14PM -0400, Eric Millbrandt wrote:
+static int __devexit pcm030_fabric_remove(struct platform_device *op)
+{ + struct platform_device *pdev = platform_get_drvdata(op); +
+platform_device_unregister(pdev); + + return 0; +}
This seems really confused... why is a platform device registering
another platform device? Do you mean to convert to
snd_soc_register_card()?
That was an artifact of me splitting the changes to pcm030-audio-fabric.c
into multiple patches. I changed the driver to a platform device in this
patch and converted to snd_soc_register_card() in the next patch. I can
merge the two patches back together if you think that is cleaner and
easier to understand.
Thanks
Eric
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
This e-mail and the information, including any attachments, it contains are
intended to be a confidential communication only to the person or entity to
whom it is addressed and may contain information that is privileged. If the
reader of this message is not the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error, please
immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/7] ASoC: fsl: add PPC_MPC52xx dependency to SND_POWERPC_SOC
From: Eric Millbrandt emillbra...@dekaresearch.com mpc52xx socs need to define SND_POWERPC_SOC to build ASoC drivers. Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com --- Changes since v1: Patch was powerpc/52xx: define FSL_SOC Changed from defining FSL_SOC for PPC_MPC52xx to adding PPC_MPC52xx as a dependency of SND_POWERPC_SOC as per Anatolij Gustschin's comment. sound/soc/fsl/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index d701330..4563b28 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -6,7 +6,7 @@ config SND_SOC_FSL_UTILS menuconfig SND_POWERPC_SOC tristate SoC Audio for Freescale PowerPC CPUs - depends on FSL_SOC + depends on FSL_SOC || PPC_MPC52xx help Say Y or M if you want to add support for codecs attached to the PowerPC CPUs. -- 1.7.2.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] p1023rds_defconfig: Add USB support
On Sep 14, 2012, at 2:57 PM, Chunhe Lan wrote: Signed-off-by: Chunhe Lan chunhe@freescale.com --- arch/powerpc/configs/85xx/p1023rds_defconfig |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl-pci: fix warning when CONFIG_SWIOTLB is disabled
On Sep 18, 2012, at 4:57 AM, Jia Hongtao wrote: Fix the following warning: arch/powerpc/sysdev/fsl_pci.c: In function 'fsl_pci_probe': arch/powerpc/sysdev/fsl_pci.c:867:25: error: unused variable 'hose' Signed-off-by: Jia Hongtao b38...@freescale.com --- arch/powerpc/sysdev/fsl_pci.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc85xx:Update interrupt handling for IFC controller
On Sep 13, 2012, at 3:04 AM, Prabhakar Kushwaha wrote: IFC may have one or two interrupts. If two interrupt specifiers are present, the first is the common interrupt (CM_EVTER_STAT), and the second is the NAND interrupt (NAND_EVTER_STAT). If there is only one, that interrupt reports both types of event. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Based upon git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git branch next arch/powerpc/sysdev/fsl_ifc.c | 20 1 file changed, 8 insertions(+), 12 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/smp: Do not disable IPI interrupts during suspend
On Jul 20, 2012, at 7:47 AM, Zhao Chenhui wrote: During suspend, all interrupts including IPI will be disabled. In this case, the suspend process will hang in SMP. To prevent this, pass the flag IRQF_NO_SUSPEND when requesting IPI irq. Signed-off-by: Zhao Chenhui chenhui.z...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- arch/powerpc/kernel/smp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git next branch
The following changes since commit caa1d631fc99940f866480c2bb88a6f5a235e7a2: Merge remote-tracking branch 'kumar/next' into next (2012-09-18 16:04:33 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next for you to fetch changes up to 4d56dec5dca496655ef035ef3b80f7c47dc22b77: powerpc/fsl-pci: fix warning when CONFIG_SWIOTLB is disabled (2012-09-19 08:41:46 -0500) Chunhe Lan (1): powerpc/85xx: Enable USB support in p1023rds_defconfig Jia Hongtao (1): powerpc/fsl-pci: fix warning when CONFIG_SWIOTLB is disabled Prabhakar Kushwaha (1): powerpc/mpc85xx: Update interrupt handling for IFC controller Zhao Chenhui (1): powerpc/smp: Do not disable IPI interrupts during suspend arch/powerpc/configs/85xx/p1023rds_defconfig |6 ++ arch/powerpc/kernel/smp.c|2 +- arch/powerpc/sysdev/fsl_ifc.c| 20 arch/powerpc/sysdev/fsl_pci.c|2 ++ 4 files changed, 17 insertions(+), 13 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH 1/3] iommu/fsl: Store iommu domain information pointer in archdata.
On Sep 19, 2012, at 8:17 AM, b16...@freescale.com b16...@freescale.com
wrote:
From: Varun Sethi varun.se...@freescale.com
Add a new field in the device (powerpc) archdata structure for storing iommu
domain
information pointer. This pointer is stored when the device is attached to a
particular
domain.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
arch/powerpc/include/asm/device.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
Not too familiar, but what does the IBM Server IOMMU do for iommu_domain?
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 77e97dd..6dc79fe 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -28,6 +28,10 @@ struct dev_archdata {
void*iommu_table_base;
} dma_data;
+ /* IOMMU domain information pointer. This would be set
+ * when this device is attached to an iommu_domain.
+ */
+ void*iommu_domain;
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
#endif
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Kumar Gala [ga...@kernel.crashing.org] Sent: Wednesday, September 19, 2012 10:27 PM To: Jia Hongtao-B38951 Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421 Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support On Sep 19, 2012, at 2:10 AM, Jia Hongtao-B38951 wrote: -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Tuesday, September 18, 2012 1:04 PM To: Jia Hongtao-B38951 Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421 Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote: Power supply for PCI inbound/outbound window registers is off when system go to deep-sleep state. We save the values of registers before suspend and restore to registers after resume. Signed-off-by: Jiang Yutang b14...@freescale.com Signed-off-by: Jia Hongtao b38...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- Changes for V4: We just rebase the patch upon following patch: powerpc/fsl-pci: Unify pci/pcie initialization code arch/powerpc/include/asm/pci-bridge.h |2 +- arch/powerpc/sysdev/fsl_pci.c | 121 + 2 files changed, 122 insertions(+), 1 deletions(-) Did you ever compare this to just re-parsing device tree method? - k I tested the re-parsing way by using setup_pci_atmu() when resume. And I found out that re-parsing will *change* outbound IO translation address regitster. It seems that in the first bootup, after setup_atmu() pcibios_setup_phb_resources() may update hose-io_resource, but atmu is not updated according to the new hose-io_resource value. In resume from sleep setup_atmu() will reset atmu according to the new hose-io_resource value. So the setup_atmu() will cause different result on outbound IO register between first bootup and resume from sleep. So... There's a possibility that in the first bootup atmu is not setup properly. [Are you seeing this happen in your testing? If so its a bug we need to look at fixing.] Yes, I see this in my testing. Also PCIe ethernet card works well after resuming from sleep in both save/restore and re-parsing way. (Maybe PCIe ethernet card don't need outbound IO resource) So, I guess the result of re-parsing (actually it's re-setup) is right and ATMU is not setup properly at the first bootup. Anyway, if setup_pci_atmu() at resume is functionally right then re-parsing is a good way for PM. I also test the latency of re-parsing and save/restore, both way are acceptable. - Hongtao. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote: Power supply for PCI inbound/outbound window registers is off when system go to deep-sleep state. We save the values of registers before suspend and restore to registers after resume. Signed-off-by: Jiang Yutang b14...@freescale.com Signed-off-by: Jia Hongtao b38...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- Changes for V4: We just rebase the patch upon following patch: powerpc/fsl-pci: Unify pci/pcie initialization code arch/powerpc/include/asm/pci-bridge.h |2 +- arch/powerpc/sysdev/fsl_pci.c | 121 + 2 files changed, 122 insertions(+), 1 deletions(-) Did you ever compare this to just re-parsing device tree method? - k I tested the re-parsing way by using setup_pci_atmu() when resume. And I found out that re-parsing will *change* outbound IO translation address regitster. It seems that in the first bootup, after setup_atmu() pcibios_setup_phb_resources() may update hose-io_resource, but atmu is not updated according to the new hose-io_resource value. In resume from sleep setup_atmu() will reset atmu according to the new hose-io_resource value. So the setup_atmu() will cause different result on outbound IO register between first bootup and resume from sleep. So... There's a possibility that in the first bootup atmu is not setup properly. [Are you seeing this happen in your testing? If so its a bug we need to look at fixing.] Yes, I see this in my testing. Also PCIe ethernet card works well after resuming from sleep in both save/restore and re-parsing way. (Maybe PCIe ethernet card don't need outbound IO resource) So, I guess the result of re-parsing (actually it's re-setup) is right and ATMU is not setup properly at the first bootup. Are you seeing the following message - PCI: I/O resource not set for host bridge ? Trying to understand why you'd hit the reassignment of io_resource. - k Anyway, if setup_pci_atmu() at resume is functionally right then re-parsing is a good way for PM. I also test the latency of re-parsing and save/restore, both way are acceptable. - Hongtao. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
Hi, On Tue, Sep 18, 2012 at 05:39:37PM +0800, Wen Congyang wrote: At 09/13/2012 01:18 AM, Vasilis Liaskovitis Wrote: Hi, On Wed, Sep 12, 2012 at 01:20:28PM +0800, Wen Congyang wrote: Hmm, seabios doesn't support ACPI table SLIT. We can specify node it for dimm device, so I think we should support SLIT in seabios. Otherwise we may meet the following kernel messages: [ 325.016769] init_memory_mapping: [mem 0x4000-0x5fff] [ 325.018060] [mem 0x4000-0x5fff] page 2M [ 325.019168] [ea000100-ea00011f] potential offnode page_structs [ 325.024172] [ea000120-ea00013f] potential offnode page_structs [ 325.028596] [ea000140-ea00017f] PMD - [88003500-8800353f] on node 1 [ 325.031775] [ea000160-ea00017f] potential offnode page_structs Do you have plan to do it? thanks for testing. commit 5294828 from https://github.com/vliaskov/seabios/commits/memhp-v2 implements a SLIT table for the given numa nodes. Hmm, why do you set node_distance(i, j) to REMOTE_DISTANCE if i != j? What's the alternative? Afaik SLIT[i][j] shows the distance between proximity domains (_PXM) i and j. It doesn't correspond to individual SRAT entries. So i and j here are not memory ranges associated with 2 different dimms. They denote domains i and j, which map to 2 different logical nodeids in the kernel. A default setting would be to set the entry to REMOTE_DISTANCE for all different domains (i!=j). So this SLIT implementation is not useful, since it results in the same numa_distance values as the non-SLIT kernel calculation in include/linux/topology.h However I am not sure the SLIT is the problem. The kernel builds a default numa_distance table in arch/x86/mm/numa.c: numa_alloc_distance(). If the BIOS doesn't present a SLIT, this should take effect (numactl --hardware should report this table) If the BIOS doesn't present a SLIT, numa_distance_cnt is set to 0 in the function numa_reset_distance(). So node_distance(i, j) is REMOTE_DISTANCE(i != j). Do you have more details on how to reproduce the warning? e.g. how many dimms are present in the system? Does this happen on the first dimm hot-plugged? Are all SRAT entries parsed correctly at boot-time or do you see any other warnings at boot-time? I can't reproduce it again. IIRC, I only do the following things: hotplug a memory device, online the pages, offline the pages and hot remove the memory device. Is the sparse_vmemmap allocation supposed to guarantee no off-node allocations? If not, then the warning could be valid. thanks, - Vasilis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/7] ASoC: fsl: convert pcm030-audio-fabric to a platform-driver
On Wed, Sep 19, 2012 at 10:35:45AM -0400, Eric Millbrandt wrote: That was an artifact of me splitting the changes to pcm030-audio-fabric.c into multiple patches. I changed the driver to a platform device in this patch and converted to snd_soc_register_card() in the next patch. I can merge the two patches back together if you think that is cleaner and easier to understand. Yes, please. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/7] ASoC: fsl: add PPC_MPC52xx dependency to SND_POWERPC_SOC
On Wed, Sep 19, 2012 at 10:51:25AM -0400, wrote: From: Eric Millbrandt emillbra...@dekaresearch.com mpc52xx socs need to define SND_POWERPC_SOC to build ASoC drivers. Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com --- Changes since v1: Patch was powerpc/52xx: define FSL_SOC Changed from defining FSL_SOC for PPC_MPC52xx to adding PPC_MPC52xx as a dependency of SND_POWERPC_SOC as per Anatolij Gustschin's comment. Patches 2 to 7 appear to have gone AWOL? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/7] ASoC: fsl: add PPC_MPC52xx dependency to SND_POWERPC_SOC
On 2012-09-19 Mark Brown wrote: On Wed, Sep 19, 2012 at 10:51:25AM -0400, wrote: From: Eric Millbrandt emillbra...@dekaresearch.com mpc52xx socs need to define SND_POWERPC_SOC to build ASoC drivers. Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com --- Changes since v1: Patch was powerpc/52xx: define FSL_SOC Changed from defining FSL_SOC for PPC_MPC52xx to adding PPC_MPC52xx as a dependency of SND_POWERPC_SOC as per Anatolij Gustschin's comment. Patches 2 to 7 appear to have gone AWOL? No changes to 2 through 7, so I didn't repost the full series. Eric -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
On 09/19/2012 08:52:27 AM, Kumar Gala wrote:
On Sep 19, 2012, at 8:17 AM, b16...@freescale.com
b16...@freescale.com wrote:
From: Varun Sethi varun.se...@freescale.com
Added the following domain attributes required by FSL PAMU driver:
1. Subwindows field added to the iommu domain geometry attribute.
2. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
3. Added an attribute for enabling/disabling DMA to a particular
memory window.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
include/linux/iommu.h | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7e83370..eaa40c6 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -44,6 +44,28 @@ struct iommu_domain_geometry {
dma_addr_t aperture_start; /* First address that can be
mapped*/
dma_addr_t aperture_end; /* Last address that can be
mapped */
bool force_aperture; /* DMA only allowed in mappable
range? */
+
+ /* The subwindows field indicates number of DMA subwindows
supported
+ * by the geometry. Following is the interpretation of
+ * values for this field:
+ * 0 : This implies that the supported geometry size is 1 MB
+ * with each subwindow size being 4KB. Thus number of
subwindows
+ * being = 1MB/4KB = 256.
+ * 1 : Only one DMA window i.e. no subwindows.
+ * value other than 0 or 1 would indicate actual number of
subwindows.
+ */
+ u32 subwindows;
+};
+
+/* This attribute corresponds to IOMMUs capable of generating
+ * a stash transaction. A stash transaction is typically a
+ * hardware initiated prefetch of data from memory to cache.
+ * This attribute allows configuring stashig specific parameters
+ * in the IOMMU hardware.
+ */
+struct iommu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
seems like this should be enum instead of u32 for cache
With enum being something like:
enum iommu_attr_stash_cache {
IOMMU_ATTR_CACHE_L1,
IOMMU_ATTR_CACHE_L2,
IOMMU_ATTR_CACHE_L3,
};
Don't we want these structs to be usable via some VFIO ioctl? In that
case they need to use fixed size types.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH 0/3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
On 09/19/2012 08:49:14 AM, Kumar Gala wrote: On Sep 19, 2012, at 8:17 AM, b16...@freescale.com b16...@freescale.com wrote: From: Varun Sethi varun.se...@freescale.com This patchset provides the Freescale PAMU (Peripheral Access Management Unit) driver and the corresponding IOMMU API implementation. PAMU is the IOMMU present on Freescale QorIQ platforms. PAMU can authorize memory access, remap the memory address, and remap the I/O transaction type. This set consists of the following patches: 1. Addition of new field in the device (powerpc) archdata structure for storing iommu domain information pointer. This pointer is stored when the device is attached to a particular iommu domain. 2. Addition of domain attributes required by the PAMU driver IOMMU API. 3. PAMU driver and IOMMU API implementation. Varun Sethi (3): Store iommu domain information pointer in archdata. Add iommu domain attributes required by fsl PAMU driver. FSL PAMU driver and IOMMU API implementation. arch/powerpc/include/asm/device.h |4 + drivers/iommu/Kconfig |7 + drivers/iommu/Makefile|1 + drivers/iommu/fsl_pamu.c | 1033 + drivers/iommu/fsl_pamu.h | 377 ++ drivers/iommu/fsl_pamu_domain.c | 990 +++ drivers/iommu/fsl_pamu_domain.h | 94 drivers/iommu/fsl_pamu_proto.h| 49 ++ include/linux/iommu.h | 30 ++ 9 files changed, 2585 insertions(+), 0 deletions(-) create mode 100644 drivers/iommu/fsl_pamu.c create mode 100644 drivers/iommu/fsl_pamu.h create mode 100644 drivers/iommu/fsl_pamu_domain.c create mode 100644 drivers/iommu/fsl_pamu_domain.h create mode 100644 drivers/iommu/fsl_pamu_proto.h I assume that another patch series will add device tree binding spec and update device trees for SoCs with PAMU? The device trees already have PAMU in them. A binding would be nice, though. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/7] ASoC: fsl: add PPC_MPC52xx dependency to SND_POWERPC_SOC
On Wed, Sep 19, 2012 at 05:07:34PM -0400, Eric Millbrandt wrote: On 2012-09-19 Mark Brown wrote: Patches 2 to 7 appear to have gone AWOL? No changes to 2 through 7, so I didn't repost the full series. Then this isn't patch 1/7, it's just a patch. The fact that you may have posted some patches earlier isn't relevant and creates confusion like this. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
