Useful since this way we can pass around just the state objects and
will get ther real object, too.

Specifically this allows us to again simplify the parameters for
set_crtc_for_plane.

v2: msm already has it's own specific plane_reset hook, don't forget
that one!

v3: Fixup kerneldoc, reported by 0-day builder.

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

This essentially reverts

commit 934ce1c2
Author: Rob Clark <robdclark@gmail.com>
Date:   Wed Nov 19 16:41:33 2014 -0500

    drm/atomic: check mode_changed *after* atomic_check

Depending upon the driver both orders (or maybe even interleaving) is
required:
- If ->atomic_check updates ->mode_changed then helper_check_modeset
  must be run afters.
- If ->atomic_check depends upon accurate adjusted dotclock values for
  e.g. watermarks, then helper_check_modeset must be run first.

The failure mode in the first case is usually a totally angry hw
because the pixel format switching doesn't happen. The failure mode in
the later case is usually nothing, since in most cases the old
adjusted mode from the previous modeset wont be too far off to be a
problem. So just underruns and perhaps even just suboptimal (from a
power consumption) watermarks.

Furthermore in the transitional helpers we only call ->atomic_check
after the new modeset state has been fully set up (and hence
computed).

Given that asymmetry in expected failure modes I think it's safer to
go back to the older order. So do that and give msm a special check
function to compensate.

Also update kerneldoc to explain this a bit.

v2: Actually add the missing hunk Rob spotted.

v3: Move msm_atomic_check into msm_atomic.c, requested by Rob.

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

The default call sequence for these two parts won't fit for all
drivers. So export the two pieces and explain with a bit of kerneldoc
when each should be called.

v2: Squash in fixup from Rob to actually add the newly exported
functions to headers

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

When a plane is being enabled, plane->crtc has not been set yet.  Use
plane->state->crtc.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

When compiling in module some symbol aren't missing,
export them correctly.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm-sti-next-2014-12-11' of http://git.linaro.org/people/benjamin.gaignard/kernel into drm-next

This series of patches fix various issues in STI drm driver.
Now HDMI i2c adapter could be selected in device tree
and plug detection doesn't use gpio anymore.
I also had fix some signal timing problems after testing the driver
on more hardware.
The remaining patches attemps to simplify the code and prepare
the next evolutions like DVO and auxiliary CRTC support

* 'drm-sti-next-2014-12-11' of http://git.linaro.org/people/benjamin.gaignard/kernel:
  drm: sti: correctly cleanup CRTC and planes
  drm: sti: add HQVDP plane
  drm: sti: add cursor plane
  drm: sti: enable auxiliary CRTC
  drm: sti: fix delay in VTG programming
  drm: sti: prepare sti_tvout to support auxiliary crtc
  drm: sti: use drm_crtc_vblank_{on/off} instead of drm_vblank_{on/off}
  drm: sti: fix hdmi avi infoframe
  drm: sti: remove event lock while disabling vblank
  drm: sti: simplify gdp code
  drm: sti: clear all mixer control
  drm: sti: remove gpio for HDMI hot plug detection
  drm: sti: allow to change hdmi ddc i2c adapter

Merge tag 'drm-intel-next-fixes-2014-12-11' of git://anongit.freedesktop.org/drm-intel into drm-next

Here's a batch of i915 fixes for 3.19.

* tag 'drm-intel-next-fixes-2014-12-11' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: save/restore GMBUS freq across suspend/resume on gen4
  drm/i915: Remove '& 0xffff' from the mask given to WA_REG()
  drm/i915: Invert the mask and val arguments in wa_add() and WA_REG()
  drm/i915/bdw: Fix the write setting up the WIZ hashing mode
  drm/i915: Don't complain about stolen conflicts on gen3
  drm/i915: resume MST after reading back hw state
  drm/i915: Handle inaccurate time conversion issues
  drm/i915: compute wait_ioctl timeout correctly
  drm/i915: don't always do full mode sets when infoframes are enabled

Should probably just init this in the GMbus code all the time, based on
the cdclk and HPLL like we do on newer platforms.  Ville has code for
that in a rework branch, but until then we can fix this bug fairly
easily.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76301Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Nikolay <mar.kolya@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

When bind failed make sure that CRTC and planes are
completely clean up to avoid properties duplication.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

High Quality Video Data Plane is hardware IP dedicated
to video rendering. Compare to GPD (graphic planes) it
have better scaler capabilities.

HQVDP use VID layer to push data into hardware compositor
without going into DDR. From data flow point of view HQVDP
and VID are nested so HQVPD update/disable VID.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

stih407 SoC have a dedicated hardware cursor plane,
this patch enable it.
The hardware have a color look up table, fix it to
be able to use ARGB8888.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

For stih407 SoC enable the second mixer to get two CRTC.
Allow GPD planes and encoders to be connected to this new CRTC.
Cursor plane can only be set on first CRTC.
GPD clocks needed change the parent clock depending on which
CRTC GPD are used.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

The HDMI path introduce a delay of 6 pixels.
This delay should be take into account while programming
VTG for the HDMI. Without this delay, the HDMI active
window area is shift of 6 pixel on the right.

Set also timing for DVO output.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

Change some functions prototype to prepare the introduction of
auxiliary crtc. It will also help to have a DVO encoder.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

Make sure that vblank is enabled when crtc commit is call.
Replace drm_vblank_off() by drm_crtc_vblank_off()
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

The hardware expect to have the infoframe checksum in the first byte.
In consequence shift all infoframe on one byte.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

Stop use event_lock in vblank disable function.
This was creating a dead lock.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

Store the physical address at node creation time
to avoid use of virt_to_dma and dma_to_virt everywhere
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

Make sure that mixer control register is correctly reset
before use it.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

gpio used for HDMI hot plug detection is useless,
HDMI_STI register contains an hot plug detection status bit.
Fix binding documentation.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

Depending of the board configuration i2c for ddc could change,
this patch allow to use a phandle to specify which i2c controller to use.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

And fix a spelling mistake.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge drm core fixes from Daniel.

* tag 'topic/core-stuff-2014-12-10' of git://anongit.freedesktop.org/drm-intel:
  drm: Zero out DRM object memory upon cleanup
  drm: fix a typo in a comment
  drm: fix a word repetition in a comment
  drm: Fix memory leak at error path of drm_read()
  drm/Documentation: Fix rowspan value in drm-kms-properties
  drm/edid: Restore kerneldoc consistency
  drm/edid: new drm_edid_block_checksum helper function V3
  drm/edid: shorten log output in case of all zeroes edid block
  drm/edid: move drm_edid_is_zero to top, make edid argument const

We may be hidding bugs by doing that, so let remove it and have the
actual mask value shine through, for better or worse.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

While trying to unify the order of those arguments throughout the
driver, Daniel noticed what we were inverting them in this part of the
code.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Drivers where the DRM objects have a lifetime that extends beyond that
of the DRM device need to zero out the DRM object memory to void stale
data such as properties. The DRM core code expects to operate on newly
allocated and zeroed out objects and will behave unexpectedly, such as
add duplicate properties, otherwise.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

I was playing with clang and oh surprise! a warning trigerred by
-Wshift-overflow (gcc doesn't have this one):

    WA_SET_BIT_MASKED(GEN7_GT_MODE,
                      GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);

    drivers/gpu/drm/i915/intel_ringbuffer.c:786:2: warning: signed shift result
      (0x28002000000) requires 43 bits to represent, but 'int' only has 32 bits
      [-Wshift-overflow]
        WA_SET_BIT_MASKED(GEN7_GT_MODE,
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/gpu/drm/i915/intel_ringbuffer.c:737:15: note: expanded from macro
      'WA_SET_BIT_MASKED'
        WA_REG(addr, _MASKED_BIT_ENABLE(mask), (mask) & 0xffff)

Turned out GEN6_WIZ_HASHING_MASK was already shifted by 16, and we were
trying to shift it a bit more.

The other thing is that it's not the usual case of setting WA bits here, we
need to have separate mask and value.

To fix this, I've introduced a new _MASKED_FIELD() macro that takes both the
(unshifted) mask and the desired value and the rest of the patch ripples
through from it.

This bug was introduced when reworking the WA emission in:

  Commit 7225342a
  Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
  Date:   Tue Oct 7 17:21:26 2014 +0300

      drm/i915: Build workaround list in ring initialization

v2: Invert the order of the mask and value arguments (Daniel Vetter)
    Rewrite _MASKED_BIT_ENABLE() and _MASKED_BIT_DISABLE() with
    _MASKED_FIELD() (Jani Nikula)
    Make sure we only evaluate 'a' once in _MASKED_BIT_ENABLE() (Dave Gordon)
    Add check to ensure the value is within the mask boundaries (Chris Wilson)

v3: Ensure the the value and mask are 16 bits (Dave Gordon)

Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Apparently stuff works that way on those machines.

I agree with Chris' concern that this is a bit risky but imo worth a
shot in -next just for fun. Afaics all these machines have the pci
resources allocated like that by the BIOS, so I suspect that it's all
ok.

This regression goes back to

commit eaba1b8f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jul 4 12:28:35 2013 +0100

    drm/i915: Verify that our stolen memory doesn't conflict

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76983
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71031Tested-by: lu hua <huax.lu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR.

CC: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge mst tiling patches and MST fixes

* 'drm-mst-next' of ssh://people.freedesktop.org/~/linux:
  drm/fb: add support for tiled monitor configurations. (v2)
  drm/tile: expose the tile property to userspace (v3)
  drm/connector: store tile information from displayid (v3)
  drm/mst: cached EDID for logical ports (v2)
  drm: add tile_group support. (v3)
  drm/displayid: add displayid defines and edid extension (v2)
  drm/dp-mst: Remove branches before dropping the reference
  drm/fb_helper: move deferred fb checking into restore mode (v2)
  drm/dp: retry AUX transactions 32 times (v1.1)

This adds fbdev/con support for tiled monitors, so that we
only set a mode on the correct half of the monitor, or
span the two halves if needed.

v2: remove unneeded ERROR, fix | vs ||
Signed-off-by: Dave Airlie <airlied@redhat.com>

This takes the tiling info from the connector and
exposes it to userspace, as a blob object in a
connector property.

The contents of the blob is ABI.

v2: add property + function documentation.

v3: move property setup from previous patch.
add boilerplate + fix long line (Daniel)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

This creates a tile group from DisplayID block, and
stores the pieces of parsed info from the DisplayID block
into the connector.

v2: add missing signoff, add new connector bits to docs.

v3: remove some debugging.
Signed-off-by: Dave Airlie <airlied@redhat.com>

Logical ports are never going to have EDID changes,
they are used for the internal ports on MST monitors.

We cache the EDIDs from these to save time at MST probe.

v2: drop misplace tile property line, meant for other patch.
Signed-off-by: Dave Airlie <airlied@redhat.com>

A tile group is an identifier shared by a single monitor,
DisplayID topology has 8 bytes we can use for this, just
use those for now until something else comes up in the
future. We assign these to an idr and use the idr to
tell userspace what connectors are in the same tile group.

DisplayID v1.3 says the serial number must be unique for
displays from the same manufacturer.

v2:
destroy idr (dvdhrm)
add docbook (danvet)
airlied:- not sure how to make docbook add fns to tile group section.

v3: fix missing unlock.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

These are just taken from the DisplayID v1.3 spec, and the
DDC spec.

v2: use __packed (Jani)
Signed-off-by: Dave Airlie <airlied@redhat.com>

When we unplug a dp mst branch we unreference the entire tree from
the root towards the leaves. Which is ok, since that's the way the
pointers and so also the refcounts go.

But when we drop the reference we must make sure that we remove the
branches/ports from the lists/pointers before dropping the reference.
Otherwise the get_validated functions will still return it instead
of returning NULL (which indicates a potentially on-going unplug).

The mst branch destroy gets this right for ports: First it deletes
the port from the ports list, then it unrefs. But the ports destroy
function gets it wrong: First it unrefs, then it drops the ref. Which
means a zombie mst branch can still be validate with get_validated_mstb_ref
when it shouldn't.

Fix this.

This should address a backtrace Dave dug out somewhere on unplug:

 [<ffffffffa00cc262>] drm_dp_mst_get_validated_mstb_ref_locked+0x92/0xa0 [drm_kms_helper]
 [<ffffffffa00cc211>] drm_dp_mst_get_validated_mstb_ref_locked+0x41/0xa0 [drm_kms_helper]
 [<ffffffffa00cc2aa>] drm_dp_get_validated_mstb_ref+0x3a/0x60 [drm_kms_helper]
 [<ffffffffa00cc2fb>] drm_dp_payload_send_msg.isra.14+0x2b/0x100 [drm_kms_helper]
 [<ffffffffa00cc547>] drm_dp_update_payload_part1+0x177/0x360 [drm_kms_helper]
 [<ffffffffa015c52e>] intel_mst_disable_dp+0x3e/0x80 [i915]
 [<ffffffffa013d60b>] haswell_crtc_disable+0x1cb/0x340 [i915]
 [<ffffffffa0136739>] intel_crtc_control+0x49/0x100 [i915]
 [<ffffffffa0136857>] intel_crtc_update_dpms+0x67/0x80 [i915]
 [<ffffffffa013fa59>] intel_connector_dpms+0x59/0x70 [i915]
 [<ffffffffa015c752>] intel_dp_destroy_mst_connector+0x32/0xc0 [i915]
 [<ffffffffa00cb44b>] drm_dp_destroy_port+0x6b/0xa0 [drm_kms_helper]
 [<ffffffffa00cb588>] drm_dp_destroy_mst_branch_device+0x108/0x130 [drm_kms_helper]
 [<ffffffffa00cb3cd>] drm_dp_port_teardown_pdt+0x3d/0x50 [drm_kms_helper]
 [<ffffffffa00cdb79>] drm_dp_mst_handle_up_req+0x499/0x540 [drm_kms_helper]
 [<ffffffff810d9ead>] ? trace_hardirqs_on_caller+0x15d/0x200 [<ffffffffa00cdc73>]
 drm_dp_mst_hpd_irq+0x53/0xa00 [drm_kms_helper] [<ffffffffa00c7dfb>]
 ? drm_dp_dpcd_read+0x1b/0x20 [drm_kms_helper] [<ffffffffa0153ed8>]
 ? intel_dp_dpcd_read_wake+0x38/0x70 [i915] [<ffffffffa015a225>]
 intel_dp_check_mst_status+0xb5/0x250 [i915] [<ffffffffa015ac71>]
 intel_dp_hpd_pulse+0x181/0x210 [i915] [<ffffffffa01104f6>]
 i915_digport_work_func+0x96/0x120 [i915]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

On MST systems the monitors don't appear when we set the fb up,
but plymouth opens the drm device and holds it open while they
come up, when plymouth finishes and lastclose gets called we
don't do the delayed fb probe, so the monitor never appears on the
console.

Fix this by moving the delayed checking into the mode restore.

v2: Daniel suggested that ->delayed_hotplug is set under
the mode_config mutex, so we should check it under that as
well, while we are in the area.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

At least on two MST devices I've tested with, when
they are link training downstream, they are totally
unable to handle aux ch msgs, so they defer like nuts.
I tried 16, it wasn't enough, 32 seems better.

This fixes one Dell 4k monitor and one of the
MST hubs.

v1.1: fixup comment (Tom).
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>