- 16 Nov, 2017 13 commits
-
-
Rodrigo Vivi authored
- 64 bits is not needed for afe_clock now we don't convert that to Hz. - 16 bits is not enough for all dco stuff. - unsigned is not relevant/needed for all divisors values. Cc: Mika Kahola <mika.kahola@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20171114194759.24541-4-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
No functional change. Just starting the wrpll fixes with a clean-up to make units a bit more clear. Cc: Mika Kahola <mika.kahola@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114194759.24541-3-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
"Display software must leave this field at the default value. It no longer needs to be configured as part of PLL programming." We respect this already and we are setting up the default one line below: "DPLL_CFGCR1_CENTRAL_FREQ". Also we don't touch anywhere else this central_freq for cnl. So let's remove from the final write. No functional change. Only a clean-up patch. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114194759.24541-2-rodrigo.vivi@intel.com
-
Chris Wilson authored
When operating on the live_ggtt we have to find a usuable hole for our test. It is possible for there to be no hole we can use, so initialise the err to 0 for the early exit. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171115152558.31252-1-chris@chris-wilson.co.ukReviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Ville Syrjälä authored
Avoid touching PIPECONF in intel_sanitize_crtc() unless the pipe is actually on. Should cure some unclaimed register accesses during reset, as we are rather cavalier in our approach to powerdomain management. We don't have to sanitize this if the pipe is off since we will overwrite the frame start delay anyway when turning the pipe on. v2: Amended commit message to implicate the reset path (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102249Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171115200442.15051-1-ville.syrjala@linux.intel.comReviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Sagar Arun Kamble authored
With all component structures and functions named appropriately, change the names of GuC submission source files. There were bunch of style issues in guc_submission.c that are highlighted now by checkpatch. Fix those. Update name in Documentation/gpu. (Joonas) v2: Rebase. v3: Rebase. 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-6-git-send-email-sagar.a.kamble@intel.comSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Sagar Arun Kamble authored
GuC submission clients are currently being used in kernel only hence update the structure name to intel_guc_client. 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-5-git-send-email-sagar.a.kamble@intel.comSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Sagar Arun Kamble authored
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.comSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Sagar Arun Kamble authored
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.comSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Sagar Arun Kamble authored
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.comSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
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.ukReviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Chris Wilson authored
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: 9eb143bb ("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.ukReviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Mika Kuoppala authored
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
-
- 15 Nov, 2017 12 commits
-
-
Chris Wilson authored
WaEnablePooledEuFor2x6 only applies to preproduction models, unsupported since commit 0102ba1f ("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.ukReviewed-by: David Weinehall <david.weinehall@linux.intel.com>
-
Chris Wilson authored
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
-
Chris Wilson authored
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
-
Chris Wilson authored
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.ukReviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Chris Wilson authored
Silence sparse warnings by using __iomem markup and io accessors. 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/20171114191842.19063-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
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.comAcked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
-
Ville Syrjälä authored
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.comReviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
-
Ville Syrjälä authored
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.comReviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
-
Ville Syrjälä authored
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.comReviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
-
Hans de Goede authored
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
-
Hans de Goede authored
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
-
Hans de Goede authored
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
-
- 14 Nov, 2017 14 commits
-
-
Chris Wilson authored
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.ukReviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
-
Chris Wilson authored
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: 37cd3300 ("drm/i915: Remove redundant intel_autoenable_gt_powersave()") References: a1c41994 ("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.ukReviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
-
Rodrigo Vivi authored
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
-
Rodrigo Vivi authored
Catchup with upstream. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Chris Wilson authored
Having removed the preproduction Broxton support (see commit 0102ba1f ("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
-
Chris Wilson authored
We've begun excluding pre-production Broxton machines since commit 0102ba1f ("drm/i915: Add early BXT sdv to the list of preproduction machines"), now remove the list of workaround register values for those early machines. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170927093325.24206-1-chris@chris-wilson.co.ukReviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114134340.5439-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
gem_workarounds reports that the SLICE_UNIT_LEVEL_CLKGATE write isn't sticking. Commit 0a60797a ("drm/i915: Implement ReadHitWriteOnlyDisable.") presumes that SLICE_UNIT_LEVEL_CLKGATE is a masked register in the context image, but commit 90007bca ("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: 0a60797a ("drm/i915: Implement ReadHitWriteOnlyDisable.") References: 90007bca ("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.ukReviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
-
Lionel Landwerlin authored
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: dab91783 ("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.comReviewed-by: Ewelina Musial <ewelina.musial@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Mika Kahola authored
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.comSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
-
James Ausmus authored
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.comSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Tina Zhang authored
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.comSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171114102513.22269-2-chris@chris-wilson.co.uk
-
Tina Zhang authored
-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.comReviewed-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
-
Lucas De Marchi authored
Commit 78597996 (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
-
Dave Airlie authored
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
-
- 13 Nov, 2017 1 commit
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
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
-