- 16 Feb, 2013 7 commits
-
-
Daniel Vetter authored
We don't need to hold onto mode_config.mutex any more to keep the fb objects around. And locking dev->struct_mutex is also not required, since omap_gem_describe only reads data anyway. And for a debug interface it's better to grab fewer locks in case the driver is deadlocked already ... The only thing we need is to hold onto mode_config.fb_lock to ensure the user-created fbs don't disappear. The fbcon fb doesn't need any protection, since it lives as long as the driver (and so the debugfs files) itself. And if the teardown/setup isn't following the right sequence grabbing locks won't prevent a NULL deref on priv->fbdev if the fb is not yet (or no longer) there. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Daniel Vetter authored
Omapdrm doesn't do anything nefarious with crtc load detection or has any shared resources, so this is enough. We also need to adjust the WARN_ON. Signed-off-by:
-
Rob Clark authored
Now that the omapdss interface has been reworked so that omapdrm can use dispc directly, we have been able to fix the remaining functional kms issues with omapdrm. And in the mean time the PM sequencing and many other of that open issues have been solved. So I think it makes sense to finally move omapdrm out of staging. Signed-off-by: -
Peter Huewe authored
Found with coccicheck. The semantic patch that makes this change is available in scripts/coccinelle/api/memdup.cocci. Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
Rob Clark <rob@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Cong Ding authored
There is a memory leakage in variable sg if it goes to error. Signed-off-by:
Cong Ding <dinggnu@gmail.com> Signed-off-by:
-
Andy Gross authored
Add support for OMAP5 processor. The main differences are that the OMAP5 has 2 containers, one for 1D and one for 2D. Each container is 128MiB in size. Signed-off-by:
Andy Gross <andy.gross@ti.com> Signed-off-by:
-
Andy Gross authored
Added power management capabilities into the omapdrm and DMM drivers. During suspend, we don't need to do anything to maintain the state of the LUT. We have all the necessary information to recreate the mappings of the GEM object list maintained by the omapdrm driver. On resume, the DMM resume handler will first reprogram the LUT to point to the dummy page. The subsequent resume handler in the omapdrm will call into the DMM and reprogram each of the buffer objects. This will ensure that all of the necessary objects will be pinned into the DMM properly. Order of suspend/resume handlers is done by device creation. We create the DMM device before the omapdrm, so the correct order is maintained. Signed-off-by:
-
- 15 Feb, 2013 4 commits
-
-
git://people.freedesktop.org/~danvet/drmDave Airlie authored
This is the drm fb helper cleanup, mostly motivated by strange things I've seen in my locking rework and the i915 modeset revamp. Compared to the original submission I've reinstated the setup flexibility you'd like to retain, kerneldoc has been reviewed by Laurent Pinchart and Rob Clark reviewed the code changes. Quick overview of the changes: - Cleaned-up library interface for drivers using the fb helper, also simplified the fb allocation callback since no driver supported reallocating the fb on-the-fly. And the fbdev/fbcon code keeps pointers to the old mapping around anyway, so reallocating backing storage will be much more work. - No longer call the crtc helper "disable everything" function at init time, but allow drivers to do so. Motivated by i915's fastboot effort and allows us to drop a bunch of noop dummy functions just to avoid calling NULL function pointers from i915.ko. - Properly clear old state when doing modeset calls, the fb helper left some old modes in there and unconditionally set an fb (even when disabling a crtc). The crtc helpers didn't care, but i915 modeset code can now drop a few special cases. - Full kerneldoc for the fb helper. Yay! - My version of the "don't sleep in panic ->unblank calls". The patch is already in -mm, I guess Andrew can drop it as soon as this pull lands in drm-next. * 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm: drm/fb-helper: remove unused members of struct drm_fb_helper drm/fb-helper: don't sleep for screen unblank when an oopps is in progress drm/fb-helper: improve kerneldoc drm/<drivers>: simplify ->fb_probe callback drm/fb-helper: streamline drm_fb_helper_single_fb_probe drm/fb-helper: directly call set_par from the hotplug handler drm/fb-helper: fixup set_config semantics drm/i915: rip out helper->disable noop functions drm/fb-helper: don't disable everything in initial_config drm/tegra: don't set up initial fbcon config twice drm/fb-helper: unexport drm_fb_helper_single_fb_probe drm/fb-helper: unexport drm_fb_helper_panic drm/fb-helper: kill drm_fb_helper_restore drm: review locking for drm_fb_helper_restore_fbdev_mode
-
Maarten Lankhorst authored
My cheapo monitor has an invalid block 1, resulting in a lot of dmesg spam every few seconds. I get it the first time that the entire block is all 0xff.. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: stable@vger.kernel.org [v3.7] Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Chris Metcalf authored
On tile architecture (with "make allyesconfig") including <linux/swiotlb.h> is required to call swiotlb_nr_tbl(). Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Acked-by:
-
Bjorn Helgaas authored
Move drm_pcie_get_speed_cap_mask() under #ifdef CONFIG_PCI because it it used only for PCI devices (evergreen, r600, r770), and it uses PCI interfaces that only exist when CONFIG_PCI=y. Previously, we tried to compile drm_pcie_get_speed_cap_mask() even when CONFIG_PCI=n, which fails. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- 13 Feb, 2013 15 commits
-
-
Daniel Vetter authored
Spotted by Rob Clark. Reviewed-by:
-
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
The fb helper lost its support for reallocating an fb completely, so no need to return special success values any more. Reviewed-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
Now that the driver is in control of whether it needs to disable everything at take-over or not, we can rip this all out. Signed-off-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
drm_fbdev_cma_init does the inital fbcon setup by calling down into drm_fb_helper_initial_config, so no need at all to restore the just set up configuration right away ... Signed-off-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:
-
Daniel Vetter authored
This reverts commit 6f33814b. The quirk cause a regression, and it looks like the original bug was simply a lack of FIFO bandwidth on the i915G of the reporter. Which should eventually be fixed as soon as we get around to implemented DSPARB FIFO reassignment on gen 3. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281 Cc: stable@vger.kernel.org Signed-off-by:
-
- 08 Feb, 2013 14 commits
-
-
git://people.freedesktop.org/~mlankhorst/linuxDave Airlie authored
TTM reservations changes, preparing for new reservation mutex system. * 'for-airlied' of git://people.freedesktop.org/~mlankhorst/linux: drm/ttm: unexport ttm_bo_wait_unreserved drm/nouveau: use ttm_bo_reserve_slowpath in validate_init, v2 drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers, v2 drm/ttm: add ttm_bo_reserve_slowpath drm/ttm: cleanup ttm_eu_reserve_buffers handling drm/ttm: remove lru_lock around ttm_bo_reserve drm/nouveau: increase reservation sequence every retry drm/vmwgfx: always use ttm_bo_is_reserved
-
Daniel Kurtz authored
It is a bit more precise to compute the total number of pixels first and then divide, rather than multiplying the line pixel count by the already-rounded line duration. Signed-off-by:
Daniel Kurtz <djkurtz@chromium.org> Signed-off-by:
-
Bjorn Helgaas authored
Use PCI Express Capability access functions to simplify this code a bit. For non-PCIe devices or pre-PCIe 3.0 devices that don't implement the Link Capabilities 2 register, pcie_capability_read_dword() reads a zero. Since we're only testing whether the bits we care about are set, there's no need to mask out the other bits we *don't* care about. Signed-off-by:
-
Bjorn Helgaas authored
For devices that conform to PCIe r3.0 and have a Link Capabilities 2 register, we test and report every bit in the Supported Link Speeds Vector field. For a device that supports both 2.5GT/s and 5.0GT/s, we set both DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in the returned mask. For pre-r3.0 devices, the Link Capabilities 0010b encoding (PCI_EXP_LNKCAP_SLS_5_0GB) means that both 5.0GT/s and 2.5GT/s are supported, so set both DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in this case as well. Signed-off-by:
-
Bjorn Helgaas authored
Use the standard #defines rather than bare numbers for the PCIe Link Capabilities speed bits. Signed-off-by:
-
Thierry Reding authored
Drivers that register interrupt handlers without the DRM core helpers don't initialize the .irq_enabled field and drm_dev_to_irq() may fail when called on them. This shouldn't preclude them from implementing the vblank IOCTL. Signed-off-by:
Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by:
-
Aaron Plattner authored
Simplify the Radeon prime implementation by using the default behavior provided by drm_gem_prime_import and drm_gem_prime_export. v2: - Rename functions to radeon_gem_prime_get_sg_table and radeon_gem_prime_import_sg_table. - Delete the now-unused vmapping_count variable. Signed-off-by:
Aaron Plattner <aplattner@nvidia.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Signed-off-by:
-
Aaron Plattner authored
Simplify the Nouveau prime implementation by using the default behavior provided by drm_gem_prime_import and drm_gem_prime_export. v2: Rename functions to nouveau_gem_prime_get_sg_table and nouveau_gem_prime_import_sg_table. Signed-off-by:
-
Aaron Plattner authored
Instead of reimplementing all of the dma_buf functionality in every driver, create helpers drm_prime_import and drm_prime_export that implement them in terms of new, lower-level hook functions: gem_prime_pin: callback when a buffer is created, used to pin buffers into GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for export gem_prime_import_sg_table: convert an sg_table into a drm_gem_object gem_prime_vmap, gem_prime_vunmap: map and unmap an object These hooks are optional; drivers can opt in by using drm_gem_prime_import and drm_gem_prime_export as the .gem_prime_import and .gem_prime_export fields of struct drm_driver. v2: - Drop .begin_cpu_access. None of the drivers this code replaces implemented it. Having it here was a leftover from when I was trying to include i915 in this rework. - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers did. This patch series shouldn't change that behavior. - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table. Rename struct sg_table* variables to 'sgt' for clarity. - Update drm.tmpl for these new hooks. v3: - Pass the vaddr down to the driver. This lets drivers that just call vunmap on the pointer avoid having to store the pointer in their GEM private structures. - Move documentation into a /** DOC */ comment in drm_prime.c and include it in drm.tmpl with a !P line. I tried to use !F lines to include documentation of the individual functions from drmP.h, but the docproc / kernel-doc scripts barf on that file, so hopefully this is good enough for now. - apply refcount fix from commit be8a42ae ("drm/prime: drop reference on imported dma-buf come from gem") Signed-off-by:
-
Rob Clark authored
Move this out of nouveau directory. As we start to add more encoder slaves used by other drivers, it makes sense to put the Kconfig bits in one place. Signed-off-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Alex writes: - CS ioctl cleanup and unification. Unification of a lot of functionality that was duplicated across multiple generates of hardware. - Add support for Oland GPUs - Deprecate UMS support. Mesa and the ddx dropped support for UMS and apparently very few people still use it since the UMS CS ioctl was broken for several kernels and no one reported it. It was fixed in 3.8/stable. - Rework GPU reset. Use the status registers to determine what blocks to reset. This better matches the recommended reset programming model. This also allows us to properly reset blocks besides GFX and DMA. - Switch the VM set page code to use an IB rather than the ring. This fixes overflow issues when doing large page table updates using a small ring like DMA. - Several small cleanups and bug fixes. * 'drm-next-3.9' of git://people.freedesktop.org/~agd5f/linux: (38 commits) drm/radeon/dce6: fix display powergating drm/radeon: add Oland pci ids drm/radeon: radeon-asic updates for Oland drm/radeon: add ucode loading support for Oland drm/radeon: fill in gpu init for Oland drm/radeon: add Oland chip family drm/radeon: switch back to using the DMA ring for VM PT updates drm/radeon: use IBs for VM page table updates v2 drm/radeon: don't reset the MC on IGPs/APUs drm/radeon: use the reset mask to determine if rings are hung drm/radeon: halt engines before disabling MC (si) drm/radeon: halt engines before disabling MC (cayman/TN) drm/radeon: halt engines before disabling MC (evergreen) drm/radeon: halt engines before disabling MC (6xx/7xx) drm/radeon: use status regs to determine what to reset (si) drm/radeon: use status regs to determine what to reset (cayman) drm/radeon: use status regs to determine what to reset (evergreen) drm/radeon: use status regs to determine what to reset (6xx/7xx) drm/radeon: rework GPU reset on cayman/TN drm/radeon: rework GPU reset on cayman/TN ...
-
git://git.pengutronix.de/git/str/linuxDave Airlie authored
videomode helpers for of + devicetree stuff, required for new kms drivers (not the fbdev maintainer). * tag 'of_videomode_helper' of git://git.pengutronix.de/git/str/linux: drm_modes: add of_videomode helpers drm_modes: add videomode helpers fbmon: add of_videomode helpers fbmon: add videomode helpers video: add of helper for display timings/videomode video: add display_timing and videomode viafb: rename display_timing to via_display_timing
-
Dave Airlie authored
Fixes for usb/udl devices * udl-fixes: drm/udl: disable fb_defio by default drm/udl: Inline memcmp() for RLE compression of xfer drm/udl: make usage as a console safer drm/usb: bind driver to correct device
-
Dave Airlie authored
(not the fbcon maintainer pull 2) fix bug in vgacon on bootup and fbcon losing fonts on startup. * console-fixes: (50 commits) fbcon: don't lose the console font across generic->chip driver switch vgacon/vt: clear buffer attributes when we load a 512 character font (v2)
-
