summaryrefslogtreecommitdiffstats
path: root/drivers/macintosh
AgeCommit message (Collapse)Author
2005-06-25[PATCH] Cleanup patch for process freezingChristoph Lameter
1. Establish a simple API for process freezing defined in linux/include/sched.h: frozen(process) Check for frozen process freezing(process) Check if a process is being frozen freeze(process) Tell a process to freeze (go to refrigerator) thaw_process(process) Restart process frozen_process(process) Process is frozen now 2. Remove all references to PF_FREEZE and PF_FROZEN from all kernel sources except sched.h 3. Fix numerous locations where try_to_freeze is manually done by a driver 4. Remove the argument that is no longer necessary from two function calls. 5. Some whitespace cleanup 6. Clear potential race in refrigerator (provides an open window of PF_FREEZE cleared before setting PF_FROZEN, recalc_sigpending does not check PF_FROZEN). This patch does not address the problem of freeze_processes() violating the rule that a task may only modify its own flags by setting PF_FREEZE. This is not clean in an SMP environment. freeze(process) is therefore not SMP safe! Signed-off-by: Christoph Lameter <christoph@lameter.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-21[PATCH] I2C: Kill address ranges in non-sensors i2c chip driversJean Delvare
Some months ago, you killed the address ranges mechanism from all sensors i2c chip drivers (both the module parameters and the in-code address lists). I think it was a very good move, as the ranges can easily be replaced by individual addresses, and this allowed for significant cleanups in the i2c core (let alone the impressive size shrink for all these drivers). Unfortunately you did not do the same for non-sensors i2c chip drivers. These need the address ranges even less, so we could get rid of the ranges here as well for another significant i2c core cleanup. Here comes a patch which does just that. Since the process is exactly the same as what you did for the other drivers set already, I did not split this one in parts. A documentation update is included. The change saves 308 bytes in the i2c core, and an average 1382 bytes for chip drivers which use I2C_CLIENT_INSMOD, 126 bytes for those which do not. This change is required if we want to merge the sensors and non-sensors i2c code (and we want to do this). Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Index: gregkh-2.6/Documentation/i2c/writing-clients ===================================================================
2005-06-20[PATCH] Driver Core: drivers/i2c/chips/w83781d.c - ↵Yani Ioannou
drivers/s390/block/dcssblk.c: update device attribute callbacks Signed-off-by: Yani Ioannou <yani.ioannou@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-20[PATCH] class: convert drivers/* to use the new class api instead of ↵gregkh@suse.de
class_simple Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-09[PATCH] ppc32: Fix nasty sleep/wakeup problemBenjamin Herrenschmidt
Despite all the care lately in making the powermac sleep/wakeup as robust as possible, there is still a nasty related to the use of cpufreq on PMU based machines. Unfortunately, it affects paulus old powerbook so I have to fix it :) We didn't manage to understand what is precisely going on, it leads to memory corruption and might have to do with RAM not beeing properly refreshed when a cpufreq transition is done right before the sleep. The best workaround (and less intrusive at this point) we could come up with is included in this patch. We basically do _not_ force a switch to high speed on suspend anymore (that is what is causing the problem) on those machines. We still force a speed switch on wakeup (since we don't know what speed we are coming back from sleep at, and that seems to work fine). Since, during this short interval, the actual CPU speed might be incorrect, we also hack around by multiplying loops_per_jiffy by 2 (max speed factor on those machines) during early wakeup stage to make sure udelay's during that time aren't too short. For after 2.6.12, we'll change udelay implementation to use the CPU timebase (which is always constant) instead like we do on ppc64 and thus get rid of all those problems. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-28[PATCH] ppc32: Fix cpufreq vs. sleep issueBenjamin Herrenschmidt
Recent kernels occasionally trigger a PMU timeout on some mac laptops, typically on wakeup from sleep. This seem to be caused by either a too big latency caused by the cpufreq switch on wakeup from sleep or by an interrupt beeing lost due to the reset of the interrupt controller done during wakeup. This patch makes that code more robust by stopping PMU auto poll activity around cpufreq changes on machines that use the PMU for such changes (long latency switching involving a CPU hard reset and flush of all caches) and by removing the reset of the open pic interrupt controller on wakeup (that can cause the loss of an interrupt and Darwin doesn't do it, so it must not be necessary). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-25[PATCH] therm_adt746x: show correct sensor locationsColin Leroy
This patch shows the correct locations of the heat sensors present in iBook and PowerBooks G4, instead of displaying them as being on CPU and GPU (which is not always the case). Signed-off-by: Colin Leroy <colin@colino.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-25[PATCH] Make sure therm_adt746x only handles known hardwareColin Leroy
This patch limits therm_adt746x to currently existing fan controllers in Apple laptops. It may avoid problems with future hardware. Signed-off-by: Colin Leroy <colin@colino.net> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-02[PATCH] ppc32: Fix might_sleep() warning with clock spreadingBenjamin Herrenschmidt
The clock spreading disable/enable code was called to late/early during the suspend/resume code on some laptops and would trigger a might_sleep() warning due to the down() call in the low level i2c code. This fixes it by calling those functions earlier/later when interrupts are still enabled. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] macintosh/adbhid.c: adb buttons support for aluminium PowerBook G4Andreas Jaggi
This patch adds support for the special adb buttons of the aluminium PowerBook G4. Signed-off-by: Andreas Jaggi <andreas.jaggi@waterwave.ch> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] fix few remaining u32 vs. pm_message_t problemsPavel Machek
This fixes remaining u32 vs. pm_message_t confusions in -rc2-mm3. [There are usb changes, too; they went to Greg on his request.] Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] fix u32 vs. pm_message_t in rest of the treePavel Machek
This fixes u32 vs. pm_message_t confusion in remaining places. Fortunately there's few of them. Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] fix u32 vs. pm_message_t in drivers/macintoshPavel Machek
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately that turned out not to be the case as Russel King pointed out. Here are fixes for drivers/macintosh. Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!