* Re: Heartbeat apps thoughts
From: Geert Uytterhoeven @ 2005-03-14 16:02 UTC (permalink / raw)
To: Joerg Dorchain; +Cc: linuxppc-dev list
In-Reply-To: <20050314154504.GA7267@Redstar.dorchain.net>
On Mon, 14 Mar 2005, Joerg Dorchain wrote:
> I am pondering a heartbeat functionality implementation. Currently, I
> have a patch that adds a few line to the timer interrupt to switch the
> led on and off when appropriate.
>
> On the list, there were opinions that switching the led on and off would
> be best done via userspace. While I in principle agree, I have some
> considerations:
And then we (kernel hackers) cannot use it anymore to see whether interrupts
are still working...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Heartbeat apps thoughts
From: Joerg Dorchain @ 2005-03-14 15:45 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 4453 bytes --]
Hi list,
I am pondering a heartbeat functionality implementation. Currently, I
have a patch that adds a few line to the timer interrupt to switch the
led on and off when appropriate.
On the list, there were opinions that switching the led on and off would
be best done via userspace. While I in principle agree, I have some
considerations:
- The heartbeat frequency is calculated dynamically as a function of the
current load. While this is available e.g. via /proc/loadavg, there is
the effect that a daemon serving the led would need more cpu on high
loads (led is blinking faster), even though it is less likely to be
scheduled. This leads the heartbeat idea ad absurdum.
- Can real time scheduling of the heartbeat daemon avoid the effect
described above?
- If so, is locking some pages of memory and a real time process still
more adequate than a few lines in the timer interrupt?
For a discussion base I've attached my current idea of an heartbeatd.
(The DEBUG define might help those without an ibook to get something
running ;-)
Curous for any comments,
Joerg
/*
* heartbeatd 2005-03-14 Joerg Dorchain <joerg@dorchain.net>
* led code taken from ibook-led Nico Schottelius (nico-linux@schottelius.org) 2005-02-18 v0.3
*
* might replace the kernel heartbeat code in arch/.../time.c
*
*/
/* open() */
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
/* write */
#include <unistd.h>
/* fopen.. */
#include <stdio.h>
/* exit */
#include <stdlib.h>
/* nanosleep..*/
#include <time.h>
/* sigaction */
#include <signal.h>
/* HZ */
#include <sys/param.h>
/* ioctl */
#include <sys/ioctl.h>
/* realtime scheduling */
#include <sched.h>
/* mlockall */
#include <sys/mman.h>
/* Linux */
#define FSHIFT 11
#define ADB_DEVICE "/dev/adb"
#define LOADAVG "/proc/loadavg"
#define PIDFILE "/var/run/heartbeatd.pid"
#undef DEBUG
#ifdef DEBUG
#undef LOADAVG
#define LOADAVG "/tmp/loadavg"
#endif
int adbfd;
inline void heartbeat_init(void)
{
#ifndef DEBUG
/* open /dev/adb */
if((adbfd = open(ADB_DEVICE,O_RDWR)) == -1) exit(1);
#endif
}
inline void heartbeat(int i)
{
char adb_on[5] = {0x06, 0xee, 0x04, 0x00, 0x01};
char adb_off[5] = {0x06, 0xee, 0x04, 0x00, 0x00};
#ifndef DEBUG
if (i)
write(adbfd, adb_on, 5);
else
write(adbfd, adb_off, 5);
#else
if (i)
printf("pump\r");
else
printf(" \r");
fflush(stdout);
#endif
}
inline unsigned int period_calc(void)
{
FILE *lf;
unsigned int ldint, ldfrac, load;
if (( lf = fopen(LOADAVG, "r")) == NULL)
exit(1);
fscanf(lf, "%u.%u", &ldint, &ldfrac);
fclose(lf);
load = (ldint << FSHIFT) + (ldfrac << FSHIFT) / 100;
return ((672<<FSHIFT)/(5*load+(7<<FSHIFT))) + 30;
}
void cleanup(int unused_signal)
{
unlink(PIDFILE);
exit(1);
}
int main(int argc, char **argv)
{
unsigned int period;
struct timespec ts0, ts1, ts2, ts3;
int fd;
struct sched_param sp;
FILE *pidf;
struct sigaction sa;
#ifndef DEBUG
/* daemonize */
if (fork() != 0)
exit(0);
if ((fd = open("/dev/tty", O_RDWR)) >= 0) {
ioctl(fd, TIOCNOTTY);
close(fd);
}
/* make pidfile and remove once done */
if ((pidf = fopen(PIDFILE,"w+")) != NULL) {
fprintf(pidf, "%d\n", getpid());
fclose(pidf);
sa.sa_handler = cleanup;
sigemptyset(&sa.sa_mask);
sa.sa_flags= SA_ONESHOT;
sigaction(SIGHUP, &sa, NULL);
sigaction(SIGQUIT, &sa, NULL);
sigaction(SIGTERM, &sa, NULL);
}
/* get priority */
if (nice(-19) != 0)
perror("nice");
if (mlockall(MCL_CURRENT|MCL_FUTURE) != 0)
perror("mlockall");
sp.sched_priority=10;
if (sched_setscheduler(0, SCHED_RR, &sp) != 0)
perror("sched_setscheduler");
#endif
heartbeat_init();
while (1) {
period = period_calc();
ts0.tv_sec = 0;
ts0.tv_nsec = 7*(1000000000/HZ);
ts1.tv_sec = 0;
ts1.tv_nsec = (period/4)*(1000000000/HZ) - ts0.tv_nsec;
ts2.tv_sec = 0;
ts2.tv_nsec = (period/4+7)*(1000000000/HZ) - ts0.tv_nsec - ts1.tv_nsec;
ts3.tv_sec = 0;
ts3.tv_nsec = (period)*(1000000000/HZ) - ts0.tv_nsec - ts1.tv_nsec - ts2.tv_nsec;
heartbeat(1);
nanosleep(&ts0,NULL);
heartbeat(0);
nanosleep(&ts1,NULL);
heartbeat(1);
nanosleep(&ts2,NULL);
heartbeat(0);
nanosleep(&ts3,NULL);
}
}
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: mpc8560ads PCI bus
From: Clemens Koller @ 2005-03-14 15:43 UTC (permalink / raw)
To: Greg Weeks, linuxppc-embedded
In-Reply-To: <4235A636.4020309@timesys.com>
Hello, Greg,
I am working on an mpc8540_ads-like board and recently, I ran into data
corruption problems with a Silicon Motion SM501 (Rev AA) PCI graphics
card. From my current point of view it seems that Kernel 2.6.11 PCI
works well. I am about to check the hardware and signal integrity.
BTW: I am working with a Promise Ultra-TX133 IDE controller (PDC20269)
which is fine with 66MHz PCICLK.
Greets,
Clemens
> Has anyone else tried to get the PCI bus working on the mpc8560ads board
> at 2.6.11? The card enumerates, but the I/O resource regions aren't
> getting set up.
>
> -bash-2.05b# lspci -vv
> 00:03.0 Unknown mass storage controller: Silicon Image, Inc. (formerly
> CMD Technology Inc) PCI0680 Ultra ATA-133 Host Controller (rev 02)
> Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc)
> PCI0680 Ultra ATA-133 Host Controller
> Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR+
> Interrupt: pin A routed to IRQ 100
> Region 0: I/O ports at <unassigned> [disabled]
> Region 1: I/O ports at <unassigned> [disabled]
> Region 2: I/O ports at <unassigned> [disabled]
> Region 3: I/O ports at <unassigned> [disabled]
> Region 4: I/O ports at <unassigned> [disabled]
> Capabilities: [60] Power Management version 2
> Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=2 PME-
>
> Greg Weeks
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* mpc8560ads PCI bus
From: Greg Weeks @ 2005-03-14 14:56 UTC (permalink / raw)
To: linuxppc-embedded
Has anyone else tried to get the PCI bus working on the mpc8560ads board
at 2.6.11? The card enumerates, but the I/O resource regions aren't
getting set up.
-bash-2.05b# lspci -vv
00:03.0 Unknown mass storage controller: Silicon Image, Inc. (formerly
CMD Technology Inc) PCI0680 Ultra ATA-133 Host Controller (rev 02)
Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc)
PCI0680 Ultra ATA-133 Host Controller
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR+
Interrupt: pin A routed to IRQ 100
Region 0: I/O ports at <unassigned> [disabled]
Region 1: I/O ports at <unassigned> [disabled]
Region 2: I/O ports at <unassigned> [disabled]
Region 3: I/O ports at <unassigned> [disabled]
Region 4: I/O ports at <unassigned> [disabled]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Greg Weeks
^ permalink raw reply
* Re: ELDK 3.1 installation tells me "Wrong format of the rpm archive"
From: Wolfgang Denk @ 2005-03-14 14:50 UTC (permalink / raw)
To: Edward Jubenville; +Cc: linuxppc-embedded
In-Reply-To: <GPECLCIGPLHEOMGPMCPAGEILCMAA.edjubenville@adelphia.net>
In message <GPECLCIGPLHEOMGPMCPAGEILCMAA.edjubenville@adelphia.net> you wrote:
> I tried installing ELDK 3.1 on RedHat 9,
> but all I got was this:
>
> Installing cross RPMs
> Wrong format of the rpm archive.
Did you verify the images?
> I'm a rookie, so I'm sure I screwed something up. I had downloaded
> the ISO image to my Windows PC, made the CD there, copied the tree
> onto my Linux box at /ELDKCD, then tried:
>
> ./install -d /ELDK
> and
> ./install -d /ELDK ppc_6xx
>
> What did I do wrong?
I can only speculate: probablky your doenload was not performed in
binary mode, and/or the image got corrupted.
Pleas make sure to verify the MD5 checksum of thr ISO image (or the
MD5 checksums of the file son the CD). RH 9 is one of the platforms
which are officially supported and tested.
[BTW: you may want to switch to ELDK 3.1.1 anyway :-) ]
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A dog always bit deepest on the veterinary hand.
- Terry Pratchett, _Wyrd Sisters_
^ permalink raw reply
* ELDK 3.1 installation tells me "Wrong format of the rpm archive"
From: Edward Jubenville @ 2005-03-14 14:29 UTC (permalink / raw)
To: linuxppc-embedded
I tried installing ELDK 3.1 on RedHat 9,
but all I got was this:
Installing cross RPMs
Wrong format of the rpm archive.
I'm a rookie, so I'm sure I screwed something up. I had downloaded
the ISO image to my Windows PC, made the CD there, copied the tree
onto my Linux box at /ELDKCD, then tried:
./install -d /ELDK
and
./install -d /ELDK ppc_6xx
What did I do wrong?
^ permalink raw reply
* PCMCIA for 8xx with 8- and 16-bit access
From: Markus Westergren @ 2005-03-14 13:21 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm working with a custom made board based on A&M Adder875 with added PCMCIA
slot. The hardware guys connected the data bus via two 8bit buffer chips. Each
buffer chip has its own chip select line (CS) connected directly to the MPC875
cpu. I think that the idea was to support both 8- and 16-bit access to the
PCMCIA slot. One CS line controls the odd bytes and the other the even ones.
Is there any way to tell the memory controler to use one chip select line for
odd adresses in an interval and another for even in the same interval? I did
not find any information about that in the MPC885 Reference Manual.
One solution to the problem would be to connect the two CS lines together and
only use 16bit access. Must 8bit access be supported for the PCMCIA to work or
can I use 16bit for everything? I need support for both IDE and Wireless LAN.
Thanks,
/Markus
---
Markus Westergren
UmeÃ,¥Sweden
^ permalink raw reply
* Re: Bootloader for IBMSTBx25xx
From: Wolfgang Denk @ 2005-03-14 11:45 UTC (permalink / raw)
To: Vijesh VH; +Cc: linuxppc-embedded
In-Reply-To: <8e78982e0503132323e8547f1@mail.gmail.com>
In message <8e78982e0503132323e8547f1@mail.gmail.com> you wrote:
>
> I am Vijesh . Can any one help in finding a perfect bootloader (source) for
> the IBM STBx25xx.
There is no _perfect_ bootloader. U-Boot might be a pretty good starting point.
But I'm obviously biased.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Save yourself! Reboot in 5 seconds!
^ permalink raw reply
* [PATCH] ppc32: Fix PowerMac cpufreq for newer machines
From: Benjamin Herrenschmidt @ 2005-03-14 10:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list
Hi !
This patch fixes the cpufreq support for newer machines, including
latest Apple laptops using the 7447A CPU. With this patch, it should now
propertly detect that the CPU is booting low speed on some models, and
let you switch it to full speed (previously, /proc/cpuinfo would display
the frequency of the full speed CPU but it was really running low
speed).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/ppc/platforms/pmac_cpufreq.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_cpufreq.c 2005-03-13 18:23:11.000000000 +1100
+++ linux-work/arch/ppc/platforms/pmac_cpufreq.c 2005-03-14 13:32:36.000000000 +1100
@@ -464,20 +464,22 @@
u32 *reg;
struct cpufreq_driver *driver = &pmac_cpufreq_driver;
- /* OF only reports the high frequency */
- hi_freq = cur_freq;
- low_freq = cur_freq/2;
- driver->get = dfs_get_cpu_speed;
- cur_freq = driver->get(0);
-
+ /* Look for voltage GPIO */
volt_gpio_np = of_find_node_by_name(NULL, "cpu-vcore-select");
+ reg = (u32 *)get_property(volt_gpio_np, "reg", NULL);
+ voltage_gpio = *reg;
if (!volt_gpio_np){
printk(KERN_ERR "cpufreq: missing cpu-vcore-select gpio\n");
return 1;
}
- reg = (u32 *)get_property(volt_gpio_np, "reg", NULL);
- voltage_gpio = *reg;
+ /* OF only reports the high frequency */
+ hi_freq = cur_freq;
+ low_freq = cur_freq/2;
+
+ /* Read actual frequency from CPU */
+ driver->get = dfs_get_cpu_speed;
+ cur_freq = driver->get(0);
set_speed_proc = dfs_set_cpu_speed;
return 0;
@@ -492,7 +494,7 @@
* - iBook2 500/600 (PMU based, 400Mhz & 500/600Mhz)
* - iBook2 700 (CPU based, 400Mhz & 700Mhz, support low voltage)
* - Recent MacRISC3 laptops
- * - iBook G4s and PowerBook G4s with 7447A CPUs
+ * - All new machines with 7447A CPUs
*/
static int __init pmac_cpufreq_setup(void)
{
@@ -513,11 +515,10 @@
goto out;
cur_freq = (*value) / 1000;
- /* Check for 7447A based iBook G4 or PowerBook */
- if (machine_is_compatible("PowerBook6,5") ||
- machine_is_compatible("PowerBook6,4") ||
- machine_is_compatible("PowerBook5,5") ||
- machine_is_compatible("PowerBook5,4")) {
+ /* Check for 7447A based MacRISC3 */
+ if (machine_is_compatible("MacRISC3") &&
+ get_property(cpunode, "dynamic-power-step", NULL) &&
+ PVR_VER(mfspr(SPRN_PVR)) == 0x8003) {
pmac_cpufreq_init_7447A(cpunode);
/* Check for other MacRISC3 machines */
} else if (machine_is_compatible("PowerBook3,4") ||
^ permalink raw reply
* Re: Adding machine types to the kernel tree...
From: Jakob Viketoft @ 2005-03-14 9:43 UTC (permalink / raw)
To: Debian User; +Cc: Linux PPC Embedded list
In-Reply-To: <20050308180149.GA4293@acmay.homeip.net>
Sorry for the delay in answer, but I've been off sick most of last week.
Anyway, I've contacted Jon Masters off the list about the OF device tree
approach and hopefully there will be something coming of this soon enough.
Cheers!
/Jakob
Debian User wrote:
> On Mon, Mar 07, 2005 at 05:27:32AM -0700, Matt Porter wrote:
>
>>On Mon, Mar 07, 2005 at 11:07:58AM +0100, Jakob Viketoft wrote:
>>
>>>Thanks for the comments!
>>>
>>>Andrew May wrote:
>>>
>>>>I think a huge first step would be to banish xparameters.h from all the
>>>>kernel code.
>
> ....
>
>>>I understand that there is numerous resentment against having this file
>>>in the kernel and I've been thinking of a solution without it. One such
>>>path would be serving the kernel with a OCP list of the devices used,
>>>but I'm unsure about the current status of OCP. Is this The Right Way to
>>>do it, or are OCP likely to be abandoned further along the 2.6 road?
>
>
> Not so much resentment, as a realization that xparamters.h is where all
> the work is going to flow from.
>
>
>>>Matt (Porter), I've seen that you've "ported" this to the 2.6 kernel,
>>>what do you say?
>>
>>Don't tie anything permanently to OCP. :) Eventually, 4xx will convert
>>to platform devices like other similar SoC type subarches in ppc32 have
>>already done. The only reason it hasn't been done yet is that there
>>are some other higher priority things on my plate at the moment.
>
>
> I am still working with an old 2_4_devel kernel myself.
> The something better is comming has always held me back from working
> on things as well.
>
> Even now OCP is being dropped for platform devices.
> And birecs is being dropped for OF.
> The kernel I am working with is a step behind both of those.
>
>
>>However, it seems you are talking about passing information to
>>the kernel from some bootrom or full featured firmware. That is
>>a separate issue from how information is passed from the arch-code
>>into drivers (this is what OCP and platform devices accomplish).
>>For now, you could define a birec type for xparameters and
>>standardize around passing the info in that. In the future,
>>birecs should be replaced by the "flattened OF device tree" method
>>that has been discussed here a bit (I know Jon Masters is lurking
>>around here, maybe with some code).
>
>
> A simple fucntion that would take the xparameters.h and create the
> birecs/OF data would be a nice way to go.
> I would think the func could run on the host to generate a binary
> blob that could be attached to the kernel or dropped in flash, for
> simple bootloaders.
> For a better bootloader it could run the func itself on the target
> and put the data in ram, and then fixup the data if needed.
>
>
>>Even the smallest bootloader rom could put the xparameters.h info in
>>a location and point to it using the standard birec method when
>>transferring control to the kernel.
>
>
> I am a U-boot person myself, but I think there will be a higher number
> of users that just stick with the standard loader providied by the vendor
> and do the wrapper thing in the kernel.
>
>
>>I belive this would give Andrew the kind of flexibility he would like.
>
>
> Yes, I think it would.
^ permalink raw reply
* Bootloader for IBMSTBx25xx
From: Vijesh VH @ 2005-03-14 7:23 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am Vijesh . Can any one help in finding a perfect bootloader (source) for
the IBM STBx25xx.
--
Thanks and Regards,
Vijesh V H
^ permalink raw reply
* Re: DMA appears broken in 2.6.11 for Mac 7200
From: Benjamin Herrenschmidt @ 2005-03-14 6:58 UTC (permalink / raw)
To: linuxppcdev; +Cc: linuxppc-dev list
In-Reply-To: <20050314035131.3098.qmail@kunk.qbjnet.com>
On Mon, 2005-03-14 at 03:51 +0000, linuxppcdev@qbjnet.com wrote:
> Just updated a couple of old Mac 7200 (601) boxen and ran into trouble with
> the ide driver and a promise PDC20267 card.
>
> The very same drives and card work fine on a 9500 but hang on a 7200. If
> I set the kernel arg ide=nodma I get in the dmesg:
> ide_setup: ide=nodma : Prevented DMA
> and the 7200 boots and runs fine.
>
> Another suspect, the mace ethernet driver (which also appears to use DMA)
> doesn't work on the 7200 with 2.6.11 but does with 2.4.28 and it works
> with 2.6.11 on the 9500.
Interesting. Not sure what's up, though. Those old machines were known
to have bugs relative to cache coherency... also check wetehr we are
setting the cache line size properly in PCI devices. You can also try to
disable use of PCI memory write & invalidate command in all devices.
> Finally, I don't think this is related to DMA however the OF frame buffer
> driver, if compiled into the kernel, kills the platinumfb driver which wasn't
> a problem in the 2.4 kernels either (I get a blank screen but the machine
> keeps running).
Ah ? platinumfb alone works, and platinumfb + offb fails ? weird ...
Ben.
^ permalink raw reply
* DMA appears broken in 2.6.11 for Mac 7200
From: linuxppcdev @ 2005-03-14 3:51 UTC (permalink / raw)
To: linuxppc-dev
Just updated a couple of old Mac 7200 (601) boxen and ran into trouble with
the ide driver and a promise PDC20267 card.
The very same drives and card work fine on a 9500 but hang on a 7200. If
I set the kernel arg ide=nodma I get in the dmesg:
ide_setup: ide=nodma : Prevented DMA
and the 7200 boots and runs fine.
Another suspect, the mace ethernet driver (which also appears to use DMA)
doesn't work on the 7200 with 2.6.11 but does with 2.4.28 and it works
with 2.6.11 on the 9500.
Finally, I don't think this is related to DMA however the OF frame buffer
driver, if compiled into the kernel, kills the platinumfb driver which wasn't
a problem in the 2.4 kernels either (I get a blank screen but the machine
keeps running).
Bob
^ permalink raw reply
* Newer laptops & CPU speed
From: Benjamin Herrenschmidt @ 2005-03-14 2:33 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org, linuxppc-dev list
Hi !
It seems the new laptops are booting with CPU set to low
speed. /proc/cpuinfo outputs the wrong fequency (thinks it's high speed)
but bogomips shows that it's running at about half speed. This patch
against 2.6.11 (will not apply on 2.6.10) adds proper cpufreq support so
that the boot speed is recognized (fixing /proc/cpuinfo output) and so
you can acutally use cpufreq interface & utilities to switch to full
speed (I recommend powernowd).
This is completely untested as I don't have access to any of those new
models yet, so I'm waiting for some feedback before submitting upstream.
Ben.
Index: linux-work/arch/ppc/platforms/pmac_cpufreq.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_cpufreq.c 2005-03-13 18:23:11.000000000 +1100
+++ linux-work/arch/ppc/platforms/pmac_cpufreq.c 2005-03-14 13:32:36.000000000 +1100
@@ -464,20 +464,22 @@
u32 *reg;
struct cpufreq_driver *driver = &pmac_cpufreq_driver;
- /* OF only reports the high frequency */
- hi_freq = cur_freq;
- low_freq = cur_freq/2;
- driver->get = dfs_get_cpu_speed;
- cur_freq = driver->get(0);
-
+ /* Look for voltage GPIO */
volt_gpio_np = of_find_node_by_name(NULL, "cpu-vcore-select");
+ reg = (u32 *)get_property(volt_gpio_np, "reg", NULL);
+ voltage_gpio = *reg;
if (!volt_gpio_np){
printk(KERN_ERR "cpufreq: missing cpu-vcore-select gpio\n");
return 1;
}
- reg = (u32 *)get_property(volt_gpio_np, "reg", NULL);
- voltage_gpio = *reg;
+ /* OF only reports the high frequency */
+ hi_freq = cur_freq;
+ low_freq = cur_freq/2;
+
+ /* Read actual frequency from CPU */
+ driver->get = dfs_get_cpu_speed;
+ cur_freq = driver->get(0);
set_speed_proc = dfs_set_cpu_speed;
return 0;
@@ -492,7 +494,7 @@
* - iBook2 500/600 (PMU based, 400Mhz & 500/600Mhz)
* - iBook2 700 (CPU based, 400Mhz & 700Mhz, support low voltage)
* - Recent MacRISC3 laptops
- * - iBook G4s and PowerBook G4s with 7447A CPUs
+ * - All new machines with 7447A CPUs
*/
static int __init pmac_cpufreq_setup(void)
{
@@ -513,11 +515,10 @@
goto out;
cur_freq = (*value) / 1000;
- /* Check for 7447A based iBook G4 or PowerBook */
- if (machine_is_compatible("PowerBook6,5") ||
- machine_is_compatible("PowerBook6,4") ||
- machine_is_compatible("PowerBook5,5") ||
- machine_is_compatible("PowerBook5,4")) {
+ /* Check for 7447A based MacRISC3 */
+ if (machine_is_compatible("MacRISC3") &&
+ get_property(cpunode, "dynamic-power-step", NULL) &&
+ PVR_VER(mfspr(SPRN_PVR)) == 0x8003) {
pmac_cpufreq_init_7447A(cpunode);
/* Check for other MacRISC3 machines */
} else if (machine_is_compatible("PowerBook3,4") ||
^ permalink raw reply
* [Fwd: Re: hda: lost interrupt starting with 2.6.8]
From: Benjamin Herrenschmidt @ 2005-03-13 7:49 UTC (permalink / raw)
To: linuxppc-dev list
-------- Forwarded Message --------
From: Vince Weaver <vince@deater.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: debian-powerpc@lists.debian.org <debian-powerpc@lists.debian.org>
Subject: Re: hda: lost interrupt starting with 2.6.8
Date: Sun, 13 Mar 2005 02:46:37 -0500 (EST)
> Can you tell me what is the value of CONFIG_NR_CPUS in your .config,
> also, is this file including include/linux/threads.h before
> include/linux/cpumask.h, and finally, send me privately the resulting
> binary vmlinux.
There is no CONFIG_NR_CPUS in my .config. Is that a problem? My tree is
a 2.6.4 tree that was patched incrementally, with "make oldconfig" run at
each release.
With the following patch I've managed to get 2.6.11 to boot on my
iBook2... do you still want a copy of a broken vmlinux?
Vince
--- linux/arch/ppc/syslib/open_pic.c.2.6.11 2005-03-13 01:57:00.000000000 -0500
+++ linux/arch/ppc/syslib/open_pic.c 2005-03-13 01:58:17.000000000 -0500
@@ -313,6 +313,7 @@
u_int t, i;
u_int timerfreq;
const char *version;
+ cpumask_t cpu0=CPU_MASK_CPU0;
if (!OpenPIC_Addr) {
printk("No OpenPIC found !\n");
@@ -405,7 +406,7 @@
openpic_initirq(i, 8, i+offset, (sense & IRQ_POLARITY_MASK),
(sense & IRQ_SENSE_MASK));
/* Processor 0 */
- openpic_mapirq(i, CPU_MASK_CPU0, CPU_MASK_NONE);
+ openpic_mapirq(i, cpu0, CPU_MASK_NONE);
}
/* Init descriptors */
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* *** Huntington Security Issues ***
From: Huntington Mutual Security Department @ 2005-03-13 7:28 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 4543 bytes --]
^ permalink raw reply
* *** Huntington Security Issues ***
From: Huntington Mutual Security Department @ 2005-03-13 7:26 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 4543 bytes --]
^ permalink raw reply
* [Fwd: Re: hda: lost interrupt starting with 2.6.8]
From: Benjamin Herrenschmidt @ 2005-03-13 6:47 UTC (permalink / raw)
To: linuxppc-dev list
-------- Forwarded Message --------
From: Vince Weaver <vince@deater.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: debian-powerpc@lists.debian.org <debian-powerpc@lists.debian.org>
Subject: Re: hda: lost interrupt starting with 2.6.8
Date: Sun, 13 Mar 2005 00:18:38 -0500 (EST)
OK, I've spent most of the day making my poor iBook compile kernels and
I've tracked down the error. I can't seem to figure out why it would
happen on my machine and no one elses, at least unless it's a compiler
issue (I am using gcc 3.2.2).
Somewhere between 2.6.8-rc1 and 2.6.8-rc2 interrupts just stop getting
delivered.
I tracked it down to this patch to linux/arch/ppc/syslib/open_pic.c :
/*
* Map an interrupt source to one or more CPUs
*/
-static void openpic_mapirq(u_int irq, u_int physmask, u_int keepmask)
+static void openpic_mapirq(u_int irq, cpumask_t physmask, cpumask_t keepmask)
{
if (ISR[irq] == 0)
return;
- if (keepmask != 0)
- physmask |= openpic_read(&ISR[irq]->Destination) &
keepmask;
- openpic_write(&ISR[irq]->Destination, physmask);
+ if (!cpus_empty(keepmask)) {
+ cpumask_t irqdest = { .bits[0] =
openpic_read(&ISR[irq]->Destination) };
+ cpus_and(irqdest, irqdest, keepmask);
+ cpus_or(physmask, physmask, irqdest);
+ }
+ openpic_write(&ISR[irq]->Destination, cpus_addr(physmask)[0]);
}
And this one:
- openpic_mapirq(i, 1<<0, 0);
+ openpic_mapirq(i, CPU_MASK_CPU0, CPU_MASK_NONE);
Using printk's, I can see before the change I properly was writing "1" as
the second argument to openpic_write, but afterwards it was 0.
It seems as though for some reason CPU_MASK_CPU0 is 0 on my kernel, rather
than just a 1.
By patching the kernel to force it to write a 1 in openpic_write the
kernel runs fine...
So, any ideas? I'll be glad to try out anything else if you'd like me to.
Vince
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Fraudulent Account
From: eBay @ 2005-03-14 0:42 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 9258 bytes --]
^ permalink raw reply
* [PATCH] compilation failure due to confliction of time_offset
From: Takeharu KATO @ 2005-03-12 16:45 UTC (permalink / raw)
To: linuxppc-embedded, galak, mporter, ebs
Hi all:
I send carbon copy of the mail to maintainers of Embedded PowerPC,
because I can not figure out who is responsible for arch/ppc/kernel/time.c.
I found a trivial bug made compilation fail.
I show error log as follows:
-- error log
arch/ppc/kernel/time.c:92: error: static declaration of 'time_offset'
follows non-static declaration
include/linux/timex.h:236: error: previous declaration of 'time_offset'
was heremake[1]: *** [arch/ppc/kernel/time.o] Error 1
make: *** [arch/ppc/kernel] Error 2
--
Please apply following patch if this is a correct fix.
Regards,
--
Takeharu KATO
Signed-off-by: Takeharu KATO <takeharu1219@ybb.ne.jp>
--- linux-2.6.11.maybe/arch/ppc/kernel/time.c 2005-03-05
23:58:20.000000000 +0900
+++ linux-2.6.11/arch/ppc/kernel/time.c 2005-03-13 00:46:49.000000000 +0900
@@ -89,7 +89,6 @@ unsigned long tb_to_ns_scale;
extern unsigned long wall_jiffies;
-static long time_offset;
DEFINE_SPINLOCK(rtc_lock);
^ permalink raw reply
* Re: 2.6.11 prep image on radstone ppc4a not booting
From: Christian @ 2005-03-12 16:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Brian V. Madzarevic
In-Reply-To: <A79EE6739F2C7348A857541FB5CD92D6011566F6@asimail1.rb.uav.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian V. Madzarevic wrote:
> Setting PCI interrupts for a "Blackhawk (Powerstack)"
> PCI: Cannot allocate resource region 0 of device 0000:00:0b.1
[...]
i don't know about these, hopefully the ppc gurus could explain these
messages.
> Linux Tulip driver version 1.1.13 (May 11, 2002)
> tulip0: EEPROM default media type Autosense.
- --^
did you try the de4x5 driver instead of the tulip one? if not...
> CONFIG_NET_TULIP=y
> # CONFIG_DE2104X is not set
> CONFIG_TULIP=y
> # CONFIG_TULIP_MWI is not set
> # CONFIG_TULIP_MMIO is not set
> # CONFIG_TULIP_NAPI is not set
> # CONFIG_DE4X5 is not set
- ----^
here it is ;)
could be worth a try.
Christian.
- --
BOFH excuse #80:
That's a great computer you have there; have you considered how it would
work as a BSD machine?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCMxn/C/PVm5+NVoYRAk1mAKCKCWXxlrHg031uktVx4BxtEMwePACg4hDq
muiR9Exk06I4vS0Xb4L4S3w=
=dqrh
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: problem opening I2C device on MPC8260
From: Yuli Barcohen @ 2005-03-12 13:54 UTC (permalink / raw)
To: Vijay Padiyar; +Cc: LinuxPPC Support
In-Reply-To: <BAY1-DAV14F92D2B45266ECD1105A48B540@phx.gbl>
>>>>> Vijay Padiyar writes:
...
Vijay> When I try to open the I2C device from a user program in root
Vijay> mode, I get an error and the value of errno is ENODEV.
...
This means that there is no I2C controller driver in your
kernel. Probably you use stock kernel which does not contain driver for
CPM I2C. You have to look for a custom kernel (I can offer Arabella
Linux) or try to apply one of the patches which were posted in the past.
Best regards,
--
========================================================================
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli@arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
========================================================================
^ permalink raw reply
* problem opening I2C device on MPC8260
From: Vijay Padiyar @ 2005-03-12 7:57 UTC (permalink / raw)
To: Yuli Barcohen, LinuxPPC Support
Hi there
I am running Linux-2.6.10 with BusyBox 1.0 on an MPC8260-based target. I'm
having problems opening the I2C controller device on the MPC8260.
I have now included I2C support in the kernel by setting the following
options:
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_ALGOBIT=y
None of the options under "I2C Hardware Bus support" and "Hardware Sensor
Chip support" are set. Do I need to enable any of these for MPC8260?
I have also mounted the Sysfs filesystem using 'mount -t sysfs sysfs /sys'.
When the kernel boots up, I can see the following message:
"i2c /dev entries driver"
which is from the I2C module initialization function i2c_dev_init() in
i2c-dev.c. This means that the I2C module has been loaded and initialized
correctly. However, the /sys/class/i2c-dev folder is found to be *empty*.
I have also created the following I2C device files in my /dev folder:
mknod i2c-0 c 89 0
mknod i2c0 c 89 0
mknod i2c-1 c 89 1
mknod i2c1 c 89 1
When I try to open the I2C device from a user program in root mode, I get an
error and the value of errno is ENODEV.
if ((fd = open("/dev/i2c-0", O_RDWR)) < 0)
{
printf ("Error: ");
if (errno == ENODEV)
printf ("No such device!\n");
}
Please tell me what I could be doing wrong? Is there anything I've missed in
setting up my configuration to use I2C? Is there anything more I need to do?
Regards
Vijay Padiyar
http://www.vijaypadiyar.eu.tf
^ permalink raw reply
* [PATCH] ppc32: Remove SPR short-hand defines
From: Kumar Gala @ 2005-03-11 23:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel, linuxppc-embedded
Andrew,
Removed the Special purpose register (SPR) short-hand defines to help with
name space pollution. All SPRs are now referenced as SPRN_<foo>.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
(patch was above the normal size limit)
http://gate.crashing.org/~galak/spr-rework.20050311.l26.patch
^ permalink raw reply
* Fw: Problem with NTP on (embedded) PPC, patch and RFC
From: Andrew Morton @ 2005-03-12 1:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Giovambattista Pulcini
Begin forwarded message:
Date: Fri, 11 Mar 2005 14:16:32 +0100
From: Giovambattista Pulcini <gpulcini@swintel.it>
To: LKML <linux-kernel@vger.kernel.org>
Subject: Problem with NTP on (embedded) PPC, patch and RFC
Hi,
On an embedded device based on the IBM 405GP, but this may be a general
problem for most PPC platforms except for chrp and gemini, the NTP
utility 'ntptime' always returns error code 5 (TIME_ERROR) even after
that NTP status reaches the PLL and FLL state. Analysis of problem
showed that the time_state variable set to TIME_ERROR by
do_settimeofday() is never set back to TIME_OK.
I found the problem in 2.4.10-1 (Lynuxworks BlueCat) but I also checked
the 2.6.11 and found similar problem. Many architectures under arch/ppc
may be affected with the exception of chrp and gemini.
Steps to reproduce:
On a PowerPC (non-CHRP) platform, set the system date with 'date',
configure and start the NTP daemon as client of a working NTP server.
Wait for it to reach the PLL/FLL state. Issue the 'ntptime' command and
check that the following two errors never disappear no matter how long
you let it running: "ntp_gettime() returns code 5 (ERROR)",
"ntp_adjtime() returns code 5 (ERROR)".
Detailed analysis:
AFAIK NTP relies on the global time_state variable which is statically
initialized to TIME_OK (kernel/timer.c). The ntptime utility calls
adjtimex() which results in a call to do_adjtimex() and prints its
return value which is basically the value of time_state. It is changed
by (kernel/timer.c)second_overflow() and by the
(kernel/time.c)do_adjtimex() state machine.
These two functions never set time_state to TIME_OK once it has been set
to TIME_ERROR.
Also, do_settimeofday() sets the STA_UNSYNC flag in time_status and sets
time_state to TIME_ERROR (in ppc but not in ppc64 nor in x86).
The function (arch/ppc/kernel/time.c)timer_interrupt() calls the
ppc_md.set_rtc_time() when certain conditions are met, as follows
(time.c:171):
if ( ppc_md.set_rtc_time && (time_status & STA_UNSYNC) == 0 &&
xtime.tv_sec - last_rtc_update >= 659 &&
abs(xtime.tv_usec - (1000000-1000000/HZ)) < 500000/HZ &&
jiffies - wall_jiffies == 1) {
if (ppc_md.set_rtc_time(xtime.tv_sec+1 + time_offset) == 0)
In the CHRP architecture (see arch/ppc/platforms/chrp_*) the specific
implementation of the set_rtc_time(), chrp_set_rtc_time(), has a check
like this (chrp_time.c:76):
if ( (time_state == TIME_ERROR) || (time_state == TIME_BAD) )
time_state = TIME_OK;
which is the only chance for the time_state to be set back to TIME_OK
after a do_settimeofday(). In other platforms this is not done.
Proposed patch:
This change should make NTP to work on any ppc platform, while not
breaking chrp and gemini. Although I've tested it only on mine.
--- linux-2.6.11/arch/ppc/kernel/time.c 2005-03-02 08:38:17.000000000 +0100
+++ linux/arch/ppc/kernel/time.c 2005-03-08 14:16:56.000000000 +0100
@@ -272,7 +272,6 @@
time_adjust = 0; /* stop active adjtime() */
time_status |= STA_UNSYNC;
- time_state = TIME_ERROR; /* p. 24, (a) */
time_maxerror = NTP_PHASE_LIMIT;
time_esterror = NTP_PHASE_LIMIT;
write_sequnlock_irqrestore(&xtime_lock, flags);
My question:
I've read some documentation but I am by no means an expert in the NTP
kernel support implementation. So I ask you where the time_state should
be reset to TIME_OK. Should this be done by the <platform>set_rtc_time() ?
Or, as in the x86 case, do_settimeofday should not set time_state to
TIME_ERROR ?
Giovambattista Pulcini
^ 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