Re: RTC on 2.6.36 for PowerMac 8600
Hi, On 1/29/12, Andreas Schwab sch...@linux-m68k.org wrote: kevin diggs diggskevi...@gmail.com writes: Perhaps the RTC was reset due to battery running out? That would set the year to 1900, but the kernel RTC interface cannot represent dates before 1970. Unfortunately hwclock insists on reading the RTC even when you just want to write to it, so you cannot fix that with hwclock -w. When the battery of my iBook has run out I'm using the following to reset RTC to current time so that it is usable again. Andreas. Thanks! I did not know about this problem with the year. This vintage of mac sets the year to 1956. Yes, the battery is dead. It is one of those $20 1/3 AA lithium cells. I can't afford to replace it. I went into the MacOS Classic date control panel and set the year to 1971 and it worked! Thanks for the tip. I would have never figured this one out! kevin -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RTC on 2.6.36 for PowerMac 8600
Hi, What will give me access to the RTC hardware on an old PowerMac 8600? I modload rtc-generic. /proc/devices has: 254 rtc and ls -l /dev/rtc*: crw-r--r-- 2 root root 254, 0 Sep 2 2010 /dev/rtc crw-r--r-- 2 root root 254, 0 Sep 2 2010 /dev/rtc0 crw-r--r-- 1 root root 10, 135 Aug 10 2004 /dev/rtc.old Trying to run hwclock gives: [root@PowerMac8600B root]# hwclock --debug hwclock from util-linux-2.12pre Using /dev/rtc interface to clock. Last drift adjustment done at 131743 seconds after 1969 Last calibration done at 131743 seconds after 1969 Hardware clock is on local time Assuming hardware clock is kept in local time. Waiting for clock tick... /dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/rtc to change RTC_RD_TIME: Invalid argument ioctl() to /dev/rtc to read the time failed. I could have sworn this used to work on this system??? What am I forgetting? gzip -dc /proc/config.gz|grep -i rtc lists: CONFIG_RTC_LIB=m CONFIG_RTC_CLASS=m # RTC interfaces CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # Platform RTC drivers CONFIG_RTC_DRV_CMOS=m # on-CPU RTC drivers CONFIG_RTC_DRV_GENERIC=m Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cpu idle time going backward
On 12/8/11, Andreas Schwab sch...@linux-m68k.org wrote: There seems to be something wrong with cpu idle time accounting at least on G5. The value as reported in the cpu lines in /proc/stat seems to be stuck in the interval [10,21] for each cpu, jumping back at random points. Any idea what could be the problem? Andreas. -- What kernel versions? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MESH SCSI driver not working
Hi, I'll add some noise to this. I have a PowerMac8600 (with a 750GX in it (in case that makes a difference)) and I can't boot 2.6.36 if it is compiled with a gcc version newer than 4.1.2. Both 4.2.4 and 4.3.5 will hang. 4.1.2 seems ok. kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Powermac11,2
Hi, Anyone know what it means when a dual core dual cpu (total 4 cores) beeps three times on startup? The white power led also blinks 3 times every few seconds. The machine in question is a recent acquisition. I have got it to boot once. Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
Hi, On Wed, Jun 29, 2011 at 3:58 PM, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: drivers/cpufreq/powerpc. However my current version (as suggested by Ben) goes directly to drivers/cpufreq Uh ... Just curious ... why is arch specific code now being put outside of the arch directories? When I wrote the 750GX stuff (~2.6.28) I put in a location similar to what x86 was doing? When did this change? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
broken g5?
Hi, I would like to figure out if my G5 is broken. And if so how to fix it? As I have previously posted it behaves strangely when using the cpufreq driver. Anyone have suggestions to figure out what is going on? Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
Hi, On Tue, Jun 28, 2011 at 10:28 PM, Benjamin Herrenschmidt If we're going to have a Kconfig.powerpc, should we maybe just have a powerpc subdirectory instead with the driver in it ? Where would the powerpc subdirectory be? under drivers/cpufreq? Or somewhere under arch/powerpc where it belongs (and I put my 750GX stuff)? + printk(KERN_INFO Frequency method: SCOM, Voltage method: none\n); This is useless. Why? Cheers, Ben. kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
Hi, Try this one more time ... On Wed, Jun 29, 2011 at 3:54 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2011-06-29 at 12:40 +0400, Dmitry Eremin-Solenikov wrote: If you feel like it :-) The powermac one has quite a bit more plumbing for voltage control etc... but it does make sense in the long run. On my G5 (PowerMac7,3?), a dual 970FX @ 2.5G, I don't think the voltage scaling works correctly. If someone else with one of these (preferably someone who is NOT swamped (and named Ben)) could run some experiments. I would like to know whether the G5 I bought on ebay is some FrankenG5 and the others actually work correctly. To summarize, if I disable frequency scaling and look at the cpu core voltages it runs at the LOW voltage at full (i.e. 2.5 GHz) speed. With frequency scaling enabled, it runs the low speed at the same voltage it runs at 2.5 GHz without frequency scaling enabled. At the full speed it switches to a higher voltage. It WILL overheat if allowed to 'do stuff'. Temps above 110 are observed for cpu 1 (the second cpu in the serial (i.e. cpu 1 is heated by cpu 0) cooling setup - DUH!!!). The two voltages are like ~1.23 and ~1.35. Back when this beast had MacOS X, I think it exhibited similar behavior based on the fan noise. kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
g4 cube [off topic query]
Hi, Sorry for the noise ... But if anyone knows what a Cube power button gasket is made of please share! Is it conductive? Again, sorry for the noise. But I figured there might be some cube owners out here. Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
Hi, This is an SMP machine ? If not, does it work with a UP kernel ? Cheers, Ben. ??? Even if it is SMP, you can run non-SMP kernel on it, right? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: book to learn ppc assembly and architecture
Hi, On Mon, May 16, 2011 at 6:38 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Mon, 2011-05-16 at 16:37 +1000, Michael Neuling wrote: what is the best book to learn assembly and architecture . Assuming you have a powerpc compiler available you can use the -S option to produce assembly listings. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
HI, On Wed, Apr 13, 2011 at 3:58 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Actually I do get a crash in X later on... something in the radeon DRM interrupt code is getting what looks like a NULL dereference. I'll try to dig that one later on. I don't know if it's related to your problem at all though. In this context, what does 'crash' mean? The X thingy goes down? Or the whole OS? Cheers, kevin. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
Hi, On Wed, Apr 13, 2011 at 6:21 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2011-04-13 at 12:52 -0500, kevin diggs wrote: Actually I do get a crash in X later on... something in the radeon DRM interrupt code is getting what looks like a NULL dereference. I'll try to dig that one later on. I don't know if it's related to your problem at all though. In this context, what does 'crash' mean? The X thingy goes down? Or the whole OS? Depends, with xmon enabled you get into xmon :-) Dunno if the oops is fatal but it could be. Cheers, Ben. As I think I have the same hardware as you (7,3, radeon 9600) If you can tell me how to reproduce it maybe I can poke around a little. Thus, at least temporarily, freeing you up for other stuff. I kinda need a break from fighting with GCC. kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
Hi, Uh Oh. Are we gettin' booted (no pun intended)? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: halt/reset on assert?
On Thu, Apr 7, 2011 at 2:55 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2011-04-06 at 14:01 +0100, Evan Lavelle wrote:
#define MY_ASSERT(expr) if(!(expr)) BUG()
Make it
#define MY_ASSERT(expr) do { if } while(0)
To ensure it has proper single statement semantics in C.
So THAT'S why they do this!! Now I just have to figure out what
'proper single statement semantics' means!
THANKS!!!
kevin
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
PowerMac7,3 dvd drive?
Hi,
I am seeing ... issues with the optical drive (hda) under 2.6.36. I
can't mount disks:
[root@PowerMacG5 ~]# mount -r /dev/hda /mnt/cdrom
mount: /dev/hda already mounted or /mnt/cdrom busy
The log has:
[ 239.922268] hda: irq timeout: status=0xd0 { Busy }
[ 239.922485] hda: possibly failed opcode: 0xa0
eject hda will hang ... longer than my patience.
At first I thought the drive was going south. But I don't see this (at
least so far) on 2.6.28.
Thanks!
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: any chance to use a modern linux kernel on Pegasos1 G3 ?
Hi, For what it is worth, I can boot 2.6.36 on a PowerMac 8600 with a 750GX processor in it. I have to compile the kernel with gcc 4.1.2. Figuring out why 4.3.5 won't work is ... a work in progress (maybe an exorcism will help?). kevin On Sat, Mar 12, 2011 at 1:05 PM, nello martuscielli ppc.ad...@gmail.com wrote: hallo dear linuxppc kernel developers, i'm looking for some tips to use a modern linux kernel on my old Pegasos1 G3 600MHz (IBM PowerPC 750Cxe). The last working one is 2.6.16.x with arch=ppc. a picture of the screen when it freezes loading a modern kernel: http://i52.tinypic.com/33uzgc8.jpg thank you, Nel -- Power Mac G4 AGP 450MHz - CRUX PPC (32bit) 2.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
ongoing mesh saga ...
Hi, While trying to figure out why the MESH SCSI controller will not work with the 4.3.5 compiler but will work when compiled with 4.1.2, I noticed some ... unfortunate behavior from the 4.3.5 compiler. Before I try to see if I can fix it (i.e. the compiler), it would be nice to see if the issue still exists. Is there any chance someone with a compiler newer than 4.3.5 would be willing to get me -S output from a mesh compile (preferably not a module unless it does not make any difference) for 2.6.36. Using: head -1 top/drivers/scsi/.mesh.o.cmd you can get a command line which can then be edited to get a script to do a -S compile (watch out for the '\#' in KBUILD_STR(s)). Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ongoing mesh saga ...
Hi, On Fri, Mar 11, 2011 at 2:25 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: make drivers/scsi/mesh.s ??? I thought I have tried this in the past and it did not work? The make path/file.s thing? Thanks for the tip! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ongoing mesh saga ...
Hi, Good to know. I just tried this on an x86 laptop. It was NOT happy! And, obviously, I am not using a mesh SCSI controller on my Toshiba A75. And thanks again for your time! kevin On Fri, Mar 11, 2011 at 7:39 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: make drivers/scsi/mesh.s ??? I thought I have tried this in the past and it did not work? The make path/file.s thing? Thanks for the tip! You need to have the driver in your kernel config, or things will go weird. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: rtc on PowerMac7,3
Hi, Thanks for taking some of your valuable time to reply. Now I can't get it to fail. I don't know what I did wrong??? These things are tryin' to push me over the edge! Part of the problem may be the /dev/rtc (10:135 or whatever the PC numbers are) PC device that gets put into /dev/ (udev) on YDL 6.0. Should probably figure out who is adding it and nuke it. Sorry for the noise!?! kevin On Wed, Feb 23, 2011 at 6:09 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Not sure, I haven't looked at that RTC stuff for ages. Basically the platform code provides generic RTC hooks (in that G5 it's going to be via the via-pmu) and it should just work. That code hasn't been touched for eons. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
rtc on PowerMac7,3
Hi, Sorry for the noise. How do I access the rtc on a PowerMac7,3 (dual 2.5 GHz 970FX) using 2.6.36? rtc-generic does not seem to work. It will work on my 8600. I do see this: [ 15.014542] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0 Is it the hwclock binary: hwclock from util-linux-2.13-pre7 I think I could get this to work in 2.6.28 using rtc-ppc. Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: rtc on PowerMac7,3
On Wed, Feb 23, 2011 at 1:42 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: [ 15.014542] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0 rtc-generic should work... Cheers, Ben. It probably does on everyone else's 7,3. The 8600 probably infected it. ... I hear the two of them out there late at night. Mumbling to each other ... plotting ... kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, I have looked at the -S output for mesh.c from both 4.1.2 and 4.3.5. The generated code is quite different but I can not see any difference that is causing the problem? If I read and print the bus status register 0, it does appear to have the busy bit set? I'm in way over my head here. It appears to complete a pair of inquiries (one with a small data buffer and a second with a larger one) to each target. It then tries a test unit ready but discovers the bus busy? ANY suggestions welcome and appreciated! Thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, FYI: This driver has some pretty good diagnostics/debug capabilities built in. Once that is enabled it shows that the inquiry works and the sync negotiation works. The next command (I think) is test unit ready, which does not work. It is retried multiple times. The result is 2 which I think is DID_BUS_BUSY. Probably in mesh_start_cmd(), possibly something off in the loop at line 462? kevin P.S.: I posted some documentation for dump_stack()/show_stack() but have not heard anything? Is that not something we are interested in doing? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, FYI: I have narrowed this down to drivers/scsi/mesh.c (the root disk controller for the PowerMac 8600). I have compiled everything else for 2.6.36 with 4.3.5, including modules. With a 4.1.2 compiled mesh.c the beast boots. I am using it to post this follow up. kevin On Sat, Jan 22, 2011 at 12:24 PM, kevin diggs diggskevi...@gmail.com wrote: Hi, If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that WILL boot on the PowerMac8600 (single 750GX). The previously mentioned G4 that runs is a dual cpu beast and thus also runs SMP. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Ben, I know you are VERY busy. I appreciate your taking the time to reply. Since I'm am still using this thing I'll take a stab at trying to track it down. I just posted the FYI to see if I could trigger some thoughts (like your post). With a 4.3.5 compiled mesh, it fails a lot of early stuff like getting cache info? I don't remember the full list because it fails to find the root fs and does the reboot in 180 seconds thing (I still have in a back corner of my brain the serial console xmon boot stuff and will probably eventually try that). I am hopeful that since it (at least so far) always fails that it might not be THAT bad to track down. That coupled with some knowledge of what the compilers are doing differently can hopefully help track it down. Thanks! kevin On Wed, Feb 2, 2011 at 3:40 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: That's interesting... That driver is really nasty, we probably have a bug in it that's exposed by optimizations done by more recent compilers but it's not going to be trivial to figure out I'm afraid. I at least have very dim memories of mesh and how it operates... One thing to be careful of with Mesh is that the DMA engine, while supposedly cache coherent, has shown in the past to have issues when DMA'ing to unaligned memory locations. This shouldn't be a problem with normal block transfers but we may have to be careful with things like inquiry, mode pages, sense requests etc... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, And one more thing: Why does an SMP kernel (mesh compiled in an SMP enabled kernel) work? What all does SMP do? If it matters, I'm voluntary preempt. Is the DMA hardware in this thing used in any other system (I guess I mean both other computers and other sub-systems in this computer - does the 53c94 use it? The audio uses it, right?)? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 750gx cpufreq induced kernel panic in 2.6.36
On Tue, Jan 25, 2011 at 10:32 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: What are exception 700 901? 700 is a program check (illegal instruction or BUG_ON() statement) 900 is decrementer (aka timer) interrupt. The 0x1000c694 address looks fishy? That's userspace. So you took a timer interrupt, which got into hrtimer, and something you did caused cpufreq_notify_transition to crash, probably with a BUG_ON This should prove quite useful! Thanks! (which you can probably see above what you pasted, unless you don't have access to that part of the backtrace). This is kind of my problem. ANY suggestions (applicable to an old world PowerMac) would be appreciated on how to get access to the rest of the information. This thing appears completely dead at this point. Thanks! kevin P.S.: There are 2 columns of numbers: [xxx] [yyy] One of these is the PC. What is the other? stack? Cheers, Ben. Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
dump_stack doc
Hi,
Does this content look ok:
kevdig@SatelliteA75:/usr/src/linux-2.6.36/arch/powerpc/kernel$ diff
-U3 process.c process-new_c
--- process.c 2010-10-23 20:01:13.0 -0500
+++ process-new_c 2011-01-26 14:04:17.0 -0600
@@ -1107,6 +1107,27 @@
static int kstack_depth_to_print = CONFIG_PRINT_STACK_DEPTH;
+/**
+ * void show_stack() - dump the contents of the stack in readable format
+ * @struct task_struct *tsk: pointer to task struct owning stack frame
+ * @unsigned long *stack: pointer to stack frame
+ *
+ * Dump the stack in bipedal carbon unit readable form. Format is:
+ * Call Trace:
+ * [[ --- Exception: trap id (%lx) at trap handler (%pS) ]]
+ * [[ LR = trapping routine (%pS) ]]
+ * [stack (REG)] [instruction (REG)] instruction (%pS) [[
(unreliable)]]
+ *
+ * Information between '[[' ']]' is optional. Additional information is
+ * printed at the beginning of what are believed to be exception frames.
+ *
+ * The first frame is considered unreliable and will have (unreliable)
+ * tacked on the end.
+ *
+ * kstack_depth_to_print determines how many frames to show.
+ *
+ * Value in parenthesis is the format specifier used. See printk().
+ */
void show_stack(struct task_struct *tsk, unsigned long *stack)
{
unsigned long sp, ip, lr, newsp;
@@ -1177,6 +1198,11 @@
} while (count++ kstack_depth_to_print);
}
+/**
+ * void dump_stack(void) - dump the contents of the stack in readable form
+ *
+ * See process.c`show_stack() for details
+ */
void dump_stack(void)
{
show_stack(current, NULL);
kevin
--- process.c 2010-10-23 20:01:13.0 -0500
+++ process-new_c 2011-01-26 14:04:17.0 -0600
@@ -1107,6 +1107,27 @@
static int kstack_depth_to_print = CONFIG_PRINT_STACK_DEPTH;
+/**
+ * void show_stack() - dump the contents of the stack in readable format
+ * @struct task_struct *tsk: pointer to task struct owning stack frame
+ * @unsigned long *stack: pointer to stack frame
+ *
+ * Dump the stack in bipedal carbon unit readable form. Format is:
+ * Call Trace:
+ * [[ --- Exception: trap id (%lx) at trap handler (%pS) ]]
+ * [[ LR = trapping routine (%pS) ]]
+ * [stack (REG)] [instruction (REG)] instruction (%pS) [[ (unreliable)]]
+ *
+ * Information between '[[' ']]' is optional. Additional information is
+ * printed at the beginning of what are believed to be exception frames.
+ *
+ * The first frame is considered unreliable and will have (unreliable)
+ * tacked on the end.
+ *
+ * kstack_depth_to_print determines how many frames to show.
+ *
+ * Value in parenthesis is the format specifier used. See printk().
+ */
void show_stack(struct task_struct *tsk, unsigned long *stack)
{
unsigned long sp, ip, lr, newsp;
@@ -1177,6 +1198,11 @@
} while (count++ kstack_depth_to_print);
}
+/**
+ * void dump_stack(void) - dump the contents of the stack in readable form
+ *
+ * See process.c`show_stack() for details
+ */
void dump_stack(void)
{
show_stack(current, NULL);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 750gx cpufreq induced kernel panic in 2.6.36
On Wed, Jan 26, 2011 at 3:43 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: You don't have a serial port ? Yeah, just did not know what to do with them? If you do, use sccdbg on the kernel command line to route xmon to it, and boot with console=ttyPZ0,38400 (I think the old things default to 38400 bauds). Use the modem port. Ok! Thanks! One thing. The 2.6 driver for the serial ports on this machine does not work very well. Can I use a slower speed to avoid missing stuff? And I'll need to build the serial stuff into the kernel, right? Thanks for the reply! Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
750gx cpufreq induced kernel panic in 2.6.36
Hi, The cpufreq driver I wrote for the 750gx causes a kernel panic in 2.6.36. This is from a screen shot: [c6035f30] [c001014c] timer_interrupt+0x13c/0x19c [c6035f40] [c0013294] ret_from_except+0x0/0x14 --- Exception: 901 at 0x1000c694 LR = 0x1000f3e4 Instruction dump: 4b48 38610008 4be7b2b1 4b9c 9421fff0 7c0802a6 bfc10xxx 90010014 7ca6 68008000 54008ffe 0f00 3d20c030 2f84 Kernel panic - not syncing: Fatal exception in interrupt Call Trace: [c6035bf0] [c00084e4] show_stack+0x3c/0x160 (unreliable) [c6035c20] [c002cf44] panic+0xa4/0x1c8 [c6035c70] [c001085c] die+0x194/0x1a0 [c6035c90] [c0010aa8] _exception+0xfc/0x108 [c6035d80] [c0013248] ret_from_except_full+0x0/0x4c --- Exception: 700 at cpufreq_notify_transition+0x20/0x128 LR = cf750gx_pll_switch_cb+0x20/0xd0 [cf750gx] [c6035e40] [c02e2280] 0xc02e2280 (unreliable) [c6035e50] [ddc4b3dc] cf750gx_pll_switch_cb+0x20/0xd0 [cf750gx] [c6035e60] [c004d7ac] notifier_call_chain+0x60/0xb0 [c6035e80] [ddc361c4] pllif_i_switch_PLLs+0xa0/0x140 [pll_if] [c6035e90] [ddc365fc] pllif_i_timer_f+0x4c/0x6c [pll_if] [c6035ea0] [c004bb24] __run_hrtimer+0x44/0xb8 [c6035eb0] [c004c1f8] hrtimer_interrupt+0x10c/0x388 [c6035f30] [c001014c] timer_interrupt+0x13c/0x19c [c6035f40] [c0013294] ret_from_except+0x0/0x14 --- Exception: 901 at 0x1000c694 LR = 0x1000f3e4 Rebooting in 180 seconds.._ What are exception 700 901? The 0x1000c694 address looks fishy? Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, I've never done any real kernel debugging. Can anyone give any pointers on how to do early boot debugging on an old world (buggy OF) powermac? Can I do anything using a serial console? A little reading last night suggested that spinlocks are supposed to disappear for single processor machines. I do not understand why they are present in 3.4.6 (at least the symbol anyway)? The 'acct_lock' spin lock was also missing with gcc 4.2.4. kevin On Sat, Jan 22, 2011 at 12:24 PM, kevin diggs diggskevi...@gmail.com wrote: Hi, If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that WILL boot on the PowerMac8600 (single 750GX). The previously mentioned G4 that runs is a dual cpu beast and thus also runs SMP. I at least know this (ok, I THINK I know): For non-SMP: The spinlock 'acct_lock' in kernel/acct.c that IS present in 3.4.6 (i.e. kernel 2.6.28 compiled with gcc 3.4.6). Not so much for 4.3.5. I have not yet done a general 4.3.5 compiled 2.6.28 spinlock safari. Don't some funky, optimizery things happen to spinlocks for the NON-smp case? I'll see what the 4.2.x gcc does. Thanks! kevin P.S.: There is one other difference for the SMP 4.3.5 compiled 2.6.28: my 750gx cpufreq driver gets disabled. It is fairly isolated code though. Should not be able to nuke the spinlock in kernel/acct.c On Fri, Jan 21, 2011 at 1:26 PM, kevin diggs diggskevi...@gmail.com wrote: Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that WILL boot on the PowerMac8600 (single 750GX). The previously mentioned G4 that runs is a dual cpu beast and thus also runs SMP. I at least know this (ok, I THINK I know): For non-SMP: The spinlock 'acct_lock' in kernel/acct.c that IS present in 3.4.6 (i.e. kernel 2.6.28 compiled with gcc 3.4.6). Not so much for 4.3.5. I have not yet done a general 4.3.5 compiled 2.6.28 spinlock safari. Don't some funky, optimizery things happen to spinlocks for the NON-smp case? I'll see what the 4.2.x gcc does. Thanks! kevin P.S.: There is one other difference for the SMP 4.3.5 compiled 2.6.28: my 750gx cpufreq driver gets disabled. It is fairly isolated code though. Should not be able to nuke the spinlock in kernel/acct.c On Fri, Jan 21, 2011 at 1:26 PM, kevin diggs diggskevi...@gmail.com wrote: Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix some 6xx/7xxx CPU setup functions
On Fri, Jan 21, 2011 at 12:35 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Some of those functions try to adjust the CPU features, for example to remove NAP support on some revisions. However, they seem to use r5 as an index into the CPU table entry, which might have been right a long time ago but no longer is. r4 is the right register to use. Can you quantify 'a long time ago'? Is this compiler dependent? This probably caused some off behaviours on some PowerMac variants using 750cx or 7455 processor revisions. what about a 750gx? Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- Can somebody with one of these PowerMacs test this ? I only managed to find a 7448 which not directly affected... I have a GigE (PowerMac 3,4?) with an upgrade card that has a pair of 7455s on it and an 8600 with a 750GX cpu card. I can probably test this on the GigE. It is running 2.6.36. Is that recent enough? The 8600 is not cooperating. The GigE is running 2.6.36 compiled with 4.3.5 built from sources. It seems to run fine. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
BootX
Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
elf section .text.unlikely
Hi, I am trying to get a PowerMac 8600 to boot past 2.6.28. I can boot 2.6.28 compiled with either 3.3.3 or 3.4.6. I can't get 2.6.28 to boot using 4.3.5. The 4.3.5 vmlinux has a section '.text.unlikely' that the 3.4.6 version does not. Anyone know what this might be? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, This would require quik, right? I went to penguinppc.org and tried to get the latest BootX and quik but the links are dead. Do you know where the latest versions are? kevin On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote: Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? It's possible. Have you tried using OF booting instead ? The 8600 should be cable to boot off SCSI or netboot COFF images. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, The link: http://www.shiner.info/?files/Yellow%20Dog%20Linux%204/quik to download the latest source does not seem to have anything useful??? kevin On Fri, Jan 21, 2011 at 7:50 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote: Hi, This would require quik, right? I went to penguinppc.org and tried to get the latest BootX and quik but the links are dead. Do you know where the latest versions are? That link still works: Oops... typing FAIL :-) I meant: http://penguinppc.org/bootloaders/quik/ However, it's possible that distros like debian have done more changes to it. Another option is to netboot a zImage directly, which works if it's not too big. Cheers, Ben. kevin On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote: Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? It's possible. Have you tried using OF booting instead ? The 8600 should be cable to boot off SCSI or netboot COFF images. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: elf section .text.unlikely
For what it is worth, this section contains dump_stack, panic, and printk Thanks! kevin On Fri, Jan 21, 2011 at 7:40 PM, kevin diggs diggskevi...@gmail.com wrote: Hi, I am trying to get a PowerMac 8600 to boot past 2.6.28. I can boot 2.6.28 compiled with either 3.3.3 or 3.4.6. I can't get 2.6.28 to boot using 4.3.5. The 4.3.5 vmlinux has a section '.text.unlikely' that the 3.4.6 version does not. Anyone know what this might be? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: elf section .text.unlikely
Hi, One more thing: The last message printed is: Driver 'sd' needs updating - please us bus_type methods The mesh SCSI controller seems to successfully scan the bus. The next message that a 3.4.6 compiled kernel prints are details about disk sda (from SCSI disk driver?). 4.3.5 keyboard is dead. Jog any thoughts? Thanks! kevin On Fri, Jan 21, 2011 at 8:31 PM, kevin diggs diggskevi...@gmail.com wrote: For what it is worth, this section contains dump_stack, panic, and printk Thanks! kevin On Fri, Jan 21, 2011 at 7:40 PM, kevin diggs diggskevi...@gmail.com wrote: Hi, I am trying to get a PowerMac 8600 to boot past 2.6.28. I can boot 2.6.28 compiled with either 3.3.3 or 3.4.6. I can't get 2.6.28 to boot using 4.3.5. The 4.3.5 vmlinux has a section '.text.unlikely' that the 3.4.6 version does not. Anyone know what this might be? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Make auto-loading of therm_pm72 possible
Hi, On a sort of related issue, if anyone out there has a PowerMac7,3 (dual 2.5 GHz 970Fx, PCI-X), I would appreciate it if you could do me a favor. I think this therm_pm72 thing creates the sysfs temperature and voltage attributes for the cpus. I noticed on my machine that if I use the cpufreq driver for this thing the frequencies were like 2.0 and 2.5. The problem is that the cpu voltages were something like 1.25 and 1.37 respectively. At 1.37 and 2.5 GHz, cpu 1 would zoom to 110+ under load. When I finally managed to get a compiler built that could build a kernel past 2.6.28, I removed the cpufreq driver. Now this thing runs at 2.5 GHz all the time. Under load cpu1 tops out at like 74 ish. I eventually noticed that the voltage was 1.25. Huh? I thought this voltage scaling business used the high voltage for the high frequency. How can this thing be running at its high speed at the lower voltage??? Can someone please confirm this behavior on a different 7,3? I did get this thing off of ebay and might have myself a franken G5? Thanks! kevin P.S.: I also don't get the 2.0 GHz low speed? I thought with the FX the speed would be 2.5 / 2 or 1.25? Does this beast NOT use the FX's frequency scaling capabilities? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerMac8600 help ...
Hi,
I have managed to boot the G4 (GigE) using a kernel built with the
4.3.5 compiler on the 8600. I have also discovered what prevented
firefox from working with 4.3.5. It was picking up the 3.4.6 libstdc++
(possibly other internal tidbits as well). Even something as simple
as:
#include iostream
#include string
using namespace std;
inline void pr_message(string s=Hello world!) {
coutsendl;
}
int main()
{
pr_message();
}
Won't run using 4.3.5 and the libstdc++ from 3.4.6. They were both
installed because I used 3.4.6 to build 4.3.5 after discovering that
3.4.6 can't build the kernel either.
So ... I am back to why I can't get a newer kernel running on the 8600???
Thanks!
kevin
P.S.: newer powermacs have a line in cpuinfo, like PowerMac 7,2.
Does this uniquely identify a particular model?
On 11/11/10, kevin diggs diggskevi...@gmail.com wrote:
Ben,
Thanks for taking the time to reply. I tried removing some memory that
I suspect might be less than ideal. The result was the same. So I
don't think the problem is memory related. Also the latest firefox
build using gcc 4.3.5 I tried was with CFLAGS=-O0 -mcpu=powerpc.
This should chew up less memory than a gcc 3.4.6 build with -O2
-mcpu=750 -mmultiple, right?
I'm gonna switch to the GigE and try a 2.6.36 with the 8600 config and
a firefox build using 4.3.5. The GigE has an hd5500 HDTV card in it!
Thanks again for taking the time to try to help!
kevin
P.S.: I have discovered that one should not build firefox with
-mpowerpc-gpopt for a 750GX cauz it ain't not got no hardware fsqrt!
Off the top of your head would you know which of the ppc32 processors
has fsqrt? Is it only the 604?
On Mon, Nov 8, 2010 at 4:31 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Mon, 2010-11-08 at 10:43 -0600, kevin diggs wrote:
Sorry for the noise but I am having trouble getting the latest kernel
built for a PowerMac8600 with a 750GX processor card. If this is not
an appropriate topic for the list please tell me (and hopefully point
me in the correct direction).
I have narrowed the problem down to the compiler. YDL 4.0 is installed
on the machine. The stock compiler is 3.3.3. That version can NOT
build past 2.6.28. I built 3.4.6, (the latest 3 series I could find).
It can NOT build later kernel versions either. It can build Firefox
2.0.0.15pre, including powerpc thin lock support. Running it now.
I then tried 4.3.5. This will build the kernel. But the resulting
kernel will NOT run. A firefox built with 4.3.5 also will not run. Or
if it runs it crashes often (http://abcnews.com).
What really puzzles me is I used the same basic compiler boot
strapping (3.3.3 to build 3.4.6, 3.4.6 to build 4.3.5) on a GiGE. That
machine is now running 2.6.36.
The CFLAGS used were: -O2 -mcpu=7450 -mmultiple -mstring for the
GiGE (dual 7455s). Substitute 750 for the 8600.
Any suggestions would be appreciated.
This is odd... I wonder if your 8600 is having some memory problems ?
Have you tried using the kernel/firefox built with 4.3.5 on the GigE and
booting them on the 8600 ?
3.x are ancient but I would expect 4.3.x to work just fine
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
PowerMac8600 help ...
Hi,
Sorry for the noise but I am having trouble getting the latest kernel
built for a PowerMac8600 with a 750GX processor card. If this is not
an appropriate topic for the list please tell me (and hopefully point
me in the correct direction).
I have narrowed the problem down to the compiler. YDL 4.0 is installed
on the machine. The stock compiler is 3.3.3. That version can NOT
build past 2.6.28. I built 3.4.6, (the latest 3 series I could find).
It can NOT build later kernel versions either. It can build Firefox
2.0.0.15pre, including powerpc thin lock support. Running it now.
I then tried 4.3.5. This will build the kernel. But the resulting
kernel will NOT run. A firefox built with 4.3.5 also will not run. Or
if it runs it crashes often (http://abcnews.com).
What really puzzles me is I used the same basic compiler boot
strapping (3.3.3 to build 3.4.6, 3.4.6 to build 4.3.5) on a GiGE. That
machine is now running 2.6.36.
The CFLAGS used were: -O2 -mcpu=7450 -mmultiple -mstring for the
GiGE (dual 7455s). Substitute 750 for the 8600.
Any suggestions would be appreciated.
Thanks!
kevin
P.S.: Why does this program work:
int main(int argc, char *argv[])
{
unsigned int pvr;
// asm(mfspr %0,22\n
asm(mfspr %0,287\n
:=r (pvr)
);
printf(pvr is 0x%x\n,pvr);
}
From what I have read, access to the pvr is restricted? strace does
not show an illegal instruction trap for SPRN_PVR.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
old MESH SCSI driver
Hi, I am trying to get 2.6.36 running on an old PowerMac 8600. It can't seem to find the root device. There are some messages about the disks on the bus. But they don't look quite right. It is currently running 2.6.28. Any suggestions? Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
PowerMac G4 RAM
Hi, I have a G4 that has 1.25 G of ram. Under Linux I only get 768M? Anyone know why? It is a GiGE with a dual 7455 PowerLogix cpu upgrade. Kernel is 2.6.28. Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerMac G5 config
Hi, Apparently, for some reason, you can't use -depth in your find command when rebuilding your initrd??? Machine is now running 2.6.36. Glad to be rid of that awful cpufreq driver ... kevin On Mon, Oct 25, 2010 at 1:45 PM, kevin diggs diggskevi...@gmail.com wrote: Hi, I have a G5 (dual 970FX, june 2004?) running YDL 6.0. After fighting to get a compiler that will build 2.6.29+ (4.2.1 - 4.2.2) I can't get it to boot. It spits out a bunch of message about devices (I think the last ones are USB related) and then says: Restarting System and then reboots. I've attached a diff of the 2.6.28 config that will boot. Any suggestions would be greatly appreciated. Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
PowerMac G5 config
Hi, I have a G5 (dual 970FX, june 2004?) running YDL 6.0. After fighting to get a compiler that will build 2.6.29+ (4.2.1 - 4.2.2) I can't get it to boot. It spits out a bunch of message about devices (I think the last ones are USB related) and then says: Restarting System and then reboots. I've attached a diff of the 2.6.28 config that will boot. Any suggestions would be greatly appreciated. Thanks! kevin --- - 2010-10-25 08:42:09.039422000 -0500 +++ /usr/src/linux-2.6.30/.config 2010-10-25 07:32:11.0 -0500 @@ -1,13 +1,14 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.28 -# Wed Dec 31 08:44:43 2008 +# Linux kernel version: 2.6.30 +# Mon Oct 25 07:32:11 2010 # CONFIG_PPC64=y # # Processor support # +CONFIG_PPC_BOOK3S=y CONFIG_POWER4_ONLY=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set @@ -15,6 +16,7 @@ CONFIG_ALTIVEC=y # CONFIG_VSX is not set CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y @@ -45,7 +47,7 @@ CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y -CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y @@ -53,6 +55,7 @@ CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y +CONFIG_DTC=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_HIBERNATE_64=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y @@ -60,6 +63,7 @@ # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_PPC_OF_PLATFORM_PCI is not set +CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # @@ -74,17 +78,27 @@ CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y +CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y + +# +# RCU Subsystem +# +CONFIG_CLASSIC_RCU=y +# CONFIG_TREE_RCU is not set +# CONFIG_PREEMPT_RCU is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 -# CONFIG_CGROUPS is not set # CONFIG_GROUP_SCHED is not set +# CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set @@ -93,23 +107,27 @@ # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set +# CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= -CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_RD_GZIP=y +CONFIG_RD_BZIP2=y +CONFIG_RD_LZMA=y +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y +# CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y -CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y -CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y @@ -118,6 +136,7 @@ CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y +CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set @@ -126,16 +145,17 @@ CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y +CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y +# CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y -# CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set @@ -143,10 +163,8 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set -CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y -# CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLOCK_COMPAT=y @@ -163,13 +181,11 @@ # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory -CONFIG_CLASSIC_RCU=y -CONFIG_FREEZER=y +# CONFIG_FREEZER is not set # # Platform support # -CONFIG_PPC_MULTIPLATFORM=y # CONFIG_PPC_PSERIES is not set # CONFIG_PPC_ISERIES is not set CONFIG_PPC_PMAC=y @@ -181,8 +197,10 @@ # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE is not set # CONFIG_PPC_CELLEB is not set +# CONFIG_PPC_CELL_QPACE is not set # CONFIG_PQ2ADS is not set CONFIG_PPC_NATIVE=y +CONFIG_PPC_OF_BOOT_TRAMPOLINE=y # CONFIG_IPIC is not set CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set @@ -195,27 +213,9 @@ CONFIG_PPC_970_NAP=y # CONFIG_PPC_INDIRECT_IO is not set # CONFIG_GENERIC_IOMAP is not set -CONFIG_CPU_FREQ=y -CONFIG_CPU_FREQ_TABLE=y -# CONFIG_CPU_FREQ_DEBUG is not set -CONFIG_CPU_FREQ_STAT=m
Re: schizophrenic G5 ...
Kevin Diggs wrote: Hi, I have a water cooled dual 2.5 GHz G5 (Powermac7,3). It has YDL 6.0 on it. Using the stock YDL 2.6.23 kernel this machine appears to work fine. After finally getting it to boot under 2.6.27, it will shut itself off if put under any significant load. And it is doing it very quickly. Like within a few seconds of becoming busy. I just discovered it is spitting out messages about temperature way above maximum (from therm_pm72.c). This one has the Panasonic cooling system. I have checked behind the cover and see no evidence of leaks. When put under load under the stock YDL kernel, the cpu fans will speed up for about 2 minutes. Then over the next minute or so they will slow down almost to idle. Thereafter a whirring sound can be heard every 15 to 30 seconds lasting about 5 seconds. Which I am guessing is the pump? The exhaust air barely gets warm? If I run: while true; do echo -n cpu0\: ; cat cpu0_temperature; echo -ne \t; cat cpu0_current; echo ; echo -n cpu1\: ; cat cpu1_temperature; echo -ne \t; cat cpu1_current; echo ; sleep 1; done in one window and: time /home/kevdig//r-970 -b4 -s1|nice -19 bzip2 -9v|dd bs=4b count=40 of=/dev/null in two others I see different results between 2.6.23 and 2.6.27. Under the stock YDL 6.0 2.6.23 kernel, the temperatures level off at 50 and 70. Peak temps are about 56 and 76. Idle temps are about 46 and 54. Under 2.6.27, if I run ONE I see cpu1 temps range from 74 - 89 - 105 - 111 - 86. All one second apart. This happened pretty fast. Once I saw the 111 I ^c'ed the process. Can the temp really change that fast? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: schizophrenic G5 ...
Benjamin Herrenschmidt wrote: On Sun, 2008-12-21 at 16:11 -0800, Kevin Diggs wrote: Hi, I have a water cooled dual 2.5 GHz G5 (Powermac7,3). It has YDL 6.0 on it. Using the stock YDL 2.6.23 kernel this machine appears to work fine. After finally getting it to boot under 2.6.27, it will shut itself off if put under any significant load. And it is doing it very quickly. Like within a few seconds of becoming busy. I just discovered it is spitting out messages about temperature way above maximum (from therm_pm72.c). This one has the Panasonic cooling system. I have checked behind the cover and see no evidence of leaks. When put under load under the stock YDL kernel, the cpu fans will speed up for about 2 minutes. Then over the next minute or so they will slow down almost to idle. Thereafter a whirring sound can be heard every 15 to 30 seconds lasting about 5 seconds. Which I am guessing is the pump? The exhaust air barely gets warm? Anyone have any ideas? Could the cooling system NOT be correctly thermally connected to the cpus? I would appreciate it if one of the many people on this list that are way more smarterer than me could tell me something like, If this were true you would have toasted the cpus already! I have approx. the same here taking dust under the desk, I'll give it a spin but i might have to wait a couple of days... If mine works, then we'll have to run some more intensive debugging to see what's going on. Cheers, Ben. Ben, I would appreciate it. I am now kinda afraid to turn the thing on. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: schizophrenic G5 ...
Christian Krafft wrote: On Sun, 21 Dec 2008 16:11:43 -0800 Kevin Diggs kev...@hypersurf.com wrote: Hi, I have a water cooled dual 2.5 GHz G5 (Powermac7,3). It has YDL 6.0 on it. Using the stock YDL 2.6.23 kernel this machine appears to work fine. After finally getting it to boot under 2.6.27, it will shut itself off if put under any significant load. And it is doing it very quickly. Like within a few seconds of becoming busy. I just discovered it is spitting out messages about temperature way above maximum (from therm_pm72.c). I have a very similar problem on my mac at work. I don't know atm how to look up the critical temperature that is fused. My mac reported only 55 degrees for the one cpu. The critical temperature can be read from the device-tree if i remember it correctly. I heard that there exists a bootable CD which contains a tool to refuse the CPU. Dont know where to download it, so my pragmatic solution was to relocate the machine to a room with air conditioning ;-) And I also run the ONE cpu at lowest frequency. ck Critical temperature? If it is in the device tree are we sure it isn't (from the 970fx_thermal_diode_an, page 2, second paragraph): In the PowerPC970FX family, the thermal diode is calibrated at a specified calibration temperature, usually around 70C, with no power on the chip, VDD = 0.0V, and 100 micro-amps being driven through the diode. The voltage across the diode is measured; it should be between 0.60V and 0.80V. The measured voltage and temperature is stored in Thermal Diode Calibration fuse bits. A second lower temperature value is used to set the second calibration point, refer to the datasheet for this value. On page 3 it also has: Reading Thermal Diode Calibration Data Via JTAG In order to access the Thermal Diode Calibration data stored in each processor, a sequence of JTAG commands must be issued, usually over the IIC bus. By using JTAG commands, the desired data will appear serially on the PowerPC970FX TDO pin or can be read using IIC. The detailed information on how to perform the read operation of the calibration registers is found in the PowerPC970FX User s Manual. Reading the thermal diode calibration register should be a one-time-only procedure. It is assumed that the Thermal Diode Calibration data stored in each processor will be captured and stored in system ROM for subsequent use. kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
schizophrenic G5 ...
Hi, I have a water cooled dual 2.5 GHz G5 (Powermac7,3). It has YDL 6.0 on it. Using the stock YDL 2.6.23 kernel this machine appears to work fine. After finally getting it to boot under 2.6.27, it will shut itself off if put under any significant load. And it is doing it very quickly. Like within a few seconds of becoming busy. I just discovered it is spitting out messages about temperature way above maximum (from therm_pm72.c). This one has the Panasonic cooling system. I have checked behind the cover and see no evidence of leaks. When put under load under the stock YDL kernel, the cpu fans will speed up for about 2 minutes. Then over the next minute or so they will slow down almost to idle. Thereafter a whirring sound can be heard every 15 to 30 seconds lasting about 5 seconds. Which I am guessing is the pump? The exhaust air barely gets warm? Anyone have any ideas? Could the cooling system NOT be correctly thermally connected to the cpus? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
970FX thermal diode on G5
Hi, Is the thermal diode on a 970FX used on a G5? Can it be read by software? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
What means technology has been retired?
Does anyone know what the statement: This technology has been retired. on this page: http://www.alphaworks.ibm.com/tech/powerscale4ppc means? Something about 970FX frequency scaling? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pmac_zilog debugging ...
Benjamin Herrenschmidt wrote: On Thu, 2008-11-13 at 14:29 -0800, Kevin Diggs wrote: Benjamin Herrenschmidt wrote: On Thu, 2008-11-13 at 03:38 -0800, Kevin Diggs wrote: 12,206 PowerMac Zilog interrupts Interrupt load is higher without the DMA support. Is it possible that this hardware was not meant to be used without the DMA (i.e. it does not work quite right?)? Well, the HW Rx buffer is only 3 bytes so if you have high interrupt latencies you are more likely to loose data... These are not real 8530s any more, right? How certain are we of this? Is it possible that there is a larger buffer when used with the DMA capability ... somehow? Well, the main thing is that when using DMA, it doesn't need to wait for the kernel to come fetch the bytes, and thus the only latency that matters if the DMA list is appropriately provisioned is the bus latency, which is much less likely to be an issue even with a small buffer. ... if the DMA list is appropriately provisioned ... ??? It's definitely not a basic 8530, it's an ESCC but I don't think the base rx buffer in polled mode is any bigger (I may be wrong). Any idea how we might find out? I tried to put some debug statements where the flow lines are managed. I could have goofed it up. They never produce any output. The latest attempt used nortscts which should have disabled flow control. That coupled with the fact that a 250 MHz 750GX is talking to a 486dx4 at 1200 - 9600 baud I would have thought would reduce the chance the PowerMac would fall behind? Have you disabled flow control both with the old macserial -and- pmac_zilog and still experiencing the same problems ? (ie one works and the other one doesn't ?) I reinstalled the disk with 2.4.31 and reran the tests. With nortscts added to the pppd options macserial still works fine. Even at 115,200 it seemed fine (I expected to see some type of packet errors via pppstats or ifconfig). I did not, however, verify that pppd actually does something with this option. I can't get pmac_zilog to work even at 1200 baud. That is pretty slow. You would need to explain to me the advantage of doing DMA in this case??? Well, if I setup for example 128 DMA descriptors for 1 byte each, then the chip will be able to DMA up to 128 bytes without CPU intervention, thus is a -lot- less likely to overflow it's fifo. It's essentially a way to have the DMA engine operate as an external FIFO. As the CPU fetches the bytes, it can recycle the descriptors at the end of the list effectively acting as some kind of ring buffer. We can more easily do DMA for Tx but while this can improve performances and lower interrupt usage, it is not a correctness issue in the sense that Tx isn't -losing- data today, it's Rx that is a potential problem. Ah! I think I get it. I was thinking that cpu intervention would be required after each byte. But the descriptors are more like linked commands for the DMA hardware. So, I'm on board with this approach. Since I don't really know what I am doing, how do you recommend I proceed? Would it be correct to say that DMA would also free the cpu from doing io accesses which are MUCH slower than normal memory acdcesses? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pmac_zilog debugging ...
Benjamin Herrenschmidt wrote: That's definitely strange. I would expect the kernel to be able to get interrupts fast enough to service a 1200 bauds serial port. Maybe there's something else wrong, or an other driver causing undue interrupt latencies As far as I can see the system is NOT busy. I see no evidence of excessive interrupt loading. It does have an Adaptec 2940 u2w SCSI card, an ATI video card, and a USB/firewire card. The SCSI card has some disks on it. The other two cards are unused. I guess, in theory, something in my 2.6.27 kernel could be causing one of the two unused cards to throw spurious interrupts? I still think the hardware is mis-behaving. Out of curiosity, check that IDE properly unmasks interrupts (hdparm -u1 /dev/hda). This is an 8600. It is SCSI only (the onboard controller is the MESH). So, I'm on board with this approach. Since I don't really know what I am doing, how do you recommend I proceed? Google for a document called MacTech.pdf which contains various documentations for bits of the ancestor of the IO chip in your machine, along with a description of the DBDMA engine :-) Something else you can do is to look at how it's properly used by other drivers such as bmac and look at some of the darwin source code for reference on how the HW works. where might one find older Darwin source? Cheers, Ben. ___ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pmac_zilog debugging ...
Benjamin Herrenschmidt wrote: On Thu, 2008-11-13 at 03:38 -0800, Kevin Diggs wrote: 12,206 PowerMac Zilog interrupts Interrupt load is higher without the DMA support. Is it possible that this hardware was not meant to be used without the DMA (i.e. it does not work quite right?)? Well, the HW Rx buffer is only 3 bytes so if you have high interrupt latencies you are more likely to loose data... These are not real 8530s any more, right? How certain are we of this? Is it possible that there is a larger buffer when used with the DMA capability ... somehow? Now, as I said, have you looked at flow control ? It's a likely cause of problems and it's possible that pmac_zilog doesn't do it the way macserial did... I tried to put some debug statements where the flow lines are managed. I could have goofed it up. They never produce any output. The latest attempt used nortscts which should have disabled flow control. That coupled with the fact that a 250 MHz 750GX is talking to a 486dx4 at 1200 - 9600 baud I would have thought would reduce the chance the PowerMac would fall behind? Regarding DMA, it's possible to implement, though there were interesting issues with the way it was done in macserial, it should be done differently in pmac_zilog. I think the only approach that really works properly (though it's fugly) is what Apple does in OSX I think, which is to have a DMA descriptor per input byte (no need for a huge DMA buffer anyway). You would need to explain to me the advantage of doing DMA in this case??? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
pmac_zilog debugging ...
Hi, If I use a command similar to: pppd ttyS0 1200 satellites: netmask 255.255.255.0 lock crtscts mru 1064 noauth debug kdebug 7 logfile /tmp/pppd.log local to connect an 8600 to a laptop via ppp the link will lock up in short order from payloaded pings. Any advice on how to figure out where it is locking up? This command works fine to connect two x86 laptops. At 1200 it does take a while for an xterm to show up, though. kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
Benjamin Herrenschmidt wrote: What does this all mean to my GigE (dual 1.1 GHz 7455s)? Is this thing supposed to be able to spread irq between its cpus? Depends on the interrupt controller. I don't know that machine but for example the Apple Dual G5's use an MPIC that can spread based on an internal HW round robin scheme. This isn't always the best idea tho for cache reasons... depends if an at what level your caches are shared between CPUs. Ben. Sorry. I thought GigE was a common name for the machine. It is a dual 450 MHz G4 powermac with a gigabit ethernet and AGP. It now has a PowerLogix dual 1.1 GHz 7455 in it. I think the L3 caches are seperate? Not sure about the original cpu card. Can the OS tell? The reason I asked is that I seem to remember a config option that would restrict the irqs to cpu 0? Help suggested it was needed for certain PowerMacs. Didn't provide any help as to which ones. My GigE currently spreads them between the two. I have not noticed any additional holes in the space time contiuum. kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
Benjamin Herrenschmidt wrote: On Fri, 2008-10-24 at 16:18 -0700, David Miller wrote: From: Kumar Gala [EMAIL PROTECTED] Date: Fri, 24 Oct 2008 10:57:38 -0500 Commit 18404756765c713a0be4eb1082920c04822ce588 introduced a regression on a subset of SMP based PPC systems whose interrupt controller only allow setting an irq to a single processor. The previous behavior was only CPU0 was initially setup to get interrupts. Revert back to that behavior. Signed-off-by: Kumar Gala [EMAIL PROTECTED] I really don't remember getting all of my interrupts only on cpu 0 on sparc64 before any of these changes. I therefore find all of this quite mysterious. :-) Well, I don't know how you do it but on powerpc, we explicitely fill the affinity masks at boot time when we can spread interrupts... Maybe we should change it the other way around and limit the mask when we can't ? It's hard to tell for sure at this stage. Ben. What does this all mean to my GigE (dual 1.1 GHz 7455s)? Is this thing supposed to be able to spread irq between its cpus? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: gigE 2.6.27 USB
Benjamin Herrenschmidt wrote: On Tue, 2008-10-14 at 03:52 -0700, Kevin Diggs wrote: Kevin Diggs wrote: Hi, I managed to wrestle my gigE to the ground and get it to boot 2.6.27. I have, however, noticed that some messages are showing up in dmesg. There are alot of them. They are continuous. They appear to come from drivers/usb/core/hub.c:2916. It looks like they come in pairs (this beast has two ports (root hubs)). I plugged in a USB CF reader. It appears to work. The keyboard and mouse (a Logitech wireless receiver) seems to work. 2.6.24 did not do this. kevin For what it is worth, I tricked a laptop into booting 2.6.27. It does not appear to generate these messages. The PowerMac is running Yellow Dog 4. It would be a lot more useful if you included informations in your report such as : - The actual error output - The full dmesg log - Informations about the adapter including output of lsusb -v - How do you actually trigger the problem It would be even more useful if you CC'ed some relevant list such as the linux-usb one too :-) Cheers, Ben. I cut a deal with my 8600 to get it to boot 2.6.27. It does not seem to work right either. The error message that shows up in dmesg is (the messages that show up for the gigE appear to be for two different busses (hubs?): hub 1-0:1.0: state 7 ports 2 chg evt hub 1-0:1.0: state 7 ports 2 chg evt hub 1-0:1.0: state 7 ports 2 chg evt hub 1-0:1.0: state 7 ports 2 chg evt lsusb does not work on this system: Unknown line at line 4969 . . . Unknown line at line 5004 lspci shows: 01:0d.0 USB Controller: Lucent Microelectronics USS-312 USB Controller (rev 10) The relevant lines from the dmesg (before they get overwritten are): ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd: block sizes: ed 64 td 64 ohci_hcd :01:0d.0: enabling device (0004 - 0006) ohci_hcd :01:0d.0: OHCI Host Controller drivers/usb/core/inode.c: creating file 'devices' drivers/usb/core/inode.c: creating file '001' ohci_hcd :01:0d.0: new USB bus registered, assigned bus number 1 ohci_hcd :01:0d.0: created debug files ohci_hcd :01:0d.0: irq 25, io mem 0x8080 ohci_hcd :01:0d.0: OHCI controller state ohci_hcd :01:0d.0: OHCI 1.0, NO legacy support registers ohci_hcd :01:0d.0: control 0x083 HCFS=operational CBSR=3 ohci_hcd :01:0d.0: cmdstatus 0x0 SOC=0 ohci_hcd :01:0d.0: intrstatus 0x0004 SF ohci_hcd :01:0d.0: intrenable 0x801a MIE UE RD WDH ohci_hcd :01:0d.0: hcca frame #001f ohci_hcd :01:0d.0: roothub.a 1202 POTPGT=16 NPS NDP=2(2) ohci_hcd :01:0d.0: roothub.b PPCM= DR= ohci_hcd :01:0d.0: roothub.status 8000 DRWE ohci_hcd :01:0d.0: roothub.portstatus [0] 0x0100 PPS ohci_hcd :01:0d.0: roothub.portstatus [1] 0x0100 PPS usb usb1: default language 0x0409 usb usb1: uevent usb usb1: usb_probe_device usb usb1: configuration #1 chosen from 1 choice usb usb1: adding 1-0:1.0 (config #1, interface 0) usb 1-0:1.0: uevent hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected hub 1-0:1.0: standalone hub hub 1-0:1.0: no power switching (usb 1.0) hub 1-0:1.0: global over-current protection hub 1-0:1.0: power on to power good time: 32ms hub 1-0:1.0: local power source is good hub 1-0:1.0: no over-current condition exists hub 1-0:1.0: trying to enable port power on non-switchable hub drivers/usb/core/inode.c: creating file '001' usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: OHCI Host Controller usb usb1: Manufacturer: Linux 2.6.27-pll-hrt ohci_hcd usb usb1: SerialNumber: :01:0d.0 hub 1-0:1.0: state 7 ports 2 chg evt usbcore: registered new interface driver libusual This is a PowerMac8600 with an OrangeLink USB Firewire card. The GigE starts spewing them immediately with no triggering event (though one should keep in mind that it uses a USB keyboard). The 8600 was fine until a gigaware USB 2 hub was plugged in (i.e. first thing plugged in). A CF reader seems to be working. The 8600 was running 2.6.26 before the upgrade to 2.6.27. I don't think it did this under 2.6.26. lsusb did work on the gigE. Thanks for the reply, Ben. kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: gigE 2.6.27 USB
Kevin Diggs wrote: Hi, I managed to wrestle my gigE to the ground and get it to boot 2.6.27. I have, however, noticed that some messages are showing up in dmesg. There are alot of them. They are continuous. They appear to come from drivers/usb/core/hub.c:2916. It looks like they come in pairs (this beast has two ports (root hubs)). I plugged in a USB CF reader. It appears to work. The keyboard and mouse (a Logitech wireless receiver) seems to work. 2.6.24 did not do this. kevin For what it is worth, I tricked a laptop into booting 2.6.27. It does not appear to generate these messages. The PowerMac is running Yellow Dog 4. kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
gigE 2.6.27 USB
Hi, I managed to wrestle my gigE to the ground and get it to boot 2.6.27. I have, however, noticed that some messages are showing up in dmesg. There are alot of them. They are continuous. They appear to come from drivers/usb/core/hub.c:2916. It looks like they come in pairs (this beast has two ports (root hubs)). I plugged in a USB CF reader. It appears to work. The keyboard and mouse (a Logitech wireless receiver) seems to work. 2.6.24 did not do this. kevin # # Automatically generated make config: don't edit # Linux kernel version: 2.6.27 # Sat Oct 11 21:51:09 2008 # # CONFIG_PPC64 is not set # # Processor support # CONFIG_6xx=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_PPC32=y CONFIG_WORD_SIZE=32 CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set # CONFIG_GROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y # CONFIG_HAVE_DMA_ATTRS is not set CONFIG_USE_GENERIC_SMP_HELPERS=y # CONFIG_HAVE_CLK is not set CONFIG_PROC_PAGE_MONITOR=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq CONFIG_CLASSIC_RCU=y # # Platform support # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y CONFIG_PPC_CHRP=y # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set # CONFIG_PQ2ADS is not set # CONFIG_PPC_83xx is not set # CONFIG_PPC_86xx is not set CONFIG_PPC_NATIVE=y # CONFIG_UDBG_RTAS_CONSOLE is not set # CONFIG_IPIC is not set CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set CONFIG_PPC_I8259=y CONFIG_PPC_RTAS=y # CONFIG_RTAS_ERROR_LOGGING is not set CONFIG_RTAS_PROC=y # CONFIG_MMIO_NVRAM is not set CONFIG_PPC_MPC106=y #
2.6.27 g5 config?
Hi, I always have trouble getting an initial build to boot. Usually it is with keyboards and video console. Currently, I can't seem to find the root disk. With the attached config I get the early messages, a pair of penguin images. And then I think it says system restarting. Happens kinda fast. If anyone is willing to look at the attached config I would appreciate it. kevin # # Automatically generated make config: don't edit # Linux kernel version: 2.6.27 # Sat Oct 11 12:11:01 2008 # CONFIG_PPC64=y # # Processor support # CONFIG_POWER4_ONLY=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y # CONFIG_VSX is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y # CONFIG_PPC_UDBG_16550 is not set CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_HIBERNATE_64=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_PPC_OF_PLATFORM_PCI is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set # CONFIG_GROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y # CONFIG_HAVE_CLK is not set CONFIG_PROC_PAGE_MONITOR=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory CONFIG_CLASSIC_RCU=y # # Platform support # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_PPC_PSERIES is not set # CONFIG_PPC_ISERIES is not set CONFIG_PPC_PMAC=y CONFIG_PPC_PMAC64=y # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_PASEMI is not set # CONFIG_PPC_PS3 is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE is not set # CONFIG_PPC_CELLEB is not set # CONFIG_PQ2ADS is not set CONFIG_PPC_NATIVE=y # CONFIG_IPIC is not set CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set # CONFIG_PPC_I8259 is not set CONFIG_U3_DART=y # CONFIG_PPC_RTAS is not set # CONFIG_MMIO_NVRAM is not set CONFIG_MPIC_U3_HT_IRQS=y # CONFIG_PPC_MPC106 is not set CONFIG_PPC_970_NAP=y # CONFIG_PPC_INDIRECT_IO is not set #
8600 serial support
Hi, I thought I might take a whack at fixing the 2.6 serial driver for my 8600. At the top of pmac_zilog.c (2.6.26) there is a todo for DMA. A quick glance at macserial.c (2.4.31) suggests it has dbdma support for receive. Anyone know of any pitfalls for adding dbdma support for pmac_zilog.c? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 8600 serial support
Benjamin Herrenschmidt wrote: On Wed, 2008-10-08 at 12:51 -0700, Kevin Diggs wrote: Hi, I thought I might take a whack at fixing the 2.6 serial driver for my 8600. At the top of pmac_zilog.c (2.6.26) there is a todo for DMA. A quick glance at macserial.c (2.4.31) suggests it has dbdma support for receive. Anyone know of any pitfalls for adding dbdma support for pmac_zilog.c? Yes, it's not totally trivial and I wouldn't recommend using the weirdo code in macserial (it does things that I don't understand how they work with the dbdma engine). The best way I see is to start from scratch with two different mechanisms: - For Tx, that's the easiest, the fire off DMA's for outgoing chars, maybe queue up a few descriptors to let data accumulate. - For Rx, one descriptor per byte. That sucks but I think that's also what Apple does. No need to have a huge Rx buffer anyway. That gives you precise Rx status to the byte. Ben. Does the 8530 (as implemented in the PowerMac ASICs) have a receive buffer like the 16550? Any pointers to some good dbdma example code? Anyone know where one might find some 8530 docs? This driver should work for ppp without receive dma, right? One descriptor per byte??? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 0/5] Add a cpufreq driver for the IBM PowerPC 750GX
Hi, This patch set adds a cpufreq driver for the IBM PowerPC 750GX processor. It should also work for the 750FX. The patches are: 1) Add low level PLL config register interface module 2) Add cpufreq driver for the 750GX 3) Other PowerPC kernel changes necessary to support the above 4) Add kernel doc for the completion feature, fix split-man.pl in kernel-doc-nano-HOWTO.txt 5) Add pll script to interface with pll_if sysfs attribute These changes are against 2.6.26. Thanks for all who took the time to review v1! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 0/5] Add a cpufreq driver for the IBM PowerPC 750GX
Hi, This patch set adds a cpufreq driver for the IBM PowerPC 750GX processor. It should also work for the 750FX. The patches are: 1) Add low level PLL config register interface module 2) Add cpufreq driver for the 750GX 3) Other PowerPC kernel changes necessary to support the above 4) Add kernel doc for the completion feature, fix split-man.pl in kernel-doc-nano-HOWTO.txt 5) Add pll script to interface with pll_if sysfs attribute These changes are against 2.6.26. Thanks for all who took the time to review v1! Documentation/DocBook/Makefile|2 Documentation/DocBook/cf750gx.tmpl| 441 Documentation/cpu-freq/pll.pl | 773 Documentation/kernel-doc-nano-HOWTO.txt |4 arch/powerpc/kernel/Makefile |1 arch/powerpc/kernel/cpu/Makefile |6 arch/powerpc/kernel/cpu/cpufreq/Kconfig | 33 + arch/powerpc/kernel/cpu/cpufreq/Makefile |1 arch/powerpc/kernel/cpu/cpufreq/cf750gx.c | 741 +++ arch/powerpc/kernel/cpu/pll_if.c | 807 ++ arch/powerpc/kernel/cpu_setup_6xx.S | 13 arch/powerpc/kernel/cputable.c| 32 + arch/powerpc/kernel/idle_6xx.S| 28 - arch/powerpc/platforms/Kconfig|2 arch/powerpc/platforms/Kconfig.cputype| 30 + arch/powerpc/platforms/powermac/feature.c |9 include/asm-powerpc/cputable.h|3 include/asm-powerpc/pll.h | 209 +++ include/asm-powerpc/pll_if.h | 117 include/linux/completion.h| 41 + kernel/sched.c| 56 ++ 21 files changed, 3305 insertions(+), 44 deletions(-) Ooops, left out the diffstat. kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 1/5] Add low level PLL config register interface module
This adds a small module to handle the low level details of dealing with the
PLL config register (HID1) found in the IBM 750GX. It provides 2 possible
interfaces, both selectable via kernel config options. One is a sysfs attribute
and the other is a normal function API. It is called pll_if.
The determination of the bus frequency is what worked on a PowerMac 8600. Any
suggestions on a more general solution are welcome.
After receiving comments, I added an argument for the data item to the
notifier register functions exported for the cpufreq API.
I also fixed a deadlock if the module is unloaded before _modify_PLL() is ever
called.
My name is Kevin Diggs and I approve this patch.
Signed-off-by: Kevin Diggs [EMAIL PROTECTED]
Index: arch/powerpc/kernel/cpu/pll_if.c
===
--- /dev/null 2004-08-10 18:55:00.0 -0700
+++ arch/powerpc/kernel/cpu/pll_if.c2008-08-29 13:42:35.0 -0700
@@ -0,0 +1,807 @@
+/*
+ * pll_if.c - low level interface to HID1 (PLL config) in the PowerPC 750GX
+ *
+ * Copyright (C) 2008 kevin Diggs
+ *
+ * ~~
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~
+ */
+#include linux/init.h
+#include linux/module.h
+#include linux/autoconf.h
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/cpu.h
+#include linux/of.h
+#include linux/notifier.h
+#include linux/delay.h
+#include linux/completion.h
+
+#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_SYSFS
+#include linux/sysdev.h
+#endif
+#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_HRTIMER
+#include linux/hrtimer.h
+#endif
+
+#include asm/time.h
+#include asm/mmu.h
+#include asm/processor.h
+#include asm/pgtable.h
+#include asm/cputable.h
+#include asm/system.h
+#include asm/pll_if.h
+#include asm/pll.h
+#include asm/smp.h
+
+MODULE_LICENSE(GPL);
+
+static DECLARE_COMPLETION(pllif_exit_completion);
+
+static unsigned int boot_ratio;
+
+static unsigned int busclock = 0;
+module_param(busclock, uint, 0);
+MODULE_PARM_DESC(busclock,
+ Bus clock frequency in KHz used to compute core clock frequency from
+bus ratios.);
+
+static unsigned int pllif_bus_clock;
+
+#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_HRTIMER
+static enum hrtimer_restart pllif_i_timer_f(struct hrtimer *hrt);
+static struct hrtimer pll_timer;
+static unsigned long hrtimers_got_no_freakin_callback_data;
+#ifdef DEBUG
+cycles_t pll_time_stamp;
+#endif
+#else
+static void pllif_i_timer_f(unsigned long newPLL);
+static struct timer_list pll_timer;
+cycles_t pll_time_stamp;
+#endif
+
+#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_SYSFS
+
+unsigned long boot_loops;
+static struct sys_device *sysdev_cpu;
+
+static ssize_t show_ppc750gxpll(struct sys_device *dev, char *buf)
+{
+ return sprintf(buf, %x\n, get_PLL());
+}
+
+static ssize_t __used store_ppc750gxpll(struct sys_device *dev,
+ const char *buf, size_t count)
+{
+ unsigned long pll_ul;
+ int ret;
+
+ pr_debug(__FILE__%s()-%d: buf=%s, count=%d\n, __func__, __LINE__,
+ buf, count);
+
+ ret = strict_strtoul(buf, 16, pll_ul);
+
+ pr_debug(__FILE__%s()-%d: strict_strtoul() returns %d\n, __func__,
+ __LINE__, ret);
+ pr_debug(__FILE__%s()-%d: %lx (%lu)\n, __func__, __LINE__, pll_ul,
+ pll_ul);
+
+ if (!ret) {
+ ret = count;
+
+ /* pllif_modify_PLL((unsigned int)pll_ul,!0); */
+ pllif_modify_PLL((unsigned int)pll_ul, 0);
+ }
+
+ return ret;
+}
+
+static SYSDEV_ATTR(ppc750gxpll, 0600, show_ppc750gxpll, store_ppc750gxpll);
+#endif
+
+#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_CPU_FREQ
+struct pllif_call_data_t {
+ void *data;
+ int scalar;
+};
+
+static struct pllif_call_data_t pllif_switch_call_data;
+static struct pllif_call_data_t pllif_lock_call_data;
+static RAW_NOTIFIER_HEAD(pllif_pll_switch_chain);
+static RAW_NOTIFIER_HEAD(pllif_pll_lock_chain);
+#endif
+
+/*
+ * This initializes the code for the PLL control:
+ * boot_ratio is used to scale the loops_per_jiffy value from its boot value
+ * boot_loops is the boot value of loops_per_jiffy and is used to compute new
+ * values
[PATCH v2 2/5] Add cpufreq driver for the IBM PowerPC 750GX
This adds the actual cpufreq driver for the 750GX. It supports all integer ratios that are valid for the processor model and bus frequency. It is called cf750gx. It has two modes of operation. Normal mode uses all valid frequencies. In minmaxmode, only the minimum and maximum are used. This provides the ability for very low latency frequency switches. There is also a sysfs attribute to have it switch off the unused PLL for additional power savings. This does NOT support SMP. I fixed a deadlock if the module is unloaded before _target() is ever called. My name is Kevin Diggs and I approve this patch. Signed-off-by: Kevin Diggs [EMAIL PROTECTED] Index: Documentation/DocBook/cf750gx.tmpl === --- /dev/null 2004-08-10 18:55:00.0 -0700 +++ Documentation/DocBook/cf750gx.tmpl 2008-08-27 13:59:45.0 -0700 @@ -0,0 +1,441 @@ +?xml version=1.0 encoding=UTF-8? +!DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN + http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd; [] + +book id=ppc750gx-cpufreq-guide + bookinfo + titlePowerPC 750GX (and FX?) cpufreq driver guide/title + + authorgroup + author +firstnameKevin/firstname +surnameDiggs/surname + /author + /authorgroup + +revhistory + revision + revnumber1.0nbsp;/revnumber + dateAugust 12, 2008/date + revremarkInitial revision posted to linuxppc-dev/revremark + /revision +/revhistory + + copyright + year2008/year + holderKevin Diggs/holder + /copyright + + legalnotice + para +This documentation 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. + /para + + para +This program is distributed in the hope that it will be +useful, but WITHOUT ANY WARRANTY; without even the implied +warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +See the GNU General Public License for more details. + /para + + para +You should have received a copy of the GNU General Public +License along with this program; if not, write to the Free +Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, +MA 02111-1307 USA + /para + + para +For more details see the file COPYING in the source +distribution of Linux. + /para + /legalnotice + + releaseinfo + This is the first release of this document coincident with submission of the + driver for inclusion in the kernel. + /releaseinfo + + /bookinfo + + toc/toc + + chapter id=introduction + titleIntroduction/title + para + This guide documents the cpufreq driver for the IBM PowerPC 750GX processor. + It should also work with the 750FX but has not been tested. + /para + para + The driver is split into two main parts. The first provides the low level + interface to the PLL configuration register (HID1 - SPR 1009). It is called + pll_if. The second is the actual cpufreq driver, called cf750gx. The pll_if + component handles the details of dealing with the PLL like PLL lock delay + requirements and preventing illegal operations. The cf750gx driver provides + the interface to the cpufreq subsystem. Under control of the specified + governor it will generate the required commands to switch the processor + frequency as requested and send them to pll_if to carry them out. + /para + /chapter + + chapter id=MajorComponents + titleMajor Components/title + + para + The IBM 750GX (and FX) processor has a pair of PLLs that can be programmed to + operate at a number of different frequencies. The frequencies are specified + as ratios to the system bus and range from 2 to 20. From 2 to 10 it also + supports half ratios (i.e. 2.5, 3.5) though they are not supported in the + cpufreq driver due to a limitation of not being able to switch from one half + ratio directly to another. It takes 100 usec for a PLL to relock to a + new frequency before it can be used [750GX_ds2-17-05.pdf, Table 3-7, + page 18]. It takes 3 bus clocks for the cpu to switch from one PLL to + another [750GX_ds2-17-05.pdf, paragraph 3, page 44]. + /para + + para + The cpufreq driver consists of two main parts: + /para + + itemizedlist + listitem +para + cf750gx - the cpufreq driver module +/para + /listitem + + listitem +para + pll_if - a low level interface that encapsulates the details of dealing + with the PLL register +/para + /listitem + /itemizedlist + + sect1 id=cf750gx + titlecf750gx - The CPUFreq 750GX driver/title + + para +cf750gx provides the standard entry points required of a cpufreq driver. They +are: + + itemizedlist +listitem + para + cf750gx_verify - verify + /para +/listitem + +listitem + para + cf750gx_target
[PATCH v2 3/5] Various arch/powerpc changes to support the 750GX cpufreq driver
This patch includes various changes necessary to support the cpufreq driver for
the PowerPC 750GX. Highlights include adding entries to recognize the 750GX to
the cputable (This includes the ... unfortunate pvr that the 750GX used in the
PowerLogix PowerForce 750GX = 0x0008 0203). The PLL switch in idle_6xx.S
during sleep (or nap) was also removed (I tried to add ability to disable this
but the result would not boot?).
My name is Kevin Diggs and I approve this patch.
Signed-off-by: Kevin Diggs [EMAIL PROTECTED]
Index: arch/powerpc/kernel/Makefile
===
--- arch/powerpc/kernel/Makefile.orig 2008-08-13 02:19:18.0 -0700
+++ arch/powerpc/kernel/Makefile2008-08-14 02:50:18.0 -0700
@@ -17,6 +17,7 @@ obj-y := cputable.o ptrace.o syscalls
init_task.o process.o systbl.o idle.o \
signal.o
obj-y += vdso32/
+obj-y += cpu/
obj-$(CONFIG_PPC64)+= setup_64.o sys_ppc32.o \
signal_64.o ptrace32.o \
paca.o cpu_setup_ppc970.o \
Index: arch/powerpc/kernel/cputable.c
===
--- arch/powerpc/kernel/cputable.c.orig 2008-08-13 02:19:19.0 -0700
+++ arch/powerpc/kernel/cputable.c 2008-08-14 03:00:51.0 -0700
@@ -42,9 +42,11 @@ extern void __setup_cpu_604(unsigned lon
extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_750cx(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_750fx(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_750gx(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_7400(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_7410(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_745x(unsigned long offset, struct cpu_spec* spec);
+
#endif /* CONFIG_PPC32 */
#ifdef CONFIG_PPC64
extern void __setup_cpu_ppc970(unsigned long offset, struct cpu_spec* spec);
@@ -660,7 +662,7 @@ static struct cpu_spec __initdata cpu_sp
.machine_check = machine_check_generic,
.platform = ppc750,
},
- { /* 750GX */
+ { /* 750GX rev 1.x */
.pvr_mask = 0x,
.pvr_value = 0x7002,
.cpu_name = 750GX,
@@ -669,7 +671,33 @@ static struct cpu_spec __initdata cpu_sp
.icache_bsize = 32,
.dcache_bsize = 32,
.num_pmcs = 4,
- .cpu_setup = __setup_cpu_750fx,
+ .cpu_setup = __setup_cpu_750gx,
+ .machine_check = machine_check_generic,
+ .platform = ppc750,
+ },
+ { /* 750GX (rev 2.3, as used on PowerLogix 750GX upgrade card */
+ .pvr_mask = 0x,
+ .pvr_value = 0x00080203,
+ .cpu_name = 750GX,
+ .cpu_features = CPU_FTRS_750GX,
+ .cpu_user_features = COMMON_USER | PPC_FEATURE_PPC_LE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .num_pmcs = 4,
+ .cpu_setup = __setup_cpu_750gx,
+ .machine_check = machine_check_generic,
+ .platform = ppc750,
+ },
+ { /* 750GX (All revs = 2.0) */
+ .pvr_mask = 0xff00,
+ .pvr_value = 0x70020200,
+ .cpu_name = 750GX,
+ .cpu_features = CPU_FTRS_750GX,
+ .cpu_user_features = COMMON_USER | PPC_FEATURE_PPC_LE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .num_pmcs = 4,
+ .cpu_setup = __setup_cpu_750gx,
.machine_check = machine_check_generic,
.platform = ppc750,
},
Index: arch/powerpc/kernel/cpu_setup_6xx.S
===
--- arch/powerpc/kernel/cpu_setup_6xx.S.orig2008-08-13 02:19:19.0
-0700
+++ arch/powerpc/kernel/cpu_setup_6xx.S 2008-08-14 02:44:30.0 -0700
@@ -53,6 +53,14 @@ _GLOBAL(__setup_cpu_750fx)
bl setup_750fx
mtlrr4
blr
+_GLOBAL(__setup_cpu_750gx)
+ mflrr4
+ bl __init_fpu_registers
+ bl setup_common_caches
+ bl setup_750_7400_hid0
+ bl setup_750gx
[PATCH v2 4/5] Add kernel doc for the completion, fix kernel-doc-nano-HOWTO.txt
This patch adds kernel doc for the completion feature. It is in kernel/sched.c
and include/linux/completion.h.
An error in the split-man.pl PERL snippet in kernel-doc-nano-HOWTO.txt is
also fixed.
My name is Kevin Diggs and I approve this patch.
Signed-off-by: Kevin Diggs [EMAIL PROTECTED]
Index: Documentation/kernel-doc-nano-HOWTO.txt
===
--- Documentation/kernel-doc-nano-HOWTO.txt.orig2008-08-13
02:18:53.0 -0700
+++ Documentation/kernel-doc-nano-HOWTO.txt 2008-08-19 14:21:43.0
-0700
@@ -168,10 +168,10 @@ if ($#ARGV 0) {
mkdir $ARGV[0],0777;
$state = 0;
while (STDIN) {
-if (/^\.TH \[^\]*\ 4 \([^\]*)\/) {
+if (/^\.TH \[^\]*\ 9 \([^\]*)\/) {
if ($state == 1) { close OUT }
$state = 1;
- $fn = $ARGV[0]/$1.4;
+ $fn = $ARGV[0]/$1.9;
print STDERR Creating $fn\n;
open OUT, $fn or die can't open $fn: $!\n;
print OUT $_;
Index: include/linux/completion.h
===
--- include/linux/completion.h.orig 2008-08-13 00:56:52.0 -0700
+++ include/linux/completion.h 2008-08-20 01:47:21.0 -0700
@@ -10,6 +10,18 @@
#include linux/wait.h
+/**
+ * struct completion - structure used to maintain state for a completion
+ *
+ * This is the opaque structure used to maintain the state for a completion.
+ * Completions currently use a FIFO to queue threads that have to wait for
+ * the completion event.
+ *
+ * See also: complete(), wait_for_completion() (and friends _timeout,
+ * _interruptible, _interruptible_timeout, and _killable), init_completion(),
+ * and macros DECLARE_COMPLETION(), DECLARE_COMPLETION_ONSTACK(), and
+ * INIT_COMPLETION().
+ */
struct completion {
unsigned int done;
wait_queue_head_t wait;
@@ -21,6 +33,14 @@ struct completion {
#define COMPLETION_INITIALIZER_ONSTACK(work) \
({ init_completion(work); work; })
+/**
+ * DECLARE_COMPLETION: - declare and initialize a completion structure
+ * @work: identifier for the completion structure
+ *
+ * This macro declares and initializes a completion structure. Generally used
+ * for static declarations. You should use the _ONSTACK variant for automatic
+ * variables.
+ */
#define DECLARE_COMPLETION(work) \
struct completion work = COMPLETION_INITIALIZER(work)
@@ -29,6 +49,13 @@ struct completion {
* completions - so we use the _ONSTACK() variant for those that
* are on the kernel stack:
*/
+/**
+ * DECLARE_COMPLETION_ONSTACK: - declare and initialize a completion structure
+ * @work: identifier for the completion structure
+ *
+ * This macro declares and initializes a completion structure on the kernel
+ * stack.
+ */
#ifdef CONFIG_LOCKDEP
# define DECLARE_COMPLETION_ONSTACK(work) \
struct completion work = COMPLETION_INITIALIZER_ONSTACK(work)
@@ -36,6 +63,13 @@ struct completion {
# define DECLARE_COMPLETION_ONSTACK(work) DECLARE_COMPLETION(work)
#endif
+/**
+ * init_completion: - Initialize a dynamically allocated completion
+ * @x: completion structure that is to be initialized
+ *
+ * This inline function will initialize a dynamically created completion
+ * structure.
+ */
static inline void init_completion(struct completion *x)
{
x-done = 0;
@@ -53,6 +87,13 @@ extern unsigned long wait_for_completion
extern void complete(struct completion *);
extern void complete_all(struct completion *);
+/**
+ * INIT_COMPLETION: - reinitialize a completion structure
+ * @x: completion structure to be reinitialized
+ *
+ * This macro should be used to reinitialize a completion structure so it can
+ * be reused. This is especially important after complete_all() is used.
+ */
#define INIT_COMPLETION(x) ((x).done = 0)
#endif
Index: kernel/sched.c
===
--- kernel/sched.c.orig 2008-08-13 02:22:42.0 -0700
+++ kernel/sched.c 2008-08-20 12:36:01.0 -0700
@@ -4363,6 +4363,15 @@ __wake_up_sync(wait_queue_head_t *q, uns
}
EXPORT_SYMBOL_GPL(__wake_up_sync); /* For internal use only */
+/**
+ * complete: - signals a single thread waiting on this completion
+ * @x: holds the state of this particular completion
+ *
+ * This will wake up a single thread waiting on this completion. Threads will
be
+ * awakened in the same order in which they were queued.
+ *
+ * See also complete_all(), wait_for_completion() and related routines.
+ */
void complete(struct completion *x)
{
unsigned long flags;
@@ -4374,6 +4383,12 @@ void complete(struct completion *x)
}
EXPORT_SYMBOL(complete);
+/**
+ * complete_all: - signals all threads waiting on this completion
+ * @x: holds the state of this particular completion
+ *
+ * This will wake up all threads waiting on this particular completion event.
+ */
void complete_all(struct completion *x)
{
unsigned long flags;
@@ -4425,12
[PATCH v2 5/5] Add PERL script to conrol the PLL via the sysfs attribute
This patch adds a PERL script that can be used to manipulate the sysfs
attribute provided by pll_if. It can query the current state, change the
state of the inactive PLL, and switch PLLs (assumming that the inactive PLL is
locked to a valid frequency).
My name is Kevin Diggs and I approve this patch.
Signed-off-by: Kevin Diggs [EMAIL PROTECTED]
Index: Documentation/cpu-freq/pll.pl
===
--- /dev/null 2004-08-10 18:55:00.0 -0700
+++ Documentation/cpu-freq/pll.pl 2008-08-29 13:34:36.0 -0700
@@ -0,0 +1,773 @@
+#!/usr/bin/perl -w
+
+=head1 NAME
+
+pll.pl - Provide user friendly interface to sysfs attribute for the 750GX PLL.
+This uses the pll_if module.
+
+=head1 SYSNOPSIS
+
+ pll.pl [ -bdhtv ] [ -f { clk | ratio }]
+ b:print bus frequency
+ d:dump current pll configuration
+ h:print simple usage information
+ f:set frequency to specified clk (MHz) or ratio (r suffix)
+ t:toggle selected pll. Use with -f to cause a switch to the newly
+ modified PLL on lock.
+ v:enable verbose
+
+=head1 DESCRIPTION
+
+This utility provides a user friendly interface to the sysfs attribute that is
+provided by the pll_if module to control the PLL configuration register (HID1)
+in the IBM PowerPC 750FX and 750GX processors.
+
+=over 4
+
+=item -b
+
+print the bus frequency which is used along with the ratios to compute the
+processor clock frequency.
+
+=pod
+
+The method used to get the bus frequency is to use the value of the
+clock-frequency property from the root of the OF tree.
+
+=item -d
+
+prints the current value of the PLL configuration register in a human readable
+form (well ... more or less).
+
+=item -h
+
+print a simple help message.
+
+=item -t
+
+Toggles the selected PLL that is driving the cpu clock. When used with -f
causes
+a switch to the new PLL upon lock (when the lock timeout expires).
+
+=item -v
+
+Enable verbose mode. Mostly just prints the file paths that stuff is pulled
+from.
+
+=item -f
+
+Sets the INACTIVE PLL to the selected clock frequency in MHz. If the value has
+an r suffix, it is taken as a ratio. This also recognizes the special value
+off (-foff) to turn off the INACTIVE PLL.
+
+=back
+
+=head1 AUTHOR
+
+kevin diggs
+
+=cut
+
+use warnings;
+use Getopt::Std;
+
+#
+# The layout of the PLL register (HID1) is:
+#
+# 0 4|5 6|7|8| 9 11|12 13|14| 15 |16 20|21 22|23|24 28|29 30| 31
+# PCE |PRE|v|v| Res | Res |v | PS | PC0 | PR0 |v | PC1 | PR1 |Res
+#| | | |
+# PSTAT1 -| | | |
+#ECLK -| | |
+#PI0 | |
+# Res |
+#
+# PCE PLL0 read-only external config
+# PRE PLL0 read-only external range
+# PSTAT1 PLL status (0 - PLL0, 1 - PLL1)
+# ECLK1 - enable clkout pin
+# PI0 PLL0 control: 0 - external
+# PS PLL select: 0 - PLL0, 1 - PLL1
+# PC0 PLL0 configuration
+# PR0 PLL0 range
+# PC1 PLL1 configuration
+# PR1 PLL1 range
+#
+# PLL_CFG bus ratio PLL_CFG bus ratio
+# 0 off 1 8
+# 1 off 10001 8.5
+# 00010 bypass 10010 9
+# 00011 bypass 10011 9.5
+# 00100 210100 10
+# 00101 2.5 10101 11
+# 00110 310110 12
+# 00111 3.5 10111 13
+# 01000 411000 14
+# 01001 4.5 11001 15
+# 01010 511010 16
+# 01011 5.5 11011 17
+# 01100 611100 18
+# 01101 6.5 11101 19
+# 01110 70 20
+# 0 7.5 1 off
+#
+# PLL_RNG range
+#00600 - 900
+#01900 - 1000
+#10500 - 600
+#
+# IBM bit numbering:
+# 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
+# 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6
+#
+# 26 27 28 29 30 31
+# 5 4 3 2 1 0
+#
+*pllcBusFreqFile=\/proc/device-tree/clock-frequency;
+#*pllcCPUPVR=\/proc/device-tree/PowerPC,*/cpu-version;
+*pllcSysFS=\/sys/devices/system/cpu/cpu0/*pll;
+
+#
+# Update the value of the PLL configuration register based on the crap passed
+# in. The upper 8 bits (0 - 7) are read only and will be used as flags to con-
+# trol what we
Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
Arnd Bergmann wrote: On Wednesday 27 August 2008, Kevin Diggs wrote: Arnd Bergmann wrote: I think the module_exit() function should leave the frequency in a well-defined state, so the easiest way to get there is probably to delete the timer, and then manually set the frequency. I really don't follow you here? If I let the timer fire then the cpu (and the cpufreq sub-system) will be left in a well-defined state. I don't understand why you want me to delete the timer and then basically do manually what it was going to do anyway. There are two calls to cpufreq_notify_transition(). One just before the modify_PLL() call, with CPUFREQ_PRECHANGE as an argument, and one in the pll_switch_cb() routine, with CPUFREQ_POSTCHANGE as an argument. I would need to make sure that these are matched up. Even without the HRTimer stuff being used the timer fires in less than 4 ms (@ 250 HZ). So I can't see the user actually trying to interrupt a frequency change. With HRTimers it is 100 us. Can we please, please leave this part as is? I'm still not convinced that it's actually correct if you call complete() from the other places as well. You have three locations in your code where you call complete() but only one for INIT_COMPLETION. The part that I don't understand (and therefore don't expect other readers to understand) is how the driver guarantees that only one complete() will be called on the completion variable after it has been initialized. What I meant with the well-defined state is that after unloading the module, the CPU frequency should be the same as before loading the module, typically the maximum frequency, but not the one that was set last. As you point out, there are three calls to complete(). The first is in the switch callback, in the idle_pll_off disabled branch. This callback is triggered from the pll switch routine in pll_if. So that means the call to _modify_PLL() in _target worked. So the complete() call in _target will NOT be called. The complete() call in the lock callback is only called in the idle_pll_off enabled branch. As just mentioned, the second complete() call in the lock callback is only called when idle_pll_off is enabled. The final complete() call is in the unlock exit path in _target(). This is an error path, where for one reason or another, there was no successful call to _modify_PLL(). Thus there will be triggering of either callback. There is another initialization of the completion: the DECLARE_COMPLETION(). I think I will deadlock if I get unloaded before _target() is ever called. This can happen. I may add a test_bit(...changing_pll_bit) condition on the wait_for_completion() call. Arnd Thanks for taking the time to review and for the comments! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
Arnd Bergmann wrote:
On Tuesday 26 August 2008, Kevin Diggs wrote:
Arnd Bergmann wrote:
On Monday 25 August 2008, Kevin Diggs wrote:
Most people list their email address here as well
For reasons I'd rather not go into, my email address is not likely
to remain valid for much longer.
Maybe you should get a freemail account somewhere then.
It's better if people have a way to Cc the author of
a file when they make changes to it.
That won't really help either.
drop the _t here, or make explicit what is meant by it.
Now that I look at it the _t is supposed to be at the end. It is
meant to indicate that this is a structure tag or type. I'll
remove it.
Ok, thanks for the explanation. I now saw that you also
use '_v' for variables (I guess). These should probably
go the same way.
Actually the _v means global variable. I would prefer to keep it.
+static DECLARE_COMPLETION(cf750gx_v_exit_completion);
+
+static unsigned int override_min_core = 0;
+static unsigned int override_max_core = 0;
+static unsigned int minmaxmode = 0;
+
+static unsigned int cf750gx_v_min_core = 0;
+static unsigned int cf750gx_v_max_core = 0;
+static int cf750gx_v_idle_pll_off = 0;
+static int cf750gx_v_min_max_mode = 0;
+static unsigned long cf750gx_v_state_bits = 0;
Is 0 a meaningful value for these? If it just means 'uninitialized',
then better don't initialize them in the first place, for clarity.
The first 3 are module parameters. For the first 2, 0 means
that they were not set. minmaxmode is a boolean. 0 is the
default of disabled.
Then at least for the first two, the common coding style would
be to leave out the '= 0'. For minmaxmode, the most expressive
way would be to define an enum, like
enum {
MODE_NORMAL,
MODE_MINMAX,
};
int minmaxmode = MODE_NORMAL;
Since this is a boolean parameter I don't know? What if I change the
name to enable_minmax. And actually use the bool module parameter
type?
..._min_max_mode is a boolean to hold the state of
minmaxmode. Seems to be only used to print the current
value.
this looks like a duplicate then. why would you need both?
It seems really confusing to have both a cpufreq attribute
and a module attribute with the same name, writing to
different variables.
I probably don't need both? I kinda treat the variables tied to module
parameters as read only.
Are there even SMP boards based on a 750? I thought only 74xx
and 603/604 were SMP capable.
Not that I have heard of. I thought it was lacking some hardware that
was needed to do SMP? Can the 603 do SMP?
+static int cf750gx_pll_switch_cb(struct notifier_block *nb, unsigned long
+ action, void *data)
+{
+struct cf750gx_t_call_data *cd;
+unsigned int idle_pll;
+unsigned int pll_off_cmd;
+unsigned int new_pll;
The whitespace appears damaged here.
Just a coding style thing. I put declarations (or definitions -
I get the two confused?) on the same indent as the block they are
in. Is this a 15 yard illegal procedure penalty?
I've never seen that style before. Better do what everyone
else does here, e.g. using 'indent -kr -i8'.
Ok, I'll fix this.
+ dprintk(__FILE__%s()-%d: Modifying PLL: 0x%x\n, __func__, __LINE__,
+ new_pll);
Please go through all your dprintk and see if you really really need all of
them.
Usually they are useful while you are doing the initial code, but only get in
the
way as soon as it starts working.
This from a code readability standpoint? Or an efficiency one?
I think the cpufreq stuff has a debug configure option that
disables compilation of these unless enabled.
It's more about readability.
I removed a few. Let me know if I should whack some more (and which ones).
+ result = pllif_register_pll_switch_cb(cf750gx_v_pll_switch_nb);
+
+ cf750gx_v_pll_lock_nb.notifier_call = cf750gx_pll_lock_cb;
+ cf750gx_v_pll_lock_nb.next =
+ (struct notifier_block *)cf750gx_v_lock_call_data;
These casts look wrong, cf750gx_v_lock_call_data is not a notifier_block.
What are you trying to do here?
Just a little sneaky. I should document in the kernel doc though.
No, better avoid such hacks instead of documenting them. I think I
now understand what you do there, and if I got it right, you should
just pass two arguments to pllif_register_pll_switch_cb.
I'll fix this.
+static int cf750gx_cpu_exit(struct cpufreq_policy *policy)
+{
+ dprintk(%s()\n, __func__);
+
+ /*
+* Wait for any active requests to ripple through before exiting
+*/
+ wait_for_completion(cf750gx_v_exit_completion);
This wait for anything use of wait_for_completion looks wrong,
because once any other function has done the 'complete', you won't
wait here any more.
What exactly are you trying to accomplish with this?
Originall I had something like:
while(some_bit_is_still_set)
sleep
I think you suggested I use a completion because it is in
fact
Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
Arnd Bergmann wrote:
On Wednesday 27 August 2008, Kevin Diggs wrote:
Arnd Bergmann wrote:
Ok, thanks for the explanation. I now saw that you also
use '_v' for variables (I guess). These should probably
go the same way.
Actually the _v means global variable. I would prefer to keep it.
The reasoning on Linux is that you can tell from the declaration
whether something is global or automatic. In fact, functions should
be so short that you can always see all automatic declarations
when you look at some code.
If you use nonstandard variable naming, people will never stop
asking you about that, so it's easier to just to the same as
everyone else.
I will remove the _v.
Then at least for the first two, the common coding style would
be to leave out the '= 0'. For minmaxmode, the most expressive
way would be to define an enum, like
enum {
MODE_NORMAL,
MODE_MINMAX,
};
int minmaxmode = MODE_NORMAL;
Since this is a boolean parameter I don't know? What if I change the
name to enable_minmax. And actually use the bool module parameter
type?
Module parameter names should be short, so just minmax would
be a good name, but better put the module_param() line right
after that. If it's a bool type, I would just leave out the
initialization.
Ok. But leaving out the initialization will make me itch. Should I
also replace override_min_core with mincore (or min_core)? And
override_max_core with maxcore (or max_core)?
Leaving out the initializations makes me ... uneasy. It's ok to leave
them out if they are 0?
..._min_max_mode is a boolean to hold the state of
minmaxmode. Seems to be only used to print the current
value.
this looks like a duplicate then. why would you need both?
It seems really confusing to have both a cpufreq attribute
and a module attribute with the same name, writing to
different variables.
I probably don't need both? I kinda treat the variables tied to module
parameters as read only.
But you have marked as read/write in the module_param line.
I would prefer to just have the module parameter and have
a tool to modify that one.
If a module parameter only makes sense as read-only, you
should mark it as 0444 instead of 0644, but this one looks
like it can be writable.
I meant I treat them as read only from the code. That is why I have a
separate variable to change from the sysfs routines. I'll eliminate it
if you like. I have removed the auto added sysfs attributes.
The completion would certainly be better than the sleep here, but
I think you shouldn't need that in the first place. AFAICT, you
have three different kinds of events that you need to protect
against, when some other code can call into your module:
1. timer function,
2. cpufreq notifier, and
3. sysfs attribute.
In each case, the problem is a race between two threads that you
need to close. In case of the timer, you need to call del_timer_sync
because the timers already have this method builtin. For the other
two, you already unregister the interfaces, which ought to be enough.
The choice I made here was to wait for the timer to fire rather than
to delete it. I think it is easier to just wait for it than to delete
it and try to get things back in order. Though since this is in a
module exit routine it probably does not matter. Also I would have to
check whether there was an analogous HRTimer call and call the right
one.
I think the module_exit() function should leave the frequency in a
well-defined state, so the easiest way to get there is probably
to delete the timer, and then manually set the frequency.
I really don't follow you here? If I let the timer fire then the cpu
(and the cpufreq sub-system) will be left in a well-defined state. I
don't understand why you want me to delete the timer and then
basically do manually what it was going to do anyway. There are two
calls to cpufreq_notify_transition(). One just before the modify_PLL()
call, with CPUFREQ_PRECHANGE as an argument, and one in the
pll_switch_cb() routine, with CPUFREQ_POSTCHANGE as an argument. I
would need to make sure that these are matched up.
Even without the HRTimer stuff being used the timer fires in less than
4 ms (@ 250 HZ). So I can't see the user actually trying to interrupt
a frequency change. With HRTimers it is 100 us.
Can we please, please leave this part as is?
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
Arnd Bergmann wrote:
On Wednesday 27 August 2008, Kevin Diggs wrote:
Arnd Bergmann wrote:
Ok, thanks for the explanation. I now saw that you also
use '_v' for variables (I guess). These should probably
go the same way.
Actually the _v means global variable. I would prefer to keep it.
The reasoning on Linux is that you can tell from the declaration
whether something is global or automatic. In fact, functions should
be so short that you can always see all automatic declarations
when you look at some code.
If you use nonstandard variable naming, people will never stop
asking you about that, so it's easier to just to the same as
everyone else.
Then at least for the first two, the common coding style would
be to leave out the '= 0'. For minmaxmode, the most expressive
way would be to define an enum, like
enum {
MODE_NORMAL,
MODE_MINMAX,
};
int minmaxmode = MODE_NORMAL;
Since this is a boolean parameter I don't know? What if I change the
name to enable_minmax. And actually use the bool module parameter
type?
Module parameter names should be short, so just minmax would
be a good name, but better put the module_param() line right
after that. If it's a bool type, I would just leave out the
initialization.
..._min_max_mode is a boolean to hold the state of
minmaxmode. Seems to be only used to print the current
value.
this looks like a duplicate then. why would you need both?
It seems really confusing to have both a cpufreq attribute
and a module attribute with the same name, writing to
different variables.
I probably don't need both? I kinda treat the variables tied to module
parameters as read only.
But you have marked as read/write in the module_param line.
I would prefer to just have the module parameter and have
a tool to modify that one.
If a module parameter only makes sense as read-only, you
should mark it as 0444 instead of 0644, but this one looks
like it can be writable.
Are there even SMP boards based on a 750? I thought only 74xx
and 603/604 were SMP capable.
Not that I have heard of. I thought it was lacking some hardware that
was needed to do SMP? Can the 603 do SMP?
No, I was wrong about the 603. The machine I was thinking of is actually
604e.
The completion would certainly be better than the sleep here, but
I think you shouldn't need that in the first place. AFAICT, you
have three different kinds of events that you need to protect
against, when some other code can call into your module:
1. timer function,
2. cpufreq notifier, and
3. sysfs attribute.
In each case, the problem is a race between two threads that you
need to close. In case of the timer, you need to call del_timer_sync
because the timers already have this method builtin. For the other
two, you already unregister the interfaces, which ought to be enough.
The choice I made here was to wait for the timer to fire rather than
to delete it. I think it is easier to just wait for it than to delete
it and try to get things back in order. Though since this is in a
module exit routine it probably does not matter. Also I would have to
check whether there was an analogous HRTimer call and call the right
one.
I think the module_exit() function should leave the frequency in a
well-defined state, so the easiest way to get there is probably
to delete the timer, and then manually set the frequency.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/4] A a cpufreq driver for the IBM PowerPC 750GX
This patch set adds a cpufreq driver for the IBM PowerPC 750GX processor. It should also work for the 750FX. The patches are: 1) Add low level PLL config register interface module 2) Add cpufreq driver for the 750GX 3) Other PowerPC kernel changes necessary to support the above 4) Add kernel doc for the completion feature, fix split-man.pl in kernel-doc-nano-HOWTO.txt These changes are against 2.6.26. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] Add low level PLL config register interface module
This adds a small module to handle the low level details of dealing with the
PLL config register (HID1) found in the IBM 750GX. It provides 2 possible
interfaces, both selectable via kernel config options. One is a sysfs attribute
and the other is a normal function API. It is called pll_if.
The determination of the bus frequency is what worked on a PowerMac 8600. Any
suggestions on a more general solution are welcome.
WARNING - I used some #ifdefs - Let the fur fly!
My name is Kevin Diggs and I approve this patch.
Signed-off-by: Kevin Diggs [EMAIL PROTECTED]
Index: Documentation/cpu-freq/pll.pl
===
--- /dev/null 2004-08-10 18:55:00.0 -0700
+++ Documentation/cpu-freq/pll.pl 2008-08-15 13:42:09.0 -0700
@@ -0,0 +1,762 @@
+#!/usr/bin/perl -w
+
+=head1 NAME
+
+pll.pl - Provide user friendly interface to sysfs attribute for the 750GX PLL.
+This uses the pll_if module.
+
+=head1 SYSNOPSIS
+
+ pll.pl [ -bdhtv ] [ -f { clk | ratio }]
+ b:print bus frequency
+ d:dump current pll configuration
+ h:print simple usage information
+ f:set frequency to specified clk (MHz) or ratio (r suffix)
+ t:toggle selected pll. Use with -f to cause a switch to the newly
+ modified PLL on lock.
+ v:enable verbose
+
+=head1 DESCRIPTION
+
+This utility provides a user friendly interface to the sysfs attribute that is
+provided by the pll_if module to control the PLL configuration register (HID1)
+in the IBM PowerPC 750FX and 750GX processors.
+
+=over 4
+
+=item -b
+
+print the bus frequency which is used along with the ratios to compute the
+processor clock frequency.
+
+=pod
+
+The method used to get the bus frequency is to use the value of the
+clock-frequency property from the root of the OF tree.
+
+=item -d
+
+prints the current value of the PLL configuration register in a human readable
+form (well ... more or less).
+
+=item -h
+
+print a simple help message.
+
+=item -t
+
+Toggles the selected PLL that is driving the cpu clock. When used with -f
causes
+a switch to the new PLL upon lock (when the lock timeout expires).
+
+=item -v
+
+Enable verbose mode. Mostly just prints the file paths that stuff is pulled
+from.
+
+=item -f
+
+Sets the INACTIVE PLL to the selected clock frequency in MHz. If the value has
+an r suffix, it is taken as a ratio. This also recognizes the special value
+off (-foff) to turn off the INACTIVE PLL.
+
+=back
+
+=head1 AUTHOR
+
+kevin diggs
+
+=cut
+
+use warnings;
+use Getopt::Std;
+
+#
+# The layout of the PLL register (HID1) is:
+#
+# 0 4|5 6|7|8| 9 11|12 13|14| 15 |16 20|21 22|23|24 28|29 30| 31
+# PCE |PRE|v|v| Res | Res |v | PS | PC0 | PR0 |v | PC1 | PR1 |Res
+#| | | |
+# PSTAT1 -| | | |
+#ECLK -| | |
+#PI0 | |
+# Res |
+#
+# PCE PLL0 read-only external config
+# PRE PLL0 read-only external range
+# PSTAT1 PLL status (0 - PLL0, 1 - PLL1)
+# ECLK1 - enable clkout pin
+# PI0 PLL0 control: 0 - external
+# PS PLL select: 0 - PLL0, 1 - PLL1
+# PC0 PLL0 configuration
+# PR0 PLL0 range
+# PC1 PLL1 configuration
+# PR1 PLL1 range
+#
+# PLL_CFG bus ratio PLL_CFG bus ratio
+# 0 off 1 8
+# 1 off 10001 8.5
+# 00010 bypass 10010 9
+# 00011 bypass 10011 9.5
+# 00100 210100 10
+# 00101 2.5 10101 11
+# 00110 310110 12
+# 00111 3.5 10111 13
+# 01000 411000 14
+# 01001 4.5 11001 15
+# 01010 511010 16
+# 01011 5.5 11011 17
+# 01100 611100 18
+# 01101 6.5 11101 19
+# 01110 70 20
+# 0 7.5 1 off
+#
+# PLL_RNG range
+#00600 - 900
+#01900 - 1000
+#10500 - 600
+#
+# IBM bit numbering:
+# 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
+# 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6
+#
+# 26 27 28 29 30 31
+# 5 4 3 2 1 0
+#
+*pllcBusFreqFile=\/proc/device-tree/clock-frequency;
+#*pllcCPUPVR=\/proc/device-tree/PowerPC,*/cpu-version
[PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
This adds the actual cpufreq driver for the 750GX. It supports all integer ratios that are valid for the processor model and bus frequency. It has two modes of operation. Normal mode uses all valid frequencies. In minmaxmode, only the minimum and maximum are used. This provides the ability for very low latency frequency switches. There is also a sysfs attribute to have it switch off the unused PLL for additional power savings. This does NOT support SMP. My name is Kevin Diggs and I approve this patch. Signed-off-by: Kevin Diggs [EMAIL PROTECTED] Index: Documentation/DocBook/cf750gx.tmpl === --- /dev/null 2004-08-10 18:55:00.0 -0700 +++ Documentation/DocBook/cf750gx.tmpl 2008-08-20 10:00:14.0 -0700 @@ -0,0 +1,441 @@ +?xml version=1.0 encoding=UTF-8? +!DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN + http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd; [] + +book id=ppc750gx-cpufreq-guide + bookinfo + titlePowerPC 750GX (and FX?) cpufreq driver guide/title + + authorgroup + author +firstnameKevin/firstname +surnameDiggs/surname + /author + /authorgroup + +revhistory + revision + revnumber1.0nbsp;/revnumber + dateAugust 12, 2008/date + revremarkInitial revision posted to linuxppc-dev/revremark + /revision +/revhistory + + copyright + year2008/year + holderKevin Diggs/holder + /copyright + + legalnotice + para +This documentation 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. + /para + + para +This program is distributed in the hope that it will be +useful, but WITHOUT ANY WARRANTY; without even the implied +warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +See the GNU General Public License for more details. + /para + + para +You should have received a copy of the GNU General Public +License along with this program; if not, write to the Free +Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, +MA 02111-1307 USA + /para + + para +For more details see the file COPYING in the source +distribution of Linux. + /para + /legalnotice + + releaseinfo + This is the first release of this document coincident with submission of the + driver for inclusion in the kernel. + /releaseinfo + + /bookinfo + + toc/toc + + chapter id=introduction + titleIntroduction/title + para + This guide documents the cpufreq driver for the IBM PowerPC 750GX processor. + It should also work with the 750FX but has not been tested. + /para + para + The driver is split into two main parts. The first provides the low level + interface to the PLL configuration register (HID1 - SPR 1009). It is called + pll_if. The second is the actual cpufreq driver, called cf750gx. The pll_if + component handles the details of dealing with the PLL like PLL lock delay + requirements and preventing illegal operations. The cf750gx driver provides + the interface to the cpufreq subsystem. Under control of the specified + governor it will generate the required commands to switch the processor + frequency as requested and send them to pll_if to carry them out. + /para + /chapter + + chapter id=MajorComponents + titleMajor Components/title + + para + The IBM 750GX (and FX) processor has a pair of PLLs that can be programmed to + operate at a number of different frequencies. The frequencies are specified + as ratios to the system bus and range from 2 to 20. From 2 to 10 it also + supports half ratios (i.e. 2.5, 3.5) though they are not supported in the + cpufreq driver due to a limitation of not being able to switch from one half + ratio directly to another. It takes 100 usec for a PLL to relock to a + new frequency before it can be used [750GX_ds2-17-05.pdf, Table 3-7, + page 18]. It takes 3 bus clocks for the cpu to switch from one PLL to + another [750GX_ds2-17-05.pdf, paragraph 3, page 44]. + /para + + para + The cpufreq driver consists of two main parts: + /para + + itemizedlist + listitem +para + cf750gx - the cpufreq driver module +/para + /listitem + + listitem +para + pll_if - a low level interface that encapsulates the details of dealing + with the PLL register +/para + /listitem + /itemizedlist + + sect1 id=cf750gx + titlecf750gx - The CPUFreq 750GX driver/title + + para +cf750gx provides the standard entry points required of a cpufreq driver. They +are: + + itemizedlist +listitem + para + cf750gx_verify - verify + /para +/listitem + +listitem + para + cf750gx_target - target + /para +/listitem + +listitem + para + cf750gx_cpu_init - cpu init
[PATCH 3/4] Various arch/powerpc changes to support the 750GX cpufreq driver
This patch includes various changes necessary to support the cpufreq driver for
the PowerPC 750GX. Highlights include adding entries to recognize the 750GX to
the cputable (This includes the ... unfortunate pvr that the 750GX used in the
PowerLogix PowerForce 750GX = 0x0008 0203). The PLL switch in idle_6xx.S
during sleep (or nap) was also removed (I tried to add ability to disable this
but the result would not boot?).
My name is Kevin Diggs and I approve this patch.
Signed-off-by: Kevin Diggs [EMAIL PROTECTED]
Index: arch/powerpc/kernel/Makefile
===
--- arch/powerpc/kernel/Makefile.orig 2008-08-13 02:19:18.0 -0700
+++ arch/powerpc/kernel/Makefile2008-08-14 02:50:18.0 -0700
@@ -17,6 +17,7 @@ obj-y := cputable.o ptrace.o syscalls
init_task.o process.o systbl.o idle.o \
signal.o
obj-y += vdso32/
+obj-y += cpu/
obj-$(CONFIG_PPC64)+= setup_64.o sys_ppc32.o \
signal_64.o ptrace32.o \
paca.o cpu_setup_ppc970.o \
Index: arch/powerpc/kernel/cputable.c
===
--- arch/powerpc/kernel/cputable.c.orig 2008-08-13 02:19:19.0 -0700
+++ arch/powerpc/kernel/cputable.c 2008-08-14 03:00:51.0 -0700
@@ -42,9 +42,11 @@ extern void __setup_cpu_604(unsigned lon
extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_750cx(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_750fx(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_750gx(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_7400(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_7410(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_745x(unsigned long offset, struct cpu_spec* spec);
+
#endif /* CONFIG_PPC32 */
#ifdef CONFIG_PPC64
extern void __setup_cpu_ppc970(unsigned long offset, struct cpu_spec* spec);
@@ -660,7 +662,7 @@ static struct cpu_spec __initdata cpu_sp
.machine_check = machine_check_generic,
.platform = ppc750,
},
- { /* 750GX */
+ { /* 750GX rev 1.x */
.pvr_mask = 0x,
.pvr_value = 0x7002,
.cpu_name = 750GX,
@@ -669,7 +671,33 @@ static struct cpu_spec __initdata cpu_sp
.icache_bsize = 32,
.dcache_bsize = 32,
.num_pmcs = 4,
- .cpu_setup = __setup_cpu_750fx,
+ .cpu_setup = __setup_cpu_750gx,
+ .machine_check = machine_check_generic,
+ .platform = ppc750,
+ },
+ { /* 750GX (rev 2.3, as used on PowerLogix 750GX upgrade card */
+ .pvr_mask = 0x,
+ .pvr_value = 0x00080203,
+ .cpu_name = 750GX,
+ .cpu_features = CPU_FTRS_750GX,
+ .cpu_user_features = COMMON_USER | PPC_FEATURE_PPC_LE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .num_pmcs = 4,
+ .cpu_setup = __setup_cpu_750gx,
+ .machine_check = machine_check_generic,
+ .platform = ppc750,
+ },
+ { /* 750GX (All revs = 2.0) */
+ .pvr_mask = 0xff00,
+ .pvr_value = 0x70020200,
+ .cpu_name = 750GX,
+ .cpu_features = CPU_FTRS_750GX,
+ .cpu_user_features = COMMON_USER | PPC_FEATURE_PPC_LE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .num_pmcs = 4,
+ .cpu_setup = __setup_cpu_750gx,
.machine_check = machine_check_generic,
.platform = ppc750,
},
Index: arch/powerpc/kernel/cpu_setup_6xx.S
===
--- arch/powerpc/kernel/cpu_setup_6xx.S.orig2008-08-13 02:19:19.0
-0700
+++ arch/powerpc/kernel/cpu_setup_6xx.S 2008-08-14 02:44:30.0 -0700
@@ -53,6 +53,14 @@ _GLOBAL(__setup_cpu_750fx)
bl setup_750fx
mtlrr4
blr
+_GLOBAL(__setup_cpu_750gx)
+ mflrr4
+ bl __init_fpu_registers
+ bl setup_common_caches
+ bl setup_750_7400_hid0
+ bl setup_750gx
[PATCH 4/4] Add kernel doc for the completion, fix kernel-doc-nano-HOWTO.txt
This patch adds kernel doc for the completion feature. It is in kernel/sched.c
and include/linux/completion.h.
An error in the split-man.pl PERL snippet in kernel-doc-nano-HOWTO.txt is
also fixed.
My name is Kevin Diggs and I approve this patch.
Signed-off-by: Kevin Diggs [EMAIL PROTECTED]
Index: Documentation/kernel-doc-nano-HOWTO.txt
===
--- Documentation/kernel-doc-nano-HOWTO.txt.orig2008-08-13
02:18:53.0 -0700
+++ Documentation/kernel-doc-nano-HOWTO.txt 2008-08-19 14:21:43.0
-0700
@@ -168,10 +168,10 @@ if ($#ARGV 0) {
mkdir $ARGV[0],0777;
$state = 0;
while (STDIN) {
-if (/^\.TH \[^\]*\ 4 \([^\]*)\/) {
+if (/^\.TH \[^\]*\ 9 \([^\]*)\/) {
if ($state == 1) { close OUT }
$state = 1;
- $fn = $ARGV[0]/$1.4;
+ $fn = $ARGV[0]/$1.9;
print STDERR Creating $fn\n;
open OUT, $fn or die can't open $fn: $!\n;
print OUT $_;
Index: include/linux/completion.h
===
--- include/linux/completion.h.orig 2008-08-13 00:56:52.0 -0700
+++ include/linux/completion.h 2008-08-20 01:47:21.0 -0700
@@ -10,6 +10,18 @@
#include linux/wait.h
+/**
+ * struct completion - structure used to maintain state for a completion
+ *
+ * This is the opaque structure used to maintain the state for a completion.
+ * Completions currently use a FIFO to queue threads that have to wait for
+ * the completion event.
+ *
+ * See also: complete(), wait_for_completion() (and friends _timeout,
+ * _interruptible, _interruptible_timeout, and _killable), init_completion(),
+ * and macros DECLARE_COMPLETION(), DECLARE_COMPLETION_ONSTACK(), and
+ * INIT_COMPLETION().
+ */
struct completion {
unsigned int done;
wait_queue_head_t wait;
@@ -21,6 +33,14 @@ struct completion {
#define COMPLETION_INITIALIZER_ONSTACK(work) \
({ init_completion(work); work; })
+/**
+ * DECLARE_COMPLETION: - declare and initialize a completion structure
+ * @work: identifier for the completion structure
+ *
+ * This macro declares and initializes a completion structure. Generally used
+ * for static declarations. You should use the _ONSTACK variant for automatic
+ * variables.
+ */
#define DECLARE_COMPLETION(work) \
struct completion work = COMPLETION_INITIALIZER(work)
@@ -29,6 +49,13 @@ struct completion {
* completions - so we use the _ONSTACK() variant for those that
* are on the kernel stack:
*/
+/**
+ * DECLARE_COMPLETION_ONSTACK: - declare and initialize a completion structure
+ * @work: identifier for the completion structure
+ *
+ * This macro declares and initializes a completion structure on the kernel
+ * stack.
+ */
#ifdef CONFIG_LOCKDEP
# define DECLARE_COMPLETION_ONSTACK(work) \
struct completion work = COMPLETION_INITIALIZER_ONSTACK(work)
@@ -36,6 +63,13 @@ struct completion {
# define DECLARE_COMPLETION_ONSTACK(work) DECLARE_COMPLETION(work)
#endif
+/**
+ * init_completion: - Initialize a dynamically allocated completion
+ * @x: completion structure that is to be initialized
+ *
+ * This inline function will initialize a dynamically created completion
+ * structure.
+ */
static inline void init_completion(struct completion *x)
{
x-done = 0;
@@ -53,6 +87,13 @@ extern unsigned long wait_for_completion
extern void complete(struct completion *);
extern void complete_all(struct completion *);
+/**
+ * INIT_COMPLETION: - reinitialize a completion structure
+ * @x: completion structure to be reinitialized
+ *
+ * This macro should be used to reinitialize a completion structure so it can
+ * be reused. This is especially important after complete_all() is used.
+ */
#define INIT_COMPLETION(x) ((x).done = 0)
#endif
Index: kernel/sched.c
===
--- kernel/sched.c.orig 2008-08-13 02:22:42.0 -0700
+++ kernel/sched.c 2008-08-20 12:36:01.0 -0700
@@ -4363,6 +4363,15 @@ __wake_up_sync(wait_queue_head_t *q, uns
}
EXPORT_SYMBOL_GPL(__wake_up_sync); /* For internal use only */
+/**
+ * complete: - signals a single thread waiting on this completion
+ * @x: holds the state of this particular completion
+ *
+ * This will wake up a single thread waiting on this completion. Threads will
be
+ * awakened in the same order in which they were queued.
+ *
+ * See also complete_all(), wait_for_completion() and related routines.
+ */
void complete(struct completion *x)
{
unsigned long flags;
@@ -4374,6 +4383,12 @@ void complete(struct completion *x)
}
EXPORT_SYMBOL(complete);
+/**
+ * complete_all: - signals all threads waiting on this completion
+ * @x: holds the state of this particular completion
+ *
+ * This will wake up all threads waiting on this particular completion event.
+ */
void complete_all(struct completion *x)
{
unsigned long flags;
@@ -4425,12
Re: [PATCH 1/4] Add low level PLL config register interface module
Kumar Gala wrote: On Aug 25, 2008, at 5:41 AM, Kevin Diggs wrote: This adds a small module to handle the low level details of dealing with the PLL config register (HID1) found in the IBM 750GX. It provides 2 possible interfaces, both selectable via kernel config options. One is a sysfs attribute and the other is a normal function API. It is called pll_if. The determination of the bus frequency is what worked on a PowerMac 8600. Any suggestions on a more general solution are welcome. WARNING - I used some #ifdefs - Let the fur fly! My name is Kevin Diggs and I approve this patch. This really should be split into two patches. One for the perl script and one for the actual kernel code. First, thanks for taking the time for the review! I can do that. But how? Do I respin everything as x/5? Do I only send out the PERL script as 5/4? Do I redo patch 1 as 1a/4 and 1b/4 (or 1.1/4 and 1.2/4)? Scanning the actual kernel code you have a lot of #ifdef's that should be cleaned up: Can't #ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_SYSFS just be #ifdef CONFIG_SYSFS and the same for CONFIG_PPC_750GX_DUAL_PLL_IF_HRTIMER CONFIG_PPC_750GX_DUAL_PLL_IF_CPU_FREQ? I like flexibility. So I allow this module to be configured with either one or both (or none - if you just want some dead code!) of the available interfaces. As an example, CONFIG_..._PLL_IF_SYSFS adds the sysfs attribute to directly control the PLL from user space via writes to the attribute file under /sys. On my system, a PowerMac 8600, this shows up in /sys/devices/system/cpu/cpu0/ppc750gxpll. CONFIG_..._PLL_IF_CPU_FREQ adds the public API functions that are used by the cpufreq driver. CONFIG_..._PLL_IF_HRTIMER causes it to use the HR timer stuff. This results in MUCH lower latencies (102 usec vs 3900 usec (HZ=250)). But I did not want to REQUIRE HR timers (even though they are pretty cool!). Did I mention that I like flexibility? Seriously, should I add a check that at least one of ..._SYSFS or ..._CPU_FREQ is defined and refuse to compile otherwise? Via a pragma or something? #ifdef CONFIG_PPC_OF seems unnecessary as all PPC always has this set. I ... uh ... have no idea? Should I remove it? What's up with #define MULFIRST and the #if 0? This was just some goofing off in a debug message. I was playing around trying to see what effect various code arrangements had on accuracy. Since this is in debug code I was kinda hoping for some leniancy. The #if 0 is removing code that ... prevented preemption between the processor speed switch and the changing of the loops_per_jiffy value. The idea was that I did not want to change any sleeps. I now think that processor speed is not a determining factor in delays. I think the time base register (or decrementer) are used. I don't even change the loops_per_jiffy any more (Maybe that is incorrect?). I left this code in there to potentially jog my memory if I find myself debugging some problem in the future? Would a comment be helpful? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev At the tone the timebase will be 12499983. No trailing 0s. Very bad for accuracy. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
Arnd Bergmann wrote:
On Monday 25 August 2008, Kevin Diggs wrote:
+ * cf750gx.c - cpufreq driver for the dual PLLs in the 750gx
Thanks for posting this driver and for your attention for detail
and for documentation in particular. Few people bother to write
documentation at this level.
I don't understand enough of cpufreq or your hardware to comment
on that, but please let me give you a few hints on coding style.
+ * Copyright (C) 2008 kevin Diggs
Most people list their email address here as well
For reasons I'd rather not go into, my email address is not likely
to remain valid for much longer.
+#define cf750gxmChangingPll(0x8000)
+#define cf750gxmChangingPllBit (31)
+#define cf750gxmTurningIdlePllOff (0x4000)
+#define cf750gxmTurningIdlePllOffBit (30)
constants should be ALL_CAPS, not sIllYCaPS.
Are cf750gxm_CHANGING_PLL and cf750gxm_CHANGING_PLL_BIT_POS ok?
+struct pll_750fgx_t {
+ unsigned short min_ratio; /* min bus ratio */
+ unsigned short max_ratio; /* max bus ratio */
+ unsigned int min_core; /* min core frequency per spec (KHz) */
+ unsigned int max_core; /* max core frequency per spec (KHz) */
+};
please drop the _t at the end of the identifier.
done
+MODULE_AUTHOR(Kevin Diggs);
+MODULE_DESCRIPTION(750GX Dual PLL cpufreq driver);
+MODULE_LICENSE(GPL);
Move this to the end.
done
+struct cf750gx_t_call_data {
+ struct cpufreq_freqs freqs;
+ unsigned long current_pll;
+ int idle_pll_off;
+};
drop the _t here, or make explicit what is meant by it.
Now that I look at it the _t is supposed to be at the end. It is
meant to indicate that this is a structure tag or type. I'll
remove it.
+static const struct pll_750fgx_t __initdata pll_750fx = {
+ .min_ratio = 2,
+ .max_ratio = 20,
+ .min_core = 40,
+ .max_core = 80,
+};
+
+static const struct pll_750fgx_t __initdata pll_750gx = {
+ .min_ratio = 2,
+ .max_ratio = 20,
+ .min_core = 50,
+ .max_core = 100,
+};
Are these correct on any board? If they can be different
depending on the board design, it would be better to get
this data from the device tree.
They are a spceification of the processor itself. Should be
the same for any board using the 750GX (or FX).
+static DECLARE_COMPLETION(cf750gx_v_exit_completion);
+
+static unsigned int override_min_core = 0;
+static unsigned int override_max_core = 0;
+static unsigned int minmaxmode = 0;
+
+static unsigned int cf750gx_v_min_core = 0;
+static unsigned int cf750gx_v_max_core = 0;
+static int cf750gx_v_idle_pll_off = 0;
+static int cf750gx_v_min_max_mode = 0;
+static unsigned long cf750gx_v_state_bits = 0;
Is 0 a meaningful value for these? If it just means 'uninitialized',
then better don't initialize them in the first place, for clarity.
The first 3 are module parameters. For the first 2, 0 means
that they were not set. minmaxmode is a boolean. 0 is the
default of disabled.
When I was initially writing the code I figured I would
need the min and max core frequencies in several places.
As it turns out they are only used in the code
initialization routine (cf750gx_init()). I have made
them locals.
..._idle_pll_off is a boolean for a sysfs attribute. 0 is
the default of disabled.
..._min_max_mode is a boolean to hold the state of
minmaxmode. Seems to be only used to print the current
value.
..._state_bits is a global to maintain state.
Does the PowerPC suffer any performance penalties when
accessing shorts compared to ints? Can I save a few bytes
by using shorts?
+static struct cpufreq_frequency_table *cf750gx_v_f_table;
+static struct cpufreq_frequency_table *cf750gx_v_freq_table;
+static struct cpufreq_frequency_table *cf750gx_v_min_max_freq_table;
+
+static struct cf750gx_t_call_data cf750gx_v_switch_call_data;
+static struct cf750gx_t_call_data cf750gx_v_lock_call_data;
+static struct notifier_block cf750gx_v_pll_switch_nb;
+static struct notifier_block cf750gx_v_pll_lock_nb;
Also, in general, try to avoid global variables here, even
in file scope (static), but rather put all device specific
data into a per-device data structure.
How big of a problem is this? I regret the decision to rip
the SMP stuff out. But it is kinda done. If absolutely
necessary I can put these into a structure?
+static int cf750gx_pll_switch_cb(struct notifier_block *nb, unsigned long
+ action, void *data)
+{
+struct cf750gx_t_call_data *cd;
+unsigned int idle_pll;
+unsigned int pll_off_cmd;
+unsigned int new_pll;
The whitespace appears damaged here.
Just a coding style thing. I put declarations (or definitions -
I get the two confused?) on the same indent as the block they are
in. Is this a 15 yard illegal procedure penalty?
+ cd = (struct cf750gx_t_call_data *)data;
done
data is a void pointer, so you don't need the cast, and shouldn't
have it therefore
compile testing: cpufreq stats driver?
Hi, When I tried building my cpufreq driver into the kernel, the cpufreq stats driver quit working? Anyone know if I screwed something up? Or is this normal (2.6.26)? Also, I thought, apparently incorrectly, That module parameters became boot parameters when the module was built in to the kernel? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
checkpatch nits ...
Hi, Can I ignore these checkpatch errors: ERROR: do not initialise statics to 0 or NULL #829: FILE: powerpc/kernel/cpu/pll_if.c:61: +static unsigned int override_bus_clock = 0; ERROR: do not initialise externals to 0 or NULL #1281: FILE: powerpc/kernel/cpu/pll_if.c:513: +int rval = 0; Someone (Arnd?) told me this was due to an older compiler putting these in a strange section? WARNING: externs should be avoided in .c files #1137: FILE: powerpc/kernel/cpu/pll_if.c:369: + __asm__ __volatile__ ( ??? I don't know what this is? The entire block is: __asm__ __volatile__ ( addi %0,%3,-1\n andc %1,%3,%0\n cntlzw %1,%1\n subfic %1,%1,31\n cntlzw %0,%2\n: =r(cntlz), =r(cnttz): r(tmp), b(cnttz) ); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
disable modules and get multiple definition errors?
Hi,
I am trying to do some compile testing of my cpufreq driver. If
I disable modules I am getting multiple definition errors of inline
functions:
inline volatile unsigned int get_PLL(void)
{
unsigned int ret;
__asm__ __volatile__ (mfspr %0,%1:
=r(ret):
i(SPRN_HID1)
);
return ret;
}
arch/powerpc/kernel/cpu/pll_if.o(.text+0x1c): In function `get_PLL':
: multiple definition of `get_PLL'
arch/powerpc/kernel/cpu/cpufreq/built-in.o(.text+0x0): first defined here
What am I doing wrong?
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Corrections please ...
Could I get any needed corrections on this. Especially on the ???
[EMAIL PROTECTED] linux-2.6.26]$ diff -U3
include/linux/completion.{h.orig,h}|more
--- include/linux/completion.h.orig 2008-08-13 00:56:52.0 -0700
+++ include/linux/completion.h 2008-08-18 13:00:23.0 -0700
@@ -10,6 +10,16 @@
#include linux/wait.h
+/**
+ * struct completion - structure used to maintain state for a completion
+ * @done: counting variable used to signal completion
+ * @wait: internal wait queue head; used for locking and synchronization
+ *
+ * This is the structure used to maintain the state for a completion. See
+ * also: complete(), wait_for_completion() (and friends _timeout,
+ * _interruptible, _interruptible_timeout, and _killable),
init_completion(),
+ * and macros DECLARE_COMPLETION() and INIT_COMPLETION().
+ */
struct completion {
unsigned int done;
wait_queue_head_t wait;
@@ -36,6 +46,13 @@
# define DECLARE_COMPLETION_ONSTACK(work) DECLARE_COMPLETION(work)
#endif
+/**
+ * init_completion: - Initialize a dynamically allocated completion
+ * @x: completion structure that is to be initialized
+ *
+ * This inline function will initialize a dynamically created completion
+ * structure.
+ */
static inline void init_completion(struct completion *x)
{
x-done = 0;
--- kernel/sched.c.orig 2008-08-13 02:22:42.0 -0700
+++ kernel/sched.c 2008-08-18 13:31:03.0 -0700
@@ -4363,6 +4363,13 @@
}
EXPORT_SYMBOL_GPL(__wake_up_sync); /* For internal use only */
+/**
+ * complete: - signals a single thread waiting on this completion
+ * @x: holds the state of this particular completion
+ *
+ * This will wake up a single thread waiting on this completion. If
multiple
+ * threads are waiting ???
+ */
void complete(struct completion *x)
{
unsigned long flags;
@@ -4374,6 +4381,12 @@
}
EXPORT_SYMBOL(complete);
+/**
+ * complete_all: - signals all threads waiting on this completion
+ * @x: holds the state of this particular completion
+ *
+ * This will wake up all threads waiting on this particular completion
event.
+ */
void complete_all(struct completion *x)
{
unsigned long flags;
@@ -4425,12 +4438,27 @@
return timeout;
}
+/**
+ * wait_for_completion: - waits for completion of a task
+ * @x: holds the state of this particular completion
+ *
+ * This waits to be signaled for completion of a specific task. It is NOT
+ * interruptible and there is no timeout.
+ */
void __sched wait_for_completion(struct completion *x)
{
wait_for_common(x, MAX_SCHEDULE_TIMEOUT, TASK_UNINTERRUPTIBLE);
}
EXPORT_SYMBOL(wait_for_completion);
+/**
+ * wait_for_completion_timeout: - waits for completion of a task
(w/timeout)
+ * @x: holds the state of this particular completion
+ * @timeout: timeout value in jiffies
+ *
+ * This waits to be signaled for completion of a specific task. It is NOT
+ * interruptible. But there is a timeout in jiffies.
+ */
unsigned long __sched
wait_for_completion_timeout(struct completion *x, unsigned long timeout)
{
@@ -4438,6 +4466,13 @@
}
EXPORT_SYMBOL(wait_for_completion_timeout);
+/**
+ * wait_for_completion_interruptible: - waits for completion of a task
(w/intr)
+ * @x: holds the state of this particular completion
+ *
+ * This waits to be signaled for completion of a specific task. It is
+ * interruptible.
+ */
int __sched wait_for_completion_interruptible(struct completion *x)
{
long t = wait_for_common(x, MAX_SCHEDULE_TIMEOUT,
TASK_INTERRUPTIBLE);
@@ -4447,6 +4482,14 @@
}
EXPORT_SYMBOL(wait_for_completion_interruptible);
+/**
+ * wait_for_completion_interruptible_timeout: - waits for completion
(w/(to,int
r))
+ * @x: holds the state of this particular completion
+ * @timeout: timeout value in jiffies
+ *
+ * This waits to be signaled for completion of a specific task. It is
+ * interruptible. And there is a timeout in jiffies.
+ */
unsigned long __sched
wait_for_completion_interruptible_timeout(struct completion *x,
unsigned long timeout)
@@ -4455,6 +4498,13 @@
}
EXPORT_SYMBOL(wait_for_completion_interruptible_timeout);
+/**
+ * wait_for_completion_killable: - waits for completion of a task
(killable)
+ * @x: holds the state of this particular completion
+ *
+ * This waits to be signaled for completion of a specific task. It is
+ * killable (???).
+ */
int __sched wait_for_completion_killable(struct completion *x)
{
long t = wait_for_common(x, MAX_SCHEDULE_TIMEOUT, TASK_KILLABLE);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
12.5 MHz woo hoo!
[EMAIL PROTECTED] root]# cat /proc/cpuinfo
processor : 0
cpu : 750GX
temperature : 1-76 C (uncalibrated)
clock : 200.00MHz
revision: 2.3 (pvr 0008 0203)
bogomips: 24.96
timebase: 1250 -- 12.5 MHz exactly!!!
platform: PowerMac
model : Power Macintosh
machine : Power Macintosh
motherboard : AAPL,8500 MacRISC
detected as : 16 (PowerMac 8500/8600)
pmac flags :
pmac-generation : OldWorld
Hey, anybody know if that temperature, thermal thingy works well enough
to bother fooling with the code to produce a more valid value?
also:
[EMAIL PROTECTED] root]# alias tis
alias tis='cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state'
[EMAIL PROTECTED] root]# tis
25 178419
30 0
35 0
40 0
45 0
50 0
55 0
60 0
65 0
70 0
75 0
80 0
85 0
90 0
95 0
100 0
[EMAIL PROTECTED] root]# uname -vr
2.6.26-pll #4 Thu Aug 14 04:02:58 PDT 2008
Finally, can someone tell me if the attached file shows up ok if it were
a patch I wanted to submit? I can't seem to figure out how to 'import
inline' using this ancient mailer.
kevin
/*
* cf750gx.c - cpufreq driver for the dual PLLs in the 750gx
* ($Revision: 1.0 $)
*
* Copyright (C) 2008 kevin Diggs
*
* ~~
*
* 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.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
*
* ~~
*/
#define DEBUG
#include linux/init.h
#include linux/module.h
#include linux/autoconf.h
#include linux/kernel.h
#include linux/errno.h
#include linux/cpu.h
#include linux/of.h
#include linux/notifier.h
#include linux/delay.h
#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_SYSFS
#include linux/sysdev.h
#endif
#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_HRTIMER
#include linux/hrtimer.h
#endif
#include asm/uaccess.h
#include asm/bitops.h
#include asm/time.h
#include asm/mmu.h
#include asm/processor.h
#include asm/io.h
#include asm/pgtable.h
#include asm/cputable.h
#include asm/system.h
#include asm/pll_if.h
#include asm/pll.h
#include asm/smp.h
MODULE_LICENSE(GPL);
static unsigned int boot_ratio;
static unsigned int pllifvBusClock;
static unsigned int override_bus_clock = 0;
#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_HRTIMER
static enum hrtimer_restart pllTimerF(struct hrtimer *hrt);
static struct hrtimer pll_timer;
static unsigned long hrtimers_got_no_freakin_callback_data;
#ifdef DEBUG
cycles_t pll_time_stamp;
#endif
#else
static void pllTimerF(unsigned long newPLL);
static struct timer_list pll_timer;
cycles_t pll_time_stamp;
#endif
#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_SYSFS
extern unsigned long loops_per_jiffy;
unsigned long boot_loops;
static struct sys_device *sysdev_cpu;
static ssize_t show_ppc750gxpll(struct sys_device *dev, char *buf)
{
return sprintf(buf, %x\n, get_PLL());
}
int modifyPLL(unsigned int pll, int scaleLPJ);
//static ssize_t __attribute_used__ store_ppc750gxpll(struct sys_device *dev,
// const char *buf, size_t count)
static ssize_t __used store_ppc750gxpll(struct sys_device *dev,
const char *buf, size_t count)
{
unsigned int pll;
char *ptr;
pr_debug(__FILE__%s()-%d: buf=%s\n, __func__, __LINE__, buf);
pll = simple_strtoul(buf, ptr, 16);
pr_debug(__FILE__%s()-%d: %x (%d)\n, __func__, __LINE__, pll, pll);
/* modifyPLL(pll,!0); */
modifyPLL(pll, 0);
return ptr-buf;
}
static SYSDEV_ATTR(ppc750gxpll, 0600, show_ppc750gxpll, store_ppc750gxpll);
#endif
#ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_CPU_FREQ
struct plliftCallData {
void *data;
int scalar;
};
static struct plliftCallData pllifvSwitchCallData;
static struct plliftCallData pllifvLockCallData;
static RAW_NOTIFIER_HEAD(pllifvPllSwitchChain);
static RAW_NOTIFIER_HEAD(pllifvPllLockChain);
#endif
/*
* This initializes the code for the PLL control:
* boot_ratio is used to scale the loops_per_jiffy value from its boot value
* boot_loops is the boot value of loops_per_jiffy and is used to compute new
* values
*/
static int __init init_PLL(void)
{
unsigned int temp;
#ifdef CONFIG_PPC_OF
const u32 *clk;
struct device_node *tree_root;
#endif
if (!cpu_has_feature
__attribute_used__ in 2.6.24
Hi, Something in a function signature called __attribute_used__ would compile in 2.6.24. This does not compile in 2.6.26. Using the store_##NAME template from arch/powerpc/kernel/sysfs.c as a guide, this appears to have changed to __used. Anything work in both? __used seems to have compiled in 2.6.24? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
details, details ...
Hi,
In cpu exit function of a cpufreq driver:
while (test_bit(cf750gxmChangingPllBit, cf750gxvStateBits))
msleep(1);
This bit will get cleared by a notifier callback.
In module_exit function of a related module:
while (test_bit(PLL_LOCK_BIT, (unsigned long *)boot_ratio)) {
msleep(1);
}
This bit will get cleared by a timer. It will also fire the notifiers
needed above.
I don't think these are in interrupt context. The sleeps ok here?
Also, from checkpatch:
ERROR: do not initialise externals to 0 or NULL
#2483: FILE: arch/powerpc/kernel/cpu/pll_if.c:486:
+int rval = 0;
ERROR: do not initialise statics to 0 or NULL
#2058: FILE: arch/powerpc/kernel/cpu/pll_if.c:61:
+static unsigned int override_bus_clock = 0;
Huh? What? Anyone care to teach an old dog a new trick???
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: details, details ...
Arnd Bergmann wrote:
On Wednesday 13 August 2008, Kevin Diggs wrote:
Arnd Bergmann wrote:
On Wednesday 13 August 2008, Kevin Diggs wrote:
In cpu exit function of a cpufreq driver:
while (test_bit(cf750gxmChangingPllBit, cf750gxvStateBits))
msleep(1);
This bit will get cleared by a notifier callback.
In module_exit function of a related module:
while (test_bit(PLL_LOCK_BIT, (unsigned long *)boot_ratio)) {
msleep(1);
}
This bit will get cleared by a timer. It will also fire the notifiers
needed above.
I don't think these are in interrupt context. The sleeps ok here?
Technically ok, but not nice. Besides the coding style issues,
it's still a busy loop that should be replaced by wait_for_completion().
I took a brief look at wait_for_completion(). Looks kinda heavy weight.
Just to be clear both of these code fragments are in code shutdown (i.e.
exit) paths. Is the use of wait_for_completion() still preferred? I
thought a busy loop used the delay routines?
You should always write code that is easy to understand and tells the
reader what you mean. If you want to wait for something to complete,
use wait_for_completion. If you look at what msleep does internally,
you will find that it isn't simpler than wait_for_completion either.
The loop doing msleep(1) is not as bad as a loop doing delays, but
it can still cause unnecessary wakeups and on average will sleep
one milisecond too long. Neither of these is a real problem, but
if you can do it correctly, just do.
Please forgive me. I'm not trying to be argumentative. I'm just trying
to learn. I found a section in the O'Reilly Linux device driver guide on
this completion stuff. If I understand it correctly, I initialize a
completion thing. In the code that starts the task I do a complete(). In
the exit code I'll do a wait_for_completion(). In my usage paradigm I
will VERY rarely ever call wait_for_completion() and have it actually
wait. This still match completion's intended use?
Can you elaborate on the coding style issues? Variable names? Use of the
bit stuff? Those brace thingies?
Variables should be lower-case names, constants should be upper-case.
Both should have names that tell you what they are used for.
The case in the second code sample is either wrong, or redundant.
You should leave out curly braces when you only have a single line
in the basic block. Read Documentation/CodingStyle to learn about
more things to consider.
Can I post the 2 routines for RFC style comments? Or is that to much
trouble?
Don't bother. Old gcc variants would put these variables into .data
instead of .bss, but with a new (less than 5 years or so) gcc, both
will result in .bss storage that is initialized to zero at boot time.
??? So ... I can ignore the error? Or I should not be initializing
variables to 0 (or NULL)?
Either fix checkpatch.pl not to warn about these, or just don't initialize
the variables. Initializing a variable at declaration time is frowned upon
by some people, because it is redundant in case of static or global
variables, and error-prone for automatic variables.
When you say initializing is frowned upon, do you mean only when you are
initializing to zero? Is the redundancy (for the case of 0?) a part of
the C spec? Or is it gcc specific? error-prone for automatic variables?
kevin
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: to schedule() or not to schedule() ?
Chris Friesen wrote:
Kevin Diggs wrote:
Hi,
I have the following near the top of my cpufreq driver target
routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
* schedule() here! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}
This is to prevent bad things from happening if someone is trying to
change a parameter for the driver via sysfs while the target routine
is running. Fortunately, because I had a bug where this bit was not
getting cleared on one of the paths through the target routine ... I
now know it is not safe to call schedule (it got stuck in there -
knocked out my adb keyboard! - (I think target is called from a timer
that the governor sets up ... interrupt context?)).
Is the issue that someone may be in the middle of a multi-stage
procedure, and you've woken up partway through?
If so, what about simply rescheduling the timer for some short time in
the future and aborting the current call?
Chris
Chris,
Thanks for taking the time to reply. The parameter in question modifies
the frequency table. It is used several times in the target routine.
I've addressed the issue by making a local copy of the frequency table
upon entry to the target routine and use that while there. I don't care
who wins the race.
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
inline assembly r0 SOS
Hi,
If I have:
inline unsigned int get_PLL_range(unsigned int range, unsigned int
config)
{
unsigned int ret;
/*
* Turn r3 (range) into a rotate count for the selected range.
* 0 - 23, 1 - 31
*/
__asm__ __volatile__ ( slwi %0,%0,3\n
addi %0,%0,23\n
rlwnm %0,%1,%0,30,31\n:
=r(ret):
r(config),0(range)
);
return ret;
}
in a header and the resultant code generated is:
.L58:
li 0,1 # ratio,
mr 29,0 # ret, ratio
#APP
slwi 29,29,3 # ret
addi 29,29,21# ret
rlwnm 29,28,29,27,31 # ret, ret
slwi 0,0,3 # ret
addi 0,0,23 # ret
rlwnm 0,28,0,30,31 # ret, ret
#NO_APP
thats bad right? Because the addi 0, 0, 23 will not work as expected
because of the special property of r0. FYI: The first three lines
after the #APP are from a similar function get_PLL_ratio().
Is there a way to blacklist r0?
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: to schedule() or not to schedule() ?
Michael Ellerman wrote:
On Tue, 2008-08-05 at 12:26 -0700, Kevin Diggs wrote:
Chris Friesen wrote:
Kevin Diggs wrote:
I have the following near the top of my cpufreq driver target
routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
* schedule() here! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}
This is to prevent bad things from happening if someone is trying to
change a parameter for the driver via sysfs while the target routine
is running. Fortunately, because I had a bug where this bit was not
getting cleared on one of the paths through the target routine ... I
now know it is not safe to call schedule (it got stuck in there -
knocked out my adb keyboard! - (I think target is called from a timer
that the governor sets up ... interrupt context?)).
Is the issue that someone may be in the middle of a multi-stage
procedure, and you've woken up partway through?
If so, what about simply rescheduling the timer for some short time in
the future and aborting the current call?
Chris,
Thanks for taking the time to reply. The parameter in question modifies
the frequency table. It is used several times in the target routine.
I've addressed the issue by making a local copy of the frequency table
upon entry to the target routine and use that while there. I don't care
who wins the race.
How are you copying the table? Is it an atomic copy? Otherwise you could
just end up copying the table while it's being updated, and you get a
copy of the partially updated table.
Don't you just need a spinlock?
cheers
In the initialization routine I create 2 tables. One is a table with all
the frequencies. The other has just the min and max. The parameter just
changes a pointer to point to one table or the other. The above
addressing of the issue should really say a local copy of the pointer
to the frequency table.
Thanks for the reply!
For the purpose of learning, there is no direct, correct way to yield
the cpu when in a timer fired routine, right?
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: inline assembly r0 SOS
Jeremy Kerr wrote: Hi Kevin, /* * Turn r3 (range) into a rotate count for the selected range. * 0 - 23, 1 - 31 */ __asm__ __volatile__ ( slwi %0,%0,3\n addi %0,%0,23\n rlwnm %0,%1,%0,30,31\n: =r(ret): r(config),0(range) ); Wouldn't this be much simpler in plain C? I just knew someone was gonna try to rain on my rlwnm'in fun parade! Wonder if the C code can be made to compile down to 3 instructions? However, if you really do need to do this in inline asm, you can use the b modifier rather than r to avoid using r0. Oh cool! Thanks! You to Ben! Cheers, Jeremy kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
to schedule() or not to schedule() ?
Hi,
I have the following near the top of my cpufreq driver target routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
* schedule() here! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}
This is to prevent bad things from happening if someone is trying to
change a parameter for the driver via sysfs while the target routine is
running. Fortunately, because I had a bug where this bit was not getting
cleared on one of the paths through the target routine ... I now know it
is not safe to call schedule (it got stuck in there - knocked out my adb
keyboard! - (I think target is called from a timer that the governor
sets up ... interrupt context?)).
How does one very briefly yield the cpu in this context?
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
750GX
Hi, In the 750GX data sheet (750GX_ds2-17-05.pdf), page 45 has Table 5-1 that describes the PLL range field. It goes something like this: PLL_RNGrange 00600 - 900 01900 - 1000 10500 - 600 Anyone have any thoughts as to what the correct values are for 600 and 900? I think I have this working. I was setting the range to 1 for all frequencies because I did: if(freq600) instead of if(freq60) when building my frequency table. This cpufreq stuff definitely messes up the repeatability of my bogomazes value. kevin P.S.: I'd be interested in various theories as to what this does? P.P.S.: On page 341 of the 750GX user manual It says: Turning the non selected PLL off results in a modest power savings ... Regarding what goes on in idle_6xx.S, wouldn't this likely save more power than switching to a lower frequency (to clock mostly nothing since the processor is going into doze or nap)? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
inline assembly
Hi, When doing inline assembly, is there a way to get the compiler to assign extra (one not specified for inputs and outputs) registers? In the following: __asm__ __volatile__ ( addi 5,%1,-1\n andc 5,%1,5\n cntlzw 5,5\n subfic %0,5,31: =r(j): r(i) ); Can I get the compiler to choose a register for r5? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
