[Top] [All Lists]

RE: [SPAM] linux- Porting OOPS

To: "David VomLehn" <>
Subject: RE: [SPAM] linux- Porting OOPS
From: "Pelton, Dave" <>
Date: Mon, 16 Jun 2008 11:52:08 -0400
Cc: "J.Ma" <>, "Markus Gothe" <>, <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <>
Thread-index: AcjNrfqBQoKFHNPtTUG9QUci5nASxgCFmUfA
Thread-topic: [SPAM] linux- Porting OOPS
David VomLehn wrote:
> Pelton, Dave wrote:
> > <snip>
> > Normally kseg2 is in the address range 0xC0000000-0xFFFFFFFF.
> > on the BMIPS3300 (the embedded MIPS32 core used on my SOC), there is
> > range of addresses within kseg2 that are reserved
> > (0xFF200000-0xFFFEFFFF).
> > This means that the TLB entry that kmap_coherent creates will not
> > if it falls within the reserved range.  The virtual address space
> > by kmap_coherent is controlled by FIXADDR_TOP in
> > include/asm-mips/fixmap.h.
> > To fix my issue, I changed FIXADDR_TOP to avoid the reserved address
> > space.
> <snip>
> Is your range of addresses reserved on the BMIPS3300 because it is
being used as
> dseg, i.e. because it is being used for debugging? If I read the
documentation on
> the processor I am using, the 24Kc, it has a similar issue. I don't
need to be
> able to use kmap_coherent because the 24K hardware takes care of data
> issues, i.e. cpu_has_dc_aliases is false, but I'm sort of thinking we
might just
> generally want to change FIXADDR_TOP to avoid address in the dseg
range for all
> MIPS32 processors. As we work our way through some of the cache
flushing issues
> related to using high memory, I'd like to be able to develop code that
works on
> processors for which cpu_has_dc_aliases is true. If my kmap_coherent
is working I
> can check things out for those processors and then simply use
kmap_atomic for
> processors where cpu_has_dc_aliases is false.

Apologies in advance for what my plain-text impaired mail client is
likely to do to this message.  The reserved range on the BMIPS3300 is
used by memory mapped registers.  I am not a memory management expert,
so I am not sure what implications there would be to moving FIXADDR_TOP
as a general fix.  The impression I have from general MIPS documentation
is that kseg2 should not be used for memory mapped i/o and hence
platforms that do this should be treated as an exception case, rather
than moving the general case to deal with this.

- David Pelton

<Prev in Thread] Current Thread [Next in Thread>