All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Hogan <james.hogan@mips.com>
To: Yuri Frolov <crashing.kernel@gmail.com>
Cc: <linux-mips@linux-mips.org>, <paul.burton@mips.com>
Subject: Re: [P5600 && EVA memory caching question] PCI region
Date: Fri, 22 Dec 2017 11:49:39 +0000	[thread overview]
Message-ID: <20171222114938.GJ5027@jhogan-linux.mipstec.com> (raw)
In-Reply-To: <d4198e82-5658-1bce-8415-cfc9dee56336@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

On Fri, Dec 22, 2017 at 02:18:26PM +0300, Yuri Frolov wrote:
> Sorry, I forgot to ask,
> > yes, the Malta implementation is slightly ugly as it relies on a
> > hardware physical memory alias of RAM starting at PA 0x80000000.
> any good docs about this hardware aliasing? I'm not sure I understand it 
> correctly, just want to understand things right.

Basically it keeps kseg0 (seg3) and kseg1 (seg2) pointing at PA 0, which
it runs kernel code from (i.e. same place it is loaded, without the EVA
layout enabled yet), but then it does data accesses from seg4 and seg5
which point at PA 0x80000000. I think the intention is to allow the VA
to PA offset to be the same for all cached segments.

However because the caches don't know that different physical addresses
refer to the same underlying RAM they aren't coherent with one another
and the kernel has to be careful not to use both, and to flush the
caches during boot.

Its not an approach I would personally recommend, and if we get EVA
support added to the generic platform I'd hope it would be a lot
cleaner, perhaps using the since added kernel self-relocation.

Cheers
James


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: James Hogan <james.hogan@mips.com>
To: Yuri Frolov <crashing.kernel@gmail.com>
Cc: linux-mips@linux-mips.org, paul.burton@mips.com
Subject: Re: [P5600 && EVA memory caching question] PCI region
Date: Fri, 22 Dec 2017 11:49:39 +0000	[thread overview]
Message-ID: <20171222114938.GJ5027@jhogan-linux.mipstec.com> (raw)
Message-ID: <20171222114939.p-lIC5s1vqHRisTGJ54m8A66mdKhtSpllXB5F3KACxM@z> (raw)
In-Reply-To: <d4198e82-5658-1bce-8415-cfc9dee56336@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

On Fri, Dec 22, 2017 at 02:18:26PM +0300, Yuri Frolov wrote:
> Sorry, I forgot to ask,
> > yes, the Malta implementation is slightly ugly as it relies on a
> > hardware physical memory alias of RAM starting at PA 0x80000000.
> any good docs about this hardware aliasing? I'm not sure I understand it 
> correctly, just want to understand things right.

Basically it keeps kseg0 (seg3) and kseg1 (seg2) pointing at PA 0, which
it runs kernel code from (i.e. same place it is loaded, without the EVA
layout enabled yet), but then it does data accesses from seg4 and seg5
which point at PA 0x80000000. I think the intention is to allow the VA
to PA offset to be the same for all cached segments.

However because the caches don't know that different physical addresses
refer to the same underlying RAM they aren't coherent with one another
and the kernel has to be careful not to use both, and to flush the
caches during boot.

Its not an approach I would personally recommend, and if we get EVA
support added to the generic platform I'd hope it would be a lot
cleaner, perhaps using the since added kernel self-relocation.

Cheers
James


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-12-22 11:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-06 10:36 [P5600 && EVA memory caching question] PCI region Yuri Frolov
2017-12-06 11:46 ` James Hogan
2017-12-06 11:46   ` James Hogan
2017-12-14 15:03   ` Yuri Frolov
2017-12-14 15:21     ` James Hogan
2017-12-14 15:21       ` James Hogan
2017-12-15 14:05       ` Yuri Frolov
2017-12-15 23:28         ` James Hogan
2017-12-15 23:28           ` James Hogan
2017-12-20 15:11           ` Yuri Frolov
2017-12-21 12:40             ` Yuri Frolov
2017-12-21 12:40               ` Yuri Frolov
2017-12-21 13:41             ` James Hogan
2017-12-21 13:41               ` James Hogan
2017-12-22  9:37               ` Yuri Frolov
2017-12-22 11:18               ` Yuri Frolov
2017-12-22 11:49                 ` James Hogan [this message]
2017-12-22 11:49                   ` James Hogan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171222114938.GJ5027@jhogan-linux.mipstec.com \
    --to=james.hogan@mips.com \
    --cc=crashing.kernel@gmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=paul.burton@mips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.