i915 GuC submission is hardware interface and GuC APIs that are not user
facing should be named intel_guc* hence we change GuC submission related
functions name prefix to intel_guc. Also changed the parameter to these
functions to intel_guc struct.
v2: Using local guc variable in intel_uc_fini_hw. (Michal Wajdeczko)
Rebase.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510839162-25197-4-git-send-email-sagar.a.kamble@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
i915_guc_submit, i915_guc_dequeue, i915_guc_submission_park and
i915_guc_submission_upark are functions internal to GuC submission
hence remove "i915_" prefix.
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510839162-25197-3-git-send-email-sagar.a.kamble@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
intel_lrc_irq_handler and i915_guc_irq_handler are HW submission related
tasklet functions. Name them with "submission_tasklet" suffix and
remove intel/i915 prefix as they are static. Also rename irq_tasklet
as just tasklet for clarity.
v2: s/_bh/_tasklet (Chris)
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1510839162-25197-2-git-send-email-sagar.a.kamble@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We check whether the multiplies will overflow prior to calling
kmalloc_array so that we can respond with -EINVAL for the invalid user
arguments rather than treating it as an -ENOMEM that would otherwise
occur. However, as Dan Carpenter pointed out, we did an addition on the
unsigned int prior to passing to kmalloc_array where it would be
promoted to size_t for the calculation, thereby allowing it to overflow
and underallocate.
v2: buffer_count is currently limited to INT_MAX because we treat it as
signaled variable for LUT_HANDLE in eb_lookup_vma
v3: Move common checks for eb1/eb2 into the same function
v4: Put the check back for nfence*sizeof(user_fence) overflow
v5: access_ok uses ULONG_MAX but kvmalloc_array uses SIZE_MAX
v6: size_t and unsigned long are not type-equivalent on 32b
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171116105059.25142-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
When we call intel_engine_cancel_signaling() to stop reporting when
a request is completed via an asynchronous signal, we remove that request
from the breadcrumb wait queue. However, we may be concurrently
processing that request in the signaler itself, the actual operations on
the request's node itself are serialised but we do not actually clear the
waiter after removing it from the tree allowing both parties to attempt
to do so and corrupting the rbtree. (Previously removing from the
breadcrumb wait queue could only be done on behalf of i915_wait_request,
so this race could not happen).
Reported-by: "He, Bo" <bo.he@intel.com>
Fixes: 9eb143bbec ("drm/i915: Allow a request to be cancelled")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "He, Bo" <bo.he@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115121458.24655-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
It is easier to categorize and debug bugs if the failed condition
is in plain sight in the actual dmesg output. Make it so.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Marta Lofstedt <marta.lofstedt@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171116083954.3357-1-mika.kuoppala@linux.intel.com
WaEnablePooledEuFor2x6 only applies to preproduction models, unsupported
since commit 0102ba1fd8 ("drm/i915: Add early BXT sdv to the list of
preproduction machines").
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114135116.30036-1-chris@chris-wilson.co.uk
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
At the start of building a request, we would wait for roughly enough
space to fit the average request (to reduce the likelihood of having to
wait and abort partway through request construction). To achieve we
would try to begin a 0-length command packet, this just adds extra
confusion so make the wait-for-space explicit, as in the next patch we
want to move it from the backend to the i915_gem_request_alloc() so it
can ensure that the wait-for-space is the first operation in building a
new request.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115151204.8105-2-chris@chris-wilson.co.uk
We don't actually emit any commands into the ringbuffer, so we set it
very small. However, an upcoming change centralises the wait-for-space
into i915_gem_request_alloc() and that imposes a minimum size upon all
ringbuffers (mock or real) of MIN_SPACE_FOR_ADD_REQUEST. Grow the
mock ringbuffer such that we allocate a single page for the struct+buffer,
satisfying the new condition without wasting too much space.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115151204.8105-1-chris@chris-wilson.co.uk
gcc-4.7.3 is confused by the guards inside intel_ppat_get() and reports:
drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘intel_ppat_get’:
drivers/gpu/drm/i915/i915_gem_gtt.c:3044:27: warning: ‘entry’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Forgive the compiler this once, and rearrange the code so that entry is
always initialised.
v2: Flavour with a bit of NULL (instead of ERR_PTR(-ENOSPC))
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115131705.16341-1-chris@chris-wilson.co.uk
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
While I have no solid proof that ILK follows the ELK path when it
comes to the stolen memory reserved area, there are some hints that
it might be the case. Unfortunately my ILK doesn't have this enabled,
and no way to enable it via the BIOS it seems.
So let's have ILK use the ELK code path, and let's toss in a WARN
into the code to see if we catch anyone with an ILK that has this
enabled to further analyze the situation.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171102151737.23336-3-ville.syrjala@linux.intel.com
Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Now that we should be properly filtering out the cases when the stolen
reserved area is disabled, let's convert the debug message about a
misplaced reserved area into an error.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171102151737.23336-2-ville.syrjala@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Apparently there are some machines that put semi-sensible looking values
into the stolen "reserved" base and size, except those values are actually
outside the stolen memory. There is a bit in the register which
supposedly could tell us whether the reserved area is even enabled or
not. Let's check for that before we go trusting the base and size.
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171102151737.23336-1-ville.syrjala@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Fix copy/paste fail in kerneldocs for intel_audio_codec_disable().
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114191127.16188-1-ville.syrjala@linux.intel.com
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Quoting Ville: "the forcewake timer might still be active until the uncore
suspend, and having active forcewakes while we've already told the GT wake
stuff to stop acting normally doesn't seem quite right to me."
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-3-hdegoede@redhat.com
intel_uncore_suspend() unregisters the uncore code's PMIC bus access
notifier and gets called on both normal and runtime suspend.
intel_uncore_resume_early() re-registers the notifier, but only on
normal resume. Add a new intel_uncore_runtime_resume() function which
only re-registers the notifier and call that on runtime resume.
Cc: stable@vger.kernel.org
Reported-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:
intel_runtime_pm_put does:
atomic_dec(&dev_priv->pm.wakeref_count);
pm_runtime_mark_last_busy(kdev);
pm_runtime_put_autosuspend(kdev);
And pm_runtime_put_autosuspend calls intel_runtime_suspend from
a workqueue, so there is ample of time between the atomic_dec() and
intel_runtime_suspend() unregistering the notifier. If the notifier
gets called in this windowd assert_rpm_wakelock_held falsely triggers
(at this point we're not runtime-suspended yet).
This commit adds disable_rpm_wakeref_asserts and
enable_rpm_wakeref_asserts calls around the
intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.
Changes in v2:
-Reword comment explaining why disabling the wakeref asserts is
ok and necessary
Cc: stable@vger.kernel.org
Reported-by: FKr <bugs-freedesktop@ubermail.me>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com
smatch does not track initialised values as well as gcc, and this
triggers many warnings by smatch not presented by gcc. Silence smatch by
initialising the error values to -ENODEV, which we use to denote
internal errors. (If we see a selftest fail with a silent -ENODEV, we
know smatch was right!)
v2: smatch was right about igt_create_vma(), it may unlikely fail on the
first object allocation which we want to be loud about.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114223346.25958-1-chris@chris-wilson.co.uk
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Resuming GEM presumes it can talk to hw, in particular to ensure the
kernel context is loaded upon resume for powersaving. If the GuC is
still asleep at this point, we upset the HW. Rearrange the resume such
that we restore the original order of init-hw, resume-guc, use-gem.
Fixes: 37cd33006d ("drm/i915: Remove redundant intel_autoenable_gt_powersave()")
References: a1c4199414 ("drm/i915/guc: Add host2guc notification for suspend and resume")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Alex Dai <yu.dai@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114130300.25677-2-chris@chris-wilson.co.uk
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Display is not sending a PMRsp when a PMReq is received
at the same time that all planes are turned off.
State machine in the dcprunit is stuck in the WAIT4DONE
state which means that there is no fill_done.
WA: disable arbiter clock gating, set bit [27] of 0x46530
v2: As Ville pointed out, based on the description the issue
can happen when disabling the planes, similar to
WaRsPkgCStateDisplayPMReq:hsw
Also description of the issue was updated on commit
message to make it more clear that we need this
earlier.
v3: Restore comment about possibility to system hang
to where we are sure about it, without speculation. (Ville).
v4: Remove doubled sob. Actually do v3 changes :/
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171111000319.5040-1-rodrigo.vivi@intel.com
Having removed the preproduction Broxton support (see commit 0102ba1fd8
("drm/i915: Add early BXT sdv to the list of preproduction machines")),
we know we then always need the production Broxton workaround set and do
not need a predicate upon revision.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114134340.5439-2-chris@chris-wilson.co.uk
gem_workarounds reports that the SLICE_UNIT_LEVEL_CLKGATE write isn't
sticking. Commit 0a60797a0e ("drm/i915: Implement
ReadHitWriteOnlyDisable.") presumes that SLICE_UNIT_LEVEL_CLKGATE is a
masked register in the context image, but commit 90007bca61
("drm/i915/cnl: Introduce initial Cannonlake Workarounds.") lists it as
an ordering unmasked register. The masked write will be losing the
default settings if we trust the original commit. That gem_workarounds
reports the value is lost entirely is more worrying though -- but it
clearly suggests that it is not a masked register in the context image,
so unify both w/a to use the original rmw.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103705
Fixes: 0a60797a0e ("drm/i915: Implement ReadHitWriteOnlyDisable.")
References: 90007bca61 ("drm/i915/cnl: Introduce initial Cannonlake Workarounds.")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171111100336.11020-1-chris@chris-wilson.co.uk
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/i915/i915.ko] undefined!
Store the frequency in kHz and drop 64bit divisions.
v2: Use div64_u64 (Matthew)
v3: store frequency in kHz to avoid 64bit divs (Chris/Ville)
Fixes: dab9178333 ("drm/i915: expose command stream timestamp frequency to userspace")
Reported-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113233455.12085-3-lionel.g.landwerlin@intel.com
Reviewed-by: Ewelina Musial <ewelina.musial@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
To make looping through transcoders in intel_ddi.c more generic, let's switch
to use 'for_each_pipe()' macro to do this.
v2: Add a notion that we are dealing with transcoders instead of pipes (Jani)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510216670-16848-1-git-send-email-mika.kahola@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Since GLK, some plane configuration settings have moved to the
PLANE_COLOR_CTL register. Refactor handling of the register to work like
PLANE_CTL. This also allows us to fix the set/read of the plane Alpha
Mode for GLK+.
v2: Adjust ordering of platform checks to be newest->oldest, drop
redundant comment about alpha blending. (Ville)
v3: Move Alpha Mode bits out of skl_plane_ctl_format into
skl_plane_ctl_alpha, and drop glk_plane_ctl_format, drop initialization
of state->color_ctl on platforms that don't use it, and drop color_ctl
local var. (Ville)
v4: Consolidate skl_plane_ctl_format switch statement on formats that
return the same settings. (Ville)
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113181128.2926-1-james.ausmus@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
GEM proxy is a kind of GEM, whose backing physical memory is pinned
and produced by guest VM and is used by host as read only. With GEM
proxy, host is able to access guest physical memory through GEM object
interface. As GEM proxy is such a special kind of GEM, a new flag
I915_GEM_OBJECT_IS_PROXY is introduced to ban host from changing the
backing storage of GEM proxy.
v3:
- update "Reviewed-by". (Joonas)
v2:
- return -ENXIO when pin and map pages of GEM proxy to kernel space.
(Chris)
Here are the histories of this patch in "Dma-buf support for Gvt-g"
patch-set:
v14:
- return -ENXIO when gem proxy object is banned by ioctl.
(Chris) (Daniel)
v13:
- add comments to GEM proxy. (Chris)
- don't ban GEM proxy in i915_gem_sw_finish_ioctl. (Chris)
- check GEM proxy bar after finishing i915_gem_object_wait. (Chris)
- remove GEM proxy bar in i915_gem_madvise_ioctl.
v6:
- add gem proxy barrier in the following ioctls. (Chris)
i915_gem_set_caching_ioctl
i915_gem_set_domain_ioctl
i915_gem_sw_finish_ioctl
i915_gem_set_tiling_ioctl
i915_gem_madvise_ioctl
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> #v1
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1510555798-21079-2-git-send-email-tina.zhang@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114102513.22269-2-chris@chris-wilson.co.uk
-ENXIO should be returned when operations are banned from changing
backing storage of objects without backing storage.
v4:
- update "Reviewed-by". (Joonas)
v3:
- separate this patch from "Introduce GEM proxy" patch-set. (Joonas)
v2:
- update the patch description and subject to just mention objects w/o
backing storage, instead of "GEM proxy". (Joonas)
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1510555798-21079-1-git-send-email-tina.zhang@intel.com
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114102513.22269-1-chris@chris-wilson.co.uk
Commit 7859799637 (drm/i915/bxt: Fix PPS lost state after suspend
breaking eDP link training) renamed the function to
intel_power_sequencer_reset() but forgot to update comment.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114004638.5186-1-lucas.demarchi@intel.com
. It moves mode setup and plane update code to commit
like other CRTC drivers
. It makes mode commit to be called in enable callback only one time
. some cleanup and fixup to HDMI and Mixer drivers.
. It adds 1024x768, 1280x1024 and 1366x768 modes support
- Added HDMI audio interface driver
. As of now, HDMI audio worked on boards with external audio codec connected
in parallel with the HDMI audio transmitter's I2S interface.
This patch is required to support HDMI audio properly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZ8SydAAoJEFc4NIkMQxK4CW8P/1cwTPcVcsdjjWQ9xuYEPjum
2bdi9CkCxwlCM6t05azcm1x6fMoZMTuTqkL0eEsS+g64ZFCmd+kRwKkxJxp2zMGO
CAz7D+baliOEuELtSJHQ9zOartiwHWLfMptJZFpOciQOSDPOMOVhJNBW6mnxC4xn
J+YDUTbW/Rbd4CwBeBCW9s+VidDP21QhXrZui5k6ZZP+rOSRgtTtKcbWaSzZIdp0
mmqnWIwgmThkSGc17a5wcXHHal1YxvbdiV1gzAZUo+mrBKSHFc60ibgfEV5atnvn
OctaBVA/glNhSz1F1OoUZVUDMg5IsrnJ9QND8DjJcm9MgXMFM5BfQQOkcGs2uq4w
hZBEr4MRi1rJ9+Q3Cc2AXcGOkFhnJJOVtgUWd4u0UsKk7BGY+9XF2/e5eA0Sp1ep
hkE4kbXf6efENqbTD0a4gnucBJhcG/nD0+PJh+IE7HFfLHgMsEkjKy3gDZRiu3lu
1QSljBGLXgYjHR8BM/oMwxJBGJwCGMY2/+MMzaWckrQ7YxMct72Fh0Nzh1R/o/Su
jBtsjre4Vob1I5OoVolL6gvZLik49yB0FmXsnGXvQjAEuRwoxNAxvjMYQjGpnOme
Ya8xsSFYEdzfE/yNgwJK+hsB/EaOgSr1zaGE0Gobo54nHbtBnyEC2gY1cg3296hS
9lwuxQvuJrzQVqlbJYbY
=wpjH
-----END PGP SIGNATURE-----
Merge tag 'exynos-drm-next-for-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
- Improved HDMI and Mixer drivers
. It moves mode setup and plane update code to commit
like other CRTC drivers
. It makes mode commit to be called in enable callback only one time
. some cleanup and fixup to HDMI and Mixer drivers.
. It adds 1024x768, 1280x1024 and 1366x768 modes support
- Added HDMI audio interface driver
. As of now, HDMI audio worked on boards with external audio codec connected
in parallel with the HDMI audio transmitter's I2S interface.
This patch is required to support HDMI audio properly.
* tag 'exynos-drm-next-for-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm: exynos: Add driver for HDMI audio interface
drm/exynos/hdmi: add 85.5MHz pixel clock for v14 HDMI PHY
drm/exynos/mixer: enable support for 1024x768 and 1280x1024 modes
drm/exynos/hdmi: quirk for support mode timings conversion
drm/exynos/mixer: pass actual mode on MIXER to encoder
drm/exynos: add mode_fixup callback to exynos_drm_crtc_ops
drm/exynos/hdmi: remove redundant mode field
drm/exynos/mixer: remove mixer_resources sub-structure
drm/exynos/mixer: fix mode validation code
drm/exynos/mixer: move resolution configuration to single function
drm/exynos/mixer: move mode commit to enable callback
drm/exynos/mixer: abstract out output mode setup code
This is a shared tree between drm and audio for some amd bits.
* 'linus-4.14-rc4-acp-prereq' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu Moving amdgpu asic types to a separate file
ASoC: AMD: Added asic_type as ACP DMA driver platform data
drm/amd/amdgpu: Added asic_type as ACP DMA driver platform data
- qxl: Use a shadow bo as primary and blit to it to fix flicker (Gerd)
- rockchip: Convert psr spinlock to mutex (Emil)
Cc: Emil Renner Berthing <kernel@esmil.dk>
Cc: Gerd Hoffmann <kraxel@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEfxcpfMSgdnQMs+QqlvcN/ahKBwoFAloJ8gUACgkQlvcN/ahK
BwruCAf/afFM64VPaMhYwl5ejfDHs39TuahlOPZ2/wx8ABdk9y5RVtidoi5grk7a
KSJcR0jPMeCnhWmEod2nEADtIxOvyq30EdttGX/OGWv0ydTqb5peCbYbc7H3J1N/
nCdHDygC6a3/0/mFuTVNnKMhiggPmbBZKjFiXMv8t2GQXJd1iDn4WS1A8JoL3zE3
Ey4ZV+m7dsm1fQB5B+/84zG34SeqQ7N7sUHm3N9DUGXgfCfbodvb8uKfh4DB8dIU
JOXiD60GGZ21HhEdZWcVleZLfNoM6tAHD6q6g8mrPAmUM60Naf0THQrnVH8xNONc
B1v53iQrqxjF9O/oMpycc1dGXxbnRA==
=cz6U
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2017-11-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
Driver Changes:
- qxl: Use a shadow bo as primary and blit to it to fix flicker (Gerd)
- rockchip: Convert psr spinlock to mutex (Emil)
Cc: Emil Renner Berthing <kernel@esmil.dk>
Cc: Gerd Hoffmann <kraxel@redhat.com>
* tag 'drm-misc-fixes-2017-11-13' of git://anongit.freedesktop.org/drm/drm-misc:
drm/rockchip: analogix_dp: Use mutex rather than spinlock
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEFWWmW3ewYy4RJOWc05gHnSar7m8FAloFp5MACgkQ05gHnSar
7m+ANQ//bTlW1dQcGIl5oVZOmpfYLJdzMf+bczUyH0J83uuZCUAqztuOTeIWaP1Z
Vq7NXErgrMzLvoTWHUl3zdwesUZ9M4qIv1L3wdpkn14Sk7Hqg6gmjF7+D/oedg71
9H5Y3iY6DJz1loDpv9gvLHqa/ErbnvApoKKFUNMfLavzMEpGk/iUi9N+ZoqHAf+V
PscyPRjeq2kZKOS0W1kFlol5MLvvQ/LPJF4mrP2CU38SKfJiR1QOmsd342j9fIOg
vid3Q4y079qX0gdrirEjpIjtMJznVjhdB3WlmOSNksDE7MuYLgKLlGW/vxX4ajQ1
eD4efgRoPRCBG3y8itjmnvN5aU5A5jIaTnWsc6VoIxUiSrmLKfbe7D/54VVTxVIS
qnWNLa3RR87C3UILvMhUzkTRhZi8Dw0wq4vq5/ZF6TwXgjdBqocd/NKDULCSTZET
vSHRCSsjlDbGTuFL3mOL5i0h92hsMMWbzw1JaPZgDLguCjH9zUEBjVgkYzHtO9s+
HXyp71/f+xdJdNQX4AxRCVvbItvVVSZTo2NhUPeyxWFt9AafzzJxk2rco5rzBThE
TisAFDxq9ygvUHLatHR8ZGv9oHcesbyAQBL0ySLnopOkr/0IgkQmB8PjNncB2h7a
+P0NpsgRrlaxLX+R9qsb8OfZbL/++nFfcCKHNY4L1vg0qiwuPJI=
=crrm
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-fixes-2017-11-10' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
drm/i915 fixes for v4.15
* tag 'drm-intel-next-fixes-2017-11-10' of git://anongit.freedesktop.org/drm/drm-intel:
drm/i915: Reorder context-close to avoid calling i915_vma_close() under RCU
drm/i915: Move init_clock_gating() back to where it was
drm/i915: Prune the reservation shared fence array
drm/i915: Idle the GPU before shinking everything
drm/i915: Lock llist_del_first() vs llist_del_all()
drm/i915: Calculate ironlake intermediate watermarks correctly, v2.
drm/i915: Disable lazy PPGTT page table optimization for vGPU
drm/i915/execlists: Remove the priority "optimisation"
drm/i915: Filter out spurious execlists context-switch interrupts
- qxl: Use a shadow bo as primary and blit to it to fix flicker (Gerd)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEfxcpfMSgdnQMs+QqlvcN/ahKBwoFAln7GdwACgkQlvcN/ahK
BwqqiggAgZSKgZzxgu5eBepENn9RiYuShC9jZPPSlA6FUKZ+2gFXdi0Ni+6fD7OV
oDliVcQWcfQDzePWiKlgObCLNMVEpNcGbIyqwJbEY8k664hh2bQVVuB0fZiPY8nn
Oc4ExSSePrhoam+fuOLfS39xERpAtG7j2cVxnLfrUBxM6wLo9FpwmD+mUCKorO1F
iF37uPQ571dTNheQK99KDJctFu4tzm9z0Jfbne4bF10rA+02/0Ov6cW/SOwlIdQ5
bMrwHQ7NGIDtipyKNzOQO8rVC7a+afmKC7+mQd5yMEFg+7EglPe1u1mI7YyhL6Z3
G1ihIpbTUyjeE60/8epFHtOg38/5NA==
=inUI
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2017-11-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
Driver Changes:
- qxl: Use a shadow bo as primary and blit to it to fix flicker (Gerd)
* tag 'drm-misc-fixes-2017-11-02' of git://anongit.freedesktop.org/drm/drm-misc:
qxl: alloc & use shadow for dumb buffers
drm/qxl: replace QXL_INFO with DRM_DEBUG_DRIVER
Until Haswell/Baytrail, the hardware used to have a per engine fault
register (e.g. 0x4094 - render fault register, 0x4194 - media fault
register and so on). But since Broadwell, all these registers were
combined into a singe one and the engine id stored in bits 14:12.
Not only we should not been reading (and writing to) registers that do
not exist, in platforms with VCS2 (SKL), the address that would belong
this engine (0x4494, VCS2_HW = 4) is already assigned to other register.
v2: use less controversial function names (Chris).
v3: make non-exported functions static, remove now obsolete check for
engine presence before posting_read (Chris).
References: IHD-OS-BDW-Vol 2c-11.15, page 75.
References: IHD-OS-SKL-Vol 2c-05.16, page 350.
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113173628.11689-1-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
From gen6, the hardware tracks address lookup failures and we should
clear those registers upon startup to prevent false positives. However,
this was happening before we have the engines defined (intel_uncore_init())
and the for_each_engine loop was just a nop. The earliest we can call
this is inside intel_engines_init_mmio().
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171111004448.12360-1-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We use to have this fixed per generation, but starting with CNL userspace
cannot tell just off the PCI ID. Let's make this information available. This
is particularly useful for performance monitoring where much of the
normalization work is done using those timestamps (this include pipeline
statistics in both GL & Vulkan as well as OA reports).
v2: Use variables for 24MHz/19.2MHz values (Ewelina)
Renamed function & coding style (Sagar)
v3: Fix frequency read on Broadwell (Sagar)
Fix missing divide by 4 on <= gen4 (Sagar)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110190845.32574-7-lionel.g.landwerlin@intel.com
This name was added with the whitelisting of registers for building up OA
configs. It is contained in a range gen8 whitelist :
addr >= RPM_CONFIG0.reg && addr <= NOA_CONFIG(8).reg
Hence why the name isn't used anywhere.
v2: Fix register name again RPC->RCP (Matthew)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110190845.32574-5-lionel.g.landwerlin@intel.com
Some parameters use CHECK_BOOL, but should really use
CHECK_BOOL_INCOMPLETE. We cannot currently check whether
the inherited infoframes and audio are set up correctly.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110113503.16253-4-maarten.lankhorst@linux.intel.com
[mlankhorst: Add danvet's comment about why this is needed.]
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The flag just tells us IPS can be enabled, if the primary plane
is not enabled it means IPS might not be. This never triggered
in CI because we don't have a haswell ULT there, but can be
reproduced easily with kms_atomic_transitions.plane-all-modeset-transition
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110113503.16253-2-maarten.lankhorst@linux.intel.com
[mlankhorst: Remove from haswell_get_pipe_config too. (danvet)]
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GEN8_CONFIG0 (0xD00) is a protected by a lock (bit 31) which is set by
the BIOS, so there is no way we can enable the three chicken bits
mandated by the WA (the BIOS should be doing it instead).
v2: Rebased
v3: Standalone patch
References: b033bb6d5d ("drm/i915/gen9: Enable must set chicken bits in config0 reg")
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510185589-9100-2-git-send-email-oscar.mateo@intel.com
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>