- Sep 19, 2013
-
-
Daniel Vetter authored
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>
-
- Jun 17, 2013
-
-
Ville Syrjälä authored
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:
Dave Airlie <airlied@gmail.com>
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
- Apr 12, 2013
-
-
Daniel Vetter authored
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:
-
- Mar 26, 2013
-
-
Jesse Barnes authored
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:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
- Feb 13, 2013
-
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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 authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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 e8e7a2b8 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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
... 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:
-
- Jan 20, 2013
-
-
Daniel Vetter authored
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 authored
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:
-
Daniel Vetter authored
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:
-
- Nov 30, 2012
-
-
Rob Clark authored
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:
-
- Nov 28, 2012
-
-
Daniel Vetter authored
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:
-
- Nov 20, 2012
-
-
Sachin Kamat authored
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:
-
Sachin Kamat authored
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 authored
Converted printks to pr_* and dev_* to silence checkpatch warnings. Signed-off-by:
-
Sachin Kamat authored
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:
-
- Oct 02, 2012
-
-
David Howells authored
Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by:
David Howells <dhowells@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>
-
- Sep 07, 2012
-
-
Daniel Vetter authored
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:
-
- Aug 24, 2012
-
-
Sachin Kamat authored
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:
-
- Aug 17, 2012
-
-
Daniel Vetter authored
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:
-
- Jul 20, 2012
-
-
Daniel Vetter authored
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 authored
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:
-
- May 22, 2012
-
-
Laurent Pinchart authored
Drivers for hardware without gamma support should not be forced to implement a no-op gamma set operation. Signed-off-by:
-
Laurent Pinchart authored
Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
- Apr 20, 2012
-
-
Adam Jackson authored
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:
-
- Apr 03, 2012
-
-
Chris Wilson authored
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:
-
- Feb 03, 2012
-
-
Sascha Hauer authored
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:
-
Sascha Hauer authored
conn_limit is set but never used. Remove it from struct drm_fb_helper. Signed-off-by:
-
Sascha Hauer authored
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 authored
drm_setup_crtcs allocated modes using drm_mode_duplicate. Free them in drm_fb_helper_crtc_free. Signed-off-by:
-
- Nov 10, 2011
-
-
Hugh Dickins authored
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:
-
