On Thursday 27 June 2013, Leif Lindholm wrote:
> On Thu, Jun 27, 2013 at 10:47:21AM +0200, Arnd Bergmann wrote:
> > > No, the purpose is just like for x86 - do early parsing of things like
> > > the UEFI system and configuration tables, DMI and ACPI, in order to
> > > populate global structs and
On Thu, Jun 27, 2013 at 10:47:21AM +0200, Arnd Bergmann wrote:
> > No, the purpose is just like for x86 - do early parsing of things like
> > the UEFI system and configuration tables, DMI and ACPI, in order to
> > populate global structs and stuff.
>
> But are those tables actually in MMIO
On Thursday 27 June 2013 01:25:06 Leif Lindholm wrote:
> On Thu, Jun 27, 2013 at 12:13:55AM +0200, Arnd Bergmann wrote:
> > > Sorry, I still don't get it. Are you saying that kmap_atomic is
> > > available before kmap_init() (in paging_init())?
> > >
> > > If not, all of my mappings are discarded
On Thursday 27 June 2013 01:25:06 Leif Lindholm wrote:
On Thu, Jun 27, 2013 at 12:13:55AM +0200, Arnd Bergmann wrote:
Sorry, I still don't get it. Are you saying that kmap_atomic is
available before kmap_init() (in paging_init())?
If not, all of my mappings are discarded (well,
On Thu, Jun 27, 2013 at 10:47:21AM +0200, Arnd Bergmann wrote:
No, the purpose is just like for x86 - do early parsing of things like
the UEFI system and configuration tables, DMI and ACPI, in order to
populate global structs and stuff.
But are those tables actually in MMIO registers? I
On Thursday 27 June 2013, Leif Lindholm wrote:
On Thu, Jun 27, 2013 at 10:47:21AM +0200, Arnd Bergmann wrote:
No, the purpose is just like for x86 - do early parsing of things like
the UEFI system and configuration tables, DMI and ACPI, in order to
populate global structs and stuff.
On Thu, Jun 27, 2013 at 12:13:55AM +0200, Arnd Bergmann wrote:
> > Sorry, I still don't get it. Are you saying that kmap_atomic is
> > available before kmap_init() (in paging_init())?
> >
> > If not, all of my mappings are discarded (well, abandoned to be more
> > correct), so I don't see how it
On Wednesday 26 June 2013, Leif Lindholm wrote:
> On Wed, Jun 26, 2013 at 11:23:50PM +0200, Arnd Bergmann wrote:
> > > Is this an issue here, since (unlike x86) this early_ioremap only works
> > > before paging_init()?
> >
> > The main problem is that the total fixmap size is only around 900kb,
>
On Wed, Jun 26, 2013 at 11:23:50PM +0200, Arnd Bergmann wrote:
> > Is this an issue here, since (unlike x86) this early_ioremap only works
> > before paging_init()?
>
> The main problem is that the total fixmap size is only around 900kb,
> and we want to reserve at least 64kb per cpu for
On Wednesday 26 June 2013, Leif Lindholm wrote:
> On Wed, Jun 26, 2013 at 08:52:09PM +0200, Arnd Bergmann wrote:
> > I made a similar suggestion to extending the use of fixmap recently, see
> > "Re: SCU registers mapping for CA9/CA5 cores". Russell pointed out that
> > fixmap is intentionally
On Wed, Jun 26, 2013 at 08:52:09PM +0200, Arnd Bergmann wrote:
> I made a similar suggestion to extending the use of fixmap recently, see
> "Re: SCU registers mapping for CA9/CA5 cores". Russell pointed out that
> fixmap is intentionally limited to just kmap_atomic uses at the moment
> and
On Tuesday 25 June 2013, Leif Lindholm wrote:
> x86 and ia64 have the early_ioremap()/early_iounmap() functions, which are
> useful for supporting things like UEFI, ACPI and SMBIOS, where configuration
> tables need to be parsed before proper memory management is available,
> regardless of highmem
On Tuesday 25 June 2013, Leif Lindholm wrote:
x86 and ia64 have the early_ioremap()/early_iounmap() functions, which are
useful for supporting things like UEFI, ACPI and SMBIOS, where configuration
tables need to be parsed before proper memory management is available,
regardless of highmem
On Wed, Jun 26, 2013 at 08:52:09PM +0200, Arnd Bergmann wrote:
I made a similar suggestion to extending the use of fixmap recently, see
Re: SCU registers mapping for CA9/CA5 cores. Russell pointed out that
fixmap is intentionally limited to just kmap_atomic uses at the moment
and changing that
On Wednesday 26 June 2013, Leif Lindholm wrote:
On Wed, Jun 26, 2013 at 08:52:09PM +0200, Arnd Bergmann wrote:
I made a similar suggestion to extending the use of fixmap recently, see
Re: SCU registers mapping for CA9/CA5 cores. Russell pointed out that
fixmap is intentionally limited to
On Wed, Jun 26, 2013 at 11:23:50PM +0200, Arnd Bergmann wrote:
Is this an issue here, since (unlike x86) this early_ioremap only works
before paging_init()?
The main problem is that the total fixmap size is only around 900kb,
and we want to reserve at least 64kb per cpu for kmap_atomic.
On Wednesday 26 June 2013, Leif Lindholm wrote:
On Wed, Jun 26, 2013 at 11:23:50PM +0200, Arnd Bergmann wrote:
Is this an issue here, since (unlike x86) this early_ioremap only works
before paging_init()?
The main problem is that the total fixmap size is only around 900kb,
and we
On Thu, Jun 27, 2013 at 12:13:55AM +0200, Arnd Bergmann wrote:
Sorry, I still don't get it. Are you saying that kmap_atomic is
available before kmap_init() (in paging_init())?
If not, all of my mappings are discarded (well, abandoned to be more
correct), so I don't see how it affects
x86 and ia64 have the early_ioremap()/early_iounmap() functions, which are
useful for supporting things like UEFI, ACPI and SMBIOS, where configuration
tables need to be parsed before proper memory management is available,
regardless of highmem status.
This patchset implements a restricted form
x86 and ia64 have the early_ioremap()/early_iounmap() functions, which are
useful for supporting things like UEFI, ACPI and SMBIOS, where configuration
tables need to be parsed before proper memory management is available,
regardless of highmem status.
This patchset implements a restricted form
20 matches
Mail list logo
