public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] DCR register read/write for PPC440EP
Date: Thu, 28 Sep 2006 20:44:51 +0200	[thread overview]
Message-ID: <200609282044.52630.sr@denx.de> (raw)
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C043814@ehost011-3.exch011.intermedia.net>

Hi Leonid,

On Thursday 28 September 2006 18:58, Leonid wrote:
> > What you really need, is an U-Boot command to set/get SDR registers,
> > indirectly accessed via the DCR 0x0e/0x0f registers. Something
> > like "setsdr/getsdr".
>
> [Leonid] I thought rather of some generic function, allowing indirect
> access to DCR-related registers since 0xE/0xF is not only combination of
> address/data - for EBC they use 0x12/0x13 for instance. To that end, GET
> command must receive 3 "address" arguments - DCR address register, DCR
> data register and offset while SET will also need a value. Please advice
> on command's name. Something like that I guess:
>
> getidcr e f 0x40
> setidcr e f 40 0xbadd
>
> where "i" in the middle stays for "indirect". What do you think?

Good idea. Much more flexible this way. I'm just thinking, if we really need 
this 2nd argument for the "DCR data register", since all "DCR data registers" 
I found upon a quick look into on of the AMCC manuals, are located at "DCR 
address register + 1". This way we would save one parameter, but would loose 
some flexibility. Best would be, if you made the 2nd paramter optional:

getidcr e [f] 0x40
setidcr e [f] 40 0xbadd

This way, you could decide upon the parameter count (argc), if the "DCR data 
register" is supplied or not. What do you think?

> Now regarding implementation. Simplest way is to call
> set_dcr()/get_dcr() from C code but that actually doesn't ensure that
> the register under consideration was not overwritten in between. I can
> disable interrupts, do you think it's OK? This is debug monitor function
> after all, nobody cares regarding performance here...

Yes, you should definitely disable the interrupts in this function.

> > It would be best, if you could supply a proper patch
> > with such additional commands.
>
> [Leonid] It will be quite a honor for me to serve this community. Can
> you refer me to proper link how I do proceed with patch submission:
> review, help information, actual sources delivering, etc...

This is explained at the end of the README under "Submitting Patches:". And 
please also take a look at "Coding Standards:".

Thanks.

Best regards,
Stefan

  reply	other threads:[~2006-09-28 18:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-27 16:06 [U-Boot-Users] DCR register read/write for PPC440EP Leonid
2006-09-28 12:54 ` Stefan Roese
2006-09-28 16:58   ` Leonid
2006-09-28 18:44     ` Stefan Roese [this message]
2006-09-28 21:54       ` Leonid
2006-09-30  2:13         ` Stefan Roese

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=200609282044.52630.sr@denx.de \
    --to=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox