Re: cpu idle time going backward
On 12/8/11, Andreas Schwab 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
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: RTC on 2.6.36 for PowerMac 8600
Hi, On 1/29/12, Andreas Schwab wrote: > kevin diggs 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
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 -CONFIG_CP
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 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 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
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
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
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
#include
using namespace std;
inline void pr_message(string s="Hello world!") {
cout< 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
> 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
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: [PATCH] powerpc: Fix some 6xx/7xxx CPU setup functions
On Fri, Jan 21, 2011 at 12:35 AM, Benjamin Herrenschmidt 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 > --- > > 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 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 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 >> 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 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 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 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: 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 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, 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 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 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, 4.2.4 does NOT work. 4.1.2 DOES work. Is there some magic PowerPC specific gcc patch somewhere? Should I reorient the computer relative to the planet's magnetic field when I compile with newer gcc? A magic handshake? what? Is anyone using a compiler newer than 4.1.2? Sorry, but I do not know where to go from here? kevin On Sat, Jan 22, 2011 at 12:24 PM, kevin diggs 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 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
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: 750gx cpufreq induced kernel panic in 2.6.36
On Tue, Jan 25, 2011 at 10:32 PM, Benjamin Herrenschmidt 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: at ]]
+ * [[ LR =]]
+ * [] [] [[
(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: at ]]
+ * [[ LR = ]]
+ * [] [] [[ (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 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
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 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 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: 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, 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
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 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: 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 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
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 /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 wrote: > > make drivers/scsi/mesh.s > ??? I thought I have tried this in the past and it did not work? The make /.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 wrote: >>> make drivers/scsi/mesh.s >>> >> ??? I thought I have tried this in the past and it did not work? The >> make /.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: 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 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
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: halt/reset on assert?
On Thu, Apr 7, 2011 at 2:55 AM, Benjamin Herrenschmidt
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
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: [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 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 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: book to learn ppc assembly and architecture
Hi, On Mon, May 16, 2011 at 6:38 PM, Benjamin Herrenschmidt 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: 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
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: [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 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
Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
Hi, On Wed, Jun 29, 2011 at 3:58 PM, Dmitry Eremin-Solenikov 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
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: 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
questions
Hi, In idle_6xx.S one finds instructions like: lis r4,[EMAIL PROTECTED] lwz r4,[EMAIL PROTECTED](r4) Can someone explain what this is doing? Presumably the first is loading an address and the second a value. What do the '@ha' and '@l' do? Also, is there any performance difference between: lbz rD,d(rA) lhz rD,d(rA) lwz rD,d(rA) While I'm wasting your time, I picked up an ADB infrared wireless keyboard. I think it works. But not under Linux. Should it? And is there any reason to prefer one over the other for doing byte swapping: lwbrx rD,rA,rB stwbrx rS,rA,rB kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
cntlzw
Hi, x86 has bsf and bsr. PPC has cntlzw which I think is equivalent to bsr. Anyone know of a sneaky algorithm to do bsf? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
750GX cpu freq support
Hi,
I was hoping that someone might know something about the cpufreq stuff
and would be willing to take a look at what I have so far.
It all loads up and tries to run. But if I switch to the conservative
governor it starts trying to switch to some 4.2 billion KHz (-49000). It
(the system) seems to eventually freeze up. The ondemand governor sort
of has the opposite effect. It wants to go to 0 KHz?
This is built on a module called pll_if that handles the low level
interface to the PLL register (HID1). It (pll_if) includes an optional
sysfs attribute that can be used to monkey with the PLL. I have a perl
script to allow one to modify the PLL in a more human friendly way. Via
the sysfs attribute, pll_if is useable. So I don't think the problem is
in it (though it is supposed to prevent you from doing anything stupid,
like switching to a PLL that is off or modifying the active PLL - but it
may not be as bullet proof as I would like).
In particular, the frequency switch in my driver is not synchronous (it
may not be completed when Target() returns). Don't know if
cpufreq_core/governors care about this? Is this notifier stuff some kind
of generic "callback" framework?
Any investigating tips would be appreciated. I don't know whether
pll_if is being asked to do something dumb and is doing it or if it is
freezing up else where.
"System" is a powermac 8600 with a powerlogix 750GX card in it.
kevin
P.S.: This will show how much of a novice I am: What's a "git"?
/*
* 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.
*
* ~~
*/
#include
#include
#include
#include
#include
#include
#include
#include "linux/of.h"
//#include
//#include
#include
//#include
#include
//#include
#include "asm/pll.h"
#include "asm/pll_if.h"
#include "cf750gx.h"
#define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, \
"ppc-750gx-cpufreq", msg)
MODULE_AUTHOR("Kevin Diggs");
MODULE_DESCRIPTION("750GX Dual PLL cpufreq driver");
MODULE_LICENSE("GPL");
static const struct pll_750fgx __initdata pll_750fx ={
.min_ratio = 2,
.max_ratio = 20,
.min_core = 40,
.max_core = 80,
};
static const struct pll_750fgx __initdata pll_750gx = {
.min_ratio = 2,
.max_ratio = 20,
.min_core = 50,
.max_core = 100,
};
static unsigned int override_min_core=0;
static unsigned int override_max_core=0;
static unsigned int override_bus_freq=0;
static unsigned int freq_steps=0;
static unsigned int cf750gxvBusSpeed=0;
static unsigned int cf750gxvMinCore=0;
static unsigned int cf750gxvMaxCore=0;
struct cpufreq_frequency_table *cf750gxvFreqTable;
static int cf750gxTarget(struct cpufreq_policy *policy,
unsigned int target_freq, unsigned int relation)
{
unsigned int next_state = 0; /* Index into freq_table */
unsigned int next_perf_state = 0; /* Index into perf table */
//unsigned int i;
int result = 0;
unsigned int pll,new_pll;
unsigned int active_pll;
struct cpufreq_freqs freqs;
dprintk("cf750gxTarget() %d (%d)\n", target_freq, policy->cpu);
result = cpufreq_frequency_table_target(policy,
cf750gxvFreqTable,
target_freq,
relation, &next_state);
if (unlikely(result))
return -ENODEV;
pll=get_PLL();
active_pll=get_active_PLL(pll);
#ifdef CONFIG_HOTPLUG_CPU
/* cpufreq holds the hotplug lock, so we are safe from here on */
// cpus_and(online_policy_cpus, cpu_online_map, policy->cpus);
#else
// online_policy_cpus = policy->cpus;
#endif
next_perf_state = cf750gxvFreqTable[next_state].index;
if (cf750gxiPackState(get_PLL_ratio(active_pll,pll), get_PLL_range(
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
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(freq<600) instead of if(freq<60) 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
sysfs cpu entry
Hi, Can someone suggest where to add the code for a cpu (/sys/devices/system/cpu/cpu0) entry in sysfs? The 2.6.24 release has a sysfs.c file but it only seems to be used for 64-bit? Anyone know why? What kind of planetary disasters will I create if I allow it to be used in 32-bit as well? kevin P.S.: On an unrelated note, anyone know where to start looking for problems in pmac_zilog. My 8600 modem which worked fine in 2.4 is now essentially useless. Some problem with handshaking, I think. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
sysfs cpu entry
Hi, Can someone suggest where to add the code for a cpu (/sys/devices/system/cpu/cpu0) entry in sysfs? The 2.6.24 release has a sysfs.c file but it only seems to be used for 64-bit? Anyone know why? What kind of planetary disasters will I create if I allow it to be used in 32-bit as well? kevin P.S.: On an unrelated note, anyone know where to start looking for problems in pmac_zilog. My 8600 modem which worked fine in 2.4 is now essentially useless. Some problem with handshaking, I think. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: sysfs cpu entry
Kumar Gala wrote: What 32-bit chip are you looking to enable this for? - k I am working on some stuff for the 750GX kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
get_cycles()
H, Anyone know how to turn get_cycles() into an actual time in a module? ppc_tb_freq does not seem to be exported? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: get_cycles()
David Miller wrote: From: Kevin Diggs <[EMAIL PROTECTED]> Date: Sat, 26 Apr 2008 00:54:11 -0700 Anyone know how to turn get_cycles() into an actual time in a module? ppc_tb_freq does not seem to be exported? You should really be using ktime_t and associated interfaces. This looks pretty cool ... but I don't want to create a dependency on hrtimer. So ... How expensive would it be to export ppc_tb_freq? Or add a get_cycles_tb() function? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: get_cycles()
David Miller wrote: From: Kevin Diggs <[EMAIL PROTECTED]> Date: Sat, 26 Apr 2008 19:39:07 -0700 This looks pretty cool ... but I don't want to create a dependency on hrtimer. It doesn't create such a dependency. We use it unconditionally in the generic networking. Please don't use platform specific interfaces if you don't have to. You're be insulated from so many things. I'm working on a cpufreq driver for the 750GX so I don't think I have to worry about being to platform specific. Would a compile time configuration be a good idea (hrtimer or get_cycles() assisted timing)? In the 2.4 code I just used a timer 2 ticks in the future to be certain I did not go under the 100 us PLL lock delay. I was trying to see if I could cut the latency down. What about using OF? Isn't there a timebase property for the cpus? Thoughts? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
DPMS for Radeon 9600 in G5
Anyone one have any suggestions on how to get DPMS working for a Radeon 9600? Using a DVI cable? Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
mucking with cputable ...
Hi,
I'm trying to monkey with cputable. It is hanging after printing:
Preparing BATs
on the console (PowerMac 8600 with PowerLogix 750GX card, 2.6.24 YDL 4.0).
I am guessing I am doing this PTRRELOC() thing wrong? Can someone
explain what is going on here:
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
Up above both s and t needed reloccing? This is from identify_cpu().
Does this have something to do with data items in different sections
(i.e. initdata)?
I also welcome comments on where else the data I'm trying to graft into
cputable might go (i.e. cpu_freq driver).
Thanks!
kevin
--- cputable-old_c 2008-02-25 18:24:23.0 -0800
+++ cputable-new_c 2008-04-30 14:31:37.0 -0700
@@ -38,11 +38,13 @@
extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
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);
extern void __setup_cpu_ppc970MP(unsigned long offset, struct cpu_spec* spec);
@@ -70,8 +72,25 @@
PPC_FEATURE_HAS_ALTIVEC_COMP)
#define COMMON_USER_BOOKE (PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU | \
PPC_FEATURE_BOOKE)
+#ifdef CONFIG_PPC32
+static struct ppc_misc_750fgx __initdata ppc_misc_750fx={
+ .misc_cp=ppc_misc_cp_750fgx,
+ .min_ratio=2, /* min bus ratio */
+ .max_ratio=20, /* max bus ratio */
+ .min_core=40, /* min core frequency per spec */
+ .max_core=80, /* max core frequency per spec */
+};
+static struct ppc_misc_750fgx __initdata ppc_misc_750gx={
+ .misc_cp=ppc_misc_cp_750fgx,
+ .min_ratio=2, /* min bus ratio */
+ .max_ratio=20, /* max bus ratio */
+ .min_core=50, /* min core frequency per spec */
+ .max_core=100, /* max core frequency per spec */
+};
+#endif /* CONFIG_PPC32 */
+
static struct cpu_spec __initdata cpu_specs[] = {
#ifdef CONFIG_PPC64
{ /* Power3 */
.pvr_mask = 0x,
@@ -590,8 +609,9 @@
.icache_bsize = 32,
.dcache_bsize = 32,
.num_pmcs = 4,
.cpu_setup = __setup_cpu_750,
+ .misc = (void *) &ppc_misc_750fx,
.platform = "ppc750",
},
{ /* 750FX rev 2.0 must disable HID0[DPM] */
.pvr_mask = 0x,
@@ -602,8 +622,9 @@
.icache_bsize = 32,
.dcache_bsize = 32,
.num_pmcs = 4,
.cpu_setup = __setup_cpu_750,
+ .misc = (void *) &ppc_misc_750fx,
.platform = "ppc750",
},
{ /* 750FX (All revs except 2.0) */
.pvr_mask = 0x,
@@ -614,20 +635,48 @@
.icache_bsize = 32,
.dcache_bsize = 32,
.num_pmcs = 4,
.cpu_setup = __setup_cpu_750fx,
+ .misc = (void *) &ppc_misc_750fx,
.platform = "ppc750",
},
- { /* 750GX */
+ { /* 750GX rev 1.x */
.pvr_mask = 0x,
.pvr_value = 0x7002,
.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_750fx,
+ .cpu_setup = __setup_cpu_750gx,
+ .misc = (void *) &ppc_misc_750gx,
+ .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_feature
function calls from identify_cpu()
I added:
int __init iDoNothingUseful(struct cpu_spec *s,struct cpu_spec *t)
{
return s-t;
}
right before the definition of identify_cpu() in cputable.c and:
// (void) (*PTRRELOC(&iDoNothingUseful))(s,t);
(void) iDoNothingUseful(s,t);
right before the return s; in the match block and it will not boot? Can
someone please explain what might be going on?
Thanks!
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: function calls from identify_cpu()
Benjamin Herrenschmidt wrote:
On Fri, 2008-05-02 at 13:42 -0700, Kevin Diggs wrote:
I added:
int __init iDoNothingUseful(struct cpu_spec *s,struct cpu_spec *t)
{
return s-t;
}
right before the definition of identify_cpu() in cputable.c and:
// (void) (*PTRRELOC(&iDoNothingUseful))(s,t);
(void) iDoNothingUseful(s,t);
right before the return s; in the match block and it will not boot? Can
someone please explain what might be going on?
Why are you trying to muck around with that code in the first
place ? :-)
What are you trying to achieve ?
Cheers,
Ben.
The original intent was to find a way to add some of the PLL parameters
(min and max core frequencies, min and max bus ratios - FX 400 - 800, 2
- 20; GX 500 - 1000, 2 - 20). Initially it seemed like the place to put
them. To avoid kernel bloat I think I'll just put them in the init
routine of the driver. I'll have to redo the cpu detection (FX vs GX);
but I guess that is not that big of a deal.
But now it is about retaining what is left of my sanity. I took the
above code and added it to a GigE running the same installation (the
8600 installation was created by installing its disk in the GigE) and it
ran fine!?! ANY suggestions would be greatly appreciated. Something to
do with BootX? BootX is to old (1.2.4)? System needs an exorcism? I
screwed up something in the 750GX cpu_spec entry?
Both are running 2.6.24.
kevin
P.S.: I would still appreciate it if someone could explain why this line:
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
isn't:
*PTRRELOC((&cur_cpu_spec) = PTRRELOC(&the_cpu_spec);
Is the address &the_cpu_spec valid later in the kernel initialization?
Is it ... valid now?
___
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
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
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
__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
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
#include "linux/kernel.h"
#include
#include
#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
#include
#include "asm/time.h"
#include
#include
#include
#include
#include
#include
#include
#include
#include
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
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
+/**
+ * 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
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
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
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
[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&
[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 @@ + +http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []> + + + + PowerPC 750GX (and FX?) cpufreq driver guide + + + + Kevin +Diggs + + + + + + 1.0 + August 12, 2008 + Initial revision posted to linuxppc-dev + + + + + 2008 + Kevin Diggs + + + + +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. + + + +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 + + + +For more details see the file COPYING in the source +distribution of Linux. + + + + + This is the first release of this document coincident with submission of the + driver for inclusion in the kernel. + + + + + + + + Introduction + + This guide documents the cpufreq driver for the IBM PowerPC 750GX processor. + It "should" also work with the 750FX but has not been tested. + + + 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. + + + + + Major Components + + + 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]. + + + + The cpufreq driver consists of two main parts: + + + + + + cf750gx - the cpufreq driver module + + + + + + pll_if - a low level interface that encapsulates the details of dealing + with the PLL register + + + + + + cf750gx - The CPUFreq 750GX driver + + +cf750gx provides the standard entry points required of a cpufreq driver. They +are: + + + + + cf750gx_verify - verify + + + + + + cf750gx_target - target + + + + + + cf750gx_cpu_init - cpu init + + + + + + cf750gx_cpu_exit - cpu exit + + + + +These routines perform functions as required by the cpufreq subsystem. + + + +The driver functions in one of 2 modes: normal and minmax. In normal mode +it switches between the available frequencies as requested by the current +cpufreq subsystem governor. In minmax mode, it switches between the minimum +and maximum frequencies only. + + + Normal Mode + + In normal mode the driver switches between all valid frequencies under + control of the selected governor. The list of valid frequencies is + determined at startup based on the cpu model (FX or GX) and the determined + bus
[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
[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 () {
-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
+/**
+ * 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 comple
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 voi
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 accompl
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
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
[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
+#include "linux/kernel.h"
+#include
+#include
+#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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+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 bo
[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 @@ + +http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []> + + + + PowerPC 750GX (and FX?) cpufreq driver guide + + + + Kevin +Diggs + + + + + + 1.0 + August 12, 2008 + Initial revision posted to linuxppc-dev + + + + + 2008 + Kevin Diggs + + + + +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. + + + +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 + + + +For more details see the file COPYING in the source +distribution of Linux. + + + + + This is the first release of this document coincident with submission of the + driver for inclusion in the kernel. + + + + + + + + Introduction + + This guide documents the cpufreq driver for the IBM PowerPC 750GX processor. + It "should" also work with the 750FX but has not been tested. + + + 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. + + + + + Major Components + + + 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]. + + + + The cpufreq driver consists of two main parts: + + + + + + cf750gx - the cpufreq driver module + + + + + + pll_if - a low level interface that encapsulates the details of dealing + with the PLL register + + + + + + cf750gx - The CPUFreq 750GX driver + + +cf750gx provides the standard entry points required of a cpufreq driver. They +are: + + + + + cf750gx_verify - verify + + + + + + cf750gx_target - target + + + + + + cf750gx_cpu_init - cpu init + + + + + + cf750gx_cpu_exit - cpu exit + + + + +These routines perform functions as required by the cpufreq subsystem. + + + +The driver functions in one of 2 modes: normal and minmax. In normal mode +it switches between the available frequencies as requested by the current +cpufreq subsystem governor. In minmax mode, it switches between the minimum +and maximum frequencies only. + + + Normal Mode + + In normal mode the driver switches between all valid frequencies under + control of the selected governor. The list of valid frequen
[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
[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 () {
-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
+/**
+ * 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 comple
[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
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
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
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 # CONFIG_PPC_9
