* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Geert Uytterhoeven @ 2008-01-27 11:15 UTC (permalink / raw)
To: Andrew Morton, Geoff Levand
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
Cell Broadband Engine OSS Development, Antonino Daplas
In-Reply-To: <20080127021659.fb6c72a1.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1621 bytes --]
Hi Andrew,
On Sun, 27 Jan 2008, Andrew Morton wrote:
> > On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > On Sat, 26 Jan 2008, Andrew Morton wrote:
> > > > On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > > > Hare are the ps3av/fb patches for 2.6.25:
> > >
> > > I would have to say: it's a bit late to be submitting things of this nature
> > > for 2.6.25. Given the mess everyone has made of everything there's little
> > > chance that I'll be able to do a 2.6.24-mm1 so this stuff basically goes
> > > into mainline without public testing.
> >
> > I beg to disagree (of course :-)
> >
> > I posted these patches before, about 2 months ago. Unfortunately I didn't CC
> > you at that time, so they slipped under your radar.
> > But the patches did receive public testing even before that, when they entered
> > Geoff's ps3-linux.git tree.
>
> Should that git tree be in the -mm lineup?
That may be a good idea! Geoff?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Andrew Morton @ 2008-01-27 10:16 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, adaplas
In-Reply-To: <Pine.LNX.4.64.0801271041160.10193@vixen.sonytel.be>
> On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> Hi Andrew,
>
> On Sat, 26 Jan 2008, Andrew Morton wrote:
> > > On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > > Hare are the ps3av/fb patches for 2.6.25:
> >
> > I would have to say: it's a bit late to be submitting things of this nature
> > for 2.6.25. Given the mess everyone has made of everything there's little
> > chance that I'll be able to do a 2.6.24-mm1 so this stuff basically goes
> > into mainline without public testing.
>
> I beg to disagree (of course :-)
>
> I posted these patches before, about 2 months ago. Unfortunately I didn't CC
> you at that time, so they slipped under your radar.
> But the patches did receive public testing even before that, when they entered
> Geoff's ps3-linux.git tree.
>
Should that git tree be in the -mm lineup?
^ permalink raw reply
* Re: [patch 09/11] ps3fb: Round up video modes
From: Geert Uytterhoeven @ 2008-01-27 9:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, adaplas
In-Reply-To: <20080126220143.16c8f821.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2023 bytes --]
On Sat, 26 Jan 2008, Andrew Morton wrote:
> > On Fri, 25 Jan 2008 16:06:32 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > static int ps3fb_cmp_mode(const struct fb_videomode *vmode,
> > const struct fb_var_screeninfo *var)
> > {
> > - /* resolution + black border must match a native resolution */
> > - if (vmode->left_margin + vmode->xres + vmode->right_margin !=
> > - var->left_margin + var->xres + var->right_margin ||
> > - vmode->upper_margin + vmode->yres + vmode->lower_margin !=
> > - var->upper_margin + var->yres + var->lower_margin)
> > + long xres, yres, left_margin, right_margin, upper_margin, lower_margin;
> > + long dx, dy;
>
> I don't think these need to be longs? And they probably don't need to be
> signed either.
>
> If a switch to u32 improves the code any, it might be worth doing..
>
> All the typecasting which this patch adds makes me wonder if the choice
> of types requires a general revisit...
The problems are:
- Adding up the various fb_var_screeninfo.* timing fields (which are u32) may
cause overflows. That's why I use `long' (which is 64-bit on ppc64).
Perhaps I should change it to s64 for readability?
- If I make xres, yres, left_margin, right_margin, upper_margin, lower_margin
u32, I need more casts for calculating dx and dy. Probably u64 would be OK,
though.
- dx and dy are signed because they can be smaller than 0.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Geert Uytterhoeven @ 2008-01-27 9:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, adaplas
In-Reply-To: <20080126220139.5385f2c7.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1334 bytes --]
Hi Andrew,
On Sat, 26 Jan 2008, Andrew Morton wrote:
> > On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > Hare are the ps3av/fb patches for 2.6.25:
>
> I would have to say: it's a bit late to be submitting things of this nature
> for 2.6.25. Given the mess everyone has made of everything there's little
> chance that I'll be able to do a 2.6.24-mm1 so this stuff basically goes
> into mainline without public testing.
I beg to disagree (of course :-)
I posted these patches before, about 2 months ago. Unfortunately I didn't CC
you at that time, so they slipped under your radar.
But the patches did receive public testing even before that, when they entered
Geoff's ps3-linux.git tree.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [patch 04/11] ps3fb: Inline macros that are used only once
From: Geert Uytterhoeven @ 2008-01-27 9:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, adaplas
In-Reply-To: <20080126220133.eb99e5c4.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1080 bytes --]
On Sat, 26 Jan 2008, Andrew Morton wrote:
> > On Fri, 25 Jan 2008 16:06:27 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> >
> > ps3fb: inline the X_OFF(), Y_OFF(), WIDTH(), HEIGHT(), and VP_OFF() macros,
> > as they're used in one place only
>
> I think the term "open-code" would be more suitable here. "inlining" means
> "make it an inline function". I'll update the changelog.
You're right. Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Load Kernel 2.6 using U-boot on ML403
From: Yedu Jathavedan @ 2008-01-27 7:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Plaintext Version of Message --]
[-- Type: text/plain, Size: 6997 bytes --]
Hi,
/I have downloaded the 2.6 kernel from
/http://git.secretlab.ca/git/linux-2.6-virtex.git , installed &
compiled it. I used "make ARCH=ppc CROSS_COMPILE=ppc_4xx-
ml403_defconfig" to build the .config file. (As explained in
http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex)PROBLEM -
1)Downloaded(sourceforge.net) & compiled the U-boot 1.1.6 files to
get u-boot, u-boot.srec & u-boot.bin (I didn't find ml403 board config
for the uboot. So used ml300_config).
After this, I tried to convert the u-boot (README says that this is
an ELF file) into an ace file. But, it gave me the error saying unable
to read elf file. Is it because ML403 board is not supported or is it
possible that the u-boot image that I created is corrupted?
$ xmd -tcl genace.tcl -jprog -board ml403 -hw download.bit -elf
u-boot -ace uboot.ace
Xilinx EDK 9.1 Build EDK_J.19
Executing xmd script : $HOME/EDK/data/xmd/genace.tcl
#######################################################################
XMD GenACE utility. Generate SystemACE File from bit/elf/data Files
#######################################################################
Target Type not defined for Processor 1, Using default Target Type ppc_hw
GenACE Options:
Board : ml403
Jtag Devs : xcf32p xc4vfx12 xc95144xl
FPGA pos : 2
JPROG : true
HW File : download.bit
ACE File : uboot.ace
nCPUs : 1
Processor ppc_hw_1 Information
Debug opt : -debugdevice devicenr 2 cpunr 1
ELF files : u-boot
Start PC Address : 0xfff80000
############################################################
Converting Bitstream 'download.bit' to SVF file 'download.svf'
Executing 'impact -batch bit2svf.scr'
Copying download.svf File to uboot.svf File
############################################################
Converting ELF file 'u-boot' to SVF file 'u-boot.svf'
Error: E02 Failed to download ELF file
ERROR(1053): UNABLE to Read Elf File. The Elf File Maybe Corrupted
: u-boot
#$
-------------------------
PROBLEM -
2) Since generating ace files failed, I tried to search the net for an
u-boot ace file that could run on ML403 & found it at
http://88.191.24.164/docenligne/projets/samba/2006/linux-embarque-sur-ml-403/u-boot-ml403.ace/view
I copied this ace file (u-boot-ml403.ace) along with the kernel 2.6
image (uImage) onto my CF card & booted the board. After loading the
kernel, it fails to read the correct root device. I tried changing the
"bootargs" env variable root = /dev/xsysace/disc0/part2 rw to root =
/dev/xsysace2 rw & root = /dev/xsda2 rw.
But, it failed in both cases. (There was a previous post on
Problem2 a year ago & he solved it by giving root =/dev/xsysace2)
Environment size: 246/1020 bytes
#u-boot> setenv bootargs console=ttyS0,9600 root=/dev/xsysace2 rw
#u-boot> fatload ace 0 0x400000 uImage
reading uImage
952237 bytes read
#u-boot> bootm 0x400000
## Booting image at 00400000 ...
Image Name: Linux-2.6.24-rc3
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 952173 Bytes = 929.9 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
[ 0.000000] Linux version 2.6.24-rc3 (icdt@icdt05) (gcc version
4.0.0 (DENX ELDK 4.0 4.0.0)) #1 Fri Jan 25 21:23:54 PST 2008
[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 16384
[ 0.000000] Normal 16384 -> 16384
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 16384
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 16256
[ 0.000000] Kernel command line: console=ttyS0,9600 ip=off
root=/dev/xsysace root=/dev/xsysace2 rw
[ 0.000000] Xilinx INTC #0 at 0xD1000FC0 mapped to 0xFDFFEFC0
[ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
[ 0.000179] Console: colour dummy device 80x25
[ 0.000669] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.001431] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.015197] Memory: 62860k available (1452k kernel code, 496k data,
96k init, 0k highmem)
[ 0.204614] Mount-cache hash table entries: 512
[ 0.209345] net_namespace: 64 bytes
[ 0.213840] NET: Registered protocol family 16
[ 0.252576] NET: Registered protocol family 2
[ 0.288713] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.291229] TCP established hash table entries: 2048 (order: 2,
16384 bytes)
[ 0.291535] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.291709] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.291737] TCP reno registered
[ 0.301433] sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
[ 0.301509] Call Trace:
[ 0.301528] [c3c17e80] [c00084f4] show_stack+0x4c/0x174 (unreliable)
[ 0.301611] [c3c17eb0] [c00305e0] set_fail+0x50/0x68
[ 0.301678] [c3c17ed0] [c0030c68] sysctl_check_table+0x670/0x6bc
[ 0.301726] [c3c17f10] [c0030c7c] sysctl_check_table+0x684/0x6bc
[ 0.301771] [c3c17f50] [c001df28] register_sysctl_table+0x5c/0xac
[ 0.301832] [c3c17f70] [c01dca84] register_ppc_htab_sysctl+0x18/0x2c
[ 0.301897] [c3c17f80] [c01d6848] kernel_init+0xc8/0x284
[ 0.301938] [c3c17ff0] [c0004af8] kernel_thread+0x44/0x60
[ 0.307739] io scheduler noop registered
[ 0.307792] io scheduler anticipatory registered (default)
[ 0.307817] io scheduler deadline registered
[ 0.307967] io scheduler cfq registered
[ 0.364669] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports,
IRQ sharing disabled
[ 0.370815] serial8250.0: ttyS0 at MMIO 0xa0001003 (irq = 9) is a 16450
[ 0.370893] console [ttyS0] enabled
[ 3.286815] RAMDISK driver initialized: 16 RAM disks of 65536K size
1024 blocksize
[ 3.376997] tun: Universal TUN/TAP device driver, 1.6
[ 3.437161] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 3.512736] mice: PS/2 mouse device common for all mice
[ 3.574814] TCP cubic registered
[ 3.613145] NET: Registered protocol family 1
[ 3.665227] NET: Registered protocol family 17
[ 3.720647] VFS: Cannot open root device "xsysace2" or unknown-block(0,0)
[ 3.801333] Please append a correct "root=" boot option; here are
the available partitions:
[ 3.901354] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(0,0)
[ 4.000286] Rebooting in 180 seconds..
-------------------------
Can anyone help me with either one (or both) of the above problems? I
have pretty much run out of ideas. :(
Thanks & Regards,
Yedu
[-- Attachment #1.2: HTML Version of Message --]
[-- Type: text/html, Size: 8005 bytes --]
[-- Attachment #2.1: Type: multipart/alternative, Size: 0 bytes --]
[-- Attachment #2.2: Plaintext Version of Message --]
[-- Type: text/plain, Size: 429 bytes --]
Hi,
/ GOAL - To use the USB Host on ML403 in a PowerPC processor reference
system to store some data on a Thumb Drive./
/BACKGROUND - I downloaded the 2.6 kernel from
/http://git.secretlab.ca/git/linux-2.6-virtex.git , installed &
compiled it to get uImage & zImage.elf files. I used "make
ml403_defconfig" to build the .config file. (As explained in
http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex)
[-- Attachment #2.3: HTML Version of Message --]
[-- Type: text/html, Size: 693 bytes --]
^ permalink raw reply
* Re: [patch 09/11] ps3fb: Round up video modes
From: Andrew Morton @ 2008-01-27 6:01 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert.Uytterhoeven, linuxppc-dev, linux-fbdev-devel, cbe-oss-dev,
adaplas
In-Reply-To: <20080125153107.478948955@vixen.sonytel.be>
> On Fri, 25 Jan 2008 16:06:32 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> static int ps3fb_cmp_mode(const struct fb_videomode *vmode,
> const struct fb_var_screeninfo *var)
> {
> - /* resolution + black border must match a native resolution */
> - if (vmode->left_margin + vmode->xres + vmode->right_margin !=
> - var->left_margin + var->xres + var->right_margin ||
> - vmode->upper_margin + vmode->yres + vmode->lower_margin !=
> - var->upper_margin + var->yres + var->lower_margin)
> + long xres, yres, left_margin, right_margin, upper_margin, lower_margin;
> + long dx, dy;
I don't think these need to be longs? And they probably don't need to be
signed either.
If a switch to u32 improves the code any, it might be worth doing..
All the typecasting which this patch adds makes me wonder if the choice
of types requires a general revisit...
^ permalink raw reply
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Andrew Morton @ 2008-01-27 6:01 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, adaplas
In-Reply-To: <20080125150623.202631389@vixen.sonytel.be>
> On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> Hare are the ps3av/fb patches for 2.6.25:
I would have to say: it's a bit late to be submitting things of this nature
for 2.6.25. Given the mess everyone has made of everything there's little
chance that I'll be able to do a 2.6.24-mm1 so this stuff basically goes
into mainline without public testing.
I don't think many people care much about ps3 so whatever. But if it were
core code or a popular driver then I would probably slip this back to
2.6.26.
We haven't heard from Tony in a while so I guess I'm fbdev maintainer
again. Be afraid.
^ permalink raw reply
* Re: [patch 04/11] ps3fb: Inline macros that are used only once
From: Andrew Morton @ 2008-01-27 6:01 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert.Uytterhoeven, linuxppc-dev, linux-fbdev-devel, cbe-oss-dev,
adaplas
In-Reply-To: <20080125153107.177014292@vixen.sonytel.be>
> On Fri, 25 Jan 2008 16:06:27 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
>
> ps3fb: inline the X_OFF(), Y_OFF(), WIDTH(), HEIGHT(), and VP_OFF() macros,
> as they're used in one place only
>
I think the term "open-code" would be more suitable here. "inlining" means
"make it an inline function". I'll update the changelog.
> -#define X_OFF(i) (ps3fb_res[i].xoff) /* left/right margin (pixel) */
> -#define Y_OFF(i) (ps3fb_res[i].yoff) /* top/bottom margin (pixel) */
> -#define WIDTH(i) (ps3fb_res[i].xres) /* width of FB */
> -#define HEIGHT(i) (ps3fb_res[i].yres) /* height of FB */
> #define BPP 4 /* number of bytes per pixel */
>
> -/* Start of the virtual frame buffer (relative to fullscreen ) */
> -#define VP_OFF(i) ((WIDTH(i) * Y_OFF(i) + X_OFF(i)) * BPP)
> -
>
> static int ps3fb_mode;
> module_param(ps3fb_mode, int, 0);
> @@ -611,7 +604,10 @@ static int ps3fb_set_par(struct fb_info
>
> par->width = info->var.xres;
> par->height = info->var.yres;
> - offset = VP_OFF(i);
> +
> + /* Start of the virtual frame buffer (relative to fullscreen) */
> + offset = ps3fb_res[i].yoff * ddr_line_length + ps3fb_res[i].xoff * BPP;
> +
^ permalink raw reply
* Re: [PATCH] Fix powerpc vio_find_name to not use devices_subsys
From: Greg KH @ 2008-01-27 5:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel, sfr
In-Reply-To: <18331.54314.379281.960297@cargo.ozlabs.ibm.com>
On Sun, Jan 27, 2008 at 11:45:30AM +1100, Paul Mackerras wrote:
> This fixes vio_find_name() in arch/powerpc/kernel/vio.c, which is
> currently broken because it tries to use devices_subsys. That is bad
> for two reasons: (1) it's doing (or trying to do) a scan of all
> devices when it should only be scanning those on the vio bus, and
> (2) devices_subsys was an internal symbol of the device system code
> which was never meant for external use and has now gone away, and
> thus the kernel fails to compile on pSeries.
>
> The new version uses bus_find_device() on the vio bus (vio_bus_type).
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> Greg, do you want to send this to Linus or will I do that? Or do you
> have a better version? :)
I'll send it to him, with a minor change (I'm going to make this a core
function, as others also use the same functionality, no need for
everyone to re-invent the wheel all the time.
I also have some other patches to send him to fix up the fall-out of
these driver core changes :)
thanks,
greg k-h
^ permalink raw reply
* Re: Patches added to for-2.6.25/master branches of powerpc.git
From: Michael Ellerman @ 2008-01-27 0:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18330.53318.857148.409675@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]
On Sat, 2008-01-26 at 17:16 +1100, Paul Mackerras wrote:
> This includes commits pulled from Josh Boyer, Kumar Gala, Grant
> Likely, and Olof Johansson. I reverted the "Fake NUMA emulation for
> PowerPC" commit because it changed behaviour even when the fake numa
> command-line option wasn't given.
>
> I'll be asking Linus to pull within the next few days, so please
> remind me about anything else that should go in 2.6.25.
Can you grab these four assuming there's no objections in the meantime.
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=16430
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=16433
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=16434
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=16437
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Patches added to for-2.6.25/master branches of powerpc.git
From: Jon Smirl @ 2008-01-27 0:48 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <fa686aa40801261509o2f6fd195h2f2662e67c022ec@mail.gmail.com>
On 1/26/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> Grant Likely (6):
> [POWERPC] mpc52xx: clean up Kconfig
> [POWERPC] mpc5200: normalize compatible property bindings
> [POWERPC] mpc5200: make dts files conform to generic names
> recommended practice
> [POWERPC] Efika: prune fixups and make them more carefull
> [POWERPC] Add common clock setting routine mpc52xx_psc_set_clkdiv()
> [POWERPC] mpc52xx_psc_spi device driver must not touch port_config and cdm
Does this fix these warnings...
CC drivers/spi/mpc52xx_psc_spi.o
drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_activate_cs':
drivers/spi/mpc52xx_psc_spi.c:110: warning: passing argument 1 of
'in_be16' from incompatible pointer type
drivers/spi/mpc52xx_psc_spi.c:116: warning: passing argument 1 of
'out_be16' from incompatible pointer type
drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_port_config':
drivers/spi/mpc52xx_psc_spi.c:417: warning: passing argument 1 of
'out_be16' from incompatible pointer type
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] Fix powerpc vio_find_name to not use devices_subsys
From: Paul Mackerras @ 2008-01-27 0:45 UTC (permalink / raw)
To: Greg KH, linux-kernel, linuxppc-dev; +Cc: sfr
This fixes vio_find_name() in arch/powerpc/kernel/vio.c, which is
currently broken because it tries to use devices_subsys. That is bad
for two reasons: (1) it's doing (or trying to do) a scan of all
devices when it should only be scanning those on the vio bus, and
(2) devices_subsys was an internal symbol of the device system code
which was never meant for external use and has now gone away, and
thus the kernel fails to compile on pSeries.
The new version uses bus_find_device() on the vio bus (vio_bus_type).
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Greg, do you want to send this to Linus or will I do that? Or do you
have a better version? :)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 19a5656..b179b7e 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -37,8 +37,6 @@
#include <asm/iseries/hv_call_xm.h>
#include <asm/iseries/iommu.h>
-extern struct kset devices_subsys; /* needed for vio_find_name() */
-
static struct bus_type vio_bus_type;
static struct vio_dev vio_bus_device = { /* fake "parent" device */
@@ -361,19 +359,23 @@ EXPORT_SYMBOL(vio_get_attribute);
#ifdef CONFIG_PPC_PSERIES
/* vio_find_name() - internal because only vio.c knows how we formatted the
* kobject name
- * XXX once vio_bus_type.devices is actually used as a kset in
- * drivers/base/bus.c, this function should be removed in favor of
- * "device_find(kobj_name, &vio_bus_type)"
*/
-static struct vio_dev *vio_find_name(const char *kobj_name)
+static int name_cmp(struct device *dev, void *data)
+{
+ const char *name = data;
+
+ return !strcmp(name, dev->bus_id);
+}
+
+static struct vio_dev *vio_find_name(const char *name)
{
- struct kobject *found;
+ struct device *found;
- found = kset_find_obj(&devices_subsys, kobj_name);
+ found = bus_find_device(&vio_bus_type, NULL, (void *)name, name_cmp);
if (!found)
return NULL;
- return to_vio_dev(container_of(found, struct device, kobj));
+ return to_vio_dev(found);
}
/**
^ permalink raw reply related
* Re: Patches added to for-2.6.25/master branches of powerpc.git
From: Grant Likely @ 2008-01-26 23:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18330.53318.857148.409675@cargo.ozlabs.ibm.com>
Paul, please pull the following mpc52xx changes.
Also, I'd like to have the following patch picked up, but I'm a bit
nervous about it. Kumar has said it looks good, but I'm still not
100% sure about eliminating the KBUILD_IMAGE and BOOTIMAGE variables.
I *think* it's safe, but I'm not a build system expert.
http://patchwork.ozlabs.org/linuxppc/patch?person=486&id=16264
Cheers,
g.
The following changes since commit 55852bed57a97b08ab56028f1054d48d45de3aec:
Paul Mackerras (1):
Revert "[POWERPC] Fake NUMA emulation for PowerPC"
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.25
Grant Likely (6):
[POWERPC] mpc52xx: clean up Kconfig
[POWERPC] mpc5200: normalize compatible property bindings
[POWERPC] mpc5200: make dts files conform to generic names
recommended practice
[POWERPC] Efika: prune fixups and make them more carefull
[POWERPC] Add common clock setting routine mpc52xx_psc_set_clkdiv()
[POWERPC] mpc52xx_psc_spi device driver must not touch port_config and cdm
Paul Gortmaker (1):
[POWERPC] mpc5200: add #address-cells and #size-cells to soc node.
arch/powerpc/boot/dts/cm5200.dts | 60 +++++------
arch/powerpc/boot/dts/lite5200.dts | 96 +++++++----------
arch/powerpc/boot/dts/lite5200b.dts | 93 +++++++---------
arch/powerpc/boot/dts/motionpro.dts | 68 +++++-------
arch/powerpc/boot/dts/tqm5200.dts | 45 ++++-----
arch/powerpc/boot/serial.c | 2 +-
arch/powerpc/kernel/prom_init.c | 149 ++++++++++++++------------
arch/powerpc/platforms/52xx/Kconfig | 41 +++-----
arch/powerpc/platforms/52xx/efika.c | 3 +
arch/powerpc/platforms/52xx/lite5200.c | 28 ++++--
arch/powerpc/platforms/52xx/lite5200_pm.c | 9 ++-
arch/powerpc/platforms/52xx/mpc5200_simple.c | 6 +-
arch/powerpc/platforms/52xx/mpc52xx_common.c | 117 ++++++++++++++++-----
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 10 ++-
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 16 +++-
arch/powerpc/platforms/52xx/mpc52xx_pm.c | 9 ++-
arch/powerpc/sysdev/bestcomm/bestcomm.c | 16 ++-
arch/ppc/syslib/mpc52xx_setup.c | 36 ++++++
drivers/ata/pata_mpc52xx.c | 6 +-
drivers/net/fec_mpc52xx.c | 6 +-
drivers/net/fec_mpc52xx_phy.c | 8 +-
drivers/serial/mpc52xx_uart.c | 4 +-
drivers/spi/mpc52xx_psc_spi.c | 82 +-------------
drivers/usb/host/ohci-ppc-of.c | 2 +
include/asm-powerpc/mpc52xx.h | 9 +-
25 files changed, 478 insertions(+), 443 deletions(-)
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [BUILD FAILURE]2.6.24-git{1,2} kernel powerpc linkage failure
From: Greg KH @ 2008-01-26 20:45 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: LKML, linuxppc-dev, Badari Pulavarty, Andrew Morton,
Linus Torvalds
In-Reply-To: <479B3453.3030105@linux.vnet.ibm.com>
On Sat, Jan 26, 2008 at 06:53:31PM +0530, Kamalesh Babulal wrote:
> Hi,
>
> The 2.6.24-git2 kernel build fails on the power boxes with following build failure
>
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/powerpc/kernel/built-in.o: In function `fphalf':
> arch/powerpc/kernel/vector.S:(.toc+0x1428): undefined reference to `devices_subsys'
> make: *** [.tmp_vmlinux1] Error 1
>
> This built-failure was seen in the mm broken-out-2007-11-06-02-32, I have tested
> the patch posted to lkml at http://lkml.org/lkml/2007/11/6/208 fixes this issue.
And that patch is wrong, see my post on lkml about this yesterday.
Paul is working on a "correct" patch, and if I get some time this
afternoon, I'll do one too.
thanks,
greg k-h
^ permalink raw reply
* Re: Patches added to for-2.6.25/master branches of powerpc.git
From: Josh Boyer @ 2008-01-26 17:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18330.53318.857148.409675@cargo.ozlabs.ibm.com>
On Sat, 26 Jan 2008 17:16:38 +1100
Paul Mackerras <paulus@samba.org> wrote:
> This includes commits pulled from Josh Boyer, Kumar Gala, Grant
> Likely, and Olof Johansson. I reverted the "Fake NUMA emulation for
> PowerPC" commit because it changed behaviour even when the fake numa
> command-line option wasn't given.
>
> I'll be asking Linus to pull within the next few days, so please
> remind me about anything else that should go in 2.6.25.
I have a couple patches that depend on the netdev and USB
trees being merged first. And I'm sure we'll have some bug fix patches
at some point to deal with the clash-o-git trees that seems to be
coming.
josh
^ permalink raw reply
* Re: [PATCH 063/196] kset: convert /sys/devices to use kset_create
From: Olof Johansson @ 2008-01-26 17:36 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, Kay Sievers, torvalds, linux-kernel
In-Reply-To: <20080126052454.GA27403@suse.de>
On Fri, Jan 25, 2008 at 09:24:54PM -0800, Greg KH wrote:
> On Fri, Jan 25, 2008 at 09:40:55PM -0600, Olof Johansson wrote:
> > On Thu, Jan 24, 2008 at 11:10:01PM -0800, Greg Kroah-Hartman wrote:
> > > Dynamically create the kset instead of declaring it statically. We also
> > > rename devices_subsys to devices_kset to catch all users of the
> > > variable.
> >
> > Guess what, you broke powerpc again!
>
> I did this ON PURPOSE!!!
>
> The linux-kernel archives hold the details, and I was told by the PPC64
> IBM people that they would fix this properly for 2.6.25, and not to hold
> back on my changes. This has been known for many months now.
Yeah, my bad. :( I thought this was new, but it was just not exposed by
my scripts because of the EHEA build errors (they were actual compile
errors, while this was a link error, so it never go this far). That's
why I didn't see it in -rc8-mm1 and thought it was new.
> > -extern struct kset devices_subsys; /* needed for vio_find_name() */
> > +extern struct kset *devices_kset; /* needed for vio_find_name() */
>
> No, this just papers over the real problem here. For some reason, the
> vio code thinks it is acceptable to walk the whole device tree and match
> by a name and just assume that they got the correct device. You call
> this "enterprise grade"? :)
>
> You need to just put your device on a real bus, and then just walk the
> bus. That's the ONLY way you can guarantee the proper name will return
> what you want, and you get the pointer that you really think you are
> getting.
Hmm, they are already on a bus. Odd, must be done like this for legacy
reasons.
[...]
> So no, I'm going to leave the build broken for this code, because that
> is what it really is.
>
> Please fix it correctly.
Alright, I'll leave that to people who care about vio and can test the
proper fix. After a quick glance it looks like it should be easy to use
bus_find_device() for it instead.
-Olof
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Josh Boyer @ 2008-01-26 16:22 UTC (permalink / raw)
To: Zoltan HERPAI; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <479AF8C5.6030404@uid0.hu>
On Sat, 26 Jan 2008 10:09:25 +0100
Zoltan HERPAI <wigyori@uid0.hu> wrote:
> Kumar Gala wrote:
> > 4xx:
> > EBONY
> >
> I have an Ebony at hand, so if no one takes it, I'll give it a try to
> port it over.
It's ported. It was the first 4xx board to be ported. Thanks for
offering though!
josh
^ permalink raw reply
* Re: [PATCH] FIXED_MII_100_FDX
From: Kumar Gala @ 2008-01-26 15:40 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev list, Jeff Garzik, netdev
In-Reply-To: <479AD93D.30202@pikatech.com>
On Jan 26, 2008, at 12:54 AM, Sean MacLennan wrote:
> On the last git pull, FIXED_MII_100_FDX was removed from the phy
> Kconfig, but the Kconfig for CPMAC still tried to select it.
>
> Cheers,
> Sean
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> ---
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 9af05a2..297a4b5 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -1710,7 +1710,6 @@ config CPMAC
> depends on NET_ETHERNET && EXPERIMENTAL && AR7
> select PHYLIB
> select FIXED_PHY
> - select FIXED_MII_100_FDX
> help
> TI AR7 CPMAC Ethernet support
This patch isn't sufficient. AntonV has posted a proper fix that we
need Jeff to pick up.
http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050330.html
- k
^ permalink raw reply
* Re: Patches added to for-2.6.25/master branches of powerpc.git
From: Kumar Gala @ 2008-01-26 15:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18330.53318.857148.409675@cargo.ozlabs.ibm.com>
On Jan 26, 2008, at 12:16 AM, Paul Mackerras wrote:
> This includes commits pulled from Josh Boyer, Kumar Gala, Grant
> Likely, and Olof Johansson. I reverted the "Fake NUMA emulation for
> PowerPC" commit because it changed behaviour even when the fake numa
> command-line option wasn't given.
>
> I'll be asking Linus to pull within the next few days, so please
> remind me about anything else that should go in 2.6.25.
>
> Paul.
I've got a bunch of patches queued up in my tree that I'll ask you to
pull in the next day or so.
- k
^ permalink raw reply
* Re: [PATCH][ppc] logical/bitand typo in powerpc/boot/4xx.c
From: Stefan Roese @ 2008-01-26 13:37 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Roel Kluin, lkml
In-Reply-To: <20080123191704.2d74073a@zod.rchland.ibm.com>
On Thursday 24 January 2008, Josh Boyer wrote:
> On Wed, 23 Jan 2008 23:37:33 +0100
>
> Roel Kluin <12o3l@tiscali.nl> wrote:
> > logical/bitand typo
> >
> > Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
> > ---
> > diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
> > index ebf9e21..dcfb459 100644
> > --- a/arch/powerpc/boot/4xx.c
> > +++ b/arch/powerpc/boot/4xx.c
> > @@ -104,7 +104,7 @@ void ibm4xx_denali_fixup_memsize(void)
> > val = DDR_GET_VAL(val, DDR_CS_MAP, DDR_CS_MAP_SHIFT);
> > cs = 0;
> > while (val) {
> > - if (val && 0x1)
> > + if (val & 0x1)
> > cs++;
> > val = val >> 1;
> > }
>
> Hm, good catch.
>
> Stefan, have you had problems with this code at all?
I'm not using the bootwrapper on a 4xx with Denali core.
Best regards,
Stefan
^ permalink raw reply
* [BUILD FAILURE]2.6.24-git{1,2} kernel powerpc linkage failure
From: Kamalesh Babulal @ 2008-01-26 13:23 UTC (permalink / raw)
To: LKML, linuxppc-dev, Linus Torvalds, Andrew Morton, Greg KH,
Andy Whitcroft, Badari Pulavarty
Hi,
The 2.6.24-git2 kernel build fails on the power boxes with following build failure
LD init/built-in.o
LD .tmp_vmlinux1
arch/powerpc/kernel/built-in.o: In function `fphalf':
arch/powerpc/kernel/vector.S:(.toc+0x1428): undefined reference to `devices_subsys'
make: *** [.tmp_vmlinux1] Error 1
This built-failure was seen in the mm broken-out-2007-11-06-02-32, I have tested
the patch posted to lkml at http://lkml.org/lkml/2007/11/6/208 fixes this issue.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* [PATCH] windfarm: add PowerMac 12,1 support
From: Étienne Bersac @ 2008-01-26 11:55 UTC (permalink / raw)
To: linuxppc-dev
From: Étienne Bersac <bersace@gmail.com>
Implement a new driver named windfarm_pm121 which drive fans on PowerMac
12,1 machine : iMac G5 iSight (rev C) 17" and 20". It's based on
windfarm_pm81 driver from Benjamin Herrenschmidt.
Signed-off-by: Étienne Bersac <bersace@gmail.com>
---
Implement fan control for PowerMac 12,1 machines. This needs update to
windfarm_lm75 and windfarm_max6690 sensors drivers in order to properly
match sensors by their location. The code is based on windfarm_pm81
driver, adapted to the complexity of PowerMac 12,1 : 4 system control
loops instead of one, per-control target correction and per-model
control rubber-banding.
All the data are copied from Darwin 8.10 AppleMacRISC4PE-185.0.0 module
as well as correction formula.
diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index 3673dd2..4c048b3 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -667,6 +667,7 @@ CONFIG_WINDFARM=y
CONFIG_WINDFARM_PM81=y
CONFIG_WINDFARM_PM91=y
CONFIG_WINDFARM_PM112=y
+CONFIG_WINDFARM_PM121=y
# CONFIG_PMAC_RACKMETER is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 77f50b6..2d028e6 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -234,6 +234,14 @@ config WINDFARM_PM112
which are the recent dual and quad G5 machines using the
970MP dual-core processor.
+config WINDFARM_PM121
+ tristate "Support for thermal management on PowerMac12,1"
+ depends on WINDFARM && I2C && PMAC_SMU
+ select I2C_POWERMAC
+ help
+ This driver provides thermal control for the PowerMac12,1
+ which is the iMac G5 (iSight) 970MP
+
config ANSLCD
tristate "Support for ANS LCD display"
depends on ADB_CUDA && PPC_PMAC
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index 2dfc3f4..e3132ef 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -42,4 +42,9 @@ obj-$(CONFIG_WINDFARM_PM112) += windfarm_pm112.o windfarm_smu_sat.o \
windfarm_smu_sensors.o \
windfarm_max6690_sensor.o \
windfarm_lm75_sensor.o windfarm_pid.o
+obj-$(CONFIG_WINDFARM_PM121) += windfarm_pm121.o windfarm_smu_sat.o \
+ windfarm_smu_controls.o \
+ windfarm_smu_sensors.o \
+ windfarm_max6690_sensor.o \
+ windfarm_lm75_sensor.o windfarm_pid.o
obj-$(CONFIG_PMAC_RACKMETER) += rack-meter.o
diff --git a/drivers/macintosh/windfarm_lm75_sensor.c b/drivers/macintosh/windfarm_lm75_sensor.c
index 7e10c3a..b92b959 100644
--- a/drivers/macintosh/windfarm_lm75_sensor.c
+++ b/drivers/macintosh/windfarm_lm75_sensor.c
@@ -127,6 +127,12 @@ static struct wf_lm75_sensor *wf_lm75_create(struct i2c_adapter *adapter,
*/
if (!strcmp(loc, "Hard drive") || !strcmp(loc, "DRIVE BAY"))
lm->sens.name = "hd-temp";
+ else if (!strcmp(loc, "Incoming Air Temp"))
+ lm->sens.name = "incoming-air-temp";
+ else if (!strcmp(loc, "ODD Temp"))
+ lm->sens.name = "optical-drive-temp";
+ else if (!strcmp(loc, "HD Temp"))
+ lm->sens.name = "hard-drive-temp";
else
goto fail;
diff --git a/drivers/macintosh/windfarm_max6690_sensor.c b/drivers/macintosh/windfarm_max6690_sensor.c
index 5f03aab..e207a90 100644
--- a/drivers/macintosh/windfarm_max6690_sensor.c
+++ b/drivers/macintosh/windfarm_max6690_sensor.c
@@ -77,18 +77,28 @@ static struct wf_sensor_ops wf_max6690_ops = {
.owner = THIS_MODULE,
};
-static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr)
+static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr,
+ const char *loc)
{
struct wf_6690_sensor *max;
- char *name = "backside-temp";
+ char *name;
max = kzalloc(sizeof(struct wf_6690_sensor), GFP_KERNEL);
if (max == NULL) {
printk(KERN_ERR "windfarm: Couldn't create MAX6690 sensor %s: "
- "no memory\n", name);
+ "no memory\n", loc);
return;
}
+ if (!strcmp(loc, "BACKSIDE"))
+ name = "backside-temp";
+ else if (!strcmp(loc, "NB Ambient"))
+ name = "north-bridge-temp";
+ else if (!strcmp(loc, "GPU Ambient"))
+ name = "gpu-temp";
+ else
+ goto fail;
+
max->sens.ops = &wf_max6690_ops;
max->sens.name = name;
max->i2c.addr = addr >> 1;
@@ -138,9 +148,7 @@ static int wf_max6690_attach(struct i2c_adapter *adapter)
if (loc == NULL || addr == 0)
continue;
printk("found max6690, loc=%s addr=0x%02x\n", loc, addr);
- if (strcmp(loc, "BACKSIDE"))
- continue;
- wf_max6690_create(adapter, addr);
+ wf_max6690_create(adapter, addr, loc);
}
return 0;
diff --git a/drivers/macintosh/windfarm_pm121.c b/drivers/macintosh/windfarm_pm121.c
new file mode 100644
index 0000000..5276156
--- /dev/null
+++ b/drivers/macintosh/windfarm_pm121.c
@@ -0,0 +1,1040 @@
+/*
+ * Windfarm PowerMac thermal control. iMac G5 iSight
+ *
+ * (c) Copyright 2007 Étienne Bersac <bersace@gmail.com>
+ *
+ * Bits & pieces from windfarm_pm81.c by (c) Copyright 2005 Benjamin
+ * Herrenschmidt, IBM Corp. <benh@kernel.crashing.org>
+ *
+ * Released under the term of the GNU GPL v2.
+ *
+ *
+ *
+ * PowerMac12,1
+ * ============
+ *
+ *
+ * The algorithm used is the PID control algorithm, used the same way
+ * the published Darwin code does, using the same values that are
+ * present in the Darwin 8.10 snapshot property lists (note however
+ * that none of the code has been re-used, it's a complete
+ * re-implementation
+ *
+ * There is two models using PowerMac12,1. Model 2 is iMac G5 iSight
+ * 17" while Model 3 is iMac G5 20". They do have both the same
+ * controls with a tiny difference. The control-ids of hard-drive-fan
+ * and cpu-fan is swapped.
+ *
+ *
+ * Target Correction :
+ *
+ * controls have a target correction calculated as :
+ *
+ * new_min = ((((average_power * slope) >> 16) + offset) >> 16) + min_value
+ * new_value = max(new_value, max(new_min, 0))
+ *
+ * OD Fan control correction.
+ *
+ * # model_id: 2
+ * offset : -19563152
+ * slope : 1956315
+ *
+ * # model_id: 3
+ * offset : -15650652
+ * slope : 1565065
+ *
+ * HD Fan control correction.
+ *
+ * # model_id: 2
+ * offset : -15650652
+ * slope : 1565065
+ *
+ * # model_id: 3
+ * offset : -19563152
+ * slope : 1956315
+ *
+ * CPU Fan control correction.
+ *
+ * # model_id: 2
+ * offset : -25431900
+ * slope : 2543190
+ *
+ * # model_id: 3
+ * offset : -15650652
+ * slope : 1565065
+ *
+ *
+ * Target rubber-banding :
+ *
+ * Some controls have a target correction which depends on another
+ * control value. The correction is computed in the following way :
+ *
+ * new_min = ref_value * slope + offset
+ *
+ * ref_value is the value of the reference control. If new_min is
+ * greater than 0, then we correct the target value using :
+ *
+ * new_target = max (new_target, new_min >> 16)
+ *
+ *
+ * # model_id : 2
+ * control : cpu-fan
+ * ref : optical-drive-fan
+ * offset : -15650652
+ * slope : 1565065
+ *
+ * # model_id : 3
+ * control : optical-drive-fan
+ * ref : hard-drive-fan
+ * offset : -32768000
+ * slope : 65536
+ *
+ *
+ * In order to have the moste efficient correction with those
+ * dependencies, we must trigger HD loop before OD loop before CPU
+ * loop.
+ *
+ *
+ * The various control loops found in Darwin config file are:
+ *
+ * HD Fan control loop.
+ *
+ * # model_id: 2
+ * control : hard-drive-fan
+ * sensor : hard-drive-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x002D70A3
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x370000
+ * Interval = 5s
+ *
+ * # model_id: 3
+ * control : hard-drive-fan
+ * sensor : hard-drive-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x002170A3
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x370000
+ * Interval = 5s
+ *
+ * OD Fan control loop.
+ *
+ * # model_id: 2
+ * control : optical-drive-fan
+ * sensor : optical-drive-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x001FAE14
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x320000
+ * Interval = 5s
+ *
+ * # model_id: 3
+ * control : optical-drive-fan
+ * sensor : optical-drive-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x001FAE14
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x320000
+ * Interval = 5s
+ *
+ * GPU Fan control loop.
+ *
+ * # model_id: 2
+ * control : hard-drive-fan
+ * sensor : gpu-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x002A6666
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x5A0000
+ * Interval = 5s
+ *
+ * # model_id: 3
+ * control : cpu-fan
+ * sensor : gpu-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x0010CCCC
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x500000
+ * Interval = 5s
+ *
+ * KODIAK (aka northbridge) Fan control loop.
+ *
+ * # model_id: 2
+ * control : optical-drive-fan
+ * sensor : north-bridge-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x003BD70A
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x550000
+ * Interval = 5s
+ *
+ * # model_id: 3
+ * control : hard-drive-fan
+ * sensor : north-bridge-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x0030F5C2
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x550000
+ * Interval = 5s
+ *
+ * CPU Fan control loop.
+ *
+ * control : cpu-fan
+ * sensors : cpu-temp, cpu-power
+ * PID params : from SDB partition
+ *
+ *
+ * CPU Slew control loop.
+ *
+ * control : cpufreq-clamp
+ * sensor : cpu-temp
+ *
+ */
+
+#undef DEBUG
+
+#include <linux/types.h>
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/spinlock.h>
+#include <linux/wait.h>
+#include <linux/kmod.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <asm/prom.h>
+#include <asm/machdep.h>
+#include <asm/io.h>
+#include <asm/system.h>
+#include <asm/sections.h>
+#include <asm/smu.h>
+
+#include "windfarm.h"
+#include "windfarm_pid.h"
+
+#define VERSION "0.3"
+
+static int pm121_mach_model; /* machine model id */
+
+/* Controls & sensors */
+static struct wf_sensor *sensor_cpu_power;
+static struct wf_sensor *sensor_cpu_temp;
+static struct wf_sensor *sensor_cpu_voltage;
+static struct wf_sensor *sensor_cpu_current;
+static struct wf_sensor *sensor_gpu_temp;
+static struct wf_sensor *sensor_north_bridge_temp;
+static struct wf_sensor *sensor_hard_drive_temp;
+static struct wf_sensor *sensor_optical_drive_temp;
+static struct wf_sensor *sensor_incoming_air_temp; /* unused ! */
+
+enum {
+ FAN_CPU,
+ FAN_HD,
+ FAN_OD,
+ CPUFREQ,
+ N_CONTROLS
+};
+static struct wf_control *controls[N_CONTROLS] = {};
+
+/* Set to kick the control loop into life */
+static int pm121_all_controls_ok, pm121_all_sensors_ok, pm121_started;
+
+enum {
+ FAILURE_FAN = 1 << 0,
+ FAILURE_SENSOR = 1 << 1,
+ FAILURE_OVERTEMP = 1 << 2
+};
+
+/* All sys loops. Note the HD before the OD loop in order to have it
+ run before. */
+enum {
+ LOOP_GPU, /* control = hd or cpu, but luckily,
+ it doesn't matter */
+ LOOP_HD, /* control = hd */
+ LOOP_KODIAK, /* control = hd or od */
+ LOOP_OD, /* control = od */
+ N_LOOPS
+};
+
+static const char *loop_names[N_LOOPS] = {
+ "GPU",
+ "HD",
+ "KODIAK",
+ "OD",
+};
+
+#define PM121_NUM_CONFIGS 2
+
+static unsigned int pm121_failure_state;
+static int pm121_readjust, pm121_skipping;
+static s32 average_power;
+
+struct pm121_correction {
+ int offset;
+ int slope;
+};
+
+static struct pm121_correction corrections[N_CONTROLS][PM121_NUM_CONFIGS] = {
+ /* FAN_OD */
+ {
+ /* MODEL 2 */
+ { .offset = -19563152,
+ .slope = 1956315
+ },
+ /* MODEL 3 */
+ { .offset = -15650652,
+ .slope = 1565065
+ },
+ },
+ /* FAN_HD */
+ {
+ /* MODEL 2 */
+ { .offset = -15650652,
+ .slope = 1565065
+ },
+ /* MODEL 3 */
+ { .offset = -19563152,
+ .slope = 1956315
+ },
+ },
+ /* FAN_CPU */
+ {
+ /* MODEL 2 */
+ { .offset = -25431900,
+ .slope = 2543190
+ },
+ /* MODEL 3 */
+ { .offset = -15650652,
+ .slope = 1565065
+ },
+ },
+ /* CPUFREQ has no correction (and is not implemented at all) */
+};
+
+struct pm121_connection {
+ unsigned int control_id;
+ unsigned int ref_id;
+ struct pm121_correction correction;
+};
+
+static struct pm121_connection pm121_connections[] = {
+ /* MODEL 2 */
+ { .control_id = FAN_CPU,
+ .ref_id = FAN_OD,
+ { .offset = -32768000,
+ .slope = 65536
+ }
+ },
+ /* MODEL 3 */
+ { .control_id = FAN_OD,
+ .ref_id = FAN_HD,
+ { .offset = -32768000,
+ .slope = 65536
+ }
+ },
+};
+
+/* pointer to the current model connection */
+static struct pm121_connection *pm121_connection;
+
+/*
+ * ****** System Fans Control Loop ******
+ *
+ */
+
+/* Since each loop handles only one control and we want to avoid
+ * writing virtual control, we store the control correction with the
+ * loop params. Some data are not set, there are common to all loop
+ * and thus, hardcoded.
+ */
+struct pm121_sys_param {
+ /* purely informative since we use mach_model-2 as index */
+ int model_id;
+ struct wf_sensor **sensor; /* use sensor_id instead ? */
+ s32 gp, itarget;
+ unsigned int control_id;
+};
+
+static struct pm121_sys_param
+pm121_sys_all_params[N_LOOPS][PM121_NUM_CONFIGS] = {
+ /* GPU Fan control loop */
+ {
+ { .model_id = 2,
+ .sensor = &sensor_gpu_temp,
+ .gp = 0x002A6666,
+ .itarget = 0x5A0000,
+ .control_id = FAN_HD,
+ },
+ { .model_id = 3,
+ .sensor = &sensor_gpu_temp,
+ .gp = 0x0010CCCC,
+ .itarget = 0x500000,
+ .control_id = FAN_CPU,
+ },
+ },
+ /* HD Fan control loop */
+ {
+ { .model_id = 2,
+ .sensor = &sensor_hard_drive_temp,
+ .gp = 0x002D70A3,
+ .itarget = 0x370000,
+ .control_id = FAN_HD,
+ },
+ { .model_id = 3,
+ .sensor = &sensor_hard_drive_temp,
+ .gp = 0x002170A3,
+ .itarget = 0x370000,
+ .control_id = FAN_HD,
+ },
+ },
+ /* KODIAK Fan control loop */
+ {
+ { .model_id = 2,
+ .sensor = &sensor_north_bridge_temp,
+ .gp = 0x003BD70A,
+ .itarget = 0x550000,
+ .control_id = FAN_OD,
+ },
+ { .model_id = 3,
+ .sensor = &sensor_north_bridge_temp,
+ .gp = 0x0030F5C2,
+ .itarget = 0x550000,
+ .control_id = FAN_HD,
+ },
+ },
+ /* OD Fan control loop */
+ {
+ { .model_id = 2,
+ .sensor = &sensor_optical_drive_temp,
+ .gp = 0x001FAE14,
+ .itarget = 0x320000,
+ .control_id = FAN_OD,
+ },
+ { .model_id = 3,
+ .sensor = &sensor_optical_drive_temp,
+ .gp = 0x001FAE14,
+ .itarget = 0x320000,
+ .control_id = FAN_OD,
+ },
+ },
+};
+
+/* the hardcoded values */
+#define PM121_SYS_GD 0x00000000
+#define PM121_SYS_GR 0x00019999
+#define PM121_SYS_HISTORY_SIZE 2
+#define PM121_SYS_INTERVAL 5
+
+/* State data used by the system fans control loop
+ */
+struct pm121_sys_state {
+ int ticks;
+ s32 setpoint;
+ struct wf_pid_state pid;
+};
+
+struct pm121_sys_state *pm121_sys_state[N_LOOPS] = {};
+
+/*
+ * ****** CPU Fans Control Loop ******
+ *
+ */
+
+#define PM121_CPU_INTERVAL 1
+
+/* State data used by the cpu fans control loop
+ */
+struct pm121_cpu_state {
+ int ticks;
+ s32 setpoint;
+ struct wf_cpu_pid_state pid;
+};
+
+static struct pm121_cpu_state *pm121_cpu_state;
+
+
+
+/*
+ * ***** Implementation *****
+ *
+ */
+
+/* correction the value using the output-low-bound correction algo */
+static s32 pm121_correct(s32 new_setpoint,
+ unsigned int control_id,
+ s32 min)
+{
+ s32 new_min;
+ struct pm121_correction *correction;
+ correction = &corrections[control_id][pm121_mach_model - 2];
+
+ new_min = (average_power * correction->slope) >> 16;
+ new_min += correction->offset;
+ new_min = (new_min >> 16) + min;
+
+ return max(new_setpoint, max(new_min, 0));
+}
+
+static s32 pm121_connect(unsigned int control_id, s32 setpoint)
+{
+ s32 new_min, value, new_setpoint;
+
+ if (pm121_connection->control_id == control_id) {
+ controls[control_id]->ops->get_value(controls[control_id],
+ &value);
+ new_min = value * pm121_connection->correction.slope;
+ new_min += pm121_connection->correction.offset;
+ if (new_min > 0) {
+ new_setpoint = max(setpoint, (new_min >> 16));
+ if (new_setpoint != setpoint) {
+ pr_debug("pm121: %s depending on %s, "
+ "corrected from %d to %d RPM\n",
+ controls[control_id]->name,
+ controls[pm121_connection->ref_id]->name,
+ (int) setpoint, (int) new_setpoint);
+ }
+ } else
+ new_setpoint = setpoint;
+ }
+ /* no connection */
+ else
+ new_setpoint = setpoint;
+
+ return new_setpoint;
+}
+
+/* FAN LOOPS */
+static void pm121_create_sys_fans(int loop_id)
+{
+ struct pm121_sys_param *param = NULL;
+ struct wf_pid_param pid_param;
+ struct wf_control *control = NULL;
+ int i;
+
+ /* First, locate the params for this model */
+ for (i = 0; i < PM121_NUM_CONFIGS; i++) {
+ if (pm121_sys_all_params[loop_id][i].model_id == pm121_mach_model) {
+ param = &(pm121_sys_all_params[loop_id][i]);
+ break;
+ }
+ }
+
+ /* No params found, put fans to max */
+ if (param == NULL) {
+ printk(KERN_WARNING "pm121: %s fan config not found "
+ " for this machine model\n",
+ loop_names[loop_id]);
+ goto fail;
+ }
+
+ control = controls[param->control_id];
+
+ /* Alloc & initialize state */
+ pm121_sys_state[loop_id] = kmalloc(sizeof(struct pm121_sys_state),
+ GFP_KERNEL);
+ if (pm121_sys_state[loop_id] == NULL) {
+ printk(KERN_WARNING "pm121: Memory allocation error\n");
+ goto fail;
+ }
+ pm121_sys_state[loop_id]->ticks = 1;
+
+ /* Fill PID params */
+ pid_param.gd = PM121_SYS_GD;
+ pid_param.gp = param->gp;
+ pid_param.gr = PM121_SYS_GR;
+ pid_param.interval = PM121_SYS_INTERVAL;
+ pid_param.history_len = PM121_SYS_HISTORY_SIZE;
+ pid_param.itarget = param->itarget;
+ pid_param.min = control->ops->get_min(control);
+ pid_param.max = control->ops->get_max(control);
+
+ wf_pid_init(&pm121_sys_state[loop_id]->pid, &pid_param);
+
+ pr_debug("pm121: %s Fan control loop initialized.\n"
+ " itarged=%d.%03d, min=%d RPM, max=%d RPM\n",
+ loop_names[loop_id], FIX32TOPRINT(pid_param.itarget),
+ pid_param.min, pid_param.max);
+ return;
+
+ fail:
+ /* note that this is not optimal since another loop may still
+ control the same control */
+ printk(KERN_WARNING "pm121: failed to set up %s loop "
+ "setting \"%s\" to max speed.\n",
+ loop_names[loop_id], control->name);
+
+ if (control)
+ wf_control_set_max(control);
+}
+
+static void pm121_sys_fans_tick(int loop_id)
+{
+ struct pm121_sys_param *param;
+ struct pm121_sys_state *st;
+ struct wf_sensor *sensor;
+ struct wf_control *control;
+ s32 temp, new_setpoint;
+ int rc;
+
+ param = &(pm121_sys_all_params[loop_id][pm121_mach_model-2]);
+ st = pm121_sys_state[loop_id];
+ sensor = *(param->sensor);
+ control = controls[param->control_id];
+
+ if (--st->ticks != 0) {
+ if (pm121_readjust)
+ goto readjust;
+ return;
+ }
+ st->ticks = PM121_SYS_INTERVAL;
+
+ rc = sensor->ops->get_value(sensor, &temp);
+ if (rc) {
+ printk(KERN_WARNING "windfarm: %s sensor error %d\n",
+ sensor->name, rc);
+ pm121_failure_state |= FAILURE_SENSOR;
+ return;
+ }
+
+ pr_debug("pm121: %s Fan tick ! %s: %d.%03d\n",
+ loop_names[loop_id], sensor->name,
+ FIX32TOPRINT(temp));
+
+ new_setpoint = wf_pid_run(&st->pid, temp);
+
+ /* correction */
+ new_setpoint = pm121_correct(new_setpoint,
+ param->control_id,
+ st->pid.param.min);
+ /* linked corretion */
+ new_setpoint = pm121_connect(param->control_id, new_setpoint);
+
+ if (new_setpoint == st->setpoint)
+ return;
+ st->setpoint = new_setpoint;
+ pr_debug("pm121: %s corrected setpoint: %d RPM\n",
+ control->name, (int)new_setpoint);
+ readjust:
+ if (control && pm121_failure_state == 0) {
+ rc = control->ops->set_value(control, st->setpoint);
+ if (rc) {
+ printk(KERN_WARNING "windfarm: %s fan error %d\n",
+ control->name, rc);
+ pm121_failure_state |= FAILURE_FAN;
+ }
+ }
+}
+
+
+/* CPU LOOP */
+static void pm121_create_cpu_fans(void)
+{
+ struct wf_cpu_pid_param pid_param;
+ const struct smu_sdbp_header *hdr;
+ struct smu_sdbp_cpupiddata *piddata;
+ struct smu_sdbp_fvt *fvt;
+ struct wf_control *fan_cpu;
+ s32 tmax, tdelta, maxpow, powadj;
+
+ fan_cpu = controls[FAN_CPU];
+
+ /* First, locate the PID params in SMU SBD */
+ hdr = smu_get_sdb_partition(SMU_SDB_CPUPIDDATA_ID, NULL);
+ if (hdr == 0) {
+ printk(KERN_WARNING "pm121: CPU PID fan config not found.\n");
+ goto fail;
+ }
+ piddata = (struct smu_sdbp_cpupiddata *)&hdr[1];
+
+ /* Get the FVT params for operating point 0 (the only supported one
+ * for now) in order to get tmax
+ */
+ hdr = smu_get_sdb_partition(SMU_SDB_FVT_ID, NULL);
+ if (hdr) {
+ fvt = (struct smu_sdbp_fvt *)&hdr[1];
+ tmax = ((s32)fvt->maxtemp) << 16;
+ } else
+ tmax = 0x5e0000; /* 94 degree default */
+
+ /* Alloc & initialize state */
+ pm121_cpu_state = kmalloc(sizeof(struct pm121_cpu_state),
+ GFP_KERNEL);
+ if (pm121_cpu_state == NULL)
+ goto fail;
+ pm121_cpu_state->ticks = 1;
+
+ /* Fill PID params */
+ pid_param.interval = PM121_CPU_INTERVAL;
+ pid_param.history_len = piddata->history_len;
+ if (pid_param.history_len > WF_CPU_PID_MAX_HISTORY) {
+ printk(KERN_WARNING "pm121: History size overflow on "
+ "CPU control loop (%d)\n", piddata->history_len);
+ pid_param.history_len = WF_CPU_PID_MAX_HISTORY;
+ }
+ pid_param.gd = piddata->gd;
+ pid_param.gp = piddata->gp;
+ pid_param.gr = piddata->gr / pid_param.history_len;
+
+ tdelta = ((s32)piddata->target_temp_delta) << 16;
+ maxpow = ((s32)piddata->max_power) << 16;
+ powadj = ((s32)piddata->power_adj) << 16;
+
+ pid_param.tmax = tmax;
+ pid_param.ttarget = tmax - tdelta;
+ pid_param.pmaxadj = maxpow - powadj;
+
+ pid_param.min = fan_cpu->ops->get_min(fan_cpu);
+ pid_param.max = fan_cpu->ops->get_max(fan_cpu);
+
+ wf_cpu_pid_init(&pm121_cpu_state->pid, &pid_param);
+
+ pr_debug("pm121: CPU Fan control initialized.\n");
+ pr_debug(" ttarged=%d.%03d, tmax=%d.%03d, min=%d RPM, max=%d RPM,\n",
+ FIX32TOPRINT(pid_param.ttarget), FIX32TOPRINT(pid_param.tmax),
+ pid_param.min, pid_param.max);
+
+ return;
+
+ fail:
+ printk(KERN_WARNING "pm121: CPU fan config not found, max fan speed\n");
+
+ if (controls[CPUFREQ])
+ wf_control_set_max(controls[CPUFREQ]);
+ if (fan_cpu)
+ wf_control_set_max(fan_cpu);
+}
+
+
+static void pm121_cpu_fans_tick(struct pm121_cpu_state *st)
+{
+ s32 new_setpoint, temp, power;
+ struct wf_control *fan_cpu = NULL;
+ int rc;
+
+ if (--st->ticks != 0) {
+ if (pm121_readjust)
+ goto readjust;
+ return;
+ }
+ st->ticks = PM121_CPU_INTERVAL;
+
+ fan_cpu = controls[FAN_CPU];
+
+ rc = sensor_cpu_temp->ops->get_value(sensor_cpu_temp, &temp);
+ if (rc) {
+ printk(KERN_WARNING "pm121: CPU temp sensor error %d\n",
+ rc);
+ pm121_failure_state |= FAILURE_SENSOR;
+ return;
+ }
+
+ rc = sensor_cpu_power->ops->get_value(sensor_cpu_power, &power);
+ if (rc) {
+ printk(KERN_WARNING "pm121: CPU power sensor error %d\n",
+ rc);
+ pm121_failure_state |= FAILURE_SENSOR;
+ return;
+ }
+
+ pr_debug("pm121: CPU Fans tick ! CPU temp: %d.%03d°C, power: %d.%03d\n",
+ FIX32TOPRINT(temp), FIX32TOPRINT(power));
+
+ if (temp > st->pid.param.tmax)
+ pm121_failure_state |= FAILURE_OVERTEMP;
+
+ new_setpoint = wf_cpu_pid_run(&st->pid, power, temp);
+
+ /* correction */
+ new_setpoint = pm121_correct(new_setpoint,
+ FAN_CPU,
+ st->pid.param.min);
+
+ /* connected correction */
+ new_setpoint = pm121_connect(FAN_CPU, new_setpoint);
+
+ if (st->setpoint == new_setpoint)
+ return;
+ st->setpoint = new_setpoint;
+ pr_debug("pm121: CPU corrected setpoint: %d RPM\n", (int)new_setpoint);
+
+ readjust:
+ if (fan_cpu && pm121_failure_state == 0) {
+ rc = fan_cpu->ops->set_value(fan_cpu, st->setpoint);
+ if (rc) {
+ printk(KERN_WARNING "pm121: %s fan error %d\n",
+ fan_cpu->name, rc);
+ pm121_failure_state |= FAILURE_FAN;
+ }
+ }
+}
+
+/*
+ * ****** Common ******
+ *
+ */
+
+static void pm121_tick(void)
+{
+ unsigned int last_failure = pm121_failure_state;
+ unsigned int new_failure;
+ s32 total_power;
+ int i;
+
+ if (!pm121_started) {
+ pr_debug("pm121: creating control loops !\n");
+ for (i = 0; i < N_LOOPS; i++)
+ pm121_create_sys_fans(i);
+
+ pm121_create_cpu_fans();
+ pm121_started = 1;
+ }
+
+ /* skipping ticks */
+ if (pm121_skipping && --pm121_skipping)
+ return;
+
+ /* compute average power */
+ total_power = 0;
+ for (i = 0; i < pm121_cpu_state->pid.param.history_len; i++)
+ total_power += pm121_cpu_state->pid.powers[i];
+
+ average_power = total_power / pm121_cpu_state->pid.param.history_len;
+
+
+ pm121_failure_state = 0;
+ for (i = 0 ; i < N_LOOPS; i++) {
+ if (pm121_sys_state[i])
+ pm121_sys_fans_tick(i);
+ }
+
+ if (pm121_cpu_state)
+ pm121_cpu_fans_tick(pm121_cpu_state);
+
+ pm121_readjust = 0;
+ new_failure = pm121_failure_state & ~last_failure;
+
+ /* If entering failure mode, clamp cpufreq and ramp all
+ * fans to full speed.
+ */
+ if (pm121_failure_state && !last_failure) {
+ for (i = 0; i < N_CONTROLS; i++) {
+ if (controls[i])
+ wf_control_set_max(controls[i]);
+ }
+ }
+
+ /* If leaving failure mode, unclamp cpufreq and readjust
+ * all fans on next iteration
+ */
+ if (!pm121_failure_state && last_failure) {
+ if (controls[CPUFREQ])
+ wf_control_set_min(controls[CPUFREQ]);
+ pm121_readjust = 1;
+ }
+
+ /* Overtemp condition detected, notify and start skipping a couple
+ * ticks to let the temperature go down
+ */
+ if (new_failure & FAILURE_OVERTEMP) {
+ wf_set_overtemp();
+ pm121_skipping = 2;
+ }
+
+ /* We only clear the overtemp condition if overtemp is cleared
+ * _and_ no other failure is present. Since a sensor error will
+ * clear the overtemp condition (can't measure temperature) at
+ * the control loop levels, but we don't want to keep it clear
+ * here in this case
+ */
+ if (new_failure == 0 && last_failure & FAILURE_OVERTEMP)
+ wf_clear_overtemp();
+}
+
+
+static struct wf_control* pm121_register_control(struct wf_control *ct,
+ const char *match,
+ unsigned int id)
+{
+ if (controls[id] == NULL && !strcmp(ct->name, match)) {
+ if (wf_get_control(ct) == 0)
+ controls[FAN_OD] = ct;
+ }
+ return controls[id];
+}
+
+static void pm121_new_control(struct wf_control *ct)
+{
+ int all = 1;
+
+ if (pm121_all_controls_ok)
+ return;
+
+ all = all && pm121_register_control(ct, "optical-driver-fan", FAN_OD);
+ all = all && pm121_register_control(ct, "hard-driver-fan", FAN_HD);
+ all = all && pm121_register_control(ct, "cpu-driver-fan", FAN_CPU);
+ all = all && pm121_register_control(ct, "cpufreq-clamp", CPUFREQ);
+
+ if (all)
+ pm121_all_controls_ok = 1;
+}
+
+
+
+
+static struct wf_sensor* pm121_register_sensor(struct wf_sensor *sensor,
+ const char *match,
+ struct wf_sensor **var)
+{
+ if (*var == NULL && !strcmp(sensor->name, match)) {
+ if (wf_get_sensor(sensor) == 0)
+ *var = sensor;
+ }
+ return *var;
+}
+
+static void pm121_new_sensor(struct wf_sensor *sr)
+{
+ int all = 1;
+
+ if (pm121_all_sensors_ok)
+ return;
+
+ all = all && pm121_register_sensor(sr, "cpu-temp",
+ &sensor_cpu_temp);
+ all = all && pm121_register_sensor(sr, "cpu-current",
+ &sensor_cpu_current);
+ all = all && pm121_register_sensor(sr, "cpu-voltage",
+ &sensor_cpu_voltage);
+ all = all && pm121_register_sensor(sr, "cpu-power",
+ &sensor_cpu_power);
+ all = all && pm121_register_sensor(sr, "hard-drive-temp",
+ &sensor_hard_drive_temp);
+ all = all && pm121_register_sensor(sr, "optical-drive-temp",
+ &sensor_optical_drive_temp);
+ all = all && pm121_register_sensor(sr, "incoming-air-temp",
+ &sensor_incoming_air_temp);
+ all = all && pm121_register_sensor(sr, "north-bridge-temp",
+ &sensor_north_bridge_temp);
+ all = all && pm121_register_sensor(sr, "gpu-temp",
+ &sensor_gpu_temp);
+
+ if (all)
+ pm121_all_sensors_ok = 1;
+}
+
+
+
+static int pm121_notify(struct notifier_block *self,
+ unsigned long event, void *data)
+{
+ switch (event) {
+ case WF_EVENT_NEW_CONTROL:
+ pr_debug("pm121: new control %s detected\n",
+ ((struct wf_control *)data)->name);
+ pm121_new_control(data);
+ break;
+ case WF_EVENT_NEW_SENSOR:
+ pr_debug("pm121: new sensor %s detected\n",
+ ((struct wf_sensor *)data)->name);
+ pm121_new_sensor(data);
+ break;
+ case WF_EVENT_TICK:
+ if (pm121_all_controls_ok && pm121_all_sensors_ok)
+ pm121_tick();
+ break;
+ }
+
+ return 0;
+}
+
+static struct notifier_block pm121_events = {
+ .notifier_call = pm121_notify,
+};
+
+static int pm121_init_pm(void)
+{
+ const struct smu_sdbp_header *hdr;
+
+ hdr = smu_get_sdb_partition(SMU_SDB_SENSORTREE_ID, NULL);
+ if (hdr != 0) {
+ struct smu_sdbp_sensortree *st =
+ (struct smu_sdbp_sensortree *)&hdr[1];
+ pm121_mach_model = st->model_id;
+ }
+
+ pm121_connection = &pm121_connections[pm121_mach_model - 2];
+
+ printk(KERN_INFO "pm121: Initializing for iMac G5 iSight model ID %d\n",
+ pm121_mach_model);
+
+ return 0;
+}
+
+
+static int pm121_probe(struct platform_device *ddev)
+{
+ wf_register_client(&pm121_events);
+
+ return 0;
+}
+
+static int __devexit pm121_remove(struct platform_device *ddev)
+{
+ wf_unregister_client(&pm121_events);
+ return 0;
+}
+
+static struct platform_driver pm121_driver = {
+ .probe = pm121_probe,
+ .remove = __devexit_p(pm121_remove),
+ .driver = {
+ .name = "windfarm",
+ .bus = &platform_bus_type,
+ },
+};
+
+
+static int __init pm121_init(void)
+{
+ int rc = -ENODEV;
+
+ if (machine_is_compatible("PowerMac12,1"))
+ rc = pm121_init_pm();
+
+ if (rc == 0) {
+ request_module("windfarm_smu_controls");
+ request_module("windfarm_smu_sensors");
+ request_module("windfarm_smu_sat");
+ request_module("windfarm_lm75_sensor");
+ request_module("windfarm_max6690_sensor");
+ request_module("windfarm_cpufreq_clamp");
+ platform_driver_register(&pm121_driver);
+ }
+
+ return rc;
+}
+
+static void __exit pm121_exit(void)
+{
+
+ platform_driver_unregister(&pm121_driver);
+}
+
+
+module_init(pm121_init);
+module_exit(pm121_exit);
+
+MODULE_AUTHOR("Étienne Bersac <bersace@gmail.com>");
+MODULE_DESCRIPTION("Thermal control logic for iMac G5 (iSight)");
+MODULE_LICENSE("GPL");
+
diff --git a/drivers/macintosh/windfarm_smu_controls.c b/drivers/macintosh/windfarm_smu_controls.c
index 58c2590..961fa0e 100644
--- a/drivers/macintosh/windfarm_smu_controls.c
+++ b/drivers/macintosh/windfarm_smu_controls.c
@@ -218,6 +218,10 @@ static struct smu_fan_control *smu_fan_create(struct device_node *node,
fct->ctrl.name = "cpu-fan";
else if (!strcmp(l, "Hard Drive") || !strcmp(l, "Hard drive"))
fct->ctrl.name = "drive-bay-fan";
+ else if (!strcmp(l, "HDD Fan")) /* seen on iMac G5 iSight */
+ fct->ctrl.name = "hard-drive-fan";
+ else if (!strcmp(l, "ODD Fan")) /* same */
+ fct->ctrl.name = "optical-drive-fan";
/* Unrecognized fan, bail out */
if (fct->ctrl.name == NULL)
^ permalink raw reply related
* [PATCH v4] create modalias file in sysfs for bus of_platform
From: Olaf Hering @ 2008-01-26 10:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: sparclinux, linuxppc-dev
In-Reply-To: <18330.32110.449914.354218@cargo.ozlabs.ibm.com>
Create /sys/bus/of_platform/devices/*/modalias file to allow autoloading
of modules. modalias files are already present for many other bus types.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/of/device.c | 33 ++++++++++++++++++---------------
drivers/of/platform.c | 3 +++
2 files changed, 21 insertions(+), 15 deletions(-)
Index: linux-2.6/drivers/of/device.c
===================================================================
--- linux-2.6.orig/drivers/of/device.c
+++ linux-2.6/drivers/of/device.c
@@ -77,7 +77,7 @@ void of_dev_put(struct of_device *dev)
}
EXPORT_SYMBOL(of_dev_put);
-static ssize_t dev_show_devspec(struct device *dev,
+static ssize_t devspec_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct of_device *ofdev;
@@ -86,7 +86,22 @@ static ssize_t dev_show_devspec(struct d
return sprintf(buf, "%s", ofdev->node->full_name);
}
-static DEVICE_ATTR(devspec, S_IRUGO, dev_show_devspec, NULL);
+static ssize_t modalias_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ ssize_t len;
+
+ len = of_device_get_modalias(to_of_device(dev), buf, PAGE_SIZE - 2);
+ buf[len] = '\n';
+ buf[len+1] = 0;
+ return len+1;
+}
+
+struct device_attribute of_platform_device_attrs[] = {
+ __ATTR_RO(devspec),
+ __ATTR_RO(modalias),
+ __ATTR_NULL
+};
/**
* of_release_dev - free an of device structure when all users of it are finished.
@@ -107,25 +122,13 @@ EXPORT_SYMBOL(of_release_dev);
int of_device_register(struct of_device *ofdev)
{
- int rc;
-
BUG_ON(ofdev->node == NULL);
-
- rc = device_register(&ofdev->dev);
- if (rc)
- return rc;
-
- rc = device_create_file(&ofdev->dev, &dev_attr_devspec);
- if (rc)
- device_unregister(&ofdev->dev);
-
- return rc;
+ return device_register(&ofdev->dev);
}
EXPORT_SYMBOL(of_device_register);
void of_device_unregister(struct of_device *ofdev)
{
- device_remove_file(&ofdev->dev, &dev_attr_devspec);
device_unregister(&ofdev->dev);
}
EXPORT_SYMBOL(of_device_unregister);
Index: linux-2.6/drivers/of/platform.c
===================================================================
--- linux-2.6.orig/drivers/of/platform.c
+++ linux-2.6/drivers/of/platform.c
@@ -17,6 +17,8 @@
#include <linux/of_device.h>
#include <linux/of_platform.h>
+extern struct device_attribute of_platform_device_attrs[];
+
static int of_platform_bus_match(struct device *dev, struct device_driver *drv)
{
struct of_device *of_dev = to_of_device(dev);
@@ -93,6 +95,7 @@ int of_bus_type_init(struct bus_type *bu
bus->remove = of_platform_device_remove;
bus->suspend = of_platform_device_suspend;
bus->resume = of_platform_device_resume;
+ bus->dev_attrs = of_platform_device_attrs;
return bus_register(bus);
}
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Srivatsa Vaddagiri @ 2008-01-26 9:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
=?iso-8859-1?Q?Michel=2ED=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=.=?iso-8859-1?B?QHNub3d5LmluLmlibS5jb20=?=,
Michel.Dänzer
In-Reply-To: <1201324552.6815.165.camel@pasglop>
On Sat, Jan 26, 2008 at 04:15:52PM +1100, Benjamin Herrenschmidt wrote:
> > Michel,
> > You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> > was the cause for this bad behavior. Do you see behavior change (from good->bad)
> > immediately after applying that patch during your bisect process?
>
> Also Michel, double check your .config in both cases.
And also Michel whether CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED
gives more or less same desktop exp as !CONFIG_FAIR_GROUP_SCHED pls!
> > I would prefer to have CONFIG_FAIR_GROUP_SCHED +
> > CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
> > think is the desktop experience with that combination?
>
> I'm going to give that a try but unfortunately, it will have to wait
> until I'm back from LCA in a bit more than a week.
--
Regards,
vatsa
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox