All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Bordug <vbordug@ru.mvista.com>
To: Kalle Pokki <kalle.pokki@iki.fi>
Cc: Paul, linuxppc-embedded@ozlabs.org, Mackerras <paulus@samba.org>
Subject: Re: [PATCH] CPM_UART: Fixed SMC handling for CPM2 processors
Date: Tue, 7 Nov 2006 17:47:41 +0300	[thread overview]
Message-ID: <20061107174741.3d837e19@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0611071451130.3291@host32.eke.fi>

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

On Tue, 7 Nov 2006 15:21:00 +0200 (EET)
Kalle Pokki wrote:

> On Tue, 7 Nov 2006, Vitaly Bordug wrote:
> 
> > Well, yes, but are you _sure_ pram_base will be the same across all
> > the 82xx PQ2, that happen to have smc wired to Ethernet?
> >
> > If not I am considering storing it in the platform_data is better
> > approach.
> 
> Yes, pram_base is always 0x87fc for SMC1 and 0x88fc for SMC2. This is
> for all PowerQUICC II families (8260, 8272, and 8280). I'm not sure
> how PQ2 Pro and PQ3 and handled, but I suspect they don't share these 
> definitions.
> 
ok
> Anyway, I'm only extending the already existing conventions to the 
> platform device approach. These same decisions have already been made
> in the past and are used in the cpm_uart compat mode. It may be that 
> Freescale someday releases a microcode patch that relocates the SMC 
> parameter RAM, but even in this case it would be better to use the
> same approach with compat mode and platform device mode to avoid
> confusion.
> 
> I could have used the numerical address offsets in the resource 
> definition, but I wanted to emphasize the fact that the offsets are 
> already defined by the DPRAM memory allocator (this is a little
> hackish, yes) instead of hardware directly requiring these exact
> values.
> 

Aha, I recall now. There was nearly exactly the same discussion in the past. 
The recap was since ppc_platform_devices[] approach is not flexible enough, revisit issue from the 
arch/powerpc POV. 

> This snippet is from cpm2.h:
> 
>  	/* Dual Port RAM addresses.  The first 16K is available for
> almost
>  	 * any CPM use, so we put the BDs there.  The first 128
> bytes are
>  	 * used for SMC1 and SMC2 parameter RAM, so we start
> allocating
>  	 * BDs above that.  All of this must change when we start
>  	 * downloading RAM microcode.
>  	 */
>  	#define CPM_DATAONLY_BASE       ((uint)128)
> 
> My patch puts pram_base exactly here.
> 
> 

I know, the questionable thing was if there is enough "value" to add yet another platform device for that.

Since it improves current ppc being and sort of puts a note for powerpc port, I'm inclined to ACK.

Thanks,

-Vitaly

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2006-11-07 14:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-06 13:29 [PATCH] CPM_UART: Fixed SMC handling for CPM2 processors Kalle Pokki
2006-11-06 17:55 ` Vitaly Bordug
2006-11-06 20:49   ` Kalle Pokki
2006-11-07 12:08     ` Vitaly Bordug
2006-11-07 13:21       ` Kalle Pokki
2006-11-07 14:47         ` Vitaly Bordug [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-02-12 10:33 Heiko Schocher
2007-02-12 17:55 ` Vitaly Bordug
2007-02-13  8:09   ` Heiko Schocher
2007-02-13 11:42     ` Vitaly Bordug

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=20061107174741.3d837e19@localhost.localdomain \
    --to=vbordug@ru.mvista.com \
    --cc=kalle.pokki@iki.fi \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=paulus@samba.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.