drm/nouveau/ttm: allow tiled memtype on system memory buffer objects

Compression not supported, and will be silently dropped.  Original G80
can't handle this either and requires LINEAR memtype, though it's still
possible to correctly texture and m2mf to/from these objects anyway.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nve0/grctx: initial attempt at unhardcoding yet more magic

Not sure about the (gpc_nr == 1) condition, it's probably wrong but for
all the examples I've seen so far it matches what NVIDIA end up poking.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nv50/therm: implement temperature reading

Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/therm: split the nv50 and nv84 code

This is needed because temperature management on nv50 can be enabled and it
looks about the same as nv40.

Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/drm: fix crash in vram manager debug callback

It's probably impossible to hit it now on mainline kernel.
I only noticed it because one of my debugging patches uses it.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nvc0/fb: ignore readback page alloc failure to support userspace

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: fix uninitialised eq_done in error path

Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/shmobile: Fix race condition between page flip request and handler

The page flip handler stores the page flip event pointer and then calls
drm_vblank_get() to enable the vblank interrupt. Due to the vblank off
delay, the vblank interrupt can be enabled in the hardware at that
point, even if the vblank reference count is equal to 0. If a vblank
interrupt is triggered between storing the event pointer and calling
drm_vblank_get(), the page flip completion handler will process the
event and call drm_vblank_put() with a reference count equal to 0. This
will result in a BUG_ON.

Fix the race condition by calling drm_vblank_get() before storing the
event pointer.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: export drm_vm_open_locked

The EXYNOS DRM driver uses drm_vm_open_locked in its mmap() function,
and it can be built as a loadable module, which currently fails.
This exports the symbol from the DRM core to avoid

ERROR: "drm_vm_open_locked" [drivers/gpu/drm/exynos/exynosdrm.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/tilcdc: use only a single module device table

The tilcdc driver fails to be built as a module because of extraneous
MODULE_DEVICE_TABLE entries:

drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here

Since the entire point of these entries is to make the module autoload
when one of the devices is present, it's enough to keep the one entry
for "ti,am33xx-tilcdc", which should always be there if any of the
others are.

Acked-by: Rob Clark <robdclark@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'gma500-fixes' of git://github.com/patjak/drm-gma500 into drm-next

Two fixes for gma500. First one from Anisse allows us to handle ASLE irqs even
when BIOS doesn't trigger a pipe event irq. The second one allows dual head
setups to have a big shared framebuffer.

* 'gma500-fixes' of git://github.com/patjak/drm-gma500:
  drm/gma500: Increase max resolution for mode setting
  drm/gma500: fix backlight hotkeys behaviour on netbooks

drm/gma500: Increase max resolution for mode setting

By having a higher max resolution we can now set up a virtual
framebuffer that spans several monitors. 4096 should be ok since we're
gen 3 or higher and should be enough for most dual head setups.

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

drm/gma500: fix backlight hotkeys behaviour on netbooks

Backlight hotkeys weren't working before on certain cedartrail laptops.

The source of this problem is that the hotkeys' ASLE opregion interrupts
were simply ignored. Driver seemed to expect the interrupt to be
associated with a pipe, but it wasn't.

Accepting the ASLE interrupt without an associated pipe event flag fixes
the issue, the backlight code is called when needed, making the
brightness keys work properly.

[patrik: This patch affects irq handling on any netbook with opregion support]

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=833597
Reference: http://lists.freedesktop.org/archives/dri-devel/2012-July/025279.html
Cc: stable@kernel.org
Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

drm/tilcdc: Fix checkpatch error in tilcdc_panel.c

Fixes the following checkpatch error:
ERROR: "foo * bar" should be "foo *bar"

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/tilcdc: Remove space before tab

Silences the following checkpatch warning:
WARNING: please, no space before tabs

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/tilcdc: Remove unnecessary braces

Silences the following checkpatch warning:
WARNING: braces {} are not necessary for any arm of this statement
if (priv->rev == 1) {

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in EXTRA_CFLAGS

  When make with EXTRA_CFLAGS=-W, it will report error.
  so give a check in Makefile.

Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/tilcdc: Fix an incorrect condition

Instead of checking if num_encoders is zero, it is being assigned 0.
Convert the assignment to a check.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

fbcon: when font is freed, clear also vc_font.data

commit ae1287865f5361fa138d4d3b1b6277908b54eac9
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu Jan 24 16:12:41 2013 +1000

    fbcon: don't lose the console font across generic->chip driver switch

uses a pointer in vc->vc_font.data to load font into the new driver.
However if the font is actually freed, we need to clear the data
so that we don't reload font from dangling pointer.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm-next-3.10-2' of git://people.freedesktop.org/~agd5f/linux into drm-next

Alex writes:
A few more updates for 3.10.  Nothing too major here.  Mostly bug fixes.
The big changes are adding golden register init for 7xx and newer asics
and some audio cleanups.

* 'drm-next-3.10-2' of git://people.freedesktop.org/~agd5f/linux: (32 commits)
  drm/radeon: disable UVD advanced semaphore mode
  drm/radeon: fix endian bugs in radeon_atom_get_clock_dividers() (v3)
  drm/radeon: fix up audio dto programming for DCE2
  drm/radeon/evergreen: set SAD registers
  drm: add drm_edid_to_eld helper extracting SADs from EDID (v2)
  drm/radeon/si: add support for golden register init
  drm/radeon/cayman,TN: add support for golden register init (v2)
  drm/radeon/evergreen: add support for golden register init
  drm/radeon/7xx: add support for golden register init
  drm/radeon: add helper function to support golden registers
  drm/radeon: fix typo in si_select_se_sh()
  drm/radeon: switch audio handling to use callbacks
  drm/radeon: clean up audio dto programming
  drm/radeon: clean up audio supported check
  drm/radeon: raise UVD clocks on init v3
  drm/radeon: raise UVD clocks only on demand
  drm/radeon: put UVD PLLs in bypass mode
  drm/radeon: disable audio format interrupts on Evergreen
  drm/radeon: fix hdmi mode enable on RS600/RS690/RS740
  drm/radeon/evergreen: write default channel numbers
  ...

drm/radeon: disable UVD advanced semaphore mode

Not needed and seems to cause some problems.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix endian bugs in radeon_atom_get_clock_dividers() (v3)

v2: fix copy paste typo.
v3: clarify new union member

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix up audio dto programming for DCE2

Uses a different register than DCE3 asics.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/evergreen: set SAD registers

This allows audio (alsa) driver to read them and have a clue about audio
capabilities of connected receiver. This has been verified to be
compatible with fglrx behaviour for Onkyo TX-SR605 and Denon 1912.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm: add drm_edid_to_eld helper extracting SADs from EDID (v2)

Some devices (ATI/AMD cards) don't support passing ELD struct to the
hardware but just require filling specific registers and then the
hardware/firmware does the rest. In such cases we need to read the info
from SAD blocks and put them in the correct registers.

agd5f: note that the returned pointer needs to be kfreed as per
Christian's suggestion.

v2: fix warning

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/si: add support for golden register init

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/cayman,TN: add support for golden register init (v2)

v2: add richland support

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/evergreen: add support for golden register init

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/7xx: add support for golden register init

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: add helper function to support golden registers

Golden registers are arrays of register settings from the
hw team that need to be initialized at asic startup.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix typo in si_select_se_sh()

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: switch audio handling to use callbacks

Register audio callbacks for asic where we support
audio.  Cleans up the code and makes it easier to
add support for newer asics.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: clean up audio dto programming

Split into DCE2/3 and DCE4/5 variants. Still todo is to
calculate the DTO dividers properly.  Add proper formula
to the comments.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: clean up audio supported check

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: raise UVD clocks on init v3

v2: not only raise the clocks on VCPU boot, but also on IB test.
v3: agd5f: fix r600_uvd_init return value.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=63730

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: raise UVD clocks only on demand

That not only saves some power, but also solves problems with
older chips where an idle UVD block on higher clocks can
cause problems.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: put UVD PLLs in bypass mode

Just power down the PLL when we get a VCLK or DCLK of zero.
Enabling the bypass mode early should also allow us to
switch UVD clocks on the fly.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: disable audio format interrupts on Evergreen

The audio format change interrupts are an aid in debugging,
but not required for operation.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix hdmi mode enable on RS600/RS690/RS740

These chips were previously skipped since they are
pre-R600.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon/evergreen: write default channel numbers

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/evergreen: reorder HDMI setup

Driver fglrx setups audio and ACR packets after basic initialization,
which sounds sane, do the same.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/evergreen: setup HDMI before enabling it

Closed source driver fglrx seems to enable infoframes and audio packets
at the end, which makes sense, do the same.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: add helpers for masking and setting bits in regs

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix alignment of UVD fence

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: cleanup UVD address checks

Message and feedback buffers must be at start of
VRAM, not at start of address space.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: disable the crtcs in mc_stop (evergreen+) (v2)

Just disabling the mem requests should be enough, but
that doesn't seem to work correctly on efi systems.

May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=57567
https://bugs.freedesktop.org/show_bug.cgi?id=43655
https://bugzilla.kernel.org/show_bug.cgi?id=56441

v2: blank displays first, then disable.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: disable the crtcs in mc_stop (r5xx-r7xx) (v2)

Just disabling the mem requests should be enough, but
that doesn't seem to work correctly on efi systems.

v2: blank displays first, then disable.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: properly lock disp in mc_stop/resume for evergreen+

Need to wait for the new addresses to take affect before
re-enabling the MC.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: properly lock disp in mc_stop/resume for r5xx-r7xx

Need to wait for the new addresses to take affect before
re-enabling the MC.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: update wait_for_vblank for evergreen+

Properly wait for the next vblank region.  The previous
code didn't always wait long enough depending on the timing.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: update wait_for_vblank for r5xx-r7xx

Properly wait for the next vblank region.  The previous
code didn't always wait long enough depending on the timing.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: update wait_for_vblank for r1xx-r4xx

Properly wait for the next vblank region.  The previous
code didn't always wait long enough depending on the timing.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Merge tag 'drm/tegra/for-3.10' of git://anongit.freedesktop.org/tegra/linux into drm-next

drm/tegra: Changes for v3.10-rc1

The bulk of this pull-request is the host1x series that has been in the
works for a few months. The current implementation looks good and has
been tested by several independent parties. So far no issues have been
found. To be on the safe side, the new Tegra-specific DRM IOCTLs depend
on staging in order to give some amount of flexibility to change them
just in case. The plan is to remove that dependency once more userspace
exists to verify the adequacy of the IOCTLs.

Currently only the 2D engine is supported, but patches are in the works
to enable 3D support on top of this framework as well. Various bits of
open-source userspace exist to test the 2D and 3D support[0]. This is
still a bit immature but it allows to verify that the kernel interfaces
work properly.

To round things off there are two smaller cleanup patches, one of them
adding a new pixel format and the other removing a redundent Kconfig
dependency.

[0]: https://github.com/grate-driver

* tag 'drm/tegra/for-3.10' of git://anongit.freedesktop.org/tegra/linux:
  drm/tegra: don't depend on OF
  drm/tegra: Support the XBGR8888 pixelformat
  drm/tegra: Add gr2d device
  gpu: host1x: drm: Add memory manager and fb
  gpu: host1x: Remove second host1x driver
  gpu: host1x: drm: Rename host1x to host1x_drm
  drm/tegra: Move drm to live under host1x
  gpu: host1x: Add debug support
  gpu: host1x: Add channel support
  gpu: host1x: Add syncpoint wait and interrupts
  gpu: host1x: Add host1x driver

drm/tegra: don't depend on OF

ARCH_TEGRA always enabled OF, so there's no need for any driver to
depend on it.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>

drm/tegra: Support the XBGR8888 pixelformat

While at it, also include the RGB565 pixelformat in the list of formats
supported by overlays.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Erik Faye-Lund <kusmabite@gmail.com>

drm/tegra: Add gr2d device

Add client driver for 2D device, and IOCTLs to pass work to host1x
channel for 2D.

Also adds functions that can be called to access sync points from
DRM.

Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>

gpu: host1x: drm: Add memory manager and fb

This patch introduces a memory manager for tegra drm and moves
existing parts to use it. As cma framebuffer helpers can no more
be used, this patch adds also a separate framebuffer driver for
tegra.

Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>

gpu: host1x: Remove second host1x driver

Remove second host1x driver, and bind tegra-drm to the new host1x
driver. The logic to parse device tree and track clients is moved
to drm.c.

Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>

gpu: host1x: drm: Rename host1x to host1x_drm

Both host1x and drm drivers have host1x structures. This patch
renames the host1x structure under drm to follow name host1x_drm.

Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>

drm/tegra: Move drm to live under host1x

Make drm part of host1x driver.

Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>

gpu: host1x: Add debug support

Add support for host1x debugging. Adds debugfs entries, and dumps
channel state to UART in case of stuck job.

Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>

gpu: host1x: Add channel support

Add support for host1x client modules, and host1x channels to submit
work to the clients.

Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>

gpu: host1x: Add syncpoint wait and interrupts

Add support for sync point interrupts, and sync point wait. Sync
point wait used interrupts for unblocking wait.

Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>

gpu: host1x: Add host1x driver

Add host1x, the driver for host1x and its client unit 2D. The Tegra
host1x module is the DMA engine for register access to Tegra's
graphics- and multimedia-related modules. The modules served by
host1x are referred to as clients. host1x includes some other
functionality, such as synchronization.

Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>

drm: Perform a full mode set when the pixel format changed

Test whether the pixel format changes in the mode set handler, and
perform a full mode set instead of a mode set base if it does.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Don't allow page flip to change pixel format

A page flip is not a mode set, changing the frame buffer pixel format
doesn't make sense and isn't handled by most drivers anyway. Disallow
it.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'exynos-drm-next' of git://git./linux/kernel/git/daeinki/drm-exynos into drm-next

Inki writes:
      This is initial pull request for Exynos. It includes a big change
       that it makes drm_display_mode for timings parameters to be used
       for exynos4 and exynos5 commonly and cleans up unnecessary codes.
       And also it adds device tree support for fimd to get timing values
       and interrupt source from dts file.

       In addition, one more patch, device tree support feature for Exynos
       FIMC, is being reviewed. This patch was posted a little ago like below,
            http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg17568.html

       So we are going to request git pull one more time after reviewed.

* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos: prepare FIMD clocks
  Revert "of/exynos_g2d: Add Bindings for exynos G2D driver"
  drm/exynos: drm_connector: Fix error check condition
  drm/exynos: drm_rotator: Fix incorrect usage of IS_ERR_OR_NULL
  drm/exynos: mixer: Fix incorrect usage of IS_ERR_OR_NULL
  drm/exynos: hdmi: Fix incorrect usage of IS_ERR_OR_NULL
  drm/exynos: change the method for getting the interrupt
  drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm fimd
  drm/exynos: Add display-timing node parsing using video helper function
  drm/exynos: hdmi: move mode_fixup to drm common hdmi
  drm/exynos: hdmi: using drm_display_mode timings for exynos4

Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

Daniel writes:
As promised a stash of (mostly) fixes. Two pieces of non-fixes included:
- A notch more gtt refactoring from Ben, beating to death with igt in our
  nightly testing.
- Support for display display-less server chips (again from Ben). New hw
  support which is only likely to break itself ;-)

Otherwise just tons of fixes:
- hpd irq storm mitigation from Egbert Eich. Your -next tree already has
  the infrastructure, this here just supplies the logic.
- sdvo hw state check fix from Egbert Eich
- fb cb tune settings for the pch pll clocks on cpt/ppt
- "Bring a bigger gun" coherence workaround for multi-threade, mulit-core
  & thrashing tiled gtt cpu access from Chris.
- Update haswell mPHY code.
- l3$ caching for context objects on ivb/hsw (Chris).
- dp aux refclock fix for haswell (Jani)
- moar overclocking fixes for snb/ivb (Ben)
- ecobits ppgtt pte caching control fixes from Ville
- fence stride check fixes and limit improvements (Ville)
- fix up crtc force restoring, potentially resulting in tons of hw state
  check WARNs
- OOPS fix for NULL derefencing of fb pointers when force-restoring a crtc
  when other crtcs are disabled and the force-restored crtc is _not_ the
  first one.
- Fix pfit disabling on gen2/3.
- Haswell ring freq scaling fixes (Chris).
- backlight init/teardown fix (failed eDP init killed the lvds backlight)
  from Jani
- cpt/ppt fdi polarity fixes from Paulo (should help a lot of the FDI link
  train failures).
- And a bunch of smaller things all over.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (56 commits)
  drm/i915: fix bpc vs. bpp confusion in intel_crtc_compute_config
  drm/i915: move cpu_transcoder to the pipe configuration
  drm/i915: preserve the PBC bits of TRANS_CHICKEN2
  drm/i915: set CPT FDI RX polarity bits based on VBT
  drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4)
  drm/i915: Disable HPD interrupt on pin when irq storm is detected (v3)
  drm/i915: Mask out the HPD irq bits before setting them individually.
  drm/i915: (re)init HPD interrupt storm statistics
  drm/i915: Add HPD IRQ storm detection (v5)
  drm/i915: WARN when LPT-LP is not paired with ULT CPU
  drm/i915: don't intel_crt_init on any ULT machines
  drm/i915: remove comment about IVB link training from intel_pm.c
  drm/i915: VLV doesn't have LLC
  drm/i915: Scale ring, rather than ia, frequency on Haswell
  drm/i915: shorten debugfs output simple attributes
  drm/i915: Fixup pfit disabling for gen2/3
  drm/i915: Fixup Oops in the pipe config computation
  drm/i915: ensure single initialization and cleanup of backlight device
  drm/i915: don't touch the PF regs if the power well is down
  drm/i915: add intel_using_power_well
  ...

drm/exynos: prepare FIMD clocks

While migrating to common clock framework (CCF), I found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.

Calling clk_prepare() for FIMD clocks fixes the issue.

This patch also replaces clk_disable() with clk_unprepare() during exit, since
clk_prepare() is called in fimd_probe().

Signed-off-by: Vikas Sajjan <vikas.sajjan@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/i915: fix bpc vs. bpp confusion in intel_crtc_compute_config

Oops.

This regression has been introduced in

commit 5d2d38ddcac991f71c19d03d95bde8e14abc0352
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 27 00:45:01 2013 +0100

    drm/i915: clean up pipe bpp confusion

Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move cpu_transcoder to the pipe configuration

For a bunch of reason we need to more accurately track this:
- hw pipe state readout for Haswell needs the cpu transcoder.
- We need to know the right cpu transcoder in a bunch of places in
  ->disable and other modeset callbacks.

In the future we need to add hw state readout&check support, too. But
to avoid ugly merge conflicts do the rote sed job now without any
functional changes.

v2: Preserve the cpu_transcoder value when overwriting crtc->config.
Reported by Paulo.

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
[danvet: Removed rough whitespace that Chris spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: preserve the PBC bits of TRANS_CHICKEN2

Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits
are being zeroed, but I couldn't find a reason for this, so leave them
as they are for now to avoid regressions.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Delete the redudant #define that Imre spotted in his review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: set CPT FDI RX polarity bits based on VBT

Check the VBT to see if the machine has inverted FDI RX polarity on
CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2
registers.

This should fix some machines that were showing black screens on all
outputs.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4)

We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it happens at certain charging states of
the system). Thus we enable it after a certain grace period (2 minutes).
Should the interrupt storm persist it will be detected immediately
and it will be disabled again.

v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state tracker.
v3: Clarified loop start value,
    Removed superfluous test for Ivybridge and Haswell,
    Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä)
v4: Fixed two bugs pointed out by Jani Nikula.

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Disable HPD interrupt on pin when irq storm is detected (v3)

This patch disables hotplug interrupts if an 'interrupt storm'
has been detected.
Noise on the interrupt line renders the hotplug interrupt useless:
each hotplug event causes the devices to be rescanned which will
will only increase the system load.
Thus disable the hotplug interrupts and fall back to periodic
device polling.

v2: Fixed cleanup typo.
v3: Fixed format issues, clarified a variable name,
    changed pr_warn() to DRM_INFO() as suggested by
    Jani Nikula <jani.nikula@linux.intel.com>.

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Mask out the HPD irq bits before setting them individually.

To disable previously enabled HPD IRQs we need to reset them and
set the enabled ones individually.

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: (re)init HPD interrupt storm statistics

When an encoder is shared on several connectors there is only
one hotplug line, thus this line needs to be shared among these
connectors.
If HPD detect only works reliably on a subset of those connectors,
we want to poll the others. Thus we need to make sure that storm
detection doesn't mess up the settings for those connectors.
Therefore we store the settings in the intel_connector struct and
restore them from there.
If nothing is set but the encoder has a hpd_pin set we assume this
connector is hotplug capable.
On init/reset we make sure the polled state of the connectors
is (re)set to the default value, the HPD interrupts are marked
enabled.

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add HPD IRQ storm detection (v5)

Add a hotplug IRQ storm detection (triggered when a hotplug interrupt
fires more than 5 times / sec).
Rationale:
Despite of the many attempts to fix the problem with noisy hotplug
interrupt lines we are still seeing systems which have issues:
Once cause of noise seems to be bad routing of the hotplug line
on the board: cross talk from other signals seems to cause erronous
hotplug interrupts. This has been documented as an erratum for the
the i945GM chipset and thus hotplug support was disabled for this
chipset model but others seem to have this problem, too.

We have seen this issue on a G35 motherboard for example:
Even different motherboards of the same model seem to behave
differently: while some only see only around 10-100 interrupts/s
others seem to see 5k or more.
We've also observed a dependency on the selected video mode.

Also on certain laptops interrupt noise seems to occur duing
battery charging when the battery is at a certain charge levels.

Thus we add a simple algorithm here that detects an 'interrupt storm'
condition.

v2: Fixed comment.
v3: Reordered drm_i915_private: moved hpd state tracking to hotplug work stuff.
v4: Followed by Jesse Barnes to use a time_..() macro.
v5: Fixed coding style as suggested by Jani Nikula.

Signed-off-by: Egbert Eich <eich@suse.de>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WARN when LPT-LP is not paired with ULT CPU

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't intel_crt_init on any ULT machines

We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not
have CRT, so just check for !IS_ULT. This problem happened on a real
machine and resulted in a very ugly dmesg.

Cc: stable@vger.kernel.org
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove comment about IVB link training from intel_pm.c

We have the exact same comment inside intel_init_display. This is
a leftover from when we moved a lot of code from intel_display.c to
intel_pm.c.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: VLV doesn't have LLC

Caused by me with v2 of

commit 219f4fdbed5570f1d2e8da0af1c298dd3622060e
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Fri Mar 15 11:17:54 2013 -0700

    drm/i915: Introduce GEN7_FEATURES for device info

I don't have a VLV to test it with, Jesse, Ken, can one of you test?

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Scale ring, rather than ia, frequency on Haswell

Haswell introduces a separate frequency domain for the ring (uncore). So
where we used to increase the CPU (IA) clock with GPU busyness, we now
need to scale the ring frequency directly instead. As the ring limits
our memory bandwidth, it is vital for performance that when the GPU is
busy, we increase the frequency of the ring to increase the available
memory bandwidth.

v2: Fix the algorithm to actually use the scaled gpu frequency for the ring.
v3: s/max_ring_freq/min_ring_freq/ as that is what it is

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add space checkpatch complained about.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: shorten debugfs output simple attributes

commit 647416f9eefe7699754b01b9fc82758fde83248c
Author: Kees Cook <keescook@chromium.org>
Date:   Sun Mar 10 14:10:06 2013 -0700

    drm/i915: use simple attribute in debugfs routines

made i915_next_seqno debugfs entry to crop it's output
if returned value was large enough. Using simple_attr
will limit the output to 24 bytes.

Fix is to strip out preamples on all simple attributes
that have one.

v2: Fix all simple attributes (Daniel Vetter)

Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fixup pfit disabling for gen2/3

The recent rework of the pfit handling didn't take into account that
the panel fitter is fixed to pipe B:

commit 24a1f16de97c4cf0029d9acd04be06db32208726
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Fri Feb 8 16:35:37 2013 +0200

    drm/i915: disable shared panel fitter for pipe

Fix this up by properly computing the pipe the pfit is on. Also
extract the logic into its own function, add a debug assert to check
that the pipe is off (mostly just documentation) and add some debug
output.

If pipe A was disabled after pipe B was set up, the panel fitter will
be disabled. Now most userspace doesn't do modesets in this order,
which is why I couldn't ever reproduce this and why it took me so long
to figure out.

We really need hw state readout and check support for the pannel
fitter ...

Reported-by: Hans de Bruin <jmdebruin@xmsnet.nl>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Hans de Bruin <jmdebruin@xmsnet.nl>
References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/19049
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fixup Oops in the pipe config computation

Yet again our current confusion between doing the modeset globally,
but only having the new parameters for one crtc at a time.

So that intel_set_mode essentially already does a global modeset:
intel_modeset_affected_pipes compares the current state with where we
want to go to (which is carefully set up by intel_crtc_set_config) and
then goes through the modeset sequence for any crtc which needs
updating.

Now the issue is that the actual interface with the remaining code
still only works on one crtc, and so we only pass in one fb and one
mode. In intel_set_mode we also only compute one intel_crtc_config
(which should be the one for the crtc we're doing a modeset on).

The reason for that mismatch is twofold:
- We want to eventually do all modeset as global state changes, so
it's just infrastructure prep.
- But even the old semantics can change more than one crtc when you
e.g. move a connector from crtc A to crtc B, then both crtc A and B
need to be updated. Usually that means one pipe is disabled and the
other enabled. This is also the reason why the hack doesn't touch the
disable_pipes mask.

Now hilarity ensued in our kms config restore paths when we actually
try to do a modeset on all crtcs: If the first crtc should be off and
the second should be on, then the call on the first crtc will notice
that the 2nd one should be switched on and so tries to compute the
pipe_config. But due to a lack of passed-in fb (crtc 1 should be off
after all) it only results in tears.

This case is ridiculously easy to hit on gen2/3 where the lvds output
is restricted to pipe B. Note that before the pipe_config bpp rework
gen2/3 didn't care really about the fb->depth, so this is a regression
brought to light with

commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 27 00:44:58 2013 +0100

    drm/i915: precompute pipe bpp before touching the hw

But apparently Ajax also managed to blow up pch platforms, probably
with some randomized configs, and pch platforms trip up over the lack
of an fb even in the old code. So this actually goes back to the first
introduction of the new modeset restore code in

commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Nov 23 18:16:34 2012 +0100

    drm/i915: force restore on lid open

Fix this mess by now by justing shunting all the cool new global
modeset logic in intel_modeset_affected_pipes.

v2: Improve commit message and clean up all the comments in
intel_modeset_affected_pipes - since the introduction of the modeset
restore code they've been a bit outdated.

Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725
Cc: stable@vger.kernel.org
References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.html
Tested-by: Richard Cochran <richardcochran@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: ensure single initialization and cleanup of backlight device

Backlight cleanup in the eDP connector destroy callback caused the
backlight device to be removed on some systems that first initialized LVDS
and then attempted to initialize eDP. Prevent multiple backlight
initializations, and ensure backlight cleanup is only done once by moving
it to modeset cleanup.

A small wrinkle is the introduced asymmetry in backlight
setup/cleanup. This could be solved by adding refcounting, but it seems
overkill considering that there should only ever be one backlight device.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Peter Verthez <peter.verthez@skynet.be>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't touch the PF regs if the power well is down

This solves some "unclaimed register" messages when booting the
machine with eDP attached.

V2: Rebase and add the comment requested by Daniel.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add intel_using_power_well

It returns true if we've requested to turn the power well on and it's
really on. It also returns true for all the previous gens.

For now there's just one caller, but I'm going to add more.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't check inconsistent modeset state when force-restoring

It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.

Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the end, so we don't reduce the amount of
checking.

v2: Try harder not to create a big patch (Chris).

v3: Even smaller (still Chris). Also fix a trailing space.

References: https://lkml.org/lkml/2013/3/16/60
Cc: Tomas Melin <tomas.melin@iki.fi>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Tomas Melin <tomas.melin@iki.fi>
Tested-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: IVB/HSW have 32 fence register

Increase the number of fence registers to 32 on IVB/HSW. VLV however
only has 16 fence registers according to the docs.

Increasing the number of fences was attempted before [1], but there was
some uncertainty about the maximum CPU fence number for FBC. Since then
BSpec has been updated to state that there are in fact 32 fence registers,
and the CPU fence number field in the SNB_DPFC_CTL_SA register is 5 bits,
and the CPU fence number field in the ILK_DPFC_CONTROL register must be
zero. So now it all makes sense.

[1] http://lists.freedesktop.org/archives/intel-gfx/2011-October/012865.html

v2: Include some background information based on the previous attempt

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Return stored value from max freq sysfs entry

commit 4f9b2fe0441d4bdf5666a306156b5d6755de2584
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Fri Apr 5 14:29:22 2013 -0700

    drm/i915: Better overclock support

changed the sysfs read semantics for 'gt_max_freq_mhz'. By
always returning overclock max instead of stored value.

Fix this by returning the stored value. Separate sysfs entry
should be considered for overclocking max freq.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63415
Cc: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove stale code

Looks like a some remnant from a rebase.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Increase max fence pitch limit to 256KB on IVB+

BSpec contains several scattered notes which state that the maximum
fence stride was increased to 256KB on IVB.

Testing on real hardware agrees.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Reject fence stride=0 on gen4+

Our checks for an invalid fence stride forgot to guard against
zero stride on gen4+. Fix it.

v2: Avoid duplicated code (danvet)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Configure GAM_ECOCHK appropriatly for Gen7

IVB and HSW use different encodings for the PPGTT cacheability bits in
the GAM_ECOCHK register.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Set GAC_ECO_BITS register on Gen7+

According to BSpec GAC_ECO_BITS register exists on Gen7 platforms as
well. Configure it accordingly.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add ECOBITS_SNB_BIT

GAC_ECO_BITS has a bit similar to GAM_ECOCHK's ECOCHK_SNB_BIT. Add
the define, and enable it on SNB.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't default to overclock max

Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Better overclock support

Most importantly this will allow users to set overclock frequencies in
sysfs. Previously the max was limited by the RP0 max as opposed to the
overclock max. This is useful if one wants to either limit the max
overclock frequency, or set the minimum frequency to be in the overclock
range. It also fixes an issue where if one sets the max frequency to be
below the overclock max, they wouldn't be able to set back the proper
overclock max.

In addition I've added a couple of other bits:
Show the overclock freq. as max in sysfs
Print the overclock max in debugfs.
Print a warning if the user sets the min frequency to be in the
overclock range.

In this patch I've decided to store the hw_max when we read it from the
pcode at init. The reason I do this is the pcode reads can fail, and are
slow.

v2: Report when user requested overclocked max (Daniel)
Remove when user sets min to overclock range (Daniel)

Reported-by: freezer from #intel-gfx on irc
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Fixup the s/100MHz/50MHz/ confusion in an unrelated comment
that Mika spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>