* [PATCH v2 1/7] ASoC: fsl: add PPC_MPC52xx dependency to SND_POWERPC_SOC
From: "Eric Millbrandt @ 2012-09-19 14:51 UTC (permalink / raw)
To: Grant Likely, Liam Girdwood, Mark Brown
Cc: alsa-devel, linuxppc-dev, Eric Millbrandt
From: Eric Millbrandt <emillbrandt@dekaresearch.com>
mpc52xx socs need to define SND_POWERPC_SOC to build ASoC drivers.
Signed-off-by: Eric Millbrandt <emillbrandt@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
^ permalink raw reply related
* Re: [PATCH] p1023rds_defconfig: Add USB support
From: Gala Kumar-B11780 @ 2012-09-19 14:52 UTC (permalink / raw)
To: Lan Chunhe-B25806; +Cc: <linuxppc-dev@lists.ozlabs.org>
In-Reply-To: <1347652640-20748-1-git-send-email-Chunhe.Lan@freescale.com>
On Sep 14, 2012, at 2:57 PM, Chunhe Lan wrote:
> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> ---
> arch/powerpc/configs/85xx/p1023rds_defconfig | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-pci: fix warning when CONFIG_SWIOTLB is disabled
From: Kumar Gala @ 2012-09-19 14:51 UTC (permalink / raw)
To: Jia Hongtao; +Cc: mikey, linuxppc-dev
In-Reply-To: <1347962268-25136-1-git-send-email-B38951@freescale.com>
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 <B38951@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_pci.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc/mpc85xx:Update interrupt handling for IFC controller
From: Kumar Gala @ 2012-09-19 14:52 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: linuxppc-dev
In-Reply-To: <1347523451-7843-1-git-send-email-prabhakar@freescale.com>
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.
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git branch =
next=20
>=20
> arch/powerpc/sysdev/fsl_ifc.c | 20 ++++++++------------
> 1 file changed, 8 insertions(+), 12 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/smp: Do not disable IPI interrupts during suspend
From: Kumar Gala @ 2012-09-19 14:52 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1342788421-27648-1-git-send-email-chenhui.zhao@freescale.com>
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.
>=20
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/kernel/smp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to next
- k=
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch
From: Kumar Gala @ 2012-09-19 15:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
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(-)
^ permalink raw reply
* Re: [RFC][PATCH 1/3] iommu/fsl: Store iommu domain information pointer in archdata.
From: Kumar Gala @ 2012-09-19 13:50 UTC (permalink / raw)
To: <b16395@freescale.com>
Cc: joerg.roedel, iommu, linuxppc-dev, linux-kernel, Varun Sethi
In-Reply-To: <1348060632-12997-2-git-send-email-b16395@freescale.com>
On Sep 19, 2012, at 8:17 AM, <b16395@freescale.com> =
<b16395@freescale.com> wrote:
> From: Varun Sethi <Varun.Sethi@freescale.com>
>=20
> 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.
>=20
> Signed-off-by: Varun Sethi <Varun.Sethi@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?
>=20
> 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;
>=20
> + /* 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
> --=20
> 1.7.4.1
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe =
linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Jia Hongtao-B38951 @ 2012-09-19 15:41 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <36119932-E4BF-4DF6-8D33-C9A832883272@kernel.crashing.org>
=0A=
________________________________________=0A=
From: Kumar Gala [galak@kernel.crashing.org]=0A=
Sent: Wednesday, September 19, 2012 10:27 PM=0A=
To: Jia Hongtao-B38951=0A=
Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421=0A=
Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM suppo=
rt=0A=
=0A=
On Sep 19, 2012, at 2:10 AM, Jia Hongtao-B38951 wrote:=0A=
=0A=
>=0A=
>=0A=
>> -----Original Message-----=0A=
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]=0A=
>> Sent: Tuesday, September 18, 2012 1:04 PM=0A=
>> To: Jia Hongtao-B38951=0A=
>> Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421=0A=
>> Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM=0A=
>> support=0A=
>>=0A=
>>=0A=
>> On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:=0A=
>>=0A=
>>> Power supply for PCI inbound/outbound window registers is off when=0A=
>>> system go to deep-sleep state. We save the values of registers before=
=0A=
>>> suspend and restore to registers after resume.=0A=
>>>=0A=
>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>=0A=
>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>=0A=
>>> Signed-off-by: Li Yang <leoli@freescale.com>=0A=
>>> ---=0A=
>>> Changes for V4:=0A=
>>> We just rebase the patch upon following patch:=0A=
>>> powerpc/fsl-pci: Unify pci/pcie initialization code=0A=
>>>=0A=
>>> arch/powerpc/include/asm/pci-bridge.h | 2 +-=0A=
>>> arch/powerpc/sysdev/fsl_pci.c | 121=0A=
>> +++++++++++++++++++++++++++++++++=0A=
>>> 2 files changed, 122 insertions(+), 1 deletions(-)=0A=
>>=0A=
>> Did you ever compare this to just re-parsing device tree method?=0A=
>>=0A=
>> - k=0A=
>=0A=
> I tested the re-parsing way by using setup_pci_atmu() when resume.=0A=
> And I found out that re-parsing will *change* outbound IO translation=0A=
> address regitster.=0A=
>=0A=
> It seems that in the first bootup, after setup_atmu()=0A=
> pcibios_setup_phb_resources() may update hose->io_resource, but atmu=0A=
> is not updated according to the new hose->io_resource value.=0A=
> In resume from sleep setup_atmu() will reset atmu according to the=0A=
> new hose->io_resource value. So the setup_atmu() will cause different=0A=
> result on outbound IO register between first bootup and resume from=0A=
> sleep.=0A=
>=0A=
> So... There's a possibility that in the first bootup atmu is not setup=0A=
> properly.=0A=
=0A=
[Are you seeing this happen in your testing? If so its a bug we need to lo=
ok at fixing.]=0A=
=0A=
Yes, I see this in my testing.=0A=
Also PCIe ethernet card works well after resuming from sleep in both save/r=
estore=0A=
and re-parsing way. (Maybe PCIe ethernet card don't need outbound IO resour=
ce)=0A=
So, I guess the result of re-parsing (actually it's re-setup) is right and =
ATMU is not setup=0A=
properly at the first bootup.=0A=
=0A=
=0A=
=0A=
>=0A=
> Anyway, if setup_pci_atmu() at resume is functionally right then re-parsi=
ng=0A=
> is a good way for PM. I also test the latency of re-parsing and save/rest=
ore,=0A=
> both way are acceptable.=0A=
>=0A=
>=0A=
> - Hongtao.=0A=
=0A=
=0A=
^ permalink raw reply
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Kumar Gala @ 2012-09-19 15:49 UTC (permalink / raw)
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01AAA4E8@039-SN1MPN1-002.039d.mgd.msft.net>
>>> On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:
>>>=20
>>>> 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.
>>>>=20
>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>> ---
>>>> Changes for V4:
>>>> We just rebase the patch upon following patch:
>>>> powerpc/fsl-pci: Unify pci/pcie initialization code
>>>>=20
>>>> arch/powerpc/include/asm/pci-bridge.h | 2 +-
>>>> arch/powerpc/sysdev/fsl_pci.c | 121
>>> +++++++++++++++++++++++++++++++++
>>>> 2 files changed, 122 insertions(+), 1 deletions(-)
>>>=20
>>> Did you ever compare this to just re-parsing device tree method?
>>>=20
>>> - k
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> So... There's a possibility that in the first bootup atmu is not =
setup
>> properly.
>=20
> [Are you seeing this happen in your testing? If so its a bug we need =
to look at fixing.]
>=20
> 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
>=20
>=20
>=20
>>=20
>> 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.
>>=20
>>=20
>> - Hongtao.
>=20
>=20
^ permalink raw reply
* Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
From: Vasilis Liaskovitis @ 2012-09-19 17:02 UTC (permalink / raw)
To: Wen Congyang
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, Yasuaki Ishimatsu, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, Andrew Morton,
linuxppc-dev, cl, liuj97
In-Reply-To: <50584159.3020403@cn.fujitsu.com>
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 0x40000000-0x5fffffff]
> >> [ 325.018060] [mem 0x40000000-0x5fffffff] page 2M
> >> [ 325.019168] [ffffea0001000000-ffffea00011fffff] potential offnode page_structs
> >> [ 325.024172] [ffffea0001200000-ffffea00013fffff] potential offnode page_structs
> >> [ 325.028596] [ffffea0001400000-ffffea00017fffff] PMD -> [ffff880035000000-ffff8800353fffff] on node 1
> >> [ 325.031775] [ffffea0001600000-ffffea00017fffff] 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
^ permalink raw reply
* Re: [PATCH 5/7] ASoC: fsl: convert pcm030-audio-fabric to a platform-driver
From: Mark Brown @ 2012-09-19 20:46 UTC (permalink / raw)
To: Eric Millbrandt
Cc: alsa-devel@alsa-project.org, Anatolij Gustschin,
linuxppc-dev@lists.ozlabs.org, Liam Girdwood
In-Reply-To: <0A40042D85E7C84DB443060EC44B3FD3459868BABB@dekaexchange07.deka.local>
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.
^ permalink raw reply
* Re: [PATCH v2 1/7] ASoC: fsl: add PPC_MPC52xx dependency to SND_POWERPC_SOC
From: Mark Brown @ 2012-09-19 20:47 UTC (permalink / raw)
To: Grant Likely, Liam Girdwood; +Cc: alsa-devel, linuxppc-dev, Eric Millbrandt
In-Reply-To: <1348066285-87741-1-git-send-email-emillbrandt@dekaresearch.com>
On Wed, Sep 19, 2012 at 10:51:25AM -0400, wrote:
> From: Eric Millbrandt <emillbrandt@dekaresearch.com>
>
> mpc52xx socs need to define SND_POWERPC_SOC to build ASoC drivers.
>
> Signed-off-by: Eric Millbrandt <emillbrandt@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?
^ permalink raw reply
* RE: [PATCH v2 1/7] ASoC: fsl: add PPC_MPC52xx dependency to SND_POWERPC_SOC
From: Eric Millbrandt @ 2012-09-19 21:07 UTC (permalink / raw)
To: 'Mark Brown', Grant Likely, Liam Girdwood
Cc: alsa-devel@alsa-project.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20120919204730.GB12297@opensource.wolfsonmicro.com>
On 2012-09-19 Mark Brown wrote:
> On Wed, Sep 19, 2012 at 10:51:25AM -0400, wrote:
>> From: Eric Millbrandt <emillbrandt@dekaresearch.com>
>>
>> mpc52xx socs need to define SND_POWERPC_SOC to build ASoC drivers.
>>
>> Signed-off-by: Eric Millbrandt <emillbrandt@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 t=
o whom it is addressed and may contain information that is privileged. If t=
he reader of this message is not the intended recipient, you are hereby not=
ified 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.
^ permalink raw reply
* Re: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
From: Scott Wood @ 2012-09-20 0:12 UTC (permalink / raw)
To: Kumar Gala
Cc: joerg.roedel, linux-kernel, iommu, <b16395@freescale.com>,
Varun Sethi, linuxppc-dev
In-Reply-To: <6B8A3365-C97E-4742-A0DD-D8FD6BA358EB@kernel.crashing.org>
On 09/19/2012 08:52:27 AM, Kumar Gala wrote:
>=20
> On Sep 19, 2012, at 8:17 AM, <b16395@freescale.com> =20
> <b16395@freescale.com> wrote:
>=20
> > From: Varun Sethi <Varun.Sethi@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.Sethi@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 =20
> mapped */
> > dma_addr_t aperture_end; /* Last address that can be =20
> mapped */
> > bool force_aperture; /* DMA only allowed in mappable =20
> range? */
> > +
> > + /* The subwindows field indicates number of DMA subwindows =20
> 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 =20
> subwindows
> > + * being =3D 1MB/4KB =3D 256.
> > + * 1 : Only one DMA window i.e. no subwindows.
> > + * value other than 0 or 1 would indicate actual number of =20
> 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 */
>=20
> seems like this should be enum instead of u32 for cache
>=20
> With enum being something like:
>=20
> 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 =20
case they need to use fixed size types.
-Scott=
^ permalink raw reply
* Re: [RFC][PATCH 0/3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Scott Wood @ 2012-09-20 0:14 UTC (permalink / raw)
To: Kumar Gala
Cc: joerg.roedel, linux-kernel, iommu, <b16395@freescale.com>,
Varun Sethi, linuxppc-dev
In-Reply-To: <A6B66C5D-71EA-4E9F-8347-7413479BD3FC@kernel.crashing.org>
On 09/19/2012 08:49:14 AM, Kumar Gala wrote:
>=20
> On Sep 19, 2012, at 8:17 AM, <b16395@freescale.com> =20
> <b16395@freescale.com> wrote:
>=20
> > From: Varun Sethi <Varun.Sethi@freescale.com>
> >
> > This patchset provides the Freescale PAMU (Peripheral Access =20
> Management Unit) driver
> > and the corresponding IOMMU API implementation. PAMU is the IOMMU =20
> present on Freescale
> > QorIQ platforms. PAMU can authorize memory access, remap the memory =20
> 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 =20
> for storing iommu domain information
> > pointer. This pointer is stored when the device is attached to a =20
> particular iommu domain.
> > 2. Addition of domain attributes required by the PAMU driver IOMMU =20
> 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 =20
> +++++++++++++++++++++++++++++++++++++
> > drivers/iommu/fsl_pamu.h | 377 ++++++++++++++
> > drivers/iommu/fsl_pamu_domain.c | 990 =20
> +++++++++++++++++++++++++++++++++++
> > 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
>=20
> I assume that another patch series will add device tree binding spec =20
> and update device trees for SoCs with PAMU?
The device trees already have PAMU in them. A binding would be nice, =20
though.
-Scott=
^ permalink raw reply
* Re: [PATCH v2 1/7] ASoC: fsl: add PPC_MPC52xx dependency to SND_POWERPC_SOC
From: Mark Brown @ 2012-09-20 1:30 UTC (permalink / raw)
To: Eric Millbrandt
Cc: alsa-devel@alsa-project.org, linuxppc-dev@lists.ozlabs.org,
Liam Girdwood
In-Reply-To: <0A40042D85E7C84DB443060EC44B3FD3459868BAC0@dekaexchange07.deka.local>
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.
^ permalink raw reply
* Re: [PATCH] powerpc-kvm: fixing page alignment for TCE
From: Alexander Graf @ 2012-09-20 9:01 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Paul Mackerras, linuxppc-dev, kvm-ppc, David Gibson
In-Reply-To: <1346744187-31226-1-git-send-email-aik@ozlabs.ru>
On 04.09.2012, at 09:36, Alexey Kardashevskiy wrote:
> From: Paul Mackerras <paulus@samba.org>
>=20
> TODO: ask Paul to make a proper message.
TODO?
Also, Ben or Paul, please ack if you think it's correct.
Alex
>=20
> This is the fix for a host kernel compiled with a page size
> other than 4K (TCE page size). In the case of a 64K page size,
> the host used to lose address bits in hpte_rpn().
> The patch fixes it.
>=20
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c =
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index 80a5775..a41f11b 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -503,7 +503,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run =
*run, struct kvm_vcpu *vcpu,
> struct kvm *kvm =3D vcpu->kvm;
> unsigned long *hptep, hpte[3], r;
> unsigned long mmu_seq, psize, pte_size;
> - unsigned long gfn, hva, pfn;
> + unsigned long gpa, gfn, hva, pfn;
> struct kvm_memory_slot *memslot;
> unsigned long *rmap;
> struct revmap_entry *rev;
> @@ -541,15 +541,14 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run =
*run, struct kvm_vcpu *vcpu,
>=20
> /* Translate the logical address and get the page */
> psize =3D hpte_page_size(hpte[0], r);
> - gfn =3D hpte_rpn(r, psize);
> + gpa =3D (r & HPTE_R_RPN & ~(psize - 1)) | (ea & (psize - 1));
> + gfn =3D gpa >> PAGE_SHIFT;
> memslot =3D gfn_to_memslot(kvm, gfn);
>=20
> /* No memslot means it's an emulated MMIO region */
> - if (!memslot || (memslot->flags & KVM_MEMSLOT_INVALID)) {
> - unsigned long gpa =3D (gfn << PAGE_SHIFT) | (ea & (psize =
- 1));
> + if (!memslot || (memslot->flags & KVM_MEMSLOT_INVALID))
> return kvmppc_hv_emulate_mmio(run, vcpu, gpa, ea,
> dsisr & DSISR_ISSTORE);
> - }
>=20
> if (!kvm->arch.using_mmu_notifiers)
> return -EFAULT; /* should never get here */
> --=20
> 1.7.10.4
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
From: Sethi Varun-B16395 @ 2012-09-20 9:46 UTC (permalink / raw)
To: Wood Scott-B07421, Kumar Gala
Cc: joerg.roedel@amd.com, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1348099936.22800.21@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, September 20, 2012 5:42 AM
> To: Kumar Gala
> Cc: Sethi Varun-B16395; joerg.roedel@amd.com; iommu@lists.linux-
> foundation.org; linuxppc-dev@lists.ozlabs.org; linux-
> kernel@vger.kernel.org; Sethi Varun-B16395
> Subject: Re: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes
> required by fsl PAMU driver.
>=20
> On 09/19/2012 08:52:27 AM, Kumar Gala wrote:
> >
> > On Sep 19, 2012, at 8:17 AM, <b16395@freescale.com>
> > <b16395@freescale.com> wrote:
> >
> > > From: Varun Sethi <Varun.Sethi@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.Sethi@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 =3D 1MB/4KB =3D 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,
> > };
>=20
> Don't we want these structs to be usable via some VFIO ioctl? In that
> case they need to use fixed size types.
>=20
Yes, this would be usable via vfio ioctl. But, then the caller should be
aware of supported stash targets. May be I should add an interface for the =
caller,
to query supported stash targets.
-Varun
^ permalink raw reply
* RE: [PATCH][v2] powerpc/mm: using two zones for freescale 64 bit kernel
From: Xie Shaohui-B21989 @ 2012-09-20 10:14 UTC (permalink / raw)
To: Xie Shaohui-B21989, Benjamin Herrenschmidt, Kumar Gala
Cc: Hu Mingkai-B21284, linuxppc-dev@lists.ozlabs.org list,
Chen Yuanquan-B41889
In-Reply-To: <1347233868.2385.128.camel@pasglop>
PiA+IE9uIFRodSwgMjAxMi0wOC0zMCBhdCAxNTo0OSAtMDUwMCwgS3VtYXIgR2FsYSB3cm90ZToN
Cj4gPiA+IE9uIEF1ZyAyNCwgMjAxMiwgYXQgNTo1MCBBTSwgU2hhb2h1aSBYaWUgd3JvdGU6DQo+
ID4gPg0KPiA+ID4gPiBQb3dlclBDIHBsYXRmb3JtIG9ubHkgc3VwcG9ydHMgWk9ORV9ETUEgem9u
ZSBmb3IgNjRiaXQga2VybmVsLCBzbw0KPiA+ID4gPiBhbGwgdGhlIG1lbW9yeSB3aWxsIGJlIHB1
dCBpbnRvIHRoaXMgem9uZS4gSWYgdGhlIG1lbW9yeSBzaXplIGlzDQo+ID4gPiA+IGdyZWF0ZXIg
dGhhbiB0aGUgZGV2aWNlJ3MgRE1BIGNhcGFiaWxpdHkgYW5kIGRldmljZSB1c2VzDQo+ID4gPiA+
IGRtYV9hbGxvY19jb2hlcmVudCB0byBhbGxvY2F0ZSBtZW1vcnksIGl0IHdpbGwgZ2V0IGFuIGFk
ZHJlc3MNCj4gPiA+ID4gd2hpY2ggaXMgb3ZlciB0aGUgZGV2aWNlJ3MgRE1BIGFkZHJlc3Npbmcs
IHRoZSBkZXZpY2Ugd2lsbCBmYWlsLg0KPiA+ID4gPg0KPiA+ID4gPiBTbyB3ZSBzcGxpdCB0aGUg
bWVtb3J5IHRvIHR3byB6b25lczogem9uZSBaT05FX0RNQTMyICYNCj4gPiA+ID4gWk9ORV9OT1JN
QUwsIHNpbmNlIHdlIGFscmVhZHkgYWxsb2NhdGUgUENJQ1NSQkFSL1BFWENTUkJBUiByaWdodA0K
PiA+ID4gPiBiZWxvdyB0aGUgNEcgYm91bmRhcnkgKGlmIHRoZSBsb3dlc3QgUENJIGFkZHJlc3Mg
aXMgYWJvdmUgNEcpLCBzbw0KPiA+ID4gPiB3ZSBjb25zdHJhaW4gdGhlIERNQSB6b25lIFpPTkVf
RE1BMzIgdG8gMkdCLCBhbHNvLCB3ZSBjbGVhciBmbGFnDQo+ID4gPiA+IF9fR0ZQX0RNQSAmDQo+
ID4gPiA+IF9fR0ZQX0RNQTMyIGFuZCBzZXQgX19HRlBfRE1BMzIgb25seSBpZiB0aGUgZGV2aWNl
J3MgZG1hX21hc2sgPA0KPiA+ID4gPiB0b3RhbCBtZW1vcnkgc2l6ZS4gQnkgZG9pbmcgdGhpcywg
ZGV2aWNlcyB3aGljaCBjYW5ub3QgRE1BIGFsbCB0aGUNCj4gPiA+ID4gbWVtb3J5IHdpbGwgYmUg
bGltaXRlZCB0byBaT05FX0RNQTMyLCBidXQgZGV2aWNlcyB3aGljaCBjYW4gRE1BDQo+ID4gPiA+
IGFsbA0KPiA+IHRoZSBtZW1vcnkgd2lsbCBub3QgYmUgYWZmZWN0ZWQgYnkgdGhpcyBsaW1pdGF0
aW9uLg0KPiA+ID4gPg0KPiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBTaGFvaHVpIFhpZSA8U2hhb2h1
aS5YaWVAZnJlZXNjYWxlLmNvbT4NCj4gPiA+ID4gU2lnbmVkLW9mZi1ieTogTWluZ2thaSBIdSA8
TWluZ2thaS5odUBmcmVlc2NhbGUuY29tPg0KPiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBDaGVuIFl1
YW5xdWFuIDxCNDE4ODlAZnJlZXNjYWxlLmNvbT4NCj4gPiA+ID4gLS0tDQo+ID4gPiA+IGNoYW5n
ZXMgZm9yIHYyOg0KPiA+ID4gPiAxLiB1c2UgYSBjb25maWcgb3B0aW9uIGZvciB1c2luZyB0d28g
em9uZXMgKFpPTkVfRE1BMzIgJg0KPiA+ID4gPiBaT05FX05PUk1BTCkgaW4gZnJlZXNjYWxlIDY0
IGJpdCBrZXJuZWwuDQo+ID4gPiA+DQo+ID4NCj4gPiBUaGVyZSBtdXN0IGhhdmUgYmVlbiBhIG1p
c3VuZGVyc3RhbmRpbmcuIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgYQ0KPiA+IHJ1bnRpbWUgY2hv
aWNlLCBwb3NzaWJseSBieSB0aGUgcGxhdGZvcm0gY29kZS4gQW55IHJlYXNvbiB0aGF0IGNhbid0
IGJlDQo+IGRvbmUgPw0KPiA+DQo+IFtTLkhdIERvIHlvdSBtZWFuIHRoaXM6DQo+IA0KPiBwaHlz
X2FkZHJfdCBwbGF0Zm9ybV9kbWFfc2l6ZSAobWF5YmUgYSBkZWZhdWx0IHZhbHVlIHNob3VsZCBi
ZSB1c2VkLCB0aGVuDQo+IHBsYXRmb3JtIGNvZGUgd2lsbCBjaGFuZ2UgaXQpDQo+IA0KPiBpZiAo
dG9wX29mX3JhbSA+IHBsYXRmb3JtX2RtYV9zaXplKQ0KPiAJbWF4X3pvbmVfcGZuc1taT05FX0RN
QV0gPSBwbGF0Zm9ybV9kbWFfc2l6ZSA+PiBQQUdFX1NISUZUOyBlbHNlDQo+IAltYXhfem9uZV9w
Zm5zW1pPTkVfRE1BXSA9IHRvcF9vZl9yYW0gPj4gUEFHRV9TSElGVDsNCj4gDQo+IG1heF96b25l
X3BmbnNbWk9ORV9OT1JNQUxdID0gdG9wX29mX3JhbSA+PiBQQUdFX1NISUZUOw0KPiANCj4gPiBB
bHNvIGhvdyBkb2VzIEludGVsIGRvIGl0ID8NCj4gW1MuSF0gYmVsb3cgYXJlIGNvZGVzIGluIElu
dGVsOg0KPiANCj4gNDAzIHZvaWQgX19pbml0IHpvbmVfc2l6ZXNfaW5pdCh2b2lkKQ0KPiA0MDQg
ew0KPiA0MDUgICAgICAgICB1bnNpZ25lZCBsb25nIG1heF96b25lX3BmbnNbTUFYX05SX1pPTkVT
XTsNCj4gNDA2DQo+IDQwNyAgICAgICAgIG1lbXNldChtYXhfem9uZV9wZm5zLCAwLCBzaXplb2Yo
bWF4X3pvbmVfcGZucykpOw0KPiA0MDgNCj4gNDA5ICNpZmRlZiBDT05GSUdfWk9ORV9ETUENCj4g
NDEwICAgICAgICAgbWF4X3pvbmVfcGZuc1taT05FX0RNQV0gICAgICAgICA9IE1BWF9ETUFfUEZO
Ow0KPiA0MTEgI2VuZGlmDQo+IDQxMiAjaWZkZWYgQ09ORklHX1pPTkVfRE1BMzINCj4gNDEzICAg
ICAgICAgbWF4X3pvbmVfcGZuc1taT05FX0RNQTMyXSAgICAgICA9IE1BWF9ETUEzMl9QRk47DQo+
IDQxNCAjZW5kaWYNCj4gNDE1ICAgICAgICAgbWF4X3pvbmVfcGZuc1taT05FX05PUk1BTF0gICAg
ICA9IG1heF9sb3dfcGZuOw0KPiA0MTYgI2lmZGVmIENPTkZJR19ISUdITUVNDQo+IDQxNyAgICAg
ICAgIG1heF96b25lX3BmbnNbWk9ORV9ISUdITUVNXSAgICAgPSBtYXhfcGZuOw0KPiA0MTggI2Vu
ZGlmDQo+IDQxOQ0KPiANCj4gRm9yIHg4Nl82NCwgdGhlcmUgaXMgbm8gQ09ORklHX0hJR0hNRU0s
IHNvIHRoZXJlIHdpbGwgYmUgdGhyZWUgem9uZXM6DQo+IFpPTkVfRE1BL1pPTkVfRE1BMzIvWk9O
RV9OT1JNQUwuDQo+IA0KW1MuSF0gSGVsbG8sIEJlbiwNCg0KSSBoYXZlIHNvbWUgcXVlc3Rpb25z
LCB0aG91Z2ggSSdtIHN0aWxsIGV4cGVjdGluZyB5b3VyIGNvbW1lbnRzLg0KUFBDIGRvZXMgbm90
IGhhdmUgWk9ORV9ETUEzMiBieSBkZWZhdWx0LCBpZiB3ZSB3YW50IHRvIHVzZSBpdCwgd2UgbmVl
ZCB0byBhZGQgImNvbmZpZyBaT05FX0RNQTMyIiBpbiBLY29uZmlnIGZpcnN0Lg0KSWYgc2V0dGlu
ZyBtdWx0aXBsZSB6b25lcyB3aXRob3V0IFpPTkVfRE1BLCBrbWFsbG9jIGluICJpbmNsdWRlL2xp
bnV4L3NsYWJfZGVmLmgiIHdpbGwgZmFpbCBpZiBpdCB1c2VzIGZsYWcgR0ZQX0RNQS4NCkZvciB0
aGUgcnVudGltZSBjaG9pY2UgaW4gNjQtYml0IGtlcm5lbCwgd2hhdCBleGFjdGx5IG11bHRpcGxl
IHpvbmVzIHNob3VsZCBiZSB1c2VkPw0KIlpPTkVfRE1BICYgWk9ORV9OT1JNQUwiIG9yICJaT05F
X0RNQSAmIFpPTkVfRE1BMzIgJiBaT05FX05PUk1BTCI/DQpUaGVuIHdoYXQgdGhlIHNpemUgc2hv
dWxkIGJlIHNldCBmb3IgdGhlbSByZXNwZWN0aXZlbHk/DQoNClBsZWFzZSBjb21tZW50LCBUaGFu
a3MhDQoNCg0KQmVzdCBSZWdhcmRzLCANClNoYW9odWkgWGllDQo=
^ permalink raw reply
* Re: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
From: Kumar Gala @ 2012-09-20 13:19 UTC (permalink / raw)
To: Sethi Varun-B16395
Cc: Wood Scott-B07421, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
joerg.roedel@amd.com
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D1A49A2@039-SN2MPN1-013.039d.mgd.msft.net>
On Sep 20, 2012, at 4:46 AM, Sethi Varun-B16395 wrote:
>=20
>=20
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Thursday, September 20, 2012 5:42 AM
>> To: Kumar Gala
>> Cc: Sethi Varun-B16395; joerg.roedel@amd.com; iommu@lists.linux-
>> foundation.org; linuxppc-dev@lists.ozlabs.org; linux-
>> kernel@vger.kernel.org; Sethi Varun-B16395
>> Subject: Re: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes
>> required by fsl PAMU driver.
>>=20
>> On 09/19/2012 08:52:27 AM, Kumar Gala wrote:
>>>=20
>>> On Sep 19, 2012, at 8:17 AM, <b16395@freescale.com>
>>> <b16395@freescale.com> wrote:
>>>=20
>>>> From: Varun Sethi <Varun.Sethi@freescale.com>
>>>>=20
>>>> 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.
>>>>=20
>>>> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
>>>> ---
>>>> include/linux/iommu.h | 30 ++++++++++++++++++++++++++++++
>>>> 1 files changed, 30 insertions(+), 0 deletions(-)
>>>>=20
>>>> 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 =3D 1MB/4KB =3D 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 */
>>>=20
>>> seems like this should be enum instead of u32 for cache
>>>=20
>>> With enum being something like:
>>>=20
>>> enum iommu_attr_stash_cache {
>>> IOMMU_ATTR_CACHE_L1,
>>> IOMMU_ATTR_CACHE_L2,
>>> IOMMU_ATTR_CACHE_L3,
>>> };
>>=20
>> Don't we want these structs to be usable via some VFIO ioctl? In =
that
>> case they need to use fixed size types.
>>=20
> Yes, this would be usable via vfio ioctl. But, then the caller should =
be
> aware of supported stash targets. May be I should add an interface for =
the caller,
> to query supported stash targets.
Guess the caller probably knows, but thinking we should move the =
#defines for valid values into this file out of pamu specific files.
- k=
^ permalink raw reply
* Re: [PATCH][v2] powerpc/mm: using two zones for freescale 64 bit kernel
From: Kumar Gala @ 2012-09-20 13:36 UTC (permalink / raw)
To: Xie Shaohui-B21989
Cc: Hu Mingkai-B21284, linuxppc-dev@lists.ozlabs.org list,
Chen Yuanquan-B41889
In-Reply-To: <ED492CCEAF882048BC2237DE806547C9079ED987@039-SN2MPN1-013.039d.mgd.msft.net>
On Sep 20, 2012, at 5:14 AM, Xie Shaohui-B21989 wrote:
>>> On Thu, 2012-08-30 at 15:49 -0500, Kumar Gala wrote:
>>>> On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
>>>>=20
>>>>> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so
>>>>> all the memory will be put into this zone. If the memory size is
>>>>> greater than the device's DMA capability and device uses
>>>>> dma_alloc_coherent to allocate memory, it will get an address
>>>>> which is over the device's DMA addressing, the device will fail.
>>>>>=20
>>>>> So we split the memory to two zones: zone ZONE_DMA32 &
>>>>> ZONE_NORMAL, since we already allocate PCICSRBAR/PEXCSRBAR right
>>>>> below the 4G boundary (if the lowest PCI address is above 4G), so
>>>>> we constrain the DMA zone ZONE_DMA32 to 2GB, also, we clear flag
>>>>> __GFP_DMA &
>>>>> __GFP_DMA32 and set __GFP_DMA32 only if the device's dma_mask <
>>>>> total memory size. By doing this, devices which cannot DMA all the
>>>>> memory will be limited to ZONE_DMA32, but devices which can DMA
>>>>> all
>>> the memory will not be affected by this limitation.
>>>>>=20
>>>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>>>> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
>>>>> Signed-off-by: Chen Yuanquan <B41889@freescale.com>
>>>>> ---
>>>>> changes for v2:
>>>>> 1. use a config option for using two zones (ZONE_DMA32 &
>>>>> ZONE_NORMAL) in freescale 64 bit kernel.
>>>>>=20
>>>=20
>>> There must have been a misunderstanding. I think this should be a
>>> runtime choice, possibly by the platform code. Any reason that can't =
be
>> done ?
>>>=20
>> [S.H] Do you mean this:
>>=20
>> phys_addr_t platform_dma_size (maybe a default value should be used, =
then
>> platform code will change it)
>>=20
>> if (top_of_ram > platform_dma_size)
>> max_zone_pfns[ZONE_DMA] =3D platform_dma_size >> PAGE_SHIFT; =
else
>> max_zone_pfns[ZONE_DMA] =3D top_of_ram >> PAGE_SHIFT;
>>=20
>> max_zone_pfns[ZONE_NORMAL] =3D top_of_ram >> PAGE_SHIFT;
>>=20
>>> Also how does Intel do it ?
>> [S.H] below are codes in Intel:
>>=20
>> 403 void __init zone_sizes_init(void)
>> 404 {
>> 405 unsigned long max_zone_pfns[MAX_NR_ZONES];
>> 406
>> 407 memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
>> 408
>> 409 #ifdef CONFIG_ZONE_DMA
>> 410 max_zone_pfns[ZONE_DMA] =3D MAX_DMA_PFN;
>> 411 #endif
>> 412 #ifdef CONFIG_ZONE_DMA32
>> 413 max_zone_pfns[ZONE_DMA32] =3D MAX_DMA32_PFN;
>> 414 #endif
>> 415 max_zone_pfns[ZONE_NORMAL] =3D max_low_pfn;
>> 416 #ifdef CONFIG_HIGHMEM
>> 417 max_zone_pfns[ZONE_HIGHMEM] =3D max_pfn;
>> 418 #endif
>> 419
>>=20
>> For x86_64, there is no CONFIG_HIGHMEM, so there will be three zones:
>> ZONE_DMA/ZONE_DMA32/ZONE_NORMAL.
>>=20
> [S.H] Hello, Ben,
>=20
> I have some questions, though I'm still expecting your comments.
> PPC does not have ZONE_DMA32 by default, if we want to use it, we need =
to add "config ZONE_DMA32" in Kconfig first.
> If setting multiple zones without ZONE_DMA, kmalloc in =
"include/linux/slab_def.h" will fail if it uses flag GFP_DMA.
> For the runtime choice in 64-bit kernel, what exactly multiple zones =
should be used?
> "ZONE_DMA & ZONE_NORMAL" or "ZONE_DMA & ZONE_DMA32 & ZONE_NORMAL"?
> Then what the size should be set for them respectively?
>=20
> Please comment, Thanks!
I think Ben is saying that Kconfig would enable ZONE_DMA32 for all =
PPC64, but make it runtime/per platform how we setup the zone's such =
that either ZONE_DMA32 is set to MAX_DMA32_PFN or it set to same value =
as ZONE_DMA.
However that's just a guess.
- k=
^ permalink raw reply
* [PATCH v2 1/3] ASoC: fsl: add PPC_MPC52xx dependency to SND_POWERPC_SOC
From: Eric Millbrandt @ 2012-09-20 14:36 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Grant Likely
Cc: alsa-devel, linuxppc-dev, Eric Millbrandt
mpc52xx socs do not define FSL_SOC but need SND_POWERPC_SOC defined to build
ASoC drivers.
Signed-off-by: Eric Millbrandt <emillbrandt@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
^ permalink raw reply related
* [PATCH 2/3] ASoC: fsl: pcm030-audio-fabric use snd_soc_register_card
From: Eric Millbrandt @ 2012-09-20 14:36 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Grant Likely
Cc: alsa-devel, linuxppc-dev, Eric Millbrandt
In-Reply-To: <1348151805-93991-1-git-send-email-emillbrandt@dekaresearch.com>
Convert pcm030-audio-fabric to use the new snd_soc_register_card api
instead of the older method of registering a separate platform device.
Create the dai_link to the mpc5200_psc_ac97 platform using the device tree.
Convert the pcm030-audio-fabric driver to a platform-driver and add a
remove function.
Signed-off-by: Eric Millbrandt <emillbrandt@dekaresearch.com>
---
sound/soc/fsl/pcm030-audio-fabric.c | 65 +++++++++++++++++++++++++----------
1 files changed, 47 insertions(+), 18 deletions(-)
diff --git a/sound/soc/fsl/pcm030-audio-fabric.c b/sound/soc/fsl/pcm030-audio-fabric.c
index 1353e8f..893e240 100644
--- a/sound/soc/fsl/pcm030-audio-fabric.c
+++ b/sound/soc/fsl/pcm030-audio-fabric.c
@@ -28,7 +28,6 @@ static struct snd_soc_dai_link pcm030_fabric_dai[] = {
.stream_name = "AC97 Analog",
.codec_dai_name = "wm9712-hifi",
.cpu_dai_name = "mpc5200-psc-ac97.0",
- .platform_name = "mpc5200-pcm-audio",
.codec_name = "wm9712-codec",
},
{
@@ -36,44 +35,74 @@ static struct snd_soc_dai_link pcm030_fabric_dai[] = {
.stream_name = "AC97 IEC958",
.codec_dai_name = "wm9712-aux",
.cpu_dai_name = "mpc5200-psc-ac97.1",
- .platform_name = "mpc5200-pcm-audio",
.codec_name = "wm9712-codec",
},
};
-static struct snd_soc_card card = {
+static struct snd_soc_card pcm030_card = {
.name = "pcm030",
.owner = THIS_MODULE,
.dai_link = pcm030_fabric_dai,
.num_links = ARRAY_SIZE(pcm030_fabric_dai),
};
-static __init int pcm030_fabric_init(void)
+static int __init pcm030_fabric_probe(struct platform_device *op)
{
- struct platform_device *pdev;
- int rc;
+ struct device_node *np = op->dev.of_node;
+ struct device_node *platform_np;
+ struct snd_soc_card *card = &pcm030_card;
+ int ret;
+ int i;
if (!of_machine_is_compatible("phytec,pcm030"))
return -ENODEV;
- pdev = platform_device_alloc("soc-audio", 1);
- if (!pdev) {
- pr_err("pcm030_fabric_init: platform_device_alloc() failed\n");
+ card->dev = &op->dev;
+ platform_set_drvdata(op, card);
+
+ platform_np = of_parse_phandle(np, "asoc-platform", 0);
+ if (!platform_np) {
+ dev_err(&op->dev, "ac97 not registered\n");
return -ENODEV;
}
- platform_set_drvdata(pdev, &card);
+ for (i = 0; i < card->num_links; i++)
+ card->dai_link[i].platform_of_node = platform_np;
- rc = platform_device_add(pdev);
- if (rc) {
- pr_err("pcm030_fabric_init: platform_device_add() failed\n");
- platform_device_put(pdev);
- return -ENODEV;
- }
- return 0;
+ ret = snd_soc_register_card(card);
+ if (ret)
+ dev_err(&op->dev, "snd_soc_register_card() failed: %d\n", ret);
+
+ return ret;
}
-module_init(pcm030_fabric_init);
+static int __devexit pcm030_fabric_remove(struct platform_device *op)
+{
+ struct snd_soc_card *card = platform_get_drvdata(op);
+ int ret;
+
+ ret = snd_soc_unregister_card(card);
+
+ return ret;
+}
+
+static struct of_device_id pcm030_audio_match[] = {
+ { .compatible = "phytec,pcm030-audio-fabric", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, pcm030_audio_match);
+
+static struct platform_driver pcm030_fabric_driver = {
+ .probe = pcm030_fabric_probe,
+ .remove = __devexit_p(pcm030_fabric_remove),
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = pcm030_audio_match,
+ },
+};
+
+module_platform_driver(pcm030_fabric_driver);
MODULE_AUTHOR("Jon Smirl <jonsmirl@gmail.com>");
--
1.7.2.5
^ permalink raw reply related
* [PATCH 3/3] ASoC: fsl: register the wm9712-codec
From: Eric Millbrandt @ 2012-09-20 14:36 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Grant Likely
Cc: alsa-devel, linuxppc-dev, Eric Millbrandt
In-Reply-To: <1348151805-93991-1-git-send-email-emillbrandt@dekaresearch.com>
The mpc5200-psc-ac97 driver does not enumerate attached ac97 devices, so
register the device here.
Signed-off-by: Eric Millbrandt <emillbrandt@dekaresearch.com>
---
sound/soc/fsl/pcm030-audio-fabric.c | 32 +++++++++++++++++++++++++++++---
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/pcm030-audio-fabric.c b/sound/soc/fsl/pcm030-audio-fabric.c
index 893e240..4b63ec8 100644
--- a/sound/soc/fsl/pcm030-audio-fabric.c
+++ b/sound/soc/fsl/pcm030-audio-fabric.c
@@ -22,6 +22,11 @@
#define DRV_NAME "pcm030-audio-fabric"
+struct pcm030_audio_data {
+ struct snd_soc_card *card;
+ struct platform_device *codec_device;
+};
+
static struct snd_soc_dai_link pcm030_fabric_dai[] = {
{
.name = "AC97",
@@ -51,14 +56,22 @@ static int __init pcm030_fabric_probe(struct platform_device *op)
struct device_node *np = op->dev.of_node;
struct device_node *platform_np;
struct snd_soc_card *card = &pcm030_card;
+ struct pcm030_audio_data *pdata;
int ret;
int i;
if (!of_machine_is_compatible("phytec,pcm030"))
return -ENODEV;
+ pdata = devm_kzalloc(&op->dev, sizeof(struct pcm030_audio_data),
+ GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
card->dev = &op->dev;
- platform_set_drvdata(op, card);
+ platform_set_drvdata(op, pdata);
+
+ pdata->card = card;
platform_np = of_parse_phandle(np, "asoc-platform", 0);
if (!platform_np) {
@@ -69,6 +82,18 @@ static int __init pcm030_fabric_probe(struct platform_device *op)
for (i = 0; i < card->num_links; i++)
card->dai_link[i].platform_of_node = platform_np;
+ ret = request_module("snd-soc-wm9712");
+ if (ret)
+ dev_err(&op->dev, "request_module returned: %d\n", ret);
+
+ pdata->codec_device = platform_device_alloc("wm9712-codec", -1);
+ if (!pdata->codec_device)
+ dev_err(&op->dev, "platform_device_alloc() failed\n");
+
+ ret = platform_device_add(pdata->codec_device);
+ if (ret)
+ dev_err(&op->dev, "platform_device_add() failed: %d\n", ret);
+
ret = snd_soc_register_card(card);
if (ret)
dev_err(&op->dev, "snd_soc_register_card() failed: %d\n", ret);
@@ -78,10 +103,11 @@ static int __init pcm030_fabric_probe(struct platform_device *op)
static int __devexit pcm030_fabric_remove(struct platform_device *op)
{
- struct snd_soc_card *card = platform_get_drvdata(op);
+ struct pcm030_audio_data *pdata = platform_get_drvdata(op);
int ret;
- ret = snd_soc_unregister_card(card);
+ ret = snd_soc_unregister_card(pdata->card);
+ platform_device_unregister(pdata->codec_device);
return ret;
}
--
1.7.2.5
^ permalink raw reply related
* Deprecating reserve-map in favor of properties
From: Benjamin Herrenschmidt @ 2012-09-20 22:10 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev
Hi folks !
The reserve map is, imho, my biggest mistake when coming up with the FDT
format.
The main problem is that it doesn't survive the transition via a real
Open Firmware interface. There is no practical way to indicate reserved
regions of memory accross in that case, unless you have an OS that is
nice enough to try to keep OF alive and accomodate its advertised
"available" properties, but that's typically not the case of Linux on
ppc.
So I would like to propose that we add a new "better" way to convey
reserved memory information, via properties in the tree.
I originally though of having these in the "memory" nodes themselves but
this can be tricky on machines that have multiple nodes (ie, NUMA
generally means a memory node per NUMA node) since the reserved regions
can spawn accross nodes and I don't want to complicate FW life too much
by requiring breaking them up in that case.
So what about something at the root of the tree:
reserved-ranges: An array of ranges of reserved memory
reserved-names: A list of zero terminated strings, one for each entry in
the reserved-ranges array, providing optional "names" for the reserved
ranges.
The idea here is that we could have well defined names (using a similar
prefix we use for properties) such as linux,initrd, which indicates
clearly to the kernel that the only reason that range is reserved is
because it contains an initrd (ie, it can be freed once that's been
extracted).
It would also be generally handy in case a reserved area is meant to be
used by a specific driver, such as an in-memory framebuffer
pre-initialized by the firmware. The generic memory management code
doesn't need to know, but later on, the gfx driver can pick it up easily
provided the name is part of the binding for that device.
Any objection ? If none, I'll cook up a patch to add support for it (at
least on powerpc :-)
Cheers,
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox