From: David Gibson <dwg@au1.ibm.com>
To: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 2/3] Derive ebc ranges property from EBC registers
Date: Wed, 16 May 2007 09:09:30 +1000 [thread overview]
Message-ID: <20070515230930.GB20290@localhost.localdomain> (raw)
In-Reply-To: <1179233998.3084.28.camel@zod.rchland.ibm.com>
On Tue, May 15, 2007 at 07:59:58AM -0500, Josh Boyer wrote:
> On Tue, 2007-05-15 at 14:54 +1000, David Gibson wrote:
> > void ebony_init(void *mac0, void *mac1)
> > Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
> > ===================================================================
> > --- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-05-14 14:38:39.000000000 +1000
> > +++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-05-14 14:45:56.000000000 +1000
> > @@ -136,11 +136,9 @@
> > #address-cells = <2>;
> > #size-cells = <1>;
> > clock-frequency = <0>; // Filled in by zImage
> > - ranges = <0 00000000 fff00000 100000
> > - 1 00000000 48000000 100000
> > - 2 00000000 ff800000 400000
> > - 3 00000000 48200000 100000
> > - 7 00000000 48300000 100000>;
> > + // ranges property is supplied by zImage
> > + // based on firmware's configuration of the
> > + // EBC bridge
>
> Do we want a "ranges;" here as a placeholder? I don't see where it's
> absolutely required, but it makes me feel better for some reason...
Absolutely not. An empty ranges property indicates that the child bus
address space is the same as the parent bus address space. If we're
using the chip-select/offset addressing form for the EBC peripherals,
that's manifestly not the case.
> > +
> > +/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
> > + * banks into the OPB address space */
> > +void ibm4xx_fixup_ebc_ranges(const char *ebc)
> > +{
> > + void *devp;
> > + u32 bxcr;
> > + u32 ranges[EBC_NUM_BANKS*4];
> > + u32 *p = ranges;
> > + int i;
> > +
> > + for (i = 0; i < EBC_NUM_BANKS; i++) {
> > + mtdcr(DCRN_EBC0_CFGADDR, EBC_BXCR(i));
> > + bxcr = mfdcr(DCRN_EBC0_CFGDATA);
> > +
> > + if ((bxcr & EBC_BXCR_BU) != EBC_BXCR_BU_OFF) {
> > + *p++ = i;
> > + *p++ = 0;
> > + *p++ = bxcr & EBC_BXCR_BAS;
> > + *p++ = EBC_BXCR_BANK_SIZE(bxcr);
> > + }
> > + }
> > +
> > + devp = finddevice(ebc);
> > + if (! devp)
> > + fatal("Couldn't locate EBC node %s\n\r", ebc);
> > +
> > + setprop(devp, "ranges", ranges, (p - ranges) * sizeof(u32));
> > +}
>
> So this sets the ranges for the EBC bus, but not the "regs" properties
> of the child nodes. Without that, the child nodes will not be mapped to
> the correct addresses...
Well, no, the child reg properties can't be deduced from the EBC
registers.
> Did you have a plan on how to fixup the child "regs" properties so that
> when the DIP switches are flipped around, the children show up
> correctly?
Well, on Ebony (AFAICT), the only child reg property that might need
adjustment is the small flash. My MTD enabling patch includes some
code in the boot wrapper to toggle the appropriate bit in it's reg
property.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2007-05-16 0:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-15 4:52 [0/3] Ebony tweaks David Gibson
2007-05-15 4:54 ` [PATCH 2/3] Derive ebc ranges property from EBC registers David Gibson
2007-05-15 12:59 ` Josh Boyer
2007-05-15 23:09 ` David Gibson [this message]
2007-05-16 2:29 ` Josh Boyer
2007-05-16 3:13 ` David Gibson
2007-05-16 13:28 ` Segher Boessenkool
2007-05-15 4:54 ` [PATCH 1/3] Factor zImage's 44x reset code out of ebony.c David Gibson
2007-05-15 12:47 ` Josh Boyer
2007-05-15 4:54 ` [PATCH 3/3] Fixes to allow use of Ebony's flash chips through physmap_of David Gibson
2007-05-15 13:10 ` Josh Boyer
2007-05-15 23:10 ` David Gibson
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=20070515230930.GB20290@localhost.localdomain \
--to=dwg@au1.ibm.com \
--cc=jwboyer@linux.vnet.ibm.com \
--cc=linuxppc-dev@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).