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

Subsystems: linux for powerpc (32-bit and 64-bit), the rest

STALE5090d

8 messages, 4 authors, 2012-09-27 · open the first message on its own page

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

From: Shaohui Xie <hidden>
Date: 2012-08-24 11:20:38

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 <redacted>
Signed-off-by: Mingkai Hu <redacted>
Signed-off-by: Chen Yuanquan <redacted>
---
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

From: Kumar Gala <hidden>
Date: 2012-08-30 20:50:02

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 <redacted>
Signed-off-by: Mingkai Hu <redacted>
Signed-off-by: Chen Yuanquan <redacted>
---
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
quoted hunk
=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);
quoted hunk
+		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

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2012-09-09 23:38:01

On Thu, 2012-08-30 at 15:49 -0500, Kumar Gala wrote:
On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
quoted
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 <redacted>
Signed-off-by: Mingkai Hu <redacted>
Signed-off-by: Chen Yuanquan <redacted>
---
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

From: Xie Shaohui-B21989 <hidden>
Date: 2012-09-10 09:51:21

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

From: Xie Shaohui-B21989 <hidden>
Date: 2012-09-20 10:15:01

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

From: Kumar Gala <hidden>
Date: 2012-09-20 13:36:44

On Sep 20, 2012, at 5:14 AM, Xie Shaohui-B21989 wrote:
quoted
quoted
On Thu, 2012-08-30 at 15:49 -0500, Kumar Gala wrote:
quoted
On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
=20
quoted
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.
quoted
quoted
=20
Signed-off-by: Shaohui Xie <redacted>
Signed-off-by: Mingkai Hu <redacted>
Signed-off-by: Chen Yuanquan <redacted>
---
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
quoted
done ?
quoted
=20
[S.H] Do you mean this:
=20
phys_addr_t platform_dma_size (maybe a default value should be used, =
then
quoted
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
quoted
	max_zone_pfns[ZONE_DMA] =3D top_of_ram >> PAGE_SHIFT;
=20
max_zone_pfns[ZONE_NORMAL] =3D top_of_ram >> PAGE_SHIFT;
=20
quoted
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

From: Kumar Gala <hidden>
Date: 2012-09-24 12:31:56

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
quoted
quoted
quoted
On Thu, 2012-08-30 at 15:49 -0500, Kumar Gala wrote:
quoted
On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
=20
quoted
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
quoted
quoted
quoted
quoted
quoted
memory will be limited to ZONE_DMA32, but devices which can DMA
all
the memory will not be affected by this limitation.
quoted
quoted
=20
Signed-off-by: Shaohui Xie <redacted>
Signed-off-by: Mingkai Hu <redacted>
Signed-off-by: Chen Yuanquan <redacted>
---
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
quoted
quoted
done ?
quoted
=20
[S.H] Do you mean this:
=20
phys_addr_t platform_dma_size (maybe a default value should be used, =
then
quoted
quoted
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
quoted
quoted
	max_zone_pfns[ZONE_DMA] =3D top_of_ram >> PAGE_SHIFT;
=20
max_zone_pfns[ZONE_NORMAL] =3D top_of_ram >> PAGE_SHIFT;
=20
quoted
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:
quoted
quoted
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.
quoted
If setting multiple zones without ZONE_DMA, kmalloc in =
"include/linux/slab_def.h" will fail if it uses flag GFP_DMA.
quoted
For the runtime choice in 64-bit kernel, what exactly multiple zones =
should be used?
quoted
"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

From: Kumar Gala <hidden>
Date: 2012-09-27 12:37:21

On Sep 24, 2012, at 7:31 AM, Kumar Gala wrote:
=20
On Sep 20, 2012, at 8:36 AM, Kumar Gala wrote:
=20
quoted
=20
On Sep 20, 2012, at 5:14 AM, Xie Shaohui-B21989 wrote:
=20
quoted
quoted
quoted
On Thu, 2012-08-30 at 15:49 -0500, Kumar Gala wrote:
quoted
On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
=20
quoted
PowerPC platform only supports ZONE_DMA zone for 64bit kernel, =
so
quoted
quoted
quoted
quoted
quoted
quoted
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
quoted
quoted
quoted
quoted
quoted
quoted
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
quoted
quoted
quoted
quoted
quoted
quoted
memory will be limited to ZONE_DMA32, but devices which can DMA
all
the memory will not be affected by this limitation.
quoted
quoted
=20
Signed-off-by: Shaohui Xie <redacted>
Signed-off-by: Mingkai Hu <redacted>
Signed-off-by: Chen Yuanquan <redacted>
---
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
quoted
quoted
quoted
done ?
quoted
=20
[S.H] Do you mean this:
=20
phys_addr_t platform_dma_size (maybe a default value should be =
used, then
quoted
quoted
quoted
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
quoted
quoted
quoted
	max_zone_pfns[ZONE_DMA] =3D top_of_ram >> PAGE_SHIFT;
=20
max_zone_pfns[ZONE_NORMAL] =3D top_of_ram >> PAGE_SHIFT;
=20
quoted
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:
quoted
quoted
quoted
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.
quoted
quoted
If setting multiple zones without ZONE_DMA, kmalloc in =
"include/linux/slab_def.h" will fail if it uses flag GFP_DMA.
quoted
quoted
For the runtime choice in 64-bit kernel, what exactly multiple zones =
should be used?
quoted
quoted
"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.
quoted
=20
However that's just a guess.
=20
Ben,
=20
Can you help clarify your thoughts here.
=20
thanks
Ben?

- k=
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help