* Re: [PATCH 2/2] [POWERPC] Add L2 cache node to AMCC Taishan dts file
From: David Gibson @ 2008-03-18 23:24 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1205847466-17854-1-git-send-email-sr@denx.de>
On Tue, Mar 18, 2008 at 02:37:46PM +0100, Stefan Roese wrote:
> This patch adds the L2 cache node to the Taishan 440GX dts file.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> arch/powerpc/boot/dts/taishan.dts | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
> index 8278068..d0bff33 100644
> --- a/arch/powerpc/boot/dts/taishan.dts
> +++ b/arch/powerpc/boot/dts/taishan.dts
> @@ -104,6 +104,16 @@
> // FIXME: anything else?
> };
>
> + L2C0: l2c@30 {
A node with no reg property shouldn't have a unit address.
> + compatible = "ibm,l2-cache-440gx", "ibm,l2-cache";
> + dcr-reg = <20 8 /* Internal SRAM DCR's */
> + 30 8>; /* L2 cache DCR's */
> + cache-line-size = <20>; /* 32 bytes */
> + cache-size = <40000>; /* L2, 256K */
> + interrupt-parent = <&UIC2>;
> + interrupts = <17 1>;
> + };
Now.. usually cache nodes are given as descendents of the CPU node.
In this case you have the DCR control registers though, so I guess
this is representing a control interface rather than the cache
itself. Hrm.. not really sure how to do this.
--
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
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] Add L2 cache node to AMCC Taishan dts file
From: Segher Boessenkool @ 2008-03-18 22:40 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1205847466-17854-1-git-send-email-sr@denx.de>
> + L2C0: l2c@30 {
> + compatible = "ibm,l2-cache-440gx", "ibm,l2-cache";
> + dcr-reg = <20 8 /* Internal SRAM DCR's */
> + 30 8>; /* L2 cache DCR's */
The unit address is based on the _first_ entry in "reg". No2 this
is "dcr-reg", but you don't really want to be more incompatible than
necessary...
Segher
^ permalink raw reply
* Re: [PATCH v2] Force 4K pages for IO addresses.
From: Tony Breeds @ 2008-03-18 21:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Jan-Bernd Themann, LinuxPPC-dev, Nathan Lynch,
Olof Johansson, Paul Mackerras
In-Reply-To: <1205872285.26869.251.camel@pasglop>
On Wed, Mar 19, 2008 at 07:31:25AM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2008-03-18 at 09:45 -0500, Nathan Lynch wrote:
> > The ibm,drc-names property of the root node should have "HEA" strings
> > in it on systems where EHEA can potentially be present.
>
> Ah good, I didn't know. That will force us to stick an ugly wart
> somewhere to test it though, maybe we can just force mmu_ci_restrictions
> to 1 ? Paul what do you think ?
That's not enough, mmu_io_psize also needs to be 4K. I'll poke at doing
something platform specific today.
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Scott Wood @ 2008-03-18 20:48 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080318202717.GA1030@localhost.localdomain>
Anton Vorontsov wrote:
> On Tue, Mar 18, 2008 at 02:55:14PM -0500, Scott Wood wrote:
>> Anton Vorontsov wrote:
>>>>> +arch_initcall(qe_init_gtm);
>>>> If this happens before the gtm_init_gtm(),
>>> "If" isn't possible, order is guaranteed.
>> You use arch_initcall for both, so you're relying on link order. I
>> think this at least merits a comment.
>>>> then np->data will not be set.
>>> It's a bug in the device tree or in the Linux code then.
>> Hmm? It's set by gtm_init_gtm(). If this code runs before
>> gtm_init_gtm(), what are you expecting to initialize np->data?
>
> What code exactly?
Sorry, "this code" == qe_init_gtm(). Obviously, if you assume that
gtm_init_gtm() will always be linked earlier, then it's not an issue.
>> Also, what if some arch_initcall runs between gtm_init_gtm and
>> qe_init_gtm, that registers itself as a client of the gtm driver, and
>> uses the wrong clock value?
>
> Again, what code exactly? If it is a driver (for what this API is
> created for), it hardly will run earlier than arch/ code. If this is
> platform code (arch/powerpc/platform/), then it is hardly will run
> earlier than arch/sysdev/. Inside the arch/sysdev/ fsl_gtm.c is
> guaranteed to run earlier than qe_lib/gtm.c. So, where is the problem?
That's a lot of implicit, undocumented dependency on link order...
Things can be moved around, and driver-ish code can pop up in surprising
places. All I meant was that having the gtm driver present itself as
ready when it isn't, in a way which isn't readily apparent if it
happens, is worrysome.
> Since I'll implement clock-frequency inside the timer node, this
> isn't relevant anymore...
OK, good.
> Ah. You need specific timer. No problem. I don't like idea of new arguments
> to the gtm_get_timer() function (complicates things), but we can just
> implement another one. gtm_get_timer_<name>, choice the name please.
> _specific, _2, _for, __gtm_get_timer, ...
How about:
struct gtm_timer *gtm_get_specific_timer(struct gtm *gtm, int timer,
int width);
...with np->data used by the caller to figure out which gtm pointer to
pass in.
-Scott
^ permalink raw reply
* Re: [PATCH v2] Force 4K pages for IO addresses.
From: Benjamin Herrenschmidt @ 2008-03-18 20:31 UTC (permalink / raw)
To: Nathan Lynch
Cc: Olof Johansson, LinuxPPC-dev, Jan-Bernd Themann, Paul Mackerras,
Stephen Rothwell
In-Reply-To: <20080318144511.GQ4712@localdomain>
On Tue, 2008-03-18 at 09:45 -0500, Nathan Lynch wrote:
> Benjamin Herrenschmidt wrote:
> >
> > On Mon, 2008-03-17 at 19:34 -0500, Olof Johansson wrote:
> > > On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote:
> > > > Currently HEA requires 4K pages for IO resources. Just set the pages size to
> > > > IO to 4K.
> > >
> > > Well, that's too bad. Why penalize all platforms for it?
> > >
> > > I.e.: Nack, we use 64K iopages on pa6t and it works well. No need to
> > > waste tlb and erat space.
> >
> > We would have to make that pSeries specific for now I suppose...
> >
> > We don't have a way to know that there "can" be an EHEA right ? It may
> > not be in the device-tree at boot and dynamically added to the
> > partition...
>
> The ibm,drc-names property of the root node should have "HEA" strings
> in it on systems where EHEA can potentially be present.
Ah good, I didn't know. That will force us to stick an ugly wart
somewhere to test it though, maybe we can just force mmu_ci_restrictions
to 1 ? Paul what do you think ?
Ben.
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Anton Vorontsov @ 2008-03-18 20:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47E01E22.9000807@freescale.com>
On Tue, Mar 18, 2008 at 02:55:14PM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
> >>>+arch_initcall(qe_init_gtm);
> >>If this happens before the gtm_init_gtm(),
> >
> >"If" isn't possible, order is guaranteed.
>
> You use arch_initcall for both, so you're relying on link order. I
> think this at least merits a comment.
> >>then np->data will not be set.
> >
> >It's a bug in the device tree or in the Linux code then.
>
> Hmm? It's set by gtm_init_gtm(). If this code runs before
> gtm_init_gtm(), what are you expecting to initialize np->data?
What code exactly?
> >>If this happens after gtm_init_gtm(), then gtm_init_gtm() will fail in
> >>gtm_get_clock(), if there's no clock-frequency -- and if there is, then
> >>why
> >>do we need qe_init_gtm() at all?
> >
> >Because for the QE clock-frequency != brg-frequency.
>
> Sorry, I missed that you were getting clock-frequency from the parent,
> rather than the gtm node. If you do the latter, then you can just stick
> the relevant frequency in the gtm node and not worry about where it
> comes from. This would be analogous to how UART clocks are specified.
Ok.
> Also, what if some arch_initcall runs between gtm_init_gtm and
> qe_init_gtm, that registers itself as a client of the gtm driver, and
> uses the wrong clock value?
Again, what code exactly? If it is a driver (for what this API is
created for), it hardly will run earlier than arch/ code. If this is
platform code (arch/powerpc/platform/), then it is hardly will run
earlier than arch/sysdev/. Inside the arch/sysdev/ fsl_gtm.c is
guaranteed to run earlier than qe_lib/gtm.c. So, where is the problem?
Since I'll implement clock-frequency inside the timer node, this
isn't relevant anymore...
> >>>+extern struct gtm_timer *gtm_get_timer(int width);
> >>To support using the GTM as a wakeup from deep sleep on 831x (which I've
> >>had
> >>a patch pending for quite a while now), we'll need some way of reserving a
> >>specific timer (only GTM1, timer 4 is supported).
> >
> >You can add reserve function either in the PM driver (if any), or
>
> What I meant was that there needs to be some way of telling this driver
> not to hand the reserved timer out to some other client.
>
> >you can do something in the device tree (wakeup-timer = <..>). I don't
> >see any problems if you want to implement it.
>
> How about simply having optional arguments to gtm_get_timer() to specify
> the GTM device and timer number, which will fail if it's already in use?
> Then, the PM driver simply needs to run early enough to grab the timer
> it needs.
Ah. You need specific timer. No problem. I don't like idea of new arguments
to the gtm_get_timer() function (complicates things), but we can just
implement another one. gtm_get_timer_<name>, choice the name please.
_specific, _2, _for, __gtm_get_timer, ...
--
Anton Vorontsov
email: cboumailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Scott Wood @ 2008-03-18 19:55 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080318192152.GA26493@localhost.localdomain>
Anton Vorontsov wrote:
>>> +arch_initcall(qe_init_gtm);
>> If this happens before the gtm_init_gtm(),
>
> "If" isn't possible, order is guaranteed.
You use arch_initcall for both, so you're relying on link order. I
think this at least merits a comment.
>> then np->data will not be set.
>
> It's a bug in the device tree or in the Linux code then.
Hmm? It's set by gtm_init_gtm(). If this code runs before
gtm_init_gtm(), what are you expecting to initialize np->data?
>> If this happens after gtm_init_gtm(), then gtm_init_gtm() will fail in
>> gtm_get_clock(), if there's no clock-frequency -- and if there is, then why
>> do we need qe_init_gtm() at all?
>
> Because for the QE clock-frequency != brg-frequency.
Sorry, I missed that you were getting clock-frequency from the parent,
rather than the gtm node. If you do the latter, then you can just stick
the relevant frequency in the gtm node and not worry about where it
comes from. This would be analogous to how UART clocks are specified.
Also, what if some arch_initcall runs between gtm_init_gtm and
qe_init_gtm, that registers itself as a client of the gtm driver, and
uses the wrong clock value?
>>> +extern struct gtm_timer *gtm_get_timer(int width);
>> To support using the GTM as a wakeup from deep sleep on 831x (which I've had
>> a patch pending for quite a while now), we'll need some way of reserving a
>> specific timer (only GTM1, timer 4 is supported).
>
> You can add reserve function either in the PM driver (if any), or
What I meant was that there needs to be some way of telling this driver
not to hand the reserved timer out to some other client.
> you can do something in the device tree (wakeup-timer = <..>). I don't
> see any problems if you want to implement it.
How about simply having optional arguments to gtm_get_timer() to specify
the GTM device and timer number, which will fail if it's already in use?
Then, the PM driver simply needs to run early enough to grab the timer
it needs.
-Scott
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Anton Vorontsov @ 2008-03-18 19:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080318174329.GB4099@loki.buserror.net>
On Tue, Mar 18, 2008 at 12:43:29PM -0500, Scott Wood wrote:
> On Tue, Mar 11, 2008 at 08:24:29PM +0300, Anton Vorontsov wrote:
> > + Required properties:
> > + - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
> > + GTMs).
> > + - reg : should contain gtm registers location and length (0x40).
> > + - interrupts : should contain four interrupts.
> > + - interrupt-parent : interrupt source phandle.
>
> interrupt-parent isn't required; it's perfectly valid to specify that in the
> parent node instead.
Ok
>
> > + Example:
> > +
> > + gtm@500 {
> > + compatible = "fsl,gtm";
> > + reg = <0x500 0x40>;
> > + interrupts = <90 8 78 8 84 8 72 8>;
> > + interrupt-parent = <&ipic>;
> > + };
> > +
> > + gtm@440 {
> > + compatible = "fsl,qe-gtm", "fsl,gtm";
> > + reg = <0x440 0x40>;
> > + interrupts = <12 13 14 15>;
> > + interrupt-parent = <&qeic>;
> > + };
>
> "timer" would be a better node name than "gtm".
Ok
> > +static int __init gtm_init_gtm(void)
>
> Name seems rather redundant... what's wrong with gtm_init()?
Probably :%s/// effect. Will fix.
> > +/*
> > + * For now we just fixing up the clock -- it's brg-frequency for QE
> > + * chips, generic code does not and should not know these details.
> > + *
> > + * Later we might want to set up BRGs, when QE will actually use
> > + * them (there are TIMERCS bits in the CMXGCR register, but today
> > + * these bits seem to be no-ops.
> > + */
> > +static int __init qe_init_gtm(void)
> > +{
> > + struct device_node *np;
> > +
> > + for_each_compatible_node(np, NULL, "fsl,qe-gtm") {
> > + struct gtm *gtm = np->data;
> > +
> > + if (!gtm) {
> > + /* fsl,qe-gtm without fsl,gtm compatible? */
> > + WARN_ON(1);
> > + continue;
> > + }
> > +
> > + gtm->clock = qe_get_brg_clk();
> > + }
> > +
> > + return 0;
> > +}
> > +arch_initcall(qe_init_gtm);
>
> If this happens before the gtm_init_gtm(),
"If" isn't possible, order is guaranteed.
> then np->data will not be set.
It's a bug in the device tree or in the Linux code then.
> If this happens after gtm_init_gtm(), then gtm_init_gtm() will fail in
> gtm_get_clock(), if there's no clock-frequency -- and if there is, then why
> do we need qe_init_gtm() at all?
Because for the QE clock-frequency != brg-frequency.
> > +/**
> > + * gtm_get_timer - request GTM timer for use with the rest of GTM API
> > + * @width: timer width (only 16 bits wide timers implemented so far)
> > + *
> > + * This function reserves GTM timer for later use. It returns gtm_timer
> > + * structure to use with the rest of GTM API, you should use timer->irq
> > + * to manage timer interrupt.
> > + */
> > +extern struct gtm_timer *gtm_get_timer(int width);
>
> To support using the GTM as a wakeup from deep sleep on 831x (which I've had
> a patch pending for quite a while now), we'll need some way of reserving a
> specific timer (only GTM1, timer 4 is supported).
You can add reserve function either in the PM driver (if any), or
you can do something in the device tree (wakeup-timer = <..>). I don't
see any problems if you want to implement it.
> > +/**
> > + * gtm_put_timer - release GTM timer
> > + * @width: timer width (only 16 bits wide timers implemented so far)
> > + *
> > + * This function releases GTM timer sp others might request it.
> > + */
> > +extern void gtm_put_timer(struct gtm_timer *tmr);
> > +
> > +/**
> > + * gtm_reset_ref_timer_16 - (re)set single (16 bits) timer in reference mode
> > + * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
> > + * @hz: timer rate in Hz
> > + * @ref: refernce value
>
> How about "period" or "expiry"? And it'd be better to let the caller
> request a time in some real unit (e.g. microseconds), and let the gtm driver
> figure out how to divide that between prescaler and reference value,
> especially in the absence of a way to ask for the allowable hz ranges.
Will think about it.
> > + * @ffr: free run flag
>
> Could we call it something more intuitive such as "freerun"?
Easy.
> > + * Thus function (re)sets GTM timer so it counts up to the reference value and
> > + * fires the interrupt when the value is reached. If ffr flag is set, timer
> > + * will also reset itself upon reference value, otherwise it continues to
> > + * increment.
> > + */
> > +extern int gtm_reset_ref_timer_16(struct gtm_timer *tmr, unsigned int hz,
> > + u16 ref, bool ffr);
> > +
> > +/**
> > + * gtm_ack_ref_timer_16 - acknowledge timer event (free-run timers only)
> > + * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
> > + *
> > + * Thus function used to acknowledge timer interrupt event, use it inside the
> > + * interrupt handler.
> > + */
> > +static inline void gtm_ack_ref_timer_16(struct gtm_timer *tmr)
>
> What does the "ref" mean in these names?
>
> How about "gtm_arm_timer16" and "gtm_ack_timer16"?
Ok.
>
> > +{
> > + out_be16(tmr->gtevr, 0xFFFF);
> > +}
>
> You need to include <asm/io.h> for this.
Ok.
> Don't blindly clear all events, just the events that have been acted upon.
> Either take the events as an argument, or make the ack function specifi
Ok.
Thanks,
--
Anton Vorontsov
email: cboumailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Hi,friends, the question about the u-boot and device tree?
From: Scott Wood @ 2008-03-18 18:28 UTC (permalink / raw)
To: 郭劲; +Cc: u-boot-users, linuxppc-embedded
In-Reply-To: <405422271.18508@tsinghua.org.cn>
On Thu, Mar 13, 2008 at 11:31:11PM +0800, 郭劲 wrote:
> I make all the frequency(timebase-frequency;bus-frequency;clock-frequency) value
> on device tree file equal to zero, I think those frequency will filled by u-boot
> during bootm, but in fact, the u-boot did not fill any frequency. after bootm,
> crashed. Why?
What board? Are you using a device-tree-aware u-boot and the three-argument
form of bootm? What sort of crash? How do you know it's not filling in the
frequencies?
> Why so many document point out that the zero value will be filled by u-boot?
Because it does. :-)
If it's not doing so on your board, that needs to be fixed.
-Scott
^ permalink raw reply
* Re: [PATCH 3/8] [POWERPC] qe_lib: implement qe_muram_offset
From: Scott Wood @ 2008-03-18 17:48 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080311172413.GC7727@localhost.localdomain>
On Tue, Mar 11, 2008 at 08:24:13PM +0300, Anton Vorontsov wrote:
> qe_muram_offset is the reverse of the qe_muram_addr, will be
> used for the Freescale QE USB Host Controller driver.
>
> This patch also moves qe_muram_addr into the qe.h header, plus
> adds __iomem hints to use with sparse.
We should really switch QE over to using the muram code in cpm_common.c...
-Scott
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Scott Wood @ 2008-03-18 17:43 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080311172429.GF7727@localhost.localdomain>
On Tue, Mar 11, 2008 at 08:24:29PM +0300, Anton Vorontsov wrote:
> + Required properties:
> + - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
> + GTMs).
> + - reg : should contain gtm registers location and length (0x40).
> + - interrupts : should contain four interrupts.
> + - interrupt-parent : interrupt source phandle.
interrupt-parent isn't required; it's perfectly valid to specify that in the
parent node instead.
> + Example:
> +
> + gtm@500 {
> + compatible = "fsl,gtm";
> + reg = <0x500 0x40>;
> + interrupts = <90 8 78 8 84 8 72 8>;
> + interrupt-parent = <&ipic>;
> + };
> +
> + gtm@440 {
> + compatible = "fsl,qe-gtm", "fsl,gtm";
> + reg = <0x440 0x40>;
> + interrupts = <12 13 14 15>;
> + interrupt-parent = <&qeic>;
> + };
"timer" would be a better node name than "gtm".
> +static int __init gtm_init_gtm(void)
Name seems rather redundant... what's wrong with gtm_init()?
> +/*
> + * For now we just fixing up the clock -- it's brg-frequency for QE
> + * chips, generic code does not and should not know these details.
> + *
> + * Later we might want to set up BRGs, when QE will actually use
> + * them (there are TIMERCS bits in the CMXGCR register, but today
> + * these bits seem to be no-ops.
> + */
> +static int __init qe_init_gtm(void)
> +{
> + struct device_node *np;
> +
> + for_each_compatible_node(np, NULL, "fsl,qe-gtm") {
> + struct gtm *gtm = np->data;
> +
> + if (!gtm) {
> + /* fsl,qe-gtm without fsl,gtm compatible? */
> + WARN_ON(1);
> + continue;
> + }
> +
> + gtm->clock = qe_get_brg_clk();
> + }
> +
> + return 0;
> +}
> +arch_initcall(qe_init_gtm);
If this happens before the gtm_init_gtm(), then np->data will not be set.
If this happens after gtm_init_gtm(), then gtm_init_gtm() will fail in
gtm_get_clock(), if there's no clock-frequency -- and if there is, then why
do we need qe_init_gtm() at all?
> +/**
> + * gtm_get_timer - request GTM timer for use with the rest of GTM API
> + * @width: timer width (only 16 bits wide timers implemented so far)
> + *
> + * This function reserves GTM timer for later use. It returns gtm_timer
> + * structure to use with the rest of GTM API, you should use timer->irq
> + * to manage timer interrupt.
> + */
> +extern struct gtm_timer *gtm_get_timer(int width);
To support using the GTM as a wakeup from deep sleep on 831x (which I've had
a patch pending for quite a while now), we'll need some way of reserving a
specific timer (only GTM1, timer 4 is supported).
> +/**
> + * gtm_put_timer - release GTM timer
> + * @width: timer width (only 16 bits wide timers implemented so far)
> + *
> + * This function releases GTM timer sp others might request it.
> + */
> +extern void gtm_put_timer(struct gtm_timer *tmr);
> +
> +/**
> + * gtm_reset_ref_timer_16 - (re)set single (16 bits) timer in reference mode
> + * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
> + * @hz: timer rate in Hz
> + * @ref: refernce value
How about "period" or "expiry"? And it'd be better to let the caller
request a time in some real unit (e.g. microseconds), and let the gtm driver
figure out how to divide that between prescaler and reference value,
especially in the absence of a way to ask for the allowable hz ranges.
> + * @ffr: free run flag
Could we call it something more intuitive such as "freerun"?
> + * Thus function (re)sets GTM timer so it counts up to the reference value and
> + * fires the interrupt when the value is reached. If ffr flag is set, timer
> + * will also reset itself upon reference value, otherwise it continues to
> + * increment.
> + */
> +extern int gtm_reset_ref_timer_16(struct gtm_timer *tmr, unsigned int hz,
> + u16 ref, bool ffr);
> +
> +/**
> + * gtm_ack_ref_timer_16 - acknowledge timer event (free-run timers only)
> + * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
> + *
> + * Thus function used to acknowledge timer interrupt event, use it inside the
> + * interrupt handler.
> + */
> +static inline void gtm_ack_ref_timer_16(struct gtm_timer *tmr)
What does the "ref" mean in these names?
How about "gtm_arm_timer16" and "gtm_ack_timer16"?
> +{
> + out_be16(tmr->gtevr, 0xFFFF);
> +}
You need to include <asm/io.h> for this.
Don't blindly clear all events, just the events that have been acted upon.
Either take the events as an argument, or make the ack function specific to
REF, and only set that bit.
-Scott
^ permalink raw reply
* RE: Kernel stack overflow in process xxxx
From: Nicholas Mc Guire @ 2008-03-18 18:12 UTC (permalink / raw)
To: jay_chen; +Cc: linuxppc-embedded
In-Reply-To: <018401c887ff$087fc2a0$016ffea9@alphajay>
> By the way, is there any skill/tool to avoid/detect/check this kind of
> problem?
>
did you try:
Kernel hacking --->
...
[*] Kernel debugging
...
[*] Check for stack overflows
[*] Stack utilization instrumentation
the last one depends on SysRq though.
In any case it would be interesting to know if these tools can help find
problems of this kind - so if it does not help - pleas let me/us know.
hofrat
^ permalink raw reply
* [PATCH][POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
From: Grant Likely @ 2008-03-18 17:07 UTC (permalink / raw)
To: linuxppc-dev, john.linn, jwboyer, stephen.neuendorffer, scottwood
From: Grant Likely <grant.likely@secretlab.ca>
This target produces a flat binary rather than an ELF file,
fixes the entry point at the beginning of the image, and takes
a complete device tree with no fixups needed.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
This has been tested on a Xilinx Virtex 4 target with the image loaded into
RAM via JTAG.
arch/powerpc/boot/Makefile | 9 +++-
arch/powerpc/boot/simpleboot.c | 84 ++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/virtex405-head.S | 30 +++++++++++++
arch/powerpc/boot/wrapper | 4 ++
4 files changed, 126 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 4974d9e..f6605fe 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -40,6 +40,7 @@ $(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
+$(obj)/virtex405-head.o: BOOTCFLAGS += -mcpu=405
zlib := inffast.c inflate.c inftrees.c
@@ -64,7 +65,7 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c
cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
fixed-head.S ep88xc.c ep405.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
- cuboot-warp.c cuboot-85xx-cpm2.c
+ cuboot-warp.c cuboot-85xx-cpm2.c simpleboot.c virtex405-head.S
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -305,6 +306,12 @@ $(obj)/uImage: vmlinux $(wrapperbits)
$(obj)/cuImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
$(call if_changed,wrap,cuboot-$*,$(dtstree)/$*.dts)
+$(obj)/simpleImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,simpleboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
+
+$(obj)/simpleImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,simpleboot-$*,$(dtstree)/$*.dts)
+
$(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
diff --git a/arch/powerpc/boot/simpleboot.c b/arch/powerpc/boot/simpleboot.c
new file mode 100644
index 0000000..86cd285
--- /dev/null
+++ b/arch/powerpc/boot/simpleboot.c
@@ -0,0 +1,84 @@
+/*
+ * The simple platform -- for booting when firmware doesn't supply a device
+ * tree or any platform configuration information.
+ * All data is extracted from an embedded device tree
+ * blob.
+ *
+ * Authors: Scott Wood <scottwood@freescale.com>
+ * Grant Likely <grant.likely@secretlab.ca>
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2008 Secret Lab Technologies Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "types.h"
+#include "io.h"
+#include "stdio.h"
+#include "libfdt/libfdt.h"
+
+BSS_STACK(4*1024);
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ const u32 *na, *ns, *reg, *timebase;
+ u64 memsize64;
+ int node, size, i;
+
+ /* Make sure FDT blob is sane */
+ if (fdt_check_header(_dtb_start) != 0)
+ fatal("Invalid device tree blob\n");
+
+ /* Find the #address-cells and #size-cells properties */
+ node = fdt_path_offset(_dtb_start, "/");
+ if (node < 0)
+ fatal("Cannot find root node\n");
+ na = fdt_getprop(_dtb_start, node, "#address-cells", &size);
+ if (!na || (size != 4))
+ fatal("Cannot find #address-cells property");
+ ns = fdt_getprop(_dtb_start, node, "#size-cells", &size);
+ if (!ns || (size != 4))
+ fatal("Cannot find #size-cells property");
+
+ /* Find the memory range */
+ node = fdt_node_offset_by_prop_value(_dtb_start, -1, "device_type",
+ "memory", sizeof("memory"));
+ if (node < 0)
+ fatal("Cannot find memory node\n");
+ reg = fdt_getprop(_dtb_start, node, "reg", &size);
+ if (size < (*na+*ns) * sizeof(u32))
+ fatal("cannot get memory range\n");
+
+ /* Only interested in memory based at 0 */
+ for (i = 0; i < *na; i++)
+ if (*reg++ != 0)
+ fatal("Memory range is not based at address 0\n");
+
+ /* get the memsize and trucate it to under 4G on 32 bit machines */
+ memsize64 = 0;
+ for (i = 0; i < *ns; i++)
+ memsize64 = (memsize64 << 32) | *reg++;
+ if (sizeof(void *) == 4 && memsize64 >= 0x100000000ULL)
+ memsize64 = 0xffffffff;
+
+ /* finally, setup the timebase */
+ node = fdt_node_offset_by_prop_value(_dtb_start, -1, "device_type",
+ "cpu", sizeof("cpu"));
+ if (!node)
+ fatal("Cannot find cpu node\n");
+ timebase = fdt_getprop(_dtb_start, node, "timebase-frequency", &size);
+ if (timebase && (size == 4))
+ timebase_period_ns = 1000000000 / *timebase;
+
+ /* Now we have the memory size; initialize the heap */
+ simple_alloc_init(_end, memsize64 - (unsigned long)_end, 32, 64);
+
+ /* prepare the device tree and find the console */
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
diff --git a/arch/powerpc/boot/virtex405-head.S b/arch/powerpc/boot/virtex405-head.S
new file mode 100644
index 0000000..3edb13f
--- /dev/null
+++ b/arch/powerpc/boot/virtex405-head.S
@@ -0,0 +1,30 @@
+#include "ppc_asm.h"
+
+ .text
+ .global _zimage_start
+_zimage_start:
+
+ /* PPC errata 213: needed by Virtex-4 FX */
+ mfccr0 0
+ oris 0,0,0x50000000@h
+ mtccr0 0
+
+ /*
+ * Invalidate the data cache if the data cache is turned off.
+ * - The 405 core does not invalidate the data cache on power-up
+ * or reset but does turn off the data cache. We cannot assume
+ * that the cache contents are valid.
+ * - If the data cache is turned on this must have been done by
+ * a bootloader and we assume that the cache contents are
+ * valid.
+ */
+ mfdccr r9
+ cmplwi r9,0
+ bne 2f
+ lis r9,0
+ li r8,256
+ mtctr r8
+1: dccci r0,r9
+ addi r9,r9,0x20
+ bdnz 1b
+2: b _zimage_start_lib
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index d50e498..c9e092b 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -199,6 +199,10 @@ adder875-redboot)
platformo="$object/fixed-head.o $object/redboot-8xx.o"
binary=y
;;
+simpleboot-virtex405-*)
+ platformo="$object/virtex405-head.o $object/simpleboot.o"
+ binary=y
+ ;;
esac
vmz="$tmpdir/`basename \"$kernel\"`.$ext"
^ permalink raw reply related
* Re: [PATCH v2] Make 83xx perfmon support selectable
From: Scott Wood @ 2008-03-18 17:05 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, paulus
In-Reply-To: <1204934343-5235-1-git-send-email-afleming@freescale.com>
On Fri, Mar 07, 2008 at 05:59:03PM -0600, Andy Fleming wrote:
> Not all e300 cores support the performance monitors, and the ones
> that don't will be confused by the mf/mtpmr instructions. This
> allows the support to be optional, so the 8349 can turn it off
> while the 8379 can turn it on. Sadly, those aren't config options,
> so it will be left to the defconfigs and the users to make that
> determination.
So does this mean we can't do multiplatform of something with perfmon and
something without perfmon? Seems like this should come from the device
tree, or PVR, or some other runtime check.
-Scott
^ permalink raw reply
* Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
From: Scott Wood @ 2008-03-18 16:56 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Stephen Rothwell, Heiko Schocher, linuxppc-dev
In-Reply-To: <20080318161957.766A124349@gemini.denx.de>
Wolfgang Denk wrote:
> Dear Scott,
>
> in message <20080318151132.GA17402@ld0162-tx32.am.freescale.net> you wrote:
>> Well, the device tree is a mechanism for communicating from the firmware
>> to the kernel, and if we could control the firmware better we'd just make
>> it set the pins properly to begin with. :-)
>
> Is this just a comment, or do you oppose Heiko's suggestion?
It was intended more as a gentle nudge to set up the pins in firmware
when not constrained by existing firmwares in the field that must be
supported.
> Other uses of the device tree seem possible and reasonable, too. For
> example, we can use the device tree to configure the firmware (U-Boot
> in this case).
>
> Using the device tree to describe the pin configuration of the
> hardware sounds easier to me than hard-coding it in some source (or
> header) file - no matter if this is in the kernel and/or in the
> firmware.
>
> What do you think?
I'm fine with putting it in the device tree for firmware's benefit,
though I'm not sure I fully agree with the "easier" bit until we get
support for expressions and named constants in dts, so that the flags
would be less opaque.
-Scott
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-03-18 16:53 UTC (permalink / raw)
To: Richard Purdie; +Cc: linuxppc-dev
In-Reply-To: <1205858510.7500.35.camel@dax.rpnet.com>
On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
>
> On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote:
> I don't mind having a specific driver but I don't know anything about
> the hardware its creating the interface for so I need the community's
> help with that part. There is drivers/leds/leds-gpio.c if that would
> work better.
Yes, I think that would be the right approach. We would need to add
the binding code to translate from the OF device tree to the leds-gpio
driver.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: simple MPC5200B system
From: Andre Schwarz @ 2008-03-18 16:44 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-ppc list
In-Reply-To: <fa686aa40803180921l654d6336udd285cf13e4138b5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4010 bytes --]
Grant Likely schrieb:
> On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz
> <andre.schwarz@matrix-vision.de> wrote:
>
>> I've read some discussions about the "interrupt-map" attribute of the pci
>> node. I tried to follow Ben and David in their explanations - obviously I
>> didn't really get it.
>> Looks like there are a lot of people outside who need some enlightenment
>> ... including me, of course.
>>
>> Maybe you can clarify this ?
>>
>> Taken from motionpro.dts ...
>>
>>
>
> First, you also need to look at interrupt-map-mask to interpret these
> values; from motionpro.dts:
>
> interrupt-map-mask = <f800 0 0 7>;
>
> which is applied to the unit interrupt specifier to figure out how to
> map onto the interrupt controller. The /size/ of this field is
> obtained by adding #address-cells with #interrupt-cells. (3+1=4).
>
> 'f8' refers to the upper 5 bits of the interrupt identifier which is a
> number from 0-31 which relates to the IDSEL line as you guessed. The
> '7' covers the lower 3 bits of the interrupt specifier which can be 1,
> 2, 3 or 4.
>
> The 120 bits in the middle are irrelevant, so interrupt-map-mask
> leaves them as zeros.
>
>
ok.
>> interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
>> c000 0 0 2 &mpc5200_pic 1 1 3
>> c000 0 0 3 &mpc5200_pic 1 2 3
>> c000 0 0 4 &mpc5200_pic 1 3 3
>>
>> c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
>> c800 0 0 2 &mpc5200_pic 1 2 3
>> c800 0 0 3 &mpc5200_pic 1 3 3
>> c800 0 0 4 &mpc5200_pic 0 0 3>;
>>
>>
>> First parameter seems to be the slot number, i.e. IDSEL line of the PCI
>> device.
>> How is this value coded ? Are these the bits 15..11 of the configuration
>> address ?
>>
>
> I don't remember how this is encoded. On the lite5200, idsel is wired
> to d0 and d1 for slots 1 and 2 respectively, yet these values suggest
> slots 24 and 25. I'll need to look at this again later.
>
>
"pci info" from u-boot shows both devices (e1000 NIC + FPGA)
00 0a 4d56 1000 ff00 03 -> bus "0" , slot "0a", "irq 3"
00 0b 8086 1078 0200 02 -> bus "0" , slot "0b", "irq 2"
IDSEL mapping of MPC5200 is "0b0_1011" for slot 0xb and "0b0_1010" for
slot 0xa.
Using those 5 bits <<= 3 for the first cell gives "5800" and "5000"
>> 2nd + 3rd paramter : no clue ! can you explain ?
>>
>
> first 3 cells are the unit address and is #address-cells large. Only
> the first cell contains real data.
>
>
ok.
>> 4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only
>> INT_A. Do we need 4 entries in any case ?
>>
>
> you only need entries for irq lines that are wired up. If your board
> does not wire up _B, _C and _D, then don't have an entry for them.
> However, if they are wired up then you should describe them.
>
>
ok. I only have INT_A.
>> 5th : ok - parent pic
>>
>
> Correct.
>
>
>> 6th ... 8th : IRQ representation of the parent pic, which gives :
>>
>> 6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins
>> 7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have
>> number 1..3 inside MAIN level.
>> 8th : should be 3 = "level low" which is default for PCI.
>>
>
> Correct.
>
> There is also some good information here:
> http://playground.sun.com/1275/practice/imap/imap0_9d.pdf
>
> Cheers,
> g.
>
>
using the following "interrupt-map" give me two working PCI devices with
working interrupts ... :-)
interrupt-map = <5800 0 0 1 &mpc5200_pic 1 2 3 // e1000
5000 0 0 1 &mpc5200_pic 1 3 3>;// FPGA
Thanks for your explanations !
regards,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
[-- Attachment #2: Type: text/html, Size: 5899 bytes --]
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Richard Purdie @ 2008-03-18 16:41 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803180747u532f6a0bq1e64e01662bdb6bd@mail.gmail.com>
On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote:
> On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> > Grant,
> >
> > Yes, the Motion-PRO LED driver has been reworked and posted:
> > http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617
>
> Okay, I've taken another look at the driver and I've figured out what
> has been bothering me about it. It seems to me that the motion pro
> led driver is just the first of many that we will see (seeing as some
> many people find the blinking lights rather soothing) and it's a non
> trivial amount of code.
>
> (Note: I'm not actually opposed to this driver if Richard is okay with
> it; but I do think that in the long term we should move towards a more
> generic approach)
>
> In essence, this driver sets up two GPIO pins to drive LEDs. A pretty
> common approach for putting LEDs on a board. In this case each GPIO
> bank only contains 1 pin; but I imagine that on other boards there
> will be multiple pins in a GPIO bank, only some of which actually used
> for blinking LEDs.
>
> I've started thinking that it would be better to split things up in
> the device tree to have one node for each GPIO block and a single LED
> node that maps LEDs to gpio pins. That would allow a common driver to
> be written for all GPIO driven LEDs with a single block of device tree
> parsing code. Plus, it allows other devices to use GPIO pins within
> the same block (not an issue for the motion pro board; but when other
> boards start coming on-line it would allow us to reduce the amount of
> board specific code). Finally, it means that the timer pin GPIO
> driver can be used for more than just flashing an attached LED.
I don't mind having a specific driver but I don't know anything about
the hardware its creating the interface for so I need the community's
help with that part. There is drivers/leds/leds-gpio.c if that would
work better.
Regards,
Richard
^ permalink raw reply
* [PATCH v3] fsl_elbc_nand: fix mtd name
From: Anton Vorontsov @ 2008-03-18 16:34 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20080318161139.GD17944@ld0162-tx32.am.freescale.net>
Currently fsl_elbc_nand doesn't initialize mtd->name, and this causes
nand_get_flash_type() to assign name that is equal to chip type, like
this:
root@b1:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00010000 "fe000000.flash"
mtd1: 02000000 00004000 "NAND 32MiB 3,3V 8-bit"
mtd0 is physmap_of flash (normal name), and mtd1 is fsl_elbc_nand.
Despite inconsistency, with mtd name like this specifying paritions
from the kernel command line becomes a torture (though, I didn't tried
and not sure if mtdparts= can handle spaces at all). Plus, this causes
real bugs when multiple fsl_elbc_nand chips registered.
With this patch applied fsl_elbc_nand chip will have proper name:
root@b1:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00010000 "fe000000.flash"
mtd1: 02000000 00004000 "e0600000.flash"
p.s. We can't use priv->dev->bus_id as in physmap_of, because
fsl_elbc_nand pretends to be a localbus controller, so its bus_id is
"address.localbus", which is incorrect and thus will also not work
for multiple chips.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
On Tue, Mar 18, 2008 at 11:11:39AM -0500, Scott Wood wrote:
> On Tue, Mar 18, 2008 at 06:58:14PM +0300, Anton Vorontsov wrote:
> > Oops, forgot the NULL checking.
> [snip]
> > + if (priv->mtd.name)
> > + kfree(priv->mtd.name);
> > +
>
> Not needed; kfree(NULL) is a no-op.
D'oh, right. Also, we should fill the name prior to nand_scan_ident,
otherwise if error happened between nand_scan_ident and kasprintf
then we'll kfree chip's type name.
drivers/mtd/nand/fsl_elbc_nand.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index b025dfe..9c86d9b 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -974,6 +974,8 @@ static int fsl_elbc_chip_remove(struct fsl_elbc_mtd *priv)
nand_release(&priv->mtd);
+ kfree(priv->mtd.name);
+
if (priv->vbase)
iounmap(priv->vbase);
@@ -1034,6 +1036,12 @@ static int fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
goto err;
}
+ priv->mtd.name = kasprintf(GFP_KERNEL, "%x.flash", res.start);
+ if (!priv->mtd.name) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
ret = fsl_elbc_chip_init(priv);
if (ret)
goto err;
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] Add Fixed PHY support for ucc_geth
From: Vitaly Bordug @ 2008-03-18 16:32 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Tjernlund, Joakim, Netdev, linuxppc-dev@ozlabs.org,
Linuxppc-Embedded@Ozlabs.Org
In-Reply-To: <1205833615-15833-1-git-send-email-Joakim.Tjernlund@transmode.se>
On Tue, 18 Mar 2008 10:46:55 +0100
Joakim Tjernlund wrote:
> The new Fixed PHY method, fixed-link property, isn't
> impl. for ucc_geth which makes fixed PHYs non functional.
> Add support for the new method to restore the Fixed PHY
> functionality.
>
Makes sense to me, but let's cc linuxppc-devel
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
> ---
>
> This is a regression as fixed PHYs works in 2.6.23 and I am
> using it.
>
> drivers/net/ucc_geth.c | 53
> +++++++++++++++++++++++++++-------------------- 1 files changed, 30
> insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index ecc5712..18c8b39 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -3836,6 +3836,7 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma struct device_node *phy;
> int err, ucc_num, max_speed = 0;
> const phandle *ph;
> + const u32 *fixed_link;
> const unsigned int *prop;
> const char *sprop;
> const void *mac_addr;
> @@ -3926,18 +3927,38 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma
> ug_info->uf_info.regs = res.start;
> ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
> + fixed_link = of_get_property(np, "fixed-link", NULL);
> + if (fixed_link) {
> + ug_info->mdio_bus = 0;
> + ug_info->phy_address = fixed_link[0];
> + phy = NULL;
> + } else {
> + ph = of_get_property(np, "phy-handle", NULL);
> + phy = of_find_node_by_phandle(*ph);
>
> - ph = of_get_property(np, "phy-handle", NULL);
> - phy = of_find_node_by_phandle(*ph);
> + if (phy == NULL)
> + return -ENODEV;
>
> - if (phy == NULL)
> - return -ENODEV;
> + /* set the PHY address */
> + prop = of_get_property(phy, "reg", NULL);
> + if (prop == NULL)
> + return -1;
> + ug_info->phy_address = *prop;
> +
> + /* Set the bus id */
> + mdio = of_get_parent(phy);
> +
> + if (mdio == NULL)
> + return -1;
>
> - /* set the PHY address */
> - prop = of_get_property(phy, "reg", NULL);
> - if (prop == NULL)
> - return -1;
> - ug_info->phy_address = *prop;
> + err = of_address_to_resource(mdio, 0, &res);
> + of_node_put(mdio);
> +
> + if (err)
> + return -1;
> +
> + ug_info->mdio_bus = res.start;
> + }
>
> /* get the phy interface type, or default to MII */
> prop = of_get_property(np, "phy-connection-type", NULL);
> @@ -3982,20 +4003,6 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma ug_info->numThreadsRx =
> UCC_GETH_NUM_OF_THREADS_4; }
>
> - /* Set the bus id */
> - mdio = of_get_parent(phy);
> -
> - if (mdio == NULL)
> - return -1;
> -
> - err = of_address_to_resource(mdio, 0, &res);
> - of_node_put(mdio);
> -
> - if (err)
> - return -1;
> -
> - ug_info->mdio_bus = res.start;
> -
> if (netif_msg_probe(&debug))
> printk(KERN_INFO "ucc_geth: UCC%1d at 0x%8x (irq =
> %d) \n", ug_info->uf_info.ucc_num + 1, ug_info->uf_info.regs,
^ permalink raw reply
* Re: simple MPC5200B system
From: Grant Likely @ 2008-03-18 16:21 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linux-ppc list
In-Reply-To: <47DFDC5B.90304@matrix-vision.de>
On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz
<andre.schwarz@matrix-vision.de> wrote:
> I've read some discussions about the "interrupt-map" attribute of the pci
> node. I tried to follow Ben and David in their explanations - obviously I
> didn't really get it.
> Looks like there are a lot of people outside who need some enlightenment
> ... including me, of course.
>
> Maybe you can clarify this ?
>
> Taken from motionpro.dts ...
>
First, you also need to look at interrupt-map-mask to interpret these
values; from motionpro.dts:
interrupt-map-mask = <f800 0 0 7>;
which is applied to the unit interrupt specifier to figure out how to
map onto the interrupt controller. The /size/ of this field is
obtained by adding #address-cells with #interrupt-cells. (3+1=4).
'f8' refers to the upper 5 bits of the interrupt identifier which is a
number from 0-31 which relates to the IDSEL line as you guessed. The
'7' covers the lower 3 bits of the interrupt specifier which can be 1,
2, 3 or 4.
The 120 bits in the middle are irrelevant, so interrupt-map-mask
leaves them as zeros.
> interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
> c000 0 0 2 &mpc5200_pic 1 1 3
> c000 0 0 3 &mpc5200_pic 1 2 3
> c000 0 0 4 &mpc5200_pic 1 3 3
>
> c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
> c800 0 0 2 &mpc5200_pic 1 2 3
> c800 0 0 3 &mpc5200_pic 1 3 3
> c800 0 0 4 &mpc5200_pic 0 0 3>;
>
>
> First parameter seems to be the slot number, i.e. IDSEL line of the PCI
> device.
> How is this value coded ? Are these the bits 15..11 of the configuration
> address ?
I don't remember how this is encoded. On the lite5200, idsel is wired
to d0 and d1 for slots 1 and 2 respectively, yet these values suggest
slots 24 and 25. I'll need to look at this again later.
>
> 2nd + 3rd paramter : no clue ! can you explain ?
first 3 cells are the unit address and is #address-cells large. Only
the first cell contains real data.
>
> 4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only
> INT_A. Do we need 4 entries in any case ?
you only need entries for irq lines that are wired up. If your board
does not wire up _B, _C and _D, then don't have an entry for them.
However, if they are wired up then you should describe them.
>
> 5th : ok - parent pic
Correct.
>
> 6th ... 8th : IRQ representation of the parent pic, which gives :
>
> 6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins
> 7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have
> number 1..3 inside MAIN level.
> 8th : should be 3 = "level low" which is default for PCI.
Correct.
There is also some good information here:
http://playground.sun.com/1275/practice/imap/imap0_9d.pdf
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
From: Wolfgang Denk @ 2008-03-18 16:19 UTC (permalink / raw)
To: Scott Wood; +Cc: Stephen Rothwell, Heiko Schocher, linuxppc-dev
In-Reply-To: <20080318151132.GA17402@ld0162-tx32.am.freescale.net>
Dear Scott,
in message <20080318151132.GA17402@ld0162-tx32.am.freescale.net> you wrote:
>
> Well, the device tree is a mechanism for communicating from the firmware
> to the kernel, and if we could control the firmware better we'd just make
> it set the pins properly to begin with. :-)
Is this just a comment, or do you oppose Heiko's suggestion?
Other uses of the device tree seem possible and reasonable, too. For
example, we can use the device tree to configure the firmware (U-Boot
in this case).
Using the device tree to describe the pin configuration of the
hardware sounds easier to me than hard-coding it in some source (or
header) file - no matter if this is in the kernel and/or in the
firmware.
What do you think?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A quarrel is quickly settled when deserted by one party; there is no
battle unless there be two. - Seneca
^ permalink raw reply
* Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
From: Vitaly Bordug @ 2008-03-18 16:19 UTC (permalink / raw)
To: hs; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <47DF777E.2030103@denx.de>
On Tue, 18 Mar 2008 09:04:14 +0100
Heiko Schocher wrote:
> Hello Stephen,
>
> Stephen Rothwell wrote:
> > On Tue, 18 Mar 2008 08:13:06 +0100 Heiko Schocher <hs@denx.de>
> > wrote:
> >> Stephen Rothwell wrote:
> >>> On Fri, 14 Mar 2008 10:24:30 +0100 Heiko Schocher <hs@denx.de>
> >>> wrote:
> >> [...]
> >>>> +struct cpm_pin {
> >>>> + int port, pin, flags;
> >>>> +};
> >>> I wish someone would consolidate all these definitions of cpm_pin.
> >> Hmm... do you mean something like, moving this struct
> >> in cpm1.h and ...
> >
> > Yes or somewhere else appropriate.
> >
> >>>> + for (i = 0; i < ARRAY_SIZE(mgsuvd_pins); i++) {
> >>>> + struct cpm_pin *pin = &mgsuvd_pins[i];
> >>>> + cpm1_set_pin(pin->port, pin->pin, pin->flags);
> >>>> + }
> >>> And the code that uses them ...
> >> making in arch/powerpc/sysdev/cpm1.c a function
> >> cpm1_setup_pins (struct cpm_pin *pins) ?
> >
> > Yes.
> >
> > This is not necessary for your patch, but would be a nice cleanup
> > later. N.B. this struct is alos used by users of cpm2_set_pin().
>
> OK. Another thought about this. Shouldnt this table go in the dts?
> A device node like
>
> cpm_pin {
> pins = <port pin flags>;
> };
>
> would be nice, or?
>
This has been a disputable question some time ago, and decided (or it looks like decided) that devtree describes hardware, and not the way it is configured at the moment. Therefor, best way for pin stuff is considered, as Scott mentioned, to set up stuff inside the firmware.
-Vitaly
> bye,
> Heiko
>
^ permalink raw reply
* Re: [PATCH v2] fsl_elbc_nand: fix mtd name
From: Scott Wood @ 2008-03-18 16:11 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20080318155814.GA5223@localhost.localdomain>
On Tue, Mar 18, 2008 at 06:58:14PM +0300, Anton Vorontsov wrote:
> Oops, forgot the NULL checking.
[snip]
> + if (priv->mtd.name)
> + kfree(priv->mtd.name);
> +
Not needed; kfree(NULL) is a no-op.
-Scott
^ permalink raw reply
* Re: [BUG]2.6.25-rc6:Unable to handle kernel paging request
From: Michael Neuling @ 2008-03-18 16:04 UTC (permalink / raw)
To: skumar; +Cc: Poornima Nayak, linuxppc-dev, akpm, linux-kernel
In-Reply-To: <20080318052921.GA32259@in.ibm.com>
In message <20080318052921.GA32259@in.ibm.com> you wrote:
> Hi,
> I found the following bug at kernel boot up on my power machine
> with 2.6.25-rc6 kernel.
>
> USB Mass Storage support registered.
> mice: PS/2 mouse device common for all mice
> Unable to handle kernel paging request for data at address
> 0xd00008000000002e
> Faulting instruction address: 0xc00000000074ded8
> cpu 0x0: Vector: 300 (Data Access) at [c00000003e073aa0]
> pc: c00000000074ded8: .f71805f_find+0x44/0x32c
> lr: c00000000074e1f8: .f71805f_init+0x38/0x194
> sp: c00000003e073d20
> msr: 8000000000009032
> dar: d00008000000002e
> dsisr: 42000000
> current = 0xc0000000220851c0
> paca = 0xc0000000007c2700
> pid = 1, comm = swapper
> enter ? for help
> [c00000003e073dc0] c00000000074e1f8 .f71805f_init+0x38/0x194
> [c00000003e073ea0] c000000000724bdc .kernel_init+0x204/0x3c8
> [c00000003e073f90] c000000000025df4 .kernel_thread+0x4c/0x68
Is this an all yes or random config? CONFIG_SENSORS_F71805F doesn't
appear in any of the powerpc def configs.
Anyway, I'm guessing the driver hasn't checked the device tree and is
probing somewhere it shouldn't.
Mikey
>
> For further reference some of the debug info is:
> 0:mon> r
> R00 = d00008000000002e R16 = 4000000001c00000
> R01 = c00000003e073d20 R17 = c00000000066ecc8
> R02 = c0000000008f4458 R18 = 0000000000000000
> R03 = 000000000000002e R19 = 00000000003a1000
> R04 = c00000003e073e30 R20 = 000000000235a3d0
> R05 = c00000003e073e34 R21 = c00000000075a3d0
> R06 = 0000000024000044 R22 = 000000000235a640
> R07 = c000000000010bcc R23 = c00000000075a640
> R08 = c00000003e073570 R24 = c00000000066fe90
> R09 = d000080000000000 R25 = 0000000000000000
> R10 = cf000000009c2d60 R26 = c00000003e070000
> R11 = ffffffffffffff87 R27 = c00000003e073e30
> R12 = 0000000000000000 R28 = c00000003e073e34
> R13 = c0000000007c2700 R29 = 000000000000002e
> R14 = 0000000000000000 R30 = c000000000880278
> R15 = c000000000670448 R31 = c00000000078e050
> pc = c00000000074ded8 .f71805f_find+0x44/0x32c
> lr = c00000000074e1f8 .f71805f_init+0x38/0x194
> msr = 8000000000009032 cr = 24000042
> ctr = c00000000074e1c0 xer = 0000000000000005 trap = 300
> dar = d00008000000002e dsisr = 42000000
>
> 0:mon> e
> cpu 0x0: Vector: 300 (Data Access) at [c00000003e073aa0]
> pc: c00000000074ded8: .f71805f_find+0x44/0x32c
> lr: c00000000074e1f8: .f71805f_init+0x38/0x194
> sp: c00000003e073d20
> msr: 8000000000009032
> dar: d00008000000002e
> dsisr: 42000000
> current = 0xc0000000220851c0
> paca = 0xc0000000007c2700
> pid = 1, comm = swapper
>
> 0:mon> di %pc
> c00000000074ded8 7d6919ae stbx r11,r9,r3
> c00000000074dedc 39000001 li r8,1
> c00000000074dee0 990d01dc stb r8,476(r13)
> c00000000074dee4 e93f0000 ld r9,0(r31)
> c00000000074dee8 7c034a14 add r0,r3,r9
> c00000000074deec 7c0004ac sync
> c00000000074def0 7d6919ae stbx r11,r9,r3
> c00000000074def4 990d01dc stb r8,476(r13)
> c00000000074def8 38800023 li r4,35
> c00000000074defc 4bcc95e1 bl c0000000004174dc #
> .superio_inw+0x0/0x134
> c00000000074df00 3940ffed li r10,-19
> c00000000074df04 5463043e clrlwi r3,r3,16
> c00000000074df08 2f831934 cmpwi cr7,r3,6452
> c00000000074df0c 409e0260 bne cr7,c00000000074e16c #
> .f71805f_find+0x2d8/0x32c
> c00000000074df10 e93e8038 ld r9,-32712(r30)
> c00000000074df14 a0690000 lhz r3,0(r9)
> 0:mon>
>
> Thanks
> Sudhir Kumar
> ISTL, IBM
> Bangalore
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox