viafb: add a mapping of supported output devices

This patch maps supported output devices to IGP versions. This list may
contain errors as most of it is derived of the driver source but it should
be

viafb: add a mapping of supported output devices

This patch maps supported output devices to IGP versions. This list may
contain errors as most of it is derived of the driver source but it should
be correct enough to provide a good help. The devices are exported via a
proc entry in the same format as those showing the output devices per IGA.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Andrew Morton <akpm@linux-foundation.org>

show more ...

viafb: introduce per output device power management

This patch moves common parts of dvi.c, lcd.c and vt1636.c to hw.c to
start a per output device power management. There should be no runtime
chang

viafb: introduce per output device power management

This patch moves common parts of dvi.c, lcd.c and vt1636.c to hw.c to
start a per output device power management. There should be no runtime
changes aside that this patch enables the proc interface to enable/disable
devices when needed which greatly increases the chances that changes to
the output device configuration will work. However the power management is
not yet complete so it might fail on some configurations. As this area is
quite complex and touches undocumented things there is a slight chance of
regressions.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Joseph Chan <JosephChan@via.com.tw>

show more ...

viafb: add interface for output device configuration

This patch extends the proc entry to contain a possibility to view and
change the output devices for each IGA. This is useful for debugging
outpu

viafb: add interface for output device configuration

This patch extends the proc entry to contain a possibility to view and
change the output devices for each IGA. This is useful for debugging
output problems as it provides a reliable way to query which low level
devices are active after VIAs output device configuration nightmare
happended. It's as well suitable for daily use as one can change the
output configuration on the fly for example to connect a projector.
At the moment it's still unstable. The reason is that we have to handle
a bunch of undocumented output devices (those without a proper name) and
that this patch is the first step to collect and verify the needed
information. Basically the only configuration change that is expected to
work at the moment is switching output devices between IGA1 and IGA2.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Andrew Morton <akpm@linux-foundation.org>

show more ...

viafb: propagate __init and __devinit

There are a lot of init functions which are not marked as such.
Fix this.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Joseph Chan <

viafb: propagate __init and __devinit

There are a lot of init functions which are not marked as such.
Fix this.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Joseph Chan <JosephChan@via.com.tw>

show more ...

viafb: fix accel_flags check_var bug

viafb: fix accel_flags check_var bug

In check_var we should check and modify the var given and not the
one which is currently active. So this code was obviously

viafb: fix accel_flags check_var bug

viafb: fix accel_flags check_var bug

In check_var we should check and modify the var given and not the
one which is currently active. So this code was obviously wrong.
Probably this was doing no harm because all acceleration functions
also check whether acceleration is possible. (otherwise I would
expect this to lead to a null pointer dereference)

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Joseph Chan <JosephChan@via.com.tw>

show more ...

viafb: probe cleanups

viafb: probe cleanups

Removal of strange special cases that must not exist as well as a
useless check.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc:

viafb: probe cleanups

viafb: probe cleanups

Removal of strange special cases that must not exist as well as a
useless check.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Joseph Chan <JosephChan@via.com.tw>

show more ...

viafb: remove ioctls which break the framebuffer interface

viafb: remove ioctls which break the framebuffer interface

The ioctls VIAFB_SET_DEVICE, VIAFB_SET_DEVICE_INFO and
VIAFB_SET_SECOND_MODE ar

viafb: remove ioctls which break the framebuffer interface

viafb: remove ioctls which break the framebuffer interface

The ioctls VIAFB_SET_DEVICE, VIAFB_SET_DEVICE_INFO and
VIAFB_SET_SECOND_MODE are removed because they prevent a clean
framebuffer driver because they modify the hardware and/or the
internal structures.
There are no known applications using these ioctls so no breakage is
expected. Additionaly the main functionality was duplicating the
framebuffer interface so there really should not exist any user.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Joseph Chan <JosephChan@via.com.tw>

show more ...

viafb: update fix before calculating depth

viafb: update fix before calculating depth

As the depth calculation depends on information in fix it is saner to
do the update first.
No runtime change ex

viafb: update fix before calculating depth

viafb: update fix before calculating depth

As the depth calculation depends on information in fix it is saner to
do the update first.
No runtime change expected as the value visual in fix used never
changes to MONO.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Joseph Chan <JosephChan@via.com.tw>

show more ...

drivers/video/via: use memdup_user

Use memdup_user when user data is immediately copied into the
allocated region.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.f

drivers/video/via: use memdup_user

Use memdup_user when user data is immediately copied into the
allocated region.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression from,to,size,flag;
position p;
identifier l1,l2;
@@

- to = \(kmalloc@p\|kzalloc@p\)(size,flag);
+ to = memdup_user(from,size);
if (
- to==NULL
+ IS_ERR(to)
|| ...) {
<+... when != goto l1;
- -ENOMEM
+ PTR_ERR(to)
...+>
}
- if (copy_from_user(to, from, size) != 0) {
- <+... when != goto l2;
- -EFAULT
- ...+>
- }
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Scott Fang <ScottFang@viatech.com.cn>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...

Merge branch 'viafb-next' of git://git.lwn.net/linux-2.6

* 'viafb-next' of git://git.lwn.net/linux-2.6: (35 commits)
viafb: move some include files to include/linux
viafb: Eliminate some global.

Merge branch 'viafb-next' of git://git.lwn.net/linux-2.6

* 'viafb-next' of git://git.lwn.net/linux-2.6: (35 commits)
viafb: move some include files to include/linux
viafb: Eliminate some global.h references
viafb: get rid of i2c debug cruft
viafb: fold via_io.h into via-core.h
viafb: Fix initialization error paths
viafb: Do not remove gpiochip under spinlock
viafb: make procfs entries optional
viafb: fix proc entry removal
viafb: improve misc register handling
viafb: replace inb/outb
viafb: move some modesetting functions to a seperate file
viafb: unify modesetting functions
viafb: Reserve framebuffer memory for the upcoming camera driver
viafb: Add a simple VX855 DMA engine driver
viafb: Add a simple interrupt management infrastructure
via: Rationalize vt1636 detection
viafb: Introduce viafb_find_i2c_adapter()
via: Do not attempt I/O on inactive I2C adapters
viafb: Turn GPIO and i2c into proper platform devices
viafb: Convert GPIO and i2c to the new indexed port ops
...

show more ...

viafb: move some include files to include/linux

These are the files which should be available to subdevices compiled
outside of drivers/video/via.

Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.co

viafb: move some include files to include/linux

These are the files which should be available to subdevices compiled
outside of drivers/video/via.

Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Cc: Harald Welte <laforge@gnumonks.org>
Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...

viafb: make procfs entries optional

viafb: make procfs entries optional

This patch adds a config option to enable procfs entries for direct
hardware access. This was the old behaviour but the optio

viafb: make procfs entries optional

viafb: make procfs entries optional

This patch adds a config option to enable procfs entries for direct
hardware access. This was the old behaviour but the option defaults
to no as this is really ugly and should not be needed if the driver
works correct (and if it doesn't, it needs to be fixed).
That stuff is really something that should
- not be needed at all (the driver should be capable of doing it)
- not be there (debugfs would be better for such things)
So add this option just for backwards compatiblity.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>

show more ...

viafb: fix proc entry removal

viafb: fix proc entry removal

Trying to remove unregistered proc entries became painful and is
useless anyway. So remove the removal of an entry that was never
registe

viafb: fix proc entry removal

viafb: fix proc entry removal

Trying to remove unregistered proc entries became painful and is
useless anyway. So remove the removal of an entry that was never
registered and duplicate the logic for one which is added
conditionally. Additionally move the removal above releasing fb_info
as we still need the information.
This prevents tainting the kernel by the procfs warn on and
avoiding access to already freed memory is probably also a good idea.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>

show more ...

viafb: unify modesetting functions

viafb: unify modesetting functions

This patch unifies some cleaned up modesetting functions to prepare for
moving them to an extra file. This includes make them u

viafb: unify modesetting functions

viafb: unify modesetting functions

This patch unifies some cleaned up modesetting functions to prepare for
moving them to an extra file. This includes make them use via_io and
changing there names to reflect that they do not depend on anything
framebuffer specific.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>

show more ...

viafb: Separate global and fb-specific data

This patch moves data of interest into a new viafb_dev structure which
describes the device as a whole; the idea here is to create a separation
between wh

viafb: Separate global and fb-specific data

This patch moves data of interest into a new viafb_dev structure which
describes the device as a whole; the idea here is to create a separation
between what all devices may need and what the framebuffer device in
particular needs.

I've also made some small steps toward thinning out the global.h mess.

Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Cc: Harald Welte <laforge@gnumonks.org>
Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...

viafb: Move core stuff into via-core.c

The first step toward turning viafb into a multifunction driver. This
patch creates a new via-core.c file which serves as the main PCI driver;
everything else

viafb: Move core stuff into via-core.c

The first step toward turning viafb into a multifunction driver. This
patch creates a new via-core.c file which serves as the main PCI driver;
everything else comes below that. Some work has been done to rationalize
the i2c drivers in this new scheme.

Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Cc: Harald Welte <laforge@gnumonks.org>
Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...

viafb: rework the I2C support in the VIA framebuffer driver

This patch changes the way how the various I2C busses are used internally
inside the viafb driver: Previosuly, only a single i2c_adapter

viafb: rework the I2C support in the VIA framebuffer driver

This patch changes the way how the various I2C busses are used internally
inside the viafb driver: Previosuly, only a single i2c_adapter was created,
even though two different hardware I2C busses are accessed: A structure member
in a global variable was modified to indicate the bus to be used.

Now, all existing hardware busses are registered with the i2c core, and the
viafb_i2c_{read,write}byte[s]() function take the adapter number as function
call parameter, rather than referring to the global structure member.

[jc: even more painful merge with mainline changes ->2.6.34]
[jc: painful merge with OLPC changes]

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: Harald Welte <HaraldWelte@viatech.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...

viafb: Unmap the frame buffer on initialization error

This was part of Harald's "make viafb a first-class citizen using
pci_driver" patch, but somehow got dropped when that patch went into
mainline.

viafb: Unmap the frame buffer on initialization error

This was part of Harald's "make viafb a first-class citizen using
pci_driver" patch, but somehow got dropped when that patch went into
mainline.

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...

viafb: use proper pci config API

This patch alters viafb to use the proper Linux in-kernel API to access
PCI configuration space, rather than poking at I/O ports by itself.

Cc: Florian Tobias Schan

viafb: use proper pci config API

This patch alters viafb to use the proper Linux in-kernel API to access
PCI configuration space, rather than poking at I/O ports by itself.

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: Harald Welte <HaraldWelte@viatech.com>

show more ...

viafb: Fix various resource leaks during module_init()

The current code executed from module_init() in viafb does not have
proper error checking and [partial] resoure release paths in case
an error

viafb: Fix various resource leaks during module_init()

The current code executed from module_init() in viafb does not have
proper error checking and [partial] resoure release paths in case
an error happens half way through driver initialization.

This patch adresses the most obvious of those issues, such as a
leftover i2c bus if module_init (and thus module load) fails.

[jc: fixed merge conflicts]
[jc: also restored -ENOMEM return on ioremap() fail]

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: Harald Welte <HaraldWelte@viatech.com>

show more ...

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when bu

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

show more ...

viafb: support color depth 15 and 30

Add support for the color depth 15 on IGA1 and 30 on IGA1 and IGA2. To
allow the usage of those the driver now refuses color depth that are
totally off and othe

viafb: support color depth 15 and 30

Add support for the color depth 15 on IGA1 and 30 on IGA1 and IGA2. To
allow the usage of those the driver now refuses color depth that are
totally off and otherwise the selection in viafb_check_var is used.
Therefore the first call to this for the first framebuffer was delayed a
bit. It only enables the new formats if they are requested exactly
(viafb_bpp=15|30).

As this is a new feature, no regressions are expected. The color depth 15
was successfully tested. Didn't get anything usable for 30 but that might
be the programs fault. I would like to get some feedback whether it works
as expected or not if somebody knows a program/configuration where it
should.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Scott Fang <ScottFang@viatech.com.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...

viafb: rework color setting

This is a rewritten version of viafb_setcolreg. The hardware register
writes were split up and moved to hw.c where they belong as this is really
low level stuff. It was

viafb: rework color setting

This is a rewritten version of viafb_setcolreg. The hardware register
writes were split up and moved to hw.c where they belong as this is really
low level stuff. It was made dual fb aware.

Furthermore viafb_setcmap was removed as the problem with 8bpp originated
from a bug in writing multiple color registers at once. The removal of
viafb_setcmap might introduce a small performance regression but its
certainly better to receive the correct result a bit slower than a garbled
picture fast. It should give us a working 8bpp mode and is more
extensible than the old hardcoded code. No other regressions are expected
but as the hardware might be a bit picky it might cause some regressions
in 8bpp mode on some hardware although I doubt that.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Scott Fang <ScottFang@viatech.com.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...

viafb: some virtual_xres handling fixes

Do not require the virtual_xres to be aligned as line length is for such
purposes. Calculate always the smallest line length required.

Signed-off-by: Floria

viafb: some virtual_xres handling fixes

Do not require the virtual_xres to be aligned as line length is for such
purposes. Calculate always the smallest line length required.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Scott Fang <ScottFang@viatech.com.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...

viafb: rework color checking

Make color checking a bit more tolerant in what values it allows and more
fine grained to later support 15 and 30 bits formats. It splits the
filling of the color infor

viafb: rework color checking

Make color checking a bit more tolerant in what values it allows and more
fine grained to later support 15 and 30 bits formats. It splits the
filling of the color information in var to a seperate function and sets
some color related values in var that where previously untouched.

This could be a bug fix but at least I don't know any applications that
was fooled by not correctly setting the fields in var. At least no
regressions are expected.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Scott Fang <ScottFang@viatech.com.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...