[Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in drivers/gpu/drm/i915/intel_sdvo.c between commit 7ba220cec0bb ("drm/i915: Enable hotplug interrupts after querying hw capabilities") from Linus' tree and commit e596a02ccfc6 ("drm/i915: Remove dead code from SDVO initialisati

[Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in drivers/gpu/drm/i915/intel_display.c between commit d62cf62ad07d ("drm/i915: Quirk the pipe A quirk in the modeset state checker") from Linus' tree and commit 6c49f24180c3 ("drm/i915: hw state readout support for pixel_multip

[Intel-gfx] [PATCH] drm/i915: asserts for lvds pre_enable

Lots of bangin my head against the wall^UExperiments have shown that we really need to enable the lvds port before we enable plls. Strangely that seems to include the fdi rx pll on the pch. Note that the pch pll assert can fire since the lvds port has it's own special clock source settings in the

[Intel-gfx] [PATCH] drm/i915: move i9xx dpll enabling into crtc enable function

Now that we have the proper pipe config to track this, we don't need to write any registers any more. Note that for platforms without DPLL_MD (pre-gen4) which store the pixel mutliplier in the DPLL register I've decided to keep the seemingly "redundant" write: The comment right below saying "do th

[Intel-gfx] Problems using intel-linux-graphics-installer on Fedora 18

Hi, when I run intel-linux-graphics-installer (wheter using sudo or not), it stucks with the following message: "Your system does not have the 'org.freedesktop.packagekit.package-install' PolicyKit files installed. Please check your installation" Indeed, my system doesn't use PolicyKit. Is the

Re: [Intel-gfx] [PATCH 27/31] drm/i915: move i9xx dpll enabling into crtc enable function

On Fri, Jun 14, 2013 at 07:02:17PM +0300, Imre Deak wrote: > On Wed, 2013-06-05 at 13:34 +0200, Daniel Vetter wrote: > > Now that we have the proper pipe config to track this, we don't need > > to write any registers any more. > > > > v2: Drop a few now unnecessary local variables and switch the e

[Intel-gfx] [PATCH 3/3] drm/i915: rename intel_fb.c to intel_fbdev.c

This file is all about the legacy fbdev support. If we want to extract framebuffer functions, we better put those into a separate file. Also rename functions accordingly, only two have used the intel_fb_ prefix anyway. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/Makefile| 2

[Intel-gfx] [PATCH 2/3] drm/i915: Kconfig option to disable the legacy fbdev support

Boots Just Fine (tm)! The only glitch seems to be that at least on Fedora the boot splash gets confused and doesn't display much at all. And since there's no ugly console flickering anymore in between, the flicker while switching between X servers (VT support is still enabled) is even more jarrin

[Intel-gfx] [PATCH 1/3] drm: Add separate Kconfig option for fbdev helpers

For drivers which might want to disable fbdev legacy support. Select the new option in all drivers for now, so this shouldn't result in any change. Drivers need some work anyway to make fbdev support optional (if they have it implemented, that is), so the recommended way to expose this is by addin

[Intel-gfx] [PATCH 0/3] fbdev no more!

Hi all, So I've taken a look again at the locking mess in our fbdev support and cried. Fixing up the console_lock mess around the fbdev notifier will be real work, semanatically the fbdev layer does lots of stupid things (like the radeon resume issue I've just debugged) and the panic notifier is p