* moving from devfs to udev with 2.6 kernel on 8xx board?
From: Robert P. J. Day @ 2005-04-11 13:37 UTC (permalink / raw)
To: Embedded PPC Linux list
since i don't have enough anguish in my life, i thought i might take
today to see if i can migrate from devfs to udev on my 8xx board. at
the moment, with a 2.6.11.7 kernel, i have:
busybox-1.00
networking with the I2C/SPI/SMC1 patch installed
devfs
JFFS2 support in kernel (but no partition definition yet)
before i start reading up on udev, any guidance on whether this will
be straightforward, or will i want to slit my wrists by lunch time?
thanks.
rday
^ permalink raw reply
* RE: [PATCH] RE: FCC Ethernet startup crash
From: Rune Torgersen @ 2005-04-11 13:51 UTC (permalink / raw)
To: Stefan Nickl; +Cc: Tom Rini, linuxppc-embedded
=20
> -----Original Message-----
> From: Stefan Nickl [mailto:Stefan.Nickl@kontron.com]=20
> Sent: Monday, April 11, 2005 04:20
> On Fri, 2005-04-08 at 09:39 -0500, Rune Torgersen wrote:
> > I'm not sure what is going on, but that patch causes me to=20
> get "eth0: tx
> > queue full!." messages as soon as I try to use the ethernet
> > (Same thing happened if I just tried to remove the fcc_restart from
> > init_fcc_startup)
> But regarding my current indisposition with hardware, I'd suggest to
> choose the smaller of the two evils, that is calling fcc_restart()
> before starting the queue, leaving but a tiny race condition=20
> on rx side.
Still get the tx full messages.
They do go away if I call fcc_restart twice in a row... (again)=09
I'll look a little more on what it is doing
^ permalink raw reply
* Re: [PATCH] pmac: Improve sleep code of tumbler driver
From: Takashi Iwai @ 2005-04-11 13:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113184854.9567.522.camel@gaston>
At Mon, 11 Apr 2005 12:00:54 +1000,
Benjamin Herrenschmidt wrote:
>
> Hi !
>
> This patch (applies on top of my previous one adding support for newer
> machines) improves the behaviour of the "tumbler/snapper" driver used on
> newer PowerMacs during sleep. It properly set the HW mutes to shut down
> amplifiers and does an analog shutdown of the codec. That might improve
> power consumption during sleep on a number of machines.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Great! I applied to ALSA tree now.
Takashi
^ permalink raw reply
* [PATCH] PPC44x: Fixes early bootup messages for Bamboo
From: Gerhard Jaeger @ 2005-04-11 14:17 UTC (permalink / raw)
To: linuxppc-embedded
While playing around with the Bamboo board (440EP based), I noticed,
that the early bootup messages won't work, because of the wrong TLB
setup for this processor. This patch fixes that issue.
-Gerhard
Signed-off-by: Gerhard Jaeger <gjaeger@sysgo.com>
--- linux-2.6.11/arch/ppc/kernel/head_44x.S.orig 2005-04-11 15:49:47.000000000 +0200
+++ linux-2.6.11/arch/ppc/kernel/head_44x.S 2005-04-11 15:50:43.000000000 +0200
@@ -190,7 +190,9 @@ skpinv: addi r4,r4,1 /* Increment */
/* xlat fields */
lis r4,UART0_PHYS_IO_BASE@h /* RPN depends on SoC */
+#ifndef CONFIG_440EP
ori r4,r4,0x0001 /* ERPN is 1 for second 4GB page */
+#endif /* CONFIG_440EP */
/* attrib fields */
li r5,0
^ permalink raw reply
* RE: [PATCH] RE: FCC Ethernet startup crash
From: Rune Torgersen @ 2005-04-11 14:40 UTC (permalink / raw)
To: Stefan Nickl; +Cc: Tom Rini, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
Found a soulution.
Still have no idea about the cause.
The part that had to be called twice toget the ethernet to work was
/* Enable transmit/receive */
fccp->fcc_gfmr |= FCC_GFMR_ENR | FCC_GFMR_ENT;
So I added that to the end of init_fcc_startup(), and kept the rest of
the patch the same as v1 (or v2)
None of the interrupts are enabled at this time, so any spurious packets
will not get reported up to IP layer anyways.
This works on my hardware. (tested with ping -f)
Signed-off-by: Rune Torgersen <runet@innovsys.com>
[-- Attachment #2: fcc_enet_startup_crash_v4.patch --]
[-- Type: application/octet-stream, Size: 1798 bytes --]
===== arch/ppc/8260_io/fcc_enet.c 1.24 vs edited =====
--- 1.24/arch/ppc/8260_io/fcc_enet.c 2005-03-18 14:51:31 -06:00
+++ edited/arch/ppc/8260_io/fcc_enet.c 2005-04-11 09:34:10 -05:00
@@ -2159,15 +2159,8 @@
*(volatile uint *)(BCSR_ADDR + 12) |= BCSR3_FETH2_RST;
#endif
-#if defined(CONFIG_USE_MDIO) || defined(CONFIG_TQM8260)
- /* start in full duplex mode, and negotiate speed
- */
- fcc_restart (dev, 1);
-#else
- /* start in half duplex mode
- */
- fcc_restart (dev, 0);
-#endif
+ /* Enable transmit/receive */
+ fccp->fcc_gfmr |= FCC_GFMR_ENR | FCC_GFMR_ENT;
}
#ifdef CONFIG_USE_MDIO
@@ -2372,24 +2365,28 @@
fep->sequence_done = 0;
fep->link = 0;
- if (fep->phy) {
- fcc_restart(dev, 0); /* always start in half-duplex */
- mii_do_cmd(dev, fep->phy->ack_int);
- mii_do_cmd(dev, fep->phy->config);
- mii_do_cmd(dev, phy_cmd_config); /* display configuration */
- while(!fep->sequence_done)
- schedule();
-
- mii_do_cmd(dev, fep->phy->startup);
- netif_start_queue(dev);
- return 0; /* Success */
- }
- return -ENODEV; /* No PHY we understand */
+ if (!fep->phy)
+ return -ENODEV; /* No PHY we understand */
+
+ mii_do_cmd(dev, fep->phy->ack_int);
+ mii_do_cmd(dev, fep->phy->config);
+ mii_do_cmd(dev, phy_cmd_config); /* display configuration */
+ while(!fep->sequence_done)
+ schedule();
+
+ mii_do_cmd(dev, fep->phy->startup);
#else
fep->link = 1;
- fcc_restart(dev, 0); /* always start in half-duplex */
- netif_start_queue(dev);
- return 0; /* Always succeed */
#endif /* CONFIG_USE_MDIO */
+
+ netif_start_queue(dev);
+
+#if defined(CONFIG_USE_MDIO) || defined(CONFIG_TQM8260)
+ fcc_restart (dev, 1); /* start in full duplex mode */
+#else
+ fcc_restart (dev, 0); /* start in half duplex mode */
+#endif
+
+ return 0; /* Always succeed */
}
^ permalink raw reply
* Re: [PATCH] pmac: sound support for latest laptops
From: Takashi Iwai @ 2005-04-11 14:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113113792.9517.476.camel@gaston>
At Sun, 10 Apr 2005 16:16:32 +1000,
Benjamin Herrenschmidt wrote:
>
> Hi !
>
> This patch hacks the current Alsa snd-powermac driver to add support for
> recent machine models with the tas3004 chip, that is basically new
> laptop models. The Mac Mini is _NOT_ yet supported by this patch (soon
> soon ...). The G5s (iMac or Desktop) will need the rewritten sound
> driver on which I'm working on (I _might_ get a hack for analog only on
> some G5s on the current driver, but no promise).
Thanks. I applied this to ALSA tree (together with your another patch
for tumbler).
Takashi
^ permalink raw reply
* Re: [PATCH] pmac: sound support for latest laptops
From: Johannes Berg @ 2005-04-11 15:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Takashi Iwai, linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113113792.9517.476.camel@gaston>
Hi,
>This patch hacks the current Alsa snd-powermac driver to add support for
>recent machine models with the tas3004 chip, that is basically new
>laptop models. The Mac Mini is _NOT_ yet supported by this patch (soon
>soon ...). The G5s (iMac or Desktop) will need the rewritten sound
>driver on which I'm working on (I _might_ get a hack for analog only on
>some G5s on the current driver, but no promise).
>
>
That's cool. I do have one slight problem with it though: When I turn
down the Master mixer and up PCM it sounds badly overmodulated. I can
keep PCM at about 75% and turn up master, and all is fine. Would it make
sense to limit the PCM mixer to about 75% of its current limits, or how
does that actually work in the hardware?
johannes
^ permalink raw reply
* Re: [PATCH] pmac: sound support for latest laptops
From: Takashi Iwai @ 2005-04-11 15:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: debian-powerpc@lists.debian.org, linuxppc-dev list
In-Reply-To: <425A92B1.6080907@sipsolutions.net>
At Mon, 11 Apr 2005 17:07:29 +0200,
Johannes Berg wrote:
>
> Hi,
>
> >This patch hacks the current Alsa snd-powermac driver to add support for
> >recent machine models with the tas3004 chip, that is basically new
> >laptop models. The Mac Mini is _NOT_ yet supported by this patch (soon
> >soon ...). The G5s (iMac or Desktop) will need the rewritten sound
> >driver on which I'm working on (I _might_ get a hack for analog only on
> >some G5s on the current driver, but no promise).
> >
> >
> That's cool. I do have one slight problem with it though: When I turn
> down the Master mixer and up PCM it sounds badly overmodulated. I can
> keep PCM at about 75% and turn up master, and all is fine. Would it make
> sense to limit the PCM mixer to about 75% of its current limits, or how
> does that actually work in the hardware?
This sounds like a problem sometimes seen in devices with a codec that
amplifies (+dB) over a certain level. Some ac97 codecs have the same
problem, too.
Takashi
^ permalink raw reply
* Re: [PATCH] invalid instructions in kernel mode
From: Kumar Gala @ 2005-04-11 15:39 UTC (permalink / raw)
To: Dan Malek, Fillod Stephane; +Cc: linuxppc-dev list
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D4F0D39@rennsmail02.eu.thmulti.com>
Ok,
After some debug on Friday and this weekend I understand what's going=20
on. The reason we hit the code path in the kernel is due to the fact=20
that we are actually executing an integer load/store that is=20
misaligned, however when we read the instruction from memory we get a=20
float point instruction. This is due to the fact that test app is not=20=
properly handling its self generated code.
Note, I was testing with math-emu turned on.
It seems to me that when we introduce CONFIG_PPC_FPU that we ifdef=20
around the code and return 0 in the 44x/e500 cases w/o FPUs
- kumar
On Apr 8, 2005, at 12:36 PM, Fillod Stephane wrote:
> Kumar Gala wrote:
> > Are you running this via a ramdisk or nfs?=A0 If ramdisk can you =
post=20
> it
>
> > somewhere that I can get to?
>
> I'm running via NFS.
>
> > Also, can you email the list with the kernel oops that shows up.
>
> I'll do that next week.
>
> Anyway, reading the source suffices to realize there's a problem when
> MATH_EMULATION is disabled on a FPU-less system with user programs
> using load/store fp instructions.
>
> --=20
> Stephane
^ permalink raw reply
* Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
From: Jon Loeliger @ 2005-04-11 15:58 UTC (permalink / raw)
To: Tom Rini
Cc: Jon Masters, Andrei Konovalov, Sylvain Munaut,
Linux PPC Embedded list, Jakob Viketoft
In-Reply-To: <20050407174936.GR3396@smtp.west.cox.net>
On Thu, 2005-04-07 at 12:49, Tom Rini wrote:
> Please post to the list as an RFC. Thanks.
Folks,
Apologies to those who have received this notice twice.
I first sent it to the list where it was summarily
denied for size reasons.
I have now posted a tgz file here instead:
http://www.jdl.com/bdt_cleanup.tgz
What follows is my original email content.
OK, for those keeping score over on the U-Boot list, _this_
message is really intended to be sent to the public list. :-)
Here (as noted above) are my diffs against a clone of
http://linux.bkbits.net/linux-2.6
as last pulled a couple days ago. (*)
Please consider this a Request For Comments for now. Feel free
to apply it and test it out as well, of course. :-) I'll sign-off
on it when it has ripened some more and gets a nod or two...
These changes relocate almost all of the ppcboot.h definitions
into new files, arc/ppc/syslib/fw_bdt.[ch] and front them
with a new, shim interface in include/asm-ppc/firmware.h.
There is a Kconfig option that allows you to select between
a "bd_t" interface and a non-existant "OF Flat dev tree"
interface. Choose wisely (default) for now. It adds the
new fw_bdt.o file.
Some potential gotchas or points to note:
- As of this patch, no interface to any board should change.
This just isolates the scattered bd_t references to one place.
- On Kumar's advice arch/ppc/boot/simple was totally ignored.
For now; this round. It can be next on the hit parade easily.
It holds the last reference to ppcboot.h still.
- Earlier cut-n-paste of some devices led to me changing a few
files over in 68k land to remove some now-obsolete ppcboot.h
related comments justs for completeness.
- I've compiled uImage using defconfigs for the following boards:
8560_ads cpci690 ash redwood5
8540_ads ads_8272 TQM8260 est8260
rpx8260 bseip mbx mpc834x_sys
ocotea lite5200 hdpu lopec
TQM860L rpxlite radstone_ppc7d walnut
- The file include/asm-ppc/ppcboot.h used to contain a nested
include of linux/types.h that was tacitly used by many files.
In ripping ppcboot.h out of many platform .h files, I've had
to add direct #include <linux/types.h> in several places.
If your board isn't listed above and it looks really broken,
consider if it needs a <linux/types.h>?
Enjoy,
jdl
--
(*) -- BK is dead. Long live BK!
^ permalink raw reply
* Re: moving from devfs to udev with 2.6 kernel on 8xx board?
From: Andre' Draszik @ 2005-04-11 15:08 UTC (permalink / raw)
To: Embedded PPC Linux list
In-Reply-To: <Pine.LNX.4.61.0504110931540.6667@localhost.localdomain>
Hi,
Robert P. J. Day wrote:
> before i start reading up on udev, any guidance on whether this will
> be straightforward, or will i want to slit my wrists by lunch time?
> thanks.
for me, this was quite straightforward on a 405 board. you should
remeber to create two device nodes in your filesystem, though:
crw-rw---- 1 root root 5, 1 2005-04-04 04:03 console
crw-rw-rw- 1 root root 1, 3 2005-02-20 11:39 null
else it won't work...
one thing to note is that udev is quite slow on bootup (at least here).
after init is started some initial device nodes are created, this takes
like 5 to 10 seconds here. i don't know if there is a way to decrease
that time:
Freeing unused kernel memory: 92k init
INIT: version 2.86 booting
Mounting a tmpfs over /dev...done.
Creating initial device nodes...done.
that is a bit annoying... but i didn't put any energy in resolving that
issue yet, so maybe it's easy ;)
hth,
andre
^ permalink raw reply
* RE: cross-compiling under cygwin?
From: Howard, Marc @ 2005-04-11 18:30 UTC (permalink / raw)
To: Embedded PPC Linux list
Wolfgang,
It has a /dev filesystem but exporting it doesn't work. Yes, user and
group ids are supported and it can either be from group/passwd files or
NIS. It does have hard and soft links. It is a pretty extensive port
(formerly known as Internix).
It is a solution for environments that have IT departments full of
Micro$soft trained robots located an ocean away who will only allow
installation of Redmond-blessed add-ons.
I'm not pushing it as a solution but it is a free way to have a mount a
NFS-style filesystem on an embedded linux board. I believe I did
mention that I disliked recommending it but to deny it exists would be
censorship.
Marc W. Howard
> -----Original Message-----
> From: wd@denx.de [mailto:wd@denx.de]=20
> Sent: Sunday, April 10, 2005 9:59 AM
> To: Howard, Marc
> Cc: Embedded PPC Linux list
> Subject: Re: cross-compiling under cygwin?=20
>=20
> In message=20
> <91B22F93A880FA48879475E134D6F0BEB9C02A@CA1EXCLV02.adcorp.kla-
> tencor.com> you wrote:
> >=20
> > Yes you can run NFS on Windows. The systems we ship inside our
> > equipment have a Win2k Server host and the embedded boards=20
> hang off of
>=20
> And this really supports things like special files, user and group
> id's, permissions including set-uid and hardlinks and all that?
>=20
> Best regards,
>=20
> Wolfgang Denk
>=20
> --=20
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> Hello! I'm from outer space, and I've made myself look like a signa-
> ture. While you are reading this, I'm having sex with your eyes. I
> know it feels good to you, because you're smiling. I'm very horny, so
> send me to someone else when you've had enough. Thanks!
> Sincerely, A Stranger in a Strange Land
>=20
^ permalink raw reply
* Eliminating RTC from MPC5200
From: Grant Likely @ 2005-04-11 18:30 UTC (permalink / raw)
To: linuxppc-embedded
I'm working on a design using the MPC5200. The hardware engineer I'm
working has asked if he could omit the crystal for the RTC. I've
searched through the Linux source (2.6.11) and it seems that the on
the lite5200 the RTC is being used to measure both the system clock
and the decrementer speed for the serial port. It does not look like
the RTC is used otherwise.
Is this true? Can I eliminate the need for the RTC If I modify
mpc52xx_calibrate_decr() in arch/ppc/syslib/mpc52xx_setup.c and
mpc52xx_ipbfreq() in arch/ppc/boot/simple/mpc52xx_tty.c? I'm assuming
that I can hard code the system clock speeds for my specific hardware.
Thanks,
g.
^ permalink raw reply
* Re: Best way to determine tb_ticks_per_jiffy inside todc_calibrate_decr()
From: Mark A. Greer @ 2005-04-11 18:39 UTC (permalink / raw)
To: Daniel Ann; +Cc: linuxppc-embedded
In-Reply-To: <9b7ca6570504081829cb84a7d@mail.gmail.com>
Daniel Ann wrote:
>On Apr 9, 2005 3:32 AM, Mark A. Greer <mgreer@mvista.com> wrote:
>
>
>>Also, 33MHz does not sound right but then you don't say what processor
>>you're using so who knows. You need to find the bus freq used by the
>>cpu/system. Try looking for the freq of the processor's SYSCLK input.
>>Then you probably have to divide that by 4 to get the frequency that the
>>decrementer runs at. That's the value that you should use for the
>>'freq' variable in the example code you included in your email.
>>
>>
>
>Okay guess I had all these things mixed up in head. What I should have
>said is, source to PCI_SYNC_IN is 33MHz.
>
Ah, that sounds reasonable. ;)
>Anyway, following the MPC8245 hardware Spec pdf file, I was able to
>find the peripheral logic/memory bus clock to be 99,000,000. Dividing
>that by 4 like you said, gave me the value of 24,750,000. Which is
>I've used it to get very real 1 second :)
>
Cool.
>
>BTW, why do you have to divide it by 4 ?
>
Because the internally kept time in ppc linux is based on the
decrementer counter and, according to the manual for the 8245, the
decrementer counter is decremented once every four sys_logic_clk
cycles. Therefore, you need to divide by 4.
Mark
^ permalink raw reply
* Re: 824x Sandpoint with 2.6.x
From: Mark A. Greer @ 2005-04-11 18:46 UTC (permalink / raw)
To: Sam Song; +Cc: linuxppc-embedded
In-Reply-To: <20050411092829.44092.qmail@web15809.mail.cnb.yahoo.com>
Sam Song wrote:
>Hi all,
>
>I'd like to know where I could get a good start on
>824x Sandpoint board with 2.6.x? Is linuxppc-2.5 BK
>tree nice for me to work?
>
>
No. Use linux-2.5/6.
Mark
^ permalink raw reply
* Re: [PATCH] pmac: Improve sleep code of tumbler driver
From: Vincent Lefevre @ 2005-04-11 19:42 UTC (permalink / raw)
To: Colin Leroy
Cc: Andrew Morton, debian-powerpc@lists.debian.org, Takashi Iwai,
linuxppc-dev list
In-Reply-To: <20050411101853.7f0e9385@colin.toulouse>
On 2005-04-11 10:18:53 +0200, Colin Leroy wrote:
> I suppose it also fixes the occasionnal loud static noise that
> sometimes at wakeup, for example on iBook G4s. Good :)
Could this be related to this bug?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=244467
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
^ permalink raw reply
* [PATCH] ppc32: refactor FPU exception handling
From: Kumar Gala @ 2005-04-11 22:02 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev, Jason McMullan, linux-kernel, linuxppc-embedded
Andrew,
Moved common FPU exception handling code out of head.S so it can be used
by several of the sub-architectures that might of a full PowerPC FPU.
Also, uses new CONFIG_PPC_FPU define to fix alignment exception
handling for floating point load/store instructions to only occur if we
have a hardware FPU.
Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig 2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/Kconfig 2005-04-11 17:00:36 -05:00
@@ -53,6 +53,7 @@
config 6xx
bool "6xx/7xx/74xx/52xx/82xx/83xx"
+ select PPC_FPU
help
There are four types of PowerPC chips supported. The more common
types (601, 603, 604, 740, 750, 7400), the Motorola embedded
@@ -85,6 +86,9 @@
bool "e500"
endchoice
+
+config PPC_FPU
+ bool
config BOOKE
bool
diff -Nru a/arch/ppc/Makefile b/arch/ppc/Makefile
--- a/arch/ppc/Makefile 2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/Makefile 2005-04-11 17:00:36 -05:00
@@ -53,6 +53,7 @@
head-$(CONFIG_6xx) += arch/ppc/kernel/idle_6xx.o
head-$(CONFIG_POWER4) += arch/ppc/kernel/idle_power4.o
+head-$(CONFIG_PPC_FPU) += arch/ppc/kernel/fpu.o
core-y += arch/ppc/kernel/ arch/ppc/platforms/ \
arch/ppc/mm/ arch/ppc/lib/ arch/ppc/syslib/
diff -Nru a/arch/ppc/kernel/Makefile b/arch/ppc/kernel/Makefile
--- a/arch/ppc/kernel/Makefile 2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/kernel/Makefile 2005-04-11 17:00:36 -05:00
@@ -9,6 +9,7 @@
extra-$(CONFIG_8xx) := head_8xx.o
extra-$(CONFIG_6xx) += idle_6xx.o
extra-$(CONFIG_POWER4) += idle_power4.o
+extra-$(CONFIG_PPC_FPU) += fpu.o
extra-y += vmlinux.lds
obj-y := entry.o traps.o irq.o idle.o time.o misc.o \
diff -Nru a/arch/ppc/kernel/align.c b/arch/ppc/kernel/align.c
--- a/arch/ppc/kernel/align.c 2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/kernel/align.c 2005-04-11 17:00:36 -05:00
@@ -368,16 +368,24 @@
/* Single-precision FP load and store require conversions... */
case LD+F+S:
+#ifdef CONFIG_PPC_FPU
preempt_disable();
enable_kernel_fp();
cvt_fd(&data.f, &data.d, ¤t->thread.fpscr);
preempt_enable();
+#else
+ return 0;
+#endif
break;
case ST+F+S:
+#ifdef CONFIG_PPC_FPU
preempt_disable();
enable_kernel_fp();
cvt_df(&data.d, &data.f, ¤t->thread.fpscr);
preempt_enable();
+#else
+ return 0;
+#endif
break;
}
diff -Nru a/arch/ppc/kernel/fpu.S b/arch/ppc/kernel/fpu.S
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/kernel/fpu.S 2005-04-11 17:00:36 -05:00
@@ -0,0 +1,190 @@
+/*
+ * FPU support code, moved here from head.S so that it can be used
+ * by chips which use other head-whatever.S files.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include <linux/config.h>
+#include <asm/processor.h>
+#include <asm/page.h>
+#include <asm/mmu.h>
+#include <asm/pgtable.h>
+#include <asm/cputable.h>
+#include <asm/cache.h>
+#include <asm/thread_info.h>
+#include <asm/ppc_asm.h>
+#include <asm/offsets.h>
+
+/*
+ * This task wants to use the FPU now.
+ * On UP, disable FP for the task which had the FPU previously,
+ * and save its floating-point registers in its thread_struct.
+ * Load up this task's FP registers from its thread_struct,
+ * enable the FPU for the current task and return to the task.
+ */
+ .globl load_up_fpu
+load_up_fpu:
+ mfmsr r5
+ ori r5,r5,MSR_FP
+#ifdef CONFIG_PPC64BRIDGE
+ clrldi r5,r5,1 /* turn off 64-bit mode */
+#endif /* CONFIG_PPC64BRIDGE */
+ SYNC
+ MTMSRD(r5) /* enable use of fpu now */
+ isync
+/*
+ * For SMP, we don't do lazy FPU switching because it just gets too
+ * horrendously complex, especially when a task switches from one CPU
+ * to another. Instead we call giveup_fpu in switch_to.
+ */
+#ifndef CONFIG_SMP
+ tophys(r6,0) /* get __pa constant */
+ addis r3,r6,last_task_used_math@ha
+ lwz r4,last_task_used_math@l(r3)
+ cmpwi 0,r4,0
+ beq 1f
+ add r4,r4,r6
+ addi r4,r4,THREAD /* want last_task_used_math->thread */
+ SAVE_32FPRS(0, r4)
+ mffs fr0
+ stfd fr0,THREAD_FPSCR-4(r4)
+ lwz r5,PT_REGS(r4)
+ add r5,r5,r6
+ lwz r4,_MSR-STACK_FRAME_OVERHEAD(r5)
+ li r10,MSR_FP|MSR_FE0|MSR_FE1
+ andc r4,r4,r10 /* disable FP for previous task */
+ stw r4,_MSR-STACK_FRAME_OVERHEAD(r5)
+1:
+#endif /* CONFIG_SMP */
+ /* enable use of FP after return */
+ mfspr r5,SPRN_SPRG3 /* current task's THREAD (phys) */
+ lwz r4,THREAD_FPEXC_MODE(r5)
+ ori r9,r9,MSR_FP /* enable FP for current */
+ or r9,r9,r4
+ lfd fr0,THREAD_FPSCR-4(r5)
+ mtfsf 0xff,fr0
+ REST_32FPRS(0, r5)
+#ifndef CONFIG_SMP
+ subi r4,r5,THREAD
+ sub r4,r4,r6
+ stw r4,last_task_used_math@l(r3)
+#endif /* CONFIG_SMP */
+ /* restore registers and return */
+ /* we haven't used ctr or xer or lr */
+ /* fall through to fast_exception_return */
+
+ .globl fast_exception_return
+fast_exception_return:
+#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
+ andi. r10,r9,MSR_RI /* check for recoverable interrupt */
+ beq 1f /* if not, we've got problems */
+#endif
+
+2: REST_4GPRS(3, r11)
+ lwz r10,_CCR(r11)
+ REST_GPR(1, r11)
+ mtcr r10
+ lwz r10,_LINK(r11)
+ mtlr r10
+ REST_GPR(10, r11)
+ mtspr SPRN_SRR1,r9
+ mtspr SPRN_SRR0,r12
+ REST_GPR(9, r11)
+ REST_GPR(12, r11)
+ lwz r11,GPR11(r11)
+ SYNC
+ RFI
+
+/* check if the exception happened in a restartable section */
+1: lis r3,exc_exit_restart_end@ha
+ addi r3,r3,exc_exit_restart_end@l
+ cmplw r12,r3
+ bge 3f
+ lis r4,exc_exit_restart@ha
+ addi r4,r4,exc_exit_restart@l
+ cmplw r12,r4
+ blt 3f
+ lis r3,fee_restarts@ha
+ tophys(r3,r3)
+ lwz r5,fee_restarts@l(r3)
+ addi r5,r5,1
+ stw r5,fee_restarts@l(r3)
+ mr r12,r4 /* restart at exc_exit_restart */
+ b 2b
+
+ .comm fee_restarts,4
+
+/* aargh, a nonrecoverable interrupt, panic */
+/* aargh, we don't know which trap this is */
+/* but the 601 doesn't implement the RI bit, so assume it's OK */
+3:
+BEGIN_FTR_SECTION
+ b 2b
+END_FTR_SECTION_IFSET(CPU_FTR_601)
+ li r10,-1
+ stw r10,TRAP(r11)
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ lis r10,MSR_KERNEL@h
+ ori r10,r10,MSR_KERNEL@l
+ bl transfer_to_handler_full
+ .long nonrecoverable_exception
+ .long ret_from_except
+
+/*
+ * FP unavailable trap from kernel - print a message, but let
+ * the task use FP in the kernel until it returns to user mode.
+ */
+ .globl KernelFP
+KernelFP:
+ lwz r3,_MSR(r1)
+ ori r3,r3,MSR_FP
+ stw r3,_MSR(r1) /* enable use of FP after return */
+ lis r3,86f@h
+ ori r3,r3,86f@l
+ mr r4,r2 /* current */
+ lwz r5,_NIP(r1)
+ bl printk
+ b ret_from_except
+86: .string "floating point used in kernel (task=%p, pc=%x)\n"
+ .align 4,0
+
+/*
+ * giveup_fpu(tsk)
+ * Disable FP for the task given as the argument,
+ * and save the floating-point registers in its thread_struct.
+ * Enables the FPU for use in the kernel on return.
+ */
+ .globl giveup_fpu
+giveup_fpu:
+ mfmsr r5
+ ori r5,r5,MSR_FP
+ SYNC_601
+ ISYNC_601
+ MTMSRD(r5) /* enable use of fpu now */
+ SYNC_601
+ isync
+ cmpwi 0,r3,0
+ beqlr- /* if no previous owner, done */
+ addi r3,r3,THREAD /* want THREAD of task */
+ lwz r5,PT_REGS(r3)
+ cmpwi 0,r5,0
+ SAVE_32FPRS(0, r3)
+ mffs fr0
+ stfd fr0,THREAD_FPSCR-4(r3)
+ beq 1f
+ lwz r4,_MSR-STACK_FRAME_OVERHEAD(r5)
+ li r3,MSR_FP|MSR_FE0|MSR_FE1
+ andc r4,r4,r3 /* disable FP for previous task */
+ stw r4,_MSR-STACK_FRAME_OVERHEAD(r5)
+1:
+#ifndef CONFIG_SMP
+ li r5,0
+ lis r4,last_task_used_math@ha
+ stw r5,last_task_used_math@l(r4)
+#endif /* CONFIG_SMP */
+ blr
diff -Nru a/arch/ppc/kernel/head.S b/arch/ppc/kernel/head.S
--- a/arch/ppc/kernel/head.S 2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/kernel/head.S 2005-04-11 17:00:36 -05:00
@@ -775,133 +775,6 @@
EXC_XFER_STD(0x480, UnknownException)
#endif /* CONFIG_PPC64BRIDGE */
-/*
- * This task wants to use the FPU now.
- * On UP, disable FP for the task which had the FPU previously,
- * and save its floating-point registers in its thread_struct.
- * Load up this task's FP registers from its thread_struct,
- * enable the FPU for the current task and return to the task.
- */
-load_up_fpu:
- mfmsr r5
- ori r5,r5,MSR_FP
-#ifdef CONFIG_PPC64BRIDGE
- clrldi r5,r5,1 /* turn off 64-bit mode */
-#endif /* CONFIG_PPC64BRIDGE */
- SYNC
- MTMSRD(r5) /* enable use of fpu now */
- isync
-/*
- * For SMP, we don't do lazy FPU switching because it just gets too
- * horrendously complex, especially when a task switches from one CPU
- * to another. Instead we call giveup_fpu in switch_to.
- */
-#ifndef CONFIG_SMP
- tophys(r6,0) /* get __pa constant */
- addis r3,r6,last_task_used_math@ha
- lwz r4,last_task_used_math@l(r3)
- cmpwi 0,r4,0
- beq 1f
- add r4,r4,r6
- addi r4,r4,THREAD /* want last_task_used_math->thread */
- SAVE_32FPRS(0, r4)
- mffs fr0
- stfd fr0,THREAD_FPSCR-4(r4)
- lwz r5,PT_REGS(r4)
- add r5,r5,r6
- lwz r4,_MSR-STACK_FRAME_OVERHEAD(r5)
- li r10,MSR_FP|MSR_FE0|MSR_FE1
- andc r4,r4,r10 /* disable FP for previous task */
- stw r4,_MSR-STACK_FRAME_OVERHEAD(r5)
-1:
-#endif /* CONFIG_SMP */
- /* enable use of FP after return */
- mfspr r5,SPRN_SPRG3 /* current task's THREAD (phys) */
- lwz r4,THREAD_FPEXC_MODE(r5)
- ori r9,r9,MSR_FP /* enable FP for current */
- or r9,r9,r4
- lfd fr0,THREAD_FPSCR-4(r5)
- mtfsf 0xff,fr0
- REST_32FPRS(0, r5)
-#ifndef CONFIG_SMP
- subi r4,r5,THREAD
- sub r4,r4,r6
- stw r4,last_task_used_math@l(r3)
-#endif /* CONFIG_SMP */
- /* restore registers and return */
- /* we haven't used ctr or xer or lr */
- /* fall through to fast_exception_return */
-
- .globl fast_exception_return
-fast_exception_return:
- andi. r10,r9,MSR_RI /* check for recoverable interrupt */
- beq 1f /* if not, we've got problems */
-2: REST_4GPRS(3, r11)
- lwz r10,_CCR(r11)
- REST_GPR(1, r11)
- mtcr r10
- lwz r10,_LINK(r11)
- mtlr r10
- REST_GPR(10, r11)
- mtspr SPRN_SRR1,r9
- mtspr SPRN_SRR0,r12
- REST_GPR(9, r11)
- REST_GPR(12, r11)
- lwz r11,GPR11(r11)
- SYNC
- RFI
-
-/* check if the exception happened in a restartable section */
-1: lis r3,exc_exit_restart_end@ha
- addi r3,r3,exc_exit_restart_end@l
- cmplw r12,r3
- bge 3f
- lis r4,exc_exit_restart@ha
- addi r4,r4,exc_exit_restart@l
- cmplw r12,r4
- blt 3f
- lis r3,fee_restarts@ha
- tophys(r3,r3)
- lwz r5,fee_restarts@l(r3)
- addi r5,r5,1
- stw r5,fee_restarts@l(r3)
- mr r12,r4 /* restart at exc_exit_restart */
- b 2b
-
- .comm fee_restarts,4
-
-/* aargh, a nonrecoverable interrupt, panic */
-/* aargh, we don't know which trap this is */
-/* but the 601 doesn't implement the RI bit, so assume it's OK */
-3:
-BEGIN_FTR_SECTION
- b 2b
-END_FTR_SECTION_IFSET(CPU_FTR_601)
- li r10,-1
- stw r10,TRAP(r11)
- addi r3,r1,STACK_FRAME_OVERHEAD
- li r10,MSR_KERNEL
- bl transfer_to_handler_full
- .long nonrecoverable_exception
- .long ret_from_except
-
-/*
- * FP unavailable trap from kernel - print a message, but let
- * the task use FP in the kernel until it returns to user mode.
- */
-KernelFP:
- lwz r3,_MSR(r1)
- ori r3,r3,MSR_FP
- stw r3,_MSR(r1) /* enable use of FP after return */
- lis r3,86f@h
- ori r3,r3,86f@l
- mr r4,r2 /* current */
- lwz r5,_NIP(r1)
- bl printk
- b ret_from_except
-86: .string "floating point used in kernel (task=%p, pc=%x)\n"
- .align 4,0
-
#ifdef CONFIG_ALTIVEC
/* Note that the AltiVec support is closely modeled after the FP
* support. Changes to one are likely to be applicable to the
@@ -1014,42 +887,6 @@
#endif /* CONFIG_SMP */
blr
#endif /* CONFIG_ALTIVEC */
-
-/*
- * giveup_fpu(tsk)
- * Disable FP for the task given as the argument,
- * and save the floating-point registers in its thread_struct.
- * Enables the FPU for use in the kernel on return.
- */
- .globl giveup_fpu
-giveup_fpu:
- mfmsr r5
- ori r5,r5,MSR_FP
- SYNC_601
- ISYNC_601
- MTMSRD(r5) /* enable use of fpu now */
- SYNC_601
- isync
- cmpwi 0,r3,0
- beqlr- /* if no previous owner, done */
- addi r3,r3,THREAD /* want THREAD of task */
- lwz r5,PT_REGS(r3)
- cmpwi 0,r5,0
- SAVE_32FPRS(0, r3)
- mffs fr0
- stfd fr0,THREAD_FPSCR-4(r3)
- beq 1f
- lwz r4,_MSR-STACK_FRAME_OVERHEAD(r5)
- li r3,MSR_FP|MSR_FE0|MSR_FE1
- andc r4,r4,r3 /* disable FP for previous task */
- stw r4,_MSR-STACK_FRAME_OVERHEAD(r5)
-1:
-#ifndef CONFIG_SMP
- li r5,0
- lis r4,last_task_used_math@ha
- stw r5,last_task_used_math@l(r4)
-#endif /* CONFIG_SMP */
- blr
/*
* This code is jumped to from the startup code to copy
diff -Nru a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S
--- a/arch/ppc/kernel/head_44x.S 2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/kernel/head_44x.S 2005-04-11 17:00:36 -05:00
@@ -426,7 +426,11 @@
PROGRAM_EXCEPTION
/* Floating Point Unavailable Interrupt */
+#ifdef CONFIG_PPC_FPU
+ FP_UNAVAILABLE_EXCEPTION
+#else
EXCEPTION(0x2010, FloatingPointUnavailable, UnknownException, EXC_XFER_EE)
+#endif
/* System Call Interrupt */
START_EXCEPTION(SystemCall)
@@ -686,9 +690,11 @@
*
* The 44x core does not have an FPU.
*/
+#ifndef CONFIG_PPC_FPU
_GLOBAL(giveup_fpu)
blr
-
+#endif
+
/*
* extern void abort(void)
*
diff -Nru a/arch/ppc/kernel/head_booke.h b/arch/ppc/kernel/head_booke.h
--- a/arch/ppc/kernel/head_booke.h 2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/kernel/head_booke.h 2005-04-11 17:00:36 -05:00
@@ -337,4 +337,11 @@
addi r3,r1,STACK_FRAME_OVERHEAD; \
EXC_XFER_LITE(0x0900, timer_interrupt)
+#define FP_UNAVAILABLE_EXCEPTION \
+ START_EXCEPTION(FloatingPointUnavailable) \
+ NORMAL_EXCEPTION_PROLOG; \
+ bne load_up_fpu; /* if from user, just load it up */ \
+ addi r3,r1,STACK_FRAME_OVERHEAD; \
+ EXC_XFER_EE_LITE(0x800, KernelFP)
+
#endif /* __HEAD_BOOKE_H__ */
diff -Nru a/arch/ppc/kernel/head_fsl_booke.S b/arch/ppc/kernel/head_fsl_booke.S
--- a/arch/ppc/kernel/head_fsl_booke.S 2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/kernel/head_fsl_booke.S 2005-04-11 17:00:36 -05:00
@@ -477,7 +477,11 @@
PROGRAM_EXCEPTION
/* Floating Point Unavailable Interrupt */
+#ifdef CONFIG_PPC_FPU
+ FP_UNAVAILABLE_EXCEPTION
+#else
EXCEPTION(0x0800, FloatingPointUnavailable, UnknownException, EXC_XFER_EE)
+#endif
/* System Call Interrupt */
START_EXCEPTION(SystemCall)
@@ -883,10 +887,12 @@
/*
* extern void giveup_fpu(struct task_struct *prev)
*
- * The e500 core does not have an FPU.
+ * Not all FSL Book-E cores have an FPU
*/
+#ifndef CONFIG_PPC_FPU
_GLOBAL(giveup_fpu)
blr
+#endif
/*
* extern void abort(void)
diff -Nru a/arch/ppc/kernel/misc.S b/arch/ppc/kernel/misc.S
--- a/arch/ppc/kernel/misc.S 2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/kernel/misc.S 2005-04-11 17:00:36 -05:00
@@ -1096,17 +1096,7 @@
* and exceptions as if the cpu had performed the load or store.
*/
-#if defined(CONFIG_4xx) || defined(CONFIG_E500)
-_GLOBAL(cvt_fd)
- lfs 0,0(r3)
- stfd 0,0(r4)
- blr
-
-_GLOBAL(cvt_df)
- lfd 0,0(r3)
- stfs 0,0(r4)
- blr
-#else
+#ifdef CONFIG_PPC_FPU
_GLOBAL(cvt_fd)
lfd 0,-4(r5) /* load up fpscr value */
mtfsf 0xff,0
diff -Nru a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
--- a/arch/ppc/kernel/traps.c 2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/kernel/traps.c 2005-04-11 17:00:36 -05:00
@@ -176,7 +176,7 @@
#else
#define get_mc_reason(regs) (mfspr(SPRN_MCSR))
#endif
-#define REASON_FP 0
+#define REASON_FP ESR_FP
#define REASON_ILLEGAL ESR_PIL
#define REASON_PRIVILEGED ESR_PPR
#define REASON_TRAP ESR_PTR
diff -Nru a/include/asm-ppc/reg_booke.h b/include/asm-ppc/reg_booke.h
--- a/include/asm-ppc/reg_booke.h 2005-04-11 17:00:36 -05:00
+++ b/include/asm-ppc/reg_booke.h 2005-04-11 17:00:36 -05:00
@@ -304,6 +304,7 @@
#define ESR_PIL 0x08000000 /* Program Exception - Illegal */
#define ESR_PPR 0x04000000 /* Program Exception - Priveleged */
#define ESR_PTR 0x02000000 /* Program Exception - Trap */
+#define ESR_FP 0x01000000 /* Floating Point Operation */
#define ESR_DST 0x00800000 /* Storage Exception - Data miss */
#define ESR_DIZ 0x00400000 /* Storage Exception - Zone fault */
#define ESR_ST 0x00800000 /* Store Operation */
^ permalink raw reply
* Re: [PATCH] pmac: Improve sleep code of tumbler driver
From: Andreas Schwab @ 2005-04-11 22:49 UTC (permalink / raw)
To: Colin Leroy
Cc: Andrew Morton, debian-powerpc@lists.debian.org, Takashi Iwai,
linuxppc-dev list
In-Reply-To: <20050411194214.GE2603@ay.vinc17.org>
Vincent Lefevre <vincent@vinc17.org> writes:
> On 2005-04-11 10:18:53 +0200, Colin Leroy wrote:
>> I suppose it also fixes the occasionnal loud static noise that
>> sometimes at wakeup, for example on iBook G4s. Good :)
>
> Could this be related to this bug?
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=244467
I'm also hearing something like that on iBook G3, but only when setting
the input source to the microphone.
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: [PATCH] pmac: sound support for latest laptops
From: Benjamin Herrenschmidt @ 2005-04-12 0:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Takashi Iwai, linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <425A92B1.6080907@sipsolutions.net>
On Mon, 2005-04-11 at 17:07 +0200, Johannes Berg wrote:
> Hi,
>
> >This patch hacks the current Alsa snd-powermac driver to add support for
> >recent machine models with the tas3004 chip, that is basically new
> >laptop models. The Mac Mini is _NOT_ yet supported by this patch (soon
> >soon ...). The G5s (iMac or Desktop) will need the rewritten sound
> >driver on which I'm working on (I _might_ get a hack for analog only on
> >some G5s on the current driver, but no promise).
> >
> >
> That's cool. I do have one slight problem with it though: When I turn
> down the Master mixer and up PCM it sounds badly overmodulated. I can
> keep PCM at about 75% and turn up master, and all is fine. Would it make
> sense to limit the PCM mixer to about 75% of its current limits, or how
> does that actually work in the hardware?
Well, the driver will let you do the setting you want, even if it's
wrong :) You should indeed keep PCM at about 75% and use the master.
There is also an issue with bad quality speakers used by Apple. OS X has
a built-in software DSP that does equalisation & filtering in the kernel
driver, and they have specific settings for it for various machine model
speakers. Obviously, we don't have such thing.
Ben.
^ permalink raw reply
* Re: [PATCH] ppc32: refactor FPU exception handling
From: Benjamin Herrenschmidt @ 2005-04-12 2:28 UTC (permalink / raw)
To: Kumar Gala
Cc: Andrew Morton, linuxppc-dev list, Jason McMullan,
Linux Kernel list, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0504111639330.10171@blarg.somerset.sps.mot.com>
On Mon, 2005-04-11 at 17:02 -0500, Kumar Gala wrote:
> Andrew,
>
> Moved common FPU exception handling code out of head.S so it can be used
> by several of the sub-architectures that might of a full PowerPC FPU.
>
> Also, uses new CONFIG_PPC_FPU define to fix alignment exception
> handling for floating point load/store instructions to only occur if we
> have a hardware FPU.
>
> Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Andrew, please hold on this patch, it hasn't been properly discussed
with the relevant maintainer, that is Paul Mackerras.
I can see matter for debate in there, like the whole duplication of the
fast exception return path...
It's also touching quite sensitive bits of kernel code (head.S) that
needs careful auditing and testing before beeing pushed upstream.
Ben.
^ permalink raw reply
* Re: Best way to determine tb_ticks_per_jiffy inside todc_calibrate_decr()
From: Daniel Ann @ 2005-04-12 3:55 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <425AC449.4070401@mvista.com>
On Apr 12, 2005 3:39 AM, Mark A. Greer <mgreer@mvista.com> wrote:
> Because the internally kept time in ppc linux is based on the
> decrementer counter and, according to the manual for the 8245, the
> decrementer counter is decremented once every four sys_logic_clk
> cycles. Therefore, you need to divide by 4.
Gotcha. Thanks ^^
--
Daniel
^ permalink raw reply
* Re: Eliminating RTC from MPC5200
From: Daniel Ann @ 2005-04-12 4:03 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc050411113074ad93b5@mail.gmail.com>
On Apr 12, 2005 3:30 AM, Grant Likely <glikely@gmail.com> wrote:
> Is this true? Can I eliminate the need for the RTC If I modify
> mpc52xx_calibrate_decr() in arch/ppc/syslib/mpc52xx_setup.c and
> mpc52xx_ipbfreq() in arch/ppc/boot/simple/mpc52xx_tty.c? I'm assuming
> that I can hard code the system clock speeds for my specific hardware.
This kinda relates back to my previous post.
Tho I'm not using mpc52xx, my board doesnt have RTC as well. And I
simply blocked out all the time related functions except the
calibrate_decr. And hard coded the freq.
It works nicely.
BTW, I'm using mpc8245. You should be able to find my post dating back
no more than a week or two. Originally I had trouble working out the
freq, but its all solved thanks to Mark ^^
--
Daniel
^ permalink raw reply
* Re: 824x Sandpoint with 2.6.x
From: Sam Song @ 2005-04-12 4:10 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
--- "Mark A. Greer" <mgreer@mvista.com> wrote:
> Sam Song wrote:
>
> >Hi all,
> >
> >I'd like to know where I could get a good start on
> >824x Sandpoint board with 2.6.x? Is linuxppc-2.5 BK
> >tree nice for me to work?
>
> No. Use linux-2.5/6.
Thanks a lot, Mark.
Sam
_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
^ permalink raw reply
* Re: [PATCH] ppc32: refactor FPU exception handling
From: Kumar Gala @ 2005-04-12 5:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, Linux Kernel list, Jason McMullan,
linuxppc-dev list, Kumar Gala, linuxppc-embedded
In-Reply-To: <1113272915.5388.37.camel@gaston>
Ben,
Sorry about that, we have had some back and forth on this on the ppc=20
embedded list.
Not sure I understand your concern about the duplication of the fast=20
exception return path? Jason's patch pretty much just moved code out=20
of head.S into fpu.S so we dont duplicate it between head.S and=20
head_44x.S & head_fsl_booke.S
- kumar
On Apr 11, 2005, at 9:28 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2005-04-11 at 17:02 -0500, Kumar Gala wrote:
> > Andrew,
> >
> > Moved common FPU exception handling code out of head.S so it can be=20=
> used
> > by several of the sub-architectures that might of a full PowerPC=20
> FPU.=A0
> >
> > Also, uses new CONFIG_PPC_FPU define to fix alignment exception
> > handling for floating point load/store instructions to only occur if=20=
> we
> > have a hardware FPU.
> >
> > Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
> > Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
>
>
>
> Andrew, please hold on this patch, it hasn't been properly discussed
> with the relevant maintainer, that is Paul Mackerras.
>
> I can see matter for debate in there, like the whole duplication of =
the
> fast exception return path...
>
> It's also touching quite sensitive bits of kernel code (head.S) that
> needs careful auditing and testing before beeing pushed upstream.
>
> Ben.
^ permalink raw reply
* [PATCH] ppc32: Fix alignment exception checking on load/store multiple instructions
From: Kumar Gala @ 2005-04-12 6:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Paulus,
Can you take a look and ack this patch before I send to akpm.
The handling of misaligned load/store multiplies did not check to see if
the address were ok to access before __{get,put}_user().
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/kernel/align.c b/arch/ppc/kernel/align.c
--- a/arch/ppc/kernel/align.c 2005-04-12 01:00:10 -05:00
+++ b/arch/ppc/kernel/align.c 2005-04-12 01:00:10 -05:00
@@ -290,6 +290,10 @@
/* lwm, stmw */
nb = (32 - reg) * 4;
}
+
+ if (!access_ok((flags & ST? VERIFY_WRITE: VERIFY_READ), addr, nb+nb0))
+ return -EFAULT; /* bad address */
+
rptr = (unsigned char *) ®s->gpr[reg];
if (flags & LD) {
for (i = 0; i < nb; ++i)
^ 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