- Jan 04, 2012
-
-
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:Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
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:
Keith Packard <keithp@keithp.com>
-
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=42578 Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-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:
Eugeni Dodonov <eugeni.dodonov@intel.com> 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:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-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:
-
- Jan 03, 2012
-
-
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:
Dave Airlie <airlied@redhat.com>
-
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
-
- Dec 29, 2011
-
-
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/164 Signed-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:
-
Inki Dae authored
this patch adds pm feature for fimd driver. Signed-off-by:
-
Joonyoung Shim authored
The fbdev fb and the user fb is created from same function - exynos_drm_fb_create, but this function creates not only drm framebuffer but buffer of fbdev. Remove it because it complicates codes and use exynos_drm_gem_create() than exynos_drm_buf_create() to create buffer of fbdev, it give better consistency of codes and more clear implementation. Signed-off-by:
-
Joonyoung Shim authored
exynos_drm_gem_create function created gem object with gem handle but it can be called externally without gem handle creation through this patch. Signed-off-by:
-
Joonyoung Shim authored
Make a fake mmap offset only when it needs. Signed-off-by:
-
Joonyoung Shim authored
This cleans codes of exynos gem - indents and order function and so on. Signed-off-by:
-
- Dec 23, 2011
-
-
Dave Airlie authored
Brown paper bag of danvet. Acked-by:
-
git://people.freedesktop.org/~danvet/drmDave Airlie authored
* 'for-airlied' of git://people.freedesktop.org/~danvet/drm: drm/i810: don't acces hw regs in lastclose drm/i810: cleanup reclaim_buffers drm: kill drm_sman drm/sis: use drm_mm instead of drm_sman drm/via: use drm_mm instead of drm_sman drm/sman: kill user_hash_tab drm/sis: track user->memblock mapping with idr drm/via: track user->memblock mapping with idr drm/sman: rip out owner tracking drm/sman: kill owner tracking interface functions drm/via: track obj->drm_fd relations in the driver drm/sis: track obj->drm_fd relations in the driver
-
Daniel Vetter authored
i810 uses a userspace provided mmio map using the drm core map infrastructure. By the time we reach lastclose, this is all gone and our mmio_map pointer points at freed memory. Depending upon luck that still works, most often it just oopses. Aside: drm maps aren't refcounted, so userspace can essentially oops the kernel any time it wants to. Who cares. Signed-off-by: -
Daniel Vetter authored
My dear old i815 always hits the deadlocked on reclaim_buffers warning. Switch over to the idlelock duct-tape on hope that works better. I've fired up my i815 and now closing glxgears doesn't take 5 seconds anymore. \o/ Signed-off-by:
-
- Dec 22, 2011
-
-
Dave Airlie authored
Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-core-next * 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (102 commits) drm/nouveau/ttm: fix crash as a result of a recent ttm change drm/nouveau: Fix notifier blocks over the 4GB mark. drm/nouveau: Fix pushbufs over the 4GB mark. drm/nvc0/pm: initial engine reclocking drm/nouveau: move hpd enable/disable to common code drm/nv40/disp: implement support for hotplug irq drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues drm/nouveau: just pass gpio line to pwm_*, not entire gpio struct drm/nouveau/hwsq: remove some magic, give proper opcode names drm/nv50/pm: introduce hwsq-based memory reclocking drm/nv04/disp: handle dual-link spwg panels without needing quirks drm/nouveau/dp: remove broken display depth function, use the improved one drm/nouveau/mxm: implement ROM shadow method drm/nouveau/mxm: implement _DSM shadow method drm/nouveau/mxm: implement wmi shadow method drm/nouveau/mxm: initial implementation of dcb sanitisation drm/nouveau/disp: parse connector info directly in nouveau_connector.c drm/nouveau/i2c: handle bit-banging ourselves drm/nouveau/i2c: fix debug message drm/nouveau/i2c: tidy up bit-bang helpers, also fixing nv50 setsda bug ...
-
Ben Skeggs authored
"drm/ttm: callback move_notify any time bo placement change v4" failed to avoid a NULL pointer dereference in nouveau caused by move_notify being expected to handle that case now. Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Daniel Vetter authored
No longer used. Signed-off-by: -
Daniel Vetter authored
v2: Smash compile fix from Tormod Volden <debian.tormod@gmail.com> for CONFIG_FB_SIS on top of this. Signed-off-by: -
Daniel Vetter authored
To make the transition in a piece-wise and bisectable way possible, I've hijacked the ->owner_list from drm_sman. While transitioning, the list_add was done by the driver, while the list_del was still done by the dying sman code. Now that we are in full control of ->owner_list, do the list_del ourselves. v2: Better explain the list_del trickery as suggested by Chris Wilson. Signed-off-by: -
Daniel Vetter authored
No longer used. Signed-off-by: -
Daniel Vetter authored
Signed-off-by: -
Daniel Vetter authored
Massive indirection through a hashtable for a simple key->pointer look-up actually just adds bloat. v2: Drop the misleading comment noted by Chris Wilson. Signed-off-by:
-
