MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a
function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h
allows all of the framebuffer and VT console drivers to remove their
dependency on tty.h.
[akpm@osdl.org: fix alpha build]
Signed-off-by: Jon Smirl <jonsmir@gmail.com>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
drivers/video/matrox/matroxfb_base.c: In function 'matroxfb_ioctl':
drivers/video/matrox/matroxfb_base.c:1140: error: 'VIDIOC_S_CTRL_OLD' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c:1140: error: (Each undeclared identifier is reported only once drivers/video/matrox/matroxfb_base.c:1140: error: for each function it appears in.)
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
There has been a longstanding problem with the Matrox G450 and perhaps
other similar cards, with modes "above" 1280x1024-60 on ppc/ppc64 boxes
running Linux. Higher resolutions and/or higher refresh rates resulted in
a very noticably "jittery" display, and sometimes no display, depending on
the physical monitor. This patch fixes that problem on the systems I have
easy access to...
I've tested with SLES9SP3 (2.6.5+ kernel) and 2.6.16-rc6 custom kernels on
an IBM eServer p5 520 w/G450 (a.k.a GXT135P on IBM's ppc64 systems), and a
colleague of mine (Ian Romanick) tested it successfully on an Apple ppc32
box (w/GXT135P). I also tested it on IA32 box I have with a GXT135P to
verify that it didn't obviously break anything. In my testing, I covered
single-card, single and dual-head setups using both HD15 and DVI-D signals,
on both the IA32 and ppc64 boxes. While everything appeared fine on both
boxes, I did encounter one problem: I can't get any signal on the DVI-D
output on the ppc64 box. However, this is also the case without my patch.
I just noticed that screen-blanking only occurs on the primary display as
well.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Signed-off-by: Ian Romanick <idr@us.ibm.com>
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This removes statically assigned platform numbers and reworks the
powerpc platform probe code to use a better mechanism. With this,
board support files can simply declare a new machine type with a
macro, and implement a probe() function that uses the flattened
device-tree to detect if they apply for a given machine.
We now have a machine_is() macro that replaces the comparisons of
_machine with the various PLATFORM_* constants. This commit also
changes various drivers to use the new macro instead of looking at
_machine.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Use ARRAY_SIZE macro instead of sizeof(x)/sizeof(x[0]) and remove
duplicates of ARRAY_SIZE. Some coding style and trailing whitespaces are
also fixed.
Compile-tested where possible (some are other arch or BROKEN)
Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
A few cleanups which were done to almost all i2c drivers some times
ago, but matroxfb_maven was forgotten:
* Don't allocate two different structures at once.
* Use kzalloc instead of kmalloc+memset.
* Use strlcpy instead of strcpy.
* Drop duplicate error message on client deregistration failure.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
insmod will tell us when the module failed to load. We do no further
processing on the return from i2c_add_driver(), so just return what
i2c_add_driver() did, instead of storing it.
Add __init/__exit annotations while we're at it.
Signed-off-by: Arthur Othieno <apgo@patchbomb.org>
Acked-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Petr Vandrovec <petr@vandrovec.name>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
checkconfig.pl is no longer needed now that autoconf.h is automatically
included. Remove it and all references to it.
Signed-off-by: Brian Gerst <bgerst@didntduck.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The ioctl and file arguments to ->fb_mmap are totally unused and there's not
reason a driver should need them.
Also update the ->fb_compat_ioctl prototype to be the same as ->fb_mmap.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Remove the "inline" keyword from a bunch of big functions in the kernel with
the goal of shrinking it by 30kb to 40kb
Signed-off-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The Coverity checker spotted this dead code.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch contains the possible cleanups including the following:
- every file should #include the headers containing the prototypes for
it's global functions
- make needlessly global functions static
- kyro/STG4000Interface.h: #include video/kyro.h and linux/pci.h
instead of a manual "struct pci_dev"
- i810_main.{c,h}: prototypes for static functions belong to the
C file
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: "Antonino A. Daplas" <adaplas@hotpop.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
matroxfb has no need for struct display and fbcon.h. Remove.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Given that implementing i2c_driver.command is optional, there is no
point in an empty implementation thereof.
Signed-off-by: Laurent Riffard <laurent.riffard@free.fr>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Michael Geng <linux@MichaelGeng.de>
Cc: Petr Vandrovec <vandrove@vc.cvut.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Now that i2c_add_driver() doesn't need the module owner to be set by
hand, we can delete it from the drivers. This patch catches all of the
drivers that I found in the current tree (if a driver sets the .owner by
hand, it's not a problem, just not needed.)
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Jean Delvare <khali@linux-fr.org>
We should use the i2c_driver.driver's .name and .owner fields
instead of the i2c_driver's ones.
This patch updates the matroxfb driver.
Signed-off-by: Laurent Riffard <laurent.riffard@free.fr>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Petr Vandrovec <petr@vandrovec.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Just about every i2c chip driver sets the I2C_DF_NOTIFY flag, so we
can simply make it the default and drop the flag. If any driver really
doesn't want to be notified when i2c adapters are added, that driver
can simply omit to set .attach_adapter. This approach is also more
robust as it prevents accidental NULL pointer dereferences.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The current init code sets hiprilvl to 0 and maxhipri to 5. According to the
specs those values are illegal on both G200 and G400. It also causes
distortions on the TV-out at least when CRTC2 is in YUV mode as is the case
with DirectFB. This patch resets both values to 0.
Signed-off-by: Ville Syrjl <syrjala@sci.fi>
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
No point in spamming the logs with a message about xres rounding.
Signed-off-by: Ville Syrjl <syrjala@sci.fi>
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Use the CACHEFLUSH register on all chip types. The register is listed in all
other specs except 2064W. However I have verified that the register does work
on a 2064W despite being marked reserved in the specs. There were no
noticeable side effects after writing to the register.
Signed-off-by: Ville Syrjl <syrjala@sci.fi>
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add new entries for Mystique AGP with the PCI ID 0x051e.
I don't actually have such boards but according to google they do exist.
Curiosly X.Org doesn't recognize that PCI ID. And what's even more
interesting is that Matrox's own Windows drivers don't recognize it either.
After going through about a dozen different versions I did find one older
driver that does list this particular ID. It is also listed in the pci.ids
file.
I'm not sure if non-220 AGP chips exist. I left the chip revision check
intact for AGP chips nonetheless.
Signed-off-by: Ville Syrjl <syrjala@sci.fi>
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
wait_event_event_interruptible() uses a private wait queue entry so there's no
need for the caller to initialize one.
Signed-off-by: Ville Syrjl <syrjala@sci.fi>
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
According to Jon Smirl, filling in the field fb_cursor with soft_cursor for
drivers that do not support hardware cursors is redundant. The soft_cursor
function is usable by all drivers because it is just a wrapper around
fb_imageblit. And because soft_cursor is an fbcon-specific hook, the file is
moved to the console directory.
Thus, drivers that do not support hardware cursors can leave the fb_cursor
field blank. For drivers that do, they can fill up this field with their own
version.
The end result is a smaller code size. And if the framebuffer console is not
loaded, module/kernel size is also reduced because the soft_cursor module will
also not be loaded.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Some adjustments to the matroxfb code, for one part preventing the display
to be disabled for longer than necessary, and for the other part to make
information about the frame buffer position available so that a kernel
debugger might obtain that before the initial mode change.
Finally, some return code corrections to fit the generic fb code.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This updates the matroxfb code so that it can find the PInS data embedded
in the BIOS on PowerPC cards. The process for finding the data is
different on OpenFirmware cards than on x86 cards, and the code for doing
so was missing.
After patching, building, installing, and booting a kernel, you should grep
for "PInS" in /var/log/messages. You should see two messages in the log:
PInS data found at offset XXXXX
PInS memtype = X
On the GXT135p card I get "31168" and "5". The first value is irrelevant,
but it's presence lets me know that the PInS data was actually found. On a
GXT130p, the second value should be 3. Since I don't have access to that
hardware, if someone can verify that, I will submit a follow-on patch that
rips out all the memtype parameter stuff.
Signed-off-by: Ian Romanick <idr@us.ibm.com>
Signed-off-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Merge the algorithm id part (16 upper bits) of the i2c adapters ids
into the definition of the adapters ids directly. After that, we don't
need to OR both ids together for each i2c_adapter structure.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch removes some obviously dead code found by the Coverity
checker.
This patch was already ACK'ed by Petr Vandrovec.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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
===================================================================
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!
