drm/i915: Register debugfs interface last

Currently debugfs files are created before the driver is even loads.
This gives the opportunity for userspace to open that interface and poke
around before the backing data structures are initialised - with the
possibility of oopsing or worse.

Move the creation of the debugfs files to our registration phase, where
we announce our presence to the world when we are ready, i.e the
sequence changes from

drm_dev_register()
 -> drm_minor_register()
  -> drm_debugfs_init()
   -> i915_debugfs_init()
 -> i915_driver_load()

to

drm_dev_register()
 -> drm_minor_register()
  -> drm_debugfs_init()
 -> i915_driver_load()
  -> i915_debugfs_register()

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-5-git-send-email-chris@chris-wilson.co.uk

drm/i915: Move connector registration to driver registration

Defer connector registration from during construction to the driver
registration phase. This is important for ordering the action correctly,
e.g. not using debugfs before it is ready.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-4-git-send-email-chris@chris-wilson.co.uk

drm/i915: Move backlight registration to connector registration

Currently the backlight is being registered in the load phase (before
the display and its objects are registered). Move the backlight
registration into the analogous phase by performing it from the
connector registration, just after its creation.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-3-git-send-email-chris@chris-wilson.co.uk

drm/i915: Move registration actions to connector->late_register

With the introduction of a connector->func for callback from
drm_connector_register() we can move all the tasks that we want to do
upon registration into that callback. Later, this will allow us to
reorder the registration and defer it until after the device is setup
and ready for userspace.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-2-git-send-email-chris@chris-wilson.co.uk

drm/i915: Move panel's backlight setup next to panel init

Currently setting up the backlight for a panel is sometimes done
together with initialising the panel, and sometimes after the connector
is registered. The backlight setup does not depend upon connector
registration (i.e. access to sysfs/debugfs and the kobject hierachy) so
perform it consistently just after panel initialisation.

Note the discrepancy here as destroying the panel is done during
connector unregistration...

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-1-git-send-email-chris@chris-wilson.co.uk

drm/i915: Small compaction of the engine init code

Effectively removes one layer of indirection between the mask of
possible engines and the engine constructors. Instead of spelling
out in code the mapping of HAS_<engine> to constructors, makes
more use of the recently added data driven approach by putting
engine constructor vfuncs into the table as well.

Effect is fewer lines of source and smaller binary.

At the same time simplify the error handling since engine
destructors can run on unitialized engines anyway.

Similar approach could be done for legacy submission is wanted.

v2: Removed ugly BUILD_BUG_ONs in favour of newly introduced
    ENGINE_MASK and HAS_ENGINE macros.
    Also removed the forward declarations by shuffling functions
    around.

v3: Warn when logical_rings table does not contain enough data
    and disable the engines which could not be initialized.
    (Chris Wilson)

v4: Chris Wilson suggested a nicer engine init loop.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1466689961-23232-1-git-send-email-tvrtko.ursulin@linux.intel.com

Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued

Backmerge drm-next for the reworked device register/unregistering.
Chris Wilson needs that to be able to land his i915 load/unload
demidlayering.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Merge tag 'mediatek-drm-2016-06-20' of git://git.pengutronix.de/git/pza/linux into drm-next

MT8173 HDMI support

- device tree binding documentation for MT8173 HDMI encoder, CEC, DDC,
  and PHY
- drivers for MT8173 HDMI encoder, CEC (HPD only for now), DDC, and PHY
- enable HDMI output via a custom SMCCC call
- add ddc-i2c-bus property to HDMI connector device tree binding

* tag 'mediatek-drm-2016-06-20' of git://git.pengutronix.de/git/pza/linux:
  dt-bindings: hdmi-connector: add DDC I2C bus phandle documentation
  drm/mediatek: enable hdmi output control bit
  drm/mediatek: Add HDMI support
  dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding

Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/media into drm-next

some rcar-du fixes.

* 'drm/next/du' of git://linuxtv.org/pinchartl/media:
  drm: rcar-du: error message is not needed for EPROBE_DEFER
  drm: rcar-du: error message is not needed for drm_vblank_init()
  rcar-du: add/rename DEFR6 TCON bits

Merge tag 'drm-intel-next-2016-06-20' of git://anongit.freedesktop.org/drm-intel into drm-next

- Infrastructure for GVT-g (paravirtualized gpu on gen8+), from Zhi Wang
- another attemp at nonblocking atomic plane updates
- bugfixes and refactoring for GuC doorbell code (Dave Gordon)
- GuC command submission enabled by default, if fw available (Dave Gordon)
- more bxt w/a (Arun Siluvery)
- bxt phy improvements (Imre Deak)
- prep work for stolen objects support (Ankitprasa Sharma & Chris Wilson)
- skl/bkl w/a update from Mika Kuoppala
- bunch of small improvements and fixes all over, as usual

* tag 'drm-intel-next-2016-06-20' of git://anongit.freedesktop.org/drm-intel: (81 commits)
  drm/i915: Update DRIVER_DATE to 20160620
  drm/i915: Introduce GVT context creation API
  drm/i915: Support LRC context single submission
  drm/i915: Introduce execlist context status change notification
  drm/i915: Make addressing mode bits in context descriptor configurable
  drm/i915: Make ring buffer size of a LRC context configurable
  drm/i915: gvt: Introduce the basic architecture of GVT-g
  drm/i915: Fold vGPU active check into inner functions
  drm/i915: Use offsetof() to calculate the offset of members in PVINFO page
  drm/i915: Factor out i915_pvinfo.h
  drm/i915: Serialise presentation with imported dmabufs
  drm/i915: Use atomic commits for legacy page_flips
  drm/i915: Move fb_bits updating later in atomic_commit
  drm/i915: nonblocking commit
  Reapply "drm/i915: Pass atomic states to fbc update, functions."
  drm/i915: Roll out the helper nonblock tracking
  drm/i915: Signal drm events for atomic
  drm/i915/ilk: Don't disable SSC source if it's in use
  drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission
  drm/i915/guc: replace assign_doorbell() with select_doorbell_register()
  ...

Merge tag 'topic/drm-misc-2016-06-22-updated' of git://anongit.freedesktop.org/drm-intel into drm-next

Again a pile of things all over
- Conversion to rst from docbook from Jani. Looks real pretty, and the
  source is now actually readable (compared to horrible, horrible docbook
  xml)! https://01.org/linuxgraphics/gfx-docs/drm/
- device register/unregister rework from Chris, with follow-up work from
  Benjamin. Allows more drivers to demidlayer load/unload and others to
  remove a bit of boilerplate.
- master/auth related cleanup, with docs
- some dma-buf polish, merged by Sumit
- small stuff all over (like build fixes from Arnd)

Group maintainership seems to slowly take off, with both Thierry and Sumit
pushing a few things. No hiccups thus far.

* tag 'topic/drm-misc-2016-06-22-updated' of git://anongit.freedesktop.org/drm-intel: (68 commits)
  drm/vc4: Remove unused connector
  drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference
  drm/sun4i: Remove open-coded drm_connector_register_all()
  drm/vc4: Remove open-coded drm_connector_register_all()
  drm/atmel-hlcdc: Remove redundant call to drm_connector_unregister_all()
  drm: document drm_auth.c
  drm: Clear up master tracking booleans
  drm: Extract drm_is_current_master
  drm: Refactor drop/set master code a bit
  drm: Lobotomize set_busid nonsense for !pci drivers
  drm: Nuke SET_UNIQUE ioctl
  drm: Don't call drm_dev_set_unique from platform drivers
  drm/vgem: Stop calling drm_drv_set_unique
  drm: Use dev->name as fallback for dev->unique
  drm: Clean up drm_crtc.h
  drm: Move master pointer from drm_minor to drm_device
  drm: sti: rework init sequence
  drm: sti: use late_register and early_unregister callbacks
  drm/amdkfd: Clean up inline handling
  drm: Add callbacks for late registering
  ...

Merge tag 'drm-sii902x' of github.com:bbrezillon/linux-at91 into drm-next

Add basic support for the sii902x RGB -> HDMI bridge.

* tag 'drm-sii902x' of github.com:bbrezillon/linux-at91:
  drm/bridge: Add sii902x DT bindings doc
  drm/bridge: Add sii902x driver

drm/i915: Refresh cached DP port register value on resume

During hibernation the cached DP port register value will be left with
whatever value we have there when we create the hibernation image.
Currently that means the port (and eDP PLL) will be off in the cached
value. However when we resume there is no guarantee that the value
in the actual register will match the cached value. If i915 isn't
loaded in the kernel that loads the hibernation image, the port may
well be on (eg. left on by the BIOS). The encoder state readout
does the right thing in this case and updates our encoder state
to reflect the actual hardware state. However the post-resume modeset
will then use the stale cached port register value in
intel_dp_link_down() and potentially confuse the hardware.

This was caught by the following assert
 WARNING: CPU: 3 PID: 5288 at ../drivers/gpu/drm/i915/intel_dp.c:2184 assert_edp_pll+0x99/0xa0 [i915]
 eDP PLL state assertion failure (expected on, current off)
on account of the eDP PLL getting prematurely turned off when
shutting down the port, since the DP_PLL_ENABLE bit wasn't set
in the cached register value.

Presumably I introduced this problem in
commit 6fec76628333 ("drm/i915: Use intel_dp->DP in eDP PLL setup")
as before that we didn't update the cached value after shuttting the
port down. That's assuming the port got enabled at least once prior
to hibernating. If that didn't happen then the cached value would
still have been totally out of sync with reality (eg. first boot w/o
eDP on, then hibernate, and then resume with eDP on).

So, let's fix this properly and refresh the cached register value from
the hardware register during resume.

DDI platforms shouldn't use the cached value during port disable at
least, so shouldn't have this particular issue. They might still have
issues if we skip the initial modeset and then try to retrain the link
or something. But untangling this DP vs. DDI mess is a bigger topic,
so let's jut punt on DDI for now.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Fixes: 6fec76628333 ("drm/i915: Use intel_dp->DP in eDP PLL setup")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463162036-27931-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Sanity check PPS HW state

The wait for panel status helper will only function correctly if the
HW panel timings are programmed correctly. Returning prematurely from
this helper may lead to obscure bugs later, so sanity check the HW
timing registers.

v2:
- Check the T8, T9 fields too, we do program them (Ville)

CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466096506-11937-1-git-send-email-imre.deak@intel.com

drm/i915: Factor out helper to read out PPS HW state

This will be needed by the next patch too so factor it out.

No functional change.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466084243-5388-4-git-send-email-imre.deak@intel.com

drm/i915: Deduplicate PPS register retrieval

No functional change.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466084243-5388-3-git-send-email-imre.deak@intel.com

drm/i915/bxt: Fix PPS lost state after suspend breaking eDP link training

The PPS registers are backed by power well #0 and as such may be reset
after system or runtime suspend (both implying a possible DC9
transition). Fix this by reusing the VLV/CHV PPS pipe-reassignment
logic. The difference on BXT is that the PPS instances are not pipe but
port (or more accurately pin) specific, so we only need to care about
the lost HW state. As opposed to VLV/CHV the SW state is fixed and
initialized during connector init.

This also paves the way towards using the actual port->PPS instance
mapping based on VBT.

This fixes eDP link training errors on BXT after suspend, where we
started the link training too early due to an incorrect T3 (panel power
on) register value.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96436
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466084243-5388-2-git-send-email-imre.deak@intel.com

drm/i915: Group all the PPS init steps to one place

Move the early PPS initialization calls next to the rest of PPS
initialization steps. This allows us to forgo a duplicated call to
intel_dp_init_panel_power_sequencer_registers() on VLV/CHV.

This will swap the order of DP AUX registration wrt. PPS initialization.
There is an existing race here in case of a user space access via the
DPAUX device node after DP AUX registration and before calling
intel_dp_init_panel_power_sequencer_registers(), but this change won't
make this worse. The fix for this is to separate DP AUX initialization
and registration, that's a separate work already underway.

The order of MST wrt. PPS init as well as the order of
intel_dp_init_panel_power_sequencer_registers() wrt.
intel_edp_panel_vdd_sanitize() also swap, which is ok, there are no
dependencies between these steps.

Suggested by Ville.

CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466499109-20240-4-git-send-email-imre.deak@intel.com

drm/i915: Initialize the PPS HW before its first use

The initial DPCD read for eDP detection involves using the PPS, but so
far we only initialized the PPS registers after the DPCD read. The
reason this was done so far is to preserve a possible LVDS PPS HW setup
if LVDS is detected but eDP is not. This is not an issue any more after
the previous patch, so we can move the init earlier now.

This was caught by CI with the PPS sanity checks in place and the
initial eDP DPCD readout waiting for the panel power cycle timeout
without the PPS registers being initialized.

CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466499109-20240-3-git-send-email-imre.deak@intel.com

drm/i915/ibx, cpt: Don't attempt to register eDP if LVDS was detected

Atm on IBX/CPT we attempt to detect if eDP is present even if LVDS was
already detected and an encoder for it was registered. This involves
trying to read out the eDP DPCD, which in turn needs the same power
sequencer that LVDS uses. Poking at the VDD line at an unexpected time
may or may not interfere with the LVDS panel, but it's probably safer to
prevent this. Registering both an LVDS and an eDP connector would also
present a similar problem accessing the shared PPS at any point later in
an unexpected way.

We also need this to be able fix PPS initialization before its first use
in the next patch. For that we want to be sure that PPS is not in use
by LVDS.

v2:
- Split out the PPS init fix to a separate patch. (Chris)
- Add comment about eDP init depending on LVDS init. (Chris)
- Make the use of the intel_encoder ptr less error prone.
v3:
- Use IBX/CPT reference instead of the incorrect ILK, add a WARN about
  this. (Ville)
v4:
- Use a helper to get the lvds encoder instead of opencoding the same.
  (Ville)

CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v3)
Link: http://patchwork.freedesktop.org/patch/msgid/1466499109-20240-2-git-send-email-imre.deak@intel.com

drm/vc4: Remove unused connector

Somehow I didn't spot this when pushing :(

Fixes: 398e97994f6d ("drm/vc4: Remove open-coded drm_connector_register_all()")
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference

We are only documenting that the read is outside of the lock, and do not
require strict ordering on the operation. In this case the more relaxed
lockless_dereference() will suffice.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466581572-16608-1-git-send-email-chris@chris-wilson.co.uk

drm/sun4i: Remove open-coded drm_connector_register_all()

drm_dev_register() will now register all known connectors, so we no
longer have to do so manually.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466501283-19976-4-git-send-email-chris@chris-wilson.co.uk

drm/vc4: Remove open-coded drm_connector_register_all()

drm_dev_register() will now register all known connectors, so we no
longer have to do so manually.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Eric Anholt <eric@anholt.net>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466501283-19976-3-git-send-email-chris@chris-wilson.co.uk

drm/atmel-hlcdc: Remove redundant call to drm_connector_unregister_all()

drm_connector_unregister_all() is not automatically called by
drm_dev_unregister() so we can drop the local call.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466501283-19976-2-git-send-email-chris@chris-wilson.co.uk

drm: document drm_auth.c

Also extract drm_auth.h for nicer grouping.

v2: Nuke the other comments since they don't really explain a lot, and
within the drm core we generally only document functions exported to
drivers: The main audience for these docs are driver writers.

v3: Limit the exposure of drm_master internals by only including
drm_auth.h where it is neede (Chris).

v4: Spelling polish (Emil).

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm: Clear up master tracking booleans

- is_master can be removed, we can compute this by checking allowed_master
  (which really just tracks whether a master struct has been allocated
  for this fpriv in either open or set_master), and whether the fpriv is
  the current master on the device.

- that frees up is_master as a good replacement name for allowed_master.
  With that it's clear that it tracks whether the fpriv is a master (with
  possibly clients attached to it and authenticated against it), and that
  one of those fprivs with is_master set is the current master.

v2: Fix kerneldoc for is_master (Emil).

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-10-git-send-email-daniel.vetter@ffwll.ch

drm: Extract drm_is_current_master

Just rolling out a bit of abstraction to be able to clean
up the master logic in the next step.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Refactor drop/set master code a bit

File open/set_maseter ioctl and file close/drop_master ioctl share the
same master handling code. Extract it.

Note that vmwgfx's master_set callback needs to know whether the
master is a new one or has been used already, so thread this through.
On the close/drop side a similar parameter existed, but wasnt used.
Drop it to simplify the flow.

v2: Try to make it not leak so much (Emil).

v3: Send out the right version ...

Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466511638-9885-1-git-send-email-daniel.vetter@ffwll.ch

drm: Lobotomize set_busid nonsense for !pci drivers

We already have a fallback in place to fill out the unique from
dev->unique, which is set to something reasonable in drm_dev_alloc.

Which means we only need to have a special set_busid for pci devices,
to be able to care the backwards compat code for drm 1.1 around, which
libdrm still needs.

While developing and testing this patch things blew up in really
interesting ways, and the code is rather confusing in naming things
between the kernel code, ioctl #defines and libdrm. For the next brave
dragon slayer, document all this madness properly in the userspace
interface section of gpu.tmpl.

v2: Make drm_dev_set_unique static and update kerneldoc.

v3: Entire rewrite, plus document what's going on for posterity in the
gpu docbook uapi section.

v4: Drop accidental amdgpu hunk (Emil).

v5: Drop accidental omapdrm vblank counter change (Emil).

v6: Rebase on top of the sphinx conversion.

Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> (virt_gpu)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm: Nuke SET_UNIQUE ioctl

Ever since

commit 2e1868b560315a8b20d688e646c489a5ad93eeae
Author: Eric Anholt <anholt@freebsd.org>
Date:   Wed Jun 16 09:25:21 2004 +0000

    DRI trunk-20040613 import

the X server supports drm 1.1, thus doesn't call call libdrm's
drmSetBusid - the sole user of this ioctl. When reviewing this note
that for hilarity both the kernel-internal functions (set_busid) and
the libdrm wrapper (drmSetBusid) have names not matching this ioctl
(SET_UNIQUE).

v2: Polish commit message (Emil).

Cc: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-6-git-send-email-daniel.vetter@ffwll.ch

drm: Don't call drm_dev_set_unique from platform drivers

Since

commit e112e593b215c394c0303dbf0534db0928e87967
Author: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Date:   Fri Dec 11 11:20:28 2015 +0100

    drm: use dev_name as default unique name in drm_dev_alloc()

we're using a reasonable default which should work for everyone. Only
mtk, rcar-du and sun4i are affected, and as kms-only drivers without
any rendering support no one should ever care about the unique name

v2: Rebase on top of mediatek.

Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-5-git-send-email-daniel.vetter@ffwll.ch

drm/vgem: Stop calling drm_drv_set_unique

With the previous patch this is now redudant, the core always
sets a reasonable dev->unique string.

Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-4-git-send-email-daniel.vetter@ffwll.ch

drm: Use dev->name as fallback for dev->unique

Lots of arm drivers get this wrong and for most arm boards this is the
right thing actually. And anyway with most loaders you want to chase
sysfs links anyway to figure out which dri device you want.

This will fix dmesg noise for rockchip and sti.

Also add a fallback to driver->name for entirely virtual drivers like
vgem.

v2: Rebase on top of

commit e112e593b215c394c0303dbf0534db0928e87967
Author: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Date:   Fri Dec 11 11:20:28 2015 +0100

    drm: use dev_name as default unique name in drm_dev_alloc()

and simplify a bit. Plus add a comment.

v3: WARN_ON(!dev->unique) as discussed with Emil.

Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-3-git-send-email-daniel.vetter@ffwll.ch

drm: Clean up drm_crtc.h

- Group declarations for separate files (drm_bridge.c, drm_edid.c)
- Move declarations only used within drm.ko to drm_crtc_internal.h
- drm_property_type_valid to drm_crtc.c, its only callsite

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-2-git-send-email-daniel.vetter@ffwll.ch

drm: Move master pointer from drm_minor to drm_device

There can only be one current master, and it's for the overall device.
Render/control minors don't support master-based auth at all.

This simplifies the master logic a lot, at least in my eyes: All these
additional pointer chases are just confusing.

While doing the conversion I spotted some locking fail:
- drm_lock/drm_auth check dev->master without holding the
  master_mutex. This is fallout from

  commit c996fd0b956450563454e7ccc97a82ca31f9d043
  Author: Thomas Hellstrom <thellstrom@vmware.com>
  Date:   Tue Feb 25 19:57:44 2014 +0100

      drm: Protect the master management with a drm_device::master_mutex v3

  but I honestly don't care one bit about those old legacy drivers
  using this.

- debugfs name info should just grab master_mutex.

- And the fbdev helper looked at it to figure out whether someone is
  using KMS. We just need a consistent value, so READ_ONCE. Aside: We
  should probably check if anyone has opened a control node too, but I
  guess current userspace doesn't really do that yet.

v2: Balance locking, reported by Julia.

v3: Rebase on top of Chris' oops fixes.

Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-1-git-send-email-daniel.vetter@ffwll.ch

drm: sti: rework init sequence

Use drm_dev_alloc() and drm_dev_register() instead of .load()
To simplify init sequence only create fbdev when requested
in output_poll_changed().

version 2:
remove call to drm_connector_unregister_all() and
drm_dev_set_unique()

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466514580-15194-4-git-send-email-benjamin.gaignard@linaro.org

drm: sti: use late_register and early_unregister callbacks

Make sti driver use register callback to move debugfs
initialization out of sub-components creation.
This will allow to convert driver .load() to
drm_dev_alloc() and drm_dev_register().

sti_compositor bring up 2 crtc but only one debugfs init is
needed so use drm_crtc_index to do it on the first one.
This can't be done in sti_drv because only sti_compositor have
access to the devices.
It is almost the same for sti_encoder which handle multiple
encoder while one only debugfs entry is needed so add a boolean
to avoid multiple debugfs initialization

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466514580-15194-3-git-send-email-benjamin.gaignard@linaro.org

drm/amdkfd: Clean up inline handling

- inline functions need to be static inline, otherwise gcc can opt to
  not inline and the linker gets unhappy.
- no forward decls for inline functions, just include the right headers.

Cc: Oded Gabbay <oded.gabbay@gmail.com>
Cc: Ben Goz <ben.goz@amd.com>
Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466500235-21282-2-git-send-email-daniel.vetter@ffwll.ch

drm: Add callbacks for late registering

Like what has been done for connectors add callbacks on encoder,
crtc and plane to let driver do actions after drm device registration.

Correspondingly, add callbacks called before unregister drm device.

version 2:
add drm_modeset_register_all() and drm_modeset_unregister_all()
to centralize all calls

version 3:
in error case unwind registers in drm_modeset_register_all
fix uninitialed return value
inverse order of unregistration in drm_modeset_unregister_all

version 4:
move function definitions in drm_crtc_internal.h
remove not needed documentation

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466519829-4000-1-git-send-email-benjamin.gaignard@linaro.org

drm/i915/guc: Remove one unnecessary variable

No need for local struct drm_device * since dev_priv is the
correct thing to pass in to NEEDS_WaRsDisableCoarsePowerGating
anyway. Changed the macro definition for the latter to reflect
that as well.

v2: Alignment bikeshed.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466518034-24838-1-git-send-email-tvrtko.ursulin@linux.intel.com

drm/fsl-dcu: use drm_mode_config_cleanup on initialization errors

Commit 7566e247672d ("drm/fsl-dcu: handle initialization errors properly")
introduced error handling during initialization, but with a wrong cleanup
order.

Replace the error handling with the generic cleanup function
drm_mode_config_cleanup.

Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160619021543.23587-1-stefan@agner.ch

drm/mediatek: Remove IOMMU_DMA select

We get a harmless build warning when trying to use the mediatek DRM
driver with IOMMU support disabled:

warning: (DRM_MEDIATEK) selects IOMMU_DMA which has unmet direct dependencies (IOMMU_SUPPORT)

However, the IOMMU_DMA symbol is not meant to be used by drivers at all,
and this driver doesn't seem to have a strict dependency on it other
than using the mediatek IOMMU driver that does.

Since we also want to be able to do compile tests with the driver on
other platforms, the IOMMU_DMA symbol should not be selected here.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1462997501-982363-1-git-send-email-arnd@arndb.de

Documentation/DocBook: remove gpu.tmpl

The gpu documentation has now been converted to reStructuredText files
under Documentation/gpu. Remove the obsolete DocBook template. Also
remove it from MAINTAINERS.

Good riddance.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/8d673f75fe686371ed9838682c368a4e3b96bf54.1466506505.git.jani.nikula@intel.com

Documentation/gpu: split up mm, kms and kms-helpers from internals

Make the documents more manageable.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/be992e56eb8442d6e03b52444df5a42525085718.1466506505.git.jani.nikula@intel.com

Documentation/gpu: convert the KMS properties table to CSV

Pandoc really did a bad job of converting the big KMS properties table
to RST. Instead, put the properties into a separate plain text CSV file,
and include it in the RST file. The generated output isn't very pretty,
but at least the information is there, and it's stored in a format
that's easier to process and improve upon at a later time.

The CSV file was generated by copy-pasting the table from the HTML
generated by the DocBook toolchain into LibreOffice Calc, and then saved
as CSV, unmodified.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/17053ff08caf5cfac4f478437ef796f83a31d772.1466506505.git.jani.nikula@intel.com

Documentation/gpu: use recommended order of heading markers

While splitting the document up, the headings "shifted" from what pandoc
generated. Use the following order for headings for consistency:

==============
Document title
==============

First
=====

Second
------

Third
~~~~~

Leave the lower level headings as they are; I think those are less
important. Although RST doesn't mandate a specific order ("Rather than
imposing a fixed number and order of section title adornment styles, the
order enforced will be the order as encountered."), having the higher
levels the same overall makes it easier to follow the documents.

[I'm sort of kind of writing the recommendation for docs-next in the
mean time, but this order seems sensible, and is what I'm proposing.]

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/126f42734defac6cbb8496a481d58db7b38461dd.1466506505.git.jani.nikula@intel.com

MAINTAINERS: add Documentation/gpu and Documentation/gpu/i915.rst

We'll want to keep an eye on what's going on in these files.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/4d409e09c475cc0bdf7a0312e30c0d3f8d535fc5.1466506505.git.jani.nikula@intel.com

Documentation/gpu: split up the gpu documentation

Make the gpu documentation easier to manage by splitting to separate
files. Again, this is just the split, no real edits.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/bd2b599b5105c28c8f05923005e6cc9b7efa7fc1.1466506505.git.jani.nikula@intel.com

Documentation/gpu: add new gpu.rst converted from DocBook gpu.tmpl

This is the first step towards converting the DocBook gpu.tmpl to Sphinx
and reStructuredText, the new kernel documentation tool and markup.

Use Jon's "cheesy conversion script" in Documentation/sphinx/tmplcvt to
do the rough conversion. Do the manual edits in follow-up patches. Add a
new Documentation/gpu directories for the graphics related
documentation. (Hooray, now we can have directories based on topics
rather than tools under Documentation.)

We also won't remove the DocBook gpu.tmpl yet so it's easier to build
both and compare the results for parity.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/bc7b4f9ac037632e0c8469c079d21fad5eaa39a0.1466506505.git.jani.nikula@intel.com

drm/i915: Use connector_type for printing in intel_connector_info, v2.

Instead of looking at encoder->type, which may be set to UNKNOWN,
use connector->connector_type. Info cannot be printed for MST
connectors which may have a NULL encoder, return early in that case.

Changes since v1:
- Whitelist encoder types for HDMI and LVDS.
- Fix oops on MST.
- Do not list encoder types for eDP/DP, they're always valid.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/7cf34026-392d-01ec-e79b-e91919d1d783@linux.intel.com

drm/i915: Use atomic state and connector_type in i915_sink_src

DPMS is unreliable, use crtc->state.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466431059-8919-4-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Use connector_type instead of intel_encoder->type for DP.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466431059-8919-3-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Use connector->name in drrs debugfs.

This removes relying on intel_encoder->type, which may be set to
unknown.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466431059-8919-2-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915/gvt: Mark i915.enable_gvt as false if loading fails

If we update the value of i915.enable_gvt should we fail to load GVT,
userspace can easily detect when it fails to load as requested.

Testcase: igt/gvt_basic
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466507234-23242-1-git-send-email-chris@chris-wilson.co.uk

drm/i915: Set the access right of kernel param "i915.enable_gvt" to read-only.

The access right of kernel param "i915.enable_gvt" should be read-only as
it only applies during module load (and is not *runtime* writable).

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1466425022-3709-1-git-send-email-zhi.a.wang@intel.com

drm/i915: Set softmin frequency on idle->busy transition

If the GPU load is low enough, it's possible that we'll be stuck at idle
frequency rather than transition into softmin frequency requested by
userspace.

v2: Use intel_set_rps, drop vlv_set_idle
v3: Back to vlv_set_idle, clamp to valid range
v4: Place intel_set_rps at the end

References: https://bugs.freedesktop.org/show_bug.cgi?id=89728
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1466416707-12075-1-git-send-email-michal.winiarski@intel.com

drm/i915/guc: index host arrays by i915 engine ID, not guc_id

The ONLY places that guc_id (aka hw_id) should be used are those where
the value or address is determined by and shared with the GuC firmware;
specifically, when filling in the GuC-context-descriptor or the GuC
addon data, or putting an entry in the GuC's work queue.

It need not (and therefore should not) be used to index GuC statistics
or similar host-managed tracking data. In particular, i915_guc_submit()
produces (and debugfs decodes) GuC submission statistics which should be
indexed by driver-engine-id rather then guc-engine-id.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466432287-5799-1-git-send-email-david.s.gordon@intel.com

drm/crtc-helper: disable_unused_functions really isn't for atomic

Rockchip just blew up here on testing, because I removed some "is this
crtc already disabled/enabled" state tracking from callbacks (not needed
with atomic). Turns out that was needed to work around rockchip still
calling legacy helper code.

Since me explaining on irc/mailing-list plus kerneldoc isn't enough,
be more verbose and add dmesg output. Not that anyone actually reads that,
either.

Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-26-git-send-email-daniel.vetter@ffwll.ch

drm/rcar-du: Remove redundant calls to drm_connector_register_all()

Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility issues with drivers not following the
more rigorous init ordering.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Tested-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466151923-1572-8-git-send-email-chris@chris-wilson.co.uk

drm/msm: Remove redundant calls to drm_connector_register_all()

Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility issues with drivers not following the
more rigorous init ordering.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rob Clark <robdclark@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Tested-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466151923-1572-7-git-send-email-chris@chris-wilson.co.uk

drm/mediatek: Remove redundant calls to drm_connector_register_all()

Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility issues with drivers not following the
more rigorous init ordering.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466151923-1572-6-git-send-email-chris@chris-wilson.co.uk

drm/hisilicon: Remove redundant calls to drm_connector_register_all()

Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility issues with drivers not following the
more rigorous init ordering.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Xinliang Liu <z.liuxinliang@hisilicon.com>
Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Chen Feng <puck.chen@hisilicon.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Acked-by: Xinliang Liu <z.liuxinliang@hisilicon.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466151923-1572-5-git-send-email-chris@chris-wilson.co.uk

drm/atmel-hlcdc: Remove redundant calls to drm_connector_register_all()

Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility issues with drivers not following the
more rigorous init ordering.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466151923-1572-4-git-send-email-chris@chris-wilson.co.uk

drm/arc: Remove redundant calls to drm_connector_register_all()

Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility issues with drivers not following the
more rigorous init ordering.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466151923-1572-3-git-send-email-chris@chris-wilson.co.uk

drm/rockchip: Finish initialization before registering DRM device

Currently the driver calls drm_dev_register() directly after allocating
the DRM device and then continues with further initialization. This is
incorrect, because drm_dev_register() is supposed to be called after all
initialization is done. This problem was masked by the fact that
drm_dev_register() did not use to do anything special before, but
recently it started to call drm_connector_register_all(), which leads to
a crash if the driver is not fully initialized.

This patch fixes the problem by moving the call to drm_dev_register() to
the end of the initialization sequence and also removing the, now
unnecessary, call to drm_connector_register_all() from driver code.

Fixes: f706974a69b6 ("drm/rockchip: Drop drm_driver.load/unload callbacks")
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
[danvet: Fix up cleanup labels a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466483254-35373-1-git-send-email-tfiga@chromium.org

drm/i915/fbdev: Flush mode configuration before lastclose

During lastclose, we call intel_fbdev_restore_mode() to switch back to
the fbcon configuration on return to VT. However, if we have not yet
finished the asynchronous fbdev initialisation, the current mode will be
invalid and trigger WARNs upon application.

Serialise with the outstanding initialisation if the first application
exits quickly. Note that to hit this in practice requires using an
unregistered async_domain as otherwise modprobe will force a full
synchronisation prior to init() completing.

v2: Reuse comment explaining the +1 by refactoring the wait on fbdev
sync in the previous patch.

Reported-by: Gustav Fägerlind <gustav.fagerlind@gmail.com>
Reported-by: "Li, Weinan Z" <weinan.z.li@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466497015-8509-3-git-send-email-chris@chris-wilson.co.uk

drm/i915/fbdev: Limit the global async-domain synchronization

During cleanup we have to synchronise with the async task we are using
to initialise and register our fbdev. Currently, we are using a full
synchronisation on the global domain, but we can restrict this to just
synchronising up to our task if we remember our cookie.

Whilst there, streamline the function parameters.

v2: async_synchronize_cookie() takes an exclusive upper bound, to
synchronize with our task we have to pass in the next cookie.
v3: Drop premature disregarding of the active cookie (we need to wait
until the task is complete before continuing in the teardown).
v4: Refactor waiting on async to incorporate a comment explaining why we
need the +1.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466497015-8509-2-git-send-email-chris@chris-wilson.co.uk

drm/i915/fbdev: Perform async fbdev initialisation much later

Setting up fbdev requires everything ready and registered (in particular
the connectors). In the forthcoming patches, we defer registration of the KMS
objects and unless we defer setting off fbdev, it may run before they are
registered and oops.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466497015-8509-1-git-send-email-chris@chris-wilson.co.uk

drm/omapdrm: don't call drm_helper_disable_unused_functions

It's a legacy helper function which won't do good with atomic helpers.

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1465510479-21180-1-git-send-email-daniel.vetter@ffwll.ch

drm/i915: use ORIGIN_CPU for frontbuffer invalidation on WC mmaps

... instead of the previous ORIGIN_GTT. This should actually
invalidate FBC once something is written on the frontbuffer using WC
mmaps. The problem with ORIGIN_GTT is that the automatic hardware
tracking is not able to detect the WC writes as it can detect the GTT
writes.

This should help fix the SKL bug where nothing happens when you type
your username/password on lightdm.

This patch was originally pasted on an email by Chris and converted to
an actual git patch by Paulo.

v2 (from Paulo):
 - Make it a full variable instead of a bit-field (Daniel)
 - Use WRITE_ONCE (Chris)
v3 (from Paulo):
 - Remove huge comment since now we have WRITE_ONCE (Chris)
 - Remove uneeded new line (Chris)
 - Add Chris' Signed-off-by, authorized via IRC

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466185599-26401-1-git-send-email-paulo.r.zanoni@intel.com

drm/i915/fbc: sanitize i915.enable_fbc during FBC init

The DDX driver changes its behavior depending on the value it reads
from i915.enable_fbc, so sanitize the value in order to allow it to
know what's going on. It uses this in order to choose the defaults for
the TearFree option. Before this patch, it would read -1 and always
assume that FBC was disabled, so it wouldn't force TearFree.

v2: Extract intel_sanitize_fbc_option() (Chris).
v3: Rebase.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460574069-14005-1-git-send-email-paulo.r.zanoni@intel.com

drm/i915/fbc: update busy_bits even for GTT and flip flushes

We ignore ORIGIN_GTT because the hardware tracking can recognize GTT
writes and take care of them. We also ignore ORIGIN_FLIP because we
deal with flips without relying on the frontbuffer tracking
infrastructure. On the other hand, a flush is a flush and means we're
good to go, so we need to update busy_bits in order to reflect that,
even if we're not going to do anything else about it.

How to reproduce the bug fixed by this patch:
 - boot SKL up to the desktop environment
 - stop the display manager
 - run any of the igt/kms_frontbuffer_tracking/*fbc*onoff* subtests
 - the tests will fail

The steps above will create the right conditions for us to lose track
of busy_bits. If you, for example, run the full set of FBC tests, the
onoff subtests will succeed.

Also notice that the "bug" is that we'll just keep FBC disabled on
cases where it could be enabled, so it's not something the users can
perceive, it just affects power consumption numbers on properly
configured machines.

Testcase: igt/kms_frontbuffer_tracking/*fbc*onoff* (see above)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459804638-3588-2-git-send-email-paulo.r.zanoni@intel.com

drm/i915/fbc: Disable on HSW by default for now

>From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :

This was kind of a difficult bug to track down. If you're using a
Haswell system running GNOME and you have fbc completely enabled and
working, playing videos can result in video artifacts. Steps to
reproduce:

- Run GNOME
- Ensure FBC is enabled and active
- Download a movie, I used the ogg version of Big Buck Bunny for this
- Run `gst-launch-1.0 filesrc location='some_movie.ogg' ! decodebin !
  glimagesink` in a terminal
- Watch for about over a minute, you'll see small horizontal lines go
  down the screen.

For the time being, disable FBC for Haswell by default.

Stefan Richter reported kernel freezes (no video artifacts) when fbc
is on.  (E3-1245 v3 with HD P4600; openbox and some KDE and LXDE
applications, thread begins at https://lkml.org/lkml/2016/4/26/813).
We also got reports from Steven Honeyman on openbox+roxterm.

v2 (From Paulo):
  - Add extra information to the commit message
  - Add Fixes tag
  - Rebase

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96461
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96464
Fixes: a98ee79317b4 ("drm/i915/fbc: enable FBC by default on HSW and BDW")
Cc: stable@vger.kernel.org
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Lyude <cpaul@redhat.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1465487895-7401-1-git-send-email-cpaul@redhat.com

drm: Mark set/drop master ioctl as unlocked.

Again this is neatly protected by the dev->master_mutex now. There is
a driver callback both for set and drop, but it's only used by vmwgfx.
And vmwgfx has it's own solid locking for shared resources (besides
dev->master_mutex), hence is all safe. Let's drop another place where
the drm legacy bkl is used.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-6-git-send-email-daniel.vetter@ffwll.ch

drm: Mark authmagic ioctls as unlocked

All protected by dev->master_mutex. And there's no driver callbacks,
which means no need to sync with old dri1 horror show drivers at all.
Hence safe to drop the drm legacy BKL from these paths.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-5-git-send-email-daniel.vetter@ffwll.ch

drm: Protect authmagic with master_mutex

Simplifies cleanup, and there's no reason drivers should ever care
about authmagic at all - it's all handled in the core.

And with that, Ladies and Gentlemen, it's time to pop the champagen
and celebrate: dev->struct_mutex is now officially gone from modern
drivers, and if a driver is using gem_free_object_unlocked and doesn't
do anything else silly it's positively impossible to ever touch
dev->struct_mutex at runtime, anywhere.

Well except for the mutex_init on driver load ;-)

v2: Rebased.

Cc: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-4-git-send-email-daniel.vetter@ffwll.ch

drm: Move authmagic cleanup into drm_master_release

It's related, and soon authmagic will also use the master_mutex.

There is an ever-so-slightly semantic change here:
- authmagic will only be cleaned up for primary_client drm_minors. But
  it's impossible to create authmagic on render/control nodes, so this
  is fine.
- The cleanup is moved down a bit in the release processing. Doesn't
  matter at all since authmagic is purely internal logic used by the
  core ioctl access checks, and when we're in a file's release
  callback no one can do ioctls any more.

v2: Rebased.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-3-git-send-email-daniel.vetter@ffwll.ch

drm: Only do the hw.lock cleanup in master_relase for !MODESET

Another place gone where modern drivers could have hit
dev->struct_mutex.

To avoid too deeply nesting control flow rework it a bit.

v2: Review from Chris:
- remove spurious newline.
- fix file_priv->master like for the !file_priv->is_master case.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-2-git-send-email-daniel.vetter@ffwll.ch

drm: rcar-du: error message is not needed for EPROBE_DEFER

EPROBE_DEFER is not error, thus, error message on kernel log on this
case is confusable. Print it only error cases

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm: rcar-du: error message is not needed for drm_vblank_init()

The only reason drm_vblank_init() could return an error at the
moment is a kcalloc() failure.
So we can remove current error message completely.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

rcar-du: add/rename DEFR6 TCON bits

The  TCNE2 bit  of the DEFR6 register was renamed to TCNE1 in the R-Car gen2
manuals -- which makes more  sense as that bit controls whether DU1, not DU2
is connected to TCON.

While at it, add the TCNE0 bit which controls whether DU0 is connected to
TCON.

Based on the large patch by Andrey Gusakov <andrey.gusakov@cogentembedded.com>.

Signed-off-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm: Prevent NULL deref in drm_name_info()

If a driver does not have a parent, or never sets the unique name for
itself, then we may proceed to chase a NULL dereference through
debugfs/.../name.

Testcase: igt/vgem_basic/debugfs
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466448813-23340-1-git-send-email-chris@chris-wilson.co.uk

drm: fix send_vblank_event use-after-free error

The drm_pending_event can be freed by drm_send_event_locked, as a
result we should call trace_drm_vblank_event_delivered before this
to avoid hitting a user-after-free error when accessing the pid member:

[  378.438497] BUG: KASAN: use-after-free in send_vblank_event+0xf0/0x310 [drm] at addr ffff8801ac7e50a0
[  378.438500] Read of size 4 by task Xorg/1562
[  378.438501] =============================================================================
[  378.438504] BUG kmalloc-128 (Tainted: G    B          ): kasan: bad access detected
[  378.438506] -----------------------------------------------------------------------------

[  378.438509] INFO: Freed in 0x10001309c age=18446737369265680575 cpu=0 pid=0
[  378.438541]  drm_send_event_locked+0x207/0x2f0 [drm]
[  378.438544]  __slab_free+0x24c/0x650
[  378.438546]  kfree+0x3a2/0x760
[  378.438578]  drm_send_event_locked+0x207/0x2f0 [drm]
[  378.438610]  send_vblank_event+0xb7/0x310 [drm]
[  378.438643]  drm_crtc_send_vblank_event+0x130/0x1f0 [drm]
[  378.438722]  intel_atomic_commit_tail+0x23b5/0x53f0 [i915]
[  378.438802]  intel_atomic_commit+0xbae/0x12f0 [i915]
[  378.438839]  drm_atomic_commit+0xb0/0x120 [drm]
[  378.438855]  drm_atomic_helper_connector_dpms+0x339/0x5d0 [drm_kms_helper]
[  378.438891]  drm_mode_obj_set_property_ioctl+0x8f1/0xcc0 [drm]
[  378.438927]  drm_mode_connector_property_set_ioctl+0xf3/0x170 [drm]
[  378.438959]  drm_ioctl+0x2d7/0xae0 [drm]
[  378.438962]  do_vfs_ioctl+0x1c9/0x1280
[  378.438964]  SyS_ioctl+0x79/0x90
[  378.438967]  entry_SYSCALL_64_fastpath+0x1a/0xa4

Cc: dri-devel@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466440966-5410-1-git-send-email-matthew.auld@intel.com

dma-buf: remove dma_buf_debugfs_create_file()

There is only a single user of dma_buf_debugfs_create_file() and that
one got the function pointer cast wrong. With that one fixed, there is
no need to have a wrapper for debugfs_create_file(), just call it
directly.

With no users left, we can remove dma_buf_debugfs_create_file().

While at it, simplify the error handling in dma_buf_init_debugfs()
slightly.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1466339491-12639-2-git-send-email-minipli@googlemail.com

dma-buf: remove dma_buf directory on bufinfo file creation errors

Change the error handling in dma_buf_init_debugfs() to remove the
"dma_buf" directory if creating the "bufinfo" file fails. No need to
have an empty debugfs directory around.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>

dma-buf: propagate errors from dma_buf_describe() on debugfs read

The callback function dma_buf_describe() returns an int not void so the
function pointer cast in dma_buf_show() is wrong. dma_buf_describe() can
also fail when acquiring the mutex gets interrupted so always returning
0 in dma_buf_show() is wrong, too.

Fix both issues by avoiding the indirection via dma_buf_show() and call
dma_buf_describe() directly. Rename it to dma_buf_debug_show() to get it
in line with the other functions.

This type mismatch was caught by the PaX RAP plugin.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Brad Spengler <spender@grsecurity.net>
Cc: PaX Team <pageexec@freemail.hu>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>

drm/i915: pwrite/pread do not require obj->base.filp, just pages

The idea behind relaxing the restriction for pread/pwrite was to handle
!obj->base.flip, i.e. non-shmemfs backed objects, which only requires
that the object provide struct pages.

v2: Remove excess (). Note enough editing after copy'n'paste.
v3: Use new i915_gem_object_has_struct_page()

Testcase: igt/prime_vgem/read
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466431552-17860-2-git-send-email-chris@chris-wilson.co.uk

drm/i915: Extract checking for backing struct pages to a helper

Currently to see if an object is backed by struct pages (as opposed to
being a simple pointer to stolen memory, for example) we do a manual
check on the obj->ops->flags. This is quite shouty and before adding
more checks in future, we should make it a bit calmer.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466431552-17860-1-git-send-email-chris@chris-wilson.co.uk

drm/bridge: Add sii902x DT bindings doc

Add Sii9022 DT bindings description.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes since v6:
- make 'reset-gpios' optional

Changes since v1:
- rename doc file
- s/sil902/sii902/

drm/bridge: Add sii902x driver

Add basic support for the sii902x RGB -> HDMI bridge.
This driver does not support audio output yet.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
---
Changes in v8:
- remove useless headers inclusion
- fix macro names (s/SIL/SII)
- drop unneeded hotplug_work field from struct sii902x
- drop drm_connector_unregister() call in the ->destroy() method
- add a timeout when polling a register value

Changes in v6:
- use HDMI_INFOFRAME_SIZE(AVI)
- fix reset_gpio initialization
- reduce the reset time based on Ming feedback

Changes in v5:
- drop the best_encoder() implementation

Changes in v4:
- make reset GPIO optional
- only support attaching to DRM devices supporting atomic updates

Changes in v3:
- fix get_modes() implementation to avoid turning the screen in power
  save mode
- rename the driver (sil902x -> sii902x)

Changes in v2:
- fix errors reported by the kbuild robot

fixup! drm: bridge: Add sii902x driver

drm/i915: Avoid use-after-free of intel_encoder in intel_dp_connector_destrpy

The drm_dp_aux is associated with the intel_dp encoder and not the
connector. Since the encoder is destroyed before the connector,
attempting to free the drm_dp_aux from inside the connector cleanup
causes a use-after-free.

This was applied to the patch that CI was happy with, but in the
confusion of so many series trying to make CI happy, the unready
patch was plucked.

Fixes: c191eca110a3 ("drm/i915: Move intel_connector->unregister to connector->early_unregister")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466411357-730-1-git-send-email-chris@chris-wilson.co.uk

drm/i915: Revert DisplayPort fast link training feature

It has been found out that in some HW combination the DisplayPort
fast link training feature caused screen flickering. Let's revert
this feature for now until we can ensure that the feature works for
all platforms.

This is a manual revert of commits 5fa836a9d859 ("drm/i915: DP link
training optimization") and 4e96c97742f4 ("drm/i915: eDP link training
optimization").

Fixes: 5fa836a9d859 ("drm/i915: DP link training optimization")
Fixes: 4e96c97742f4 ("drm/i915: eDP link training optimization")
Cc: <stable@vger.kernel.org> # v4.2+
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466410226-19543-1-git-send-email-mika.kahola@intel.com

drm/i915: Update DRIVER_DATE to 20160620

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

drm/i915: Move backlight unregistration to connector unregistration

Currently the backlight is being unregistered in the unload phase (after
the display and its objects are unregistered). Move the backlight
unregistration into the analogous phase by performing it from the
connector unregistration, just prior to its deletion.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466160034-12173-3-git-send-email-chris@chris-wilson.co.uk

drm/i915: Move intel_connector->unregister to connector->early_unregister

We now have a connector->func that serves the same purpose as our own
intel_connector->unregister vfunc allowing us to unwrap ourselves and
use drm_connector_register() (and friends) as the central function.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466160034-12173-2-git-send-email-chris@chris-wilson.co.uk

drm: Protect drm_connector_register_all() under DRIVER_MODESET

0-day kbuilder found

[    1.360244] BUG: unable to handle kernel NULL pointer dereference at   (null)
[    1.360972] IP: [<c14db9ad>] mutex_lock_nested+0x11f/0x2c3
[    1.361512] *pde = 00000000
[    1.361827] Oops: 0002 [#1]
[    1.362123] Modules linked in:
[    1.362451] CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.0-rc2-00564-ge28cd4d #1
[    1.363202] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[    1.364105] task: c03d0000 ti: d28da000 task.ti: d28da000
[    1.364636] EIP: 0060:[<c14db9ad>] EFLAGS: 00210096 CPU: 0
[    1.365215] EIP is at mutex_lock_nested+0x11f/0x2c3
[    1.365703] EAX: 00000000 EBX: d39e8ae8 ECX: d39e8b14 EDX: c1361cf9
[    1.366351] ESI: c03d0000 EDI: d28dbed0 EBP: d28dbeec ESP: d28dbec0
[    1.367010]  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[    1.367534] CR0: 80050033 CR2: 00000000 CR3: 019a9000 CR4: 00000690
[    1.368152] Stack:
[    1.368356]  d39e8b14 d39e8b24 c1361cf9 00200246 d39e8b14 00000000 11111111 d28dbed0
[    1.369235]  d39e8800 d39e8ae8 00000000 d28dbf08 c1361cf9 d28dbf0c c10b25be d39e8800
[    1.370087]  00000000 00000000 d28dbf1c c135e37d fffffff4 ffffffff 00000000 d28dbf28
[    1.371012] Call Trace:
[    1.371272]  [<c1361cf9>] ? drm_connector_register_all+0x1a/0x92
[    1.371847]  [<c1361cf9>] drm_connector_register_all+0x1a/0x92
[    1.372421]  [<c10b25be>] ? kstrdup+0x25/0x3a
[    1.372863]  [<c135e37d>] drm_dev_register+0x59/0x99
[    1.373358]  [<c195ea3e>] vgem_init+0x34/0x49
[    1.373770]  [<c195ea0a>] ? mipi_dsi_bus_init+0xf/0xf
[    1.374257]  [<c100048f>] do_one_initcall+0x7c/0xfd
[    1.374754]  [<c104b409>] ? parse_args+0x1fd/0x314
[    1.375259]  [<c1939c10>] ? kernel_init_freeable+0xd0/0x179
[    1.375837]  [<c1939c2c>] kernel_init_freeable+0xec/0x179
[    1.376371]  [<c14d66ea>] kernel_init+0x8/0xcb
[    1.376806]  [<c14debce>] ret_from_kernel_thread+0xe/0x30
[    1.377322]  [<c14d66e2>] ? rest_init+0x10e/0x10e
[    1.377754] Code: 89 fa e8 71 c5 b7 ff 8b 4e 04 89 fa 89 d8 e8 8e c6 b7 ff 8d 43 2c 89 45 d4 8b 43 30 8d 4b 2c 89 45 e8 89 7b 30 89 4d e4 8b 55 dc <89> 38 8d 43 3c 89 75 ec e8 c9 dd b7 ff eb 0c 31 c0 87 03 48
+75
[    1.380442] EIP: [<c14db9ad>] mutex_lock_nested+0x11f/0x2c3 SS:ESP 0068:d28dbec0
[    1.381174] CR2: 0000000000000000

when loading the non-modesetting vGEM module. To prevent use of the
uninitialised dev->mode_config from drm_dev_register() we move the
drm_connector_register_all() under a DRIVER_MODESET guard. Longer term,
we probably want to initialise the embedded dev->mode_config automatically
from drm_dev_init() for all DRIVER_MODESET drivers.

v2: Also protect drm_dev_unregister.

Fixes: e28cd4d0a223 ("drm: Automatically register/unregister all connectors")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Testcase: igt/vgem_reload_basic
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466257601-5656-1-git-send-email-chris@chris-wilson.co.uk

drm/i915: Introduce GVT context creation API

GVT workload scheduler needs special host LRC contexts, the so called
"shadow LRC context" to submit guest workload to host i915. During the
guest workload submission, workload scheduler fills the shadow LRC
context with the content of guest LRC context: engine context is copied
without changes, ring context is mostly owned by host i915.

v8:

- Remove the graph temporarily. (Chris)
- Use interruptible mutex_lock. (Chris)
- Rename the function name of creating a GVT context. (Chris)
- Add the missing declaration in i915_drv.h (Chris)

v7:

- Move chart to a better place. (Joonas)

v6:

- Make GVT code as dead code when !CONFIG_DRM_I915_GVT. (Chris)

v5:
- Only compile this feature when CONFIG_DRM_I915_GVT is enabled. (Tvrtko)
- Rebase the code into new repo.
- Add a comment about the ring buffer size. (Joonas)

v2:

Mostly based on Daniel's idea. Call the refactored core logic of GEM
context creation service and LRC context creation service to create the GVT
context.

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1466078825-6662-10-git-send-email-zhi.a.wang@intel.com

drm/i915: Support LRC context single submission

This patch introduces the support of LRC context single submission.
As GVT context may come from different guests, which require different
configuration of render registers. It can't be combined into a dual ELSP
submission combo.

Only GVT-g will create this kinds of GEM context currently.

v8:

- Rename the data member in struct i915_gem_context. (Chris)

v7:

- Fix typos in commit message. (Joonas)

v6:
- Make GVT code as dead code when !CONFIG_DRM_I915_GVT. (Chris)

v5:

- Only compile this feature when CONFIG_DRM_I915_GVT=y. (Tvrtko)

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1466078825-6662-9-git-send-email-zhi.a.wang@intel.com

drm/i915: Introduce execlist context status change notification

This patch introduces an approach to track the execlist context status
change.

GVT-g uses GVT context as the "shadow context". The content inside GVT
context will be copied back to guest after the context is idle. And GVT-g
has to know the status of the execlist context.

This function is configurable when creating a new GEM context. Currently,
Only GVT-g will create the "status-change-notification" enabled GEM
context.

v10:

- Fix the identation. (Joonas)

v8:

- Remove the boolean flag in struct i915_gem_context. (Joonas)

v7:

- Remove per-engine ctx status notifiers. Use one status notifier for all
engines. (Joonas)
- Add prefix "INTEL_" for related definitions. (Joonas)
- Refine the comments in execlists_context_status_change(). (Joonas)

v6:

- When !CONFIG_DRM_I915_GVT, make GVT code as dead code then compiler
could automatically eliminate them for us. (Chris)
- Always initialize the notifier header, so it could be switched on/off
at runtime. (Chris)

v5:

- Only compile this feature when CONFIG_DRM_I915_GVT is enabled.(Tvrtko)

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v8)
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466078825-6662-8-git-send-email-zhi.a.wang@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>