aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/drm_fb_helper.c
Commit message (Collapse)AuthorAgeFilesLines
* Revert "drm/fb-helper: don't sleep for screen unblank when an oops is in ↵Dave Airlie2013-10-101-8/+0
| | | | | | | | | | progress" This reverts commit 928c2f0c006bf7f381f58af2b2786d2a858ae311. This patch double applied, two checks for the price of one. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/fb-helper: don't sleep for screen unblank when an oops is in progressDaniel Vetter2013-09-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise the system will burn even brighter and worse, leave the user wondering what's going on exactly. Since we already have a panic handler which will (try) to restore the entire fbdev console mode, we can just bail out. Inspired by a patch from Konstantin Khlebnikov. The callchain leading to this, cut&pasted from Konstantin's original patch: callstack: panic() bust_spinlocks(1) unblank_screen() vc->vc_sw->con_blank() fbcon_blank() fb_blank() info->fbops->fb_blank() drm_fb_helper_blank() drm_fb_helper_dpms() drm_modeset_lock_all() mutex_lock(&dev->mode_config.mutex) Note that the entire locking in the fb helper around panic/sysrq and kdbg is ... non-existant. So we have a decent change of blowing up everything. But since reworking this ties in with funny concepts like the fbdev notifier chain or the impressive things which happen around console_lock while oopsing, I'll leave that as an exercise for braver souls than me. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Dave Airlie <airlied@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/fb-helper: Make load_lut and gamma_set/gamma_get hooks optionalVille Syrjälä2013-06-171-1/+13
| | | | | | | | | | | | | | | Check whether the crtc provides the load_lut callback before calling it. This allows the driver to provide the hook only for those CRTCs that actually have the hardware support for it. Also check whether the driver provided the fb_helper gamma_set/gamma_get hooks. It's a driver bug if it allows non-truecolor fbdev visuals w/o these hooks, but auditing all the drivers is too tedious. So just slap a big WARN_ON() there and bail out before things start to explode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@gmail.com>
* drm/fb-helper: Don't clobber the display palette when fbdev isn't boundVille Syrjälä2013-06-171-1/+10
| | | | | | | | | | | | | | Perform the drm_fb_helper_is_bound() check to avoid clobbering the display palette of some other KMS client. While at it, fix up the locking by grabbing all modeset locks for the duration of the fb_setcmap operation. v2: Make a note of the locking changes in the commit message Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@gmail.com>
* drm/fb-helper: Disable cursors and planes when restoring fbdev modeVille Syrjälä2013-06-171-2/+16
| | | | | | | | | | | | Cursors and plane can obscure whatever fbdev wants to show the user. Disable them all in drm_fb_helper_restore_fbdev_mode. After the cursors and planes have been disabled, user space needs to explicitly re-enable them to make them visible again. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@gmail.com>
* Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2013-05-021-8/+15
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm updates from Dave Airlie: "This is the main drm pull request for 3.10. Wierd bits: - OMAP drm changes required OMAP dss changes, in drivers/video, so I took them in here. - one more fbcon fix for font handover - VT switch avoidance in pm code - scatterlist helpers for gpu drivers - have acks from akpm Highlights: - qxl kms driver - driver for the spice qxl virtual GPU Nouveau: - fermi/kepler VRAM compression - GK110/nvf0 modesetting support. Tegra: - host1x core merged with 2D engine support i915: - vt switchless resume - more valleyview support - vblank fixes - modesetting pipe config rework radeon: - UVD engine support - SI chip tiling support - GPU registers initialisation from golden values. exynos: - device tree changes - fimc block support Otherwise: - bunches of fixes all over the place." * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (513 commits) qxl: update to new idr interfaces. drm/nouveau: fix build with nv50->nvc0 drm/radeon: fix handling of v6 power tables drm/radeon: clarify family checks in pm table parsing drm/radeon: consolidate UVD clock programming drm/radeon: fix UPLL_REF_DIV_MASK definition radeon: add bo tracking debugfs drm/radeon: add new richland pci ids drm/radeon: add some new SI PCI ids drm/radeon: fix scratch reg handling for UVD fence drm/radeon: allocate SA bo in the requested domain drm/radeon: fix possible segfault when parsing pm tables drm/radeon: fix endian bugs in atom_allocate_fb_scratch() OMAPDSS: TFP410: return EPROBE_DEFER if the i2c adapter not found OMAPDSS: VENC: Add error handling for venc_probe_pdata OMAPDSS: HDMI: Add error handling for hdmi_probe_pdata OMAPDSS: RFBI: Add error handling for rfbi_probe_pdata OMAPDSS: DSI: Add error handling for dsi_probe_pdata OMAPDSS: SDI: Add error handling for sdi_probe_pdata OMAPDSS: DPI: Add error handling for dpi_probe_pdata ...
| * drm: add initial_config function to fb helperJesse Barnes2013-03-261-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than building a config which may or may not work, let the driver build an initial fb config. This allows the driver to use the BIOS boot configuration for example, displaying kernel messages and the initial fb console on the same outputs the BIOS lit up at boot time. If that fails, the driver can still fall back the same way as the core. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: dri-devel@lists.freedesktop.org Acked-by: Dave Airlie <airlied@gmail.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/fb-helper: Fix locking in drm_fb_helper_hotplug_eventDaniel Vetter2013-04-121-3/+5
|/ | | | | | | | | | | | | Driver's and ->fill_modes functions are allowed to grab crtc mutexes (for e.g. load detect). Hence we need to first only grab the general kms mutex, and only in a second step grab all locks to do the modesets. This prevents a deadlock on my gm45 in the tv load detect code called by drm_helper_probe_single_connector_modes. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/fb-helper: don't sleep for screen unblank when an oopps is in progressDaniel Vetter2013-02-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise the system will burn even brighter and worse, leave the user wondering what's going on exactly. Since we already have a panic handler which will (try) to restore the entire fbdev console mode, we can just bail out. Inspired by a patch from Konstantin Khlebnikov. The callchain leading to this, cut&pasted from Konstantin's original patch: callstack: panic() bust_spinlocks(1) unblank_screen() vc->vc_sw->con_blank() fbcon_blank() fb_blank() info->fbops->fb_blank() drm_fb_helper_blank() drm_fb_helper_dpms() drm_modeset_lock_all() mutex_lock(&dev->mode_config.mutex) Note that the entire locking in the fb helper around panic/sysrq and kdbg is ... non-existant. So we have a decent change of blowing up everything. But since reworking this ties in with funny concepts like the fbdev notifier chain or the impressive things which happen around console_lock while oopsing, I'll leave that as an exercise for braver souls than me. v2: Drop the -EBUSY return value I've copied, we don't need it since the we'll take care of things ourselves anyway. Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Andrew Morton <akpm@linux-foundation.org> References: https://patchwork.kernel.org/patch/1878181/ Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/fb-helper: improve kerneldocDaniel Vetter2013-02-141-15/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the fbdev helper interface for drivers is trimmed down, update the kerneldoc for all the remaining exported functions. I've tried to beat the DocBook a bit by reordering the function references a bit into a more sensible ordering. But that didn't work out at all. Hence just extend the in-code DOC: section a bit. Also remove the LOCKING: sections - especially for the setup functions they're totally bogus. But that's not a documentation problem, but simply an artifact of the current rather hazardous locking around drm init and even more so around fbdev setup ... v2: Some further improvements: - Also add documentation for drm_fb_helper_single_add_all_connectors, Dave Airlie didn't want me to kill this one from the fb helper interface. - Update docs for drm_fb_helper_fill_var/fix - they should be used from the driver's ->fb_probe callback to setup the fbdev info structure. - Clarify what the ->fb_probe callback should all do - it needs to setup both the fbdev info and allocate the drm framebuffer used as backing storage. - Add basic documentaation for the drm_fb_helper_funcs driver callback vfunc. v3: Implement clarifications Laurent Pinchart suggested in his review. v4: Fix another mispelling Laurent spotted. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/fb-helper: streamline drm_fb_helper_single_fb_probeDaniel Vetter2013-02-141-14/+15
| | | | | | | | | No need to check whether we've allocated a new fb since we're not always doing that. Also, we always need to register the fbdev and add it to the panic notifier. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/fb-helper: directly call set_par from the hotplug handlerDaniel Vetter2013-02-141-3/+3
| | | | | | | | | | | | | | | | | The idea behind calling down into the driver's ->fb_probe function on each hotplug seems to be able to reallocate the backing storage (if e.g. a screen with higher resolution gets added). But that requires quite a bit of work in the fb helper itself, since currently we limit new screens to the currently allocated fb. An no kms driver supports fbdev fb resizing. So don't bother and start to simplify the code by calling drm_fb_helper_set_par directly from the fbdev hotplug function, since that's the only thing left in drm_fb_helper_single_fb_probe which does not concern itself with fb allocation and initial setup. Follow-on patches will streamline the initial setup code. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/fb-helper: fixup set_config semanticsDaniel Vetter2013-02-141-4/+23
| | | | | | | | | | | | | | | | | | | | | | | | | While doing the modeset rework for drm/i915 I've noticed that the fb helper is very liberal with the semantics of the ->set_config interface: - It doesn't bother clearing stale modes (e.g. when unplugging a screen). - It unconditionally sets the fb, even if no mode will be set on a given crtc. - The initial setup is a bit fun since we need to pick crtcs to decide the desired fb size, but also should set the modeset->fb pointer. Explain what's going on in the fixup code after the fb is allocated. The crtc helper didn't really care, but the new i915 modeset infrastructure did, so I've had to add a bunch of special-cases to catch this. Fix this all up and enforce the interface by converting the checks in drm/i915/intel_display.c to BUG_ONs. v2: Fix commit message spell fail spotted by Rob Clark. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/fb-helper: don't disable everything in initial_configDaniel Vetter2013-02-141-3/+0
| | | | | | | | | | | | | | This should be done in the drivers for two reasons: - it gets in the way of fastboot efforts - it links the fb helpers with the crtc helpers instead of going through the real interface vfuncs, forcing i915 to fake all the ->disable callbacks used by the crtc helper to avoid ugly Oopsen v2: Resolve conflicts since drivers still call drm_fb_helper_single_add_all_connectors. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/fb-helper: unexport drm_fb_helper_single_fb_probeDaniel Vetter2013-02-141-3/+2
| | | | | | | | | | Not called by anyone, and really, shouldn't be. Drivers are supposed either drm_fb_helper_initial_config or drm_fb_helper_hotplug_event. Originally this was done differently, but is now consolidated in the helper functions and no longer done by drivers directly. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/fb-helper: unexport drm_fb_helper_panicDaniel Vetter2013-02-141-2/+1
| | | | | | | | | | | | | | | It doesn't even show up in any header files and only used iternally. Originally it was (ab)used to restore the fbcon on lastclose, but that died with commit e8e7a2b8ccfdae0d4cb6bd25824bbedcd42da316 Author: Dave Airlie <airlied@redhat.com> Date: Thu Apr 21 22:18:32 2011 +0100 drm/i915: restore only the mode of this driver on lastclose (v2) Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/fb-helper: kill drm_fb_helper_restoreDaniel Vetter2013-02-141-15/+8
| | | | | | | | | | | | | | | | | | It's only used internally for the sysrq and panic handlers provided by the drm fb helper implementation. Hence just inline it, kill the export and remove the confusing kerneldoc. Driver's are supposed to call drm_fb_helper_restore_fbdev_mode on lastclose. Note that locking is totally fubar - the sysrq case doesn't take any locks at all. The panic handler probably shouldn't take any locks since it'll only make things worse. Otoh it's probably better to switch things over to the atomic modeset callbacks (and disable the panic handler for those drivers which don't implement it). But that's both better done in separate patches. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: review locking for drm_fb_helper_restore_fbdev_modeDaniel Vetter2013-02-141-0/+11
| | | | | | | | | | | | | | | | | ... it's required. Fix up exynos and the cma helper, and add a corresponding WARN_ON to drm_fb_helper_restore_fbdev_mode. Note that tegra calls the fbdev cma helper restore function also from it's driver-load callback. Which is a bit against current practice, since usually the call is only from ->lastclose, and initial setup is done by drm_fb_helper_initial_config. Also add the relevant drm DocBook entry. v2: Add promised WARN to restore_fbdev_mode. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/fb_helper: check whether fbcon is boundDaniel Vetter2013-01-201-10/+29
| | | | | | | | | | | | | | | | | | | | We need to make sure that the fbcon is still bound when touching the hw, since otherwise we might corrupt the modeset state of kms clients. X mostly works around that with VT switching and setting the VT into raw mode, which disables most fbcon events. Raw kms test programs though don't do that dance, and in the future we might want to aim to abolish CONFIG_VT anyway. So improve preventive measures a bit. To do so, extract the existing logic for handling hotplug events (which X can't block with the current set of tricks) and reuse it for the fbdev blanking helper. Long-term we really need to either scrap this all and only have a OOPS console, or come up with a saner model for device ownership sharing between fbdev/fbcon and kms userspace. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: add drm_modeset_lock|unlock_allDaniel Vetter2013-01-201-10/+10
| | | | | | | | | | | | | | | This is the first step towards introducing the new modeset locking scheme. The plan is to put helper functions into place at all the right places step-by-step, so that the final patch to switch on the new locking scheme doesn't need to touch every single driver. This helper here will serve as the shotgun solutions for all places where a more fine-grained locking isn't (yet) implemented. v2: Fixup kerneldoc for unlock_all. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: encapsulate crtc->set_config callsDaniel Vetter2013-01-201-3/+3
| | | | | | | | | With refcounting we need to adjust framebuffer refcounts at each callsite - much easier to do if they all call the same little helper function. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: remove legacy drm_connector_property fxnsRob Clark2012-11-301-1/+1
| | | | | | | | | | | Replace references to and remove the connector property fxns, which have been superseded with the more general object property fxns: + drm_connector_attach_property -> drm_object_attach_property + drm_connector_property_set_value -> drm_object_property_set_value + drm_connector_property_get_value -> drm_object_property_get_value Signed-off-by: Rob Clark <rob@ti.com>
* drm/doc: integrate fb helper reference into docsDaniel Vetter2012-11-281-4/+15
| | | | | | | | | | | | Again only minimal changes to make kerneldoc no longer shout. Plus a little introduction in the form of a inline DOC: section to quickly explain what this is all about. v2: Fixup spelling fail. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/fb_helper: Fix potential NULL pointer dereferenceSachin Kamat2012-11-201-0/+6
| | | | | | | | | | | | | | kcalloc returns NULL on failure. Hence check for the return value and exit on error to avoid NULL pointer dereference. Fixes the following smatch errors: drivers/gpu/drm/drm_fb_helper.c:1271 drm_setup_crtcs() error: potential null dereference 'modes'. (kcalloc returns null) drivers/gpu/drm/drm_fb_helper.c:1272 drm_setup_crtcs() error: potential null dereference 'crtcs'. (kcalloc returns null) Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/drm_fb_helper: Remove unnecessary bracesSachin Kamat2012-11-201-13/+10
| | | | | | | | | | Remove unnecessary braces to silence the following type of checkpatch warnings: WARNING: braces {} are not necessary for single statement blocks WARNING: braces {} are not necessary for any arm of this statement Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/fb_helper: Convert printk to pr_* and dev_*Sachin Kamat2012-11-201-6/+8
| | | | | | | Converted printks to pr_* and dev_* to silence checkpatch warnings. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/fb_helper: Fix checkpatch errorsSachin Kamat2012-11-201-3/+9
| | | | | | | | | | | | | | | | Fixes the following checkpatch errors: ERROR: trailing statements should be on next line 98: FILE: gpu/drm/drm_fb_helper.c:98: case DRM_FORCE_OFF: s = "OFF"; break; ERROR: trailing statements should be on next line 99: FILE: gpu/drm/drm_fb_helper.c:99: case DRM_FORCE_ON_DIGITAL: s = "ON - dig"; break; ERROR: trailing statements should be on next line 101: FILE: gpu/drm/drm_fb_helper.c:101: case DRM_FORCE_ON: s = "ON"; break; Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2012-10-031-8/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm merge (part 1) from Dave Airlie: "So first of all my tree and uapi stuff has a conflict mess, its my fault as the nouveau stuff didn't hit -next as were trying to rebase regressions out of it before we merged. Highlights: - SH mobile modesetting driver and associated helpers - some DRM core documentation - i915 modesetting rework, haswell hdmi, haswell and vlv fixes, write combined pte writing, ilk rc6 support, - nouveau: major driver rework into a hw core driver, makes features like SLI a lot saner to implement, - psb: add eDP/DP support for Cedarview - radeon: 2 layer page tables, async VM pte updates, better PLL selection for > 2 screens, better ACPI interactions The rest is general grab bag of fixes. So why part 1? well I have the exynos pull req which came in a bit late but was waiting for me to do something they shouldn't have and it looks fairly safe, and David Howells has some more header cleanups he'd like me to pull, that seem like a good idea, but I'd like to get this merge out of the way so -next dosen't get blocked." Tons of conflicts mostly due to silly include line changes, but mostly mindless. A few other small semantic conflicts too, noted from Dave's pre-merged branch. * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (447 commits) drm/nv98/crypt: fix fuc build with latest envyas drm/nouveau/devinit: fixup various issues with subdev ctor/init ordering drm/nv41/vm: fix and enable use of "real" pciegart drm/nv44/vm: fix and enable use of "real" pciegart drm/nv04/dmaobj: fixup vm target handling in preparation for nv4x pcie drm/nouveau: store supported dma mask in vmmgr drm/nvc0/ibus: initial implementation of subdev drm/nouveau/therm: add support for fan-control modes drm/nouveau/hwmon: rename pwm0* to pmw1* to follow hwmon's rules drm/nouveau/therm: calculate the pwm divisor on nv50+ drm/nouveau/fan: rewrite the fan tachometer driver to get more precision, faster drm/nouveau/therm: move thermal-related functions to the therm subdev drm/nouveau/bios: parse the pwm divisor from the perf table drm/nouveau/therm: use the EXTDEV table to detect i2c monitoring devices drm/nouveau/therm: rework thermal table parsing drm/nouveau/gpio: expose the PWM/TOGGLE parameter found in the gpio vbios table drm/nouveau: fix pm initialization order drm/nouveau/bios: check that fixed tvdac gpio data is valid before using it drm/nouveau: log channel debug/error messages from client object rather than drm client drm/nouveau: have drm debugging macros build on top of core macros ...
| * drm/fb helper: don't call drm_helper_connector_dpms directlyDaniel Vetter2012-09-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Yet again a case where the fb helper is too intimate with the crtc helper and calls a crtc helepr function directly instead of going through the interface vtable. This fixes console blanking in drm/i915 with the new i915-specific modeset code. Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel ↵Dave Airlie2012-09-031-6/+0
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next Daniel writes: "New stuff for -next. Highlights: - prep patches for the modeset rework. Note that one of those patches touches the fb helper in the common drm code. - hasw hdmi audio support (Wang Xingchao) - improved instdone dumping for gen7 (Ben) - unbound tracking and a few follow-up patches from Chris - dma_buf->begin/end_cpu_access plus fix for drm/udl (Dave) - improve mmio error reporting for hsw - prep patch for WQ_NON_REENTRANT removal (Tejun Heo) " * 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (41 commits) drm/i915: Remove __GFP_NO_KSWAPD drm/i915: disable rc6 on ilk when vt-d is enabled drm/i915: Avoid unbinding due to an interrupted pin_and_fence during execbuffer drm/i915: Use new INSTDONE registers (Gen7+) drm/i915: Add new INSTDONE registers drm/i915: Extract reading INSTDONE drm/i915: Use a non-blocking wait for set-to-domain ioctl drm/i915: Juggle code order to ease flow of the next patch drm/i915: Use cpu relocations if the object is in the GTT but not mappable drm/i915: Extract general object init routine drm/i915: Protect private gem objects from truncate (such as imported dmabuf) drm/i915: Only pwrite through the GTT if there is space in the aperture i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1 drm/i915: Find unclaimed MMIO writes. drm/i915: Add ERR_INT to gen7 error state drm/i915: Cantiga+ cannot handle a hsync front porch of 0 drm/i915: fix reassignment of variable "intel_dp->DP" drm/i915: Try harder to allocate an mmap_offset drm/i915: Show pin count in debugfs drm/i915: Show (count, size) of purgeable objects in i915_gem_objects ...
| | * drm/fb-helper: don't clobber output routing in setup_crtcsDaniel Vetter2012-08-171-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Yet again the too close relationship between the fb helper and the crtc helper code strikes. This time around the fb helper resets all encoder->crtc pointers to NULL before starting to set up it's own mode. Which is total bullocks, because this will clobber the existing output routing, which the new drm/i915 code depends upon to be absolutely correct. The crtc helper itself doesn't really care about that, since it disables unused encoders in a rather roundabout way anyway. Two places call drm_setup_crts: - For the initial fb config. I've auditted all current drivers, and they all allocate their encoders with kzalloc. So there's no need to clear encoder->crtc once more. - When processing hotplug events while showing the fb console. This one is a bit more tricky, but both the crtc helper code and the new drm/i915 modeset code disable encoders if their crtc is changed and that encoder isn't part of the new config. Also, both disable any disconnected outputs, too. Which only leaves encoders that are on, connected, but for some odd reason the fb helper code doesn't want to use. That would be a bug in the fb configuration selector, since it tries to light up as many outputs as possible. v2: Kill the now unused encoders variable. Acked-by: Dave Airlie <airlied@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm: Add misssing static storage class specifier in drm_fb_helper.c fileSachin Kamat2012-08-241-1/+1
| |/ | | | | | | | | | | | | | | | | Fixes the following sparse warning: drivers/gpu/drm/drm_fb_helper.c:239:6: warning: symbol 'drm_fb_helper_force_kernel_mode' was not declared. Should it be static? Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells2012-10-021-4/+4
|/ | | | | | | | | | | Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
* drm/fb helper: don't call drm_crtc_helper_set_configDaniel Vetter2012-07-191-1/+1
| | | | | | | | | Go through the interface vtable instead, because not everyone might be using the crtc helper code. Cc: dri-devel@lists.freedesktop.org Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/fb-helper: delay hotplug handling when partially boundDaniel Vetter2012-07-191-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ok, this requires quite a dance to actually hit: 1) We plug in a 2nd screen, enable it in both X and (by vt-switching) in the fbcon. 2) We disable that screen again in with xrandr. 3) We vt-switch again, so that fbcon displays on the 2nd screen, but X on the first screen. This obviously needs a driver that doesn't switch off unused functions when regaining the VT. 3) When X controls the vt, we unplug that screen. Now drm_fb_helper_hotplug_event we noticed that that some crtcs are bound, but because we still have the fbcon on the 2nd screeen we also have bound set. Which means the fbcon wrongly assumes it's in control of everything an happily disables the output on the 2nd screen, but enables its fb on the first screen. Work around this issue by counting how many crtcs are bound and how many are bound to fbcon and assuming that when fbcon isn't bound to all of them, it better not touch the output configuration. Conceptually this is the same as only restoring the fbcon output configuration on the driver's ->lastclose, when we're sure that no one else is using kms. So this should be consistent with existing kms drivers. Chris has created a separate patch for the intel ddx, but I think we should fix this issue here regardless - the fbcon messing with the output config while it's not fully in control simply isn't a too polite behaviour. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50772 Tested-by: Maxim A. Nikulin <M.A.Nikulin@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Make the CRTC gamma_set operation optionalLaurent Pinchart2012-05-221-0/+3
| | | | | | | | | Drivers for hardware without gamma support should not be forced to implement a no-op gamma set operation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Rob Clark <rob.clark@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Don't initialize local ret variable when not neededLaurent Pinchart2012-05-221-4/+1
| | | | | | Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Allow drm_mode_find_dmt to hunt for reduced-blanking modesAdam Jackson2012-04-201-1/+1
| | | | | | | | | | | | | | It won't find any, yet. Fix up callers to match: standard mode codes will look prefer r-b modes for a given size if present, EST3 mode codes will look for exactly the r-b-ness mentioned in the mode code. This might mean fewer modes matched for EST3 mode codes between now and when the DMT mode list regrows the r-b modes, but practically speaking EST3 codes don't exist in the wild. Signed-off-by: Adam Jackson <ajax@redhat.com> Tested-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Validate requested virtual size against allocated fb sizeChris Wilson2012-04-031-2/+6
| | | | | | | | | | | | | | | | mplayer -vo fbdev tries to create a screen that is twice as tall as the allocated framebuffer for "doublebuffering". By default, and all in-tree users, only sufficient memory is allocated and mapped to satisfy the smallest framebuffer and the virtual size is no larger than the actual. For these users, we should therefore reject any userspace request to create a screen that requires a buffer larger than the framebuffer originally allocated. References: https://bugs.freedesktop.org/show_bug.cgi?id=38138 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm fb helper: remove unused variable crtc_idSascha Hauer2012-02-031-1/+0
| | | | | | | | crtc_id is set but never used, so remove it from struct drm_fb_helper_crtc. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm fb helper: remove unused variable conn_limitSascha Hauer2012-02-031-1/+1
| | | | | | | | conn_limit is set but never used. Remove it from struct drm_fb_helper. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm fb helper: use drm_helper_connector_dpms to do dpmsSascha Hauer2012-02-031-70/+10
| | | | | | | | drm_fb_helper_on|off currently manually searches for encoders to turn on/off. Make this simpler by using the helper function. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm drm_fb_helper: destroy modesSascha Hauer2012-02-031-1/+4
| | | | | | | | drm_setup_crtcs allocated modes using drm_mode_duplicate. Free them in drm_fb_helper_crtc_free. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: avoid switching to text console if there is no panic timeoutHugh Dickins2011-11-101-0/+7
| | | | | | | | | | | | | | | | Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if we're going to reboot immediately, the user will not be able to see the messages anyway, and messing with the video mode may display artifacts, and certainly get into several layers of complexity (including mutexes and memory allocations) which we shall be much safer to avoid. Signed-off-by: Hugh Dickins <hughd@google.com> [ Edited commit message and modified to short-circuit panic_timeout < 0 instead of testing panic_timeout >= 0. -Mandeep ] Signed-off-by: Mandeep Singh Baines <msb@chromium.org> Acked-by: David Rientjes <rientjes@google.com> Acked-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* gpu: add module.h to drivers/gpu files as required.Paul Gortmaker2011-10-311-0/+1
| | | | | | | So that we don't get build failures once the implicit module.h presence is removed. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* drm: Remove duplicate "return" statementLin Ming2011-09-091-1/+0
| | | | | | | Remove the duplicate "return" statement in drm_fb_helper_panic(). Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Export the command-line mode parserChris Wilson2011-04-281-171/+36
| | | | | | | | | | | In the absence of configuration data for providing the fixed mode for a panel, I would like to be able to pass such modes along a separate module paramenter. To do so, I then need to parse a modeline from a string, which drm is already capable of. Export that capability to the drivers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Take lock around probes for drm_fb_helper_hotplug_eventChris Wilson2011-04-281-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to hold the dev->mode_config.mutex whilst detecting the output status. But we also need to drop it for the call into drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when attaching the fbcon. Failure to do so exposes a race with normal output probing. Detected by adding some warnings that the mutex is held to the backend detect routines: [ 17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]() [ 17.772458] Hardware name: Latitude E6400 [ 17.772460] Modules linked in: .... [ 17.772582] Pid: 11, comm: kworker/0:1 Tainted: G W 2.6.38.4-custom.2 #8 [ 17.772584] Call Trace: [ 17.772591] [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c [ 17.772603] [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915] [ 17.772612] [<ffffffffa0355d49>] ? drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper] [ 17.772619] [<ffffffffa03534d5>] ? drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper] [ 17.772625] [<ffffffffa0354760>] ? drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper] [ 17.772633] [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper] [ 17.772638] [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345 [ 17.772644] [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper] [ 17.772648] [<ffffffff8105b540>] ? process_one_work+0x193/0x28e [ 17.772652] [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172 [ 17.772655] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172 [ 17.772658] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172 [ 17.772663] [<ffffffff8105f767>] ? kthread+0x7a/0x82 [ 17.772668] [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10 [ 17.772671] [<ffffffff8105f6ed>] ? kthread+0x0/0x82 [ 17.772674] [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10 Reported-by: Frederik Himpe <fhimpe@telenet.be> References: https://bugs.freedesktop.org/show_bug.cgi?id=36394 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915: restore only the mode of this driver on lastclose (v2)Dave Airlie2011-04-271-7/+20
| | | | | | | | | | | | | | | i915 calls the panic handler function on last close to reset the modes, however this is a really bad idea for multi-gpu machines, esp shareable gpus machines. So add a new entry point for the driver to just restore its own fbcon mode. v2: move code into fb helper, fix panic code to block mode change on powered off GPUs. [airlied: this hits drm core and I wrote it and it was reviewed on intel-gfx so really I signed it off twice ;-).] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge commit '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into drm-core-nextDave Airlie2011-03-161-2/+2
|\ | | | | | | | | | | | | | | | | | | This commit changed an internal radeon structure, that meant a new driver in -next had to be fixed up, merge in the commit and fix up the driver. Also fixes a trivial nouveau merge. Conflicts: drivers/gpu/drm/nouveau/nouveau_mem.c
generated by cgit v1.1 at 2024-11-01 04:29:07 +0000