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 c
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 u
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
> >
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 register
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
o
On 03/21/2013 10:31 PM, Arnd Bergmann wrote:
On Thursday 21 March 2013, Thomas Petazzoni wrote:
In the mean time can we do something like:
soc {
compatible = "simple-bus";
range =<...>;
[... all the peripherals ...]
};
with
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 -> 8
> 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 bootl
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. Ma
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
> > con
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 w
On Thursday 21 March 2013, Thomas Petazzoni wrote:
> In the mean time can we do something like:
>
> soc {
> compatible = "simple-bus";
> range = <...>;
>
> [... all the peripherals ...]
> };
>
> with the range = <...> property conve
> 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
___
dev
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
> >
On Thu, Mar 21, 2013 at 09:22:36PM +0100, Thomas Petazzoni 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
> different addres
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 se
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 se
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 arb
> /*
> - * 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 o
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
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
> rang
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 fi
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 do
25 matches
Mail list logo
