From: "Vladislav D. Buzov" <vbuzov@ru.mvista.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
Date: Fri, 15 Jun 2007 12:55:45 +0400 [thread overview]
Message-ID: <46725411.3080002@ru.mvista.com> (raw)
In-Reply-To: <c6cd3a9fe7713f081354cca9b4306811@kernel.crashing.org>
Segher Boessenkool wrote:
>>>>> /* TODO: use HW flush assist when available */
>>>>
>>>> You want to get rid of this old comment though -- and
>>>> perhaps branch over the non-hardware-assisted cache
>>>> flushing code.
>>>
>>> Ok, I agree that the comment is obsolete now. Would you please explain
>>> why the branch over non-hardware-assisted code should be removed as
>>> well. Technically the cache is flushed and there is no need to use
>>> extra
>>> commands to fill and then re-flush the cache.
>>
>> I think Segher is saying that you can skip the manual invalidation too
>> (although he said "flushing", I think he really meant "invalidation"--
>> the manual flushing is already skipped).
>
> Erm yes.
>
>> If I'm reading the manual
>> correctly, L2HWF does the invalidation as well so both the manual
>> flushing and invalidation can be skipped.
>
> Yeah. Not that it really matters of course.
Hrm. I don't think that cache invalidation should be skipped. It is done
after _set_L2CR() explicitly disabled the cache, in part of cache
enabling procedure. Note that cache is flushed only if _set_L2CR() is
called for already enabled cache. So, to skip cache invalidation there
is a need to somehow track whether the cache has been
flushed/invalidated before disabling or not. Since the manual
invalidation does not break anything I think it is better to leave it as
is rather than overload a _set_L2CR() logic.
Vlad.
>
>
> Segher
>
next prev parent reply other threads:[~2007-06-15 8:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-13 10:19 [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization Vladislav Buzov
2007-06-14 13:56 ` Segher Boessenkool
2007-06-14 17:12 ` Vladislav Buzov
2007-06-14 22:26 ` Mark A. Greer
2007-06-15 8:16 ` Segher Boessenkool
2007-06-15 8:55 ` Vladislav D. Buzov [this message]
2007-06-15 9:01 ` Segher Boessenkool
2007-06-15 9:33 ` Vladislav D. Buzov
2007-06-15 10:44 ` Segher Boessenkool
2007-06-15 8:14 ` Segher Boessenkool
2007-06-15 8:42 ` Vladislav D. Buzov
2007-06-15 8:56 ` Segher Boessenkool
2007-06-15 21:20 ` Mark A. Greer
2007-06-15 22:14 ` Segher Boessenkool
2007-06-21 12:37 ` Benjamin Herrenschmidt
2007-06-22 15:22 ` Vladislav Buzov
2007-06-23 15:46 ` Segher Boessenkool
2007-06-25 14:09 ` Vladislav Buzov
2007-06-28 8:24 ` Segher Boessenkool
2007-06-28 9:13 ` Benjamin Herrenschmidt
2007-06-28 10:47 ` Vladislav Buzov
2007-06-28 11:09 ` Benjamin Herrenschmidt
2007-06-25 19:00 ` Vladislav Buzov
2007-06-28 8:35 ` Segher Boessenkool
2007-06-29 10:41 ` Vladislav Buzov
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=46725411.3080002@ru.mvista.com \
--to=vbuzov@ru.mvista.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=segher@kernel.crashing.org \
/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.