Hi all,
So, lets see if i have all this right.
IO space needs to stay where it is, somewhere in the top 1GB, because
it is limited to the 32bit address space.
We must have some SDRAM in the bottom of the 40bit address range in
order that DMA works. Bounce buffers are used for anything which is
On Thursday 21 March 2013, Lior Amsalem wrote:
From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
Sent: Thursday, March 21, 2013 11:46 PM
On Thu, Mar 21, 2013 at 11:35:21PM +0200, Lior Amsalem wrote:
*) It would require Linux to change the internal registers address
On Thursday 21 March 2013, Jason Gunthorpe wrote:
On Thu, Mar 21, 2013 at 10:15:23PM +0100, Thomas Petazzoni wrote:
Dear Jason Gunthorpe,
*) It only works when LPAE is enabled, so we would have to have
different internal register addresses depending on whether LPAE is
enabled
On Fri, Mar 22, 2013 at 07:28:54AM +0100, Andrew Lunn wrote:
IO space needs to stay where it is, somewhere in the top 1GB, because
it is limited to the 32bit address space.
Yes
We must have some SDRAM in the bottom of the 40bit address range in
order that DMA works. Bounce buffers are used
On Friday 22 March 2013, Jason Gunthorpe wrote:
At a certain point low mem exhaustion becomes a serious issue for
Linux, a system that can't DMA to 85% of its memory is incredibly
broken, IMHO.
A lot of workloads will also suffer from lowmem exhaustion even without
the DMA zone problem. If
In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.
Armada XP and Armada 370 share a dtsi file which have also be
converted to 64 bits. This lead to convert all the device tree files
to 64 bits even the one used for Armada 370 (which
On 03/21/2013 11:26 AM, Gregory CLEMENT wrote:
In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.
Armada XP and Armada 370 share a dtsi file which have also be
converted to 64 bits. This lead to convert all the device tree files
On Thursday 21 March 2013, Rob Herring wrote:
soc {
- #address-cells = 1;
- #size-cells = 1;
+ #address-cells = 2;
+ #size-cells = 2;
If all the addresses for the soc bus are below 4GB or even within a 4GB
range if using the
Dear Arnd Bergmann,
On Thu, 21 Mar 2013 19:03:52 +, Arnd Bergmann wrote:
On Thursday 21 March 2013, Rob Herring wrote:
soc {
- #address-cells = 1;
- #size-cells = 1;
+ #address-cells = 2;
+ #size-cells = 2;
If all the
/*
- * 4 GB of plug-in RAM modules by default but only 3GB
- * are visible, the amount of memory available can be
- * changed by the bootloader according the size of the
- * module actually plugged
+ * 8 GB of
Dear Andrew Lunn,
On Thu, 21 Mar 2013 21:15:33 +0100, Andrew Lunn wrote:
Could you recommend a document which introduces LPAE.
Only being able to address 7GB seems a bit odd to me. I kind of
expected you set up the translation tables to map a page in the 32 bit
address range to any
On Thu, Mar 21, 2013 at 09:22:36PM +0100, Thomas Petazzoni wrote:
Dear Andrew Lunn,
On Thu, 21 Mar 2013 21:15:33 +0100, Andrew Lunn wrote:
Could you recommend a document which introduces LPAE.
Only being able to address 7GB seems a bit odd to me. I kind of
expected you set up the
On Thu, Mar 21, 2013 at 09:22:36PM +0100, Thomas Petazzoni wrote:
Dear Andrew Lunn,
On Thu, 21 Mar 2013 21:15:33 +0100, Andrew Lunn wrote:
Could you recommend a document which introduces LPAE.
Only being able to address 7GB seems a bit odd to me. I kind of
expected you set up the
Dear Andrew Lunn,
On Thu, 21 Mar 2013 21:37:51 +0100, Andrew Lunn wrote:
And I'm not sure the SDRAM address decoding windows allows to split the
first 4 GB of RAM into two areas, one that would be mapped starting at
physical address 0x0, and another area that would be mapped at a
Dear Jason Gunthorpe,
On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote:
Or, better, locate all the internal registers above 8G and use
contiguous DRAM mapping from 0 - 8GB
I see two potential issues with this idea:
*) It only works when LPAE is enabled, so we would have to have
Dear Andrew Lunn,
On Thu, 21 Mar 2013 21:37:51 +0100, Andrew Lunn wrote:
And I'm not sure the SDRAM address decoding windows allows to split the
first 4 GB of RAM into two areas, one that would be mapped starting at
physical address 0x0, and another area that would be mapped at a
Or, better, locate all the internal registers above 8G and use
contiguous DRAM mapping from 0 - 8GB
Wouldn't that get us into a 640KBs is enough for everyone situation?
Why not put the IO at the very top of the 1TB address range?
Andrew
___
On Thu, Mar 21, 2013 at 10:15:23PM +0100, Thomas Petazzoni wrote:
Dear Jason Gunthorpe,
On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote:
Or, better, locate all the internal registers above 8G and use
contiguous DRAM mapping from 0 - 8GB
I see two potential issues with this
Hi Thomas, Jason,
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
Sent: Thursday, March 21, 2013 11:15 PM
Dear Jason Gunthorpe,
On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote:
Or, better, locate all the internal registers above 8G and use
contiguous
On Thu, Mar 21, 2013 at 11:35:21PM +0200, Lior Amsalem wrote:
*) It would require Linux to change the internal registers address
(for now the kernel relies on the bootloader). The problem is that
we can't do it early enough to preserve the earlyprintk
functionality. Maybe you
From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
Sent: Thursday, March 21, 2013 11:46 PM
On Thu, Mar 21, 2013 at 11:35:21PM +0200, Lior Amsalem wrote:
*) It would require Linux to change the internal registers address
(for now the kernel relies on the bootloader).
On 03/21/2013 10:41 PM, Jason Gunthorpe wrote:
On Thu, Mar 21, 2013 at 10:15:23PM +0100, Thomas Petazzoni wrote:
Dear Jason Gunthorpe,
On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote:
Or, better, locate all the internal registers above 8G and use
contiguous DRAM mapping from 0 -
22 matches
Mail list logo
