* Re: Linux 2.6.x on 8xx status
From: Guillaume Autran @ 2005-03-21 21:45 UTC (permalink / raw)
To: linux-ppc-embedded; +Cc: Smith, Craig
In-Reply-To: <20050210170859.GB20153@logos.cnet>
[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]
Hi,
Was there any progress made about this issue or is it still pending ?
I'm running 2.6.11 and still see the problem...
Regards,
Guillaume.
Marcelo Tosatti wrote:
>On Thu, Feb 10, 2005 at 03:06:58PM -0200, Marcelo Tosatti wrote:
>
>
>>On Thu, Feb 10, 2005 at 02:26:52PM -0500, Dan Malek wrote:
>>
>>
>>>On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote:
>>>
>>>
>>>
>>>>Does anyone have a clue of what is/can be wrong with the TLB entry for
>>>>the
>>>>address being flushed at __flush_dcache_icache()?
>>>>
>>>>
>>>Not sure. The problem is that the __flush_dcache_icache is passed a
>>>user space virtual address that doesn't look like it is mapped for
>>>writing
>>>or something. I don't know, as an ooops isn't sufficient to debug the
>>>problem.
>>>You have to catch it here and track down the current state of the TLB
>>>and
>>>the page tables. Of course, when I do this everything looks OK,
>>>
>>>
>>How do you do track down the current TLB state? With a BDI?
>>
>>
>>
>>>so what I've been trying to do is catch the TLBmiss reload that actually causes
>>>this
>>>to happen to see what it really tried to load into the tlb.
>>>
>>>
>>Shouldnt it be loading the TLB entry which "seem to be OK" accordingly to your
>>analysis ??
>>
>>
>
>So this assumption which you have made sometime ago is wrong, given that now you
>know TLB entry is not stale ?
>
>"The symptom is we appear to have a stale TLB entry,
>so at least one of the callouts from the generic VM
>code isn't doing the right thing for us. I'm still
>puzzled as to why it doesn't affect other PPC processor."
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
[-- Attachment #2: Type: text/html, Size: 2953 bytes --]
^ permalink raw reply
* RE: MPC885 CryptoApi support.
From: Bruce Donadt @ 2005-03-21 20:54 UTC (permalink / raw)
To: Guillaume Autran, linuxppc-embedded
In-Reply-To: <423F0FFB.10307@mrv.com>
Guillaume:
Arabella Software provides asynchronous 2.6 kernel CryptoApi support for the
MPC885 as well as the PowerQUICC II devices as part of our commercially
supported Linux distribution. If you would be interested in a commercial
open source offering, please feel free to contact me and I can provide
further detail.
Best Regards,
Bruce
*********************************************************************
Bruce Donadt
Arabella Software Inc.
300B West Main Street
Northborough, MA. 01532
Phone (508) 393-4144
bdonadt@arabellasw.com
www.arabellasw.com
-----Original Message-----
From: Guillaume Autran [mailto:gautran@mrv.com]
Sent: Monday, March 21, 2005 1:19 PM
To: linuxppc-embedded
Subject: MPC885 CryptoApi support.
Hi,
Is there any open source development done to integrate the MPC885
security coprocessor into the linux 2.6 kernel CryptoApi framework ?
Did anyone wrote a driver for it yet ?
Best regards,
Guillaume.
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
^ permalink raw reply
* Re: Wakeup broken on iBook G3
From: Andreas Schwab @ 2005-03-21 20:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1111407779.1236.272.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Can you try playing with pmac_sleep.S and pmac_cache.S, basically
> reverting those including the calls to set_L2CR in via-pmu.c ?
That makes it even worse (it apparently crashes almost immediately after
wakeup).
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: MPC885 CryptoApi support.
From: Eugene Surovegin @ 2005-03-21 19:03 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linuxppc-embedded
In-Reply-To: <423F1A05.4080308@mrv.com>
On Mon, Mar 21, 2005 at 02:01:25PM -0500, Guillaume Autran wrote:
> >Current kernel CryptoAPI is lacking sane support for hw crypto engines
> >(e.g. there is no async crypto). Until there is such generic support,
> >it's highly difficult to efficiently integrate hw crypto into the
> >kernel. I did such stuff for Hifn 7955 accelerator and didn't like the
> >result :).
> >
> >--
> >Eugene
> >
> >
> >
> Thanks Eugene,
> Do you know if anybody is working on HW crypto engine support ?
There were some patches posted to lkml around a month or so ago. Don't
know what happened to them.
--
Eugene
^ permalink raw reply
* Re: MPC885 CryptoApi support.
From: Guillaume Autran @ 2005-03-21 19:01 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20050321185056.GB11734@gate.ebshome.net>
[-- Attachment #1: Type: text/plain, Size: 917 bytes --]
Eugene Surovegin wrote:
>On Mon, Mar 21, 2005 at 01:18:35PM -0500, Guillaume Autran wrote:
>
>
>>Is there any open source development done to integrate the MPC885
>>security coprocessor into the linux 2.6 kernel CryptoApi framework ?
>>Did anyone wrote a driver for it yet ?
>>
>>
>
>Current kernel CryptoAPI is lacking sane support for hw crypto engines
>(e.g. there is no async crypto). Until there is such generic support,
>it's highly difficult to efficiently integrate hw crypto into the
>kernel. I did such stuff for Hifn 7955 accelerator and didn't like the
>result :).
>
>--
>Eugene
>
>
>
Thanks Eugene,
Do you know if anybody is working on HW crypto engine support ?
Regards,
Guillaume.
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
[-- Attachment #2: Type: text/html, Size: 1467 bytes --]
^ permalink raw reply
* Re: MPC885 CryptoApi support.
From: Eugene Surovegin @ 2005-03-21 18:50 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linuxppc-embedded
In-Reply-To: <423F0FFB.10307@mrv.com>
On Mon, Mar 21, 2005 at 01:18:35PM -0500, Guillaume Autran wrote:
> Is there any open source development done to integrate the MPC885
> security coprocessor into the linux 2.6 kernel CryptoApi framework ?
> Did anyone wrote a driver for it yet ?
Current kernel CryptoAPI is lacking sane support for hw crypto engines
(e.g. there is no async crypto). Until there is such generic support,
it's highly difficult to efficiently integrate hw crypto into the
kernel. I did such stuff for Hifn 7955 accelerator and didn't like the
result :).
--
Eugene
^ permalink raw reply
* Re: [RFC] ppc32: Report chip version in common /proc/cpuinfo handling
From: Kumar Gala @ 2005-03-21 18:32 UTC (permalink / raw)
To: Tom Rini; +Cc: Kumar Gala, linuxppc-embedded
In-Reply-To: <20050321180548.GU8345@smtp.west.cox.net>
On Mar 21, 2005, at 12:05 PM, Tom Rini wrote:
> On Mon, Mar 21, 2005 at 11:21:28AM -0600, Kumar Gala wrote:
> >
> > On Mar 21, 2005, at 10:39 AM, Tom Rini wrote:
> >
> > >On Fri, Mar 18, 2005 at 06:26:52PM -0600, Kumar Gala wrote:
> > >
> > >>
> > >> You asked me to look at doing the following.? I just want to =
make
> > >sure
> > >> this is what we want to do (and call it).? I'm a little =
concerned
> > >that
> > >> 'chip' is not necessary the right name in light of TSI10x and=20
> MV64x60
> > >> being described by ppc_sys in the future.
> > >
> > >"chip" or "chip(set)" or anything else is fine with me (I'm=20
> horrible at
> > > names).? But I don't like:
> > >
> > >> +#if defined (CONFIG_85xx) || defined (CONFIG_83xx)
> > >> +???? if (cur_ppc_sys_spec->ppc_sys_name)
> > >> +???? ??????? seq_printf(m, "chip\t\t: %s\n",
> > >cur_ppc_sys_spec->ppc_sys_name);
> > >> +#endif
> > >
> > >ifdef'ing this.? If the field is set, we should print it.
> >
> > The only reason this is ifdef'd is that cur_ppc_sys_spec does not
> > always exist on all platforms built.
>
> Oh boy, I sense an <asm-ppc/serial.h> in the making.=A0 Please tell me
> it's at least not possible that someone could stick an 85xx and an
> MV64x60 together.=A0 So we want the enum there to do sanity checking,
> right?
It is not possible that this could happen, in the sense that you are=20
using the MV64x60 as a chipset, not a PCI device or something bizarre.
- kumar=
^ permalink raw reply
* MPC885 CryptoApi support.
From: Guillaume Autran @ 2005-03-21 18:18 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Is there any open source development done to integrate the MPC885
security coprocessor into the linux 2.6 kernel CryptoApi framework ?
Did anyone wrote a driver for it yet ?
Best regards,
Guillaume.
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
^ permalink raw reply
* RE: LED driver (8260)
From: David Bruce @ 2005-03-21 18:10 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050317125419.73A6367A79@ozlabs.org>
I've taken Hans Schillstrom's version of rcb8270_led-0001.bin (which is
based on DENX status_led.c) and "generalized" it for my purposes (I have
LED's on more that one port and not all pins can be LED's) (This is used
on a TQM8260). This also has only been tested briefly...
What was done:
1.) put back in DENX copyright; ;^)
2.) removed unknown include files;
3.) put in compile option to NOT initialize a port pin during module
install, see #define DO_NOT_INIT_PORT and #ifndef DO_NOT_INIT_PORT;
4.) added "used" field to control structure to specify if LED was ever
used (set in statusled_open());
5.) put code in statusled_cleanup() that will only shut off a LED if the
LED was ever used (opened);
In the led_dev_t led_dev[] control structure, all of the port A & D pins
are specified (for my needs) but not all are used. (The project that I
am using this for is a "moving" target and not all of the port pins have
been specified.) Therefore in the load script, only create devices that
_ARE_ LED's. Device minor numbers for port A is the port pin number and
for port D it is the port pin number times 2.
It can be found at:
http://www.geocities.com/dbruce_01721/status_led_8260.c
^ permalink raw reply
* Re: [RFC] ppc32: Report chip version in common /proc/cpuinfo handling
From: Tom Rini @ 2005-03-21 18:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: Kumar Gala, linuxppc-embedded
In-Reply-To: <4ae19fb229974e099a8472158be9482f@freescale.com>
On Mon, Mar 21, 2005 at 11:21:28AM -0600, Kumar Gala wrote:
>
> On Mar 21, 2005, at 10:39 AM, Tom Rini wrote:
>
> >On Fri, Mar 18, 2005 at 06:26:52PM -0600, Kumar Gala wrote:
> >
> >>
> >> You asked me to look at doing the following.? I just want to make
> >sure
> >> this is what we want to do (and call it).? I'm a little concerned
> >that
> >> 'chip' is not necessary the right name in light of TSI10x and MV64x60
> >> being described by ppc_sys in the future.
> >
> >"chip" or "chip(set)" or anything else is fine with me (I'm horrible at
> > names).? But I don't like:
> >
> >> +#if defined (CONFIG_85xx) || defined (CONFIG_83xx)
> >> +???? if (cur_ppc_sys_spec->ppc_sys_name)
> >> +???? ??????? seq_printf(m, "chip\t\t: %s\n",
> >cur_ppc_sys_spec->ppc_sys_name);
> >> +#endif
> >
> >ifdef'ing this.? If the field is set, we should print it.
>
> The only reason this is ifdef'd is that cur_ppc_sys_spec does not
> always exist on all platforms built.
Oh boy, I sense an <asm-ppc/serial.h> in the making. Please tell me
it's at least not possible that someone could stick an 85xx and an
MV64x60 together. So we want the enum there to do sanity checking,
right?
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] ppc44x: Remove PVR_440G* and change usages
From: Eugene Surovegin @ 2005-03-21 17:40 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20050321152728.GS8345@smtp.west.cox.net>
On Mon, Mar 21, 2005 at 08:27:29AM -0700, Tom Rini wrote:
> The following patch changes the usages of PVR_440* into strcmp's with
> the cpu_name field, and removes the defines altogether. The Ebony
> portion was briefly tested.
>
> Signed-off-by: Tom Rini <trini@kernel.crashing.org>
>
> arch/ppc/platforms/4xx/ebony.c | 13 ++++---------
> arch/ppc/syslib/ibm440gx_common.c | 7 ++++---
> include/asm-ppc/reg.h | 6 ------
> 3 files changed, 8 insertions(+), 18 deletions(-)
> --- 1.11/arch/ppc/platforms/4xx/ebony.c 2005-03-04 23:41:48 -07:00
> +++ edited/arch/ppc/platforms/4xx/ebony.c 2005-03-08 15:22:19 -07:00
> @@ -97,15 +97,10 @@
> * on Rev. C silicon then errata forces us to
> * use the internal clock.
> */
> - switch (PVR_REV(mfspr(PVR))) {
> - case PVR_REV(PVR_440GP_RB):
> - freq = EBONY_440GP_RB_SYSCLK;
> - break;
> - case PVR_REV(PVR_440GP_RC1):
> - default:
> - freq = EBONY_440GP_RC_SYSCLK;
> - break;
> - }
> + if (strcmp(cur_cpu_spec[0]->cpu_name, "440GP Rev. B") == 0)
> + freq = EBONY_440GP_RB_SYSCLK;
> + else
> + freq = EBONY_440GP_RC_SYSCLK;
>
> ibm44x_calibrate_decr(freq);
> }
> --- 1.3/arch/ppc/syslib/ibm440gx_common.c 2004-11-07 19:08:31 -07:00
> +++ edited/arch/ppc/syslib/ibm440gx_common.c 2005-03-21 08:20:17 -07:00
> @@ -221,9 +221,10 @@
> /* Disable L2C on rev.A, rev.B and 800MHz version of rev.C,
> enable it on all other revisions
> */
> - u32 pvr = mfspr(PVR);
> - if (pvr == PVR_440GX_RA || pvr == PVR_440GX_RB ||
> - (pvr == PVR_440GX_RC && p->cpu > 667000000))
> + if (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. A") == 0 ||
> + strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. B") == 0
> + || (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. C")
> + == 0 && p->cpu > 667000000))
While I applaud Tom's quest to eliminate _useless_ PVR defines I think
this change looks strange.
It substitutes simple and clear (for those who are reading this code)
check to something more involved without good reason, IMHO.
Also, it adds additional "point of failure" making this code more
fragile. We never used those CPU ID strings anywhere in the kernel
code before, people are used to the fact that they don't matter much
(maybe only for user-mode) and it's possible that during some future
"cleanup" code will break. One could say that we aren't allowed to
change such strings because something in user-mode could break, and
while I agree with that, I don't think it's good argument to _add_
additional point where code could break.
--
Eugene
^ permalink raw reply
* Re: [RFC] ppc32: Report chip version in common /proc/cpuinfo handling
From: Kumar Gala @ 2005-03-21 17:21 UTC (permalink / raw)
To: Tom Rini; +Cc: Kumar Gala, linuxppc-embedded
In-Reply-To: <20050321163904.GT8345@smtp.west.cox.net>
On Mar 21, 2005, at 10:39 AM, Tom Rini wrote:
> On Fri, Mar 18, 2005 at 06:26:52PM -0600, Kumar Gala wrote:
>
> >
> > You asked me to look at doing the following.=A0 I just want to make=20=
> sure
> > this is what we want to do (and call it).=A0 I'm a little concerned=20=
> that
> > 'chip' is not necessary the right name in light of TSI10x and =
MV64x60
> > being described by ppc_sys in the future.
>
> "chip" or "chip(set)" or anything else is fine with me (I'm horrible =
at
> names).=A0 But I don't like:
>
> > +#if defined (CONFIG_85xx) || defined (CONFIG_83xx)
> > +=A0=A0=A0=A0 if (cur_ppc_sys_spec->ppc_sys_name)
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "chip\t\t: %s\n",=20=
> cur_ppc_sys_spec->ppc_sys_name);
> > +#endif
>
> ifdef'ing this.=A0 If the field is set, we should print it.
The only reason this is ifdef'd is that cur_ppc_sys_spec does not=20
always exist on all platforms built.
- kumar=
^ permalink raw reply
* Re: [RFC] ppc32: Report chip version in common /proc/cpuinfo handling
From: Tom Rini @ 2005-03-21 16:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0503181818330.26408@blarg.somerset.sps.mot.com>
On Fri, Mar 18, 2005 at 06:26:52PM -0600, Kumar Gala wrote:
>
> You asked me to look at doing the following. I just want to make sure
> this is what we want to do (and call it). I'm a little concerned that
> 'chip' is not necessary the right name in light of TSI10x and MV64x60
> being described by ppc_sys in the future.
"chip" or "chip(set)" or anything else is fine with me (I'm horrible at
names). But I don't like:
> +#if defined (CONFIG_85xx) || defined (CONFIG_83xx)
> + if (cur_ppc_sys_spec->ppc_sys_name)
> + seq_printf(m, "chip\t\t: %s\n", cur_ppc_sys_spec->ppc_sys_name);
> +#endif
ifdef'ing this. If the field is set, we should print it.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [RFC] ppc32: Report chip version in common /proc/cpuinfo handling
From: Kumar Gala @ 2005-03-21 16:33 UTC (permalink / raw)
To: linuxppc-embedded list; +Cc: Tom Rini
In-Reply-To: <Pine.LNX.4.61.0503181818330.26408@blarg.somerset.sps.mot.com>
Ok, in a possible solution we could call it 'chip(set)' this dealing=20
with either chips (85??, 82??, 52??, ....) or chipsets (MV64x60,=20
TSI10x, MPC10x, etc..)
- kumar
On Mar 18, 2005, at 6:26 PM, Kumar Gala wrote:
> Tom,
>
> You asked me to look at doing the following.=A0 I just want to make =
sure
> this is what we want to do (and call it).=A0 I'm a little concerned =
that
> 'chip' is not necessary the right name in light of TSI10x and MV64x60
> being described by ppc_sys in the future.
>
> - kumar
>
> --=20
>
> Moved reporting of chip revision from board specific to common handing=20=
> of
> /proc/cpuinfo.=A0 In light of numerous PPC system-on-chip devices, we=20=
> report
> both the cpu version (reflects the core version) and the chip version
> (reflects the system-on-chip version).
>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
>
> ---
> diff -Nru a/arch/ppc/kernel/setup.c b/arch/ppc/kernel/setup.c
> --- a/arch/ppc/kernel/setup.c=A0=A0 2005-03-18 18:17:16 -06:00
> +++ b/arch/ppc/kernel/setup.c=A0=A0 2005-03-18 18:17:16 -06:00
> @@ -40,6 +40,7 @@
> =A0#include <asm/nvram.h>
> =A0#include <asm/xmon.h>
> =A0#include <asm/ocp.h>
> +#include <asm/ppc_sys.h>
> =A0
> =A0#if defined CONFIG_KGDB
> =A0#include <asm/kgdb.h>
> @@ -245,6 +246,11 @@
> =A0
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "bogomips\t: %lu.%02lu\n",
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0 lpj / (500000/HZ), =
(lpj / (5000/HZ)) % 100);
> +
> +#if defined (CONFIG_85xx) || defined (CONFIG_83xx)
> +=A0=A0=A0=A0=A0=A0 if (cur_ppc_sys_spec->ppc_sys_name)
> +=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "chip\t\t: =
%s\n",=20
> cur_ppc_sys_spec->ppc_sys_name);
> +#endif
> =A0
> =A0#ifdef CONFIG_SMP
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "\n");
> diff -Nru a/arch/ppc/platforms/83xx/mpc834x_sys.c=20
> b/arch/ppc/platforms/83xx/mpc834x_sys.c
> --- a/arch/ppc/platforms/83xx/mpc834x_sys.c=A0=A0=A0=A0 2005-03-18 =
18:17:16=20
> -06:00
> +++ b/arch/ppc/platforms/83xx/mpc834x_sys.c=A0=A0=A0=A0 2005-03-18 =
18:17:16=20
> -06:00
> @@ -143,7 +143,6 @@
> =A0=A0=A0=A0=A0=A0=A0 pvid =3D mfspr(SPRN_PVR);
> =A0=A0=A0=A0=A0=A0=A0 svid =3D mfspr(SPRN_SVR);
> =A0
> -=A0=A0=A0=A0=A0=A0 seq_printf(m, "chip\t\t: MPC%s\n",=20
> cur_ppc_sys_spec->ppc_sys_name);
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "Vendor\t\t: Freescale Inc.\n");
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "Machine\t\t: mpc%s sys\n",=20
> cur_ppc_sys_spec->ppc_sys_name);
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "core clock\t: %d MHz\n"
> diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c=20
> b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
> --- a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c=A0=A0=A0=A0=A0 =
2005-03-18=20
> 18:17:16 -06:00
> +++ b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c=A0=A0=A0=A0=A0 =
2005-03-18=20
> 18:17:16 -06:00
> @@ -129,7 +129,6 @@
> =A0=A0=A0=A0=A0=A0=A0 pvid =3D mfspr(SPRN_PVR);
> =A0=A0=A0=A0=A0=A0=A0 svid =3D mfspr(SPRN_SVR);
> =A0
> -=A0=A0=A0=A0=A0=A0 seq_printf(m, "chip\t\t: MPC%s\n",=20
> cur_ppc_sys_spec->ppc_sys_name);
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "Vendor\t\t: Freescale =
Semiconductor\n");
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "Machine\t\t: mpc%sads\n",=20
> cur_ppc_sys_spec->ppc_sys_name);
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "clock\t\t: %dMHz\n", freq / =
1000000);
> diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c=20
> b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
> --- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c=A0=A0=A0=A0=A0 =
2005-03-18=20
> 18:17:16 -06:00
> +++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c=A0=A0=A0=A0=A0 =
2005-03-18=20
> 18:17:16 -06:00
> @@ -146,7 +146,6 @@
> =A0=A0=A0=A0=A0=A0=A0 pvid =3D mfspr(SPRN_PVR);
> =A0=A0=A0=A0=A0=A0=A0 svid =3D mfspr(SPRN_SVR);
> =A0
> -=A0=A0=A0=A0=A0=A0 seq_printf(m, "chip\t\t: MPC%s\n",=20
> cur_ppc_sys_spec->ppc_sys_name);
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "Vendor\t\t: Freescale =
Semiconductor\n");
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "Machine\t\t: CDS - MPC%s (%x)\n",=20=
> cur_ppc_sys_spec->ppc_sys_name, cadmus[CM_VER]);
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "clock\t\t: %dMHz\n", freq / =
1000000);
> diff -Nru a/arch/ppc/platforms/85xx/sbc85xx.c=20
> b/arch/ppc/platforms/85xx/sbc85xx.c
> --- a/arch/ppc/platforms/85xx/sbc85xx.c 2005-03-18 18:17:16 -06:00
> +++ b/arch/ppc/platforms/85xx/sbc85xx.c 2005-03-18 18:17:16 -06:00
> @@ -129,7 +129,6 @@
> =A0=A0=A0=A0=A0=A0=A0 pvid =3D mfspr(SPRN_PVR);
> =A0=A0=A0=A0=A0=A0=A0 svid =3D mfspr(SPRN_SVR);
> =A0
> -=A0=A0=A0=A0=A0=A0 seq_printf(m, "chip\t\t: MPC%s\n",=20
> cur_ppc_sys_spec->ppc_sys_name);
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "Vendor\t\t: Wind River\n");
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "Machine\t\t: SBC%s\n",=20
> cur_ppc_sys_spec->ppc_sys_name);
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "clock\t\t: %dMHz\n", freq / =
1000000);
> diff -Nru a/arch/ppc/platforms/85xx/stx_gp3.c=20
> b/arch/ppc/platforms/85xx/stx_gp3.c
> --- a/arch/ppc/platforms/85xx/stx_gp3.c 2005-03-18 18:17:16 -06:00
> +++ b/arch/ppc/platforms/85xx/stx_gp3.c 2005-03-18 18:17:16 -06:00
> @@ -268,7 +268,6 @@
> =A0
> =A0=A0=A0=A0=A0=A0=A0 memsize =3D total_memory;
> =A0
> -=A0=A0=A0=A0=A0=A0 seq_printf(m, "chip\t\t: MPC%s\n",=20
> cur_ppc_sys_spec->ppc_sys_name);
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "Vendor\t\t: RPC Electronics STx =
\n");
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "Machine\t\t: GP3 - MPC%s\n",=20
> cur_ppc_sys_spec->ppc_sys_name);
> =A0=A0=A0=A0=A0=A0=A0 seq_printf(m, "bus freq\t: %u.%.6u MHz\n", freq =
/ 1000000,
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] ppc32: typo fix in load/store string emulation
From: Kumar Gala @ 2005-03-21 15:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Segher Boessenkool, linuxppc-embedded
In-Reply-To: <34e690a54bb55ad44bb2518e1d7bf4f3@freescale.com>
Andrew,
Patch fixes a typo in the emulation of load/store string emulations
pointed out by Segher Boessenkool.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
--- a/arch/ppc/kernel/traps.c 2005-03-21 09:36:28 -06:00
+++ b/arch/ppc/kernel/traps.c 2005-03-21 09:36:28 -06:00
@@ -412,7 +412,7 @@
return -EINVAL;
/* Early out if we are an invalid form of lswi */
- if ((instword & INST_STRING_MASK) == INST_LSWX)
+ if ((instword & INST_STRING_MASK) == INST_LSWI)
if ((rA >= rT) || (rT == rA))
return -EINVAL;
^ permalink raw reply
* Re: New PowerQUICC III support
From: Kumar Gala @ 2005-03-21 15:30 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-embedded
In-Reply-To: <1111395923.14412.23.camel@felix.allot.com>
Felix,
The expectation is that the existing gianfar driver should work on
8548. However until its tried out we will not know for sure.
- kumar
On Mar 21, 2005, at 3:05 AM, Felix Radensky wrote:
> Hi, Kumar
>
> Thanks for answering. There isn't much info regarding new PQ3 chips on
> Freescale site, so It's hard to tell how similar they are to
> 8540/8560.
> I'm interested in basic support and Gigabit ethernet driver. Are you
> saying
> that gianfar driver will work with new PQ3 chips ?
>
> Thanks a lot.
>
> Felix.
>
> On Sun, 2005-03-20 at 12:43 -0600, Kumar Gala wrote:
>
> Felix,
>
> Is there something specific about the new PQ3 chips you are looking
> for? The basic support that is in the kernel for the existing PQ3
> line
> (8540, 8541, 8555, 8560) should work on these devices w/o much change.
>
> - kumar
>
> On Mar 20, 2005, at 4:09 AM, Felix Radensky wrote:
>
> > Hi, folks
> >
> > Are there any plans to support new PowerQUICC III models (e.g.
> 8543,
> > 8548)
> > in the near future ? Is anyone working on it ?
> >
> > TIA.
> >
> > Felix. <ATT325611.txt>
>
>
^ permalink raw reply
* Re: [PATCH] ppc32: emulate load/store string instructions
From: Kumar Gala @ 2005-03-21 15:29 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Andrew Morton, linux-kernel, Kumar Gala, linuxppc-embedded
In-Reply-To: <43b769d454b49bc3f33414912c7fa3ab@kernel.crashing.org>
Thanks, will send a patch to fix that.
- kumar
On Mar 19, 2005, at 8:36 AM, Segher Boessenkool wrote:
>> + /* Early out if we are an invalid form of lswi */
>> + if ((instword & INST_STRING_MASK) == INST_LSWX)
>
> Typo --------------------------------------------^
>
>
> Segher
^ permalink raw reply
* [PATCH] ppc44x: Remove PVR_440G* and change usages
From: Tom Rini @ 2005-03-21 15:27 UTC (permalink / raw)
To: Matt Porter, linuxppc-embedded
The following patch changes the usages of PVR_440* into strcmp's with
the cpu_name field, and removes the defines altogether. The Ebony
portion was briefly tested.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
arch/ppc/platforms/4xx/ebony.c | 13 ++++---------
arch/ppc/syslib/ibm440gx_common.c | 7 ++++---
include/asm-ppc/reg.h | 6 ------
3 files changed, 8 insertions(+), 18 deletions(-)
--- 1.11/arch/ppc/platforms/4xx/ebony.c 2005-03-04 23:41:48 -07:00
+++ edited/arch/ppc/platforms/4xx/ebony.c 2005-03-08 15:22:19 -07:00
@@ -97,15 +97,10 @@
* on Rev. C silicon then errata forces us to
* use the internal clock.
*/
- switch (PVR_REV(mfspr(PVR))) {
- case PVR_REV(PVR_440GP_RB):
- freq = EBONY_440GP_RB_SYSCLK;
- break;
- case PVR_REV(PVR_440GP_RC1):
- default:
- freq = EBONY_440GP_RC_SYSCLK;
- break;
- }
+ if (strcmp(cur_cpu_spec[0]->cpu_name, "440GP Rev. B") == 0)
+ freq = EBONY_440GP_RB_SYSCLK;
+ else
+ freq = EBONY_440GP_RC_SYSCLK;
ibm44x_calibrate_decr(freq);
}
--- 1.3/arch/ppc/syslib/ibm440gx_common.c 2004-11-07 19:08:31 -07:00
+++ edited/arch/ppc/syslib/ibm440gx_common.c 2005-03-21 08:20:17 -07:00
@@ -221,9 +221,10 @@
/* Disable L2C on rev.A, rev.B and 800MHz version of rev.C,
enable it on all other revisions
*/
- u32 pvr = mfspr(PVR);
- if (pvr == PVR_440GX_RA || pvr == PVR_440GX_RB ||
- (pvr == PVR_440GX_RC && p->cpu > 667000000))
+ if (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. A") == 0 ||
+ strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. B") == 0
+ || (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. C")
+ == 0 && p->cpu > 667000000))
ibm440gx_l2c_disable();
else
ibm440gx_l2c_enable();
--- 1.16/include/asm-ppc/reg.h 2005-03-04 23:41:17 -07:00
+++ edited/include/asm-ppc/reg.h 2005-03-21 08:21:22 -07:00
@@ -449,12 +449,6 @@
#define PVR_STB03XXX 0x40310000
#define PVR_NP405H 0x41410000
#define PVR_NP405L 0x41610000
-#define PVR_440GP_RB 0x40120440
-#define PVR_440GP_RC1 0x40120481
-#define PVR_440GP_RC2 0x40200481
-#define PVR_440GX_RA 0x51b21850
-#define PVR_440GX_RB 0x51b21851
-#define PVR_440GX_RC 0x51b21892
#define PVR_601 0x00010000
#define PVR_602 0x00050000
#define PVR_603 0x00030000
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] ppc32: emulate load/store string instructions
From: Segher Boessenkool @ 2005-03-19 14:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, linux-kernel, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0503111609001.9384@blarg.somerset.sps.mot.com>
> + /* Early out if we are an invalid form of lswi */
> + if ((instword & INST_STRING_MASK) == INST_LSWX)
Typo --------------------------------------------^
Segher
^ permalink raw reply
* Re: mtd maps
From: Jörn Engel @ 2005-03-21 12:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <1110936813.28218.21.camel@jdub.homelinux.org>
On Tue, 15 March 2005 19:33:33 -0600, Josh Boyer wrote:
>
> There is a driver in MTD CVS now called mphysmap (untested I believe),
> that might be able to deal with that. Eventually.
If someone has the need and a test machine with remote access, it
could get done rather soon.
Jörn
--
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth
^ permalink raw reply
* Re: Wakeup broken on iBook G3
From: Benjamin Herrenschmidt @ 2005-03-21 12:22 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list
In-Reply-To: <jey8che16m.fsf@sykes.suse.de>
On Mon, 2005-03-21 at 11:35 +0100, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > What video chip is this ?
>
> Radeon Mobility M7 LY
>
> > And what CPU ?
>
> 750FX
>
> > Are you sure it's the radeonfb patch ?
>
> It's hard to tell. I tried going back to the 2.6.10 radeon driver, but
> that doesn't have the necessary hooks to tell the PM code that it can
> sleep. If you can give a hint how to forward port that I can give it a
> try.
>
> > There is also an old problem with AGP and sleep that is coming & going
> > lately. Can you check if it works if you never go to X ?
>
> Did that, same problem.
Can you try playing with pmac_sleep.S and pmac_cache.S, basically
reverting those including the calls to set_L2CR in via-pmu.c ?
Ben.
^ permalink raw reply
* DS1306 RTC
From: Frédéric Savane @ 2005-03-21 10:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 1567 bytes --]
^ permalink raw reply
* Re: Wakeup broken on iBook G3
From: Andreas Schwab @ 2005-03-21 10:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1111377588.3835.258.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> What video chip is this ?
Radeon Mobility M7 LY
> And what CPU ?
750FX
> Are you sure it's the radeonfb patch ?
It's hard to tell. I tried going back to the 2.6.10 radeon driver, but
that doesn't have the necessary hooks to tell the PM code that it can
sleep. If you can give a hint how to forward port that I can give it a
try.
> There is also an old problem with AGP and sleep that is coming & going
> lately. Can you check if it works if you never go to X ?
Did that, same problem.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: New PowerQUICC III support
From: Felix Radensky @ 2005-03-21 9:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <b8995d61612e5e38680a3ce37fcd7dcc@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
Hi, Kumar
Thanks for answering. There isn't much info regarding new PQ3 chips on
Freescale site, so It's hard to tell how similar they are to 8540/8560.
I'm interested in basic support and Gigabit ethernet driver. Are you
saying
that gianfar driver will work with new PQ3 chips ?
Thanks a lot.
Felix.
On Sun, 2005-03-20 at 12:43 -0600, Kumar Gala wrote:
> Felix,
>
> Is there something specific about the new PQ3 chips you are looking
> for? The basic support that is in the kernel for the existing PQ3 line
> (8540, 8541, 8555, 8560) should work on these devices w/o much change.
>
> - kumar
>
> On Mar 20, 2005, at 4:09 AM, Felix Radensky wrote:
>
> > Hi, folks
> >
> > Are there any plans to support new PowerQUICC III models (e.g. 8543,
> > 8548)
> > in the near future ? Is anyone working on it ?
> >
> > TIA.
> >
> > Felix. <ATT325611.txt>
>
[-- Attachment #2: Type: text/html, Size: 1616 bytes --]
^ permalink raw reply
* Re: Wakeup broken on iBook G3
From: Benjamin Herrenschmidt @ 2005-03-21 3:59 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list
In-Reply-To: <jed5tuqlp1.fsf@sykes.suse.de>
On Sun, 2005-03-20 at 18:19 +0100, Andreas Schwab wrote:
> Ever since the massive changes to the radeonfb pm code I've never been
> able to get a working wakeup on my iBook G3. The screen keeps blank after
> wakeup, I hear the cdrom drive being reset, and then the system crashes
> hard.
What video chip is this ? And what CPU ? Are you sure it's the radeonfb
patch ? There have been other changes to the system PM code
approximately at the same time. The "massive" PM change didn't really
change what was done to the vidoe chip on older models (mostly _added_
new code, totally separate, for new models). I suspect for example a
problem with the cache flush code in pmac_cache.S on some G3 CPUs ...
There is also an old problem with AGP and sleep that is coming & going
lately. Can you check if it works if you never go to X ? (That is boot
in console mode, do not ever launch X, launching X and quitting X breaks
the test I want you to do, then suspend/resume).
Ben.
^ 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