[RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Santosh Shilimkar]

The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
PFNs but that breaks the dma_mask for few block layer drivers since
ARM start of physical memory is not PFN0 unlike most of the architectures.
Some more read on it is here:
	http://lwn.net/Articles/543408/
	http://lwn.net/Articles/543424/

To address this issue, we introduce generic dma_max_pfn() helper which
can be overridden from the architectures.
	
Another intention behind move to nobootmem is also to convert ARM to
switch to memblock and getting rid of bootmem allocator dependency which
don't work for LPAE machines which has physical memory starting beyond
4 GB boundary. It needs changes to core kernel and also a new memblock
API. More on this can be found here:
	https://lkml.org/lkml/2013/6/29/77

I have been trying to cook up these patches with kind help from Russell
and we know series don't solve all the dma_mask bad assumptions. But at
least I am hoping that it can get the ball rolling.	

Comments/testing help is welcome !!

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>

Santosh Shilimkar (5):
  block: Rename parameter dma_mask to max_addr for
    blk_queue_bounce_limit()
  mm: dma-mapping: Add dma_max_pfn(dev) helper function
  scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations
  ARM: mm: change max*pfn to include the physical offset of memory
  ARM: mm: Remove bootmem code and switch to NO_BOOTMEM

 arch/arm/Kconfig                   |    1 +
 arch/arm/include/asm/dma-mapping.h |   16 ++++++---
 arch/arm/kernel/setup.c            |    2 +-
 arch/arm/mm/init.c                 |   68 ++++--------------------------------
 block/blk-settings.c               |    8 ++---
 drivers/scsi/scsi_lib.c            |    2 +-
 include/linux/dma-mapping.h        |    7 ++++
 7 files changed, 32 insertions(+), 72 deletions(-)

-- 
1.7.9.5

[RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Santosh Shilimkar]

The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
PFNs but that breaks the dma_mask for few block layer drivers since
ARM start of physical memory is not PFN0 unlike most of the architectures.
Some more read on it is here:
	http://lwn.net/Articles/543408/
	http://lwn.net/Articles/543424/

To address this issue, we introduce generic dma_max_pfn() helper which
can be overridden from the architectures.
	
Another intention behind move to nobootmem is also to convert ARM to
switch to memblock and getting rid of bootmem allocator dependency which
don't work for LPAE machines which has physical memory starting beyond
4 GB boundary. It needs changes to core kernel and also a new memblock
API. More on this can be found here:
	https://lkml.org/lkml/2013/6/29/77

I have been trying to cook up these patches with kind help from Russell
and we know series don't solve all the dma_mask bad assumptions. But at
least I am hoping that it can get the ball rolling.	

Comments/testing help is welcome !!

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>

Santosh Shilimkar (5):
  block: Rename parameter dma_mask to max_addr for
    blk_queue_bounce_limit()
  mm: dma-mapping: Add dma_max_pfn(dev) helper function
  scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations
  ARM: mm: change max*pfn to include the physical offset of memory
  ARM: mm: Remove bootmem code and switch to NO_BOOTMEM

 arch/arm/Kconfig                   |    1 +
 arch/arm/include/asm/dma-mapping.h |   16 ++++++---
 arch/arm/kernel/setup.c            |    2 +-
 arch/arm/mm/init.c                 |   68 ++++--------------------------------
 block/blk-settings.c               |    8 ++---
 drivers/scsi/scsi_lib.c            |    2 +-
 include/linux/dma-mapping.h        |    7 ++++
 7 files changed, 32 insertions(+), 72 deletions(-)

-- 
1.7.9.5

[RFC/RFT PATCH 1/5] block: Rename parameter dma_mask to max_addr for blk_queue_bounce_limit()

[Santosh Shilimkar]

The blk_queue_bounce_limit() API parameter 'dma_mask' is actually the
maximum address the device can handle rather than a dma_mask. Rename
it accordingly to avoid it being interpreted as dma_mask.

No functional change.

The idea is to fix the bad assumptions about dma_mask wherever it could
be miss-interpreted.

Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Jens Axboe <axboe@kernel.dk>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 block/blk-settings.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index c50ecf0..026c151 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -195,17 +195,17 @@ EXPORT_SYMBOL(blk_queue_make_request);
 /**
  * blk_queue_bounce_limit - set bounce buffer limit for queue
  * @q: the request queue for the device
- * @dma_mask: the maximum address the device can handle
+ * @max_addr: the maximum address the device can handle
  *
  * Description:
  *    Different hardware can have different requirements as to what pages
  *    it can do I/O directly to. A low level driver can call
  *    blk_queue_bounce_limit to have lower memory pages allocated as bounce
- *    buffers for doing I/O to pages residing above @dma_mask.
+ *    buffers for doing I/O to pages residing above @max_addr.
  **/
-void blk_queue_bounce_limit(struct request_queue *q, u64 dma_mask)
+void blk_queue_bounce_limit(struct request_queue *q, u64 max_addr)
 {
-	unsigned long b_pfn = dma_mask >> PAGE_SHIFT;
+	unsigned long b_pfn = max_addr >> PAGE_SHIFT;
 	int dma = 0;
 
 	q->bounce_gfp = GFP_NOIO;
-- 
1.7.9.5

[RFC/RFT PATCH 1/5] block: Rename parameter dma_mask to max_addr for blk_queue_bounce_limit()

[Santosh Shilimkar]

The blk_queue_bounce_limit() API parameter 'dma_mask' is actually the
maximum address the device can handle rather than a dma_mask. Rename
it accordingly to avoid it being interpreted as dma_mask.

No functional change.

The idea is to fix the bad assumptions about dma_mask wherever it could
be miss-interpreted.

Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Jens Axboe <axboe@kernel.dk>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 block/blk-settings.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index c50ecf0..026c151 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -195,17 +195,17 @@ EXPORT_SYMBOL(blk_queue_make_request);
 /**
  * blk_queue_bounce_limit - set bounce buffer limit for queue
  * @q: the request queue for the device
- * @dma_mask: the maximum address the device can handle
+ * @max_addr: the maximum address the device can handle
  *
  * Description:
  *    Different hardware can have different requirements as to what pages
  *    it can do I/O directly to. A low level driver can call
  *    blk_queue_bounce_limit to have lower memory pages allocated as bounce
- *    buffers for doing I/O to pages residing above @dma_mask.
+ *    buffers for doing I/O to pages residing above @max_addr.
  **/
-void blk_queue_bounce_limit(struct request_queue *q, u64 dma_mask)
+void blk_queue_bounce_limit(struct request_queue *q, u64 max_addr)
 {
-	unsigned long b_pfn = dma_mask >> PAGE_SHIFT;
+	unsigned long b_pfn = max_addr >> PAGE_SHIFT;
 	int dma = 0;
 
 	q->bounce_gfp = GFP_NOIO;
-- 
1.7.9.5

[RFC/RFT PATCH 2/5] mm: dma-mapping: Add dma_max_pfn(dev) helper function

[Santosh Shilimkar]

Most of the kernel assumes that PFN0 is the start of the physical
memory (RAM). This assumptions is not true on most of the ARM SOCs
and hence and if one try to update the ARM port to follow the assumptions,
we end of breaking the dma bounce limit for few block layer drivers.
One such example is trying to unify the meaning of max*_pfn on ARM
as the bootmem layer expects, breaks few block layer driver dma
bounce limit.

To fix this problem, we introduce dma_max_pfn(dev) generic helper with
a possibility of override from the architecture code. The helper converts
a DMA bitmask of bits to a block PFN number. In all the generic cases,
it is just  "dev->dma_mask >> PAGE_SHIFT" and hence default behavior
is maintained as is.

Subsequent patches will make use of the helper. No functional change.

Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Jens Axboe <axboe@kernel.dk>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 include/linux/dma-mapping.h |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 94af418..68a7863 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -129,6 +129,13 @@ static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask)
 		return -EIO;
 }
 
+#ifndef dma_max_pfn
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+	return *dev->dma_mask >> PAGE_SHIFT;
+}
+#endif
+
 static inline void *dma_zalloc_coherent(struct device *dev, size_t size,
 					dma_addr_t *dma_handle, gfp_t flag)
 {
-- 
1.7.9.5

[RFC/RFT PATCH 2/5] mm: dma-mapping: Add dma_max_pfn(dev) helper function

[Santosh Shilimkar]

Most of the kernel assumes that PFN0 is the start of the physical
memory (RAM). This assumptions is not true on most of the ARM SOCs
and hence and if one try to update the ARM port to follow the assumptions,
we end of breaking the dma bounce limit for few block layer drivers.
One such example is trying to unify the meaning of max*_pfn on ARM
as the bootmem layer expects, breaks few block layer driver dma
bounce limit.

To fix this problem, we introduce dma_max_pfn(dev) generic helper with
a possibility of override from the architecture code. The helper converts
a DMA bitmask of bits to a block PFN number. In all the generic cases,
it is just  "dev->dma_mask >> PAGE_SHIFT" and hence default behavior
is maintained as is.

Subsequent patches will make use of the helper. No functional change.

Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Jens Axboe <axboe@kernel.dk>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 include/linux/dma-mapping.h |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 94af418..68a7863 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -129,6 +129,13 @@ static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask)
 		return -EIO;
 }
 
+#ifndef dma_max_pfn
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+	return *dev->dma_mask >> PAGE_SHIFT;
+}
+#endif
+
 static inline void *dma_zalloc_coherent(struct device *dev, size_t size,
 					dma_addr_t *dma_handle, gfp_t flag)
 {
-- 
1.7.9.5

[RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Santosh Shilimkar]

DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-scsi@vger.kernel.org

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 drivers/scsi/scsi_lib.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 86d5220..e8275fa 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
 
 	host_dev = scsi_get_device(shost);
 	if (host_dev && host_dev->dma_mask)
-		bounce_limit = *host_dev->dma_mask;
+		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;
 
 	return bounce_limit;
 }
-- 
1.7.9.5

[RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Santosh Shilimkar]

DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-scsi at vger.kernel.org

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 drivers/scsi/scsi_lib.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 86d5220..e8275fa 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
 
 	host_dev = scsi_get_device(shost);
 	if (host_dev && host_dev->dma_mask)
-		bounce_limit = *host_dev->dma_mask;
+		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;
 
 	return bounce_limit;
 }
-- 
1.7.9.5

[RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Santosh Shilimkar]

DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-scsi@vger.kernel.org

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 drivers/scsi/scsi_lib.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 86d5220..e8275fa 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
 
 	host_dev = scsi_get_device(shost);
 	if (host_dev && host_dev->dma_mask)
-		bounce_limit = *host_dev->dma_mask;
+		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;
 
 	return bounce_limit;
 }
-- 
1.7.9.5

Re: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Sergei Shtylyov]

Hello.

On 07/13/2013 01:48 AM, Santosh Shilimkar wrote:

> DMA bounce limit is the maximum direct DMA'able memory beyond which
> bounce buffers has to be used to perform dma operations. SCSI driver
> relies on dma_mask but its calculation is based on max_*pfn which
> don't have uniform meaning across architectures. So make use of
> dma_max_pfn() which is expected to return the DMAable maximum pfn
> value across architectures.

> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-scsi@vger.kernel.org

> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
>   drivers/scsi/scsi_lib.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 86d5220..e8275fa 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
>
>   	host_dev = scsi_get_device(shost);
>   	if (host_dev && host_dev->dma_mask)
> -		bounce_limit = *host_dev->dma_mask;
> +		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;

    You definitely forgot -1 here.

WBR, Sergei

[RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Sergei Shtylyov]

Hello.

On 07/13/2013 01:48 AM, Santosh Shilimkar wrote:

> DMA bounce limit is the maximum direct DMA'able memory beyond which
> bounce buffers has to be used to perform dma operations. SCSI driver
> relies on dma_mask but its calculation is based on max_*pfn which
> don't have uniform meaning across architectures. So make use of
> dma_max_pfn() which is expected to return the DMAable maximum pfn
> value across architectures.

> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-scsi at vger.kernel.org

> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
>   drivers/scsi/scsi_lib.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 86d5220..e8275fa 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
>
>   	host_dev = scsi_get_device(shost);
>   	if (host_dev && host_dev->dma_mask)
> -		bounce_limit = *host_dev->dma_mask;
> +		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;

    You definitely forgot -1 here.

WBR, Sergei

Re: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Russell King - ARM Linux]

On Sat, Jul 13, 2013 at 01:55:58AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 07/13/2013 01:48 AM, Santosh Shilimkar wrote:
>
>> DMA bounce limit is the maximum direct DMA'able memory beyond which
>> bounce buffers has to be used to perform dma operations. SCSI driver
>> relies on dma_mask but its calculation is based on max_*pfn which
>> don't have uniform meaning across architectures. So make use of
>> dma_max_pfn() which is expected to return the DMAable maximum pfn
>> value across architectures.
>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: linux-scsi@vger.kernel.org
>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>>   drivers/scsi/scsi_lib.c |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index 86d5220..e8275fa 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
>> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
>>
>>   	host_dev = scsi_get_device(shost);
>>   	if (host_dev && host_dev->dma_mask)
>> -		bounce_limit = *host_dev->dma_mask;
>> +		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;
>
>    You definitely forgot -1 here.

Please explain your point.

[RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Russell King - ARM Linux]

On Sat, Jul 13, 2013 at 01:55:58AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 07/13/2013 01:48 AM, Santosh Shilimkar wrote:
>
>> DMA bounce limit is the maximum direct DMA'able memory beyond which
>> bounce buffers has to be used to perform dma operations. SCSI driver
>> relies on dma_mask but its calculation is based on max_*pfn which
>> don't have uniform meaning across architectures. So make use of
>> dma_max_pfn() which is expected to return the DMAable maximum pfn
>> value across architectures.
>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: linux-scsi at vger.kernel.org
>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>>   drivers/scsi/scsi_lib.c |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index 86d5220..e8275fa 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
>> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
>>
>>   	host_dev = scsi_get_device(shost);
>>   	if (host_dev && host_dev->dma_mask)
>> -		bounce_limit = *host_dev->dma_mask;
>> +		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;
>
>    You definitely forgot -1 here.

Please explain your point.

Re: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Sergei Shtylyov]

Hello.

On 07/13/2013 02:25 AM, Russell King - ARM Linux wrote:

>>> DMA bounce limit is the maximum direct DMA'able memory beyond which
>>> bounce buffers has to be used to perform dma operations. SCSI driver
>>> relies on dma_mask but its calculation is based on max_*pfn which
>>> don't have uniform meaning across architectures. So make use of
>>> dma_max_pfn() which is expected to return the DMAable maximum pfn
>>> value across architectures.

>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: linux-scsi@vger.kernel.org

>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>> ---
>>>    drivers/scsi/scsi_lib.c |    2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)

>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>> index 86d5220..e8275fa 100644
>>> --- a/drivers/scsi/scsi_lib.c
>>> +++ b/drivers/scsi/scsi_lib.c
>>> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
>>>
>>>    	host_dev = scsi_get_device(shost);
>>>    	if (host_dev && host_dev->dma_mask)
>>> -		bounce_limit = *host_dev->dma_mask;
>>> +		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;

>>     You definitely forgot -1 here.

> Please explain your point.

    Previously, 'bounce_limit' would look like 0xffffffff (unless I'm 
mistaken), now it would look like 0xfffff000 which is hardly what we're 
looking for, no?

WBR, Sergei

[RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Sergei Shtylyov]

Hello.

On 07/13/2013 02:25 AM, Russell King - ARM Linux wrote:

>>> DMA bounce limit is the maximum direct DMA'able memory beyond which
>>> bounce buffers has to be used to perform dma operations. SCSI driver
>>> relies on dma_mask but its calculation is based on max_*pfn which
>>> don't have uniform meaning across architectures. So make use of
>>> dma_max_pfn() which is expected to return the DMAable maximum pfn
>>> value across architectures.

>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: linux-scsi at vger.kernel.org

>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>> ---
>>>    drivers/scsi/scsi_lib.c |    2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)

>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>> index 86d5220..e8275fa 100644
>>> --- a/drivers/scsi/scsi_lib.c
>>> +++ b/drivers/scsi/scsi_lib.c
>>> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
>>>
>>>    	host_dev = scsi_get_device(shost);
>>>    	if (host_dev && host_dev->dma_mask)
>>> -		bounce_limit = *host_dev->dma_mask;
>>> +		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;

>>     You definitely forgot -1 here.

> Please explain your point.

    Previously, 'bounce_limit' would look like 0xffffffff (unless I'm 
mistaken), now it would look like 0xfffff000 which is hardly what we're 
looking for, no?

WBR, Sergei

Re: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Sergei Shtylyov]

On 07/13/2013 03:08 AM, Sergei Shtylyov wrote:

>>>> DMA bounce limit is the maximum direct DMA'able memory beyond which
>>>> bounce buffers has to be used to perform dma operations. SCSI driver
>>>> relies on dma_mask but its calculation is based on max_*pfn which
>>>> don't have uniform meaning across architectures. So make use of
>>>> dma_max_pfn() which is expected to return the DMAable maximum pfn
>>>> value across architectures.

>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>> Cc: linux-scsi@vger.kernel.org

>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>> ---
>>>>    drivers/scsi/scsi_lib.c |    2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)

>>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>>> index 86d5220..e8275fa 100644
>>>> --- a/drivers/scsi/scsi_lib.c
>>>> +++ b/drivers/scsi/scsi_lib.c
>>>> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct
>>>> Scsi_Host *shost)
>>>>
>>>>        host_dev = scsi_get_device(shost);
>>>>        if (host_dev && host_dev->dma_mask)
>>>> -        bounce_limit = *host_dev->dma_mask;
>>>> +        bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;

>>>     You definitely forgot -1 here.

>> Please explain your point.

>     Previously, 'bounce_limit' would look like 0xffffffff (unless I'm
> mistaken), now it would look like 0xfffff000 which is hardly what we're
> looking for, no?

    Although, -1 won't give us the correct result in this case, it's 
more like + PAGE_SIZE - 1.

WBR, Sergei

[RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Sergei Shtylyov]

On 07/13/2013 03:08 AM, Sergei Shtylyov wrote:

>>>> DMA bounce limit is the maximum direct DMA'able memory beyond which
>>>> bounce buffers has to be used to perform dma operations. SCSI driver
>>>> relies on dma_mask but its calculation is based on max_*pfn which
>>>> don't have uniform meaning across architectures. So make use of
>>>> dma_max_pfn() which is expected to return the DMAable maximum pfn
>>>> value across architectures.

>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>> Cc: linux-scsi at vger.kernel.org

>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>> ---
>>>>    drivers/scsi/scsi_lib.c |    2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)

>>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>>> index 86d5220..e8275fa 100644
>>>> --- a/drivers/scsi/scsi_lib.c
>>>> +++ b/drivers/scsi/scsi_lib.c
>>>> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct
>>>> Scsi_Host *shost)
>>>>
>>>>        host_dev = scsi_get_device(shost);
>>>>        if (host_dev && host_dev->dma_mask)
>>>> -        bounce_limit = *host_dev->dma_mask;
>>>> +        bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;

>>>     You definitely forgot -1 here.

>> Please explain your point.

>     Previously, 'bounce_limit' would look like 0xffffffff (unless I'm
> mistaken), now it would look like 0xfffff000 which is hardly what we're
> looking for, no?

    Although, -1 won't give us the correct result in this case, it's 
more like + PAGE_SIZE - 1.

WBR, Sergei

Re: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Russell King - ARM Linux]

On Sat, Jul 13, 2013 at 03:42:55AM +0400, Sergei Shtylyov wrote:
>>>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>>>> index 86d5220..e8275fa 100644
>>>>> --- a/drivers/scsi/scsi_lib.c
>>>>> +++ b/drivers/scsi/scsi_lib.c
>>>>> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct
>>>>> Scsi_Host *shost)
>>>>>
>>>>>        host_dev = scsi_get_device(shost);
>>>>>        if (host_dev && host_dev->dma_mask)
>>>>> -        bounce_limit = *host_dev->dma_mask;
>>>>> +        bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;
>
>>>>     You definitely forgot -1 here.
>
>>> Please explain your point.
>
>>     Previously, 'bounce_limit' would look like 0xffffffff (unless I'm
>> mistaken), now it would look like 0xfffff000 which is hardly what we're
>> looking for, no?
>
>    Although, -1 won't give us the correct result in this case, it's more 
> like + PAGE_SIZE - 1.

And where it's used is blk_bounce_limit(), the first which that does
is convert it back to a PFN, losing the bottom bits again...

I'm tempted to suggest converting the whole thing to just deal with
PFNs rather than bytes since we only deal with "can we DMA to this"
on a per-page basis.

[RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Russell King - ARM Linux]

On Sat, Jul 13, 2013 at 03:42:55AM +0400, Sergei Shtylyov wrote:
>>>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>>>> index 86d5220..e8275fa 100644
>>>>> --- a/drivers/scsi/scsi_lib.c
>>>>> +++ b/drivers/scsi/scsi_lib.c
>>>>> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct
>>>>> Scsi_Host *shost)
>>>>>
>>>>>        host_dev = scsi_get_device(shost);
>>>>>        if (host_dev && host_dev->dma_mask)
>>>>> -        bounce_limit = *host_dev->dma_mask;
>>>>> +        bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;
>
>>>>     You definitely forgot -1 here.
>
>>> Please explain your point.
>
>>     Previously, 'bounce_limit' would look like 0xffffffff (unless I'm
>> mistaken), now it would look like 0xfffff000 which is hardly what we're
>> looking for, no?
>
>    Although, -1 won't give us the correct result in this case, it's more 
> like + PAGE_SIZE - 1.

And where it's used is blk_bounce_limit(), the first which that does
is convert it back to a PFN, losing the bottom bits again...

I'm tempted to suggest converting the whole thing to just deal with
PFNs rather than bytes since we only deal with "can we DMA to this"
on a per-page basis.

[RFC/RFT PATCH 4/5] ARM: mm: change max*pfn to include the physical offset of memory

[Santosh Shilimkar]

Most of the kernel code assumes that max*pfn is maximum pfns because
the physical start of memory is expected to be PFN0. Since this
assumption is not true on ARM architectures, the meaning of max*pfn
is number of memory pages. This is done to keep drivers happy which
are making use of of these variable to calculate the dma bounce limit
using dma_mask.

Now since we have a architecture override possibility for DMAable
maximum pfns, lets make meaning of max*pfns as maximum pnfs on ARM
as well.

In the patch, the dma_to_pfn/pfn_to_dma() pair is hacked to take care of
the physical memory offset. It is done this way just to enable testing
since its understood that it can come in way of single zImage.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/include/asm/dma-mapping.h |   16 ++++++++++++----
 arch/arm/mm/init.c                 |   10 ++++------
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 5b579b9..b2d5937 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -47,12 +47,12 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
 #ifndef __arch_pfn_to_dma
 static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
 {
-	return (dma_addr_t)__pfn_to_bus(pfn);
+	return (dma_addr_t)__pfn_to_bus(pfn + PHYS_PFN_OFFSET);
 }
 
 static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
 {
-	return __bus_to_pfn(addr);
+	return __bus_to_pfn(addr) - PHYS_PFN_OFFSET;
 }
 
 static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
@@ -64,15 +64,16 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
 {
 	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
 }
+
 #else
 static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
 {
-	return __arch_pfn_to_dma(dev, pfn);
+	return __arch_pfn_to_dma(dev, pfn + PHYS_PFN_OFFSET);
 }
 
 static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
 {
-	return __arch_dma_to_pfn(dev, addr);
+	return __arch_dma_to_pfn(dev, addr) - PHYS_PFN_OFFSET;
 }
 
 static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
@@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
 }
 #endif
 
+/* The ARM override for dma_max_pfn() */
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+	return dma_to_pfn(dev, *dev->dma_mask);
+}
+#define dma_max_pfn(dev) dma_max_pfn(dev)
+
 /*
  * DMA errors are defined by all-bits-set in the DMA address.
  */
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 6833cbe..588a2c1 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -420,12 +420,10 @@ void __init bootmem_init(void)
 	 * This doesn't seem to be used by the Linux memory manager any
 	 * more, but is used by ll_rw_block.  If we can get rid of it, we
 	 * also get rid of some of the stuff above as well.
-	 *
-	 * Note: max_low_pfn and max_pfn reflect the number of _pages_ in
-	 * the system, not the maximum PFN.
 	 */
-	max_low_pfn = max_low - PHYS_PFN_OFFSET;
-	max_pfn = max_high - PHYS_PFN_OFFSET;
+	min_low_pfn = min;
+	max_low_pfn = max_low;
+	max_pfn = max_high;
 }
 
 /*
@@ -531,7 +529,7 @@ static inline void free_area_high(unsigned long pfn, unsigned long end)
 static void __init free_highpages(void)
 {
 #ifdef CONFIG_HIGHMEM
-	unsigned long max_low = max_low_pfn + PHYS_PFN_OFFSET;
+	unsigned long max_low = max_low_pfn;
 	struct memblock_region *mem, *res;
 
 	/* set highmem page free */
-- 
1.7.9.5

[RFC/RFT PATCH 4/5] ARM: mm: change max*pfn to include the physical offset of memory

[Santosh Shilimkar]

Most of the kernel code assumes that max*pfn is maximum pfns because
the physical start of memory is expected to be PFN0. Since this
assumption is not true on ARM architectures, the meaning of max*pfn
is number of memory pages. This is done to keep drivers happy which
are making use of of these variable to calculate the dma bounce limit
using dma_mask.

Now since we have a architecture override possibility for DMAable
maximum pfns, lets make meaning of max*pfns as maximum pnfs on ARM
as well.

In the patch, the dma_to_pfn/pfn_to_dma() pair is hacked to take care of
the physical memory offset. It is done this way just to enable testing
since its understood that it can come in way of single zImage.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/include/asm/dma-mapping.h |   16 ++++++++++++----
 arch/arm/mm/init.c                 |   10 ++++------
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 5b579b9..b2d5937 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -47,12 +47,12 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
 #ifndef __arch_pfn_to_dma
 static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
 {
-	return (dma_addr_t)__pfn_to_bus(pfn);
+	return (dma_addr_t)__pfn_to_bus(pfn + PHYS_PFN_OFFSET);
 }
 
 static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
 {
-	return __bus_to_pfn(addr);
+	return __bus_to_pfn(addr) - PHYS_PFN_OFFSET;
 }
 
 static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
@@ -64,15 +64,16 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
 {
 	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
 }
+
 #else
 static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
 {
-	return __arch_pfn_to_dma(dev, pfn);
+	return __arch_pfn_to_dma(dev, pfn + PHYS_PFN_OFFSET);
 }
 
 static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
 {
-	return __arch_dma_to_pfn(dev, addr);
+	return __arch_dma_to_pfn(dev, addr) - PHYS_PFN_OFFSET;
 }
 
 static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
@@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
 }
 #endif
 
+/* The ARM override for dma_max_pfn() */
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+	return dma_to_pfn(dev, *dev->dma_mask);
+}
+#define dma_max_pfn(dev) dma_max_pfn(dev)
+
 /*
  * DMA errors are defined by all-bits-set in the DMA address.
  */
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 6833cbe..588a2c1 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -420,12 +420,10 @@ void __init bootmem_init(void)
 	 * This doesn't seem to be used by the Linux memory manager any
 	 * more, but is used by ll_rw_block.  If we can get rid of it, we
 	 * also get rid of some of the stuff above as well.
-	 *
-	 * Note: max_low_pfn and max_pfn reflect the number of _pages_ in
-	 * the system, not the maximum PFN.
 	 */
-	max_low_pfn = max_low - PHYS_PFN_OFFSET;
-	max_pfn = max_high - PHYS_PFN_OFFSET;
+	min_low_pfn = min;
+	max_low_pfn = max_low;
+	max_pfn = max_high;
 }
 
 /*
@@ -531,7 +529,7 @@ static inline void free_area_high(unsigned long pfn, unsigned long end)
 static void __init free_highpages(void)
 {
 #ifdef CONFIG_HIGHMEM
-	unsigned long max_low = max_low_pfn + PHYS_PFN_OFFSET;
+	unsigned long max_low = max_low_pfn;
 	struct memblock_region *mem, *res;
 
 	/* set highmem page free */
-- 
1.7.9.5

Re: [RFC/RFT PATCH 4/5] ARM: mm: change max*pfn to include the physical offset of memory

[Russell King - ARM Linux]

On Fri, Jul 12, 2013 at 05:48:13PM -0400, Santosh Shilimkar wrote:
> Most of the kernel code assumes that max*pfn is maximum pfns because
> the physical start of memory is expected to be PFN0. Since this
> assumption is not true on ARM architectures, the meaning of max*pfn
> is number of memory pages. This is done to keep drivers happy which
> are making use of of these variable to calculate the dma bounce limit
> using dma_mask.
> 
> Now since we have a architecture override possibility for DMAable
> maximum pfns, lets make meaning of max*pfns as maximum pnfs on ARM
> as well.
> 
> In the patch, the dma_to_pfn/pfn_to_dma() pair is hacked to take care of
> the physical memory offset. It is done this way just to enable testing
> since its understood that it can come in way of single zImage.

As Santosh says, this is a hack - but we need to have a discussion about
how to handle translations from PFN to bus addresses.

Currently, the way we do that on ARM is mostly assume that physical
addresses are the same as bus addresses, but that's not true everywhere,
and certainly isn't true when you have a 32-bit DMA controller which
can access physical memory, where the physical memory is above 4GB
in physical space.

We have certain platforms where the DMA address is already being
programmed into a controller with less than 32-bits in its address
register, and with a physical memory offset - and of course this
case just works out of the box because the high bits are ignored
by the device.

What I'm basically saying is we've had this problem for a while, and
we've lived with it by hoping and hacking, and adjusting max*pfn, but
this is not long-term sustainable.  We *need* to get away from the
idea that DMA addresses are physical addresses and device DMA masks
have some relationship to physical addresses.

Consider for a moment:

	PCI address 0x00000000 ---> physical address 0xc0000000.

You plug a card in which can't do 32-bit addressing (remember, there
are such PCI cards in the past...).  The driver sets the DMA mask to
0x0fffffff (or whatever).  How does that relate to the PCI bus address?
It's 0x00000000 to 0x0fffffff.  How does that relate to the physical
address space?  0xc0000000 to 0xcfffffff.

This is why DMA masks can't be treated as some notional address limit.
It just doesn't work when you have bus offsets.

And the extreme case of that is LPAE with all system memory above the
4GB physical mark, with 32-bit DMA capable peripherals - which we're
starting to see now.

Ideally, I think we need some kind of per-bus DT property to describe
the memory which can be accessed from the bus - to do it properly to
cover the cases we've already seen, that would be an offset and a size.

We then need some way for dma_to_pfn() and pfn_to_dma() to efficiently
get at that information - bear in mind that they're hot paths when doing
DMA mappings and the like.  I doubt we want to be looking up the same
property time and time again inside them.

[RFC/RFT PATCH 4/5] ARM: mm: change max*pfn to include the physical offset of memory

[Russell King - ARM Linux]

On Fri, Jul 12, 2013 at 05:48:13PM -0400, Santosh Shilimkar wrote:
> Most of the kernel code assumes that max*pfn is maximum pfns because
> the physical start of memory is expected to be PFN0. Since this
> assumption is not true on ARM architectures, the meaning of max*pfn
> is number of memory pages. This is done to keep drivers happy which
> are making use of of these variable to calculate the dma bounce limit
> using dma_mask.
> 
> Now since we have a architecture override possibility for DMAable
> maximum pfns, lets make meaning of max*pfns as maximum pnfs on ARM
> as well.
> 
> In the patch, the dma_to_pfn/pfn_to_dma() pair is hacked to take care of
> the physical memory offset. It is done this way just to enable testing
> since its understood that it can come in way of single zImage.

As Santosh says, this is a hack - but we need to have a discussion about
how to handle translations from PFN to bus addresses.

Currently, the way we do that on ARM is mostly assume that physical
addresses are the same as bus addresses, but that's not true everywhere,
and certainly isn't true when you have a 32-bit DMA controller which
can access physical memory, where the physical memory is above 4GB
in physical space.

We have certain platforms where the DMA address is already being
programmed into a controller with less than 32-bits in its address
register, and with a physical memory offset - and of course this
case just works out of the box because the high bits are ignored
by the device.

What I'm basically saying is we've had this problem for a while, and
we've lived with it by hoping and hacking, and adjusting max*pfn, but
this is not long-term sustainable.  We *need* to get away from the
idea that DMA addresses are physical addresses and device DMA masks
have some relationship to physical addresses.

Consider for a moment:

	PCI address 0x00000000 ---> physical address 0xc0000000.

You plug a card in which can't do 32-bit addressing (remember, there
are such PCI cards in the past...).  The driver sets the DMA mask to
0x0fffffff (or whatever).  How does that relate to the PCI bus address?
It's 0x00000000 to 0x0fffffff.  How does that relate to the physical
address space?  0xc0000000 to 0xcfffffff.

This is why DMA masks can't be treated as some notional address limit.
It just doesn't work when you have bus offsets.

And the extreme case of that is LPAE with all system memory above the
4GB physical mark, with 32-bit DMA capable peripherals - which we're
starting to see now.

Ideally, I think we need some kind of per-bus DT property to describe
the memory which can be accessed from the bus - to do it properly to
cover the cases we've already seen, that would be an offset and a size.

We then need some way for dma_to_pfn() and pfn_to_dma() to efficiently
get at that information - bear in mind that they're hot paths when doing
DMA mappings and the like.  I doubt we want to be looking up the same
property time and time again inside them.

Re: [RFC/RFT PATCH 4/5] ARM: mm: change max*pfn to include the physical offset of memory

[Russell King - ARM Linux]

On Fri, Jul 12, 2013 at 05:48:13PM -0400, Santosh Shilimkar wrote:
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index 5b579b9..b2d5937 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -47,12 +47,12 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
>  #ifndef __arch_pfn_to_dma
>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>  {
> -	return (dma_addr_t)__pfn_to_bus(pfn);
> +	return (dma_addr_t)__pfn_to_bus(pfn + PHYS_PFN_OFFSET);
>  }
>  
>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>  {
> -	return __bus_to_pfn(addr);
> +	return __bus_to_pfn(addr) - PHYS_PFN_OFFSET;
>  }
>  
>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
> @@ -64,15 +64,16 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>  {
>  	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
>  }
> +
>  #else
>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>  {
> -	return __arch_pfn_to_dma(dev, pfn);
> +	return __arch_pfn_to_dma(dev, pfn + PHYS_PFN_OFFSET);
>  }
>  
>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>  {
> -	return __arch_dma_to_pfn(dev, addr);
> +	return __arch_dma_to_pfn(dev, addr) - PHYS_PFN_OFFSET;
>  }
>  
>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
> @@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>  }
>  #endif

Note that I don't think the above are correct - the 'pfn' argument to the
above functions already includes the PFN offset of physical memory -
they're all physical_address >> PAGE_SHIFT values.

> +/* The ARM override for dma_max_pfn() */
> +static inline unsigned long dma_max_pfn(struct device *dev)
> +{
> +	return dma_to_pfn(dev, *dev->dma_mask);
> +}
> +#define dma_max_pfn(dev) dma_max_pfn(dev)

So I'd suggest this becomes:

	return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev->dma_mask);

[RFC/RFT PATCH 4/5] ARM: mm: change max*pfn to include the physical offset of memory

[Russell King - ARM Linux]

On Fri, Jul 12, 2013 at 05:48:13PM -0400, Santosh Shilimkar wrote:
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index 5b579b9..b2d5937 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -47,12 +47,12 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
>  #ifndef __arch_pfn_to_dma
>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>  {
> -	return (dma_addr_t)__pfn_to_bus(pfn);
> +	return (dma_addr_t)__pfn_to_bus(pfn + PHYS_PFN_OFFSET);
>  }
>  
>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>  {
> -	return __bus_to_pfn(addr);
> +	return __bus_to_pfn(addr) - PHYS_PFN_OFFSET;
>  }
>  
>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
> @@ -64,15 +64,16 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>  {
>  	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
>  }
> +
>  #else
>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>  {
> -	return __arch_pfn_to_dma(dev, pfn);
> +	return __arch_pfn_to_dma(dev, pfn + PHYS_PFN_OFFSET);
>  }
>  
>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>  {
> -	return __arch_dma_to_pfn(dev, addr);
> +	return __arch_dma_to_pfn(dev, addr) - PHYS_PFN_OFFSET;
>  }
>  
>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
> @@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>  }
>  #endif

Note that I don't think the above are correct - the 'pfn' argument to the
above functions already includes the PFN offset of physical memory -
they're all physical_address >> PAGE_SHIFT values.

> +/* The ARM override for dma_max_pfn() */
> +static inline unsigned long dma_max_pfn(struct device *dev)
> +{
> +	return dma_to_pfn(dev, *dev->dma_mask);
> +}
> +#define dma_max_pfn(dev) dma_max_pfn(dev)

So I'd suggest this becomes:

	return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev->dma_mask);

Re: [RFC/RFT PATCH 4/5] ARM: mm: change max*pfn to include the physical offset of memory

[Santosh Shilimkar]

On Wednesday 31 July 2013 06:56 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 12, 2013 at 05:48:13PM -0400, Santosh Shilimkar wrote:
>> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
>> index 5b579b9..b2d5937 100644
>> --- a/arch/arm/include/asm/dma-mapping.h
>> +++ b/arch/arm/include/asm/dma-mapping.h
>> @@ -47,12 +47,12 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
>>  #ifndef __arch_pfn_to_dma
>>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>>  {
>> -	return (dma_addr_t)__pfn_to_bus(pfn);
>> +	return (dma_addr_t)__pfn_to_bus(pfn + PHYS_PFN_OFFSET);
>>  }
>>  
>>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>>  {
>> -	return __bus_to_pfn(addr);
>> +	return __bus_to_pfn(addr) - PHYS_PFN_OFFSET;
>>  }
>>  
>>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
>> @@ -64,15 +64,16 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>>  {
>>  	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
>>  }
>> +
>>  #else
>>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>>  {
>> -	return __arch_pfn_to_dma(dev, pfn);
>> +	return __arch_pfn_to_dma(dev, pfn + PHYS_PFN_OFFSET);
>>  }
>>  
>>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>>  {
>> -	return __arch_dma_to_pfn(dev, addr);
>> +	return __arch_dma_to_pfn(dev, addr) - PHYS_PFN_OFFSET;
>>  }
>>  
>>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
>> @@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>>  }
>>  #endif
> 
> Note that I don't think the above are correct - the 'pfn' argument to the
> above functions already includes the PFN offset of physical memory -
> they're all physical_address >> PAGE_SHIFT values.
> 
Right.
Updated patch pushed into the patch system. (patch 7805/1)

Regards,
Santosh

[RFC/RFT PATCH 4/5] ARM: mm: change max*pfn to include the physical offset of memory

[Santosh Shilimkar]

On Wednesday 31 July 2013 06:56 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 12, 2013 at 05:48:13PM -0400, Santosh Shilimkar wrote:
>> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
>> index 5b579b9..b2d5937 100644
>> --- a/arch/arm/include/asm/dma-mapping.h
>> +++ b/arch/arm/include/asm/dma-mapping.h
>> @@ -47,12 +47,12 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
>>  #ifndef __arch_pfn_to_dma
>>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>>  {
>> -	return (dma_addr_t)__pfn_to_bus(pfn);
>> +	return (dma_addr_t)__pfn_to_bus(pfn + PHYS_PFN_OFFSET);
>>  }
>>  
>>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>>  {
>> -	return __bus_to_pfn(addr);
>> +	return __bus_to_pfn(addr) - PHYS_PFN_OFFSET;
>>  }
>>  
>>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
>> @@ -64,15 +64,16 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>>  {
>>  	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
>>  }
>> +
>>  #else
>>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>>  {
>> -	return __arch_pfn_to_dma(dev, pfn);
>> +	return __arch_pfn_to_dma(dev, pfn + PHYS_PFN_OFFSET);
>>  }
>>  
>>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>>  {
>> -	return __arch_dma_to_pfn(dev, addr);
>> +	return __arch_dma_to_pfn(dev, addr) - PHYS_PFN_OFFSET;
>>  }
>>  
>>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
>> @@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>>  }
>>  #endif
> 
> Note that I don't think the above are correct - the 'pfn' argument to the
> above functions already includes the PFN offset of physical memory -
> they're all physical_address >> PAGE_SHIFT values.
> 
Right.
Updated patch pushed into the patch system. (patch 7805/1)

Regards,
Santosh

[RFC/RFT PATCH 5/5] ARM: mm: Remove bootmem code and switch to NO_BOOTMEM

[Santosh Shilimkar]

In the effort of using memblock instead of bootmem allocator, ARM arch
needs to be converted to use NO_BOOTMEM. With NO_BOOTMEM change,
now we use memblock allocator to reserve space for crash kernel to
have one less dependency with nobootmem allocator wrapper.

Hopefully the NO_BOOTMEM memblock wrapper(nobootmem.c) will vanish in
near future and archs can directly use memblock APIs. Ongoing thread
on this topic is here:
https://lkml.org/lkml/2013/6/29/77

Boot tested with both flat memory and sparse (faked) memory models
with highmem enabled. LAPE systems with memory starting > 4GB still
won't work but this is one of the step to solve that problem for ARM.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Tejun Heo <tj@kernel.org>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/Kconfig        |    1 +
 arch/arm/kernel/setup.c |    2 +-
 arch/arm/mm/init.c      |   58 ++---------------------------------------------
 3 files changed, 4 insertions(+), 57 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0ac9be6..cff9a59 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -63,6 +63,7 @@ config ARM
 	select OLD_SIGSUSPEND3
 	select OLD_SIGACTION
 	select HAVE_CONTEXT_TRACKING
+	select NO_BOOTMEM
 	help
 	  The ARM series is a line of low-power-consumption RISC chip designs
 	  licensed by ARM Ltd and targeted at embedded applications and
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 63af9a7..2ca4b90 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -805,7 +805,7 @@ static void __init reserve_crashkernel(void)
 	if (ret)
 		return;
 
-	ret = reserve_bootmem(crash_base, crash_size, BOOTMEM_EXCLUSIVE);
+	ret = memblock_reserve(crash_base, crash_size);
 	if (ret < 0) {
 		printk(KERN_WARNING "crashkernel reservation failed - "
 		       "memory is in use (0x%lx)\n", (unsigned long)crash_base);
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 588a2c1..84dd56c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -153,58 +153,6 @@ static void __init find_limits(unsigned long *min, unsigned long *max_low,
 	*max_high = bank_pfn_end(&mi->bank[mi->nr_banks - 1]);
 }
 
-static void __init arm_bootmem_init(unsigned long start_pfn,
-	unsigned long end_pfn)
-{
-	struct memblock_region *reg;
-	unsigned int boot_pages;
-	phys_addr_t bitmap;
-	pg_data_t *pgdat;
-
-	/*
-	 * Allocate the bootmem bitmap page.  This must be in a region
-	 * of memory which has already been mapped.
-	 */
-	boot_pages = bootmem_bootmap_pages(end_pfn - start_pfn);
-	bitmap = memblock_alloc_base(boot_pages << PAGE_SHIFT, L1_CACHE_BYTES,
-				__pfn_to_phys(end_pfn));
-
-	/*
-	 * Initialise the bootmem allocator, handing the
-	 * memory banks over to bootmem.
-	 */
-	node_set_online(0);
-	pgdat = NODE_DATA(0);
-	init_bootmem_node(pgdat, __phys_to_pfn(bitmap), start_pfn, end_pfn);
-
-	/* Free the lowmem regions from memblock into bootmem. */
-	for_each_memblock(memory, reg) {
-		unsigned long start = memblock_region_memory_base_pfn(reg);
-		unsigned long end = memblock_region_memory_end_pfn(reg);
-
-		if (end >= end_pfn)
-			end = end_pfn;
-		if (start >= end)
-			break;
-
-		free_bootmem(__pfn_to_phys(start), (end - start) << PAGE_SHIFT);
-	}
-
-	/* Reserve the lowmem memblock reserved regions in bootmem. */
-	for_each_memblock(reserved, reg) {
-		unsigned long start = memblock_region_reserved_base_pfn(reg);
-		unsigned long end = memblock_region_reserved_end_pfn(reg);
-
-		if (end >= end_pfn)
-			end = end_pfn;
-		if (start >= end)
-			break;
-
-		reserve_bootmem(__pfn_to_phys(start),
-			        (end - start) << PAGE_SHIFT, BOOTMEM_DEFAULT);
-	}
-}
-
 #ifdef CONFIG_ZONE_DMA
 
 unsigned long arm_dma_zone_size __read_mostly;
@@ -242,7 +190,7 @@ void __init setup_dma_zone(struct machine_desc *mdesc)
 #endif
 }
 
-static void __init arm_bootmem_free(unsigned long min, unsigned long max_low,
+static void __init zone_sizes_init(unsigned long min, unsigned long max_low,
 	unsigned long max_high)
 {
 	unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES];
@@ -396,8 +344,6 @@ void __init bootmem_init(void)
 
 	find_limits(&min, &max_low, &max_high);
 
-	arm_bootmem_init(min, max_low);
-
 	/*
 	 * Sparsemem tries to allocate bootmem in memory_present(),
 	 * so must be done after the fixed reservations
@@ -414,7 +360,7 @@ void __init bootmem_init(void)
 	 * the sparse mem_map arrays initialized by sparse_init()
 	 * for memmap_init_zone(), otherwise all PFNs are invalid.
 	 */
-	arm_bootmem_free(min, max_low, max_high);
+	zone_sizes_init(min, max_low, max_high);
 
 	/*
 	 * This doesn't seem to be used by the Linux memory manager any
-- 
1.7.9.5

[RFC/RFT PATCH 5/5] ARM: mm: Remove bootmem code and switch to NO_BOOTMEM

[Santosh Shilimkar]

In the effort of using memblock instead of bootmem allocator, ARM arch
needs to be converted to use NO_BOOTMEM. With NO_BOOTMEM change,
now we use memblock allocator to reserve space for crash kernel to
have one less dependency with nobootmem allocator wrapper.

Hopefully the NO_BOOTMEM memblock wrapper(nobootmem.c) will vanish in
near future and archs can directly use memblock APIs. Ongoing thread
on this topic is here:
https://lkml.org/lkml/2013/6/29/77

Boot tested with both flat memory and sparse (faked) memory models
with highmem enabled. LAPE systems with memory starting > 4GB still
won't work but this is one of the step to solve that problem for ARM.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Tejun Heo <tj@kernel.org>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/Kconfig        |    1 +
 arch/arm/kernel/setup.c |    2 +-
 arch/arm/mm/init.c      |   58 ++---------------------------------------------
 3 files changed, 4 insertions(+), 57 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0ac9be6..cff9a59 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -63,6 +63,7 @@ config ARM
 	select OLD_SIGSUSPEND3
 	select OLD_SIGACTION
 	select HAVE_CONTEXT_TRACKING
+	select NO_BOOTMEM
 	help
 	  The ARM series is a line of low-power-consumption RISC chip designs
 	  licensed by ARM Ltd and targeted at embedded applications and
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 63af9a7..2ca4b90 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -805,7 +805,7 @@ static void __init reserve_crashkernel(void)
 	if (ret)
 		return;
 
-	ret = reserve_bootmem(crash_base, crash_size, BOOTMEM_EXCLUSIVE);
+	ret = memblock_reserve(crash_base, crash_size);
 	if (ret < 0) {
 		printk(KERN_WARNING "crashkernel reservation failed - "
 		       "memory is in use (0x%lx)\n", (unsigned long)crash_base);
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 588a2c1..84dd56c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -153,58 +153,6 @@ static void __init find_limits(unsigned long *min, unsigned long *max_low,
 	*max_high = bank_pfn_end(&mi->bank[mi->nr_banks - 1]);
 }
 
-static void __init arm_bootmem_init(unsigned long start_pfn,
-	unsigned long end_pfn)
-{
-	struct memblock_region *reg;
-	unsigned int boot_pages;
-	phys_addr_t bitmap;
-	pg_data_t *pgdat;
-
-	/*
-	 * Allocate the bootmem bitmap page.  This must be in a region
-	 * of memory which has already been mapped.
-	 */
-	boot_pages = bootmem_bootmap_pages(end_pfn - start_pfn);
-	bitmap = memblock_alloc_base(boot_pages << PAGE_SHIFT, L1_CACHE_BYTES,
-				__pfn_to_phys(end_pfn));
-
-	/*
-	 * Initialise the bootmem allocator, handing the
-	 * memory banks over to bootmem.
-	 */
-	node_set_online(0);
-	pgdat = NODE_DATA(0);
-	init_bootmem_node(pgdat, __phys_to_pfn(bitmap), start_pfn, end_pfn);
-
-	/* Free the lowmem regions from memblock into bootmem. */
-	for_each_memblock(memory, reg) {
-		unsigned long start = memblock_region_memory_base_pfn(reg);
-		unsigned long end = memblock_region_memory_end_pfn(reg);
-
-		if (end >= end_pfn)
-			end = end_pfn;
-		if (start >= end)
-			break;
-
-		free_bootmem(__pfn_to_phys(start), (end - start) << PAGE_SHIFT);
-	}
-
-	/* Reserve the lowmem memblock reserved regions in bootmem. */
-	for_each_memblock(reserved, reg) {
-		unsigned long start = memblock_region_reserved_base_pfn(reg);
-		unsigned long end = memblock_region_reserved_end_pfn(reg);
-
-		if (end >= end_pfn)
-			end = end_pfn;
-		if (start >= end)
-			break;
-
-		reserve_bootmem(__pfn_to_phys(start),
-			        (end - start) << PAGE_SHIFT, BOOTMEM_DEFAULT);
-	}
-}
-
 #ifdef CONFIG_ZONE_DMA
 
 unsigned long arm_dma_zone_size __read_mostly;
@@ -242,7 +190,7 @@ void __init setup_dma_zone(struct machine_desc *mdesc)
 #endif
 }
 
-static void __init arm_bootmem_free(unsigned long min, unsigned long max_low,
+static void __init zone_sizes_init(unsigned long min, unsigned long max_low,
 	unsigned long max_high)
 {
 	unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES];
@@ -396,8 +344,6 @@ void __init bootmem_init(void)
 
 	find_limits(&min, &max_low, &max_high);
 
-	arm_bootmem_init(min, max_low);
-
 	/*
 	 * Sparsemem tries to allocate bootmem in memory_present(),
 	 * so must be done after the fixed reservations
@@ -414,7 +360,7 @@ void __init bootmem_init(void)
 	 * the sparse mem_map arrays initialized by sparse_init()
 	 * for memmap_init_zone(), otherwise all PFNs are invalid.
 	 */
-	arm_bootmem_free(min, max_low, max_high);
+	zone_sizes_init(min, max_low, max_high);
 
 	/*
 	 * This doesn't seem to be used by the Linux memory manager any
-- 
1.7.9.5

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Russell King - ARM Linux]

On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
> PFNs but that breaks the dma_mask for few block layer drivers since
> ARM start of physical memory is not PFN0 unlike most of the architectures.
> Some more read on it is here:
> 	http://lwn.net/Articles/543408/
> 	http://lwn.net/Articles/543424/
> 
> To address this issue, we introduce generic dma_max_pfn() helper which
> can be overridden from the architectures.
> 	
> Another intention behind move to nobootmem is also to convert ARM to
> switch to memblock and getting rid of bootmem allocator dependency which
> don't work for LPAE machines which has physical memory starting beyond
> 4 GB boundary. It needs changes to core kernel and also a new memblock
> API. More on this can be found here:
> 	https://lkml.org/lkml/2013/6/29/77
> 
> I have been trying to cook up these patches with kind help from Russell
> and we know series don't solve all the dma_mask bad assumptions. But at
> least I am hoping that it can get the ball rolling.	
> 
> Comments/testing help is welcome !!

As this is related to some of the cleanup of dma_mask which I've been
doing, I think it may make sense to roll this into one tree.  Any
objection to that?

Can we get any acks on this stuff from Jens and Jejb etc - especially
for the bits which touch block/ and for the scsi bits as these are
touching other subsystems.  (oddly, linux-scsi wasn't on the original
mail for this series summary.)

[RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Russell King - ARM Linux]

On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
> PFNs but that breaks the dma_mask for few block layer drivers since
> ARM start of physical memory is not PFN0 unlike most of the architectures.
> Some more read on it is here:
> 	http://lwn.net/Articles/543408/
> 	http://lwn.net/Articles/543424/
> 
> To address this issue, we introduce generic dma_max_pfn() helper which
> can be overridden from the architectures.
> 	
> Another intention behind move to nobootmem is also to convert ARM to
> switch to memblock and getting rid of bootmem allocator dependency which
> don't work for LPAE machines which has physical memory starting beyond
> 4 GB boundary. It needs changes to core kernel and also a new memblock
> API. More on this can be found here:
> 	https://lkml.org/lkml/2013/6/29/77
> 
> I have been trying to cook up these patches with kind help from Russell
> and we know series don't solve all the dma_mask bad assumptions. But at
> least I am hoping that it can get the ball rolling.	
> 
> Comments/testing help is welcome !!

As this is related to some of the cleanup of dma_mask which I've been
doing, I think it may make sense to roll this into one tree.  Any
objection to that?

Can we get any acks on this stuff from Jens and Jejb etc - especially
for the bits which touch block/ and for the scsi bits as these are
touching other subsystems.  (oddly, linux-scsi wasn't on the original
mail for this series summary.)

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Santosh Shilimkar]

On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
>> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
>> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
>> PFNs but that breaks the dma_mask for few block layer drivers since
>> ARM start of physical memory is not PFN0 unlike most of the architectures.
>> Some more read on it is here:
>> 	http://lwn.net/Articles/543408/
>> 	http://lwn.net/Articles/543424/
>>
>> To address this issue, we introduce generic dma_max_pfn() helper which
>> can be overridden from the architectures.
>> 	
>> Another intention behind move to nobootmem is also to convert ARM to
>> switch to memblock and getting rid of bootmem allocator dependency which
>> don't work for LPAE machines which has physical memory starting beyond
>> 4 GB boundary. It needs changes to core kernel and also a new memblock
>> API. More on this can be found here:
>> 	https://lkml.org/lkml/2013/6/29/77
>>
>> I have been trying to cook up these patches with kind help from Russell
>> and we know series don't solve all the dma_mask bad assumptions. But at
>> least I am hoping that it can get the ball rolling.	
>>
>> Comments/testing help is welcome !!
> 
> As this is related to some of the cleanup of dma_mask which I've been
> doing, I think it may make sense to roll this into one tree.  Any
> objection to that?
> 
> Can we get any acks on this stuff from Jens and Jejb etc - especially
> for the bits which touch block/ and for the scsi bits as these are
> touching other subsystems.  (oddly, linux-scsi wasn't on the original
> mail for this series summary.)
> 
Sorry I missed the scsi lists on the summary patch.

While browsing the code I found another spot in mmc layer which
needs fixing. The patch is at the end of the email with Chris
and linux-mmc cc'ed here.

Regards,
Santosh

>From 06a27a784a1fd86bf22adf1b247ac82a7c21d46b Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Fri, 19 Jul 2013 21:36:46 -0400
Subject: [PATCH] mmc: Use dma_max_pfn(dev) helper for bounce_limit
 calculations

DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. MMC queue layer
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Chris Ball <cjb@laptop.org>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 drivers/mmc/card/queue.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index fa9632e..357bbc5 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -15,6 +15,7 @@
 #include <linux/freezer.h>
 #include <linux/kthread.h>
 #include <linux/scatterlist.h>
+#include <linux/dma-mapping.h>
 
 #include <linux/mmc/card.h>
 #include <linux/mmc/host.h>
@@ -196,7 +197,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
 	struct mmc_queue_req *mqrq_prev = &mq->mqrq[1];
 
 	if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask)
-		limit = *mmc_dev(host)->dma_mask;
+		limit = dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT;
 
 	mq->card = card;
 	mq->queue = blk_init_queue(mmc_request_fn, lock);
-- 
1.7.9.5

[RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Santosh Shilimkar]

On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
>> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
>> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
>> PFNs but that breaks the dma_mask for few block layer drivers since
>> ARM start of physical memory is not PFN0 unlike most of the architectures.
>> Some more read on it is here:
>> 	http://lwn.net/Articles/543408/
>> 	http://lwn.net/Articles/543424/
>>
>> To address this issue, we introduce generic dma_max_pfn() helper which
>> can be overridden from the architectures.
>> 	
>> Another intention behind move to nobootmem is also to convert ARM to
>> switch to memblock and getting rid of bootmem allocator dependency which
>> don't work for LPAE machines which has physical memory starting beyond
>> 4 GB boundary. It needs changes to core kernel and also a new memblock
>> API. More on this can be found here:
>> 	https://lkml.org/lkml/2013/6/29/77
>>
>> I have been trying to cook up these patches with kind help from Russell
>> and we know series don't solve all the dma_mask bad assumptions. But at
>> least I am hoping that it can get the ball rolling.	
>>
>> Comments/testing help is welcome !!
> 
> As this is related to some of the cleanup of dma_mask which I've been
> doing, I think it may make sense to roll this into one tree.  Any
> objection to that?
> 
> Can we get any acks on this stuff from Jens and Jejb etc - especially
> for the bits which touch block/ and for the scsi bits as these are
> touching other subsystems.  (oddly, linux-scsi wasn't on the original
> mail for this series summary.)
> 
Sorry I missed the scsi lists on the summary patch.

While browsing the code I found another spot in mmc layer which
needs fixing. The patch is at the end of the email with Chris
and linux-mmc cc'ed here.

Regards,
Santosh

>From 06a27a784a1fd86bf22adf1b247ac82a7c21d46b Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Fri, 19 Jul 2013 21:36:46 -0400
Subject: [PATCH] mmc: Use dma_max_pfn(dev) helper for bounce_limit
 calculations

DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. MMC queue layer
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Chris Ball <cjb@laptop.org>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 drivers/mmc/card/queue.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index fa9632e..357bbc5 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -15,6 +15,7 @@
 #include <linux/freezer.h>
 #include <linux/kthread.h>
 #include <linux/scatterlist.h>
+#include <linux/dma-mapping.h>
 
 #include <linux/mmc/card.h>
 #include <linux/mmc/host.h>
@@ -196,7 +197,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
 	struct mmc_queue_req *mqrq_prev = &mq->mqrq[1];
 
 	if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask)
-		limit = *mmc_dev(host)->dma_mask;
+		limit = dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT;
 
 	mq->card = card;
 	mq->queue = blk_init_queue(mmc_request_fn, lock);
-- 
1.7.9.5

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Santosh Shilimkar]

On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
>> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
>> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
>> PFNs but that breaks the dma_mask for few block layer drivers since
>> ARM start of physical memory is not PFN0 unlike most of the architectures.
>> Some more read on it is here:
>> 	http://lwn.net/Articles/543408/
>> 	http://lwn.net/Articles/543424/
>>
>> To address this issue, we introduce generic dma_max_pfn() helper which
>> can be overridden from the architectures.
>> 	
>> Another intention behind move to nobootmem is also to convert ARM to
>> switch to memblock and getting rid of bootmem allocator dependency which
>> don't work for LPAE machines which has physical memory starting beyond
>> 4 GB boundary. It needs changes to core kernel and also a new memblock
>> API. More on this can be found here:
>> 	https://lkml.org/lkml/2013/6/29/77
>>
>> I have been trying to cook up these patches with kind help from Russell
>> and we know series don't solve all the dma_mask bad assumptions. But at
>> least I am hoping that it can get the ball rolling.	
>>
>> Comments/testing help is welcome !!
> 
> As this is related to some of the cleanup of dma_mask which I've been
> doing, I think it may make sense to roll this into one tree.  Any
> objection to that?
> 
> Can we get any acks on this stuff from Jens and Jejb etc - especially
> for the bits which touch block/ and for the scsi bits as these are
> touching other subsystems.  (oddly, linux-scsi wasn't on the original
> mail for this series summary.)
> 
Sorry I missed the scsi lists on the summary patch.

While browsing the code I found another spot in mmc layer which
needs fixing. The patch is at the end of the email with Chris
and linux-mmc cc'ed here.

Regards,
Santosh

>From 06a27a784a1fd86bf22adf1b247ac82a7c21d46b Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Fri, 19 Jul 2013 21:36:46 -0400
Subject: [PATCH] mmc: Use dma_max_pfn(dev) helper for bounce_limit
 calculations

DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. MMC queue layer
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Chris Ball <cjb@laptop.org>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 drivers/mmc/card/queue.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index fa9632e..357bbc5 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -15,6 +15,7 @@
 #include <linux/freezer.h>
 #include <linux/kthread.h>
 #include <linux/scatterlist.h>
+#include <linux/dma-mapping.h>
 
 #include <linux/mmc/card.h>
 #include <linux/mmc/host.h>
@@ -196,7 +197,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
 	struct mmc_queue_req *mqrq_prev = &mq->mqrq[1];
 
 	if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask)
-		limit = *mmc_dev(host)->dma_mask;
+		limit = dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT;
 
 	mq->card = card;
 	mq->queue = blk_init_queue(mmc_request_fn, lock);
-- 
1.7.9.5

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Russell King - ARM Linux]

On Fri, Jul 26, 2013 at 12:28:26PM -0400, Santosh Shilimkar wrote:
> On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote:
> > On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
> >> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
> >> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
> >> PFNs but that breaks the dma_mask for few block layer drivers since
> >> ARM start of physical memory is not PFN0 unlike most of the architectures.
> >> Some more read on it is here:
> >> 	http://lwn.net/Articles/543408/
> >> 	http://lwn.net/Articles/543424/
> >>
> >> To address this issue, we introduce generic dma_max_pfn() helper which
> >> can be overridden from the architectures.
> >> 	
> >> Another intention behind move to nobootmem is also to convert ARM to
> >> switch to memblock and getting rid of bootmem allocator dependency which
> >> don't work for LPAE machines which has physical memory starting beyond
> >> 4 GB boundary. It needs changes to core kernel and also a new memblock
> >> API. More on this can be found here:
> >> 	https://lkml.org/lkml/2013/6/29/77
> >>
> >> I have been trying to cook up these patches with kind help from Russell
> >> and we know series don't solve all the dma_mask bad assumptions. But at
> >> least I am hoping that it can get the ball rolling.	
> >>
> >> Comments/testing help is welcome !!
> > 
> > As this is related to some of the cleanup of dma_mask which I've been
> > doing, I think it may make sense to roll this into one tree.  Any
> > objection to that?
> > 
> > Can we get any acks on this stuff from Jens and Jejb etc - especially
> > for the bits which touch block/ and for the scsi bits as these are
> > touching other subsystems.  (oddly, linux-scsi wasn't on the original
> > mail for this series summary.)
> > 
> Sorry I missed the scsi lists on the summary patch.
> 
> While browsing the code I found another spot in mmc layer which
> needs fixing. The patch is at the end of the email with Chris
> and linux-mmc cc'ed here.

Would you mind putting them all in the patch system, I can add the acks
should anyone supply them later, and I'll repost them along with my set
of dma-mask patches.  Thanks.

[RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Russell King - ARM Linux]

On Fri, Jul 26, 2013 at 12:28:26PM -0400, Santosh Shilimkar wrote:
> On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote:
> > On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
> >> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
> >> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
> >> PFNs but that breaks the dma_mask for few block layer drivers since
> >> ARM start of physical memory is not PFN0 unlike most of the architectures.
> >> Some more read on it is here:
> >> 	http://lwn.net/Articles/543408/
> >> 	http://lwn.net/Articles/543424/
> >>
> >> To address this issue, we introduce generic dma_max_pfn() helper which
> >> can be overridden from the architectures.
> >> 	
> >> Another intention behind move to nobootmem is also to convert ARM to
> >> switch to memblock and getting rid of bootmem allocator dependency which
> >> don't work for LPAE machines which has physical memory starting beyond
> >> 4 GB boundary. It needs changes to core kernel and also a new memblock
> >> API. More on this can be found here:
> >> 	https://lkml.org/lkml/2013/6/29/77
> >>
> >> I have been trying to cook up these patches with kind help from Russell
> >> and we know series don't solve all the dma_mask bad assumptions. But at
> >> least I am hoping that it can get the ball rolling.	
> >>
> >> Comments/testing help is welcome !!
> > 
> > As this is related to some of the cleanup of dma_mask which I've been
> > doing, I think it may make sense to roll this into one tree.  Any
> > objection to that?
> > 
> > Can we get any acks on this stuff from Jens and Jejb etc - especially
> > for the bits which touch block/ and for the scsi bits as these are
> > touching other subsystems.  (oddly, linux-scsi wasn't on the original
> > mail for this series summary.)
> > 
> Sorry I missed the scsi lists on the summary patch.
> 
> While browsing the code I found another spot in mmc layer which
> needs fixing. The patch is at the end of the email with Chris
> and linux-mmc cc'ed here.

Would you mind putting them all in the patch system, I can add the acks
should anyone supply them later, and I'll repost them along with my set
of dma-mask patches.  Thanks.

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Santosh Shilimkar]

On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 12:28:26PM -0400, Santosh Shilimkar wrote:
>> On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote:
>>> On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
>>>> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
>>>> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
>>>> PFNs but that breaks the dma_mask for few block layer drivers since
>>>> ARM start of physical memory is not PFN0 unlike most of the architectures.
>>>> Some more read on it is here:
>>>> 	http://lwn.net/Articles/543408/
>>>> 	http://lwn.net/Articles/543424/
>>>>
>>>> To address this issue, we introduce generic dma_max_pfn() helper which
>>>> can be overridden from the architectures.
>>>> 	
>>>> Another intention behind move to nobootmem is also to convert ARM to
>>>> switch to memblock and getting rid of bootmem allocator dependency which
>>>> don't work for LPAE machines which has physical memory starting beyond
>>>> 4 GB boundary. It needs changes to core kernel and also a new memblock
>>>> API. More on this can be found here:
>>>> 	https://lkml.org/lkml/2013/6/29/77
>>>>
>>>> I have been trying to cook up these patches with kind help from Russell
>>>> and we know series don't solve all the dma_mask bad assumptions. But at
>>>> least I am hoping that it can get the ball rolling.	
>>>>
>>>> Comments/testing help is welcome !!
>>>
>>> As this is related to some of the cleanup of dma_mask which I've been
>>> doing, I think it may make sense to roll this into one tree.  Any
>>> objection to that?
>>>
>>> Can we get any acks on this stuff from Jens and Jejb etc - especially
>>> for the bits which touch block/ and for the scsi bits as these are
>>> touching other subsystems.  (oddly, linux-scsi wasn't on the original
>>> mail for this series summary.)
>>>
>> Sorry I missed the scsi lists on the summary patch.
>>
>> While browsing the code I found another spot in mmc layer which
>> needs fixing. The patch is at the end of the email with Chris
>> and linux-mmc cc'ed here.
> 
> Would you mind putting them all in the patch system, I can add the acks
> should anyone supply them later, and I'll repost them along with my set
> of dma-mask patches.  Thanks.
> 
Done.
7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1

Didn't know how to get XXXX/1,2,3,4... pushed into the tracker.
BTW, I have also pushed the patched on my git tree branch [1] just
in case you or some one needs it.

Regards,
Santosh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
3.12/nobootmem_n_dma-mask

[RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Santosh Shilimkar]

On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 12:28:26PM -0400, Santosh Shilimkar wrote:
>> On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote:
>>> On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
>>>> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
>>>> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
>>>> PFNs but that breaks the dma_mask for few block layer drivers since
>>>> ARM start of physical memory is not PFN0 unlike most of the architectures.
>>>> Some more read on it is here:
>>>> 	http://lwn.net/Articles/543408/
>>>> 	http://lwn.net/Articles/543424/
>>>>
>>>> To address this issue, we introduce generic dma_max_pfn() helper which
>>>> can be overridden from the architectures.
>>>> 	
>>>> Another intention behind move to nobootmem is also to convert ARM to
>>>> switch to memblock and getting rid of bootmem allocator dependency which
>>>> don't work for LPAE machines which has physical memory starting beyond
>>>> 4 GB boundary. It needs changes to core kernel and also a new memblock
>>>> API. More on this can be found here:
>>>> 	https://lkml.org/lkml/2013/6/29/77
>>>>
>>>> I have been trying to cook up these patches with kind help from Russell
>>>> and we know series don't solve all the dma_mask bad assumptions. But at
>>>> least I am hoping that it can get the ball rolling.	
>>>>
>>>> Comments/testing help is welcome !!
>>>
>>> As this is related to some of the cleanup of dma_mask which I've been
>>> doing, I think it may make sense to roll this into one tree.  Any
>>> objection to that?
>>>
>>> Can we get any acks on this stuff from Jens and Jejb etc - especially
>>> for the bits which touch block/ and for the scsi bits as these are
>>> touching other subsystems.  (oddly, linux-scsi wasn't on the original
>>> mail for this series summary.)
>>>
>> Sorry I missed the scsi lists on the summary patch.
>>
>> While browsing the code I found another spot in mmc layer which
>> needs fixing. The patch is at the end of the email with Chris
>> and linux-mmc cc'ed here.
> 
> Would you mind putting them all in the patch system, I can add the acks
> should anyone supply them later, and I'll repost them along with my set
> of dma-mask patches.  Thanks.
> 
Done.
7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1

Didn't know how to get XXXX/1,2,3,4... pushed into the tracker.
BTW, I have also pushed the patched on my git tree branch [1] just
in case you or some one needs it.

Regards,
Santosh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
3.12/nobootmem_n_dma-mask

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Santosh Shilimkar]

On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 12:28:26PM -0400, Santosh Shilimkar wrote:
>> On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote:
>>> On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
>>>> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
>>>> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
>>>> PFNs but that breaks the dma_mask for few block layer drivers since
>>>> ARM start of physical memory is not PFN0 unlike most of the architectures.
>>>> Some more read on it is here:
>>>> 	http://lwn.net/Articles/543408/
>>>> 	http://lwn.net/Articles/543424/
>>>>
>>>> To address this issue, we introduce generic dma_max_pfn() helper which
>>>> can be overridden from the architectures.
>>>> 	
>>>> Another intention behind move to nobootmem is also to convert ARM to
>>>> switch to memblock and getting rid of bootmem allocator dependency which
>>>> don't work for LPAE machines which has physical memory starting beyond
>>>> 4 GB boundary. It needs changes to core kernel and also a new memblock
>>>> API. More on this can be found here:
>>>> 	https://lkml.org/lkml/2013/6/29/77
>>>>
>>>> I have been trying to cook up these patches with kind help from Russell
>>>> and we know series don't solve all the dma_mask bad assumptions. But at
>>>> least I am hoping that it can get the ball rolling.	
>>>>
>>>> Comments/testing help is welcome !!
>>>
>>> As this is related to some of the cleanup of dma_mask which I've been
>>> doing, I think it may make sense to roll this into one tree.  Any
>>> objection to that?
>>>
>>> Can we get any acks on this stuff from Jens and Jejb etc - especially
>>> for the bits which touch block/ and for the scsi bits as these are
>>> touching other subsystems.  (oddly, linux-scsi wasn't on the original
>>> mail for this series summary.)
>>>
>> Sorry I missed the scsi lists on the summary patch.
>>
>> While browsing the code I found another spot in mmc layer which
>> needs fixing. The patch is at the end of the email with Chris
>> and linux-mmc cc'ed here.
> 
> Would you mind putting them all in the patch system, I can add the acks
> should anyone supply them later, and I'll repost them along with my set
> of dma-mask patches.  Thanks.
> 
Done.
7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1

Didn't know how to get XXXX/1,2,3,4... pushed into the tracker.
BTW, I have also pushed the patched on my git tree branch [1] just
in case you or some one needs it.

Regards,
Santosh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
3.12/nobootmem_n_dma-mask

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Russell King - ARM Linux]

On Mon, Jul 29, 2013 at 09:26:44AM -0400, Santosh Shilimkar wrote:
> On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
> > Would you mind putting them all in the patch system, I can add the acks
> > should anyone supply them later, and I'll repost them along with my set
> > of dma-mask patches.  Thanks.
> > 
> Done.
> 7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1
> 
> Didn't know how to get XXXX/1,2,3,4... pushed into the tracker.
> BTW, I have also pushed the patched on my git tree branch [1] just
> in case you or some one needs it.

Thanks.  I'd prefer not to have them as stable commits yet because should
we get acks from Jens, Jejb or cjb, we will need to add their acks to them.

My dma-masks branch is still very much unstable at the moment (which is
why its not published) but I shall be posting the patches during this
week.

[RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Russell King - ARM Linux]

On Mon, Jul 29, 2013 at 09:26:44AM -0400, Santosh Shilimkar wrote:
> On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
> > Would you mind putting them all in the patch system, I can add the acks
> > should anyone supply them later, and I'll repost them along with my set
> > of dma-mask patches.  Thanks.
> > 
> Done.
> 7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1
> 
> Didn't know how to get XXXX/1,2,3,4... pushed into the tracker.
> BTW, I have also pushed the patched on my git tree branch [1] just
> in case you or some one needs it.

Thanks.  I'd prefer not to have them as stable commits yet because should
we get acks from Jens, Jejb or cjb, we will need to add their acks to them.

My dma-masks branch is still very much unstable at the moment (which is
why its not published) but I shall be posting the patches during this
week.

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Russell King - ARM Linux]

On Mon, Jul 29, 2013 at 09:26:44AM -0400, Santosh Shilimkar wrote:
> On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
> > Would you mind putting them all in the patch system, I can add the acks
> > should anyone supply them later, and I'll repost them along with my set
> > of dma-mask patches.  Thanks.
> > 
> Done.
> 7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1
> 
> Didn't know how to get XXXX/1,2,3,4... pushed into the tracker.
> BTW, I have also pushed the patched on my git tree branch [1] just
> in case you or some one needs it.

Thanks.  I'd prefer not to have them as stable commits yet because should
we get acks from Jens, Jejb or cjb, we will need to add their acks to them.

My dma-masks branch is still very much unstable at the moment (which is
why its not published) but I shall be posting the patches during this
week.

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Santosh Shilimkar]

On Monday 29 July 2013 09:40 AM, Russell King - ARM Linux wrote:
> On Mon, Jul 29, 2013 at 09:26:44AM -0400, Santosh Shilimkar wrote:
>> On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
>>> Would you mind putting them all in the patch system, I can add the acks
>>> should anyone supply them later, and I'll repost them along with my set
>>> of dma-mask patches.  Thanks.
>>>
>> Done.
>> 7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1
>>
>> Didn't know how to get XXXX/1,2,3,4... pushed into the tracker.
>> BTW, I have also pushed the patched on my git tree branch [1] just
>> in case you or some one needs it.
> 
> Thanks.  I'd prefer not to have them as stable commits yet because should
> we get acks from Jens, Jejb or cjb, we will need to add their acks to them.
>
right.
 
> My dma-masks branch is still very much unstable at the moment (which is
> why its not published) but I shall be posting the patches during this
> week.
> 
Sure.

Regards,
Santosh

[RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Santosh Shilimkar]

On Monday 29 July 2013 09:40 AM, Russell King - ARM Linux wrote:
> On Mon, Jul 29, 2013 at 09:26:44AM -0400, Santosh Shilimkar wrote:
>> On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
>>> Would you mind putting them all in the patch system, I can add the acks
>>> should anyone supply them later, and I'll repost them along with my set
>>> of dma-mask patches.  Thanks.
>>>
>> Done.
>> 7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1
>>
>> Didn't know how to get XXXX/1,2,3,4... pushed into the tracker.
>> BTW, I have also pushed the patched on my git tree branch [1] just
>> in case you or some one needs it.
> 
> Thanks.  I'd prefer not to have them as stable commits yet because should
> we get acks from Jens, Jejb or cjb, we will need to add their acks to them.
>
right.
 
> My dma-masks branch is still very much unstable at the moment (which is
> why its not published) but I shall be posting the patches during this
> week.
> 
Sure.

Regards,
Santosh

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Santosh Shilimkar]

On Monday 29 July 2013 09:40 AM, Russell King - ARM Linux wrote:
> On Mon, Jul 29, 2013 at 09:26:44AM -0400, Santosh Shilimkar wrote:
>> On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
>>> Would you mind putting them all in the patch system, I can add the acks
>>> should anyone supply them later, and I'll repost them along with my set
>>> of dma-mask patches.  Thanks.
>>>
>> Done.
>> 7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1
>>
>> Didn't know how to get XXXX/1,2,3,4... pushed into the tracker.
>> BTW, I have also pushed the patched on my git tree branch [1] just
>> in case you or some one needs it.
> 
> Thanks.  I'd prefer not to have them as stable commits yet because should
> we get acks from Jens, Jejb or cjb, we will need to add their acks to them.
>
right.
 
> My dma-masks branch is still very much unstable at the moment (which is
> why its not published) but I shall be posting the patches during this
> week.
> 
Sure.

Regards,
Santosh