RE: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.

[Sethi Varun-B16395]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, December 04, 2012 11:53 PM
> To: Sethi Varun-B16395
> Cc: Wood Scott-B07421; Joerg Roedel; linux-ker...@vger.kernel.org;
> io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; Tabi
> Timur-B04825
> Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes
> required by fsl PAMU driver.
> 
> On 12/04/2012 05:53:33 AM, Sethi Varun-B16395 wrote:
> >
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Monday, December 03, 2012 10:34 PM
> > > To: Sethi Varun-B16395
> > > Cc: Joerg Roedel; linux-ker...@vger.kernel.org; iommu@lists.linux-
> > > foundation.org; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
> > Tabi
> > > Timur-B04825
> > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes
> > > required by fsl PAMU driver.
> > >
> > > On 12/03/2012 10:57:29 AM, Sethi Varun-B16395 wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> > > > > boun...@lists.linux-foundation.org] On Behalf Of Joerg Roedel
> > > > > Sent: Sunday, December 02, 2012 7:33 PM
> > > > > To: Sethi Varun-B16395
> > > > > Cc: linux-ker...@vger.kernel.org;
> > io...@lists.linux-foundation.org;
> > > > Wood
> > > > > Scott-B07421; linuxppc-dev@lists.ozlabs.org; Tabi Timur-B04825
> > > > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain
> > attributes
> > > > > required by fsl PAMU driver.
> > > > >
> > > > > Hmm, we need to work out a good abstraction for this.
> > > > >
> > > > > On Tue, Nov 20, 2012 at 07:24:56PM +0530, Varun Sethi wrote:
> > > > > > Added the following domain attributes required by FSL PAMU
> > driver:
> > > > > > 1. Subwindows field added to the iommu domain geometry
> > attribute.
> > > > >
> > > > > Are the Subwindows mapped with full size or do you map only
> > parts
> > > > of the
> > > > > subwindows?
> > > > >
> > > > [Sethi Varun-B16395] It's possible to map a part of the subwindow
> > i.e.
> > > > size of the mapping can be less than the sub window size.
> > > >
> > > > > > +* This attribute indicates number of DMA subwindows
> > > supported
> > > > by
> > > > > > +* the geometry. If there is a single window that maps
> > the
> > > > entire
> > > > > > +* geometry, attribute must be set to "1". A value of
> > "0"
> > > > implies
> > > > > > +* that this mechanism is not used at all(normal paging
> > is
> > > > used).
> > > > > > +* Value other than* "0" or "1" indicates the actual
> > number
> > > of
> > > > > > +* subwindows.
> > > > > > +*/
> > > > >
> > > > > This semantic is ugly, how about a feature detection mechanism?
> > > > >
> > > > [Sethi Varun-B16395] A feature mechanism to query the type of
> > IOMMU?
> > >
> > > A feature mechanism to determine whether this subwindow mechanism is
> > > available, and what the limits are.
> > >
> > So, we use the IOMMU capability interface to find out if IOMMU
> > supports sub windows or not, right? But still number of sub windows
> > would be specified as a part of the geometry and the valid value for
> > sub windows would  0,1 or actual number of sub windows.
> 
> How does a user of the interface find out what values are possible for
> the "actual number of subwindows"?  How does a user of the interface find
> out whether there are any limitations on specifying a value of zero (in
> the case of PAMU, that would be a maximum 1 MiB naturally-aligned
> aperture to support arbitrary 4KiB mappings)?
How about if we say that the default value for subwindows is zero and this what 
you get when you read the geometry (iommu_get_attr) after initializing the 
domain? In that case the user would know that implication of setting subwindows 
to zero with respect to the aperture size. Also, should we introduce an 
additional API like "iommu_check_attr", which the user can use to validate the 
attribute value. For example in case of geometry, the user can fill up the 
structure and pass it to the iommu driver in order to verify the aperture and 
subwindows field.

-Varun

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

Re: [PATCH v2 2/4] powerpc: Move the single step enable code to a generic path

[Ananth N Mavinakayanahalli]

On Mon, Dec 03, 2012 at 08:38:37PM +0530, Suzuki K. Poulose wrote:
> From: Suzuki K. Poulose 
> 
> This patch moves the single step enable code used by kprobe to a generic
> routine header so that, it can be re-used by other code, in this case,
> uprobes. No functional changes.
> 
> Signed-off-by: Suzuki K. Poulose 
> Cc:   Ananth N Mavinakaynahalli 
> Cc:   Kumar Gala 
> Cc:   linuxppc-...@ozlabs.org

Acked-by: Ananth N Mavinakayanahalli 

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

pci and pcie device-tree binding - range No cells

[Michal Simek]

Hi Grant and others,

I have a question regarding number of cells in ranges property
for pci and pcie nodes.

Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts, sequoia.dts, etc)
but also 6 cells format too (mpc832x_mds.dts)

Here is shown 6 cells ranges format and describe
http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge

And also in documentation in the linux
Documentation/devicetree/bindings/pci/83xx-512x-pci.txt

Both format uses:
#size-cells = <2>;
#address-cells = <3>;

What is valid format?

Thanks,
Michal

--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: pci and pcie device-tree binding - range No cells

[Rob Herring]

On 12/10/2012 06:20 AM, Michal Simek wrote:
> Hi Grant and others,
> 
> I have a question regarding number of cells in ranges property
> for pci and pcie nodes.
> 
> Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts,
> sequoia.dts, etc)
> but also 6 cells format too (mpc832x_mds.dts)
> 
> Here is shown 6 cells ranges format and describe
> http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
> 
> And also in documentation in the linux
> Documentation/devicetree/bindings/pci/83xx-512x-pci.txt
> 
> Both format uses:
> #size-cells = <2>;
> #address-cells = <3>;
> 
> What is valid format?

Both. 7 cells are valid when the host (parent) bus is 64-bit and 6 cells
are valid when the host bus is 32-bit. The ranges property is <  >. The parent address #address-cells is
taken from the parent node.

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

Re: pci and pcie device-tree binding - range No cells

[Michal Simek]

On 12/10/2012 03:26 PM, Rob Herring wrote:

On 12/10/2012 06:20 AM, Michal Simek wrote:

Hi Grant and others,

I have a question regarding number of cells in ranges property
for pci and pcie nodes.

Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts,
sequoia.dts, etc)
but also 6 cells format too (mpc832x_mds.dts)

Here is shown 6 cells ranges format and describe
http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge

And also in documentation in the linux
Documentation/devicetree/bindings/pci/83xx-512x-pci.txt

Both format uses:
#size-cells = <2>;
#address-cells = <3>;

What is valid format?


Both. 7 cells are valid when the host (parent) bus is 64-bit and 6 cells
are valid when the host bus is 32-bit. The ranges property is <  >. The parent address #address-cells is
taken from the parent node.


Ok. Got it.

Here is what we use on zynq and microblaze - both 32bit which should be fine.

ps7_axi_interconnect_0: axi@0 {
#address-cells = <1>;
#size-cells = <1>;
axi_pcie_0: axi-pcie@5000 {
#address-cells = <3>;
#size-cells = <2>;
compatible = "xlnx,axi-pcie-1.05.a";
ranges = < 0x0200 0 0x6000 0x6000 0 0x1000 
>;
...
}
}

What I am wondering is pci_process_bridge_OF_ranges() at 
arch/powerpc/kernel/pci-common.c
where there are used some hardcoded values which should be probably loaded from 
device-tree.

For example:
683 int np = pna + 5;
...
702 pci_addr = of_read_number(ranges + 1, 2);
703 cpu_addr = of_translate_address(dev, ranges + 3);
704 size = of_read_number(ranges + pna + 3, 2);


Unfortunately we have copied it to microblaze.

Thanks,
Michal






--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: pci and pcie device-tree binding - range No cells

[Rob Herring]

On 12/10/2012 09:05 AM, Michal Simek wrote:
> On 12/10/2012 03:26 PM, Rob Herring wrote:
>> On 12/10/2012 06:20 AM, Michal Simek wrote:
>>> Hi Grant and others,
>>>
>>> I have a question regarding number of cells in ranges property
>>> for pci and pcie nodes.
>>>
>>> Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts,
>>> sequoia.dts, etc)
>>> but also 6 cells format too (mpc832x_mds.dts)
>>>
>>> Here is shown 6 cells ranges format and describe
>>> http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>
>>> And also in documentation in the linux
>>> Documentation/devicetree/bindings/pci/83xx-512x-pci.txt
>>>
>>> Both format uses:
>>> #size-cells = <2>;
>>> #address-cells = <3>;
>>>
>>> What is valid format?
>>
>> Both. 7 cells are valid when the host (parent) bus is 64-bit and 6 cells
>> are valid when the host bus is 32-bit. The ranges property is <> address>  >. The parent address #address-cells is
>> taken from the parent node.
> 
> Ok. Got it.
> 
> Here is what we use on zynq and microblaze - both 32bit which should be
> fine.
> 
> ps7_axi_interconnect_0: axi@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> axi_pcie_0: axi-pcie@5000 {
> #address-cells = <3>;
> #size-cells = <2>;
> compatible = "xlnx,axi-pcie-1.05.a";
> ranges = < 0x0200 0 0x6000 0x6000 0 0x1000 >;
> ...
> }
> }
> 
> What I am wondering is pci_process_bridge_OF_ranges() at
> arch/powerpc/kernel/pci-common.c
> where there are used some hardcoded values which should be probably
> loaded from device-tree.
> 
> For example:
> 683 int np = pna + 5;
> ...
> 702 pci_addr = of_read_number(ranges + 1, 2);
> 703 cpu_addr = of_translate_address(dev, ranges + 3);
> 704 size = of_read_number(ranges + pna + 3, 2);

These would always be correct whether you have 6 or 7 cells. pna is the
parent bus address cells size. The pci address is fixed at 3 cells.

> 
> 
> Unfortunately we have copied it to microblaze.

I look at the PCI DT code in powerpc and see a whole bunch of code that
seems like it should be common. The different per arch pci structs
complicates that. No one has really gotten to looking at PCI DT on ARM
yet except you and Thierry for Tegra. We definitely don't want to create
a 3rd copy. Starting the process of moving it to something like
drivers/pci/pci-of.c would be great.

Rob

> 
> Thanks,
> Michal
> 
> 
> 
> 
> 
> 

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

Re: pci and pcie device-tree binding - range No cells

[Michal Simek]

On 12/10/2012 04:21 PM, Rob Herring wrote:

On 12/10/2012 09:05 AM, Michal Simek wrote:

On 12/10/2012 03:26 PM, Rob Herring wrote:

On 12/10/2012 06:20 AM, Michal Simek wrote:

Hi Grant and others,

I have a question regarding number of cells in ranges property
for pci and pcie nodes.

Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts,
sequoia.dts, etc)
but also 6 cells format too (mpc832x_mds.dts)

Here is shown 6 cells ranges format and describe
http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge

And also in documentation in the linux
Documentation/devicetree/bindings/pci/83xx-512x-pci.txt

Both format uses:
#size-cells = <2>;
#address-cells = <3>;

What is valid format?


Both. 7 cells are valid when the host (parent) bus is 64-bit and 6 cells
are valid when the host bus is 32-bit. The ranges property is <  >. The parent address #address-cells is
taken from the parent node.


Ok. Got it.

Here is what we use on zynq and microblaze - both 32bit which should be
fine.

 ps7_axi_interconnect_0: axi@0 {
 #address-cells = <1>;
 #size-cells = <1>;
 axi_pcie_0: axi-pcie@5000 {
 #address-cells = <3>;
 #size-cells = <2>;
 compatible = "xlnx,axi-pcie-1.05.a";
 ranges = < 0x0200 0 0x6000 0x6000 0 0x1000 >;
 ...
 }
 }

What I am wondering is pci_process_bridge_OF_ranges() at
arch/powerpc/kernel/pci-common.c
where there are used some hardcoded values which should be probably
loaded from device-tree.

For example:
683 int np = pna + 5;
...
702 pci_addr = of_read_number(ranges + 1, 2);
703 cpu_addr = of_translate_address(dev, ranges + 3);
704 size = of_read_number(ranges + pna + 3, 2);


These would always be correct whether you have 6 or 7 cells. pna is the
parent bus address cells size. The pci address is fixed at 3 cells.


Sorry for my pci ignorance (have never got hw for mb/zynq)
I just want to get better overview how we should we our drivers to be 
compatible.

Does it mean that pci is supposed be always 64 bit wide?
And there is no option to have just 32bit values.


Unfortunately we have copied it to microblaze.


I look at the PCI DT code in powerpc and see a whole bunch of code that
seems like it should be common. The different per arch pci structs
complicates that. No one has really gotten to looking at PCI DT on ARM
yet except you and Thierry for Tegra. We definitely don't want to create
a 3rd copy. Starting the process of moving it to something like
drivers/pci/pci-of.c would be great.


We have done pcie working on zynq and the same pcie host is working on 
Microblaze too.
There are just small differences. That's why I have sent another email
("Sharing PCIE driver between Microblaze and Arm zynq") to find out proper 
location.

PCI: Microblaze shares almost the same code with powerpc that's why I am 
definitely open
to move this code out of architecture.

Thanks,
Michal



--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: pci and pcie device-tree binding - range No cells

[David Laight]

> Does it mean that pci is supposed be always 64 bit wide?
> And there is no option to have just 32bit values.

I certainly believe that all PCIe (not PCI) transfers are
nominally multiples of 64bit data.
There are (effectively) 8 byte-lane enables to allow partial word
transfers (I'm not sure whether disjoint subwords are valid).

Some PCIe slave->32bit bus bridges always do two slave cycles.
Even though, for a 32bit word transfer, one of them ends up having
no byte enables asserted.

David



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

Re: pci and pcie device-tree binding - range No cells

[Rob Herring]

On 12/10/2012 09:37 AM, Michal Simek wrote:
> On 12/10/2012 04:21 PM, Rob Herring wrote:
>> On 12/10/2012 09:05 AM, Michal Simek wrote:
>>> On 12/10/2012 03:26 PM, Rob Herring wrote:
 On 12/10/2012 06:20 AM, Michal Simek wrote:
> Hi Grant and others,
>
> I have a question regarding number of cells in ranges property
> for pci and pcie nodes.
>
> Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts,
> sequoia.dts, etc)
> but also 6 cells format too (mpc832x_mds.dts)
>
> Here is shown 6 cells ranges format and describe
> http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>
> And also in documentation in the linux
> Documentation/devicetree/bindings/pci/83xx-512x-pci.txt
>
> Both format uses:
> #size-cells = <2>;
> #address-cells = <3>;
>
> What is valid format?

 Both. 7 cells are valid when the host (parent) bus is 64-bit and 6
 cells
 are valid when the host bus is 32-bit. The ranges property is <>>> address>  >. The parent address #address-cells is
 taken from the parent node.
>>>
>>> Ok. Got it.
>>>
>>> Here is what we use on zynq and microblaze - both 32bit which should be
>>> fine.
>>>
>>>  ps7_axi_interconnect_0: axi@0 {
>>>  #address-cells = <1>;
>>>  #size-cells = <1>;
>>>  axi_pcie_0: axi-pcie@5000 {
>>>  #address-cells = <3>;
>>>  #size-cells = <2>;
>>>  compatible = "xlnx,axi-pcie-1.05.a";
>>>  ranges = < 0x0200 0 0x6000 0x6000 0
>>> 0x1000 >;
>>>  ...
>>>  }
>>>  }
>>>
>>> What I am wondering is pci_process_bridge_OF_ranges() at
>>> arch/powerpc/kernel/pci-common.c
>>> where there are used some hardcoded values which should be probably
>>> loaded from device-tree.
>>>
>>> For example:
>>> 683 int np = pna + 5;
>>> ...
>>> 702 pci_addr = of_read_number(ranges + 1, 2);
>>> 703 cpu_addr = of_translate_address(dev, ranges + 3);
>>> 704 size = of_read_number(ranges + pna + 3, 2);
>>
>> These would always be correct whether you have 6 or 7 cells. pna is the
>> parent bus address cells size. The pci address is fixed at 3 cells.
> 
> Sorry for my pci ignorance (have never got hw for mb/zynq)
> I just want to get better overview how we should we our drivers to be
> compatible.
> 
> Does it mean that pci is supposed be always 64 bit wide?
> And there is no option to have just 32bit values.

That's what the DT documentation says.

BTW, you can use 2 cells even if you only have a 32-bit bus.

> 
>>> Unfortunately we have copied it to microblaze.
>>
>> I look at the PCI DT code in powerpc and see a whole bunch of code that
>> seems like it should be common. The different per arch pci structs
>> complicates that. No one has really gotten to looking at PCI DT on ARM
>> yet except you and Thierry for Tegra. We definitely don't want to create
>> a 3rd copy. Starting the process of moving it to something like
>> drivers/pci/pci-of.c would be great.
> 
> We have done pcie working on zynq and the same pcie host is working on
> Microblaze too.
> There are just small differences. That's why I have sent another email
> ("Sharing PCIE driver between Microblaze and Arm zynq") to find out
> proper location.

Yes, I've followed the thread. There are lots of areas for consolidation
with PCIe hosts both across architectures and within ARM. There are
multiple people using DW PCIe IP although not upstream yet that I'm
aware of.

Rob

> 
> PCI: Microblaze shares almost the same code with powerpc that's why I am
> definitely open
> to move this code out of architecture.
> 
> Thanks,
> Michal
> 
> 
> 

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

Re: pci and pcie device-tree binding - range No cells

[Michal Simek]

On 12/10/2012 04:52 PM, David Laight wrote:

Does it mean that pci is supposed be always 64 bit wide?
And there is no option to have just 32bit values.


I certainly believe that all PCIe (not PCI) transfers are
nominally multiples of 64bit data.


And PCI? That powerpc/pci-common code was designed for PCI
and microblaze also used it for PCI.

CC: Thomas: I think it will be interesting to see this discussion
because you are using size-cell/address-cells equal 1.
http://www.spinics.net/lists/arm-kernel/msg211839.html

Thanks,
Michal

--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: pci and pcie device-tree binding - range No cells

[Michal Simek]

On 12/10/2012 05:02 PM, Rob Herring wrote:

On 12/10/2012 09:37 AM, Michal Simek wrote:

On 12/10/2012 04:21 PM, Rob Herring wrote:

On 12/10/2012 09:05 AM, Michal Simek wrote:

On 12/10/2012 03:26 PM, Rob Herring wrote:

On 12/10/2012 06:20 AM, Michal Simek wrote:

Hi Grant and others,

I have a question regarding number of cells in ranges property
for pci and pcie nodes.

Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts,
sequoia.dts, etc)
but also 6 cells format too (mpc832x_mds.dts)

Here is shown 6 cells ranges format and describe
http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge

And also in documentation in the linux
Documentation/devicetree/bindings/pci/83xx-512x-pci.txt

Both format uses:
#size-cells = <2>;
#address-cells = <3>;

What is valid format?


Both. 7 cells are valid when the host (parent) bus is 64-bit and 6
cells
are valid when the host bus is 32-bit. The ranges property is <  >. The parent address #address-cells is
taken from the parent node.


Ok. Got it.

Here is what we use on zynq and microblaze - both 32bit which should be
fine.

  ps7_axi_interconnect_0: axi@0 {
  #address-cells = <1>;
  #size-cells = <1>;
  axi_pcie_0: axi-pcie@5000 {
  #address-cells = <3>;
  #size-cells = <2>;
  compatible = "xlnx,axi-pcie-1.05.a";
  ranges = < 0x0200 0 0x6000 0x6000 0
0x1000 >;
  ...
  }
  }

What I am wondering is pci_process_bridge_OF_ranges() at
arch/powerpc/kernel/pci-common.c
where there are used some hardcoded values which should be probably
loaded from device-tree.

For example:
683 int np = pna + 5;
...
702 pci_addr = of_read_number(ranges + 1, 2);
703 cpu_addr = of_translate_address(dev, ranges + 3);
704 size = of_read_number(ranges + pna + 3, 2);


These would always be correct whether you have 6 or 7 cells. pna is the
parent bus address cells size. The pci address is fixed at 3 cells.


Sorry for my pci ignorance (have never got hw for mb/zynq)
I just want to get better overview how we should we our drivers to be
compatible.

Does it mean that pci is supposed be always 64 bit wide?
And there is no option to have just 32bit values.


That's what the DT documentation says.

BTW, you can use 2 cells even if you only have a 32-bit bus.


ok - no problem with that. Just want to be sure about it.


Unfortunately we have copied it to microblaze.


I look at the PCI DT code in powerpc and see a whole bunch of code that
seems like it should be common. The different per arch pci structs
complicates that. No one has really gotten to looking at PCI DT on ARM
yet except you and Thierry for Tegra. We definitely don't want to create
a 3rd copy. Starting the process of moving it to something like
drivers/pci/pci-of.c would be great.


We have done pcie working on zynq and the same pcie host is working on
Microblaze too.
There are just small differences. That's why I have sent another email
("Sharing PCIE driver between Microblaze and Arm zynq") to find out
proper location.


Yes, I've followed the thread. There are lots of areas for consolidation
with PCIe hosts both across architectures and within ARM. There are
multiple people using DW PCIe IP although not upstream yet that I'm
aware of.


Your suggestions are really appreciate.

Thanks,
Michal

--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2] powerpc: fix wii_memory_fixups() compile error on 3.0.y tree

[Shuah Khan]

Fix wii_memory_fixups() the following compile error on 3.0.y tree with 
wii_defconfig on 3.0.y tree.

  CC  arch/powerpc/platforms/embedded6xx/wii.o
arch/powerpc/platforms/embedded6xx/wii.c: In function ‘wii_memory_fixups’:
arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects 
argument of type ‘long long unsigned int’, but argument 2 has type 
‘phys_addr_t’ [-Werror=format]
arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects 
argument of type ‘long long unsigned int’, but argument 3 has type 
‘phys_addr_t’ [-Werror=format]
arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects 
argument of type ‘long long unsigned int’, but argument 2 has type 
‘phys_addr_t’ [-Werror=format]
arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects 
argument of type ‘long long unsigned int’, but argument 3 has type 
‘phys_addr_t’ [-Werror=format]
cc1: all warnings being treated as errors
make[2]: *** [arch/powerpc/platforms/embedded6xx/wii.o] Error 1
make[1]: *** [arch/powerpc/platforms/embedded6xx] Error 2
make: *** [arch/powerpc/platforms] Error 2

Signed-off-by: Shuah Khan 
CC: sta...@vger.kernel.org 3.0.y
---
 arch/powerpc/platforms/embedded6xx/wii.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/embedded6xx/wii.c 
b/arch/powerpc/platforms/embedded6xx/wii.c
index 1b5dc1a..d8ff38f 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -85,9 +85,11 @@ void __init wii_memory_fixups(void)
wii_hole_start = p[0].base + p[0].size;
wii_hole_size = p[1].base - wii_hole_start;
 
-   pr_info("MEM1: <%08llx %08llx>\n", p[0].base, p[0].size);
+   pr_info("MEM1: <%08ulx %08ulx>\n",
+   (phys_addr_t) p[0].base, (phys_addr_t) p[0].size);
pr_info("HOLE: <%08lx %08lx>\n", wii_hole_start, wii_hole_size);
-   pr_info("MEM2: <%08llx %08llx>\n", p[1].base, p[1].size);
+   pr_info("MEM2: <%08ulx %08ulx>\n",
+   (phys_addr_t) p[1].base, (phys_addr_t) p[1].size);
 
p[0].size += wii_hole_size + p[1].size;
 
-- 
1.7.9.5

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

Re: [PATCH v2] powerpc: fix wii_memory_fixups() compile error on 3.0.y tree

[Ben Hutchings]

On Mon, Dec 10, 2012 at 10:23:16AM -0700, Shuah Khan wrote:
> Fix wii_memory_fixups() the following compile error on 3.0.y tree with 
> wii_defconfig on 3.0.y tree.
> 
>   CC  arch/powerpc/platforms/embedded6xx/wii.o
> arch/powerpc/platforms/embedded6xx/wii.c: In function ‘wii_memory_fixups’:
> arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects 
> argument of type ‘long long unsigned int’, but argument 2 has type 
> ‘phys_addr_t’ [-Werror=format]
> arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects 
> argument of type ‘long long unsigned int’, but argument 3 has type 
> ‘phys_addr_t’ [-Werror=format]
> arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects 
> argument of type ‘long long unsigned int’, but argument 2 has type 
> ‘phys_addr_t’ [-Werror=format]
> arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects 
> argument of type ‘long long unsigned int’, but argument 3 has type 
> ‘phys_addr_t’ [-Werror=format]
> cc1: all warnings being treated as errors
> make[2]: *** [arch/powerpc/platforms/embedded6xx/wii.o] Error 1
> make[1]: *** [arch/powerpc/platforms/embedded6xx] Error 2
> make: *** [arch/powerpc/platforms] Error 2
> 
> Signed-off-by: Shuah Khan 
> CC: sta...@vger.kernel.org 3.0.y
> ---
>  arch/powerpc/platforms/embedded6xx/wii.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/embedded6xx/wii.c 
> b/arch/powerpc/platforms/embedded6xx/wii.c
> index 1b5dc1a..d8ff38f 100644
> --- a/arch/powerpc/platforms/embedded6xx/wii.c
> +++ b/arch/powerpc/platforms/embedded6xx/wii.c
> @@ -85,9 +85,11 @@ void __init wii_memory_fixups(void)
>   wii_hole_start = p[0].base + p[0].size;
>   wii_hole_size = p[1].base - wii_hole_start;
>  
> - pr_info("MEM1: <%08llx %08llx>\n", p[0].base, p[0].size);
> + pr_info("MEM1: <%08ulx %08ulx>\n",
> + (phys_addr_t) p[0].base, (phys_addr_t) p[0].size);
[...]

This is incorrect in exactly the same way as the last version,
but with extra redundant casts.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: pci and pcie device-tree binding - range No cells

[Thomas Petazzoni]

Dear Michal Simek,

On Mon, 10 Dec 2012 17:05:13 +0100, Michal Simek wrote:

> CC: Thomas: I think it will be interesting to see this discussion
> because you are using size-cell/address-cells equal 1.
> http://www.spinics.net/lists/arm-kernel/msg211839.html

Thanks for Cc'ing me.

The thing is that on Marvell SoCs, we don't need to describe statically
in the Device Tree the translation between CPU addresses and PCI device
addresses, because those translations are set up dynamically at run
time through address decoding windows.

Marvell SoCs have up to 20 configurable address windows, which allow
you, at run time, to say "I would like the range from physical address
0x to 0x to correspond to the PCIe device in port 1,
lane 2, or to the NAND, or to this or that device". Therefore, in the
PCIe driver I proposed for the Armada 370/XP SoCs [1], there is no need
to encode all those ranges statically in the DT.

The only "ranges" property I'm using is to allow the DT sub-nodes
describing each PCIe port/lane to access the CPU registers that allow
to see if the PCIe link is up or down, access the PCI configuration
space and so on. So all ranges in my "ranges" property correspond to
normal CPU registers, like the one you would put in the "reg" property
for any device. The fact that those devices are PCIe is really
orthogonal here.

Of course, I have no idea if I'm doing a correct usage of the DT, but I
certainly don't need those 6 values ranges with bits to say if it's I/O
space, memory space, bus number, device number and so on. The physical
addresses at which I'm setting up my address decoding windows are
decided dynamically at runtime, depending on the number of PCIe devices
that are found in the different PCIe slots (for now, those windows have
a statically defined size, but I'd ideally would like to size them to
match exactly the size of the PCIe device memory, in order to avoid
wasting physical address space, but I haven't found how to get the size
needed for each PCIe device during the ARM pcibios initialization
sequence).

For those willing to have a look at the PCIe patch set for Armada
370/XP, see:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/136455.html.
The core of the PCIe driver and its DT binding documentation is at
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/136711.html.

Thanks a lot for your comments,

Thomas

[1] that I hope to extend to cover previous Marvell SoCs as well, they
work basically the same way
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC] Add IBM Blue Gene/Q Platform

[Jimi Xenidis]

On Dec 7, 2012, at 8:31 AM, Andrew Tauferner  wrote:

> Jimi,
> 
> > > Do you actually want this upstream?  I assume no.
> > 
> > I needed to get these long-term patches out there for the BGQ 
> > community for test.
> 
> To which BGQ community are you referring?

This work is being done by IBM Research (me) and made possible by the US-DOE 
via:
  

>  What is the motivation for this work?

Maintain a modern kernel that has a "reasonable" set of patches that, with the 
much appreciated feedback from the Linux community, _could_ go upstream.

> 
> > I would very much like to get a version of these upstream.
> > I expect only the QPX, kexec, and (maybe) the DCR changes to cause 
> > any controversy, but I've been wrong before.
> 
> Hehe.  Ben had a variety of issues with the BG/Q firmware when he 
> gave me some feedback a few years ago.

Yup, I think I have addressed these issues.

> 
> > I'll be making those patches soon and hope to get a lot of feedback 
> > from these patches.
> 
> What was the starting point for this work?  On what is it based?

  >

-jx


> 
> > -jx
> > 
> > 
> > > 
> > > Mikey
> > > 
> > >> 
> > >> Here is a are the summary logs:
> > >> 
> > >> $ git log --reverse linux-stable/linux-3.4.y..
> > >> commit 5a8edb2bdd914597693eed299119ff4c2e6d31f2
> > >> Author: Jimi Xenidis 
> > >> Date:   Fri Nov 9 09:26:00 2012 -0600
> > >> 
> > >>powerpc: Fix cputable #ifdef where CONFIG_PPC_A2 is used for 
> > CONFIG_PPC_BOOK3E_64
> > >> 
> > >>Signed-off-by: Jimi Xenidis 
> > >> 
> > >> commit ea51920d7035c8d23801d6de46261e7d0a537dfd
> > >> Author: Jimi Xenidis 
> > >> Date:   Fri Nov 9 08:58:27 2012 -0600
> > >> 
> > >>powerpc/book3e: Remove config for PPC_A2_DD2 since there is no
> > reference to it
> > >> 
> > >>This must have been leftover from early DD1 days which is not
> > >>present in any current kernel code.
> > >> 
> > >>Signed-off-by: Jimi Xenidis 
> > >> 
> > >> commit 08151401a5db4ff0d441a1b7bf8ad92bd92b14c5
> > >> Author: Jimi Xenidis 
> > >> Date:   Mon Nov 5 09:38:01 2012 -0600
> > >> 
> > >>powerpc/dcr: Some native DCR fixes
> > >> 
> > >>The following fixes have been made:
> > >> - dcr_read/write_native() must use the indexed version of the
> > >>   m[ft]dcrx since the non-indexed version only allows a 10-bit
> > >>   numerical space, but the C interface allows a full 32-bits.
> > >> - C bindings for m[ft]dcrx, and the "table" versions, should use
> > >>   "unsigned long" so that they are 64/32 bit neutral.
> > >> - The "table" versions (__m[ft]cdr) should obtain the table address
> > >>   with LOAD_REG_ADDR(), this will also make it 64/32bit neutral.
> > >> 
> > >>Signed-off-by: Jimi Xenidis 
> > >> 
> > >> commit c8320a5daaceed03992d763302020834ea8e17dd
> > >> Author: Jimi Xenidis 
> > >> Date:   Mon Nov 5 09:12:00 2012 -0600
> > >> 
> > >>powerpc/dcr: Add 64-bit DCR access methods.
> > >> 
> > >>This patch adds the ability to make 64-bit Device Control Register
> > >>(DCR) accesses.
> > >> 
> > >>Signed-off-by: Jimi Xenidis 
> > >> 
> > >> commit a763b3f8453b3bd83d7dded8c6644939863af430
> > >> Author: Jimi Xenidis 
> > >> Date:   Thu Nov 29 12:49:24 2012 -0500
> > >> 
> > >>powerpc/boot: Add a "spin_threads" hook to platform_ops
> > >> 
> > >>It is useful for the boot program to arrange for all secondary cpus
> > >>and threads to enter the kernel in a "kexec" fashion.  This hook makes
> > >>it possible.
> > >> 
> > >>Signed-off-by: Jimi Xenidis 
> > >> 
> > >> commit 391e43393380b514d4d02a42d059619542c7597b
> > >> Author: Jimi Xenidis 
> > >> Date:   Thu Nov 29 13:01:23 2012 -0500
> > >> 
> > >>powerpc/kexec: Add kexec "hold" support for Book3e processors
> > >> 
> > >>This patch add two items:
> > >>1) Book3e requires that GPR4 survive the "hold" process, so we make
> > >>   sure that happens.
> > >>2) Book3e has no real mode, and the hold code exploits this.  Since
> > >>   these processors ares always translated, we arrange for the kexeced
> > >>   threads to enter the hold code using the normal kernel 
> > linear mapping.
> > >> 
> > >>Signed-off-by: Jimi Xenidis 
> > >> 
> > >> commit f6e3c1f706cb6922349d639a74ff6c50acc8b9f8
> > >> Author: Jimi Xenidis 
> > >> Date:   Wed Dec 5 13:41:25 2012 -0500
> > >> 
> > >>powerpc: Remove unecessary VSX symbols
> > >> 
> > >>The symbol THREAD_VSR0 is defined to be the same as THREAD_FPR0.  Its
> > >>presence causes build issues with more complex configurations.
> > >> 
> > >>Signed-off-by: Jimi Xenidis 
> > >> 
> > >> commit 4e817bb42ec8e3d3689877528dd97c4286a870eb
> > >> Author: Jimi Xenidis 
> > >> Date:   Tue Nov 20 10:10:52 2012 -0600
> > >> 
> > >>Blue Gene/Q wicked optimizing compiler does not know the rfdi 
> > instruction yet
> > >> 
> > >>Signed-o

Re: [RFC] Add IBM Blue Gene/Q Platform

[Jimi Xenidis]

On Dec 10, 2012, at 3:32 PM, Jimi Xenidis  wrote:

> 
> On Dec 7, 2012, at 8:31 AM, Andrew Tauferner  wrote:
> 
>> Jimi,
>> 
 Do you actually want this upstream?  I assume no.
>>> 
>>> I needed to get these long-term patches out there for the BGQ 
>>> community for test.
>> 
>> To which BGQ community are you referring?
> 
> This work is being done by IBM Research (me) and made possible by the US-DOE 
> via:
>  
> 
>> What is the motivation for this work?
> 
> Maintain a modern kernel that has a "reasonable" set of patches that, with 
> the much appreciated feedback from the Linux community, _could_ go upstream.
> 
>> 
>>> I would very much like to get a version of these upstream.
>>> I expect only the QPX, kexec, and (maybe) the DCR changes to cause 
>>> any controversy, but I've been wrong before.
>> 
>> Hehe.  Ben had a variety of issues with the BG/Q firmware when he 
>> gave me some feedback a few years ago.
> 
> Yup, I think I have addressed these issues.
> 
>> 
>>> I'll be making those patches soon and hope to get a lot of feedback 
>>> from these patches.
>> 
>> What was the starting point for this work?  On what is it based?
> 
>  >

I should add that these patches have been heavily modified to meet requirements 
and suggestions of BenH and others.
-jx


> 
> -jx
> 
> 
>> 
>>> -jx
>>> 
>>> 
 
 Mikey
 
> 
> Here is a are the summary logs:
> 
> $ git log --reverse linux-stable/linux-3.4.y..
> commit 5a8edb2bdd914597693eed299119ff4c2e6d31f2
> Author: Jimi Xenidis 
> Date:   Fri Nov 9 09:26:00 2012 -0600
> 
>   powerpc: Fix cputable #ifdef where CONFIG_PPC_A2 is used for 
>>> CONFIG_PPC_BOOK3E_64
> 
>   Signed-off-by: Jimi Xenidis 
> 
> commit ea51920d7035c8d23801d6de46261e7d0a537dfd
> Author: Jimi Xenidis 
> Date:   Fri Nov 9 08:58:27 2012 -0600
> 
>   powerpc/book3e: Remove config for PPC_A2_DD2 since there is no
>>> reference to it
> 
>   This must have been leftover from early DD1 days which is not
>   present in any current kernel code.
> 
>   Signed-off-by: Jimi Xenidis 
> 
> commit 08151401a5db4ff0d441a1b7bf8ad92bd92b14c5
> Author: Jimi Xenidis 
> Date:   Mon Nov 5 09:38:01 2012 -0600
> 
>   powerpc/dcr: Some native DCR fixes
> 
>   The following fixes have been made:
>- dcr_read/write_native() must use the indexed version of the
>  m[ft]dcrx since the non-indexed version only allows a 10-bit
>  numerical space, but the C interface allows a full 32-bits.
>- C bindings for m[ft]dcrx, and the "table" versions, should use
>  "unsigned long" so that they are 64/32 bit neutral.
>- The "table" versions (__m[ft]cdr) should obtain the table address
>  with LOAD_REG_ADDR(), this will also make it 64/32bit neutral.
> 
>   Signed-off-by: Jimi Xenidis 
> 
> commit c8320a5daaceed03992d763302020834ea8e17dd
> Author: Jimi Xenidis 
> Date:   Mon Nov 5 09:12:00 2012 -0600
> 
>   powerpc/dcr: Add 64-bit DCR access methods.
> 
>   This patch adds the ability to make 64-bit Device Control Register
>   (DCR) accesses.
> 
>   Signed-off-by: Jimi Xenidis 
> 
> commit a763b3f8453b3bd83d7dded8c6644939863af430
> Author: Jimi Xenidis 
> Date:   Thu Nov 29 12:49:24 2012 -0500
> 
>   powerpc/boot: Add a "spin_threads" hook to platform_ops
> 
>   It is useful for the boot program to arrange for all secondary cpus
>   and threads to enter the kernel in a "kexec" fashion.  This hook makes
>   it possible.
> 
>   Signed-off-by: Jimi Xenidis 
> 
> commit 391e43393380b514d4d02a42d059619542c7597b
> Author: Jimi Xenidis 
> Date:   Thu Nov 29 13:01:23 2012 -0500
> 
>   powerpc/kexec: Add kexec "hold" support for Book3e processors
> 
>   This patch add two items:
>   1) Book3e requires that GPR4 survive the "hold" process, so we make
>  sure that happens.
>   2) Book3e has no real mode, and the hold code exploits this.  Since
>  these processors ares always translated, we arrange for the kexeced
>  threads to enter the hold code using the normal kernel 
>>> linear mapping.
> 
>   Signed-off-by: Jimi Xenidis 
> 
> commit f6e3c1f706cb6922349d639a74ff6c50acc8b9f8
> Author: Jimi Xenidis 
> Date:   Wed Dec 5 13:41:25 2012 -0500
> 
>   powerpc: Remove unecessary VSX symbols
> 
>   The symbol THREAD_VSR0 is defined to be the same as THREAD_FPR0.  Its
>   presence causes build issues with more complex configurations.
> 
>   Signed-off-by: Jimi Xenidis 
> 
> commit 4e817bb42ec8e3d3689877528dd97c4286a870eb
> Author: Jimi Xenidis 
> Date:   Tue Nov 20 10:10:52 2012 -0600
> 
>   Blue Gene/Q wicke

Re: pci and pcie device-tree binding - range No cells

[Grant Likely]

On Mon, 10 Dec 2012 16:37:26 +0100, Michal Simek  wrote:
> On 12/10/2012 04:21 PM, Rob Herring wrote:
> > On 12/10/2012 09:05 AM, Michal Simek wrote:
> >> On 12/10/2012 03:26 PM, Rob Herring wrote:
> >>> On 12/10/2012 06:20 AM, Michal Simek wrote:
>  Hi Grant and others,
> 
>  I have a question regarding number of cells in ranges property
>  for pci and pcie nodes.
> 
>  Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts,
>  sequoia.dts, etc)
>  but also 6 cells format too (mpc832x_mds.dts)
> 
>  Here is shown 6 cells ranges format and describe
>  http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
> 
>  And also in documentation in the linux
>  Documentation/devicetree/bindings/pci/83xx-512x-pci.txt
> 
>  Both format uses:
>  #size-cells = <2>;
>  #address-cells = <3>;
> 
>  What is valid format?
> >>>
> >>> Both. 7 cells are valid when the host (parent) bus is 64-bit and 6 cells
> >>> are valid when the host bus is 32-bit. The ranges property is < >>> address>  >. The parent address #address-cells is
> >>> taken from the parent node.
> >>
> >> Ok. Got it.
> >>
> >> Here is what we use on zynq and microblaze - both 32bit which should be
> >> fine.
> >>
> >>  ps7_axi_interconnect_0: axi@0 {
> >>  #address-cells = <1>;
> >>  #size-cells = <1>;
> >>  axi_pcie_0: axi-pcie@5000 {
> >>  #address-cells = <3>;
> >>  #size-cells = <2>;
> >>  compatible = "xlnx,axi-pcie-1.05.a";
> >>  ranges = < 0x0200 0 0x6000 0x6000 0 0x1000 >;
> >>  ...
> >>  }
> >>  }
> >>
> >> What I am wondering is pci_process_bridge_OF_ranges() at
> >> arch/powerpc/kernel/pci-common.c
> >> where there are used some hardcoded values which should be probably
> >> loaded from device-tree.
> >>
> >> For example:
> >> 683 int np = pna + 5;
> >> ...
> >> 702 pci_addr = of_read_number(ranges + 1, 2);
> >> 703 cpu_addr = of_translate_address(dev, ranges + 3);
> >> 704 size = of_read_number(ranges + pna + 3, 2);
> >
> > These would always be correct whether you have 6 or 7 cells. pna is the
> > parent bus address cells size. The pci address is fixed at 3 cells.
> 
> Sorry for my pci ignorance (have never got hw for mb/zynq)
> I just want to get better overview how we should we our drivers to be 
> compatible.
> 
> Does it mean that pci is supposed be always 64 bit wide?
> And there is no option to have just 32bit values.

Yes, PCIe addressing is always 64 bits wide. Even on 32bit PCI systems
we use 64 bit PCI addressing in the device tree.

g.

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

Re: pci and pcie device-tree binding - range No cells

[Grant Likely]

On Mon, 10 Dec 2012 09:21:51 -0600, Rob Herring  wrote:
> On 12/10/2012 09:05 AM, Michal Simek wrote:
> > On 12/10/2012 03:26 PM, Rob Herring wrote:
> >> On 12/10/2012 06:20 AM, Michal Simek wrote:
> >>> Hi Grant and others,
> >>>
> >>> I have a question regarding number of cells in ranges property
> >>> for pci and pcie nodes.
> >>>
> >>> Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts,
> >>> sequoia.dts, etc)
> >>> but also 6 cells format too (mpc832x_mds.dts)
> >>>
> >>> Here is shown 6 cells ranges format and describe
> >>> http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
> >>>
> >>> And also in documentation in the linux
> >>> Documentation/devicetree/bindings/pci/83xx-512x-pci.txt
> >>>
> >>> Both format uses:
> >>> #size-cells = <2>;
> >>> #address-cells = <3>;
> >>>
> >>> What is valid format?
> >>
> >> Both. 7 cells are valid when the host (parent) bus is 64-bit and 6 cells
> >> are valid when the host bus is 32-bit. The ranges property is < >> address>  >. The parent address #address-cells is
> >> taken from the parent node.
> > 
> > Ok. Got it.
> > 
> > Here is what we use on zynq and microblaze - both 32bit which should be
> > fine.
> > 
> > ps7_axi_interconnect_0: axi@0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > axi_pcie_0: axi-pcie@5000 {
> > #address-cells = <3>;
> > #size-cells = <2>;
> > compatible = "xlnx,axi-pcie-1.05.a";
> > ranges = < 0x0200 0 0x6000 0x6000 0 0x1000 >;
> > ...
> > }
> > }
> > 
> > What I am wondering is pci_process_bridge_OF_ranges() at
> > arch/powerpc/kernel/pci-common.c
> > where there are used some hardcoded values which should be probably
> > loaded from device-tree.
> > 
> > For example:
> > 683 int np = pna + 5;
> > ...
> > 702 pci_addr = of_read_number(ranges + 1, 2);
> > 703 cpu_addr = of_translate_address(dev, ranges + 3);
> > 704 size = of_read_number(ranges + pna + 3, 2);
> 
> These would always be correct whether you have 6 or 7 cells. pna is the
> parent bus address cells size. The pci address is fixed at 3 cells.
> 
> > 
> > 
> > Unfortunately we have copied it to microblaze.
> 
> I look at the PCI DT code in powerpc and see a whole bunch of code that
> seems like it should be common. The different per arch pci structs
> complicates that. No one has really gotten to looking at PCI DT on ARM
> yet except you and Thierry for Tegra. We definitely don't want to create
> a 3rd copy. Starting the process of moving it to something like
> drivers/pci/pci-of.c would be great.

A lot of it should be common. The microblaze code is a copy of the
powerpc version. I'll strongly nack any attempt to add a third!  :-)

drivers/pci/pci-of.c would be good. I'd also accept drivers/of/pci.c
which might actually be a good idea in the short term so that it gets
appropriate supervision while being generalized before being moved into
the pci directory.

g.

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

Re: pci and pcie device-tree binding - range No cells

[Benjamin Herrenschmidt]

On Mon, 2012-12-10 at 21:43 +, Grant Likely wrote:
> > Sorry for my pci ignorance (have never got hw for mb/zynq)
> > I just want to get better overview how we should we our drivers to
> be compatible.
> > 
> > Does it mean that pci is supposed be always 64 bit wide?
> > And there is no option to have just 32bit values.
> 
> Yes, PCIe addressing is always 64 bits wide. Even on 32bit PCI systems
> we use 64 bit PCI addressing in the device tree.

Right. The size & format of an address cell for PCI is specified in the
OF PCI bindings and we follow that binding. It's always 3 cells.

Cheers,
Ben.


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

Re: pci and pcie device-tree binding - range No cells

[Mitch Bradley]

On 12/10/2012 12:38 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-12-10 at 21:43 +, Grant Likely wrote:
>>> Sorry for my pci ignorance (have never got hw for mb/zynq)
>>> I just want to get better overview how we should we our drivers to
>> be compatible.
>>>
>>> Does it mean that pci is supposed be always 64 bit wide?
>>> And there is no option to have just 32bit values.
>>
>> Yes, PCIe addressing is always 64 bits wide. Even on 32bit PCI systems
>> we use 64 bit PCI addressing in the device tree.
> 
> Right. The size & format of an address cell for PCI is specified in the
> OF PCI bindings and we follow that binding. It's always 3 cells.

.. and the reason why it must be 3 cells, even if the host PCI bus only
supports 32-bit addressing, is because a plug-in PCI card has no way of
knowing what the host supports.


> 
> Cheers,
> Ben.
> 
> 
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: pci and pcie device-tree binding - range No cells

[Rob Herring]

On 12/10/2012 11:15 AM, Thomas Petazzoni wrote:
> Dear Michal Simek,
> 
> On Mon, 10 Dec 2012 17:05:13 +0100, Michal Simek wrote:
> 
>> CC: Thomas: I think it will be interesting to see this discussion
>> because you are using size-cell/address-cells equal 1.
>> http://www.spinics.net/lists/arm-kernel/msg211839.html
> 
> Thanks for Cc'ing me.
> 
> The thing is that on Marvell SoCs, we don't need to describe statically
> in the Device Tree the translation between CPU addresses and PCI device
> addresses, because those translations are set up dynamically at run
> time through address decoding windows.
> 
> Marvell SoCs have up to 20 configurable address windows, which allow
> you, at run time, to say "I would like the range from physical address
> 0x to 0x to correspond to the PCIe device in port 1,
> lane 2, or to the NAND, or to this or that device". Therefore, in the
> PCIe driver I proposed for the Armada 370/XP SoCs [1], there is no need
> to encode all those ranges statically in the DT.

That's not a unique feature. I'm not sure if any powerpc systems do that
though.

> The only "ranges" property I'm using is to allow the DT sub-nodes
> describing each PCIe port/lane to access the CPU registers that allow
> to see if the PCIe link is up or down, access the PCI configuration
> space and so on. So all ranges in my "ranges" property correspond to
> normal CPU registers, like the one you would put in the "reg" property
> for any device. The fact that those devices are PCIe is really
> orthogonal here.

That doesn't really sound right.

> Of course, I have no idea if I'm doing a correct usage of the DT, but I
> certainly don't need those 6 values ranges with bits to say if it's I/O
> space, memory space, bus number, device number and so on. The physical
> addresses at which I'm setting up my address decoding windows are
> decided dynamically at runtime, depending on the number of PCIe devices
> that are found in the different PCIe slots (for now, those windows have
> a statically defined size, but I'd ideally would like to size them to
> match exactly the size of the PCIe device memory, in order to avoid
> wasting physical address space, but I haven't found how to get the size
> needed for each PCIe device during the ARM pcibios initialization
> sequence).

I don't think deviating from the normal binding is the right approach.
Perhaps the host driver should fill in the ranges property with the
addresses it uses. Then any child devices will get the right address
translation.

Also, while the h/w may support practically any config, there are
practical constraints of what Linux will use like there's no reason to
support more than 64K i/o space. PCI memory addresses generally start at
0x10. You probably don't need more than 1 memory window per root
complex (although prefetchable memory may also be needed).

You could let the DT settings drive the address window configuration.

Rob

> For those willing to have a look at the PCIe patch set for Armada
> 370/XP, see:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/136455.html.
> The core of the PCIe driver and its DT binding documentation is at
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/136711.html.
> 
> Thanks a lot for your comments,
> 
> Thomas
> 
> [1] that I hope to extend to cover previous Marvell SoCs as well, they
> work basically the same way
> 

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

Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.

[Scott Wood]

On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote:



> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, December 04, 2012 11:53 PM
> To: Sethi Varun-B16395
> Cc: Wood Scott-B07421; Joerg Roedel; linux-ker...@vger.kernel.org;
> io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;  
Tabi

> Timur-B04825
> Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes
> required by fsl PAMU driver.
>
> On 12/04/2012 05:53:33 AM, Sethi Varun-B16395 wrote:
> >
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Monday, December 03, 2012 10:34 PM
> > > To: Sethi Varun-B16395
> > > Cc: Joerg Roedel; linux-ker...@vger.kernel.org;  
iommu@lists.linux-
> > > foundation.org; Wood Scott-B07421;  
linuxppc-dev@lists.ozlabs.org;

> > Tabi
> > > Timur-B04825
> > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain  
attributes

> > > required by fsl PAMU driver.
> > >
> > > On 12/03/2012 10:57:29 AM, Sethi Varun-B16395 wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: iommu-boun...@lists.linux-foundation.org  
[mailto:iommu-
> > > > > boun...@lists.linux-foundation.org] On Behalf Of Joerg  
Roedel

> > > > > Sent: Sunday, December 02, 2012 7:33 PM
> > > > > To: Sethi Varun-B16395
> > > > > Cc: linux-ker...@vger.kernel.org;
> > io...@lists.linux-foundation.org;
> > > > Wood
> > > > > Scott-B07421; linuxppc-dev@lists.ozlabs.org; Tabi  
Timur-B04825

> > > > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain
> > attributes
> > > > > required by fsl PAMU driver.
> > > > >
> > > > > Hmm, we need to work out a good abstraction for this.
> > > > >
> > > > > On Tue, Nov 20, 2012 at 07:24:56PM +0530, Varun Sethi wrote:
> > > > > > Added the following domain attributes required by FSL PAMU
> > driver:
> > > > > > 1. Subwindows field added to the iommu domain geometry
> > attribute.
> > > > >
> > > > > Are the Subwindows mapped with full size or do you map only
> > parts
> > > > of the
> > > > > subwindows?
> > > > >
> > > > [Sethi Varun-B16395] It's possible to map a part of the  
subwindow

> > i.e.
> > > > size of the mapping can be less than the sub window size.
> > > >
> > > > > > +  * This attribute indicates number of DMA subwindows
> > > supported
> > > > by
> > > > > > +  * the geometry. If there is a single window that maps
> > the
> > > > entire
> > > > > > +  * geometry, attribute must be set to "1". A value of
> > "0"
> > > > implies
> > > > > > +  * that this mechanism is not used at all(normal paging
> > is
> > > > used).
> > > > > > +  * Value other than* "0" or "1" indicates the actual
> > number
> > > of
> > > > > > +  * subwindows.
> > > > > > +  */
> > > > >
> > > > > This semantic is ugly, how about a feature detection  
mechanism?

> > > > >
> > > > [Sethi Varun-B16395] A feature mechanism to query the type of
> > IOMMU?
> > >
> > > A feature mechanism to determine whether this subwindow  
mechanism is

> > > available, and what the limits are.
> > >
> > So, we use the IOMMU capability interface to find out if IOMMU
> > supports sub windows or not, right? But still number of sub  
windows
> > would be specified as a part of the geometry and the valid value  
for

> > sub windows would  0,1 or actual number of sub windows.
>
> How does a user of the interface find out what values are possible  
for
> the "actual number of subwindows"?  How does a user of the  
interface find
> out whether there are any limitations on specifying a value of zero  
(in

> the case of PAMU, that would be a maximum 1 MiB naturally-aligned
> aperture to support arbitrary 4KiB mappings)?
How about if we say that the default value for subwindows is zero and  
this what you get when you read the geometry (iommu_get_attr) after  
initializing the domain? In that case the user would know that  
implication of setting subwindows to zero with respect to the  
aperture size.


So it would default to the maximum aperture size possible with no  
subwindows?  That might be OK, though is there a way to reset the  
domain later on to get back to that informational state?


How about finding out the maximum number of subwindows?

Also, should we introduce an additional API like "iommu_check_attr",  
which the user can use to validate the attribute value. For example  
in case of geometry, the user can fill up the structure and pass it  
to the iommu driver in order to verify the aperture and subwindows  
field.


Doesn't the current API raise an error if you do something  
unsupported?  In any case I don't think making a series of guesses and  
seeing which ones are accepted is a good substitute for being able to  
simply read out the relevant parameters.


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

Re: [PATCH 5/6] powerpc: Macros for saving/restore PPR

[Michael Ellerman]

On Mon, 2012-11-26 at 17:49 -0800, Haren Myneni wrote:
> On 11/22/2012 07:39 PM, Michael Neuling wrote:
> > Haren Myneni  wrote:
> > 
> >> [PATCH 5/6] powerpc: Macros for saving/restore PPR
> > 
> > Maybe we should change the names 
> >   HTM_MEDIUM_NO_PPR  => HTM_MEDIUM_PPR_DISCARD   and
> >   HTM_MEDIUM_HAS_PPR => HTM_MEDIUM_PPR_SAVE
> > But now I'm heading into bike shedding territory... plus I think I
> > suggested the names you have currently, so I'm feeling a bit dumb now
> > :-)
> 
> No problem, We can change these macro names if HTM_MEDIUM_PPR_DISCARD/
> HTM_MEDIUM_PPR_SAVE gives better description.

Yes, those names are better.

Even though they're macros they act as functions, so they should
preferably be named using a verb.

cheers

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

[stable] [PATCH] powerpc/ptrace: Fix build with gcc 4.6

[Michael Neuling]

From: Benjamin Herrenschmidt 

gcc (rightfully) complains that we are accessing beyond the
end of the fpr array (we do, to access the fpscr).

The only sane thing to do (whether anything in that code can be
called remotely sane is debatable) is to special case fpscr and
handle it as a separate statement.

I initially tried to do it it by making the array access conditional
to index < PT_FPSCR and using a 3rd else leg but for some reason gcc
was unable to understand it and still spewed the warning.

So I ended up with something a tad more intricated but it seems to
build on 32-bit and on 64-bit with and without VSX.

commit e69b742a6793dc5bf16f6eedca534d4bc10d68b2

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Michael Neuling 
cc: sta...@vger.kernel.org (for 3.0 only)

--- 
Mr Stable: This seemed to miss 3.0 stable, please add...

diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 05b7dd2..18447c4 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1497,9 +1497,14 @@ long arch_ptrace(struct task_struct *child, long request,
if (index < PT_FPR0) {
tmp = ptrace_get_reg(child, (int) index);
} else {
+   unsigned int fpidx = index - PT_FPR0;
+
flush_fp_to_thread(child);
-   tmp = ((unsigned long *)child->thread.fpr)
-   [TS_FPRWIDTH * (index - PT_FPR0)];
+   if (fpidx < (PT_FPSCR - PT_FPR0))
+   tmp = ((unsigned long *)child->thread.fpr)
+   [fpidx * TS_FPRWIDTH];
+   else
+   tmp = child->thread.fpscr.val;
}
ret = put_user(tmp, datalp);
break;
@@ -1525,9 +1530,14 @@ long arch_ptrace(struct task_struct *child, long request,
if (index < PT_FPR0) {
ret = ptrace_put_reg(child, index, data);
} else {
+   unsigned int fpidx = index - PT_FPR0;
+
flush_fp_to_thread(child);
-   ((unsigned long *)child->thread.fpr)
-   [TS_FPRWIDTH * (index - PT_FPR0)] = data;
+   if (fpidx < (PT_FPSCR - PT_FPR0))
+   ((unsigned long *)child->thread.fpr)
+   [fpidx * TS_FPRWIDTH] = data;
+   else
+   child->thread.fpscr.val = data;
ret = 0;
}
break;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.

[Sethi Varun-B16395]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, December 11, 2012 6:31 AM
> To: Sethi Varun-B16395
> Cc: Wood Scott-B07421; Joerg Roedel; linux-ker...@vger.kernel.org;
> io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; Tabi
> Timur-B04825
> Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes
> required by fsl PAMU driver.
> 
> On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote:
> >
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, December 04, 2012 11:53 PM
> > > To: Sethi Varun-B16395
> > > Cc: Wood Scott-B07421; Joerg Roedel; linux-ker...@vger.kernel.org;
> > > io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
> > Tabi
> > > Timur-B04825
> > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes
> > > required by fsl PAMU driver.
> > >
> > > On 12/04/2012 05:53:33 AM, Sethi Varun-B16395 wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Monday, December 03, 2012 10:34 PM
> > > > > To: Sethi Varun-B16395
> > > > > Cc: Joerg Roedel; linux-ker...@vger.kernel.org;
> > iommu@lists.linux-
> > > > > foundation.org; Wood Scott-B07421;
> > linuxppc-dev@lists.ozlabs.org;
> > > > Tabi
> > > > > Timur-B04825
> > > > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain
> > attributes
> > > > > required by fsl PAMU driver.
> > > > >
> > > > > On 12/03/2012 10:57:29 AM, Sethi Varun-B16395 wrote:
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: iommu-boun...@lists.linux-foundation.org
> > [mailto:iommu-
> > > > > > > boun...@lists.linux-foundation.org] On Behalf Of Joerg
> > Roedel
> > > > > > > Sent: Sunday, December 02, 2012 7:33 PM
> > > > > > > To: Sethi Varun-B16395
> > > > > > > Cc: linux-ker...@vger.kernel.org;
> > > > io...@lists.linux-foundation.org;
> > > > > > Wood
> > > > > > > Scott-B07421; linuxppc-dev@lists.ozlabs.org; Tabi
> > Timur-B04825
> > > > > > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain
> > > > attributes
> > > > > > > required by fsl PAMU driver.
> > > > > > >
> > > > > > > Hmm, we need to work out a good abstraction for this.
> > > > > > >
> > > > > > > On Tue, Nov 20, 2012 at 07:24:56PM +0530, Varun Sethi wrote:
> > > > > > > > Added the following domain attributes required by FSL PAMU
> > > > driver:
> > > > > > > > 1. Subwindows field added to the iommu domain geometry
> > > > attribute.
> > > > > > >
> > > > > > > Are the Subwindows mapped with full size or do you map only
> > > > parts
> > > > > > of the
> > > > > > > subwindows?
> > > > > > >
> > > > > > [Sethi Varun-B16395] It's possible to map a part of the
> > subwindow
> > > > i.e.
> > > > > > size of the mapping can be less than the sub window size.
> > > > > >
> > > > > > > > +* This attribute indicates number of DMA subwindows
> > > > > supported
> > > > > > by
> > > > > > > > +* the geometry. If there is a single window that maps
> > > > the
> > > > > > entire
> > > > > > > > +* geometry, attribute must be set to "1". A value of
> > > > "0"
> > > > > > implies
> > > > > > > > +* that this mechanism is not used at all(normal paging
> > > > is
> > > > > > used).
> > > > > > > > +* Value other than* "0" or "1" indicates the actual
> > > > number
> > > > > of
> > > > > > > > +* subwindows.
> > > > > > > > +*/
> > > > > > >
> > > > > > > This semantic is ugly, how about a feature detection
> > mechanism?
> > > > > > >
> > > > > > [Sethi Varun-B16395] A feature mechanism to query the type of
> > > > IOMMU?
> > > > >
> > > > > A feature mechanism to determine whether this subwindow
> > mechanism is
> > > > > available, and what the limits are.
> > > > >
> > > > So, we use the IOMMU capability interface to find out if IOMMU
> > > > supports sub windows or not, right? But still number of sub
> > windows
> > > > would be specified as a part of the geometry and the valid value
> > for
> > > > sub windows would  0,1 or actual number of sub windows.
> > >
> > > How does a user of the interface find out what values are possible
> > for
> > > the "actual number of subwindows"?  How does a user of the
> > interface find
> > > out whether there are any limitations on specifying a value of zero
> > (in
> > > the case of PAMU, that would be a maximum 1 MiB naturally-aligned
> > > aperture to support arbitrary 4KiB mappings)?
> > How about if we say that the default value for subwindows is zero and
> > this what you get when you read the geometry (iommu_get_attr) after
> > initializing the domain? In that case the user would know that
> > implication of setting subwindows to zero with respect to the aperture
> > size.
> 
> So it would default to the maximum aperture size possible with no
> subwindows?  That might be OK, though is there a way to reset the domain
> later on to get back to that informational state?
> 
[Sethi Varun-B16395] Yes, that can be done via

Re: [PATCH v2 1/4] kprobes/powerpc: Do not disable External interrupts during single step

[Suzuki K. Poulose]

On 12/03/2012 08:37 PM, Suzuki K. Poulose wrote:

From: Suzuki K. Poulose 

External/Decrement exceptions have lower priority than the Debug Exception.
So, we don't have to disable the External interrupts before a single step.
However, on BookE, Critical Input Exception(CE) has higher priority than a
Debug Exception. Hence we mask them.

Signed-off-by:  Suzuki K. Poulose 
Cc: Sebastian Andrzej Siewior 
Cc: Ananth N Mavinakaynahalli 
Cc: Kumar Gala 
Cc: linuxppc-...@ozlabs.org
---
  arch/powerpc/kernel/kprobes.c |   10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index e88c643..4901b34 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -104,13 +104,13 @@ void __kprobes arch_remove_kprobe(struct kprobe *p)

  static void __kprobes prepare_singlestep(struct kprobe *p, struct pt_regs 
*regs)
  {
-   /* We turn off async exceptions to ensure that the single step will
-* be for the instruction we have the kprobe on, if we dont its
-* possible we'd get the single step reported for an exception handler
-* like Decrementer or External Interrupt */
-   regs->msr &= ~MSR_EE;
regs->msr |= MSR_SINGLESTEP;
  #ifdef CONFIG_PPC_ADV_DEBUG_REGS
+   /*
+* We turn off Critical Input Exception(CE) to ensure that the single
+* step will be for the instruction we have the probe on; if we don't,
+* it is possible we'd get the single step reported for CE.
+*/
regs->msr &= ~MSR_CE;
mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM);
  #ifdef CONFIG_PPC_47x



Ben, Kumar,

Could you please review this patch ?


Thanks
Suzuki

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

Re: Understanding how kernel updates MMU hash table

[Pegasus11]

Hi ben

Now that many things are becoming clear let me sum up my understanding until
this point. Do correct it if there are mistakes.

1. Linux page table structure (PGD, PUD, PMD and PTE) is directly used in
case of architecture that lend themselves to such a tree structure for
maintaining virtual memory information. Otherwise Linux needs to maintain
two seperate constructs like it does in case of PowerPC. Right?
2. PowerPC's hash table as you said is pretty large. However isn't it still
smaller than Linux's VM infrastructure such that the chances of it being
'FULL' are a lot more. It is also possible that there could be two entries
in the table that points to the same Real address. Like a page being shared
by two processes?

My main concern here is to understand if having such an inverted page table
aka the hash table helps us in any way when doing TLB flushes. You mentioned
and I also read  in a paper by Paul Mackerras that every Linux PTE (LPTE) in
case of ppc64 contains 4 extra bits that help us to get to the very slot in
the hash table that houses the corresponding hashtable PTE(HPTE). Now this
(at least to me) is smartness on the part of the kernel and I do not think
the architecture per se is doing us any favor by having that hash table
right? Or am I missing something here? 

His paper is (or rather was) on how one can optimize the Linux ppc kernel
and time and again he mentions the fact that one can first record the LPTEs
being invalidated and then remove the corresponding HPTEs in a batched
format. In his own words "Alternatively, it would be possible to make a list
of virtual addresses when LPTEs are changed and then use that list in the
TLB flush routines to avoid the search through the Linux page tables". So do
we skip looking for the corresponding LPTEs or perhaps we've already
invalidated them and we remove the corresponding HPTEs in a batch as you
mentioned earlier?? Could you shed some light on how this optimization
actually developed over time? He had results for an "immediate update"
kernel and "batched update" kernel for both ppc32 and ppc64. For ppc32 the
batched update is actually a bit worse than immediate update however for
ppc64, the batched update performs better than immediate update. What
exactly is helping ppc64 perform better with the so called "batched update"?
Is it the encoding of the HPTE address in the LPTE as mentioned above? Or
some aspect of ppc64 that I am unaware of? :thinking:

Also on a generic note, how come we have 4 spare bits in the PTE for 64bit
address space? Large pages perhaps?
-- 
View this message in context: 
http://old.nabble.com/Understanding-how-kernel-updates-MMU-hash-table-tp34760537p34782747.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

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