drm/edid: new drm_edid_block_checksum helper function V3

The function will also be used by a later patch, so factor it out.

V2: make raw_edid const, define/declare before first use
V3: fix erroneuos removal of csum variable

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/edid: shorten log output in case of all zeroes edid block

There is no need to dump the whole EDID block in case it contains no
information. Just print a single line stating the block is empty instead
of 8 lines containing only zeroes.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/edid: move drm_edid_is_zero to top, make edid argument const

drm_edid_is_zero will be used by drm_edid_block valid, move it up.
raw_edid argument can be const.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/atomic: clear plane's CRTC and FB when shutting down

Otherwise we'd still end up w/ the plane attached to the CRTC, and
seemingly active, but without an FB.  Which ends up going *boom*
in the drivers.

Slightly modified version of Daniel's irc suggestion.

Note that the big problem isn't drivers going *boom* here (since we
already have the situation of planes being left enabled when the crtc
goes down). The real issue is that the core assumes the primary plane
always goes down when calling ->set_config with a NULL mode. Ignoring
that assumption leads to the legacy state pointers plane->fb/crtc
getting out of sync with atomic, and that then leads to the subsequent
*boom* all over the place.

CC: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>
[danvet: Drop my opinion of what's going sidewides here into the
commit message as a note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Handle atomic state properly in kms getfoo ioctl

So the problem with async commit (especially async modeset commit) is
that the legacy pointers only get updated after the point of no
return, in the async part of the modeset sequence. At least as
implemented by the current helper functions. This is done in the
set_routing_links function in drm_atomic_helper.c.

Which also means that access isn't protected by locks but only
coordinated by synchronizing with async workers. No problem thus far,
until we lock at the getconnector/encoder ioctls.

So fix this up by adding special cases for atomic drivers: For those
we need to look at state objects. Unfortunately digging out the
correct encoder->crtc link is a bit of work, so wrap this up in a
helper function.

Moving the assignments of connector->encoder and encoder->crtc earlier
isn't a good idea because the point of the atomic helpers is that we
stage the state updates. That way the disable functions can still
inspect the links and rely upon them.

v2: Extract full encoder->crtc lookup into helper (Rob).

v3: Extract drm_connector_get_encoder too since - we need to always
return state->best_encoder when there is a state otherwise we might
return stale data if there's a pending async disable (and chase
unlocked pointers, too). Same issue with encoder_get_crtc but there
it's a bit more tricky to handle.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Lightly-Tested-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm: use mode_object_find helpers

Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: fix indentation

Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/msm: switch to atomic-helpers iterator macros

Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/atomic: add plane iterator macros

Add helper macros to iterate the current, or incoming set of planes
attached to a crtc.  These helpers are only available for drivers
converted to use atomic-helpers.

Signed-off-by: Rob Clark <robdclark@gmail.com>
[danvet: Squash in fixup from Rob to move the planemask iterator to
drm_crtc.h and document it. That one is needed by the atomic ioctl so
can't be in a helper library.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/atomic: track bitmask of planes attached to crtc

Chasing plane->state->crtc of planes that are *not* part of the same
atomic update is racy, making it incredibly awkward (or impossible) to
do something simple like iterate over all planes and figure out which
ones are attached to a crtc.

Solve this by adding a bitmask of currently attached planes in the
crtc-state.

Note that the transitional helpers do not maintain the plane_mask.  But
they only support the legacy ioctls, which have sufficient brute-force
locking around plane updates that they can continue to loop over all
planes to see what is attached to a crtc the old way.

Signed-off-by: Rob Clark <robdclark@gmail.com>
[danvet:
- Drop comments about locking in set_crtc_for_plane since they're a
  bit misleading - we already should hold lock for the current crtc.
- Also WARN_ON if get_state on the old crtc fails since that should
  have been done already.
- Squash in fixup to check get_plane_state return value, reported by
  Dan Carpenter and acked by Rob Clark.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Free atomic state during cleanup

The current state of CRTCs, planes and connectors currently leaks during
DRM driver ->unload() unless drivers explicitly clean it up. Since there
is nothing driver-specific about it, that cleanup can be done within the
DRM core.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Make drm_atomic.h standalone includible

This header file makes use of a bunch of structures declared in the
drm_crtc.h header file. Include that to make sure the drm_atomic.h
header can be included standalone.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Make drm_atomic_helper.h standalone includible

This header uses a bunch of declarations from the drm/drm_crtc.h header,
so make sure to include that as well so that drm_atomic_helper.h can be
included standalone.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/plane: Add missing kerneldoc

The plane helpers aren't pulled into the DocBook yet, so these weren't
noticed.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/plane: Pass old state to ->atomic_update()

In most situations it will be useful to have the old state passed to the
->atomic_update() callback. For example if a plane is being disabled the
new state's .crtc field will be NULL, but some drivers may rely on this
field to program the CRTCs registers.

v2: rename variable to old_plane_state and remove redundant comment as
suggested by Daniel Vetter, remove an Exynos hunk that doesn't apply to
drm-next and add a hunk for pending MSM mdp5 changes

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/atomic_helper: Cope with plane->crtc == NULL in disable helper

The drm core can call the plane disable hook multiple times, which
means it can get called when plane->crtc is already NULL. That in turn
means we can't get at the implicit acquire ctx we use in the atomic
helpers for legacy entries points.

We could try to pass drm_modeset_legacy_acquire_ctx a drm_device
pointer so that it can cope with a NULL crtc. But that still doesn't
work since the cursor ioctls (remapped with the universal cursor plane
support code) only grabs the crtc locks. So the global acquire context
isn't set eitehr.

The real solution here would be to bite the bullet and wire up
explicit acquire context parameters to all relevant functions. We need
to do that anyway (to be able to get rid of some small allocations
which we can't cope with failing). But that's a lot of work and better
done once atomic has settled a bit.

So meanwhile just catch this case in the helper and bail out.

Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Completely rewrite commit message and comment but keep
Jasper's logic and author credits since his patch is the only
short-term solution that works.]
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/atomic: Drop per-plane locking TODO

I've forgotten to remove that in my per-plane locking patch.

Reported-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/atomic-helper: Skip vblank waits for unchanged fbs

Especially with legacy cursor ioctls existing userspace assumes that
you can pile up lots of updates in one go. The super-proper way to
support this would be a special commit mode which overwrites the last
update. But getting there will be quite a bit of work.

Meanwhile do what pretty much all the drivers have done for the plane
update functions: Simply skip the vblank wait for the buffer cleanup
if the buffer is the same. Since the universal cursor plane code will
not recreate framebuffers needlessly this allows us to not slow down
legacy pageflip events while someone moves the cursor around.

v2: Drop the async plane update hunk from a previous attempt at this
issue.

v3: Fix up kerneldoc.

v4: Don't oops so badly. Reported by Jasper.

Cc: Rob Clark <robdclark@gmail.com>
Cc: "Jasper St. Pierre" <jstpierre@mecheye.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Tested-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm: Document that drm_dev_alloc doesn't need a parent

Possible for purely virtual debug devices.

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

Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next

Now that we have the bits needed for mdp5 atomic, here is the followup
pull request I mentioned.  Main highlights are:

1) mdp5 multiple crtc and public plane support (no more hard-coded mixer setup!)
2) mdp5 atomic conversion
3) couple atomic helper fixes for issues found during mdp5 atomic
debug (reviewed by danvet.. but he didn't plane to send an
atomic-fixes pull request so I agreed to tack them on to mine)

* 'msm-next' of git://people.freedesktop.org/~robclark/linux:
  drm/atomic: shutdown *current* encoder
  drm/atomic: check mode_changed *after* atomic_check
  drm/msm/mdp4: fix mixer setup for multi-crtc + planes
  drm/msm/mdp5: dpms(OFF) cleanups
  drm/msm/mdp5: atomic
  drm/msm: atomic fixes
  drm/msm/mdp5: remove global mdp5_ctl_mgr
  drm/msm/mdp5: don't use void * for opaque types
  drm/msm: add multiple CRTC and overlay support
  drm/msm/mdp5: set rate before enabling clk
  drm/msm/mdp5: introduce mdp5_cfg module
  drm/msm/mdp5: make SMP module dynamically configurable
  drm/msm/hdmi: remove useless kref
  drm/msm/mdp5: get the core clock rate from MDP5 config
  drm/msm/mdp5: use irqdomains

drm/atomic: shutdown *current* encoder

In disable_outputs() we need to shut down the outgoing encoder, not the
incoming one (we have already swapped-state at this point).  Without
this, we end up telling the driver to crtc->dpms(OFF) without first
encoder->dpms(OFF), and that makes some hw quite unhappy.

v2: missing WARN_ON() hunk and comment

Reviewed-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/atomic: check mode_changed *after* atomic_check

The intention is that drivers can set crtc_state->mode_changed in their
atomic_check() fxns if they encounter a scenario that requires full
modeset.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/msm/mdp4: fix mixer setup for multi-crtc + planes

On mdp4 there is a single global LAYERMIXER_IN_CFG register.  The
previous logic to share that between multiple crtcs didn't actually
handle plane-disable very well.  Easier just to look at all of the
crtcs each time.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: dpms(OFF) cleanups

When disabling the interface (INTF), the change doesn't latch until next
vblank, so we need to wait for vblank.

Also, to be pedantic, in the crtc, set all the mixer stages to unused.
It shouldn't really matter, since at this point we have already disabled
the INTF and waited for necessary vblank.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: atomic

Convert mdp5 over to atomic helpers.  Extend/wrap drm_plane_state to
track plane zpos and to keep track of the needed when applying the
atomic update.  In mdp5's plane->atomic_check() we also need to check
for updates which require SMP reallocation, in order to trigger full
modeset.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: atomic fixes

Fixes for a couple little issues found in testing.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: remove global mdp5_ctl_mgr

A bit cleaner.. and won't resulting in an attempt to kfree() a static
global in unload path.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: don't use void * for opaque types

For example, use 'struct mdp5_smp *' everywhere instead of 'void *', but
only declare it as 'struct mdp5_smp;' in common headers, so the struct
body is still private.  The accomplishes the desired modularity while
still letting the compiler provide some type checking for us.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: add multiple CRTC and overlay support

MDP5 currently support one single CRTC with its private pipe.
This change allows the configuration of multiple CRTCs with
the possibility to attach several public planes to these CRTCs.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: set rate before enabling clk

Set a "safe" rate at first, in order to read out the hw revision.  And
then after set the optimal value.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: introduce mdp5_cfg module

The hardware configuration modification from a version to another
is quite consequent. Introducing a configuration module
(mdp5_cfg) may make things more clear and easier to access when a
new hardware version comes up.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: make SMP module dynamically configurable

The Shared Memory Pool (SMP) has its own limitation, features and
state. Some examples are:
 - the number of Memory Macro Block (MMB) and their size
 - the number of lines that can be fetched
 - the state of MMB currently allocated
 - the computation of number of blocks required per plane
 - client IDs ...

In order to avoid private data to be overwritten by other modules,
let's make these private to the SMP module.

Some of these depend on the hardware configuration, let's add them
to the mdp5_config struct.

In some hw configurations, some MMBs are statically tied to RGB
pipes and cannot be re-allocated dynamically. This change
introduces the concept of MMB static usage and makes sure that
dynamic MMB requests are dimensioned accordingly.

A note on passing a pipe pointer, instead of client IDs:
Client IDs are SMP-related information. Passing PIPE information
to SMP lets SMP module to find out which SMP client(s) are used.
This allows the SMP module to access the PIPE pointer, which can
be used for FIFO watermark configuration.
By the way, even though REG_MDP5_PIPE_REQPRIO_FIFO_WM_* registers
are part of the PIPE registers, their functionality is to reflect
the behavior of the SMP block. These registers access is now
restricted to the SMP module.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/hdmi: remove useless kref

A left-over from prior to component framework.  The original intent was
to deal with hdmi getting unloaded before the master component, but that
isn't really going to work anyways.  These days with the component
framework taking care to unload the master component first, we don't
have to worry about this.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: get the core clock rate from MDP5 config

The core clock rate depends on the hw configuration. Once we have
read the hardware revision, we can set the core clock to its
maximum value.
Before then, the clock is set at a rate supported by all MDP5
revisions.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: use irqdomains

For mdp5, the irqs of hdmi/eDP/dsi0/dsi1 blocks get routed through the
mdp block.  In order to decouple hdmi/eDP/etc, register an irq domain
in mdp5.  When hdmi/dsi/etc are used with mdp4, they can directly setup
their irqs in their DT nodes as normal.  When used with mdp5, instead
set the mdp device as the interrupt-parent, as in:

mdp: qcom,mdss_mdp@fd900000 {
compatible = "qcom,mdss_mdp";
interrupt-controller;
#interrupt-cells = <1>;
...
};

hdmi: qcom,hdmi_tx@fd922100 {
compatible = "qcom,hdmi-tx-8074";
interrupt-parent = <&mdp>;
interrupts = <8 0>;   /* MDP5_HW_INTR_STATUS.INTR_HDMI */
...
};

There is a slight awkwardness, in that we cannot disable child irqs
at the mdp level, they can only be cleared in the child block.  So
you must not use threaded irq handlers in the child.  I'm not sure
if there is a better way to deal with that.

Signed-off-by: Rob Clark <robdclark@gmail.com>

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

- More CI dpm fixes
- Initial DPM fan control for SI/CI (disabled by default)
- GPUVM multi-ring efficiency improvements
- Some cursor fixes

* 'drm-next-3.19' of git://people.freedesktop.org/~agd5f/linux: (22 commits)
  drm/radeon: update the VM after setting BO address v4
  drm/radeon: sync PT updates as shared v2
  drm/radeon: sync PD updates as shared
  drm/radeon: fence BO_VAs manually
  drm/radeon: use one VMID for each ring
  drm/radeon: track VM update fences separately
  drm/radeon: fence PT updates manually v2
  drm/radeon: split semaphore and sync object handling v2
  drm/radeon: remove unnecessary VM syncs
  drm/radeon: stop re-reserving the BO in radeon_vm_bo_set_addr
  drm/radeon: rework vm_flush parameters
  drm/radeon/ci: disable needless sclk changes
  drm/radeon/ci: force pcie level before sclk and mclk
  drm/radeon/ci: use different smc command for pcie dpm
  drm/radeon/ci: apply disp voltage changes before clk changes
  drm/radeon: fix PCC debugging message for CI DPM
  drm/radeon/dpm: add thermal dpm support for CI
  drm/radeon/dpm: add smc fan control for CI (v2)
  drm/radeon/dpm: add smc fan control for SI (v2)
  drm/radeon: work around a hw bug in MGCG on CIK
  ...

drm/vmwgfx: Deletion of an unnecessary check before the function call "vfree"

The vfree() function performes also input parameter validation. Thus the test
around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/udl: Deletion of an unnecessary check before the function call "vunmap"

The vunmap() function performes also input parameter validation. Thus the test
around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/tilcdc: Deletion of an unnecessary check before the function call "drm_fbdev_cma_hotplug_event"

The drm_fbdev_cma_hotplug_event() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/edid: Deletion of an unnecessary check before the function call "release_firmware"

The release_firmware() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/atomic: Add missing ERR_PTR casting

This is an oversight from

commit f52b69f1ecfdd7ef6867a257620258c09e569552
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Nov 19 18:38:08 2014 +0100

    drm/atomic: Don't overrun the connector array when hotplugging

Cc: Dave Airlie <airlied@redhat.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gem: Warn on illegal use of the dumb buffer interface v2

It happens on occasion that developers of generic user-space applications
abuse the dumb buffer API to get hold of drm buffers that they can both
mmap() and use for GPU acceleration, using the assumptions that dumb buffers
and buffers available for GPU are
a) The same type and can be aribtrarily type-casted.
b) fully coherent.

This patch makes the most widely used drivers warn nicely when that happens,
the next step will be to fail.

v2: Move drmP.h changes to drm_gem.h. Fix Radeon dumb mmap breakage.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon: update the VM after setting BO address v4

This way the necessary VM update is kicked off immediately
if all BOs involved are in GPU accessible memory.

v2: fix vm lock
v3: immediately update unmaps as well
v4: use drm_free_large instead of kfree

Tested-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: sync PT updates as shared v2

Only invalidating PTEs needs to be executed synchronized to using the PT.

v2: fix sync to uses

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

drm/radeon: sync PD updates as shared

We never invalidate PD entries and making them valid can
run with other users in parallel.

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

drm/radeon: fence BO_VAs manually

This allows us to finally remove the VM fence and
so allow concurrent use of it from different engines.

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

drm/radeon: use one VMID for each ring

Use multiple VMIDs for each VM, one for each ring. That allows
us to execute flushes separately on each ring, still not ideal
cause in a lot of cases rings can share IDs.

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

drm/radeon: track VM update fences separately

Note for each fence if it's a VM page table update or not. This allows
us to determine the last VM update in a sync object and so to figure
out if we need to flush the TLB or not.

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

drm/radeon: fence PT updates manually v2

This allows us to add the real execution fence as shared.

v2: fix typo

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

drm/radeon: split semaphore and sync object handling v2

Previously we just allocated space for four hardware semaphores
in each software semaphore object. Make software semaphore objects
represent only one hardware semaphore address again by splitting
the sync code into it's own object.

v2: fix typo in comment

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

drm/radeon: remove unnecessary VM syncs

The PD/PTs reservation object now contains everything needed.

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

drm/radeon: stop re-reserving the BO in radeon_vm_bo_set_addr

That's useless when all callers drop the reservation
immediately after calling the function.

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

drm/radeon: rework vm_flush parameters

Use ring structure instead of index and provide vm_id and pd_addr separately.

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

drm/radeon/ci: disable needless sclk changes

The current code always reprogrammed the sclk levels,
but we don't currently handle disp sclk requirements
so just skip it.

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

drm/radeon/ci: force pcie level before sclk and mclk

Preferred ordering.

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

drm/radeon/ci: use different smc command for pcie dpm

Use unforce levels rather than enable mask instruction.
This is the preferred method.

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

drm/radeon/ci: apply disp voltage changes before clk changes

Apply voltage changes for displays before changing clocks.

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

drm/radeon: fix PCC debugging message for CI DPM

Add missing newline and print the bad gpio shift.

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

drm/radeon/dpm: add thermal dpm support for CI

Not currently used.

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

drm/radeon/dpm: add smc fan control for CI (v2)

Enable smc fan control for CI boards.  Should
reduce the fan noise on systems with a higher
default fan profile.

v2: disable by default, add additional fan setup, rpm control

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73338

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

drm/radeon/dpm: add smc fan control for SI (v2)

Enable smc fan control for SI boards.  Should
reduce the fan noise on systems with a higher
default fan profile.

v2: disable by default, add rpm controls

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73338

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

drm/radeon: work around a hw bug in MGCG on CIK

Always need to set bit 0 of RLC_CGTT_MGCG_OVERRIDE
to avoid unreliable doorbell updates in some cases.

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

drm/radeon: Move radeon_cursor_move(_locked) to replace forward declaration

No functional change.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor

The cursor_set2 hook provides the cursor hotspot position within the
cursor image. When the hotspot position changes, we can adjust the cursor
position such that the hotspot doesn't move on the screen. This prevents
the cursor from appearing to intermittently jump around on the screen
when the position of the hotspot within the cursor image changes.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Merge branch 'amdkfd-v6' of git://people.freedesktop.org/~gabbayo/linux into drm-next

Merge AMDKFD it seems clean enough.
* 'amdkfd-v6' of git://people.freedesktop.org/~gabbayo/linux: (29 commits)
  amdkfd: Implement the Get Version IOCTL
  amdkfd: Implement the Get Process Aperture IOCTL
  amdkfd: Implement the Get Clock Counters IOCTL
  amdkfd: Implement the Set Memory Policy IOCTL
  amdkfd: Implement the create/destroy/update queue IOCTLs
  amdkfd: Add interrupt handling module
  amdkfd: Add device queue manager module
  amdkfd: Add process queue manager module
  amdkfd: Add packet manager module
  amdkfd: Add module parameter of scheduling policy
  amdkfd: Add kernel queue module
  amdkfd: Add mqd_manager module
  amdkfd: Add queue module
  amdkfd: Add binding/unbinding calls to amd_iommu driver
  amdkfd: Add basic modules to amdkfd
  amdkfd: Add topology module to amdkfd
  amdkfd: Add amdkfd skeleton driver
  amdkfd: Add IOCTL set definitions of amdkfd
  Update MAINTAINERS and CREDITS files with amdkfd info
  drm/radeon: Add radeon <--> amdkfd interface
  ...

drm/cirrus: allow 32bpp framebuffers for cirrus drm

This patch allows framebuffers for cirrus to be created with
32bpp pixel formats provided that they do not violate certain
restrictions of the cirrus hardware.

v2: Use pci resource length for vram size.

Signed-off-by: Zach Reizner <zachr@google.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/udl: add support to export a handle to a FD on UDL.

Only importing an FD to a handle is currently supported on UDL,
but the exporting functionality is equally useful.

Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/udl: add cache flags definitions for udl_gem_object

By default set udl_gem_object as cacheable, but set WC flag when attaching
dmabuf. In udl_gem_mmap() update cache attributes based on the flags, similar
to exynos_drm_gem_mmap().

Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/cirrus: fix leaky driver load error handling

Before this patch, cirrus_device_init could have failed while
cirrus_mm_init succeeded and the driver would have reported overall
success on load. This patch causes cirrus_device_init to return on
the first error encountered.

Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/atomic_helper: Make it clear that commit_planes gets the old state

Oversight from my kerneldoc cleanup when doing the original atomic
helper series - I've only applied this clarification to the modeset
related helpers, and not the plane update code. Remedy this asap.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: s/enum_blob_list/enum_list/ in drm_property

I guess for hysterical raisins this was meant to be the way to read
blob properties. But that's done with the two-stage approach which
uses separate blob kms object and the special-purpose get_blob ioctl.

Shipping userspace seems to have never relied on this, and the kernel
also never put any blob thing onto that property. And nowadays it
would blow up, e.g. in drm_property_destroy. Also it makes no sense to
return values in an ioctl that only returns metadata about everything.

So let's ditch all the internal code for the blob list, rename the
list to be unambiguous and sprinkle comments all over the place to
explain this peculiar piece of api.

v2: Squash in fixup from Rob to remove now unused variables.

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/crtc: Polish kerneldoc

- Make it clear that it's a negative errno (more in line with
  everything else).
- Clean up the confusion around get_properties vs. getproperty ioctls:
  One reads per-obj property values, the other reads property
  metadata.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/atomic: Don't overrun the connector array when hotplugging

Yet another fallout from not considering DP MST hotplug. With the
previous patches we have stable indices, but it might still happen
that a connector gets added between when we allocate the array and
when we actually add a connector. Especially when we back off due to
ww mutex contention or similar issues.

So store the sizes of the arrays in struct drm_atomic_state and double
check them. We don't really care about races except that we want to
use a consistent value, so ACCESS_ONCE is all we need. And if we
indeed notice that we'd overrun the array then just give up and
restart the entire ioctl.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/atomic: Only destroy connector states with connection mutex held

Otherwise the connector might have been unplugged and destroyed while
we didn't look. Yet another fallout from DP MST hotplugging that I
didn't consider.

To make sure we get this right add an appropriate WARN_ON to
drm_atomic_state_clear (obviously only when we actually have a state
to clear up). And reorder all the state_clear and backoff calls to
make it work out properly.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/atomic: Ensure that drm_connector_index is stable

I've totally forgotten that with DP MST connectors can now be
hotplugged. And failed to adapt Rob's drm_atomic_state code (which
predates connector hotplugging) to the new realities.

The first step is to make sure that the connector indices used to
access the arrays of pointers are stable. The connection mutex gives
us enough guarantees for that, which means we won't unecessarily block
on concurrent modesets or background probing.

So add a locking WARN_ON and shuffle the code slightly to make sure we
always hold the right lock.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/irq: BUG_ON() -> WARN_ON()

Let's make things a bit easier to debug when things go bad (potentially
under console_lock).

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/ttm: Avoid memory allocation from shrinker functions.

Andrew Morton wrote:
> On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> > Andrew Morton wrote:
> > > Poor ttm guys - this is a bit of a trap we set for them.
> >
> > Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid deadlock.")
> > changed to use sc->gfp_mask rather than GFP_KERNEL.
> >
> > -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
> > -                       GFP_KERNEL);
> > +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> >
> > But this bug is caused by sc->gfp_mask containing some flags which are not
> > in GFP_KERNEL, right? Then, I think
> >
> > -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> > +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & GFP_KERNEL);
> >
> > would hide this bug.
> >
> > But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag)
>
> Well no - ttm_page_pool_free() should stop calling kmalloc altogether.
> Just do
>
>  struct page *pages_to_free[16];
>
> and rework the code to free 16 pages at a time.  Easy.

Well, ttm code wants to process 512 pages at a time for performance.
Memory footprint increased by 512 * sizeof(struct page *) buffer is
only 4096 bytes. What about using static buffer like below?
----------
>From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Thu, 13 Nov 2014 22:21:54 +0900
Subject: [PATCH] drm/ttm: Avoid memory allocation from shrinker functions.

Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid
deadlock.") caused BUG_ON() due to sc->gfp_mask containing flags
which are not in GFP_KERNEL.

  https://bugzilla.kernel.org/show_bug.cgi?id=87891

Changing from sc->gfp_mask to (sc->gfp_mask & GFP_KERNEL) would
avoid the BUG_ON(), but avoiding memory allocation from shrinker
function is better and reliable fix.

Shrinker function is already serialized by global lock, and
clean up function is called after shrinker function is unregistered.
Thus, we can use static buffer when called from shrinker function
and clean up function.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: remove unnecessary sizeof(u8)

sizeof(u8) is always 1.

Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: omapdrm: remove unused variable

Commit f9b9faf6d94dd29eab8c128905c7d091f955481d "drm: flip-work: change
drm_flip_work_init prototype" changed the drm_flip_work_init prototype
to a void function, which makes 'ret' an unused variable.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

bochs: add page_flip

Implement crtc page_flip callback for bochsdrm.  The qemu stdvga has no
vblank signaling, so we have to fake it.  We do so by instantly calling
drm_send_vblank_event.  Tested with kmscon.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

bochs: fix bochsdrmfb mmap

Remove the mapping offset from the bo backing the fbdev framebuffer.
Wire up fbdev mmap function to map the backing bo using ttm_fbdev_mmap.
With that patch in place mmap(/dev/fb0) works as expected.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

bochs: add endian switching support

Recently (qemu 2.2+) the qemu stdvga got a register to switch the vga
framebuffer endianness.  This patch adds code to explicitly set the
endianness of the framebuffer.  In most cases this has no effect as
the default is guest architecture endianness.  It is needed though in
case a architecture supports both big and little endian, i.e. for
ppc64le.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

bochs: little cleanup

Drop some leftover, commented code.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next

Main pull for 3.19.  I may have another pull in a few days with some
mdp5 bits (and hopefully mdp5 atomic), but I figured there was no need
to hold up what we have already.  Main highlights so far:

1) a4xx gpu support (userspace gallium bits on mesa master)
2) mdp4/hdmi/core bits for atomic helpers.  Still missing mdp5
conversion, main hold up there is current hard-coded mixer setup isn't
clever enough to deal with disabling primary plane while crtc active.
3) various other misc cleanup/fixes/etc..

* 'msm-next' of git://people.freedesktop.org/~robclark/linux: (21 commits)
  drm/msm: a4xx support for msm-drm
  drm/msm: Handle register offset differences between a3xx and a4xx
  drm/msm: small mmap offset cleanups
  drm/msm/mdp4: atomic
  drm/msm/hdmi: atomic
  drm/msm: atomic core bits
  drm/msm: bit of fb error checking
  drm/msm: fb prepare/cleanup
  drm/msm: remove unused compile-test stub
  drm/msm: small fence cleanup
  drm/msm/mdp5: drop attached planes table
  drm/msm/mdp4: drop attached planes table
  drm/msm/mdp4: don't care about fb in crtc
  drm/msm/mdp5: drop private primary ptr
  drm/msm/mdp4: drop private primary ptr
  drm/msm: Fix fbdev for 16- and 24-bit modes.
  drm/msm: Allow exported dma-bufs to be mapped
  drm/msm/hdmi: refactor bind/init
  drm/msm: update generated headers
  drm/msm/adreno: slight init order cleanup
  ...

drm/msm: a4xx support for msm-drm

Added a4xx GPU support.

Signed-off-by: Aravind Ganesan <aravindg@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: Handle register offset differences between a3xx and a4xx

Register offsets have changed between a3xx and a4xx GPUs.
To be able access these registers in common code, we create
a lookup table, and set of read-write APIs to access the
register through the lookup table.

Signed-off-by: Aravind Ganesan <aravindg@codeaurora.org>
[robclark: remove REG_ADRENO_UNDEFINED, just use zero, and minor
tweaks for latest generated headers]
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: small mmap offset cleanups

Use pre-computed iova when unmapping, to reduce the places we assume iova
and mmap offset are (at the moment) the same.  And get rid of an extra
drm_gem_free_mmap_offset() call (since it is already called from
drm_gem_object_release())

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp4: atomic

Convert mdp4 display controller backend to atomic helpers.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/hdmi: atomic

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: atomic core bits

The core parts for async commit.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: bit of fb error checking

It's a problem that can't happen yet, since we don't support any
multi-planar formats yet.  But let's avoid nasty surprises when the
time comes.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: fb prepare/cleanup

Atomic wants to split the prepare/pin from where we actually program the
scanout address (so that any part that can fail is done synchronously).
Add some fb/gem apis to make this easier to use from the kms parts.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: remove unused compile-test stub

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: small fence cleanup

Give ourselves a way to wait for certain fence #..  makes it easier to
wait on a set of bo's, which we'll need for atomic.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: drop attached planes table

Simplify things a bit for atomic, gets rid of some bookkeeping, and
makes the code cleaner.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp4: drop attached planes table

Simplify things a bit for atomic, gets rid of some bookkeeping, and
makes the code cleaner.

TODO move iterator macro somewhere common.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp4: don't care about fb in crtc

Since we are configuring things via MDP4_PIPE regs in the plane, it seems
like setting the dimensions of the primary plane on the OVLP/DMA regs in
crtc is unnecessary.  This will make life easier when we want to do a
nofb modeset.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: drop private primary ptr

Since primary-plane support in core, we can just use crtc->primary.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp4: drop private primary ptr

Since primary-plane support in core, we can just use crtc->primary.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: Fix fbdev for 16- and 24-bit modes.

Currently forcing the video mode from the kernel command line (for example
video=HDMI-A-1:1280x720-16@60) does not correctly set the number of bits
per pixel. This is due to a rather aggressive override in
msm_fbdev_create(). This is a particular problem for Android bring up
because the software EGL fallbacks don't support 32bpp.

Since the overrides are actually the default values anyway then this
problem can be trivially fixed by removing the overrides completely.

Change was tested by dd'ing a test image to /dev/fb0 with no video=
(still 32bpp), video=1920x1080-32@60, video=1920x1080-24@60 and
video=1920x1080-16@60 .

Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>