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

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

[Shaohui Xie]

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 <Shaohui.Xie@freescale.com>
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: Chen Yuanquan <B41889@freescale.com>
---
changes for v2:
1. use a config option for using two zones (ZONE_DMA32 & ZONE_NORMAL) in
freescale 64 bit kernel.

 arch/powerpc/Kconfig      |    3 +++
 arch/powerpc/kernel/dma.c |   15 +++++++++++++++
 arch/powerpc/mm/mem.c     |    4 ++++
 3 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 352f416..a96fbbb 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -629,6 +629,9 @@ config ZONE_DMA
 	bool
 	default y
 
+config ZONE_DMA32
+	def_bool (PPC64 && PPC_FSL_BOOK3E)
+
 config NEED_DMA_MAP_STATE
 	def_bool (PPC64 || NOT_COHERENT_CACHE)
 
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 355b9d8..cbf5ac1 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -41,9 +41,24 @@ void *dma_direct_alloc_coherent(struct device *dev, size_t size,
 #else
 	struct page *page;
 	int node = dev_to_node(dev);
+#ifdef CONFIG_ZONE_DMA32
+	phys_addr_t top_ram_pfn = memblock_end_of_DRAM();
 
+	/*
+	 * check for crappy device which has dma_mask < ZONE_DMA, and
+	 * we are not going to support it, just warn and fail.
+	 */
+	if (*dev->dma_mask < DMA_BIT_MASK(31)) {
+		dev_err(dev, "Unsupported dma_mask 0x%llx\n", *dev->dma_mask);
+		return NULL;
+	}
 	/* ignore region specifiers */
+	flag  &= ~(__GFP_HIGHMEM | __GFP_DMA | __GFP_DMA32);
+	if (*dev->dma_mask < top_ram_pfn - 1)
+		flag |= __GFP_DMA32;
+#else
 	flag  &= ~(__GFP_HIGHMEM);
+#endif
 
 	page = alloc_pages_node(node, flag, get_order(size));
 	if (page == NULL)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index baaafde..2a11e49 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -280,6 +280,10 @@ void __init paging_init(void)
 #ifdef CONFIG_HIGHMEM
 	max_zone_pfns[ZONE_DMA] = lowmem_end_addr >> PAGE_SHIFT;
 	max_zone_pfns[ZONE_HIGHMEM] = top_of_ram >> PAGE_SHIFT;
+#elif defined CONFIG_ZONE_DMA32
+	max_zone_pfns[ZONE_DMA32] = min_t(phys_addr_t, top_of_ram,
+					1ull << 31) >> PAGE_SHIFT;
+	max_zone_pfns[ZONE_NORMAL] = top_of_ram >> PAGE_SHIFT;
 #else
 	max_zone_pfns[ZONE_DMA] = top_of_ram >> PAGE_SHIFT;
 #endif
-- 
1.6.4

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

[Kumar Gala]

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.
>=20
> So we split the memory to two zones: zone ZONE_DMA32 & ZONE_NORMAL, =
since
> we already allocate PCICSRBAR/PEXCSRBAR right below the 4G boundary =
(if the
> lowest PCI address is above 4G), so we constrain the DMA zone =
ZONE_DMA32
> to 2GB, also, we clear flag __GFP_DMA & __GFP_DMA32 and set =
__GFP_DMA32 only
> if the device's dma_mask < total memory size. By doing this, devices =
which
> cannot DMA all the memory will be limited to ZONE_DMA32, but devices =
which
> can DMA all the memory will not be affected by this limitation.
>=20
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
> Signed-off-by: Chen Yuanquan <B41889@freescale.com>
> ---
> changes for v2:
> 1. use a config option for using two zones (ZONE_DMA32 & ZONE_NORMAL) =
in
> freescale 64 bit kernel.
>=20
> arch/powerpc/Kconfig      |    3 +++
> arch/powerpc/kernel/dma.c |   15 +++++++++++++++
> arch/powerpc/mm/mem.c     |    4 ++++
> 3 files changed, 22 insertions(+), 0 deletions(-)

Ben,

What's the feeling of doing this on ppc64 always?=20

- k

>=20
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 352f416..a96fbbb 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -629,6 +629,9 @@ config ZONE_DMA
> 	bool
> 	default y
>=20
> +config ZONE_DMA32
> +	def_bool (PPC64 && PPC_FSL_BOOK3E)
> +
> config NEED_DMA_MAP_STATE
> 	def_bool (PPC64 || NOT_COHERENT_CACHE)
>=20
> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
> index 355b9d8..cbf5ac1 100644
> --- a/arch/powerpc/kernel/dma.c
> +++ b/arch/powerpc/kernel/dma.c
> @@ -41,9 +41,24 @@ void *dma_direct_alloc_coherent(struct device *dev, =
size_t size,
> #else
> 	struct page *page;
> 	int node =3D dev_to_node(dev);
> +#ifdef CONFIG_ZONE_DMA32
> +	phys_addr_t top_ram_pfn =3D memblock_end_of_DRAM();
>=20
> +	/*
> +	 * check for crappy device which has dma_mask < ZONE_DMA, and
> +	 * we are not going to support it, just warn and fail.
> +	 */
> +	if (*dev->dma_mask < DMA_BIT_MASK(31)) {
> +		dev_err(dev, "Unsupported dma_mask 0x%llx\n", =
*dev->dma_mask);
> +		return NULL;
> +	}
> 	/* ignore region specifiers */
> +	flag  &=3D ~(__GFP_HIGHMEM | __GFP_DMA | __GFP_DMA32);
> +	if (*dev->dma_mask < top_ram_pfn - 1)
> +		flag |=3D __GFP_DMA32;
> +#else
> 	flag  &=3D ~(__GFP_HIGHMEM);
> +#endif
>=20
> 	page =3D alloc_pages_node(node, flag, get_order(size));
> 	if (page =3D=3D NULL)
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index baaafde..2a11e49 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -280,6 +280,10 @@ void __init paging_init(void)
> #ifdef CONFIG_HIGHMEM
> 	max_zone_pfns[ZONE_DMA] =3D lowmem_end_addr >> PAGE_SHIFT;
> 	max_zone_pfns[ZONE_HIGHMEM] =3D top_of_ram >> PAGE_SHIFT;
> +#elif defined CONFIG_ZONE_DMA32
> +	max_zone_pfns[ZONE_DMA32] =3D min_t(phys_addr_t, top_of_ram,
> +					1ull << 31) >> PAGE_SHIFT;
> +	max_zone_pfns[ZONE_NORMAL] =3D top_of_ram >> PAGE_SHIFT;
> #else
> 	max_zone_pfns[ZONE_DMA] =3D top_of_ram >> PAGE_SHIFT;
> #endif
> --=20
> 1.6.4
>=20
>=20
> _______________________________________________
> 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

[Benjamin Herrenschmidt]

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 <Shaohui.Xie@freescale.com>
> > Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
> > Signed-off-by: Chen Yuanquan <B41889@freescale.com>
> > ---
> > changes for v2:
> > 1. use a config option for using two zones (ZONE_DMA32 & ZONE_NORMAL) in
> > freescale 64 bit kernel.
> > 

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 ?

Also how does Intel do it ? Do they have iommu and ZONE_DMA32 co-exist ?

Cheers,
Ben.

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

[Xie Shaohui-B21989]

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2ht
aWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBNb25kYXksIFNl
cHRlbWJlciAxMCwgMjAxMiA3OjM4IEFNDQo+IFRvOiBLdW1hciBHYWxhDQo+IENjOiBYaWUgU2hh
b2h1aS1CMjE5ODk7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnIGxpc3Q7IEh1IE1pbmdr
YWktDQo+IEIyMTI4NDsgQ2hlbiBZdWFucXVhbi1CNDE4ODkNCj4gU3ViamVjdDogUmU6IFtQQVRD
SF1bdjJdIHBvd2VycGMvbW06IHVzaW5nIHR3byB6b25lcyBmb3IgZnJlZXNjYWxlIDY0IGJpdA0K
PiBrZXJuZWwNCj4gDQo+IE9uIFRodSwgMjAxMi0wOC0zMCBhdCAxNTo0OSAtMDUwMCwgS3VtYXIg
R2FsYSB3cm90ZToNCj4gPiBPbiBBdWcgMjQsIDIwMTIsIGF0IDU6NTAgQU0sIFNoYW9odWkgWGll
IHdyb3RlOg0KPiA+DQo+ID4gPiBQb3dlclBDIHBsYXRmb3JtIG9ubHkgc3VwcG9ydHMgWk9ORV9E
TUEgem9uZSBmb3IgNjRiaXQga2VybmVsLCBzbw0KPiA+ID4gYWxsIHRoZSBtZW1vcnkgd2lsbCBi
ZSBwdXQgaW50byB0aGlzIHpvbmUuIElmIHRoZSBtZW1vcnkgc2l6ZSBpcw0KPiA+ID4gZ3JlYXRl
ciB0aGFuIHRoZSBkZXZpY2UncyBETUEgY2FwYWJpbGl0eSBhbmQgZGV2aWNlIHVzZXMNCj4gPiA+
IGRtYV9hbGxvY19jb2hlcmVudCB0byBhbGxvY2F0ZSBtZW1vcnksIGl0IHdpbGwgZ2V0IGFuIGFk
ZHJlc3Mgd2hpY2gNCj4gPiA+IGlzIG92ZXIgdGhlIGRldmljZSdzIERNQSBhZGRyZXNzaW5nLCB0
aGUgZGV2aWNlIHdpbGwgZmFpbC4NCj4gPiA+DQo+ID4gPiBTbyB3ZSBzcGxpdCB0aGUgbWVtb3J5
IHRvIHR3byB6b25lczogem9uZSBaT05FX0RNQTMyICYgWk9ORV9OT1JNQUwsDQo+ID4gPiBzaW5j
ZSB3ZSBhbHJlYWR5IGFsbG9jYXRlIFBDSUNTUkJBUi9QRVhDU1JCQVIgcmlnaHQgYmVsb3cgdGhl
IDRHDQo+ID4gPiBib3VuZGFyeSAoaWYgdGhlIGxvd2VzdCBQQ0kgYWRkcmVzcyBpcyBhYm92ZSA0
RyksIHNvIHdlIGNvbnN0cmFpbg0KPiA+ID4gdGhlIERNQSB6b25lIFpPTkVfRE1BMzIgdG8gMkdC
LCBhbHNvLCB3ZSBjbGVhciBmbGFnIF9fR0ZQX0RNQSAmDQo+ID4gPiBfX0dGUF9ETUEzMiBhbmQg
c2V0IF9fR0ZQX0RNQTMyIG9ubHkgaWYgdGhlIGRldmljZSdzIGRtYV9tYXNrIDwNCj4gPiA+IHRv
dGFsIG1lbW9yeSBzaXplLiBCeSBkb2luZyB0aGlzLCBkZXZpY2VzIHdoaWNoIGNhbm5vdCBETUEg
YWxsIHRoZQ0KPiA+ID4gbWVtb3J5IHdpbGwgYmUgbGltaXRlZCB0byBaT05FX0RNQTMyLCBidXQg
ZGV2aWNlcyB3aGljaCBjYW4gRE1BIGFsbA0KPiB0aGUgbWVtb3J5IHdpbGwgbm90IGJlIGFmZmVj
dGVkIGJ5IHRoaXMgbGltaXRhdGlvbi4NCj4gPiA+DQo+ID4gPiBTaWduZWQtb2ZmLWJ5OiBTaGFv
aHVpIFhpZSA8U2hhb2h1aS5YaWVAZnJlZXNjYWxlLmNvbT4NCj4gPiA+IFNpZ25lZC1vZmYtYnk6
IE1pbmdrYWkgSHUgPE1pbmdrYWkuaHVAZnJlZXNjYWxlLmNvbT4NCj4gPiA+IFNpZ25lZC1vZmYt
Ynk6IENoZW4gWXVhbnF1YW4gPEI0MTg4OUBmcmVlc2NhbGUuY29tPg0KPiA+ID4gLS0tDQo+ID4g
PiBjaGFuZ2VzIGZvciB2MjoNCj4gPiA+IDEuIHVzZSBhIGNvbmZpZyBvcHRpb24gZm9yIHVzaW5n
IHR3byB6b25lcyAoWk9ORV9ETUEzMiAmDQo+ID4gPiBaT05FX05PUk1BTCkgaW4gZnJlZXNjYWxl
IDY0IGJpdCBrZXJuZWwuDQo+ID4gPg0KPiANCj4gVGhlcmUgbXVzdCBoYXZlIGJlZW4gYSBtaXN1
bmRlcnN0YW5kaW5nLiBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGEgcnVudGltZQ0KPiBjaG9pY2Us
IHBvc3NpYmx5IGJ5IHRoZSBwbGF0Zm9ybSBjb2RlLiBBbnkgcmVhc29uIHRoYXQgY2FuJ3QgYmUg
ZG9uZSA/DQo+IA0KW1MuSF0gRG8geW91IG1lYW4gdGhpczoNCg0KcGh5c19hZGRyX3QgcGxhdGZv
cm1fZG1hX3NpemUgKG1heWJlIGEgZGVmYXVsdCB2YWx1ZSBzaG91bGQgYmUgdXNlZCwgdGhlbiBw
bGF0Zm9ybSBjb2RlIHdpbGwgY2hhbmdlIGl0KQ0KDQppZiAodG9wX29mX3JhbSA+IHBsYXRmb3Jt
X2RtYV9zaXplKQ0KCW1heF96b25lX3BmbnNbWk9ORV9ETUFdID0gcGxhdGZvcm1fZG1hX3NpemUg
Pj4gUEFHRV9TSElGVDsNCmVsc2UNCgltYXhfem9uZV9wZm5zW1pPTkVfRE1BXSA9IHRvcF9vZl9y
YW0gPj4gUEFHRV9TSElGVDsNCg0KbWF4X3pvbmVfcGZuc1taT05FX05PUk1BTF0gPSB0b3Bfb2Zf
cmFtID4+IFBBR0VfU0hJRlQ7DQoJDQo+IEFsc28gaG93IGRvZXMgSW50ZWwgZG8gaXQgPyANCltT
LkhdIGJlbG93IGFyZSBjb2RlcyBpbiBJbnRlbDoNCg0KNDAzIHZvaWQgX19pbml0IHpvbmVfc2l6
ZXNfaW5pdCh2b2lkKQ0KNDA0IHsgICAgICAgDQo0MDUgICAgICAgICB1bnNpZ25lZCBsb25nIG1h
eF96b25lX3BmbnNbTUFYX05SX1pPTkVTXTsNCjQwNiAgICAgICAgIA0KNDA3ICAgICAgICAgbWVt
c2V0KG1heF96b25lX3BmbnMsIDAsIHNpemVvZihtYXhfem9uZV9wZm5zKSk7DQo0MDggICAgICAg
ICAgICAgICAgIA0KNDA5ICNpZmRlZiBDT05GSUdfWk9ORV9ETUENCjQxMCAgICAgICAgIG1heF96
b25lX3BmbnNbWk9ORV9ETUFdICAgICAgICAgPSBNQVhfRE1BX1BGTjsNCjQxMSAjZW5kaWYNCjQx
MiAjaWZkZWYgQ09ORklHX1pPTkVfRE1BMzINCjQxMyAgICAgICAgIG1heF96b25lX3BmbnNbWk9O
RV9ETUEzMl0gICAgICAgPSBNQVhfRE1BMzJfUEZOOw0KNDE0ICNlbmRpZg0KNDE1ICAgICAgICAg
bWF4X3pvbmVfcGZuc1taT05FX05PUk1BTF0gICAgICA9IG1heF9sb3dfcGZuOw0KNDE2ICNpZmRl
ZiBDT05GSUdfSElHSE1FTQ0KNDE3ICAgICAgICAgbWF4X3pvbmVfcGZuc1taT05FX0hJR0hNRU1d
ICAgICA9IG1heF9wZm47DQo0MTggI2VuZGlmDQo0MTkgIA0KICAgICAgDQpGb3IgeDg2XzY0LCB0
aGVyZSBpcyBubyBDT05GSUdfSElHSE1FTSwgc28gdGhlcmUgd2lsbCBiZSB0aHJlZSB6b25lczog
DQpaT05FX0RNQS9aT05FX0RNQTMyL1pPTkVfTk9STUFMLg0KDQo+RG8gdGhleSBoYXZlIGlvbW11
IGFuZCBaT05FX0RNQTMyIGNvLWV4aXN0ID8NCg0KSSdtIG5vdCBmYW1pbGlhciB3aXRoIElPTU1V
LCBJIHJlYWQgc29tZSBrZXJuZWwgZG9jcywgaW4gRG9jdW1lbnRhdGlvbi9rZXJuZWwtcGFyYW1l
dGVycy50eHQsDQpUaGVyZSBhcmUgYW1kX2lvbW11ICYgaW50ZWxfaW9tbXUgYXZhaWxhYmxlLCBp
biBEb2N1bWVudGF0aW9uL3g4Ni94ODZfNjQvYm9vdC1vcHRpb25zLnR4dCwNCkl0IHNheXMgIiBD
dXJyZW50bHkgZm91ciB4ODYtNjQgUENJLURNQSBtYXBwaW5nIGltcGxlbWVudGF0aW9ucyBleGlz
dCIuIA0KDQpEb2VzIFBQQzY0IHN1cHBvcnQgSU9NTVUsIGhvdyB0byB1c2UgaXQ/DQoNCg0KQmVz
dCBSZWdhcmRzLCANClNoYW9odWkgWGllDQo=

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

[Xie Shaohui-B21989]

PiA+IE9uIFRodSwgMjAxMi0wOC0zMCBhdCAxNTo0OSAtMDUwMCwgS3VtYXIgR2FsYSB3cm90ZToN
Cj4gPiA+IE9uIEF1ZyAyNCwgMjAxMiwgYXQgNTo1MCBBTSwgU2hhb2h1aSBYaWUgd3JvdGU6DQo+
ID4gPg0KPiA+ID4gPiBQb3dlclBDIHBsYXRmb3JtIG9ubHkgc3VwcG9ydHMgWk9ORV9ETUEgem9u
ZSBmb3IgNjRiaXQga2VybmVsLCBzbw0KPiA+ID4gPiBhbGwgdGhlIG1lbW9yeSB3aWxsIGJlIHB1
dCBpbnRvIHRoaXMgem9uZS4gSWYgdGhlIG1lbW9yeSBzaXplIGlzDQo+ID4gPiA+IGdyZWF0ZXIg
dGhhbiB0aGUgZGV2aWNlJ3MgRE1BIGNhcGFiaWxpdHkgYW5kIGRldmljZSB1c2VzDQo+ID4gPiA+
IGRtYV9hbGxvY19jb2hlcmVudCB0byBhbGxvY2F0ZSBtZW1vcnksIGl0IHdpbGwgZ2V0IGFuIGFk
ZHJlc3MNCj4gPiA+ID4gd2hpY2ggaXMgb3ZlciB0aGUgZGV2aWNlJ3MgRE1BIGFkZHJlc3Npbmcs
IHRoZSBkZXZpY2Ugd2lsbCBmYWlsLg0KPiA+ID4gPg0KPiA+ID4gPiBTbyB3ZSBzcGxpdCB0aGUg
bWVtb3J5IHRvIHR3byB6b25lczogem9uZSBaT05FX0RNQTMyICYNCj4gPiA+ID4gWk9ORV9OT1JN
QUwsIHNpbmNlIHdlIGFscmVhZHkgYWxsb2NhdGUgUENJQ1NSQkFSL1BFWENTUkJBUiByaWdodA0K
PiA+ID4gPiBiZWxvdyB0aGUgNEcgYm91bmRhcnkgKGlmIHRoZSBsb3dlc3QgUENJIGFkZHJlc3Mg
aXMgYWJvdmUgNEcpLCBzbw0KPiA+ID4gPiB3ZSBjb25zdHJhaW4gdGhlIERNQSB6b25lIFpPTkVf
RE1BMzIgdG8gMkdCLCBhbHNvLCB3ZSBjbGVhciBmbGFnDQo+ID4gPiA+IF9fR0ZQX0RNQSAmDQo+
ID4gPiA+IF9fR0ZQX0RNQTMyIGFuZCBzZXQgX19HRlBfRE1BMzIgb25seSBpZiB0aGUgZGV2aWNl
J3MgZG1hX21hc2sgPA0KPiA+ID4gPiB0b3RhbCBtZW1vcnkgc2l6ZS4gQnkgZG9pbmcgdGhpcywg
ZGV2aWNlcyB3aGljaCBjYW5ub3QgRE1BIGFsbCB0aGUNCj4gPiA+ID4gbWVtb3J5IHdpbGwgYmUg
bGltaXRlZCB0byBaT05FX0RNQTMyLCBidXQgZGV2aWNlcyB3aGljaCBjYW4gRE1BDQo+ID4gPiA+
IGFsbA0KPiA+IHRoZSBtZW1vcnkgd2lsbCBub3QgYmUgYWZmZWN0ZWQgYnkgdGhpcyBsaW1pdGF0
aW9uLg0KPiA+ID4gPg0KPiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBTaGFvaHVpIFhpZSA8U2hhb2h1
aS5YaWVAZnJlZXNjYWxlLmNvbT4NCj4gPiA+ID4gU2lnbmVkLW9mZi1ieTogTWluZ2thaSBIdSA8
TWluZ2thaS5odUBmcmVlc2NhbGUuY29tPg0KPiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBDaGVuIFl1
YW5xdWFuIDxCNDE4ODlAZnJlZXNjYWxlLmNvbT4NCj4gPiA+ID4gLS0tDQo+ID4gPiA+IGNoYW5n
ZXMgZm9yIHYyOg0KPiA+ID4gPiAxLiB1c2UgYSBjb25maWcgb3B0aW9uIGZvciB1c2luZyB0d28g
em9uZXMgKFpPTkVfRE1BMzIgJg0KPiA+ID4gPiBaT05FX05PUk1BTCkgaW4gZnJlZXNjYWxlIDY0
IGJpdCBrZXJuZWwuDQo+ID4gPiA+DQo+ID4NCj4gPiBUaGVyZSBtdXN0IGhhdmUgYmVlbiBhIG1p
c3VuZGVyc3RhbmRpbmcuIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgYQ0KPiA+IHJ1bnRpbWUgY2hv
aWNlLCBwb3NzaWJseSBieSB0aGUgcGxhdGZvcm0gY29kZS4gQW55IHJlYXNvbiB0aGF0IGNhbid0
IGJlDQo+IGRvbmUgPw0KPiA+DQo+IFtTLkhdIERvIHlvdSBtZWFuIHRoaXM6DQo+IA0KPiBwaHlz
X2FkZHJfdCBwbGF0Zm9ybV9kbWFfc2l6ZSAobWF5YmUgYSBkZWZhdWx0IHZhbHVlIHNob3VsZCBi
ZSB1c2VkLCB0aGVuDQo+IHBsYXRmb3JtIGNvZGUgd2lsbCBjaGFuZ2UgaXQpDQo+IA0KPiBpZiAo
dG9wX29mX3JhbSA+IHBsYXRmb3JtX2RtYV9zaXplKQ0KPiAJbWF4X3pvbmVfcGZuc1taT05FX0RN
QV0gPSBwbGF0Zm9ybV9kbWFfc2l6ZSA+PiBQQUdFX1NISUZUOyBlbHNlDQo+IAltYXhfem9uZV9w
Zm5zW1pPTkVfRE1BXSA9IHRvcF9vZl9yYW0gPj4gUEFHRV9TSElGVDsNCj4gDQo+IG1heF96b25l
X3BmbnNbWk9ORV9OT1JNQUxdID0gdG9wX29mX3JhbSA+PiBQQUdFX1NISUZUOw0KPiANCj4gPiBB
bHNvIGhvdyBkb2VzIEludGVsIGRvIGl0ID8NCj4gW1MuSF0gYmVsb3cgYXJlIGNvZGVzIGluIElu
dGVsOg0KPiANCj4gNDAzIHZvaWQgX19pbml0IHpvbmVfc2l6ZXNfaW5pdCh2b2lkKQ0KPiA0MDQg
ew0KPiA0MDUgICAgICAgICB1bnNpZ25lZCBsb25nIG1heF96b25lX3BmbnNbTUFYX05SX1pPTkVT
XTsNCj4gNDA2DQo+IDQwNyAgICAgICAgIG1lbXNldChtYXhfem9uZV9wZm5zLCAwLCBzaXplb2Yo
bWF4X3pvbmVfcGZucykpOw0KPiA0MDgNCj4gNDA5ICNpZmRlZiBDT05GSUdfWk9ORV9ETUENCj4g
NDEwICAgICAgICAgbWF4X3pvbmVfcGZuc1taT05FX0RNQV0gICAgICAgICA9IE1BWF9ETUFfUEZO
Ow0KPiA0MTEgI2VuZGlmDQo+IDQxMiAjaWZkZWYgQ09ORklHX1pPTkVfRE1BMzINCj4gNDEzICAg
ICAgICAgbWF4X3pvbmVfcGZuc1taT05FX0RNQTMyXSAgICAgICA9IE1BWF9ETUEzMl9QRk47DQo+
IDQxNCAjZW5kaWYNCj4gNDE1ICAgICAgICAgbWF4X3pvbmVfcGZuc1taT05FX05PUk1BTF0gICAg
ICA9IG1heF9sb3dfcGZuOw0KPiA0MTYgI2lmZGVmIENPTkZJR19ISUdITUVNDQo+IDQxNyAgICAg
ICAgIG1heF96b25lX3BmbnNbWk9ORV9ISUdITUVNXSAgICAgPSBtYXhfcGZuOw0KPiA0MTggI2Vu
ZGlmDQo+IDQxOQ0KPiANCj4gRm9yIHg4Nl82NCwgdGhlcmUgaXMgbm8gQ09ORklHX0hJR0hNRU0s
IHNvIHRoZXJlIHdpbGwgYmUgdGhyZWUgem9uZXM6DQo+IFpPTkVfRE1BL1pPTkVfRE1BMzIvWk9O
RV9OT1JNQUwuDQo+IA0KW1MuSF0gSGVsbG8sIEJlbiwNCg0KSSBoYXZlIHNvbWUgcXVlc3Rpb25z
LCB0aG91Z2ggSSdtIHN0aWxsIGV4cGVjdGluZyB5b3VyIGNvbW1lbnRzLg0KUFBDIGRvZXMgbm90
IGhhdmUgWk9ORV9ETUEzMiBieSBkZWZhdWx0LCBpZiB3ZSB3YW50IHRvIHVzZSBpdCwgd2UgbmVl
ZCB0byBhZGQgImNvbmZpZyBaT05FX0RNQTMyIiBpbiBLY29uZmlnIGZpcnN0Lg0KSWYgc2V0dGlu
ZyBtdWx0aXBsZSB6b25lcyB3aXRob3V0IFpPTkVfRE1BLCBrbWFsbG9jIGluICJpbmNsdWRlL2xp
bnV4L3NsYWJfZGVmLmgiIHdpbGwgZmFpbCBpZiBpdCB1c2VzIGZsYWcgR0ZQX0RNQS4NCkZvciB0
aGUgcnVudGltZSBjaG9pY2UgaW4gNjQtYml0IGtlcm5lbCwgd2hhdCBleGFjdGx5IG11bHRpcGxl
IHpvbmVzIHNob3VsZCBiZSB1c2VkPw0KIlpPTkVfRE1BICYgWk9ORV9OT1JNQUwiIG9yICJaT05F
X0RNQSAmIFpPTkVfRE1BMzIgJiBaT05FX05PUk1BTCI/DQpUaGVuIHdoYXQgdGhlIHNpemUgc2hv
dWxkIGJlIHNldCBmb3IgdGhlbSByZXNwZWN0aXZlbHk/DQoNClBsZWFzZSBjb21tZW50LCBUaGFu
a3MhDQoNCg0KQmVzdCBSZWdhcmRzLCANClNoYW9odWkgWGllDQo=

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

[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:
>>>>=20
>>>>> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so
>>>>> all the memory will be put into this zone. If the memory size is
>>>>> greater than the device's DMA capability and device uses
>>>>> dma_alloc_coherent to allocate memory, it will get an address
>>>>> which is over the device's DMA addressing, the device will fail.
>>>>>=20
>>>>> So we split the memory to two zones: zone ZONE_DMA32 &
>>>>> ZONE_NORMAL, since we already allocate PCICSRBAR/PEXCSRBAR right
>>>>> below the 4G boundary (if the lowest PCI address is above 4G), so
>>>>> we constrain the DMA zone ZONE_DMA32 to 2GB, also, we clear flag
>>>>> __GFP_DMA &
>>>>> __GFP_DMA32 and set __GFP_DMA32 only if the device's dma_mask <
>>>>> total memory size. By doing this, devices which cannot DMA all the
>>>>> memory will be limited to ZONE_DMA32, but devices which can DMA
>>>>> all
>>> the memory will not be affected by this limitation.
>>>>>=20
>>>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>>>> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
>>>>> Signed-off-by: Chen Yuanquan <B41889@freescale.com>
>>>>> ---
>>>>> changes for v2:
>>>>> 1. use a config option for using two zones (ZONE_DMA32 &
>>>>> ZONE_NORMAL) in freescale 64 bit kernel.
>>>>>=20
>>>=20
>>> There must have been a misunderstanding. I think this should be a
>>> runtime choice, possibly by the platform code. Any reason that can't =
be
>> done ?
>>>=20
>> [S.H] Do you mean this:
>>=20
>> phys_addr_t platform_dma_size (maybe a default value should be used, =
then
>> platform code will change it)
>>=20
>> if (top_of_ram > platform_dma_size)
>> 	max_zone_pfns[ZONE_DMA] =3D platform_dma_size >> PAGE_SHIFT; =
else
>> 	max_zone_pfns[ZONE_DMA] =3D top_of_ram >> PAGE_SHIFT;
>>=20
>> max_zone_pfns[ZONE_NORMAL] =3D top_of_ram >> PAGE_SHIFT;
>>=20
>>> Also how does Intel do it ?
>> [S.H] below are codes in Intel:
>>=20
>> 403 void __init zone_sizes_init(void)
>> 404 {
>> 405         unsigned long max_zone_pfns[MAX_NR_ZONES];
>> 406
>> 407         memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
>> 408
>> 409 #ifdef CONFIG_ZONE_DMA
>> 410         max_zone_pfns[ZONE_DMA]         =3D MAX_DMA_PFN;
>> 411 #endif
>> 412 #ifdef CONFIG_ZONE_DMA32
>> 413         max_zone_pfns[ZONE_DMA32]       =3D MAX_DMA32_PFN;
>> 414 #endif
>> 415         max_zone_pfns[ZONE_NORMAL]      =3D max_low_pfn;
>> 416 #ifdef CONFIG_HIGHMEM
>> 417         max_zone_pfns[ZONE_HIGHMEM]     =3D max_pfn;
>> 418 #endif
>> 419
>>=20
>> For x86_64, there is no CONFIG_HIGHMEM, so there will be three zones:
>> ZONE_DMA/ZONE_DMA32/ZONE_NORMAL.
>>=20
> [S.H] Hello, Ben,
>=20
> I have some questions, though I'm still expecting your comments.
> PPC does not have ZONE_DMA32 by default, if we want to use it, we need =
to add "config ZONE_DMA32" in Kconfig first.
> If setting multiple zones without ZONE_DMA, kmalloc in =
"include/linux/slab_def.h" will fail if it uses flag GFP_DMA.
> For the runtime choice in 64-bit kernel, what exactly multiple zones =
should be used?
> "ZONE_DMA & ZONE_NORMAL" or "ZONE_DMA & ZONE_DMA32 & ZONE_NORMAL"?
> Then what the size should be set for them respectively?
>=20
> Please comment, Thanks!

I think Ben is saying that Kconfig would enable ZONE_DMA32 for all =
PPC64, but make it runtime/per platform how we setup the zone's such =
that either ZONE_DMA32 is set to MAX_DMA32_PFN or it set to same value =
as ZONE_DMA.

However that's just a guess.

- k=

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

[Kumar Gala]

On Sep 20, 2012, at 8:36 AM, Kumar Gala wrote:

>=20
> On Sep 20, 2012, at 5:14 AM, Xie Shaohui-B21989 wrote:
>=20
>>>> On Thu, 2012-08-30 at 15:49 -0500, Kumar Gala wrote:
>>>>> On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
>>>>>=20
>>>>>> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so
>>>>>> all the memory will be put into this zone. If the memory size is
>>>>>> greater than the device's DMA capability and device uses
>>>>>> dma_alloc_coherent to allocate memory, it will get an address
>>>>>> which is over the device's DMA addressing, the device will fail.
>>>>>>=20
>>>>>> So we split the memory to two zones: zone ZONE_DMA32 &
>>>>>> ZONE_NORMAL, since we already allocate PCICSRBAR/PEXCSRBAR right
>>>>>> below the 4G boundary (if the lowest PCI address is above 4G), so
>>>>>> we constrain the DMA zone ZONE_DMA32 to 2GB, also, we clear flag
>>>>>> __GFP_DMA &
>>>>>> __GFP_DMA32 and set __GFP_DMA32 only if the device's dma_mask <
>>>>>> total memory size. By doing this, devices which cannot DMA all =
the
>>>>>> memory will be limited to ZONE_DMA32, but devices which can DMA
>>>>>> all
>>>> the memory will not be affected by this limitation.
>>>>>>=20
>>>>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>>>>> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
>>>>>> Signed-off-by: Chen Yuanquan <B41889@freescale.com>
>>>>>> ---
>>>>>> changes for v2:
>>>>>> 1. use a config option for using two zones (ZONE_DMA32 &
>>>>>> ZONE_NORMAL) in freescale 64 bit kernel.
>>>>>>=20
>>>>=20
>>>> There must have been a misunderstanding. I think this should be a
>>>> runtime choice, possibly by the platform code. Any reason that =
can't be
>>> done ?
>>>>=20
>>> [S.H] Do you mean this:
>>>=20
>>> phys_addr_t platform_dma_size (maybe a default value should be used, =
then
>>> platform code will change it)
>>>=20
>>> if (top_of_ram > platform_dma_size)
>>> 	max_zone_pfns[ZONE_DMA] =3D platform_dma_size >> PAGE_SHIFT; =
else
>>> 	max_zone_pfns[ZONE_DMA] =3D top_of_ram >> PAGE_SHIFT;
>>>=20
>>> max_zone_pfns[ZONE_NORMAL] =3D top_of_ram >> PAGE_SHIFT;
>>>=20
>>>> Also how does Intel do it ?
>>> [S.H] below are codes in Intel:
>>>=20
>>> 403 void __init zone_sizes_init(void)
>>> 404 {
>>> 405         unsigned long max_zone_pfns[MAX_NR_ZONES];
>>> 406
>>> 407         memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
>>> 408
>>> 409 #ifdef CONFIG_ZONE_DMA
>>> 410         max_zone_pfns[ZONE_DMA]         =3D MAX_DMA_PFN;
>>> 411 #endif
>>> 412 #ifdef CONFIG_ZONE_DMA32
>>> 413         max_zone_pfns[ZONE_DMA32]       =3D MAX_DMA32_PFN;
>>> 414 #endif
>>> 415         max_zone_pfns[ZONE_NORMAL]      =3D max_low_pfn;
>>> 416 #ifdef CONFIG_HIGHMEM
>>> 417         max_zone_pfns[ZONE_HIGHMEM]     =3D max_pfn;
>>> 418 #endif
>>> 419
>>>=20
>>> For x86_64, there is no CONFIG_HIGHMEM, so there will be three =
zones:
>>> ZONE_DMA/ZONE_DMA32/ZONE_NORMAL.
>>>=20
>> [S.H] Hello, Ben,
>>=20
>> I have some questions, though I'm still expecting your comments.
>> PPC does not have ZONE_DMA32 by default, if we want to use it, we =
need to add "config ZONE_DMA32" in Kconfig first.
>> If setting multiple zones without ZONE_DMA, kmalloc in =
"include/linux/slab_def.h" will fail if it uses flag GFP_DMA.
>> For the runtime choice in 64-bit kernel, what exactly multiple zones =
should be used?
>> "ZONE_DMA & ZONE_NORMAL" or "ZONE_DMA & ZONE_DMA32 & ZONE_NORMAL"?
>> Then what the size should be set for them respectively?
>>=20
>> Please comment, Thanks!
>=20
> 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.
>=20
> However that's just a guess.

Ben,

Can you help clarify your thoughts here.

thanks

- k=

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

[Kumar Gala]

On Sep 24, 2012, at 7:31 AM, Kumar Gala wrote:

>=20
> On Sep 20, 2012, at 8:36 AM, Kumar Gala wrote:
>=20
>>=20
>> On Sep 20, 2012, at 5:14 AM, Xie Shaohui-B21989 wrote:
>>=20
>>>>> On Thu, 2012-08-30 at 15:49 -0500, Kumar Gala wrote:
>>>>>> On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
>>>>>>=20
>>>>>>> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, =
so
>>>>>>> all the memory will be put into this zone. If the memory size is
>>>>>>> greater than the device's DMA capability and device uses
>>>>>>> dma_alloc_coherent to allocate memory, it will get an address
>>>>>>> which is over the device's DMA addressing, the device will fail.
>>>>>>>=20
>>>>>>> So we split the memory to two zones: zone ZONE_DMA32 &
>>>>>>> ZONE_NORMAL, since we already allocate PCICSRBAR/PEXCSRBAR right
>>>>>>> below the 4G boundary (if the lowest PCI address is above 4G), =
so
>>>>>>> we constrain the DMA zone ZONE_DMA32 to 2GB, also, we clear flag
>>>>>>> __GFP_DMA &
>>>>>>> __GFP_DMA32 and set __GFP_DMA32 only if the device's dma_mask <
>>>>>>> total memory size. By doing this, devices which cannot DMA all =
the
>>>>>>> memory will be limited to ZONE_DMA32, but devices which can DMA
>>>>>>> all
>>>>> the memory will not be affected by this limitation.
>>>>>>>=20
>>>>>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>>>>>> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
>>>>>>> Signed-off-by: Chen Yuanquan <B41889@freescale.com>
>>>>>>> ---
>>>>>>> changes for v2:
>>>>>>> 1. use a config option for using two zones (ZONE_DMA32 &
>>>>>>> ZONE_NORMAL) in freescale 64 bit kernel.
>>>>>>>=20
>>>>>=20
>>>>> There must have been a misunderstanding. I think this should be a
>>>>> runtime choice, possibly by the platform code. Any reason that =
can't be
>>>> done ?
>>>>>=20
>>>> [S.H] Do you mean this:
>>>>=20
>>>> phys_addr_t platform_dma_size (maybe a default value should be =
used, then
>>>> platform code will change it)
>>>>=20
>>>> if (top_of_ram > platform_dma_size)
>>>> 	max_zone_pfns[ZONE_DMA] =3D platform_dma_size >> PAGE_SHIFT; =
else
>>>> 	max_zone_pfns[ZONE_DMA] =3D top_of_ram >> PAGE_SHIFT;
>>>>=20
>>>> max_zone_pfns[ZONE_NORMAL] =3D top_of_ram >> PAGE_SHIFT;
>>>>=20
>>>>> Also how does Intel do it ?
>>>> [S.H] below are codes in Intel:
>>>>=20
>>>> 403 void __init zone_sizes_init(void)
>>>> 404 {
>>>> 405         unsigned long max_zone_pfns[MAX_NR_ZONES];
>>>> 406
>>>> 407         memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
>>>> 408
>>>> 409 #ifdef CONFIG_ZONE_DMA
>>>> 410         max_zone_pfns[ZONE_DMA]         =3D MAX_DMA_PFN;
>>>> 411 #endif
>>>> 412 #ifdef CONFIG_ZONE_DMA32
>>>> 413         max_zone_pfns[ZONE_DMA32]       =3D MAX_DMA32_PFN;
>>>> 414 #endif
>>>> 415         max_zone_pfns[ZONE_NORMAL]      =3D max_low_pfn;
>>>> 416 #ifdef CONFIG_HIGHMEM
>>>> 417         max_zone_pfns[ZONE_HIGHMEM]     =3D max_pfn;
>>>> 418 #endif
>>>> 419
>>>>=20
>>>> For x86_64, there is no CONFIG_HIGHMEM, so there will be three =
zones:
>>>> ZONE_DMA/ZONE_DMA32/ZONE_NORMAL.
>>>>=20
>>> [S.H] Hello, Ben,
>>>=20
>>> I have some questions, though I'm still expecting your comments.
>>> PPC does not have ZONE_DMA32 by default, if we want to use it, we =
need to add "config ZONE_DMA32" in Kconfig first.
>>> If setting multiple zones without ZONE_DMA, kmalloc in =
"include/linux/slab_def.h" will fail if it uses flag GFP_DMA.
>>> For the runtime choice in 64-bit kernel, what exactly multiple zones =
should be used?
>>> "ZONE_DMA & ZONE_NORMAL" or "ZONE_DMA & ZONE_DMA32 & ZONE_NORMAL"?
>>> Then what the size should be set for them respectively?
>>>=20
>>> Please comment, Thanks!
>>=20
>> 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.
>>=20
>> However that's just a guess.
>=20
> Ben,
>=20
> Can you help clarify your thoughts here.
>=20
> thanks

Ben?

- k=