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 > > Signed-off-by: Jia Hongtao > > Signed-off-by: Li Yang > > --- > > 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
Signed-off-by: Roy Zang
---
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 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
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
---
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
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
---
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, wrote: > From: Varun Sethi > > 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,
wrote:
> From: Varun Sethi
>
> 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
> ---
> 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
> Signed-off-by: Roy Zang
> ---
> 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 >>> Signed-off-by: Jia Hongtao >>> Signed-off-by: Li Yang >>> --- >>> 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 mpc52xx socs need to define SND_POWERPC_SOC to build ASoC drivers. Signed-off-by: Eric Millbrandt --- 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 > --- > 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 > --- > 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 > --- > 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 > Signed-off-by: Li Yang > --- > 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,
wrote:
> From: Varun Sethi
>
> 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
> ---
> 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 >>> Signed-off-by: Jia Hongtao >>> Signed-off-by: Li Yang >>> --- >>> 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 Signed-off-by: Jia Hongtao Signed-off-by: Li Yang --- 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 > > mpc52xx socs need to define SND_POWERPC_SOC to build ASoC drivers. > > Signed-off-by: Eric Millbrandt > --- > 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 >> >> mpc52xx socs need to define SND_POWERPC_SOC to build ASoC drivers. >> >> Signed-off-by: Eric Millbrandt --- >> 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,
wrote:
> From: Varun Sethi
>
> 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
> ---
> 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, wrote: > From: Varun Sethi > > 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
