This breaks the connection between the core drm connector list
and the fbdev connector usage, and allows them to become disjoint
in the future. It also removes the untype void* that was in the
connector struct to support this.

All connectors are added to the fbdev now but this could be
changed in the future.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This move to using the list of crtcs in the fb helper and cleans up the
whole picking code, now we store the crtc/connectors we want directly
into the modeset and we use the modeset directly to set the mode.

Fixes from James Simmons and Ben Skeggs.
Signed-off-by: NDave Airlie <airlied@redhat.com>

The fbdev layer in the kms code should act like a consumer of the kms services and avoid having relying on information being store in the kms core structures in order for it to work.

This patch

a) removes the info pointer/psuedo palette from the core drm_framebuffer structure and moves it to the fbdev helper layer, it also removes the core drm keeping a list of kernel kms fbdevs.
b) migrated all the fb helper functions out of the crtc helper file into the fb helper file.
c) pushed the fb probing/hotplug control into the driver
d) makes the surface sizes into a structure for ease of passing
This changes the intel/radeon/nouveau drivers to use the new helper.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fix build error when CONFIG_MAGIC_SYSRQ is not enabled:

drivers/gpu/drm/drm_fb_helper.c:915: error: 'sysrq_drm_fb_helper_restore_op' undeclared (first use in this function)
drivers/gpu/drm/drm_fb_helper.c:929: error: 'sysrq_drm_fb_helper_restore_op' undeclared (first use in this function)
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NPavel Roskin <proski@gnu.org>
[clemens@ladisch.de: merged into drm_fb_helper]
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Kernel has simple_strtol() which would be used as atoi().

This is quite the same fix as in 2cb96f86
("fbdev: drop custom atoi from drivers/video/modedb.c") because code in
drivers/gpu/drm/drm_fb_helper.c is based on drivers/video/modedb.c.
Signed-off-by: NAndy Shevchenko <ext-andriy.shevchenko@nokia.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NPavel Roskin <proski@gnu.org>
[clemens@ladisch.de: merged into drm_fb_helper]
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

commit 731b5a15
Author: James Simmons <jsimmons@infradead.org>
Date:   Thu Oct 29 20:39:07 2009 +0000

    drm/kms: properly handle fbdev blanking

uses DRM_MODE_DPMS_ON for FB_BLANK_NORMAL, but DRM_MODE_DPMS_ON
is actually for turning output on instead of blank.

This makes fb blank broken on my T61, it put LVDS on but leave
pipe disabled which made screen totally white or caused some
'burning' effect.

[airlied: James objects to this but at this point in 2.6.33,
I can't see a patch that will fix this properly like he wants coming
in time and otherwise this is a regression - proper fix for 2.6.34
hopefully.]

Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If userspace (plymouth in this case) asks for a deeper depth,
refuse it as well due to lack of resizing.

This fixes an issue since < 32MB cards went to 8bpp and plymouth
crashes on startup.
Signed-off-by: NDave Airlie <airlied@redhat.com>

If userspace (plymouth in this case) asks for a deeper depth,
refuse it as well due to lack of resizing.

This fixes an issue since < 32MB cards went to 8bpp and plymouth
crashes on startup.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This always evaluates to true.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

crtc may be undefined at this point.
Signed-off-by: NDave Airlie <airlied@redhat.com>

When the framebuffer driver does not publish detailed timing information
for the current video mode, the correct value for the pixclock field is
zero, not -1.

Since pixclock is actually unsigned, the value -1 would be interpreted
as 4294967295 picoseconds (i.e., about 4 milliseconds) by
register_framebuffer() and userspace programs.

This patch allows X.org's fbdev driver to work.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Tested-by: NPaulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Without an allocated colormap, FBIOGETCMAP fails.  This would make
programs restore an all-black colormap ("links -g") or fail to work
altogether ("mplayer -vo fbdev2").
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When the framebuffer driver does not publish detailed timing information
for the current video mode, the correct value for the pixclock field is
zero, not -1.

Since pixclock is actually unsigned, the value -1 would be interpreted
as 4294967295 picoseconds (i.e., about 4 milliseconds) by
register_framebuffer() and userspace programs.

This patch allows X.org's fbdev driver to work.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I examined several fbdev drivers and foudn the blanking code in
drm_fb_helper to be wrong. This patch fixes the fbdev blanking to behave
like other fbdev drivers.
Signed-off-by: NDave Airlie <airlied@redhat.com>

I believe this is a typo.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This sets the fbcon to use TRUECOLOR by default, it then
only modifies the pseudo palette for fbcon, and only touches
the real palette when in 8-bit pseudo color mode.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This sets the fbcon to use TRUECOLOR by default, it then
only modifies the pseudo palette for fbcon, and only touches
the real palette when in 8-bit pseudo color mode.
Signed-off-by: NDave Airlie <airlied@redhat.com>

The previous patches had some unwanted side effects, I've fixed
the lack of 32bpp working, and fixed up 16bpp so it should also work.

this also adds the interface to allow the driver to set a preferred
console depth so for example low memory rn50 can set it to 8bpp.
It also catches 24bpp on cards that can't do it and forces 32bpp.

Tested on r100/r600/i945.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds support for the setcmap api and fixes the 8bpp
support at least on radeon hardware. It adds a new load_lut
hook which can be called once the color map is setup.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Compiling DRM throws the following warning if MAGIC_SYSRQ is disabled:

drivers/gpu/drm/drm_fb_helper.c:101: warning: 'sysrq_drm_fb_helper_restore_op' defined but not used

Fix: place sysrq_drm_fb_helper_restore_op and associated
definitions inside #ifdef CONFIG_MAGIC_SYSRQ.
Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
Signed-off-by: NDave Airlie <airlied@linux.ie>

This initialises the fb helper with the connector helper,
so that the fb cmdline code works for intel as well.
Signed-off-by: NDave Airlie <airlied@redhat.com>

If drivers don't init the fb helper on the connector, the cmdline
code won't work, but it shouldn't crash either.
Signed-off-by: NDave Airlie <airlied@redhat.com>

[note this requires an fb patch posted to linux-fbdev-devel already]

This uses the normal video= command line option to control the kms
output setup at boot time. It is used to override the autodetection
done by kms.

video= normally takes a framebuffer as the first parameter, in kms
it will take a connector name, DVI-I-1, or LVDS-1 etc. If no output
connector is specified the mode string will apply to all connectors.

The mode specification used will match down the probed modes, and if
no mode is found it will add a CVT mode that matches.

video=1024x768 - all connectors match a 1024x768 mode or add a CVT on
video=VGA-1:1024x768, VGA-1 connector gets mode only.

The same strings as used in current fb modedb.c are used, except I've
added three more letters, e, D, d, e = enable, D = enable Digital,
d = disable, which allow a connector to be forced into a certain state.
Signed-off-by: NDave Airlie <airlied@redhat.com>

The drm_fb_helper shouldn't mess with CRTCs that aren't enabled or in
its initial config. Ideally it shouldn't even include CRTCs in its
initial config if they're not in use, but my old fix for that no longer
works.  At any rate, this fixes a real bug I was seeing where after a
console blank, both pipes would come back on, even though only one had
been enabled before that.  Since the other pipe had a bogus config,
this led to some screen corruption.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Allow the KMS module to work properly, and also rename
it to KMS_HELPER so its clearer what its for.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Set accel to none, we really don't want anyone thinking
fb is an accel interface.
Pass pitch not depth to function for intel.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Initially I always meant this code to be shared, but things
ran away from me before I got to it.

This refactors the i915 and radeon kms fbdev interaction layers
out into generic helpers + driver specific pieces.

It moves all the panic/sysrq enhancements to the core file,
and stores a linked list of kernel fbs. This could possibly be
improved to only store the fb which has fbcon on it for panics
etc.

radeon retains some specific codes used for a big endian
workaround.

changes:
fix oops in v1
fix freeing path for crtc_info
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>