Also add golden registers, update firmware loading functions.
Signed-off-by: NSamuel Li <samuel.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>

Mullins is a new CI-based APU.
Signed-off-by: NSamuel Li <samuel.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=75241Signed-off-by: NChristian König <christian.koenig@amd.com>

Partially fixes: https://bugzilla.kernel.org/show_bug.cgi?id=75211Signed-off-by: NChristian König <christian.koenig@amd.com>

It would appear this bug has been copy/pasted many times without being noticed.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

The way the tile mode array index was calculated only makes sense for
the CIK specific macrotile mode array. For SI, we need to use one of the
tile mode array indices reserved for displayable surfaces.

This happened to result in correct display most if not all of the time
because most of the SI tiling modes use the same number of banks.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>

Check to make sure the transaction succeeded before
using the register value.  Fixes occasional link training
problems.
Noticed-by: NSergei Antonov <saproj@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>

Signed-off-by: NChristian König <christian.koenig@amd.com>

Signed-off-by: NLeo Liu <leo.liu@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org

Testing the update pending bit directly after issuing an
update is nonsense cause depending on the pixel clock the
CRTC needs a bit of time to execute the flip even when we
are in the VBLANK period.

This is just a non invasive patch to solve the problem at
hand, a more complete and cleaner solution should follow
in the next merge window.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76564

v2: fix source IDs for CRTC2-6
Signed-off-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org

Some RV7xx generation hardware crashes after you
raise the UVD clocks for the first time. Try to
avoid this by using the lower clocks to boot these.

Workaround for: https://bugzilla.kernel.org/show_bug.cgi?id=71891

v2: lower clocks on IB test as well
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Use %pad for dma_addr_t, because a dma_addr_t type can vary
based on build options. So, it prevents possible build warnings
in printks.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

devm_ioremap_resource() returns an error pointer, not NULL. Thus,
the result should be checked with IS_ERR().
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Recently, Exynos DP driver was moved from drivers/video/exynos/
directory to drivers/gpu/drm/exynos/ directory. So, I update
and add maintainer entry for Exynos DP driver.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

exynos_drm_crtc_mode_set assigns primary framebuffer to plane without
taking reference. Then during framebuffer removal it is dereferenced twice,
causing oops. The patch fixes it.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

single security fix, cc'd stable.

* 'vmwgfx-fixes-3.15' of git://people.freedesktop.org/~thomash/linux:
  drm/vmwgfx: Make sure user-space can't DMA across buffer object boundaries v2

drm/tegra: Fixes for v3.15-rc3

A single fix for some framebuffer reference counting fallout caused by
the primary plane helpers introduced in 3.15-rc1.

* tag 'drm/tegra/for-3.15-rc3' of git://anongit.freedesktop.org/tegra/linux:
  drm/tegra: restrict plane loops to legacy planes

Fixes for msm for 3.15.. a memory leak fix for devices using vram
carveout instead of iommu.  Plus I think finally managed to sort out /
workaround some cursor vs underflow issues.  And small fbcon tweak
needed to avoid extra full-modesets at boot.

* 'msm-fixes-3.15-rc3' of git://people.freedesktop.org/~robclark/linux:
  drm/msm/mdp4: cure for the cursor blues (v2)
  drm/msm: default to XR24 rather than AR24
  drm/msm: fix memory leak

Fix regression with DVI and fix warns, and GM45 boot regression.

* tag 'drm-intel-fixes-2014-04-25' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Move all ring resets before setting the HWS page
  drm/i915: Don't WARN nor handle unexpected hpd interrupts on gmch platforms
  drm/i915: Allow full PPGTT with param override
  drm/i915: Discard BIOS framebuffers too small to accommodate chosen mode
  drm/i915: get power domain in case the BIOS enabled eDP VDD
  drm/i915: Don't check gmch state on inherited configs
  drm/i915: Allow user modes to exceed DVI 165MHz limit

In commit a51435a3
Author: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Date:   Wed Mar 12 16:39:40 2014 +0530

    drm/i915: disable rings before HW status page setup

we reordered stopping the rings to do so before we set the HWS register.
However, there is an extra workaround for g45 to reset the rings twice,
and for consistency we should apply that workaround before setting the
HWS to be sure that the rings are truly stopped.

Reference: http://lkml.kernel.org/r/20140423202248.GA3621@amd.pavel.ucw.czTested-by: NPavel Machek <pavel@ucw.cz>
Cc: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The status bits are unconditionally set, the control bits only enable
the actual interrupt generation. Which means if we get some random
other interrupts we'll bogusly complain about them.

So restrict the WARN to platforms with a sane hotplug interrupt
handling scheme. And even more important also don't attempt to process
the hpd bit since we've detected a storm already. Instead just clear
the bit silently.

This WARN has been introduced in

commit b8f102e8
Author: Egbert Eich <eich@suse.de>
Date:   Fri Jul 26 14:14:24 2013 +0200

    drm/i915: Add messages useful for HPD storm detection debugging (v2)

before that we silently handled the hpd event and so partially
defeated the storm detection.

v2: Pimp commit message (Jani)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Egbert Eich <eich@suse.de>
Cc: bitlord <bitlord0xff@gmail.com>
Reported-by: Nbitlord <bitlord0xff@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The hw cursor is relatively adept at triggering underflows, which
manifest as a "blue flash" (since blue is configured as the underflow
color).  Juggle a few things around to tighten up the timing for setting
cursor registers in DONE irq.

And most importantly, don't ever disable the hw cursor.  Instead flip it
to a blank/empty cursor.  This seems far more reliable, as even simply
clearing the cursor-enable bit (with no other updates in previous/
following frames) can in some cases cause underflow.

v1: original
v2: add missing locking spotted by Micah

Cc: Micah Richert <richert@braincorporation.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Since X11 is going to create an XR24 fb, if the pixel formats do not
match then crtc helpers will think it is a full modeset even if mode is
the same, which prevents smooth/flickerless handover from fbcon/plymouth
to X11.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NMicah Richert <richert@braincorporation.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In Matt Ropers primary plane series a set of prep patches like

commit af2b653b
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Tue Apr 1 15:22:32 2014 -0700

    drm/i915: Restrict plane loops to only operate on overlay planes (v2)

ensured that all exisiting users of the mode_config->plane_list
wouldn't change behaviour. Unfortunately tegra seems to have fallen
through the cracks. Fix it.

This regression was introduced in

commit e13161af
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Tue Apr 1 15:22:38 2014 -0700

    drm: Add drm_crtc_init_with_planes() (v2)

The result was that we've unref'ed the fb for the primary plane twice,
leading to a use-after free bug. This is because the drm core will
already set crtc->primary->fb to NULL and do the unref for us, and the
crtc disable hook is called by the drm crtc helpers for exactly this
case.

Aside: Now that the fbdev helpers clean up planes there's no longer a
need to do this in drivers. So this could probably be nuked entirely
in linux-next.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

When PPGTT was disabled by default, the patch also prevented the user
from overriding this behavior via module parameter. Being able to test
this on arbitrary kernels is extremely beneficial to track down the
remaining bugs. The patch that prevented this was:

commit 93a25a9e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Mar 6 09:40:43 2014 +0100

    drm/i915: Disable full ppgtt by default

By default PPGTT is set to -1. 0 means off, 1 means aliasing only, 2
means full, all other values are reserved.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup the panel fitter to upscale.

Regression from commit d978ef14
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Mar 7 08:57:51 2014 -0800

    drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12

v2: Add a debug message to track the discard of the BIOS fb.
v3: Ville pointed out the difference between ref/unref
Reported-by: NKnut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77767Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We already check that the buffer object we're accessing is registered with
the file. Now also make sure that we can't DMA across buffer object boundaries.

v2: Code commenting update.

Cc: stable@vger.kernel.org
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>

If I unplug the eDP monitor, the BIOS of my machine will enable the
VDD bit, then when the driver loads it will think VDD is enabled. It
will detect that the eDP is not enabled and return false from
intel_edp_init_connector. This will trigger a call to
edp_panel_vdd_off_sync(), which trigger a WARN saying that the
refcount of the power domain is less than zero.

The problem happens because the driver gets a refcount whenever it
enables the VDD bit, and puts the refcount whenever it disables the
VDD bit. But on this case, the BIOS enabled VDD, so all we do is to
call put() without calling get() first, so the code added is there to
make sure we always have the get() in case the BIOS enabled the bit.

This regression was introduced in
commit e9cb81a2
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Thu Nov 21 13:47:23 2013 -0200

    drm/i915: get a runtime PM reference when the panel VDD is on

v2: - Rebase

Tested-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org (v3.13+)
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

... our current modeset code isn't good enough yet to handle this. The
scenario is:

1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.

2. We read out that state for pipe B and assign the gmch_pfit state to
it.

3. The initial modeset switches the lvds to pipe A but due to lack of
atomic modeset we don't recompute the config of pipe B.

-> both pipes now claim (in the sw pipe config structure) to use the
gmch_pfit, which just won't work.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081Tested-by: Nmax <manikulin@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

1. Further PLL parameter fixes.
2. Fixes for HPD on DP
3. Could of different PM fixes
4. Disabling DPM on RV770

* 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
  drm/radeon: don't allow runpm=1 on systems with out ATPX
  drm/radeon: fix ATPX detection on non-VGA GPUs
  drm/radeon/pm: don't walk the crtc list before it has been initialized (v2)
  drm/radeon: properly unregister hwmon interface (v2)
  drm/radeon: fix count in cik_sdma_ring_test()
  drm/radeon/aux: fix hpd assignment for aux bus
  drm/radeon: improve PLL limit handling in post div calculation
  drm/radeon: use fixed PPL ref divider if needed
  drm/radeon: disable dpm on rv770 by default

Pull gpio fixes from Linus Walleij:
 "A small batch of GPIO fixes for the v3.15 series.  I expect more to
  come in but I'm a bit behind on mail, might as well get these to you
  right now:

   - Change a crucial semantic ordering in the GPIO irqchip helpers

   - Fix two nasty regressions in the ACPI gpiolib extensions"

* tag 'gpio-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio / ACPI: Prevent potential wrap of GPIO value on OpRegion read
  gpio / ACPI: Don't crash on NULL chip->dev
  gpio: set data first, then chip and handler

Pull x86 vdso fix from Peter Anvin:
 "This is a single build fix for building with gold as opposed to GNU
  ld.  It got queued up separately and was expected to be pushed during
  the merge window, but it got left behind"

* 'x86-vdso-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, vdso: Make the vdso linker script compatible with Gold

vgaswitcheroo and the ATPX ACPI methods are required to
power down the dGPU.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73901Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Some newer PX laptops have the pci device class
set to DISPLAY_OTHER rather than DISPLAY_VGA.  This
properly detects ATPX on those laptops.

Based on a patch from: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Cc: airlied@gmail.com

Avoids a crash in certain cases when thermal irqs are generated
before the display structures have been initialized.

v2: fix the vblank and vrefresh helpers as well

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73931Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Need to properly unregister the hwmon device on driver
unload.

v2: minor clean up

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73931Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Should be 5 rather than 4.
Noticed-by: NMathias Fröhlich <Mathias.Froehlich@gmx.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NChristian König <christian.koenig@amd.com>

In commit
 commit 6375b768
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Mon Mar 3 11:33:36 2014 +0200

    drm/i915: Reject >165MHz modes w/ DVI monitors

the driver started to filter out display modes which exceed the
single-link DVI 165Mz dotclock limits when the monitor doesn't report
itself as being HDMI compliant. The intent was to filter out all
EDID derived modes that require dual-link DVI to operate since we
don't support dual-link.

However the patch went a bit too far and also causes the driver to reject
such modes even when specified by the user. Normally we don't check the
sink limitations when setting a mode from the user. This allows the user
to specify any mode whether the sink reports to support it or not. This
can be useful since often the sinks support more modes than they report
in the EDID.

So relax the checks a bit, and apply the single-link DVI dotclock limit
only when filtering the mode list, and ignore the limit when setting
a user specified mode.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=72961Tested-by: NNicholas Vinson <nvinson@comcast.net>
Cc: stable@vger.kernel.org [3.14]
Reviewed-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The hpd (hot plug detect) pin assignment got lost
in the conversion to to the common i2c over aux
code.  Without this information, aux transactions
do not work properly.  Fixes DP failures.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>