- 05 Jan, 2012 8 commits
-
-
Ilija Hadzic authored
drm_getcap and drm_version ioctls only reads static data, there is no need to protect them with drm_global_mutex, so make them DRM_UNLOCKED Signed-off-by:
Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Chen Jie authored
Sweep common_modes array should start with index 0. Signed-off-by:
Chen Jie <chenj@lemote.com> Reviewed-by:
-
Alex Deucher authored
We often end up missing fences on older asics with writeback enabled which leads to delays in the userspace accel code, so just disable it by default on those asics. Reported-by:
Helge Deller <deller@gmx.de> Reported-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Jerome Glisse authored
This allow to share the ib pool with semaphore and avoid having more bo around. Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
-
Jerome Glisse authored
This avoid to waste ib pool size and avoid a bunch of wait for previous ib to finish. Signed-off-by:
-
Alex Deucher authored
Signed-off-by:
-
Rob Clark authored
In cases where the scanout hw is sufficiently similar between "overlay" and traditional crtc layers, it might be convenient to allow the driver to create internal drm_plane helper objects used by the drm_crtc implementation, rather than duplicate code between the plane and crtc. A private plane is not exposed to userspace. Signed-off-by:
Rob Clark <rob@ti.com> Signed-off-by:
-
Rob Clark authored
Since plane->fb and plane->crtc are set in drm_mode_setplane() after update_plane(), They should be cleared after disable(). Signed-off-by:
-
- 03 Jan, 2012 26 commits
-
-
Jesse Barnes authored
If it failed, leave it in the "off" state. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Keith Packard <keithp@keithp.com>
-
Jesse Barnes authored
If a PCH pipe PLL is being used by transcoder C, don't disable it. Signed-off-by:
-
Daniel Vetter authored
In the pre-gem days with non-existing hangcheck and gpu reset code, this timeout of 3 seconds was pretty important to avoid stuck processes. But now we have the hangcheck code in gem that goes to great length to ensure that the gpu is really dead before declaring it wedged. So there's no need for this timeout anymore. Actually it's even harmful because we can bail out too early (e.g. with xscreensaver slip) when running giant batchbuffers. And our code isn't robust enough to properly unroll any state-changes, we pretty much rely on the gpu reset code cleaning up the mess (like cache tracking, fencing state, active list/request tracking, ...). With this change intel_begin_ring can only fail when the gpu is wedged, and it will return -EAGAIN (like wait_request in case the gpu reset is still outstanding). v2: Chris Wilson noted that on resume timers aren't running and hence we won't ever get kicked out of this loop by the hangcheck code. Use an insanely large timeout instead for the HAS_GEM case to prevent resume bugs from totally hanging the machine. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
-
Daniel Vetter authored
If our semaphore logic gets confused and we have a ring stuck waiting for one, there's a decent chance it'll just execute garbage when being kicked. Also, kicking the ring obscures the place where the error first occured, making error_state decoding much harder. So drop this an let gpu reset handle this mess in a clean fashion. In contrast, kicking rings stuck on MI_WAIT is rather harmless, at worst there'll be a bit of screen-flickering. There's also old broken userspace out there which needs this as a work-around. Signed-off-by:
Chris Wilson <chris@hchris-wilson.co.uk> Reviewed-by:
-
Eric Anholt authored
These registers are automatically incremented by the hardware during transform feedback to track where the next streamed vertex output should go. Unlike the previous generation, which had a packet for setting the corresponding registers to a defined value, gen7 only has MI_LOAD_REGISTER_IMM to do so. That's a secure packet (since it loads an arbitrary register), so we need to do it from the kernel, and it needs to be settable atomically with the batchbuffer execution so that two clients doing transform feedback don't stomp on each others' state. Instead of building a more complicated interface involcing setting the registers to a specific value, just set them to 0 when asked and userland can tweak its pointers accordingly. Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
Eric Anholt authored
The waits we do here are generally so short that sleeping is a bad idea unless we have an IRQ to wake us up. Improves regression test performance from 18 minutes to 3.5 minutes on gen7, which is now consistent with the previous generation. Signed-off-by:
-
Eric Anholt authored
Previous to this commit, testing easily reproduced a failure where the seqno would apparently arrive after the IRQ associated with it, with test programs as simple as: for (;;) { glCopyPixels(0, 0, 1, 1); glFinish(); } Various workarounds we've seen for previous generations didn't work to fix this issue, so until new information comes in, replace the IRQ waits on the BLT ring with polling. Signed-off-by: -
Eric Anholt authored
As a workaround for IRQ synchronization issues in the gen7 BLT ring, we want to turn the two wait functions into polling loops. Signed-off-by:
-
Eric Anholt authored
They don't fix our problems alone, but we're told to set them. Signed-off-by:
-
Jesse Barnes authored
Add new ioctls for getting and setting the current destination color key. This allows for simple overlay display control by matching a color key value in the primary plane before blending the overlay on top. v2: remove unnecessary mutex acquire/release around reg accesses v3: add support for full color key management v4: fix copy & paste bug in snb_get_colorkey don't bother checking min/max values against docs as the docs are likely wrong (how could we handle 10bpc surface formats?) Reviewed-by: -
Jesse Barnes authored
To save power when the sprite is full screen, we can disable the primary plane on the same pipe. Track the sprite status and enable/disable the primary opportunistically. v2: remove primary plane enable/disable hooks; they're identical Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Jesse Barnes authored
The video sprites support various video surface formats natively and can handle scaling as well. So add support for them using the new DRM core sprite support functions. v2: use drm specific fourcc header and defines v3: address Daniel's comments: - don't take struct mutex around register access (only needed for regs in the GT power well) - don't hold struct mutex across vblank waits - fix up update_plane API (pass obj instead of GTT offset) - add interlaced defines for sprite regs - drop unnecessary 'reg' variables - comment double buffered reg flushing Also fix w/h confusion when writing the scaling reg. v4: more fixes, address more comments from Daniel, and include Hai's fix - prevent divide by zero in scaling calculation (Hai Lan) - update to Ville's new DRM_FORMAT_* types - fix sprite watermark handling (calc based on CRTC size, separate from normal display wm) - remove private refcounts now that the fb cleanups handles things v5: add linear surface support v6: remove color key clearing & setting from update_plane For this version, I tested DPMS since it came up in the last review; DPMS off/on works ok when a video player is working under X, but for power saving we'll probably want to do something smarter. I'll leave that for a separate patch on top. Likewise with the refcounting/fb layer handling, which are really separate cleanups. Reviewed-by: -
Keith Packard authored
We learned that the ECOBUS register was inside the GT power well, and so *did* need force wake to be read, so it gets removed from the list of 'doesn't need force wake' registers. That means the code reading ECOBUS after forcing the mt_force_wake function to be called needs to use I915_READ_NOTRACE; it doesn't need to do more force wake fun as it's already done it manually. This also adds a comment explaining why the MT forcewake testing code only needs to call mt_forcewake_get/put and not disable RC6 manually -- the ECOBUS read will return 0 if the device is in RC6 and isn't using MT forcewake, causing the test to work correctly. Signed-off-by: -
Ben Widawsky authored
Many of the old fields from Ironlake have gone away. Strip all those fields, and try to update to fields people care about. RC information isn't exactly ideal anymore. All we can guarantee when we read the register is that we're not using forcewake, ie. the software isn't forcing the hardware to stay awake. The downside is that in doing this we may wait a while and that causes an unnaturally idle state on the GPU. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42578Signed-off-by:
-
Ben Widawsky authored
This matches the modern specs more accurately. This will be used by the following patch to fix the way we display RC status. Signed-off-by:
-
Ben Widawsky authored
The docs say this is required for Gen7, and since the bit was added for Gen6, we are also setting it there pit pf paranoia. Particularly as Chris points out, if PIPE_CONTROL counts as a 3d state packet. This was found through doc inspection by Ken and applies to Gen6+; Reported-by:
-
Ben Widawsky authored
dev_priv keeps track of the current addressing mode that gets set at execbuffer time. Unfortunately the existing code was doing this before acquiring struct_mutex which leaves a race with another thread also doing an execbuffer. If that wasn't bad enough, relocate_slow drops struct_mutex which opens a much more likely error where another thread comes in and modifies the state while relocate_slow is being slow. The solution here is to just defer setting this state until we absolutely need it, and we know we'll have struct_mutex for the remainder of our code path. v2: Keith noticed a bug in the original patch. Signed-off-by:
-
Dave Airlie authored
This merges the evergreen HDMI audio support. * 'drm-radeon-testing' of ../drm-radeon-next: drm/radeon/kms: define TMDS/LVTM HDMI enabling bits drm/radeon/kms: workaround invalid AVI infoframe checksum issue drm/radeon/kms: setup HDMI mode on Evergreen encoders drm/radeon/kms: support for audio on Evergreen drm/radeon/kms: minor HDMI audio cleanups drm/radeon/kms: do not force DVI mode on DCE4 if audio is on ridge Conflicts: drivers/gpu/drm/radeon/evergreen.c
-
Rafał Miłecki authored
The names has been taken from free M76 specs. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Reviewed-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Rafał Miłecki authored
This change was verified to fix both issues with no video I've investigated. I've also checked checksum calculation with fglrx on: RV620, HD54xx, HD5450, HD6310, HD6320. Cc: stable@vger.kernel.org Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
git://people.freedesktop.org/~keithp/linuxDave Airlie authored
* 'drm-intel-next' of git://people.freedesktop.org/~keithp/linux: drm/i915: check ACTHD of all rings drm/i915: DisplayPort hot remove notification to audio driver drm/i915: HDMI hot remove notification to audio driver drm/i915: dont trigger hotplug events on unchanged ELD drm/i915: rename audio ELD registers drm/i915: fix ELD writing for SandyBridge
-
Alan Cox authored
This doesn't work and isn't of any use. It was inherited from the older driver code and can go away. Kill it off before it becomes part of mainstream as we don't want to support it in future. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Alan Cox authored
And update to the actual product naming as the press release is now out. http://newsroom.intel.com/docs/DOC-2553#pressmaterials - Fixes the wrong ifdef check - Fixes the missing crtc count declaration Signed-off-by:
-
Alan Cox authored
Oaktrail Atom E620 has a different PCI identifier we need to cover Signed-off-by:
-
Dave Airlie authored
Merge branch 'exynos-drm-next' of git://git.infradead.org/users/kmpark/linux-samsung into drm-core-next these patch sets include the following features: - add Samsung SoC Exynos based HDMI support. - add pm feature for fimd driver. - add multi buffer plane pixel formats to drm/drm_fourcc.h. multi buffer plane pixel format has seperated memory spaces for each plane. for exampme, NV12M has Y plane and CbCr plane and these are in non-continuous memory region. compared with NV12, NV12M's memory shape is like following. NV12 : ______(Y)(CbCr)_______ NV12M : __(Y)_ ..... _(CbCr)__ - bug fix to vblank. - code clean to exynos gem framework. * 'exynos-drm-next' of git://git.infradead.org/users/kmpark/linux-samsung: drm/exynos: added hdmi display support drm/exynos: added mutex lock and code clean. drm/exynos: extend vblank off delay time. drm/exynos: change driver name. drm/exynos: Support multi buffers drm: Add multi buffer plane pixel formats drm/exynos: added pm support. drm/exynos: remove buffer creation of fbdev from drm framebuffer creation drm/exynos: Split creation of gem object and gem handle drm/exynos: Fix a fake mmap offset creation drm/exynos: gem code cleanup
-
- 29 Dec, 2011 6 commits
-
-
Seung-Woo Kim authored
This patch is hdmi display support for exynos drm driver. There is already v4l2 based exynos hdmi driver in drivers/media/video/s5p-tv and some low level code is already in s5p-tv and even headers for register define are almost same. but in this patch, we decide not to consider separated common code with s5p-tv. Exynos HDMI is composed of 5 blocks, mixer, vp, hdmi, hdmiphy and ddc. 1. mixer. The piece of hardware responsible for mixing and blending multiple data inputs before passing it to an output device. The mixer is capable of handling up to three image layers. One is the output of VP. Other two are images in RGB format. The blending factor, and layers' priority are controlled by mixer's registers. The output is passed to HDMI. 2. vp (video processor). It is used for processing of NV12/NV21 data. An image stored in RAM is accessed by DMA. The output in YCbCr444 format is send to mixer. 3. hdmi. The piece of HW responsible for generation of HDMI packets. It takes pixel data from mixer and transforms it into data frames. The output is send to HDMIPHY interface. 4. hdmiphy. Physical interface for HDMI. Its duties are sending HDMI packets to HDMI connector. Basically, it contains a PLL that produces source clock for mixer, vp and hdmi. 5. ddc (display data channel). It is dedicated i2c channel to exchange display information as edid with display monitor. With plane support, exynos hdmi driver fully supports two mixer layes and vp layer. Also vp layer supports multi buffer plane pixel formats having non contigus memory spaces. In exynos drm driver, common drm_hdmi driver to interface with drm framework has opertion pointers for mixer and hdmi. this drm_hdmi driver is registered as sub driver of exynos_drm. hdmi has hdmiphy and ddc i2c clients and controls them. mixer controls all overlay layers in both mixer and vp. Vblank interrupts for hdmi are handled by mixer internally because drm framework cannot support multiple irq id. And pipe number is used to check which display device irq happens. History v2: this version - drm plane feature support to handle overlay layers. - multi buffer plane pixel format support for vp layer. - vp layer support RFCv1: original - at https://lkml.org/lkml/2011/11/4/164Signed-off-by:
Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com>
-
Inki Dae authored
Signed-off-by: -
Inki Dae authored
some platform could be entering to sleep after short time once lcd panel off but before that vblank could be off by vblank off delay feature. at that time, vblank doesn't have the pair between vblank_get/put. so this path makes vblank off delay to have enough. Signed-off-by: -
Inki Dae authored
Signed-off-by:
-
Seung-Woo Kim authored
These formats(NV12M, NV12MT and YUV420M) have non contiguous multi planes, so each plane uses different buffer. The exynos drm should support multi buffer for them. Signed-off-by:
-
Seung-Woo Kim authored
Multi buffer plane pixel format has seperated memory spaces for each plane. For example, NV12M has Y plane and CbCr plane and these are in non contiguous memory region. Compared with NV12, NV12M's memory shape is like following. NV12 : ______(Y)(CbCr)_______ NV12M : __(Y)_ ..... _(CbCr)__ Signed-off-by:
-
