Imre Deak [Wed, 16 Mar 2016 11:39:04 +0000 (13:39 +0200)]
drm/i915: Split out load time MMIO initialization
According to the new init phases scheme we should have a definite step
in the init sequence where MMIO access is setup, so move the
corresponding code to a separate function. This also has the benefit of
making the error path cleaner both in the new function and in
i915_driver_load()/unload().
Imre Deak [Wed, 16 Mar 2016 11:39:03 +0000 (13:39 +0200)]
drm/i915: Split out load time early initialization
According to the new init phases scheme we should initialize "SW-only"
state not requiring accessing the device as the very first step, so that
the reasoning about dependencies of later steps becomes easier. So move
these init steps into a separate function. This also has the benefit of
making the error path cleaner both in the new function and int
i915_driver_load()/unload().
Imre Deak [Wed, 16 Mar 2016 11:39:01 +0000 (13:39 +0200)]
drm/i915: Move unload time GTT, MSI IRQ cleanup later
Move the GTT,MSI IRQ cleanup later so that it matches their
corresponding init order. Also fix the order of these calls wrt. each
other to match their corresponding init order.
Imre Deak [Wed, 16 Mar 2016 11:39:00 +0000 (13:39 +0200)]
drm/i915: Move unload time display power domain uninit later
Move the power domain uninitialization later so that it matches its
corresponding init order. Since we access the HW during the later
unitialization steps keep a wake reference until after the last such
step.
Imre Deak [Wed, 16 Mar 2016 11:38:58 +0000 (13:38 +0200)]
drm/i915: Move load time shrinker registration later
According to the new init phases scheme we should register the driver
with frameworks/userspace only one the device is setup fully. So move
the shrinker registration later accordingly.
Also fix the shrinker unregistration order wrt. the acpi unregistration
to fix the corresponding init order.
Imre Deak [Wed, 16 Mar 2016 12:54:03 +0000 (14:54 +0200)]
drm/i915: Move load time gem_load_init earlier
The only steps requiring device access is the fence and swizzling
initialization, so split these out keeping them in their current place
and move the rest of init steps earlier.
v2-v3:
- unchanged
v4:
- move call to i915_gem_detect_bit_6_swizzle() to
i915_gem_load_init_fences() and preserve the original order of
the detection of HW fence capailities wrt. swizzling (Chris)
Imre Deak [Wed, 16 Mar 2016 11:38:55 +0000 (13:38 +0200)]
drm/i915: Move load time runtime device info init earlier
This init step accesses the device, but doesn't have any device
specific side effect. It also sets up some platform specific
attributes that may be required early, so move it earlier.
Imre Deak [Wed, 16 Mar 2016 11:38:54 +0000 (13:38 +0200)]
drm/i915: Move load time init of clock gating hooks earlier
Split out the part initing the clock gating hooks and move it earlier.
Add a new NOP hook for platforms without the need to apply clockgating
or workaround settings, so that the hook can be called unconditionally.
Also add a WARN for future platforms that forget to add a hook.
The rest of the hooks in intel_init_pm() should be inited in the same
way, but atm some of the hooks are set only conditionally, so before
doing this we need to make the setup unconditional and use instead some
flags.
v2:
- add a NOP hook and WARN if no hook is set for the platform (Chris)
- use the term hook instead of callback for these functions (Jani)
v3:
- remove the GEN4() check it's already covered by earlier platform
checks (Chris)
Imre Deak [Wed, 16 Mar 2016 11:38:53 +0000 (13:38 +0200)]
drm/i915: Move load time init of display/audio hooks earlier
All of this is SW only initialization so we can move them earlier. Move
the mutex init where the rest of the locks are inited. While at it also
convert dev to dev_priv.
v2:
- use the term hook instead of callback for these functions (Jani)
Imre Deak [Wed, 16 Mar 2016 11:38:51 +0000 (13:38 +0200)]
drm/i915: Move load time PCH detect, DPIO, power domain SW init earlier
These are all SW only init steps not accessing the device and they only
need the platform identification macros to work, which are already
available earlier, so move these init steps earlier.
Mika Kuoppala [Wed, 16 Mar 2016 15:54:00 +0000 (17:54 +0200)]
drm/i915: Modify reset func to handle per engine resets
In full gpu reset we prime all engines and reset domains corresponding to
each engine. Per engine reset is just a special case of this process
wherein only a single engine is reset. This change is aimed to modify
relevant functions to achieve this. There are some other steps we carry out
in case of engine reset which are addressed in later patches.
Reset func now accepts a mask of all engines that need to be reset. Where
per engine resets are supported, error handler populates the mask
accordingly otherwise all engines are specified.
v2: ALL_ENGINES mask fixup, better for_each_ring_masked (Chris)
v3: Whitespace fixes (Chris)
v4: Rebase due to s/ring/engine
Jani Nikula [Wed, 16 Mar 2016 10:43:35 +0000 (12:43 +0200)]
drm/i915: hide away VBT private data in a separate header
We've been accumulating code across the driver that depends on the VBT
specific structures and defines. The VBT is an uncontrollable
beast. Encourage encapsulation of the VBT data by hiding the structures
and defines in a private header only to be included from intel_bios.c.
Lyude [Wed, 16 Mar 2016 19:18:04 +0000 (15:18 -0400)]
drm/i915: Fix race condition in intel_dp_destroy_mst_connector()
After unplugging a DP MST display from the system, we have to go through
and destroy all of the DRM connectors associated with it since none of
them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
doesn't do a good enough job of ensuring that throughout the destruction
process that no modesettings can be done with the connectors. As it is
right now, intel_dp_destroy_mst_connector() works like this:
* Take all modeset locks
* Clear the configuration of the crtc on the connector, if there is one
* Drop all modeset locks, this is required because of circular
dependency issues that arise with trying to remove the connector from
sysfs with modeset locks held
* Unregister the connector
* Take all modeset locks, again
* Do the rest of the required cleaning for destroying the connector
* Finally drop all modeset locks for good
This only works sometimes. During the destruction process, it's very
possible that a userspace application will attempt to do a modesetting
using the connector. When we drop the modeset locks, an ioctl handler
such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
locks from us. When this happens, one thing leads to another and
eventually we end up committing a mode with the non-existent connector:
[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training
[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
[drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization
[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
[drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
And in some cases, such as with the T460s using an MST dock, this
results in breaking modesetting and/or panicking the system.
To work around this, we now unregister the connector at the very
beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
locks, and then hold them until we finish the rest of the function.
Alex Dai [Wed, 16 Mar 2016 22:24:13 +0000 (15:24 -0700)]
drm/i915/guc: Support GuC SKL v6.1
This version of GuC firmware fixes the engine reset issue where golden
context LRC address is treated as page index by mistake. It also fixes
the problem that scheduler stops submiting to one engine when the other
engine work queue is full.
Signed-off-by: Alex Dai <yu.dai@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Jani Nikula [Wed, 16 Mar 2016 10:43:34 +0000 (12:43 +0200)]
drm/i915/bios: drop has_mipi in favor of intel_bios_is_dsi_present
Favor a single point of truth instead of duplicating the
information. The change also filters out unsupported DSI ports at this
stage, accepting only ports A and C, instead of waiting until the port
checks.
Jani Nikula [Wed, 16 Mar 2016 10:43:33 +0000 (12:43 +0200)]
drm/i915/panel: setup pwm backlight based on connector type
Use the connector type instead of VBT directly to decide which backlight
mechanism to use on VLV/CHV. (Indirectly, this is the same thing, but
hides the VBT use.)
Jani Nikula [Tue, 15 Mar 2016 19:51:09 +0000 (21:51 +0200)]
drm/i915: add for_each_port_masked macro
Same as for_each_dsi_port, but for general use. Leave the
for_each_dsi_port version around as an "alias" for now to not cause too
much churn. No functional changes.
Jani Nikula [Wed, 16 Mar 2016 10:21:40 +0000 (12:21 +0200)]
drm/i915/dsi: start using enum mipi_dsi_pixel_format
A small step moving us closer to DRM MIPI DSI code. Use enum
mipi_dsi_pixel_format instead of our own. The first benefit is being
able to use common mipi_dsi_pixel_format_to_bpp().
There's a little back and forth conversion with the VBT -> enum ->
register, since we have just shoved the VBT value into the register
directly. Longer term, all the VBT parsing and deciphering should be
done in intel_bios.c, and abstracted there.
Jani Nikula [Wed, 16 Mar 2016 10:21:39 +0000 (12:21 +0200)]
drm/i915/dsi: lose the loose 666 format name in favor of packed
The enum mipi_dsi_pixel_format defines MIPI_DSI_FMT_RGB666 for the
"loose" 24 bpp format and MIPI_DSI_FMT_RGB666_PACKED for the 18 bpp
format. We have this the other way round, defining a loose version for
24 bpp.
Follow suit with what's in enum mipi_dsi_pixel_format to avoid future
confusion. Rename
Chris Wilson [Mon, 7 Mar 2016 12:05:57 +0000 (12:05 +0000)]
drm/i915/csr: Allow matching unknown HW steppings with generic firmware
If the firmware is generic and has a run-anywhere mode, enable it rather
than completely failing on unknown HW revisions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457352357-8433-1-git-send-email-chris@chris-wilson.co.uk
Nathan Schulte [Tue, 15 Mar 2016 15:14:05 +0000 (10:14 -0500)]
drm/i915: add module param "enable_dp_mst"
Adds an (unsafe; auto-kernel-tainting) boolean module parameter to the i915
drm driver: "enable_dp_mst", which is enabled by default. Disabling the
parameter forces newly connected DisplayPort sinks to report as not
supporting multi-stream transport (MST), thus "forcing" the use of
single-stream transport (SST).
v2: rename parameter to conform to style
v3: add signoff
But that didn't fully work so I cleaned it up with:
for f in *.[hc]; do sed -i -e s/I915_NUM_RINGS/I915_NUM_ENGINES/ $f; done
for f in *.[hc]; do sed -i -e s/i915_gem_request_get_ring/i915_gem_request_get_engine/ $f; done
for f in *.[hc]; do sed -i -e s/intel_ring_flag/intel_engine_flag/ $f; done
for f in *.[hc]; do sed -i -e s/intel_ring_idle/intel_engine_idle/ $f; done
for f in *.[hc]; do sed -i -e s/init_ring_lists/init_engine_lists/ $f; done
for f in *.[hc]; do sed -i -e s/i915_gem_reset_ring_cleanup/i915_gem_reset_engine_cleanup/ $f; done
for f in *.[hc]; do sed -i -e s/i915_gem_reset_ring_status/i915_gem_reset_engine_status/ $f; done
v2: Rebase.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Imre Deak [Mon, 14 Mar 2016 17:55:34 +0000 (19:55 +0200)]
drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs
After the commit below the Broxton PLL IDs had an off-by-one error, so
fix this up. Also add a missing brace at intel_shared_dpll_init(), it
happened to compile only due to the way the IS_BROXTON macro is defined.
v2:
- remove debugging left-over
Fixes: a3c988ea068c ("drm/i915: Make SKL/KBL DPLL0 managed by the shared dpll code") CC: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> CC: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457978134-12362-1-git-send-email-imre.deak@intel.com
drm/i915: Nuke fbc members from intel_crtc->atomic, v4.
Whenever there's an update to the primary plane,
fbc_pre_update and fbc_post_update are called. Kill off
intel_crtc->atomic.update_fbc and now that intel_crtc->atomic
is empty, kill it off too.
Changes since v1:
- Add a intel_fbc_supports_rotation helper.
Changes since v2:
- Remove intel_fbc_supports_rotation_helper.
- Remove unrelated changes.
Changes since v3:
- Rebase
drm/i915: Remove some post-commit members from intel_crtc->atomic, v3.
fb_bits is useful to have in the crtc_state for cs flips when
the code is updated to use intel_frontbuffer_flip_prepare/complete.
So calculate it in advance and move it to crtc_state. The other stuff
can be calculated in post_plane_update, and aren't useful elsewhere.
Changes since v1:
- Changing wording, remove comment about loop.
Changes since v2:
- Rebase.
Daniel Vetter [Wed, 16 Mar 2016 07:11:09 +0000 (08:11 +0100)]
Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued
Backmerge because:
- Maarten needs latest atomic patches from drm-misc.
- Lionel needs the color manager core patch from drm-misc.
- Ander extracted intel_dpll_mgr.c, we need a backmerge to avoid git
losing track of things too often (right now it seems ok due to
cherry-picks).
- Tvrtko needs a stable baseline to apply some large-scale renaming
patches to i915 GEM code.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
gcc-6 warns about code in the nouveau driver that is obviously silly:
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c: In function 'nv40_perfctr_next':
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c:62:19: warning: self-comparison always evaluats to false [-Wtautological-compare]
if (pm->sequence != pm->sequence) {
The behavior was accidentally introduced in a patch described as "This is
purely preparation for upcoming commits, there should be no code changes here.".
As far as I can tell, that was true for the rest of that patch except for
this one function, which has been changed to a NOP.
This patch restores the original behavior.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 8c1aeaa13954 ("drm/nouveau/pm: cosmetic changes") Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Wed, 16 Mar 2016 01:09:00 +0000 (11:09 +1000)]
Merge tag 'drm-amdkfd-next-fixes-2016-03-15' of git://people.freedesktop.org/~gabbayo/linux into drm-next
* tag 'drm-amdkfd-next-fixes-2016-03-15' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: uninitialized variable in dbgdev_wave_control_set_registers()
Tomi Valkeinen [Tue, 15 Mar 2016 12:55:53 +0000 (14:55 +0200)]
drm/omap: fix panel/encoder probes
The recent changes which removed platform data support from panels &
encoders had a few mistakes, causing probes of DVI connector and DSI
command mode panels to fail every time due to missing '!'. Fix the
if()s.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Mon, 14 Mar 2016 23:49:19 +0000 (09:49 +1000)]
Merge tag 'drm-vc4-next-2016-03-14' of github.com:anholt/linux into drm-next
This pull request covers what's left for 4.6. Notably, it includes a
significant 3D performance improvement and a fix to HDMI hotplug
detection for the Pi2/3.
* tag 'drm-vc4-next-2016-03-14' of github.com:anholt/linux:
drm/vc4: Recognize a more specific compatible string for V3D.
dt-bindings: Add binding docs for V3D.
drm/vc4: Return -EFAULT on copy_from_user() failure
drm/vc4: Respect GPIO_ACTIVE_LOW on HDMI HPD if set in the devicetree.
drm/vc4: Let gpiolib know that we're OK with sleeping for HPD.
drm/vc4: improve throughput by pipelining binning and rendering jobs
Eric Anholt [Fri, 4 Mar 2016 20:32:07 +0000 (12:32 -0800)]
drm/vc4: Recognize a more specific compatible string for V3D.
The Raspberry Pi Foundation's firmware updates are shipping device
trees using the old string, so we'll keep recognizing that as this rev
of V3D. Still, we should use a more specific name in the upstream DT
to clarify which board is being supported, in case we do other revs of
V3D in the future.
Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Dave Airlie [Mon, 14 Mar 2016 00:49:40 +0000 (10:49 +1000)]
Merge branch 'linux-4.6' of git://github.com/skeggsb/linux into drm-next
- GM20x secure boot support (hence, acceleration, finally \o/)
- GM200 support
- GM20B clock driver
- Support for power sensors on some GPUs
- Various other fixes all over the place
* 'linux-4.6' of git://github.com/skeggsb/linux: (95 commits)
drm/nouveau/clk/gm20b: add basic driver
drm/nouveau/clk/gk20a: share reusable structures/functions
drm/nouveau/clk/gk20a: set lowest frequency during init()
drm/nouveau/clk/gk20a: split gk20a_clk_new()
drm/nouveau/clk/gk20a: abstract pl_to_div
drm/nouveau/clk/gk20a: put mnp values into their own struct
drm/nouveau/clk/gk20a: emit parent rate as debug message
drm/nouveau/clk/gk20a: only restore divider to 1:1 if needed
drm/nouveau/clk/gk20a: only compute n_lo if needed
drm/nouveau/clk/gk20a: fix VCO bit mask
drm/nouveau/clk/gk20a: rename enable/disable functions
drm/nouveau/clk/gk20a: reorganize variables in gk20a_pllg_calc_mnp()
drm/nouveau/clk/gk20a: convert parameters to Khz
drm/nouveau/volt: add GM20B driver
drm/nouveau/volt/gk20a: split constructor
drm/nouveau/volt/gk20a: share reusable members & functions
drm/nouveau/ce/gm107: expose MaxwellDmaCopyA
drm/nouveau/fifo/gm107: KeplerChannelGpfifoB, and 2048 channels
drm/nouveau/fifo/gk110: expose KeplerChannelGpfifoB
drm/nouveau/fifo/gk104: submit NOP after all PBDMA_INTR_0, not just DEVICE
...
drm/nouveau/clk/gk20a: only restore divider to 1:1 if needed
Only restore the 1:1 divider if it is not set already. Also use the
proper masks for this operation and add a second write as done in the
Android code.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fix the mask specified to switch to VCO mode was given as an (incorrect)
immediate value. Although the side-effect happens to be the same, this
is clearly incorrect.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
gk20a_pllg_disable() is only used in the context of gk20a_clk_fini().
Move its body there and rename _gk20a_pllg_enable() and
_gk20a_pllg_disable() to non-underscored versions.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This class supports a WFI method (0x0078) that's not present on the
KeplerChannelGpfifoA class.
The binary driver exposes both classes on these GPUs for some reason,
though there doesn't appear to be any difference in the setup that's
done for each (ie. even if you allocate GpfifoA, the WFI method will
still work).
We shall just expose GpfifoB, as I don't see a good reason to report
the presence of both.