In theory, there should be no more users of I2C_ALGO_* at this point.
However, it happens that several drivers were using I2C_ALGO_* for
adapter ids, so we need to correct these before we can get rid of all
the I2C_ALGO_* definitions.
Note that this also fixes a bug in media/video/tvaudio.c:
/* don't attach on saa7146 based cards,
because dedicated drivers are used */
if ((adap->id & I2C_ALGO_SAA7146))
return 0;
This test was plain broken, as it would succeed for many more adapters
than just the saa7146: any those id would share at least one bit with
the saa7146 id. We are really lucky that the few other adapters we want
this driver to work with did not fulfill that condition.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This adds type-checking to pm_message_t, so that people can't confuse it
with int or u32. It also allows us to fix "disk yoyo" during suspend (disk
spinning down/up/down).
[We've tried that before; since that cpufreq problems were fixed and I've
tried make allyes config and fixed resulting damage.]
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Alexander Nyberg <alexn@telia.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
radeonfb does not clean up EDID sysfs attribute
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch removes CONFIG_PMAC_PBOOK (PowerBook support). This is now
split into CONFIG_PMAC_MEDIABAY for the actual hotswap bay that some
powerbooks have, CONFIG_PM for power management related code, and just left
out of any CONFIG_* option for some generally useful stuff that can be used
on non-laptops as well.
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>
The current radeonfb memset's the framebuffer to 0 when loaded. This
removes occasional artifacts but has the nasty side effect that if you
load radeonfb without framebuffer console, you destroy the VGA text
buffer, font, etc... radeon must not touch the framebuffer content when
it doesn't "own" it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch adds to the fbdev interface a set_cmap callback that allow the
driver to "batch" palette changes. This is useful for drivers like
radeonfb which might require lenghtly workarounds on palette accesses, thus
allowing to factor out those workarounds efficiently.
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>
My previous patch that added sleep support for uninorth-agp and some AGP
"off" stuff in radeonfb and aty128fb is breaking some configs. More
specifically, it has problems with rage128 setups since the DRI code for
these in X doesn't properly re-enable AGP on wakeup or console switch
(unlike the radeon DRM).
This patch fixes the problem for pmac once for all by using a different
approach. The AGP driver "registers" special suspend/resume callbacks with
some arch code that the fbdev's can later on call to suspend and resume
AGP, making sure it's resumed back in the same state it was when suspended.
This is platform specific for now. It would be too complicated to try to
do a generic implementation of this at this point due to all sort of weird
things going on with AGP on other architectures. We'll re-work that whole
problem cleanly once we finally merge fbdev's and DRI.
In the meantime, please apply this patch which brings back some r128 based
laptops into working condition as far as system sleep is concerned.
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>
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!
Jean Delvare