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: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>

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: Keith Packard <keithp@keithp.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>

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 <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>

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 <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>

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: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>

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: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Keith Packard <keithp@keithp.com>

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

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>

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 <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

* '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

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: Dave Airlie <airlied@redhat.com>

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 <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Oaktrail Atom E620 has a different PCI identifier we need to cover
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

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

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>

Signed-off-by: Inki Dae <inki.dae@samsung.com>

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 <inki.dae@samsung.com>

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

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 <sw0312.kim@samsung.com>
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

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: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

this patch adds pm feature for fimd driver.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

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 <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

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 <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

Make a fake mmap offset only when it needs.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

This cleans codes of exynos gem - indents and order function and so on.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

Brown paper bag of danvet.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

* '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

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 <daniel.vetter@ffwll.ch>

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: Daniel Vetter <daniel.vetter@ffwll.ch>

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
  ...

"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>

No longer used.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

v2: Smash compile fix from Tormod Volden <debian.tormod@gmail.com> for
CONFIG_FB_SIS on top of this.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

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 <daniel.vetter@ffwll.ch>

No longer used.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

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: Daniel Vetter <daniel.vetter@ffwll.ch>

In contrast to kms drivers, sis/via _always_ associated a buffer with
a drm fd. So by the time we reach lastclose, all open drm fds are gone
and with them their associated objects.

So when sis/via call drm_sman_cleanup in their lastclose funcs, that
will free 0 objects.

The owner tracking now serves no purpose at all, hence rip it ou. We
can't kill the corresponding fields in struct drm_memblock_item yet
because we hijack these in the new driver private owner tracking. But
now that drm_sman.c doesn't touch ->owner_list anymore, we need to
kill the list_move hack and properly add the item to the file_priv
list.

Also leave the list_del(&obj->owner_list) in drm_sman_free for the
moment, it will move to the drivers when sman disappears completely.

v2: Remove the redundant INIT_LIST_HEAD as noted by Chris Wilson
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

These are now unused.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>