LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* 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: 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: [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: [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: 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: 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: 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: 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: 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: 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: 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: 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: 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: [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(&gtm->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 = &regs->gtcfr1;
 	timers[0].gtmdr = &regs->gtmdr1;
-	timers[0].gtpsr = &regs->gtpsr1;
 	timers[0].gtcnr = &regs->gtcnr1;
 	timers[0].gtrfr = &regs->gtrfr1;
 	timers[0].gtevr = &regs->gtevr1;
 
 	timers[1].gtcfr = &regs->gtcfr1;
 	timers[1].gtmdr = &regs->gtmdr2;
-	timers[1].gtpsr = &regs->gtpsr2;
 	timers[1].gtcnr = &regs->gtcnr2;
 	timers[1].gtrfr = &regs->gtrfr2;
 	timers[1].gtevr = &regs->gtevr2;
 
 	timers[2].gtcfr = &regs->gtcfr2;
 	timers[2].gtmdr = &regs->gtmdr3;
-	timers[2].gtpsr = &regs->gtpsr3;
 	timers[2].gtcnr = &regs->gtcnr3;
 	timers[2].gtrfr = &regs->gtrfr3;
 	timers[2].gtevr = &regs->gtevr3;
 
 	timers[3].gtcfr = &regs->gtcfr2;
 	timers[3].gtmdr = &regs->gtmdr4;
-	timers[3].gtpsr = &regs->gtpsr4;
 	timers[3].gtcnr = &regs->gtcnr4;
 	timers[3].gtrfr = &regs->gtrfr4;
 	timers[3].gtevr = &regs->gtevr4;
+
+	/* CPM2 doesn't have primary prescaler */
+	if (!of_device_is_compatible(np, "fsl,cpm2-gtm")) {
+		timers[0].gtpsr = &regs->gtpsr1;
+		timers[1].gtpsr = &regs->gtpsr2;
+		timers[2].gtpsr = &regs->gtpsr3;
+		timers[3].gtpsr = &regs->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: [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: 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: [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: 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: A question about the 8250/16550 Driver
From: 旭 罗 @ 2008-04-17 16:44 UTC (permalink / raw)
  To: Li Yang, Linu PPC Mail list
In-Reply-To: <989B956029373F45A0B8AF02970818900200759C@zch01exm26.fsl.freescale.net>

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

Hello Leo:
    Follow your advises, i look the source code and find that you are right. In the source code, There are 2 functions can do some work for the serial port initralization. The code is followed.
1. static int __devinit serial8250_probe(struct platform_device *dev)
2. static void __init serial8250_isa_init_ports(void)

In my system i use the function 2 and this function should use the structer old_serial_port. 
In fact the function 1 can initralize the serial port too. But i don't known how to call this function. 

For the more, i have find some source code in of_serial.c which is in the \drivers\serial directory. In this file, the function 
static int __devinit of_platform_serial_probe(struct of_device *ofdev,
                        const struct of_device_id *id)
call the serial8250_register_port function to initralized the serial port.

This issues makes me puzzlled, Could you help me to analyzed it? and what kind of the function i should used to initralize my serial port.



thanks 
best wishs

Li Yang <LeoLi@freescale.com> 写道: > -----Original Message-----
> From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org 
> [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org] 
> On Behalf Of 旭 罗
> Sent: Thursday, April 17, 2008 3:32 PM
> To: Linu PPC Mail list
> Cc: Wood Scott
> Subject: A question about the 8250/16550 Driver
> 
> Hello:
>     I have founded that the serial can't be initialized as 
> the bootting process. My platform is MPC8313 and my kernel 
> version is linux-2.6.23.9. I look though the source code and 
> find that the MPC8313 driver is compatible with 8250/16550. 
> The driver is in the \drivers\serial\8250.c
> 
> In the function serial8250_isa_init_ports we should use the 
> structer old_serial_port  but i can't find the definition for 
> this struct. I can only find the following senrense in the 
> head of this file 

If you look into the function carefully enough, you can find that old_serial_port is optional and can be empty.  It seems to be some leftover to provide backward compatibility when the port structure changed.

- Leo


       
---------------------------------
 雅虎邮箱,您的终生邮箱!

[-- Attachment #2: Type: text/html, Size: 2650 bytes --]

^ permalink raw reply

* Re: Warp patches for 2.6.26
From: Sean MacLennan @ 2008-04-17 17:26 UTC (permalink / raw)
  To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20080417160804.GA696@farnsworth.org>

On Thu, 17 Apr 2008 09:08:04 -0700
"Dale Farnsworth" <dale@farnsworth.org> wrote:

> 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.

Ok, that makes more sense to me. Sorry that I read that wrong :(

One last question.... would the warp_defconfig be considered part of
the platform code? I think one of the problems was I split up the
patches when really they all go together (again ignoring led and wdt).
But I am not sure if the defconfig really goes with the platform code.

Cheers,
  Sean

^ permalink raw reply

* Re: [PATCH 4/5] LED driver
From: Sean MacLennan @ 2008-04-17 17:32 UTC (permalink / raw)
  To: jwboyer; +Cc: linuxppc-dev
In-Reply-To: <1208047290.5869.31.camel@vader.jdub.homelinux.org>

On Sat, 12 Apr 2008 19:41:30 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:

> This should be sent to Richard Purdie.

I spoke with Richard and we agreed that, since the GPIO library will
make this driver obsolete, it is not worth committing this driver for,
hopefully, only one release.

If anybody sees any problems with this driver, I am still interested in
feedback since this driver will be used in the short term.

Cheers,
  Sean

^ permalink raw reply

* Re: USB on MPC8641D
From: John Marc @ 2008-04-17 17:53 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1492DA11-D49C-492A-9085-3B5A7A569245@kernel.crashing.org>

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

Okie Friend ,
  I will try the latest kernel 2.6.24, and let you know the results.
   
  With Regards
  John

Kumar Gala <galak@kernel.crashing.org> wrote:
  
On Apr 17, 2008, at 3:36 AM, John Marc wrote:
> Hi
> I Have the kernel patches , but no one for the USB.
> The changes for the USB are integrated in the Kernel.
> I am currently looking into the linux BSP for usb
> changes , but unfortunately don't find any major
> chages.
>
> MPC8641 board have one EHCI controller and 3 OHCI
> conroller.
>
> As I am also new to USB , it would be great help, if
> someone give me any idea about the changes in new
> MPC8641 BSP ?
>
> Does freescale fix the PCI Express issue , that makes
> USB works.
>
> I have lots of hope with this forum :-)
>
>
> With Regards
> John

This forum is about the open source kernel and not BSPs kernels from 
Freescale or any other provider.

Have you tried a 2.6.24 or 2.6.25 open source kernel for the 8641 and 
see if it works w/regards to USB. If not we can help try and figure 
out why not.

There have been a number of fixes made to PCIe support on 8641 that 
are in the 2.6.24 kernel, I'm guessing some of those might address 
whatever issue you're seeing with USB.

- k


       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

[-- Attachment #2: Type: text/html, Size: 1798 bytes --]

^ permalink raw reply

* Re: Warp patches for 2.6.26
From: Dale Farnsworth @ 2008-04-17 18:11 UTC (permalink / raw)
  To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080417132623.58f8dba7@lappy.seanm.ca>

On Thu, Apr 17, 2008 at 01:26:23PM -0400, Sean MacLennan wrote:
> On Thu, 17 Apr 2008 09:08:04 -0700
> "Dale Farnsworth" <dale@farnsworth.org> wrote:
> 
> > 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.
> 
> Ok, that makes more sense to me. Sorry that I read that wrong :(

No problem.

> One last question.... would the warp_defconfig be considered part of
> the platform code? I think one of the problems was I split up the
> patches when really they all go together (again ignoring led and wdt).
> But I am not sure if the defconfig really goes with the platform code.

I would suggest adding the defconfig as the last patch of the "platform
code" series.  (A separate patch just containing the added defconfig.)

-Dale

^ permalink raw reply

* problems with 'XPAR_PLB_CLOCK_FREQ_HZ'.
From: rodolfo @ 2008-04-17 19:15 UTC (permalink / raw)
  To: Grant Likely, Linuxppc embedded

Hi, everybody,

my xparameters_ml300.h does not include 'XPAR_PLB_CLOCK_FREQ_HZ'.


  CC      arch/ppc/boot/simple/embed_config.o
arch/ppc/boot/simple/embed_config.c: In function 'embed_config':
arch/ppc/boot/simple/embed_config.c:781: error: 'XPAR_PLB_CLOCK_FREQ_HZ'
undeclared (first use in this function)
arch/ppc/boot/simple/embed_config.c:781: error: (Each undeclared identifier
is reported only once
arch/ppc/boot/simple/embed_config.c:781: error: for each function it
appears in.)
make[2]: ** [arch/ppc/boot/simple/embed_config.o] Erro 1
make[1]: ** [simple] Erro 2
make: ** [zImage] Erro 2



Can I replace 'XPAR_PLB_CLOCK_FREQ_HZ' for XPAR_CORE_CLOCK_FREQ_HZ/3
knowing that my MHS file description is:


# Processor clock frequency: 300.000000 MHz
# Bus clock frequency: 100.000000 MHz


MHS FILE:
#
##############################################################################
# Created by Base System Builder Wizard for Xilinx EDK 9.1 Build EDK_J.19
# Thu Apr  3 17:07:17 2008
# Target Board:  Xilinx XUP Virtex-II Pro Development System Rev C
# Family:	 virtex2p
# Device:	 xc2vp30
# Package:	 ff896
# Speed Grade:	 -7
# Processor: PPC 405
# Processor clock frequency: 300.000000 MHz
# Bus clock frequency: 100.000000 MHz
# Debug interface: FPGA JTAG
# On Chip Memory : 128 KB
# Total Off Chip Memory : 512 MB
# - DDR_SDRAM_64Mx64 Dual Rank = 256 MB
# - DDR_512MB_64Mx64_rank2_row13_col10_cl2_5 = 256 MB
#
##############################################################################

regards,
rodolfo

^ permalink raw reply

* [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to support Rev B boards
From: Sean MacLennan @ 2008-04-17 19:22 UTC (permalink / raw)
  To: linuxppc-dev

PIKA Warp: Update platform code to support Rev B boards.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Full DTM support including critical temperature.
* Added POST information.
* Removed LED function, moved to new LED driver.
* Moved ad7414 to new style I2C initialization.

Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>

diff --git a/arch/powerpc/boot/cuboot-warp.c b/arch/powerpc/boot/cuboot-warp.c
index eb108a8..2178021 100644
--- a/arch/powerpc/boot/cuboot-warp.c
+++ b/arch/powerpc/boot/cuboot-warp.c
@@ -10,6 +10,7 @@
 #include "ops.h"
 #include "4xx.h"
 #include "cuboot.h"
+#include "stdio.h"
 
 #define TARGET_4xx
 #define TARGET_44x
@@ -17,14 +18,54 @@
 
 static bd_t bd;
 
-static void warp_fixups(void)
+static void warp_fixup_one_nor(u32 from, u32 to)
 {
-	unsigned long sysclk = 66000000;
+	void *devp;
+	char name[50];
+	u32 v[2];
+
+	sprintf(name, "/plb/opb/ebc/nor_flash@0,0/partition@%x", from);
+
+	devp = finddevice(name);
+	if (!devp)
+		return;
+
+	if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+		v[0] = to;
+		setprop(devp, "reg", v, sizeof(v));
+
+		printf("NOR 64M fixup %x -> %x\r\n", from, to);
+	}
+}
+
 
-	ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
+static void warp_fixups(void)
+{
+	ibm440ep_fixup_clocks(66000000, 11059200, 50000000);
 	ibm4xx_sdram_fixup_memsize();
 	ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
 	dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
+
+	/* Fixup for 64M flash on Rev A boards. */
+	if (bd.bi_flashsize == 0x4000000) {
+		void *devp;
+		u32 v[3];
+
+		devp = finddevice("/plb/opb/ebc/nor_flash@0,0");
+		if (!devp)
+			return;
+
+		/* Fixup the size */
+		if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+			v[2] = bd.bi_flashsize;
+			setprop(devp, "reg", v, sizeof(v));
+		}
+
+		/* Fixup parition offsets */
+		warp_fixup_one_nor(0x300000, 0x3f00000);
+		warp_fixup_one_nor(0x340000, 0x3f40000);
+		warp_fixup_one_nor(0x380000, 0x3f80000);
+	}
 }
 
 
diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index b04a52e..fa070b0 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -132,40 +132,33 @@
 
 				fpga@2,0 {
 					compatible = "pika,fpga";
-			   		reg = <2 0 2200>;
+			   		reg = <2 0 1000>;
 					interrupts = <18 8>;
 					interrupt-parent = <&UIC0>;
 				};
 
+				fpga@2,4000 {
+					compatible = "pika,fpga-sd";
+					reg = <2 4000 A00>;
+				};
+
 				nor_flash@0,0 {
-					compatible = "amd,s29gl512n", "cfi-flash";
+					compatible = "amd,s29gl032a", "cfi-flash";
 					bank-width = <2>;
-					reg = <0 0 4000000>;
+					reg = <0 0 400000>;
 					#address-cells = <1>;
 					#size-cells = <1>;
-					partition@0 {
-						label = "kernel";
-						reg = <0 180000>;
-					};
-					partition@180000 {
-						label = "root";
-						reg = <180000 3480000>;
-					};
-					partition@3600000 {
-						label = "user";
-						reg = <3600000 900000>;
-					};
-					partition@3f00000 {
+					partition@300000 {
 						label = "fpga";
-						reg = <3f00000 40000>;
+						reg = <300000 40000>;
 					};
-					partition@3f40000 {
+					partition@340000 {
 						label = "env";
-						reg = <3f40000 40000>;
+						reg = <340000 40000>;
 					};
-					partition@3f80000 {
+					partition@380000 {
 						label = "u-boot";
-						reg = <3f80000 80000>;
+						reg = <380000 80000>;
 					};
 				};
 			};
@@ -186,6 +179,16 @@
 				reg = <ef600700 14>;
 				interrupt-parent = <&UIC0>;
 				interrupts = <2 4>;
+				index = <0>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				ad7414@4a {
+					compatible = "adi,ad7414";
+					reg = <4a>;
+					interrupts = <19 8>;
+					interrupt-parent = <&UIC0>;
+				};
 			};
 
 			GPIO0: gpio@ef600b00 {
diff --git a/arch/powerpc/platforms/44x/warp-nand.c b/arch/powerpc/platforms/44x/warp-nand.c
index 9150318..4c6a2a5 100644
--- a/arch/powerpc/platforms/44x/warp-nand.c
+++ b/arch/powerpc/platforms/44x/warp-nand.c
@@ -11,8 +11,10 @@
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/nand.h>
 #include <linux/mtd/ndfc.h>
+#include <linux/of_platform.h>
 #include <asm/machdep.h>
 
+
 #ifdef CONFIG_MTD_NAND_NDFC
 
 #define CS_NAND_0	1	/* use chip select 1 for NAND device 0 */
@@ -35,13 +37,23 @@ static struct mtd_partition nand_parts[] = {
 	{
 		.name   = "root",
 		.offset = 0x0200000,
-		.size   = 0x3400000
+		.size   = 0x3E00000
+	},
+	{
+		.name   = "persistent",
+		.offset = 0x4000000,
+		.size   = 0x4000000
 	},
 	{
-		.name   = "user",
-		.offset = 0x3600000,
-		.size   = 0x0A00000
+		.name   = "persistent1",
+		.offset = 0x8000000,
+		.size   = 0x4000000
 	},
+	{
+		.name   = "persistent2",
+		.offset = 0xC000000,
+		.size   = 0x4000000
+	}
 };
 
 struct ndfc_controller_settings warp_ndfc_settings = {
@@ -67,19 +79,15 @@ static struct platform_device warp_ndfc_device = {
 	.resource = &warp_ndfc,
 };
 
-static struct nand_ecclayout nand_oob_16 = {
-	.eccbytes = 3,
-	.eccpos = { 0, 1, 2, 3, 6, 7 },
-	.oobfree = { {.offset = 8, .length = 16} }
-};
-
+/* Do NOT set the ecclayout: let it default so it is correct for both
+ * 64M and 256M flash chips.
+ */
 static struct platform_nand_chip warp_nand_chip0 = {
 	.nr_chips = 1,
 	.chip_offset = CS_NAND_0,
 	.nr_partitions = ARRAY_SIZE(nand_parts),
 	.partitions = nand_parts,
-	.chip_delay = 50,
-	.ecclayout = &nand_oob_16,
+	.chip_delay = 20,
 	.priv = &warp_chip0_settings,
 };
 
@@ -96,6 +104,23 @@ static struct platform_device warp_nand_device = {
 
 static int warp_setup_nand_flash(void)
 {
+	struct device_node *np;
+
+	/* Try to detect a rev A based on NOR size. */
+	np = of_find_compatible_node(NULL, NULL, "cfi-flash");
+	if (np) {
+		struct property *pp;
+
+		pp = of_find_property(np, "reg", NULL);
+		if (pp && (pp->length == 12)) {
+			u32 *v = pp->value;
+			if (v[2] == 0x4000000)
+				/* Rev A = 64M NAND */
+				warp_nand_chip0.nr_partitions = 2;
+		}
+		of_node_put(np);
+	}
+
 	platform_device_register(&warp_ndfc_device);
 	platform_device_register(&warp_nand_device);
 
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 39cf615..d770b8f 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -12,6 +12,9 @@
 #include <linux/init.h>
 #include <linux/of_platform.h>
 #include <linux/kthread.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/pika.h>
 
 #include <asm/machdep.h>
 #include <asm/prom.h>
@@ -27,6 +30,18 @@ static __initdata struct of_device_id warp_of_bus[] = {
 	{},
 };
 
+static __initdata struct i2c_board_info warp_i2c_info[] = {
+	{ I2C_BOARD_INFO("ad7414", 0x4a) }
+};
+
+static int __init warp_arch_init(void)
+{
+	/* This should go away once support is moved to the dts. */
+	i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
+	return 0;
+}
+machine_arch_initcall(warp, warp_arch_init);
+
 static int __init warp_device_probe(void)
 {
 	of_platform_bus_probe(NULL, warp_of_bus, NULL);
@@ -52,61 +67,183 @@ define_machine(warp) {
 };
 
 
-#define LED_GREEN (0x80000000 >> 0)
-#define LED_RED   (0x80000000 >> 1)
+/* I am not sure this is the best place for this... */
+static int __init warp_post_info(void)
+{
+	struct device_node *np;
+	void __iomem *fpga;
+	u32 post1, post2;
+
+	/* Sighhhh... POST information is in the sd area. */
+	np = of_find_compatible_node(NULL, NULL, "pika,fpga-sd");
+	if (np == NULL)
+		return -ENOENT;
+
+	fpga = of_iomap(np, 0);
+	of_node_put(np);
+	if (fpga == NULL)
+		return -ENOENT;
+
+	post1 = in_be32(fpga + 0x40);
+	post2 = in_be32(fpga + 0x44);
+
+	iounmap(fpga);
+
+	if (post1 || post2)
+		printk(KERN_INFO "Warp POST %08x %08x\n", post1, post2);
+	else
+		printk(KERN_INFO "Warp POST OK\n");
+
+	return 0;
+}
+machine_late_initcall(warp, warp_post_info);
+
+
+#ifdef CONFIG_SENSORS_AD7414
+
+static LIST_HEAD(dtm_shutdown_list);
+static void __iomem *dtm_fpga;
+
+struct dtm_shutdown {
+	struct list_head list;
+	void (*func)(void *arg);
+	void *arg;
+};
+
+
+int dtm_register_shutdown(void (*func)(void *arg), void *arg)
+{
+	struct dtm_shutdown *shutdown;
+
+	shutdown = kmalloc(sizeof(struct dtm_shutdown), GFP_KERNEL);
+	if (shutdown == NULL)
+		return -ENOMEM;
+
+	shutdown->func = func;
+	shutdown->arg = arg;
 
+	list_add(&shutdown->list, &dtm_shutdown_list);
+
+	return 0;
+}
+EXPORT_SYMBOL(dtm_register_shutdown);
 
-/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
-void warp_set_power_leds(int green, int red)
+int dtm_unregister_shutdown(void (*func)(void *arg), void *arg)
 {
-	static void __iomem *gpio_base = NULL;
-	unsigned leds;
-
-	if (gpio_base == NULL) {
-		struct device_node *np;
-
-		/* Power LEDS are on the second GPIO controller */
-		np = of_find_compatible_node(NULL, NULL, "ibm,gpio-440EP");
-		if (np)
-			np = of_find_compatible_node(np, NULL, "ibm,gpio-440EP");
-		if (np == NULL) {
-			printk(KERN_ERR __FILE__ ": Unable to find gpio\n");
-			return;
-		}
+	struct dtm_shutdown *shutdown;
 
-		gpio_base = of_iomap(np, 0);
-		of_node_put(np);
-		if (gpio_base == NULL) {
-			printk(KERN_ERR __FILE__ ": Unable to map gpio");
-			return;
+	list_for_each_entry(shutdown, &dtm_shutdown_list, list)
+		if (shutdown->func == func && shutdown->arg == arg) {
+			list_del(&shutdown->list);
+			kfree(shutdown);
+			return 0;
 		}
+
+	return -EINVAL;
+}
+EXPORT_SYMBOL(dtm_unregister_shutdown);
+
+static long wdt_keepalive(long time)
+{
+	if (dtm_fpga) {
+		unsigned reset = in_be32(dtm_fpga + 0x14);
+		out_be32(dtm_fpga + 0x14, reset);
 	}
 
-	leds = in_be32(gpio_base);
+	return 0;
+}
+
+static irqreturn_t temp_isr(int irq, void *context)
+{
+	struct dtm_shutdown *shutdown;
+
+	/* Run through the shutdown list. */
+	list_for_each_entry(shutdown, &dtm_shutdown_list, list)
+		shutdown->func(shutdown->arg);
+
+	panic_timeout = 1800;
+	panic_blink = wdt_keepalive;
+	panic("Critical Temperature Shutdown");
+	return IRQ_HANDLED;
+}
+
+static void pika_setup_critical_temp(struct i2c_client *client)
+{
+	struct device_node *np;
+	int irq, rc;
+
+	/* These registers are in 1 degree increments. */
+	i2c_smbus_write_byte_data(client, 2, 65); /* Thigh */
+	i2c_smbus_write_byte_data(client, 3, 55); /* Tlow */
 
-	switch (green) {
-	case 0: leds &= ~LED_GREEN; break;
-	case 1: leds |=  LED_GREEN; break;
+	np = of_find_compatible_node(NULL, NULL, "adi,ad7414");
+	if (np == NULL) {
+		printk(KERN_ERR __FILE__ ": Unable to find ad7414\n");
+		return;
 	}
-	switch (red) {
-	case 0: leds &= ~LED_RED; break;
-	case 1: leds |=  LED_RED; break;
+
+	irq = irq_of_parse_and_map(np, 0);
+	of_node_put(np);
+	if (irq  == NO_IRQ) {
+		printk(KERN_ERR __FILE__ ": Unable to get ad7414 irq\n");
+		return;
 	}
 
-	out_be32(gpio_base, leds);
+	rc = request_irq(irq, temp_isr, 0, "ad7414", NULL);
+	if (rc) {
+		printk(KERN_ERR __FILE__
+		       ": Unable to request ad7414 irq %d = %d\n", irq, rc);
+		return;
+	}
 }
-EXPORT_SYMBOL(warp_set_power_leds);
 
+static inline void pika_dtm_check_fan(void __iomem *fpga)
+{
+	static int fan_state;
+	u32 fan = in_be32(fpga + 0x34) & (1 << 14);
+
+	if (fan_state != fan) {
+		fan_state = fan;
+		if (fan)
+			printk(KERN_WARNING "Fan rotation error detected."
+				   " Please check hardware.\n");
+	}
+}
 
-#ifdef CONFIG_SENSORS_AD7414
 static int pika_dtm_thread(void __iomem *fpga)
 {
-	extern int ad7414_get_temp(int index);
+	struct i2c_adapter *adap;
+	struct i2c_client *client;
+
+	/* We loop in case either driver was compiled as a module and
+	 * has not been insmoded yet.
+	 */
+	while (!(adap = i2c_get_adapter(0))) {
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout(HZ);
+	}
+
+	while (1) {
+		list_for_each_entry(client, &adap->clients, list)
+			if (client->addr == 0x4a)
+				goto found_it;
+
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout(HZ);
+	}
+
+found_it:
+	i2c_put_adapter(adap);
+
+	pika_setup_critical_temp(client);
+
+	printk(KERN_INFO "PIKA DTM thread running.\n");
 
 	while (!kthread_should_stop()) {
-		int temp = ad7414_get_temp(0);
+		u16 temp = swab16(i2c_smbus_read_word_data(client, 0));
+		out_be32(fpga + 0x20, temp);
 
-		out_be32(fpga, temp);
+		pika_dtm_check_fan(fpga);
 
 		set_current_state(TASK_INTERRUPTIBLE);
 		schedule_timeout(HZ);
@@ -115,37 +252,28 @@ static int pika_dtm_thread(void __iomem *fpga)
 	return 0;
 }
 
+
 static int __init pika_dtm_start(void)
 {
 	struct task_struct *dtm_thread;
 	struct device_node *np;
-	struct resource res;
-	void __iomem *fpga;
 
 	np = of_find_compatible_node(NULL, NULL, "pika,fpga");
 	if (np == NULL)
 		return -ENOENT;
 
-	/* We do not call of_iomap here since it would map in the entire
-	 * fpga space, which is over 8k.
-	 */
-	if (of_address_to_resource(np, 0, &res)) {
-		of_node_put(np);
-		return -ENOENT;
-	}
+	dtm_fpga = of_iomap(np, 0);
 	of_node_put(np);
-
-	fpga = ioremap(res.start, 0x24);
-	if (fpga == NULL)
+	if (dtm_fpga == NULL)
 		return -ENOENT;
 
-	dtm_thread = kthread_run(pika_dtm_thread, fpga + 0x20, "pika-dtm");
+	dtm_thread = kthread_run(pika_dtm_thread, dtm_fpga, "pika-dtm");
 	if (IS_ERR(dtm_thread)) {
-		iounmap(fpga);
+		iounmap(dtm_fpga);
 		return PTR_ERR(dtm_thread);
 	}
 
 	return 0;
 }
-device_initcall(pika_dtm_start);
+machine_late_initcall(warp, pika_dtm_start);
 #endif

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox