On pre-r6xx, the power mode array is usually ordered:
low
...
high
default
On r6xx+:
default
low
...
high
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Useful for certain power management operations. You
need to wait for the GUI engine (2D, 3D, CP, etc.) to be
idle before changing clocks or adjusting engine parameters.
(v2) Fix gui idle enable on pre-r6xx asics
(v3) The gui idle interrrupt status bit is permanently asserted
on pre-r6xx chips, but the interrrupt is still generated.
workaround it in the driver.
(v4) Add support for evergreen
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Check to see if the GUI engine and related blocks
(2D, 3D, CP, etc) are idle or not. There are a number
of cases when we need to know if the drawing engine
is busy.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Simple cloning rules compared to server:
(a) single crtc
(b) > 1 connector active
(c) check command line mode
(d) try and find 1024x768 DMT mode if no command line.
(e) fail to clone
Signed-off-by: Dave Airlie <airlied@redhat.com>
After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.
v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings.
v3: add config lock take inside polling, add intel/nouveau poll init/fini calls
v4: config lock was a bit agressive, only needed around connector list reading.
otherwise it could re-enter.
glisse: discard drm_helper_hpd_irq_event
v3: Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
m == num_est3_modes is one past the end of the est3_modes[].
Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
let vga16fb claim 0xA0000+0x10000 region as its aperture;
drm drivers don't use it, so we have to detect it and kick
vga16fb manually - but only if drm is driving the primary card
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: James Simmons <jsimmons@infradead.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Currently vesafb/efifb/... is kicked when hardware driver is registering
framebuffer. To do it hardware must be fully functional, so there's a short
window between start of initialisation and framebuffer registration when
two drivers touch the hardware. Unfortunately sometimes it breaks nouveau
initialisation.
Fix it by kicking firmware driver(s) before we start touching the hardware.
Reported-by: Didier Spaier <didier.spaier@epsm.fr>
Tested-by: Didier Spaier <didier.spaier@epsm.fr>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Recently I've studied my system dmesg and seen this:
<lots of stuff before>
1 [ 0.478416] ACPI: Battery Slot [C1B4] (battery present)
2 [ 0.478648] ACPI: Battery Slot [C1B3] (battery absent)
3 [ 0.906678] [drm] initialized overlay support
4 [ 1.762304] Console: switching to colour frame buffer device 128x48
5 [ 1.765211] fb0: inteldrmfb frame buffer device
6 [ 1.765242] registered panic notifier
7 [ 1.765272] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
8 [ 1.765372] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
<lots of stuff after>
and it was not evident who registered that panic notifier on line 6.
I'd bought it as some low-level stuff needed by kernel itself, but the
time was inappropriate -- too late for such things.
So I had to study sources to see it was drm who was registering
switch-to-fb on panic.
Let's avoid possible confusion and mark this message as going from drm
subsystem.
(I'm a bit unsure whether to use '[drm]:' or 'drm:' -- the rest of the
kernel just uses 'topic:', and even in drm_fb_helper.c we use 'fb%d:'
without [] brackets. Either way is ok with me.)
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm
crtc id. Bump the minor version so userspace can enable conditionaly
features depend on this.
V2 use num_crtc and avoid DRM_ERROR
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Having hsync both start and end on pixel 1072 ain't gonna work very
well. Matches the X server's list.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-By: Michael Tokarev <mjt@tls.msk.ru>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use kzalloc rather than the combination of kmalloc and memset.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x,size,flags;
statement S;
@@
-x = kmalloc(size,flags);
+x = kzalloc(size,flags);
if (x == NULL) S
-memset(x, 0, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Reviewed-by: Corbin Simpson <MostAwesomeDude@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Smatch complained that we initialize 6 elements in add_detailed_modes()
but the timings[] array is declared with 5 elements. Adam Jackson
verified that 6 is the correct number of timings.
On Mon, May 10, 2010 at 12:08:24PM -0400, Adam Jackson wrote:
> > > struct std_timing timings[5];
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This decl is wrong, should be 6. From the 1.4 spec:
>
> "Six additional Standard Timings may be listed as a display descriptor
> (tag #FAh)."
>
> The 1.3 spec is a little less explicit about it, but does show 6
> standard timing codes in the 0xFA detailed subblock, terminated by 0x0A
> in the 18th byte. I don't have the docs for 1.2 or earlier, but we're
> paranoid enough about not adding broken timings that we should be fine.
This patch is basically a clean up, because timings[] is declared inside
a union and increasing the number of elements here doesn't change the
overall size of the union.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We don't use timing_level any more after: 9cf00977da "drm/edid: Unify
detailed block parsing between base and extension blocks".
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Previously we just set them to dpms off. This should save
additional power.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>