RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

2012-09-20 Thread Jia Hongtao-B38951 


> -Original Message-
> From: Li Yang-R58472
> Sent: Friday, September 21, 2012 11:51 AM
> To: Jia Hongtao-B38951; Kumar Gala
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421
> Subject: RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
> support
> 
> 
> 
> > -Original Message-
> > From: Jia Hongtao-B38951
> > Sent: Friday, September 21, 2012 11:14 AM
> > To: Kumar Gala
> > 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
> >
> >
> >
> > > -Original Message-
> > > From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> > > Sent: Wednesday, September 19, 2012 11:49 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.
> > >
> > > Are you seeing the following message - "PCI: I/O resource not set
> > > for host bridge" ?
> >
> > No.
> >
> > >
> > > Trying to understand why you'd hit the reassignment of io_resource.
> > >
> > > - k
> > >
> >
> > I did some investigations and the conclusion is:
> >
> > io_resource.flags & IORESOURCE_IO are both positive but
> > io_resource.start is 0 before pcibios_setup_phb_io_space() is done.
> >
> > The sequence of related process listed below:
> > fsl_add_bridge() -> setup_pci_atmu()
> > pcibios_init() -> pcibios_scan_phb() -> pcibios_setup_phb_io_space()
> >
> > Because fsl_add_bridge() must be finished before pcibios_init() so
> > ATMU is set when io_resource.start is 0. That means outbound IO regs
> > are not set.
> >
> > If system re-setup ATMU the io_resource.start has already updated so
> > outbound IO regs are set.
> >
> > My question is:
> > Is there any problem if outbound IO regs are not set in first bootup?
> 
> Please also provide the IO resource address range before and after the
> pci scan.  Then we can evaluate if the range is needed to be mapped via
> ATMU.
> 
> Leo

Since potar is set by out_be32(&pci->pow[j].potar, (hose->io_resource.start >> 
12);
I provide the result of hose->io_resource.start >> 12 as follows:

pcie@ffe09000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7ed

pcie@ffe0a000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7db

pcie@ffe0b000:
before pci scan: io_resource.start >> 12: 0
after pci scan : io_resource.start >> 12: ff7c9

Note that I tested on P1022DS.

- 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

2012-09-20 Thread Li Yang-R58472 


> -Original Message-
> From: Jia Hongtao-B38951
> Sent: Friday, September 21, 2012 11:14 AM
> To: Kumar Gala
> 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
> 
> 
> 
> > -Original Message-
> > From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> > Sent: Wednesday, September 19, 2012 11:49 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.
> >
> > Are you seeing the following message - "PCI: I/O resource not set for
> > host bridge" ?
> 
> No.
> 
> >
> > Trying to understand why you'd hit the reassignment of io_resource.
> >
> > - k
> >
> 
> I did some investigations and the conclusion is:
> 
> io_resource.flags & IORESOURCE_IO are both positive but io_resource.start
> is 0 before pcibios_setup_phb_io_space() is done.
> 
> The sequence of related process listed below:
> fsl_add_bridge() -> setup_pci_atmu()
> pcibios_init() -> pcibios_scan_phb() -> pcibios_setup_phb_io_space()
> 
> Because fsl_add_bridge() must be finished before pcibios_init() so ATMU
> is set when io_resource.start is 0. That means outbound IO regs are not
> set.
> 
> If system re-setup ATMU the io_resource.start has already updated so
> outbound IO regs are set.
> 
> My question is:
> Is there any problem if outbound IO regs are not set in first bootup?

Please also provide the IO resource address range before and after the pci 
scan.  Then we can evaluate if the range is needed to be mapped via ATMU.

Leo

___
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

2012-09-20 Thread Lian Minghaun-b31939 

Hi Kumar,

please see my comments inline.


On 09/19/2012 10:22 PM, Kumar Gala wrote:

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.

[Minghuan] Thanks for you pointing this.
I want to move setup_pci_cmd like this:

pr_debug(" ->Hose at 0x%p, cfg_addr=0x%p,cfg_data=0x%p\n",
hose, hose->cfg_addr, hose->cfg_data);

+setup_pci_cmd(hose);

/* Interpret the "ranges" property */
/* This also maps the I/O region and sets isa_io/mem_base */
pci_process_bridge_OF_ranges(hose, dev, is_primary);

This movement will cause fsl_pcie_check_link() calling before 
setup_pci_cmd().

Is this ok?
If not, I will call setup_pci_cmd() for PCI and PCIE respectively.


/* 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/linu

RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support

2012-09-20 Thread Jia Hongtao-B38951 


> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Wednesday, September 19, 2012 11:49 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.
> 
> Are you seeing the following message - "PCI: I/O resource not set for
> host bridge" ?

No.

> 
> Trying to understand why you'd hit the reassignment of io_resource.
> 
> - k
> 

I did some investigations and the conclusion is:

io_resource.flags & IORESOURCE_IO are both positive but io_resource.start
is 0 before pcibios_setup_phb_io_space() is done.

The sequence of related process listed below:
fsl_add_bridge() -> setup_pci_atmu()
pcibios_init() -> pcibios_scan_phb() -> pcibios_setup_phb_io_space()

Because fsl_add_bridge() must be finished before pcibios_init() so ATMU
is set when io_resource.start is 0. That means outbound IO regs are not
set.

If system re-setup ATMU the io_resource.start has already updated so
outbound IO regs are set.

My question is:
Is there any problem if outbound IO regs are not set in first bootup?

- Hongtao.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Deprecating reserve-map in favor of properties

2012-09-20 Thread Benjamin Herrenschmidt 
On Thu, 2012-09-20 at 20:35 -0500, Kumar Gala wrote:
> If you do this, please update the code in dtc/libfdt to construct the
> new nodes.  We use this in u-boot to reserve kernel, dtb, initrd, etc
> regions.  So would be nice to have drop in replacement code that could
> use same APIs if possible.

The kernel would of course still understand the reserve map and I don't
intend to remove it from the header immediately, so I think that can
stay unless we make it a function of the version.

It's non-trivial to make the same (stateless) API in libfdt deal with
setting properties. I'd rather avoid that problem initially by not
changing the blob format, keeping the reserve map around for "legacy"
purposes and simply making the kernel capable of understanding the
properties.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Deprecating reserve-map in favor of properties

2012-09-20 Thread Kumar Gala 

On Sep 20, 2012, at 5:10 PM, Benjamin Herrenschmidt wrote:

> 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.

If you do this, please update the code in dtc/libfdt to construct the new 
nodes.  We use this in u-boot to reserve kernel, dtb, initrd, etc regions.  So 
would be nice to have drop in replacement code that could use same APIs if 
possible.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] Use pmc_overflow() to detect rolled back events

2012-09-20 Thread Sukadev Bhattiprolu 

Sukadev Bhattiprolu [suka...@linux.vnet.ibm.com] wrote:
| 
| >From 21e9d1775f0c6f37a39e5d682ff74693fa9a4004 Mon Sep 17 00:00:00 2001
| From: Sukadev Bhattiprolu 
| Date: Tue, 7 Aug 2012 17:53:24 -0700
| Subject: [PATCH] Use pmc_overflow to detect rolled back events.
| 
| For certain speculative events on Power7, 'perf stat' reports far higher
| event count than 'perf record' for the same event.
| 
| As described in following commit, a performance monitor exception is raised
| even when the the performance events are rolled back.
| 
| commit 0837e3242c73566fc1c0196b4ec61779c25ffc93
| Author: Anton Blanchard 
| Date:   Wed Mar 9 14:38:42 2011 +1100
| 
| perf_event_interrupt() records an event only when an overflow occurs. But
| this check for overflow is a simple 'if (val < 0)'.
| 
| Because the events are rolled back, this check for overflow fails and the
| event is not recorded. perf_event_interrupt() later uses pmc_overflow() to
| detect the overflow and resets the counters and the events are lost 
completely.
| 
| To properly detect the overflow of rolled back events, use pmc_overflow()
| even when recording events.

Ben,

Sorry for the noise, but please revert this patch (following commit):

commit 813312110bede27bffd082c25cd31730bd567beb
Author: Sukadev Bhattiprolu 
Date:   Tue Aug 7 15:07:19 2012 +

While it does fix the problem described above and works for the limit-pmc
events, it seems to break on Power7 for other events and when the sample
period is low.

I am still investigating the problem and will follow up with a separate
mail.

Sukadev

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: linux-next: build failure after merge of the final tree (net-next tree related)

2012-09-20 Thread David Miller 
From: Benjamin Herrenschmidt 
Date: Fri, 21 Sep 2012 08:22:44 +1000

> Hrm, that's ancient gunk, I'll have to dig. We potentially can support
> ISA devices DMA'ing from an ISA bridge... but via the iommu, which means
> isa_virt_to_bus is a non-starter.
> 
> But then, do we really care ? IE. Is there single device that actually
> requires ISA_DMA_API and that is expected to work on any currently
> supported powerpc hw ? :-)
> 
> We don't even support PReP anymore, so that leaves us with what ?

ISA_DMA_API implies a fixed window of addresses which are <= 32-bits
on the bus, which is a hardware requirement of these devices.

isa_virt_to_bus() goes to that physical address, and the expection is
that you use GFP_DMA and thus the physical addresses fit inside of
an unsigned int.

isa_virt_to_bus() basically amounts to a virt-->phys plus a cast.

> Anybody has an objection to turning ISA_DMA_API off ?

Then you can remove all of the DMA api stuff in powerpc's asm/dma.h
but some of it looks like it might be in use.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: linux-next: build failure after merge of the final tree (net-next tree related)

2012-09-20 Thread Stephen Rothwell 
Hi Dave,

On Thu, 20 Sep 2012 16:45:58 -0400 (EDT) David Miller  
wrote:
>
> I think the powerpc port is at fault here.
> 
> Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().

Not disagreeing, but it would be nice if this was documented somewhere
(maybe in Documentation/DMA-ISA-LPC.txt).  We have not had this problem
before because all the other uses of isa_virt_to_bus() are in drivers
that depend on X86 or ARM or ISA or EISA.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpH3JFkMDQYO.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: linux-next: build failure after merge of the final tree (net-next tree related)

2012-09-20 Thread Benjamin Herrenschmidt 

> > I think the powerpc port is at fault here.
> > 
> > Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().

Hrm, that's ancient gunk, I'll have to dig. We potentially can support
ISA devices DMA'ing from an ISA bridge... but via the iommu, which means
isa_virt_to_bus is a non-starter.

But then, do we really care ? IE. Is there single device that actually
requires ISA_DMA_API and that is expected to work on any currently
supported powerpc hw ? :-)

We don't even support PReP anymore, so that leaves us with what ?

Anybody has an objection to turning ISA_DMA_API off ?

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: linux-next: build failure after merge of the final tree (net-next tree related)

2012-09-20 Thread Stephen Rothwell 
[Just bring this to the attention of the PowerPC folks ...]

On Thu, 20 Sep 2012 16:45:58 -0400 (EDT) David Miller  
wrote:
>
> From: Mika Westerberg 
> Date: Thu, 20 Sep 2012 12:10:14 +0300
> 
> > On Thu, Sep 20, 2012 at 05:36:22PM +1000, Stephen Rothwell wrote:
> >> Hi all,
> >> 
> >> After merging the final tree, today's linux-next build (powerpc
> >> allyesconfig) failed like this:
> >> 
> >> drivers/net/ethernet/i825xx/znet.c: In function 'hardware_init':
> >> drivers/net/ethernet/i825xx/znet.c:868:2: error: implicit declaration of 
> >> function 'isa_virt_to_bus' [-Werror=implicit-function-declaration]
> >> 
> >> Caused by commit 1d3ff76759b7 ("i825xx: znet: fix compiler warnings when
> >> building a 64-bit kernel").  Is there some Kconfig dependency missing 
> >> (CONFIG_ISA)?
> > 
> > If we make it dependent on CONFIG_ISA then the driver cannot be built with
> > 64-bit kernel. Then again is there someone running 64-bit kernel on Zenith
> > Z-note notebook? From the pictures it looks like very ancient "laptop".
> > 
> > An alternative is to make it depend on X86 like this:
> 
> I think the powerpc port is at fault here.
> 
> Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpWzg6cwmaH4.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Deprecating reserve-map in favor of properties

2012-09-20 Thread Benjamin Herrenschmidt 
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.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/3] ASoC: fsl: pcm030-audio-fabric use snd_soc_register_card

2012-09-20 Thread Eric Millbrandt 
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 
---
 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 ");
-- 
1.7.2.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 1/3] ASoC: fsl: add PPC_MPC52xx dependency to SND_POWERPC_SOC

2012-09-20 Thread Eric Millbrandt 
mpc52xx socs do not define FSL_SOC but need SND_POWERPC_SOC defined 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

[PATCH 3/3] ASoC: fsl: register the wm9712-codec

2012-09-20 Thread Eric Millbrandt 
The mpc5200-psc-ac97 driver does not enumerate attached ac97 devices, so
register the device here.

Signed-off-by: Eric Millbrandt 
---
 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

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH][v2] powerpc/mm: using two zones for freescale 64 bit kernel

2012-09-20 Thread Kumar Gala 

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:
 
> 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.
> 
> 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.
> 
> Signed-off-by: Shaohui Xie 
> Signed-off-by: Mingkai Hu 
> Signed-off-by: Chen Yuanquan 
> ---
> changes for v2:
> 1. use a config option for using two zones (ZONE_DMA32 &
> ZONE_NORMAL) in freescale 64 bit kernel.
> 
>>> 
>>> 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 ?
>>> 
>> [S.H] Do you mean this:
>> 
>> phys_addr_t platform_dma_size (maybe a default value should be used, then
>> platform code will change it)
>> 
>> if (top_of_ram > platform_dma_size)
>>  max_zone_pfns[ZONE_DMA] = platform_dma_size >> PAGE_SHIFT; else
>>  max_zone_pfns[ZONE_DMA] = top_of_ram >> PAGE_SHIFT;
>> 
>> max_zone_pfns[ZONE_NORMAL] = top_of_ram >> PAGE_SHIFT;
>> 
>>> Also how does Intel do it ?
>> [S.H] below are codes in Intel:
>> 
>> 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] = MAX_DMA_PFN;
>> 411 #endif
>> 412 #ifdef CONFIG_ZONE_DMA32
>> 413 max_zone_pfns[ZONE_DMA32]   = MAX_DMA32_PFN;
>> 414 #endif
>> 415 max_zone_pfns[ZONE_NORMAL]  = max_low_pfn;
>> 416 #ifdef CONFIG_HIGHMEM
>> 417 max_zone_pfns[ZONE_HIGHMEM] = max_pfn;
>> 418 #endif
>> 419
>> 
>> For x86_64, there is no CONFIG_HIGHMEM, so there will be three zones:
>> ZONE_DMA/ZONE_DMA32/ZONE_NORMAL.
>> 
> [S.H] Hello, Ben,
> 
> 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?
> 
> 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
___
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.

2012-09-20 Thread Kumar Gala 

On Sep 20, 2012, at 4:46 AM, Sethi Varun-B16395 wrote:

> 
> 
>> -Original Message-
>> From: Wood Scott-B07421
>> Sent: Thursday, September 20, 2012 5:42 AM
>> To: Kumar Gala
>> Cc: Sethi Varun-B16395; joerg.roe...@amd.com; iommu@lists.linux-
>> foundation.org; linuxppc-dev@lists.ozlabs.org; linux-
>> ker...@vger.kernel.org; Sethi Varun-B16395
>> Subject: 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.
>> 
> 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH][v2] powerpc/mm: using two zones for freescale 64 bit kernel

2012-09-20 Thread Xie Shaohui-B21989 
> > On Thu, 2012-08-30 at 15:49 -0500, Kumar Gala wrote:
> > > On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
> > >
> > > > 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.
> > > >
> > > > 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.
> > > >
> > > > Signed-off-by: Shaohui Xie 
> > > > Signed-off-by: Mingkai Hu 
> > > > Signed-off-by: Chen Yuanquan 
> > > > ---
> > > > changes for v2:
> > > > 1. use a config option for using two zones (ZONE_DMA32 &
> > > > ZONE_NORMAL) in freescale 64 bit kernel.
> > > >
> >
> > 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 ?
> >
> [S.H] Do you mean this:
> 
> phys_addr_t platform_dma_size (maybe a default value should be used, then
> platform code will change it)
> 
> if (top_of_ram > platform_dma_size)
>   max_zone_pfns[ZONE_DMA] = platform_dma_size >> PAGE_SHIFT; else
>   max_zone_pfns[ZONE_DMA] = top_of_ram >> PAGE_SHIFT;
> 
> max_zone_pfns[ZONE_NORMAL] = top_of_ram >> PAGE_SHIFT;
> 
> > Also how does Intel do it ?
> [S.H] below are codes in Intel:
> 
> 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] = MAX_DMA_PFN;
> 411 #endif
> 412 #ifdef CONFIG_ZONE_DMA32
> 413 max_zone_pfns[ZONE_DMA32]   = MAX_DMA32_PFN;
> 414 #endif
> 415 max_zone_pfns[ZONE_NORMAL]  = max_low_pfn;
> 416 #ifdef CONFIG_HIGHMEM
> 417 max_zone_pfns[ZONE_HIGHMEM] = max_pfn;
> 418 #endif
> 419
> 
> For x86_64, there is no CONFIG_HIGHMEM, so there will be three zones:
> ZONE_DMA/ZONE_DMA32/ZONE_NORMAL.
> 
[S.H] Hello, Ben,

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?

Please comment, Thanks!


Best Regards, 
Shaohui Xie
___
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.

2012-09-20 Thread Sethi Varun-B16395 


> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, September 20, 2012 5:42 AM
> To: Kumar Gala
> Cc: Sethi Varun-B16395; joerg.roe...@amd.com; iommu@lists.linux-
> foundation.org; linuxppc-dev@lists.ozlabs.org; linux-
> ker...@vger.kernel.org; Sethi Varun-B16395
> Subject: 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.
> 
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

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc-kvm: fixing page alignment for TCE

2012-09-20 Thread Alexander Graf 

On 04.09.2012, at 09:36, Alexey Kardashevskiy wrote:

> From: Paul Mackerras 
> 
> TODO: ask Paul to make a proper message.

TODO?

Also, Ben or Paul, please ack if you think it's correct.


Alex

> 
> 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.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
> arch/powerpc/kvm/book3s_64_mmu_hv.c |9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
> 
> 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 = 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,
> 
>   /* Translate the logical address and get the page */
>   psize = hpte_page_size(hpte[0], r);
> - gfn = hpte_rpn(r, psize);
> + gpa = (r & HPTE_R_RPN & ~(psize - 1)) | (ea & (psize - 1));
> + gfn = gpa >> PAGE_SHIFT;
>   memslot = gfn_to_memslot(kvm, gfn);
> 
>   /* No memslot means it's an emulated MMIO region */
> - if (!memslot || (memslot->flags & KVM_MEMSLOT_INVALID)) {
> - unsigned long gpa = (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);
> - }
> 
>   if (!kvm->arch.using_mmu_notifiers)
>   return -EFAULT; /* should never get here */
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev