All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kumar Gala <kumar.gala@motorola.com>
To: Eugene Surovegin <ebs@ebshome.net>
Cc: <linuxppc-embedded@lists.linuxppc.org>,
	Stephen Williams <612dlag102@sneakemail.com>
Subject: Re: [RFC] "indirect" DCR access (40x, BookE)
Date: Fri, 12 Mar 2004 08:25:23 -0600	[thread overview]
Message-ID: <1921A482-7431-11D8-AFB6-000393DBC2E8@motorola.com> (raw)
In-Reply-To: <20040312045451.GA25876@gate.ebshome.net>


Look in u-boot.  They have some user commands that allow
reading/writing dcr's.  These commands are written with self modifying
code, I would recommend that we reuse that.

Also, it begs the question of should this be extended to SPRs, not that
I have come across a case with SPRs that I need to iterate over a large
list.

- kumar

On Mar 11, 2004, at 10:54 PM, Eugene Surovegin wrote:

>
> On Thu, Mar 11, 2004 at 08:44:09PM -0800, Stephen Williams wrote:
>>>> I think you should just write it as self modifying code :-)
>>>> Write the instruction with the DCR number and just execute it.
>>>
>>>
>>> And deal with locking and icache/dcache coherency ?
>>>
>>> No, thanks :)
>>
>>
>> Actually, I recall that there is a code fixup mechanism that
>> is invoked early in kernel init that does exactly that: it
>> manages some machine specific differences by editing the code
>> in place in a safe way.
>
> Yes, you are correct, but this is done only once during startup and
> nobody cares how fast it is. BTW, there is no locking issues at this
> stage.
>
> I'm not saying that it's impossible :). It's just not very efficient
> to do such stuff on run-time (lock a spinlock, change memory, dcache
> flush, icache invalidate, isync...)
>
> Eugene.
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2004-03-12 14:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-12  1:48 [RFC] "indirect" DCR access (40x, BookE) Eugene Surovegin
2004-03-12  2:46 ` Dan Malek
2004-03-12  3:05   ` Eugene Surovegin
2004-03-12  4:44     ` Stephen Williams
2004-03-12  4:54       ` Eugene Surovegin
2004-03-12 14:25         ` Kumar Gala [this message]
2004-03-12 14:53           ` Chuck Meade
2004-03-12 16:20           ` Eugene Surovegin
2004-03-12 18:01           ` Dan Malek
2004-03-19  4:00           ` Benjamin Herrenschmidt
2004-03-23  2:47             ` Eugene Surovegin
2004-04-01  5:36               ` Kumar Gala

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=1921A482-7431-11D8-AFB6-000393DBC2E8@motorola.com \
    --to=kumar.gala@motorola.com \
    --cc=612dlag102@sneakemail.com \
    --cc=ebs@ebshome.net \
    --cc=linuxppc-embedded@lists.linuxppc.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.