* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Anton Vorontsov @ 2008-04-17 16:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <48077748.1040001@freescale.com>
On Thu, Apr 17, 2008 at 11:14:00AM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
>> This isn't a timer with usec precision! This is a timer that silently
>> crops precision as it wants to. Ahh, I see you dropped "u" prefix.
>
> It is a timer with usec precision, unless you ask for a timeout of more
> than 65535 usec -- at which point the hardware can't provide usec
> precision.
>
> And s/as it wants to/as it needs to/.
>
>> Well. I'm not going to use it anyway, so just give it some name you
>> prefer and I'll wrap it into the patch. Preferably, drop a line here with
>> kerneldoc for it, so I'll not have to document its drawbacks. :-)
>
> /**
> * gtm_reset_timer16 - reset 16 bit timer with arbitrary precision
> * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
> * @usec: timer interval in microseconds
> * @reload: if set, the timer will reset upon expiry rather than
> * continue running free.
> *
> * This function (re)sets the GTM timer so that it counts up to the
> * requested interval value, and fires the interrupt when the value is
> * reached. This function will reduce the precision of the timer as
> * needed in order for the requested timeout to fit in a 16-bit
> * register.
> */
> int gtm_reset_timer16(struct gtm_timer *tmr, unsigned long usec,
> bool reload)
> {
> ...
> }
Thanks!
>>> It could be made faster using cntlzw.
>>
>> No need to cntlzw, there is fls() already.
>
> fls() uses cntlzw, does it not? I was just too lazy to look up what
> Linux calls it. :-)
Yup, I looked it up. ;-)
>> Though, here you'll need two because of u64.
>
> We can probably get away with 32 bits.
>
>> Btw, I hope you aware that single GTM timer running at 166MHz will give you
>> 6 minutes of sleep, maximum.
>
> Yes, but it's all we have on-chip that can do the job.
>
>> With cascaded timer you'll get much better
>> result of 310 days. Is that possible to use cascaded timer as a wakeup
>> event on 8313?
>
> No, unfortunately. Only timer4 can be a wakeup source, and when
> cascaded, timer4 is the input to timer3, rather than the other way
> around.
Ok, very well.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [EFIKA] Really, don't pretend to be CHRP
From: David Woodhouse @ 2008-04-17 16:37 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, paulus
In-Reply-To: <48076A00.1080608@genesi-usa.com>
On Thu, 2008-04-17 at 16:17 +0100, Matt Sealey wrote:
> David Woodhouse wrote:
> > On Thu, 2008-04-17 at 13:28 +0100, Matt Sealey wrote:
> >> I thought we were using efika.forth for this in Fedora.
> >
> > We were, until you pointed out that the kernel actually works just fine
> > these days without it.
>
> I said the kernel has had braindead patches shoved into it that sort of
> obviate the need for the most heinous of crimes committed in the Efika
> device tree.
:)
> The Linux kernel fixups don't add the CDM or XLB arbiter or many other
> components some out-of-mainline drivers
I don't give a monkey's left testicle about code which isn't mainline.
If and when it's merged, we can make sure the device-tree fixups are
sufficient for it -- by whatever means.
> > can't set environment variables from within Linux (and yes, we can
> > probably improve on that too, but we let them setenv for themselves, for
> > now).
>
> You really won't be improving on it because there's no reliable way to
> pass setenv back to the firmware from userland :D
Except by putting it in a text file which is booted instead of yaboot,
the first time after install. The user just types 'boot hd:,\fixme.fth'
instead of having to set the variables manually.
> My ideal situation is all this stuff is stripped from the kernel. You do
> realise 90% of the Efika traffic on this list is submitting code that
> fixes fixups for a firmware which has a seperated fixup script, putting
> the responsibility firmly where Linux-PPC policy dictated it should be
> (with the firmware).
The fixup script is a fairly unwieldy hack for a distribution to try to
support. It turns our release/install notes for Efika from a few lines
of "Efika firmware is a bit crap" into twice as many lines of "Efika
firmware is entirely crap".
> I think it's stunting the development of the platform. In lieu of a
> real, solid, flashable firmware update that fixes the problems,
Bored now. Quit whining and give us a real, solid, flashable firmware
update that fixes the problems. Really.
> I don't think patching the Linux kernel is the correct solution, and I
> do not appreciate the 180 degree turn that Linux-PPC policy has taken
> with this.
> If we could not commit fixes for it in the beginning and were lambasted
> for shoving firmware bugfixes into the kernel, how should it be so
> different now?
Haven't we covered this? We were originally promised a firmware update
which would fix all this, about a year ago. It was quite reasonable at
the time to wait for it and avoid putting the hacks in the kernel.
Now we've come to the conclusion that it isn't going to happen, it's
also quite reasonable to change tack and work around it.
If there was a chance of policy, it was because we were promised
something which didn't appear.
> You do realise that once the fixes are in the kernel *you may never
> see another firmware update*? There'll be no point..
Except to fix the off-by-one problems and various other breakages other
than the device-tree, perhaps. But I thought we'd already reached the
conclusion that we may never see another firmware update?
OTOH, it probably wouldn't be _so_ hard to port Mitch's OpenFirmware to
mpc5200...
--
dwmw2
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Scott Wood @ 2008-04-17 16:22 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
On Thu, Apr 17, 2008 at 04:39:04AM +1000, Anton Vorontsov wrote:
> +#define GTMDR_FFR (1 << 3)
This should be GTMDR_FRR according to the chip docs.
-Scott
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Scott Wood @ 2008-04-17 16:14 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080417150755.GA29239@polina.dev.rtsoft.ru>
Anton Vorontsov wrote:
> This isn't a timer with usec precision! This is a timer that silently
> crops precision as it wants to. Ahh, I see you dropped "u" prefix.
It is a timer with usec precision, unless you ask for a timeout of more
than 65535 usec -- at which point the hardware can't provide usec precision.
And s/as it wants to/as it needs to/.
> Well. I'm not going to use it anyway, so just give it some name you
> prefer and I'll wrap it into the patch. Preferably, drop a line here with
> kerneldoc for it, so I'll not have to document its drawbacks. :-)
/**
* gtm_reset_timer16 - reset 16 bit timer with arbitrary precision
* @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
* @usec: timer interval in microseconds
* @reload: if set, the timer will reset upon expiry rather than
* continue running free.
*
* This function (re)sets the GTM timer so that it counts up to the
* requested interval value, and fires the interrupt when the value is
* reached. This function will reduce the precision of the timer as
* needed in order for the requested timeout to fit in a 16-bit
* register.
*/
int gtm_reset_timer16(struct gtm_timer *tmr, unsigned long usec,
bool reload)
{
...
}
>> It could be made faster using cntlzw.
>
> No need to cntlzw, there is fls() already.
fls() uses cntlzw, does it not? I was just too lazy to look up what
Linux calls it. :-)
> Though, here you'll need two because of u64.
We can probably get away with 32 bits.
> Btw, I hope you aware that single GTM timer running at 166MHz will give you
> 6 minutes of sleep, maximum.
Yes, but it's all we have on-chip that can do the job.
> With cascaded timer you'll get much better
> result of 310 days. Is that possible to use cascaded timer as a wakeup
> event on 8313?
No, unfortunately. Only timer4 can be a wakeup source, and when
cascaded, timer4 is the input to timer3, rather than the other way around.
-Scott
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Anton Vorontsov @ 2008-04-17 16:12 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <200804171624.02769.laurentp@cse-semaphore.com>
On Thu, Apr 17, 2008 at 04:23:56PM +0200, Laurent Pinchart wrote:
> > + /*
> > + * We have two 8 bit prescalers -- primary and secondary (psr, sps),
> > + * plus "slow go" mode (clk / 16). So, total prescale value is
> > + * 16 * (psr + 1) * (sps + 1).
> > + */
> > + if (prescaler > 256 * 256 * 16)
> > + return -EINVAL;
> > +
> > + if (prescaler > 256 * 256) {
> > + iclk = GTMDR_ICLK_SLGO;
> > + prescaler /= 16;
> > + }
> > +
> > + if (prescaler > 256) {
> > + psr = 256 - 1;
> > + sps = prescaler / 256 - 1;
> > + } else {
> > + psr = prescaler - 1;
> > + sps = 1 - 1;
> > + }
>
> Don't forget that the CPM2 doesn't support the primary prescaler.
Here is incremental diff of how this is solved. I guess this should work.
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index b0ddd54..b89c56d 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2835,7 +2835,7 @@ platforms are moved over to use the flattened-device-tree model.
Required properties:
- compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
- GTMs).
+ GTMs or "fsl,cpm2-gtm" for CPM2 GTMs).
- reg : should contain gtm registers location and length (0x40).
- interrupts : should contain four interrupts.
- interrupt-parent : interrupt source phandle.
diff --git a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
index 6d86983..105c633 100644
--- a/arch/powerpc/sysdev/fsl_gtm.c
+++ b/arch/powerpc/sysdev/fsl_gtm.c
@@ -125,27 +125,32 @@ static int gtm_reset_ref_timer16(struct gtm_timer *tmr, int frequency,
u8 psr;
u8 sps;
unsigned long flags;
+ int max_prescaler = 256 * 256 * 16;
+
+ /* CPM2 doesn't have primary prescaler */
+ if (!tmr->gtpsr)
+ max_prescaler /= 256;
prescaler = gtm->clock / frequency;
/*
* We have two 8 bit prescalers -- primary and secondary (psr, sps),
* plus "slow go" mode (clk / 16). So, total prescale value is
- * 16 * (psr + 1) * (sps + 1).
+ * 16 * (psr + 1) * (sps + 1). Though, for CPM2 GTMs we losing psr.
*/
- if (prescaler > 256 * 256 * 16)
+ if (prescaler > max_prescaler)
return -EINVAL;
- if (prescaler > 256 * 256) {
+ if (prescaler > max_prescaler / 16) {
iclk = GTMDR_ICLK_SLGO;
prescaler /= 16;
}
- if (prescaler > 256) {
+ if (prescaler <= 256) {
+ psr = 0;
+ sps = prescaler - 1;
+ } else {
psr = 256 - 1;
sps = prescaler / 256 - 1;
- } else {
- psr = prescaler - 1;
- sps = 1 - 1;
}
spin_lock_irqsave(>m->lock, flags);
@@ -159,7 +164,8 @@ static int gtm_reset_ref_timer16(struct gtm_timer *tmr, int frequency,
setbits8(tmr->gtcfr, GTCFR_STP(num));
- out_be16(tmr->gtpsr, psr);
+ if (tmr->gtpsr)
+ out_be16(tmr->gtpsr, psr);
clrsetbits_be16(tmr->gtmdr, 0xFFFF, iclk | GTMDR_SPS(sps) |
GTMDR_ORI | (free_run ? GTMDR_FFR : 0));
out_be16(tmr->gtcnr, 0);
@@ -222,7 +228,8 @@ void gtm_stop_timer16(struct gtm_timer *tmr)
}
EXPORT_SYMBOL(gtm_stop_timer16);
-static void __init gtm_set_shortcuts(struct gtm_timer *timers,
+static void __init gtm_set_shortcuts(struct device_node *np,
+ struct gtm_timer *timers,
struct gtm_timers_regs __iomem *regs)
{
/*
@@ -233,31 +240,35 @@ static void __init gtm_set_shortcuts(struct gtm_timer *timers,
*/
timers[0].gtcfr = ®s->gtcfr1;
timers[0].gtmdr = ®s->gtmdr1;
- timers[0].gtpsr = ®s->gtpsr1;
timers[0].gtcnr = ®s->gtcnr1;
timers[0].gtrfr = ®s->gtrfr1;
timers[0].gtevr = ®s->gtevr1;
timers[1].gtcfr = ®s->gtcfr1;
timers[1].gtmdr = ®s->gtmdr2;
- timers[1].gtpsr = ®s->gtpsr2;
timers[1].gtcnr = ®s->gtcnr2;
timers[1].gtrfr = ®s->gtrfr2;
timers[1].gtevr = ®s->gtevr2;
timers[2].gtcfr = ®s->gtcfr2;
timers[2].gtmdr = ®s->gtmdr3;
- timers[2].gtpsr = ®s->gtpsr3;
timers[2].gtcnr = ®s->gtcnr3;
timers[2].gtrfr = ®s->gtrfr3;
timers[2].gtevr = ®s->gtevr3;
timers[3].gtcfr = ®s->gtcfr2;
timers[3].gtmdr = ®s->gtmdr4;
- timers[3].gtpsr = ®s->gtpsr4;
timers[3].gtcnr = ®s->gtcnr4;
timers[3].gtrfr = ®s->gtrfr4;
timers[3].gtevr = ®s->gtevr4;
+
+ /* CPM2 doesn't have primary prescaler */
+ if (!of_device_is_compatible(np, "fsl,cpm2-gtm")) {
+ timers[0].gtpsr = ®s->gtpsr1;
+ timers[1].gtpsr = ®s->gtpsr2;
+ timers[2].gtpsr = ®s->gtpsr3;
+ timers[3].gtpsr = ®s->gtpsr4;
+ }
}
static int __init gtm_init(void)
@@ -307,7 +318,7 @@ static int __init gtm_init(void)
goto err;
}
- gtm_set_shortcuts(gtm->timers, gtm->regs);
+ gtm_set_shortcuts(np, gtm->timers, gtm->regs);
/* We don't want to lose the node and its ->data */
of_node_get(np);
^ permalink raw reply related
* Re: Warp patches for 2.6.26
From: Dale Farnsworth @ 2008-04-17 16:08 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080417115045.7e4e6b1e@lappy.seanm.ca>
On Thu, Apr 17, 2008 at 11:50:45AM -0400, Sean MacLennan wrote:
> On Sat, 12 Apr 2008 20:13:16 -0700
> "Dale Farnsworth" <dale@farnsworth.org> wrote:
>
> > Each patch needs to be standalone. you need to add a header
> > describing what the patch is intended to accomplish. Being more
> > descriptive is better than less. Also, as Stephen said, make sure
> > that the subject of each email containing a patch is descriptive and
> > reasonably unique within the entire kernel.
>
> Splitting up the patches would be very error prone. I would have to
> basically do all the editing by hand.
I didn't suggest splitting the patches or further modification of the
patches themselves. What I found lacking were the patch descriptions.
You need to describe in each patch (commit) commentary exactly what
the patch is intended to accomplish, and the rationale behind it.
> I also think I am not being clear enough. Basically what is currently
> in the mainline is platform code for a Rev A board with minimal FPGA
> functionality, since that is what we had at the time.
>
> These patches, I should probably merge them into one patch, bring the
> platform code up to a Rev B board with a more complete FPGA load. (I
> say more complete because FPGA loads are never complete ;)
>
> These patches only affect the Warp. Ignoring the LED and WDT patches,
> you have to have all the changes to get a working Rev B. You can't just
> put in the DTM changes or just put in the NAND changes.
>
> I listed 8 changes, but three are for NAND, and four are for DTM. I
> could compress them down:
>
> Updated platform code to support Rev B boards.
> * Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
> * Fully functional DTM.
> * Added POST information.
> * Removed LED function, moved to new LED driver.
>
> Now, the POST function and the removed LED function could be separate
> patches I guess, but it hardly seems worth it. The LED function was
> never used except in temporary debug code.
>
> > For example, instead of "WDT driver", as a minimum something like:
> > "[POWERPC] warp: Add WDT driver".
>
> Ok, that I can do.
-Dale
^ permalink raw reply
* RE: Xilinx network trouble
From: Rick Moleres @ 2008-04-17 15:56 UTC (permalink / raw)
To: Guillaume Dargaud, linuxppc-dev
In-Reply-To: <03fc01c8a072$67280110$ad289e86@LPSC0173W>
Which version of xps_ll_temac are you using, and which version of EDK?
Also, do both designs meet timing?
-Rick
-----Original Message-----
From: linuxppc-dev-bounces+moleres=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-bounces+moleres=3Dxilinx.com@ozlabs.org] On Behalf =
Of
Guillaume Dargaud
Sent: Thursday, April 17, 2008 4:04 AM
To: linuxppc-dev@ozlabs.org
Subject: Xilinx network trouble
Our network guru is out on vacation, so I'll ask here...
I now have a working Xilinx ML405 board... except the network is flaky
to=20
say the least.
I have tried both with the Emac Lite and the LLTemac IPs.
They both work during the DHCP state of the kernel boot, my target board
gets its IP and network parameters alright from the host DHCP server.
The Emac Lite can ping both ways, but with 500ms and 30% packet loss
when=20
pinging from the host PC and 300ms and 70% packet loss the other way.
And it=20
goes in hiccups: 30s or so with no pings, and then 30s or so with 90%=20
success... RX/TX LEDs also are dark when there's nothing going on.
When using the LLTemac, ping just doesn't work.
ifconfig shows no drops and no collisions in both cases.
I'm no network specialist so I don't know what kind of tools I can use
for=20
further diagnosis.
Here are some of the relevant kernel options I've set for both=20
configurations:
$ egrep "EMAC|NET|XILINX|NFS" .config | egrep -v "^#|^$"
CONFIG_XILINX_ML405=3Dy
CONFIG_XILINX_MLxxx=3Dy
CONFIG_XILINX_VIRTEX_4_FX=3Dy
CONFIG_XILINX_VIRTEX=3Dy
CONFIG_XILINX_EMBED_CONFIG=3Dy
CONFIG_NET=3Dy
CONFIG_INET=3Dy
CONFIG_INET_DIAG=3Dy
CONFIG_INET_TCP_DIAG=3Dy
CONFIG_XILINX_SYSACE=3Dy
CONFIG_XILINX_DRIVERS=3Dy
CONFIG_NEED_XILINX_IPIF=3Dy
CONFIG_NETDEVICES=3Dy
CONFIG_NET_ETHERNET=3Dy
CONFIG_XILINX_EMACLITE=3Dy
CONFIG_XILINX_GPIO=3Dy
CONFIG_XILINX_HWICAP=3Dy
CONFIG_XILINX_IIC=3Dy
CONFIG_XILINX_EDK=3Dy
CONFIG_NETWORK_FILESYSTEMS=3Dy
CONFIG_NFS_FS=3Dy
CONFIG_NFS_V3=3Dy
CONFIG_ROOT_NFS=3Dy
CONFIG_NFS_COMMON=3Dy
or:
CONFIG_XILINX_ML405=3Dy
CONFIG_XILINX_MLxxx=3Dy
CONFIG_XILINX_VIRTEX_4_FX=3Dy
CONFIG_XILINX_VIRTEX=3Dy
CONFIG_XILINX_EMBED_CONFIG=3Dy
CONFIG_NET=3Dy
CONFIG_INET=3Dy
CONFIG_INET_DIAG=3Dy
CONFIG_INET_TCP_DIAG=3Dy
CONFIG_XILINX_SYSACE=3Dy
CONFIG_XILINX_DRIVERS=3Dy
CONFIG_NEED_XILINX_LLDMA=3Dy
CONFIG_NETDEVICES=3Dy
CONFIG_NETDEV_1000=3Dy
CONFIG_XILINX_LLTEMAC=3Dy
CONFIG_XILINX_LLTEMAC_MARVELL_88E1111_GMII=3Dy
CONFIG_XILINX_GPIO=3Dy
CONFIG_XILINX_HWICAP=3Dy
CONFIG_XILINX_IIC=3Dy
CONFIG_XILINX_EDK=3Dy
CONFIG_NETWORK_FILESYSTEMS=3Dy
CONFIG_NFS_FS=3Dy
CONFIG_NFS_V3=3Dy
CONFIG_ROOT_NFS=3Dy
CONFIG_NFS_COMMON=3Dy
Thanks for any hint.
--=20
Guillaume Dargaud
http://www.gdargaud.net/
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Sean MacLennan @ 2008-04-17 15:50 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <E1Jksea-0001ba-DL@xyzzy.farnsworth.org>
On Sat, 12 Apr 2008 20:13:16 -0700
"Dale Farnsworth" <dale@farnsworth.org> wrote:
> Each patch needs to be standalone. you need to add a header
> describing what the patch is intended to accomplish. Being more
> descriptive is better than less. Also, as Stephen said, make sure
> that the subject of each email containing a patch is descriptive and
> reasonably unique within the entire kernel.
Splitting up the patches would be very error prone. I would have to
basically do all the editing by hand.
I also think I am not being clear enough. Basically what is currently
in the mainline is platform code for a Rev A board with minimal FPGA
functionality, since that is what we had at the time.
These patches, I should probably merge them into one patch, bring the
platform code up to a Rev B board with a more complete FPGA load. (I
say more complete because FPGA loads are never complete ;)
These patches only affect the Warp. Ignoring the LED and WDT patches,
you have to have all the changes to get a working Rev B. You can't just
put in the DTM changes or just put in the NAND changes.
I listed 8 changes, but three are for NAND, and four are for DTM. I
could compress them down:
Updated platform code to support Rev B boards.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Fully functional DTM.
* Added POST information.
* Removed LED function, moved to new LED driver.
Now, the POST function and the removed LED function could be separate
patches I guess, but it hardly seems worth it. The LED function was
never used except in temporary debug code.
> For example, instead of "WDT driver", as a minimum something like:
> "[POWERPC] warp: Add WDT driver".
Ok, that I can do.
Cheers,
Sean
^ permalink raw reply
* Re: RFC: MPC5200 PSC AC97 driver
From: Sergei Shtylyov @ 2008-04-17 15:46 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev
In-Reply-To: <4807701F.9030105@genesi-usa.com>
Matt Sealey wrote:
>>>> + /* the fifo starts right after psc ends */
>>>> + priv->fifo = (struct mpc52xx_psc_fifo*)&priv->psc[1]; /*
>>>> FIXME */
>>> Wouldn't
>>> priv->fifo = (struct mpc52xx_psc_fifo*) (priv->psc + sizeof(struct
>>> mpc52xx_psc));
>>> Be a little less obtuse use of C?
>> "priv->psc" is of type "struct mpc52xx_ac97_priv*". If I add 0x58 to
>> it, wouldn't I add 0x58 times the size of "struct mpc52xx_ac97_priv"?
> I always got a result of MBAR+PSC_OFFSET(n)+0x58 out of it as I expected.
> priv->psc is of type struct mpc52xx_psc * which means it's just pointer
> arithmetic. If you add a value to it (not increment or so as if it's
> an array) then it just adds the value, no?
Of course no -- that'll be pointer arithmetic unless you cast the pointer
to an integer type.
WBR, Sergei
^ permalink raw reply
* Re: RFC: MPC5200 PSC AC97 driver
From: Matt Sealey @ 2008-04-17 15:43 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200804171723.27002.jbe@pengutronix.de>
Juergen Beisert wrote:
> On Thursday 17 April 2008 17:10, Matt Sealey wrote:
>> Juergen Beisert wrote:
>>> Hi,
>>> + /* the fifo starts right after psc ends */
>>> + priv->fifo = (struct mpc52xx_psc_fifo*)&priv->psc[1]; /* FIXME */
>> Wouldn't
>>
>> priv->fifo = (struct mpc52xx_psc_fifo*) (priv->psc + sizeof(struct
>> mpc52xx_psc));
>>
>> Be a little less obtuse use of C?
>
> "priv->psc" is of type "struct mpc52xx_ac97_priv*". If I add 0x58 to it,
> wouldn't I add 0x58 times the size of "struct mpc52xx_ac97_priv"?
I always got a result of MBAR+PSC_OFFSET(n)+0x58 out of it as I expected.
priv->psc is of type struct mpc52xx_psc * which means it's just pointer
arithmetic. If you add a value to it (not increment or so as if it's
an array) then it just adds the value, no?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: XLlTemac soft lockup BUG
From: Brian Silverman @ 2008-04-17 15:20 UTC (permalink / raw)
To: Hugo Villeneuve; +Cc: linuxppc-embedded
In-Reply-To: <42848A5C5A0D1E47B026E644DD49B08E025AA69F@mail>
[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]
Hugo,
We have a design with the BCM5482, and will be trying it out shortly.
Any chance you could post a patch of your BCM5466 mods?
-bri
Hugo Villeneuve wrote:
> linuxppc-embedded-bounces+hugo.villeneuve=lyrtech.com@ozlabs.org wrote:
>
>> Hi all,
>>
>> I am trying to switch my design from the PLB Temac to the local link
>> temac, and i have a problem when trying to run ifconfig in my init
>> script. It gives me a BUG: soft lockup - CPU#0 stuck for 11s!
>> [ifconfig:208] Here is the rest of the dump, thanks for your help in
>> advance. [ 233.114960] eth0: XLlTemac: Options: 0x3fa
>>
>> [ 233.118449] eth0: XLlTemac: allocating interrupt 8 for fifo mode.
>>
>> [ 237.135029] eth0: XLlTemac: We renegotiated the speed to: 100
>>
>> [ 237.150339] eth0: XLlTemac: speed set to 100Mb/s
>>
>> [ 244.792140] BUG: soft lockup - CPU#0 stuck for 11s! [ifconfig:204]
>>
>
> Hi,
> we had a similar error message, which was caused by us selecting the wrong PHY type in the kernel configuration menu (latest linux-2.6-xlnx-git tree). In fact, we had to modify the lltemac driver to support our PHY (BCM5466). Once we did that, the error message went away.
>
> Hugo V.
>
>
> Hugo Villeneuve
> Hardware developer | Concepteur matériel
> Lyrtech
> Phone/Tél. : (1) (418) 877-4644 #2395
> Toll-free/Sans frais - Canada & USA : (1) (888) 922-4644 #2395
> Fax/Téléc. : (1) (418) 877-7710
> www.lyrtech.com
> Infinite possibilities...TM
>
> THIS MESSAGE AND ALL ATTACHED DOCUMENTS ARE EXCLUSIVELY INTENDED
> TO THE INDICATED RECIPIENTS AND ITS CONTENTS MAY BE CONFIDENTIAL.
> IT IS STRICTLY FORBIDDEN TO ANYONE TO TAKE COGNIZANCE, USE, OR
> DIVULGE THE INFORMATION CONTAINED HEREIN. IF YOU MISTAKENLY
> RECEIVE THIS MESSAGE, IMMEDIATELY INFORM LYRTECH AND DESTROY THE
> MESSAGE AND ATTACHMENTS FORTHWITH.THANK YOU.
>
> LE PRESENT MESSAGE ET LES DOCUMENTS QUI Y SONT JOINTS S'ADRESSENT
> EXCLUSIVEMENT AU(X)DESTINATAIRE(S) INDIQUE(S) ET LEUR TENEUR PEUT
> ETRE CONFIDENTIELLE. IL EST STRICTEMENT INTERDIT A QUICONQUE D'EN
> PRENDRE CONNAISSANCE, DE LES UTILISER OU DE LES DIVULGUER. SI
> VOUS RECEVEZ LE PRESENT MESSAGE PAR ERREUR, VEUILLEZ EN AVISER
> LYRTECH IMMEDIATEMENT ET DETRUIRE LE MESSAGE SEANCE TENANTE,
> AINSI QUE LES DOCUMENTS QUI Y SONT JOINTS.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Brian Silverman
Concept X, LLC
[-- Attachment #2: Type: text/html, Size: 3295 bytes --]
^ permalink raw reply
* Re: RFC: MPC5200 PSC AC97 driver
From: Juergen Beisert @ 2008-04-17 15:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4807673B.1010608@genesi-usa.com>
On Thursday 17 April 2008 17:05, Matt Sealey wrote:
> > + help
> > + Say Y or M if you want to support any AC97 codec attached to
> > + the Freescqle MPC52xx AC97 interface.
>
> Also this; Freescale :)
yes. ;-)
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=C2=A0Pengutronix - Linux Solutions for Science and Industry
=C2=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=C2=A0 =C2=A0 =C2=A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: RFC: MPC5200 PSC AC97 driver
From: Juergen Beisert @ 2008-04-17 15:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4807684C.4000508@genesi-usa.com>
On Thursday 17 April 2008 17:10, Matt Sealey wrote:
> Juergen Beisert wrote:
> > Hi,
> > + /* the fifo starts right after psc ends */
> > + priv->fifo =3D (struct mpc52xx_psc_fifo*)&priv->psc[1]; /* FIXME */
>
> Wouldn't
>
> priv->fifo =3D (struct mpc52xx_psc_fifo*) (priv->psc + sizeof(struct
> mpc52xx_psc));
>
> Be a little less obtuse use of C?
"priv->psc" is of type "struct mpc52xx_ac97_priv*". If I add 0x58 to it,=20
wouldn't I add 0x58 times the size of "struct mpc52xx_ac97_priv"?
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=C2=A0Pengutronix - Linux Solutions for Science and Industry
=C2=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=C2=A0 =C2=A0 =C2=A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [EFIKA] Really, don't pretend to be CHRP
From: Matt Sealey @ 2008-04-17 15:17 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus
In-Reply-To: <1208443057.9212.250.camel@pmac.infradead.org>
David Woodhouse wrote:
> On Thu, 2008-04-17 at 13:28 +0100, Matt Sealey wrote:
>> I thought we were using efika.forth for this in Fedora.
>
> We were, until you pointed out that the kernel actually works just fine
> these days without it.
I said the kernel has had braindead patches shoved into it that sort of
obviate the need for the most heinous of crimes committed in the Efika
device tree.
The Linux kernel fixups don't add the CDM or XLB arbiter or many other
components some out-of-mainline drivers will need (and should be able
to just access without writing a fixup first) to map to work properly.
Adding these will clean up things like the UART module, Sylvain's sleep
patches will work on Efika, etc.
> can't set environment variables from within Linux (and yes, we can
> probably improve on that too, but we let them setenv for themselves, for
> now).
You really won't be improving on it because there's no reliable way to
pass setenv back to the firmware from userland :D
> That might be a little cleaner than what we have at the moment, yes. But
> what we have also works, so I'd rather concentrate on things like
> getting audio support merged, before we faff around with what are
> essentially cosmetics.
My ideal situation is all this stuff is stripped from the kernel. You do
realise 90% of the Efika traffic on this list is submitting code that
fixes fixups for a firmware which has a seperated fixup script, putting
the responsibility firmly where Linux-PPC policy dictated it should be
(with the firmware).
I think it's stunting the development of the platform. In lieu of a
real, solid, flashable firmware update that fixes the problems, I don't
think patching the Linux kernel is the correct solution, and I do not
appreciate the 180 degree turn that Linux-PPC policy has taken with this.
If we could not commit fixes for it in the beginning and were lambasted
for shoving firmware bugfixes into the kernel, how should it be so
different now?
You do realise that once the fixes are in the kernel *you may never see
another firmware update*? There'll be no point..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Anton Vorontsov @ 2008-04-17 15:13 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <200804171624.02769.laurentp@cse-semaphore.com>
On Thu, Apr 17, 2008 at 04:23:56PM +0200, Laurent Pinchart wrote:
[...]
> > + /*
> > + * We have two 8 bit prescalers -- primary and secondary (psr, sps),
> > + * plus "slow go" mode (clk / 16). So, total prescale value is
> > + * 16 * (psr + 1) * (sps + 1).
> > + */
> > + if (prescaler > 256 * 256 * 16)
> > + return -EINVAL;
> > +
> > + if (prescaler > 256 * 256) {
> > + iclk = GTMDR_ICLK_SLGO;
> > + prescaler /= 16;
> > + }
> > +
> > + if (prescaler > 256) {
> > + psr = 256 - 1;
> > + sps = prescaler / 256 - 1;
> > + } else {
> > + psr = prescaler - 1;
> > + sps = 1 - 1;
> > + }
>
> Don't forget that the CPM2 doesn't support the primary prescaler.
I didn't know that, how can I possibly forget it? Oh, now I can.
Thanks for the info. :-)
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [EFIKA] Really, don't pretend to be CHRP
From: David Woodhouse @ 2008-04-17 14:37 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, paulus
In-Reply-To: <4807427B.3030902@genesi-usa.com>
On Thu, 2008-04-17 at 13:28 +0100, Matt Sealey wrote:
> I thought we were using efika.forth for this in Fedora.
We were, until you pointed out that the kernel actually works just fine
these days without it.
Now, the _only_ thing that goes wrong without it is that 'CHRP' in the
machine: line -- which is fixed by this patch. And so the user's life is
made easier -- all they have to work around now is the fact that we
can't set environment variables from within Linux (and yes, we can
probably improve on that too, but we let them setenv for themselves, for
now).
> Why don't we just roll all those fixes into prom_efika.c or something
> and make it a huge, unwieldy file nice and *seperate* from
> prom_init.c?
That might be a little cleaner than what we have at the moment, yes. But
what we have also works, so I'd rather concentrate on things like
getting audio support merged, before we faff around with what are
essentially cosmetics.
--
dwmw2
^ permalink raw reply
* Re: RFC: MPC5200 PSC AC97 driver
From: Matt Sealey @ 2008-04-17 15:10 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200804171619.56615.jbe@pengutronix.de>
Juergen Beisert wrote:
> Hi,
> + /* the fifo starts right after psc ends */
> + priv->fifo = (struct mpc52xx_psc_fifo*)&priv->psc[1]; /* FIXME */
Wouldn't
priv->fifo = (struct mpc52xx_psc_fifo*) (priv->psc + sizeof(struct mpc52xx_psc));
Be a little less obtuse use of C?
I just added 0x58 and gave it a pretty define in my version (PSC_FIFO_OFFSET or
something). I guess that was lame since the structure might change size in some
other dimension, but I don't think there is any smart way to do it... the 5121E
stuff really stomped on the way the device tree should be organised for the 5200B.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Anton Vorontsov @ 2008-04-17 15:07 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080417141903.GB21793@ld0162-tx32.am.freescale.net>
On Thu, Apr 17, 2008 at 09:19:03AM -0500, Scott Wood wrote:
> On Thu, Apr 17, 2008 at 04:52:35PM +0400, Anton Vorontsov wrote:
> > Heh. Scott, think about it. You have single 16bit timer with variable
> > frequency. To use it, you'd better know what exactly precision you need.
>
> Why? I know the timeout I need.
>
> > Then you limited to u16 for the interval for this chosen precision.
> >
> > Yes, you can implement this:
> >
> > #define MAX_PRESCALER (256 * 256 * 16)
> >
> > int gtm_reset_weird_behaving_utimer16(struct gtm_timer *tmr,
> > unsigned long long usec,
> > bool free_run)
> > {
> > int freq = 1000000;
> > int min_hz2 = (tmr->gtm->freq / MAX_PRESCALER) << 1;
> >
> > while (!(freq & 1) && !(usec & 1) && freq >= min_hz2) {
> > freq >>= 1;
> > usec >>= 1;
> > }
> >
> > if (usec > 0xffff)
> > return -EINVAL;
> >
> > return gtm_reset_ref_timer16(tmr, freq, (u16)usec, free_run);
> > }
>
> Try something like this:
>
> int gtm_reset_sane_behaving_timer(struct gtm_timer *tmr,
> u64 usec, bool free_run)
> {
> int freq = 1000000;
> int min_hz2 = (tmr->gtm->freq / MAX_PRESCALER) << 1;
>
> while (usec > 0xffff && freq >= min_hz2) {
This isn't a timer with usec precision! This is a timer that silently
crops precision as it wants to. Ahh, I see you dropped "u" prefix.
Well. I'm not going to use it anyway, so just give it some name you
prefer and I'll wrap it into the patch. Preferably, drop a line here with
kerneldoc for it, so I'll not have to document its drawbacks. :-)
> freq >>= 1;
> usec >>= 1;
> }
>
> if (usec > 0xffff)
> return -EINVAL;
>
> return gtm_reset_ref_timer16(tmr, freq, usec, free_run);
> }
>
> It could be made faster using cntlzw.
No need to cntlzw, there is fls() already. Though, here you'll need
two because of u64.
Btw, I hope you aware that single GTM timer running at 166MHz will give you
6 minutes of sleep, maximum. With cascaded timer you'll get much better
result of 310 days. Is that possible to use cascaded timer as a wakeup
event on 8313? If so, I'd suggest you to implement cascading firstly.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Kumar Gala @ 2008-04-17 15:05 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: a.zummo, linuxppc-dev
In-Reply-To: <200804171702.59562.laurentp@cse-semaphore.com>
On Apr 17, 2008, at 10:02 AM, Laurent Pinchart wrote:
> Hi,
>
> here's a patch against 2.6.25-rc8-mm2 that adds support for device
> tree names
> to the rtc-pcf8563 driver.
>
> Is the new-style driver conversion patch in 2.6.25-rc8-mm2 scheduled
> for
> 2.6.26 ?
Should probably include the rtc & i2c mailing list on such patches/
questions.
- k
^ permalink raw reply
* Re: RFC: MPC5200 PSC AC97 driver
From: Matt Sealey @ 2008-04-17 15:05 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200804171619.56615.jbe@pengutronix.de>
> + help
> + Say Y or M if you want to support any AC97 codec attached to
> + the Freescqle MPC52xx AC97 interface.
Also this; Freescale :)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH] [POWERPC] fsl: Convert dts to v1 syntax
From: Kumar Gala @ 2008-04-17 15:04 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080417150320.GB22368@ld0162-tx32.am.freescale.net>
On Apr 17, 2008, at 10:03 AM, Scott Wood wrote:
> On Thu, Apr 17, 2008 at 09:47:24AM -0500, Kumar Gala wrote:
>> ranges = <
>> - 0 0 fc000000 04000000
>> - 3 0 fa000000 01000000
>> + 0x0 0x0 0xfc000000 0x4000000
>> + 0x3 0x0 0xfa000000 0x1000000
>
> Chip selects should probably be decimal.
my script isn't that smart :)
patches are welcome for such clean ups. I made sure the
resulting .dtb where identical.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] fsl: Convert dts to v1 syntax
From: Scott Wood @ 2008-04-17 15:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804170946470.18068@blarg.am.freescale.net>
On Thu, Apr 17, 2008 at 09:47:24AM -0500, Kumar Gala wrote:
> ranges = <
> - 0 0 fc000000 04000000
> - 3 0 fa000000 01000000
> + 0x0 0x0 0xfc000000 0x4000000
> + 0x3 0x0 0xfa000000 0x1000000
Chip selects should probably be decimal.
-Scott
^ permalink raw reply
* [PATCH] rtc-pcf8563: Add device ids table
From: Laurent Pinchart @ 2008-04-17 15:02 UTC (permalink / raw)
To: a.zummo; +Cc: linuxppc-dev
Hi,
here's a patch against 2.6.25-rc8-mm2 that adds support for device tree names
to the rtc-pcf8563 driver.
Is the new-style driver conversion patch in 2.6.25-rc8-mm2 scheduled for
2.6.26 ?
--
This patch adds support for device tree names via the i2c mod alias mechanism
to the rtc-pcf8563 driver.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
drivers/rtc/rtc-pcf8563.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index a1e2f39..9667a3f 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -299,12 +299,20 @@ static int pcf8563_remove(struct i2c_client *client)
return 0;
}
+static struct i2c_device_id pcf8563_id[] = {
+ { "pcf8563", 0 },
+ { "rtc8564", 0 },
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, pcf8563_id);
+
static struct i2c_driver pcf8563_driver = {
.driver = {
.name = "rtc-pcf8563",
},
.probe = pcf8563_probe,
.remove = pcf8563_remove,
+ .id_table = pcf8563_id,
};
static int __init pcf8563_init(void)
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
^ permalink raw reply related
* Re: [PATCH 2/2] mpc86xx_hpcn: Temporarily accept old dts node identifier.
From: Kumar Gala @ 2008-04-17 14:57 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <a267e81e741560d8715ca4422179dcfe2ec467c6.1208364243.git.paul.gortmaker@windriver.com>
On Apr 16, 2008, at 12:53 PM, Paul Gortmaker wrote:
> As suggested by Timur Tabi, we match on the old compat node ID for one
> version and warn accordingly. If we don't do this, we plunge people
> who
> try to use an old DTB into silent boot death with no clear
> indication of
> what the problem is.
>
> This patch should be removed at the beginning of the 2.6.27 dev cycle.
> It is only meant to ease the transition in the short term.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH for 2.6.26] Fix the size of qe muram for MPC8568E
From: Kumar Gala @ 2008-04-17 14:57 UTC (permalink / raw)
To: Haiying Wang; +Cc: linuxppc-dev
In-Reply-To: <1208436962.2963.5.camel@r54964-12.am.freescale.net>
On Apr 17, 2008, at 7:56 AM, Haiying Wang wrote:
> MPC8568E has 64K byte MURAM, so the size should be 0x10000, not
> 0xc000 in dts.
>
> Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8568mds.dts | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
applied.
- k
^ 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