MIPS raw_local_irq_restore flags

MIPS raw_local_irq_restore flags

[Mikael Starvik]

For the common case CONFIG_CPU_MIPSR2 && CONFIG_IRQ_CPU raw_local_irq_restore_flags is defined as:

"       beqz    \\flags, 1f                                     \n"
"       di                                                      \n"
"       ei                                                      \n"
"1:                                                             \n"

Doesn't this imply that you can't do recursive local_irq_save() (with different locks ofcourse)? 

Best Regards
/Mikael

Re: MIPS raw_local_irq_restore flags

[David Daney]

On 03/11/2010 06:59 AM, Mikael Starvik wrote:
> For the common case CONFIG_CPU_MIPSR2&&  CONFIG_IRQ_CPU raw_local_irq_restore_flags is defined as:
>
> "       beqz    \\flags, 1f                                     \n"
> "       di                                                      \n"
> "       ei                                                      \n"
> "1:                                                             \n"
>
> Doesn't this imply that you can't do recursive local_irq_save() (with different locks ofcourse)?
>

No.  In fact local_irq_save() is intentionally designed to be used 
'recursively'.

David Daney

RE: MIPS raw_local_irq_restore flags

[Ramgopal Kota]

Hi ,

Is there any moderation done to the messages posted to this mailing list. I posted couple of messages but none has come , just wondering what is wrong ? 

Thanks & Regards,
Ramgopal Kota
-----Original Message-----
From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Mikael Starvik
Sent: Thursday, March 11, 2010 8:30 PM
To: linux-mips@linux-mips.org
Subject: MIPS raw_local_irq_restore flags

For the common case CONFIG_CPU_MIPSR2 && CONFIG_IRQ_CPU raw_local_irq_restore_flags is defined as:

"       beqz    \\flags, 1f                                     \n"
"       di                                                      \n"
"       ei                                                      \n"
"1:                                                             \n"

Doesn't this imply that you can't do recursive local_irq_save() (with different locks ofcourse)? 

Best Regards
/Mikael

HIGHMEM not working.

[Ramgopal Kota]

 Hi,

I need help in running CPU with HIGH_MEM.
Below is the processor memory map .. It is base on MIPS64K Core.

0x0000_0000  -- 0x07FF_FFFF   -> RAM (Region 1)
0x0800_0000  -- 0x0FFF_FFFF   -> PCI BUS 1
0x2000_0000  -- 0x2FFF_FFFF   -> Flash Region
0x4000_0000  -- 0x47FF_FFFF   -> PCI BUS 2
0x8000_0000  -- 0xCFFF_FFFF   -> RAM (Region 2) the first 128MB is remapped into 0x8000_0000 .. 

The system has 256MB of PHYSICAL RAM .. 

I configured TLB's and added memory regions. The system boots up correctly ..
If I show cat /proc/meminfo it shows 256MB , it could allocate memory ( I verified with a simple program allocating the memory and writing some data)

There is a PCI MAC device on PCI BUS 2. The CPU is not able to perform DMA to/from device.
The MAC driver is allocating DMA buffers using the following code ..
{
    phy = virt_to_bus(high_memory);  << Resulting in 0xa000_0000; 
    virt = ioremap(pbase);    
}
The Linux configuration has no ZONE_DMA configuration ..

Few questions ..
  A) HIGH_MEMORY START Address is configured to 0x2000_0000 , is it correct value.
  B) Are there any data which can be dumped to know more information ?
  C) Do I need to enable MEMORY Discontinuous Config also ?  ( As I did not see a reason to enable this as memory in Region 2 is contiguous)
  D) I read in some articles on internet that if HIGH_MEM is used,PCI bounce buffers needs to be used ? Can some body point me how to set this up ?

Thanks & Regards,
Ramgopal Kota

Re: HIGHMEM not working.

[Adam Jiang]

2010/3/17 Ramgopal Kota <rkota@broadcom.com>
>
> Adam,
>
> Thanks for the response ...
>
> We enabled CONFIG_SPARSEMEM in place of CONFIG_DISCONTIGMEM .. It is specified that SPARSEMEM will eventually replaces DISCONTIGMEM
> (http://marc.info/?l=lhms-devel&m=111451976115580&w=2)

Yes. It seems a better way to do this.

> We have configured zones as below in paging_init function ..
> max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
> max_zone_pfns[ZONE_NORMAL] = max_low_pfn;   <<  0x20000
> max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;  <<  0x8FFFF
> We added 2 memory regions as below ..
> add_memory_region(0x00000000, 128MB, BOOT_MEM_RAM);
> add_memory_region(0x88000000  ,128MB, BOOT_MEM_RAM);
> Is this what you are refering as 2 memory nodes ??
>

OK. Physical memory is managed in nodes and zones. Because you have
mentioned that there would be 2 ranges of memory on your architecture
like

Node 0   [0x0000 0000, 0x0800 0000]
Node 1   [0x8000 0000, 0xcfff ffff]

I guess you can define these two nodes by add_memory_region function
but I am not sure... However, the start_addr of the second node would
be 0x8000 0000 rather than 0x8800 0000. On the other hand, I think the
following code is not correct

> max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
> max_zone_pfns[ZONE_NORMAL] = max_low_pfn;   <<  0x20000
> max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;  <<  0x8FFFF

if max_low_pfn is 0x20000, then your ZONE_NORMAL will end up at 0x2000
0000(PFN x PAGE_SIZE); but according to the information about physical
memory address you provided. 0x0800 0000 ~ 0x0fff ffff is used as PCI
device addresses. Em~, the highend_pfn is not correct either. Please
double check these address.

Bounce buffers are required for devices that cannnot access the full
range of memory available to the CPU, such as old ISA cards with only
24bit address. Is this the situation you have to face? If it is needed
you may look into function create_bounce_buffer() in the other drivers
for details, however, I still think you would not need it. By the way,
high memory just mapped to low memory by kmap() function. You don't
need to define a ZONE_HIGH in your configuration. Because 0x8000_0000
~ 0x8fff ffff is kseg0 on MIPS. You can handle them as ZONE_NORMAL in
much easier way.

Best regards,
/Adam

>
> What is the significance of MAX_PHYSMEM_BITS  & SECTION_SIZE_BITS .. Sorry for troubling with novoice questions ..
>
> Thanks & Regards,
> Ramgopal Kota
> ________________________________
> From: Adam Jiang [mailto:jiang.adam@gmail.com]
> Sent: Wednesday, March 17, 2010 12:36 PM
> To: Ramgopal Kota
> Subject: Re: HIGHMEM not working.
>
> 2010/3/17 Ramgopal Kota <rkota@broadcom.com>
>>
>>  Hi,
>>
>> I need help in running CPU with HIGH_MEM.
>> Below is the processor memory map .. It is base on MIPS64K Core.
>>
>> 0x0000_0000  -- 0x07FF_FFFF   -> RAM (Region 1)
>> 0x0800_0000  -- 0x0FFF_FFFF   -> PCI BUS 1
>> 0x2000_0000  -- 0x2FFF_FFFF   -> Flash Region
>> 0x4000_0000  -- 0x47FF_FFFF   -> PCI BUS 2
>> 0x8000_0000  -- 0xCFFF_FFFF   -> RAM (Region 2) the first 128MB is remapped into 0x8000_0000 ..
>>
>> The system has 256MB of PHYSICAL RAM ..
>>
>> I configured TLB's and added memory regions. The system boots up correctly ..
>> If I show cat /proc/meminfo it shows 256MB , it could allocate memory ( I verified with a simple program allocating the memory and writing some data)
>>
>> There is a PCI MAC device on PCI BUS 2. The CPU is not able to perform DMA to/from device.
>> The MAC driver is allocating DMA buffers using the following code ..
>> {
>>    phy = virt_to_bus(high_memory);  << Resulting in 0xa000_0000;
>>    virt = ioremap(pbase);
>> }
>> The Linux configuration has no ZONE_DMA configuration ..
>>
>>
>> Few questions ..
>>  A) HIGH_MEMORY START Address is configured to 0x2000_0000 , is it correct value.
>
> I don't think 0x2000_0000 is a correct value for HIGH_MEM in general meaning. The value depends on which architecture you're working on. And its start address could be initialed in
> LNX/arch/(arch)/kernel/setup.c
> LNX/arch/(arch)/mm/init.c
> in your case, I thing you can use all your memory as ZONE_NORMAL or ZONE_DMA but not ZONE_HIGH.
>
>>
>>  B) Are there any data which can be dumped to know more information ?
>
> Yes, of course. You could try to add some printk in the above two files in bootmem_init() function or function free_area_init_core() to see what's the memory layout exactly.
>
>>
>>  C) Do I need to enable MEMORY Discontinuous Config also ?  ( As I did not see a reason to enable this as memory in Region 2 is contiguous)
>
> Since you have two separated range fsyc memory on you board, I think you do really need CONFIG_DISCONTIGMEM_*; You may also need to define two memory nodes in bootmem.
>
>>
>>  D) I read in some articles on internet that if HIGH_MEM is used,PCI bounce buffers needs to be used ? Can some body point me how to set this up ?
>
> Usually, DMA data transferring could perform directly on fysc memory address. You may not need bounce buffer or scatter/gather operations if you can config all your memory to ZONE_NORMAL. ZONE_DMA is not necessary because this area is only required by kmalloc call with GFP_DMA flags.
> Best regards,
> /Adam
>
>>
>> Thanks & Regards,
>> Ramgopal Kota
>>
>>
>
> --
> Adam Jiang
> -----------------------------------
> e-mail:jiang.adam@gmail.com
> http://www.adamjiang.com
> -----------------------------------



--
Adam Jiang
-----------------------------------
e-mail:jiang.adam@gmail.com
http://www.adamjiang.com
-----------------------------------

RE: HIGHMEM not working.

[Ramgopal Kota]

Adam, 

The first 128MB of 0x8000_0000 is mapped to 0x0000_0000 address, hence I added them as 2 nodes with 0 & 0x8800_0000 ..
max_zone_pfns[ZONE_NORMAL] should be assigned with maximum physical address of the memory i.e. address >> page_size ...
As the physical address is 0x07FF_FFFF .. The ZONE_NORMAL PFN should be 0x07FFF ..

As ZONE_HIGH max address is 0x8FFF_FFFF .. The ZONE_HIGH PFN should be 0x8FFFF .. Why do you think this is wrong ?

I did not get how I can handle with out ZONE_HIGH ?? Can you explain me in more detail please ..

Thanks & Regards,
Ramgopal Kota

-----Original Message-----
From: Adam Jiang [mailto:jiang.adam@gmail.com] 
Sent: Wednesday, March 17, 2010 5:00 PM
To: linux-mips@linux-mips.org
Cc: Ramgopal Kota
Subject: Re: HIGHMEM not working.

2010/3/17 Ramgopal Kota <rkota@broadcom.com>
>
> Adam,
>
> Thanks for the response ...
>
> We enabled CONFIG_SPARSEMEM in place of CONFIG_DISCONTIGMEM .. It is specified that SPARSEMEM will eventually replaces DISCONTIGMEM
> (http://marc.info/?l=lhms-devel&m=111451976115580&w=2)

Yes. It seems a better way to do this.

> We have configured zones as below in paging_init function ..
> max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
> max_zone_pfns[ZONE_NORMAL] = max_low_pfn;   <<  0x20000
> max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;  <<  0x8FFFF
> We added 2 memory regions as below ..
> add_memory_region(0x00000000, 128MB, BOOT_MEM_RAM);
> add_memory_region(0x88000000  ,128MB, BOOT_MEM_RAM);
> Is this what you are refering as 2 memory nodes ??
>

OK. Physical memory is managed in nodes and zones. Because you have
mentioned that there would be 2 ranges of memory on your architecture
like

Node 0   [0x0000 0000, 0x0800 0000]
Node 1   [0x8000 0000, 0xcfff ffff]

I guess you can define these two nodes by add_memory_region function
but I am not sure... However, the start_addr of the second node would
be 0x8000 0000 rather than 0x8800 0000. On the other hand, I think the
following code is not correct

> max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
> max_zone_pfns[ZONE_NORMAL] = max_low_pfn;   <<  0x20000
> max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;  <<  0x8FFFF

if max_low_pfn is 0x20000, then your ZONE_NORMAL will end up at 0x2000
0000(PFN x PAGE_SIZE); but according to the information about physical
memory address you provided. 0x0800 0000 ~ 0x0fff ffff is used as PCI
device addresses. Em~, the highend_pfn is not correct either. Please
double check these address.

Bounce buffers are required for devices that cannnot access the full
range of memory available to the CPU, such as old ISA cards with only
24bit address. Is this the situation you have to face? If it is needed
you may look into function create_bounce_buffer() in the other drivers
for details, however, I still think you would not need it. By the way,
high memory just mapped to low memory by kmap() function. You don't
need to define a ZONE_HIGH in your configuration. Because 0x8000_0000
~ 0x8fff ffff is kseg0 on MIPS. You can handle them as ZONE_NORMAL in
much easier way.

Best regards,
/Adam

>
> What is the significance of MAX_PHYSMEM_BITS  & SECTION_SIZE_BITS .. Sorry for troubling with novoice questions ..
>
> Thanks & Regards,
> Ramgopal Kota
> ________________________________
> From: Adam Jiang [mailto:jiang.adam@gmail.com]
> Sent: Wednesday, March 17, 2010 12:36 PM
> To: Ramgopal Kota
> Subject: Re: HIGHMEM not working.
>
> 2010/3/17 Ramgopal Kota <rkota@broadcom.com>
>>
>>  Hi,
>>
>> I need help in running CPU with HIGH_MEM.
>> Below is the processor memory map .. It is base on MIPS64K Core.
>>
>> 0x0000_0000  -- 0x07FF_FFFF   -> RAM (Region 1)
>> 0x0800_0000  -- 0x0FFF_FFFF   -> PCI BUS 1
>> 0x2000_0000  -- 0x2FFF_FFFF   -> Flash Region
>> 0x4000_0000  -- 0x47FF_FFFF   -> PCI BUS 2
>> 0x8000_0000  -- 0xCFFF_FFFF   -> RAM (Region 2) the first 128MB is remapped into 0x8000_0000 ..
>>
>> The system has 256MB of PHYSICAL RAM ..
>>
>> I configured TLB's and added memory regions. The system boots up correctly ..
>> If I show cat /proc/meminfo it shows 256MB , it could allocate memory ( I verified with a simple program allocating the memory and writing some data)
>>
>> There is a PCI MAC device on PCI BUS 2. The CPU is not able to perform DMA to/from device.
>> The MAC driver is allocating DMA buffers using the following code ..
>> {
>>    phy = virt_to_bus(high_memory);  << Resulting in 0xa000_0000;
>>    virt = ioremap(pbase);
>> }
>> The Linux configuration has no ZONE_DMA configuration ..
>>
>>
>> Few questions ..
>>  A) HIGH_MEMORY START Address is configured to 0x2000_0000 , is it correct value.
>
> I don't think 0x2000_0000 is a correct value for HIGH_MEM in general meaning. The value depends on which architecture you're working on. And its start address could be initialed in
> LNX/arch/(arch)/kernel/setup.c
> LNX/arch/(arch)/mm/init.c
> in your case, I thing you can use all your memory as ZONE_NORMAL or ZONE_DMA but not ZONE_HIGH.
>
>>
>>  B) Are there any data which can be dumped to know more information ?
>
> Yes, of course. You could try to add some printk in the above two files in bootmem_init() function or function free_area_init_core() to see what's the memory layout exactly.
>
>>
>>  C) Do I need to enable MEMORY Discontinuous Config also ?  ( As I did not see a reason to enable this as memory in Region 2 is contiguous)
>
> Since you have two separated range fsyc memory on you board, I think you do really need CONFIG_DISCONTIGMEM_*; You may also need to define two memory nodes in bootmem.
>
>>
>>  D) I read in some articles on internet that if HIGH_MEM is used,PCI bounce buffers needs to be used ? Can some body point me how to set this up ?
>
> Usually, DMA data transferring could perform directly on fysc memory address. You may not need bounce buffer or scatter/gather operations if you can config all your memory to ZONE_NORMAL. ZONE_DMA is not necessary because this area is only required by kmalloc call with GFP_DMA flags.
> Best regards,
> /Adam
>
>>
>> Thanks & Regards,
>> Ramgopal Kota
>>
>>
>
> --
> Adam Jiang
> -----------------------------------
> e-mail:jiang.adam@gmail.com
> http://www.adamjiang.com
> -----------------------------------



--
Adam Jiang
-----------------------------------
e-mail:jiang.adam@gmail.com
http://www.adamjiang.com
-----------------------------------

Re: MIPS raw_local_irq_restore flags

[Ralf Baechle]

On Tue, Mar 16, 2010 at 10:27:24PM -0700, Ramgopal Kota wrote:

> Is there any moderation done to the messages posted to this mailing list. I posted couple of messages but none has come , just wondering what is wrong ? 

There is no general moderation for any of the lists on linux-mips but your
postings were false positives of the spamfilter and as such ended up in the
moderator queue (which I religiously ignore due to volume and it being
beyond 99% spam) anyway.  This was not the first time this happened so I've
disabled the tests.

And as a general rant, if you want to post some new topic to the list then
don't reply to another posting.  That totally screws mail threading so
start a new mail thread please.

  Ralf

Re: HIGHMEM not working.

[Adam Jiang]

Hi, Ramgopal

2010/3/17 Ramgopal Kota <rkota@broadcom.com>:
> The first 128MB of 0x8000_0000 is mapped to 0x0000_0000 address, hence I added them as 2 nodes with 0 & 0x8800_0000 ..
> max_zone_pfns[ZONE_NORMAL] should be assigned with maximum physical address of the memory i.e. address >> page_size ...
> As the physical address is 0x07FF_FFFF .. The ZONE_NORMAL PFN should be 0x07FFF ..
> As ZONE_HIGH max address is 0x8FFF_FFFF .. The ZONE_HIGH PFN should be 0x8FFFF .. Why do you think this is wrong ?

I get confusing with your memory mapping... What do you mean ZONE_HIGH
max address is 0x8fff ffff? Could you please clarify your memory
layout within physical address instead of mixed mapped virtual
address? And, what's the virtual addresses you planed to map them?

> I did not get how I can handle with out ZONE_HIGH ?? Can you explain me in more detail please ..

You are using a MIPS64 core, aren't you? If Linux kernel could only
access the virtual memory address lower than PAGE_OFFSET, you don't
need to define a ZONE_HIGH because you have only 128M + 128M memory <
(PAGE_OFFSET) on your target. You don't need map those memory because
you can access all your memory directly, I think.

If you have a 32-bit PCI controller on you board, you may need bounce
buffers because you CPU just has 64-bit address. I missed the most
important information you have provided. You can find out some sample
code on ARM at the following URL:

http://lxr.linux.no/linux+v2.6.33/arch/arm/common/dmabounce.c#L5

there're common routines you can try to port it to MIPS if you need them.

Regards,
/Adam

>
> Thanks & Regards,
> Ramgopal Kota
>
> -----Original Message-----
> From: Adam Jiang [mailto:jiang.adam@gmail.com]
> Sent: Wednesday, March 17, 2010 5:00 PM
> To: linux-mips@linux-mips.org
> Cc: Ramgopal Kota
> Subject: Re: HIGHMEM not working.
>
> 2010/3/17 Ramgopal Kota <rkota@broadcom.com>
>>
>> Adam,
>>
>> Thanks for the response ...
>>
>> We enabled CONFIG_SPARSEMEM in place of CONFIG_DISCONTIGMEM .. It is specified that SPARSEMEM will eventually replaces DISCONTIGMEM
>> (http://marc.info/?l=lhms-devel&m=111451976115580&w=2)
>
> Yes. It seems a better way to do this.
>
>> We have configured zones as below in paging_init function ..
>> max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
>> max_zone_pfns[ZONE_NORMAL] = max_low_pfn;   <<  0x20000
>> max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;  <<  0x8FFFF
>> We added 2 memory regions as below ..
>> add_memory_region(0x00000000, 128MB, BOOT_MEM_RAM);
>> add_memory_region(0x88000000  ,128MB, BOOT_MEM_RAM);
>> Is this what you are refering as 2 memory nodes ??
>>
>
> OK. Physical memory is managed in nodes and zones. Because you have
> mentioned that there would be 2 ranges of memory on your architecture
> like
>
> Node 0   [0x0000 0000, 0x0800 0000]
> Node 1   [0x8000 0000, 0xcfff ffff]
>
> I guess you can define these two nodes by add_memory_region function
> but I am not sure... However, the start_addr of the second node would
> be 0x8000 0000 rather than 0x8800 0000. On the other hand, I think the
> following code is not correct
>
>> max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
>> max_zone_pfns[ZONE_NORMAL] = max_low_pfn;   <<  0x20000
>> max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;  <<  0x8FFFF
>
> if max_low_pfn is 0x20000, then your ZONE_NORMAL will end up at 0x2000
> 0000(PFN x PAGE_SIZE); but according to the information about physical
> memory address you provided. 0x0800 0000 ~ 0x0fff ffff is used as PCI
> device addresses. Em~, the highend_pfn is not correct either. Please
> double check these address.
>
> Bounce buffers are required for devices that cannnot access the full
> range of memory available to the CPU, such as old ISA cards with only
> 24bit address. Is this the situation you have to face? If it is needed
> you may look into function create_bounce_buffer() in the other drivers
> for details, however, I still think you would not need it. By the way,
> high memory just mapped to low memory by kmap() function. You don't
> need to define a ZONE_HIGH in your configuration. Because 0x8000_0000
> ~ 0x8fff ffff is kseg0 on MIPS. You can handle them as ZONE_NORMAL in
> much easier way.
>
> Best regards,
> /Adam
>
>>
>> What is the significance of MAX_PHYSMEM_BITS  & SECTION_SIZE_BITS .. Sorry for troubling with novoice questions ..
>>
>> Thanks & Regards,
>> Ramgopal Kota
>> ________________________________
>> From: Adam Jiang [mailto:jiang.adam@gmail.com]
>> Sent: Wednesday, March 17, 2010 12:36 PM
>> To: Ramgopal Kota
>> Subject: Re: HIGHMEM not working.
>>
>> 2010/3/17 Ramgopal Kota <rkota@broadcom.com>
>>>
>>>  Hi,
>>>
>>> I need help in running CPU with HIGH_MEM.
>>> Below is the processor memory map .. It is base on MIPS64K Core.
>>>
>>> 0x0000_0000  -- 0x07FF_FFFF   -> RAM (Region 1)
>>> 0x0800_0000  -- 0x0FFF_FFFF   -> PCI BUS 1
>>> 0x2000_0000  -- 0x2FFF_FFFF   -> Flash Region
>>> 0x4000_0000  -- 0x47FF_FFFF   -> PCI BUS 2
>>> 0x8000_0000  -- 0xCFFF_FFFF   -> RAM (Region 2) the first 128MB is remapped into 0x8000_0000 ..
>>>
>>> The system has 256MB of PHYSICAL RAM ..
>>>
>>> I configured TLB's and added memory regions. The system boots up correctly ..
>>> If I show cat /proc/meminfo it shows 256MB , it could allocate memory ( I verified with a simple program allocating the memory and writing some data)
>>>
>>> There is a PCI MAC device on PCI BUS 2. The CPU is not able to perform DMA to/from device.
>>> The MAC driver is allocating DMA buffers using the following code ..
>>> {
>>>    phy = virt_to_bus(high_memory);  << Resulting in 0xa000_0000;
>>>    virt = ioremap(pbase);
>>> }
>>> The Linux configuration has no ZONE_DMA configuration ..
>>>
>>>
>>> Few questions ..
>>>  A) HIGH_MEMORY START Address is configured to 0x2000_0000 , is it correct value.
>>
>> I don't think 0x2000_0000 is a correct value for HIGH_MEM in general meaning. The value depends on which architecture you're working on. And its start address could be initialed in
>> LNX/arch/(arch)/kernel/setup.c
>> LNX/arch/(arch)/mm/init.c
>> in your case, I thing you can use all your memory as ZONE_NORMAL or ZONE_DMA but not ZONE_HIGH.
>>
>>>
>>>  B) Are there any data which can be dumped to know more information ?
>>
>> Yes, of course. You could try to add some printk in the above two files in bootmem_init() function or function free_area_init_core() to see what's the memory layout exactly.
>>
>>>
>>>  C) Do I need to enable MEMORY Discontinuous Config also ?  ( As I did not see a reason to enable this as memory in Region 2 is contiguous)
>>
>> Since you have two separated range fsyc memory on you board, I think you do really need CONFIG_DISCONTIGMEM_*; You may also need to define two memory nodes in bootmem.
>>
>>>
>>>  D) I read in some articles on internet that if HIGH_MEM is used,PCI bounce buffers needs to be used ? Can some body point me how to set this up ?
>>
>> Usually, DMA data transferring could perform directly on fysc memory address. You may not need bounce buffer or scatter/gather operations if you can config all your memory to ZONE_NORMAL. ZONE_DMA is not necessary because this area is only required by kmalloc call with GFP_DMA flags.
>> Best regards,
>> /Adam
>>
>>>
>>> Thanks & Regards,
>>> Ramgopal Kota
>>>
>>>
>>
>> --
>> Adam Jiang
>> -----------------------------------
>> e-mail:jiang.adam@gmail.com
>> http://www.adamjiang.com
>> -----------------------------------
>
>
>
> --
> Adam Jiang
> -----------------------------------
> e-mail:jiang.adam@gmail.com
> http://www.adamjiang.com
> -----------------------------------
>
>
>



-- 
Adam Jiang
-----------------------------------
e-mail:jiang.adam@gmail.com
http://www.adamjiang.com
-----------------------------------