On Mon, Mar 13, 2017 at 12:08:19PM +0100, Maarten Lankhorst wrote:
> Op 13-03-17 om 11:15 schreef Daniel Vetter:
> > On Thu, Mar 09, 2017 at 03:52:04PM +0100, Maarten Lankhorst wrote:
> >> Add a big fat warning in __intel_display_resume that the old state is
> >> invalid, and use the correct state
== Series Details ==
Series: drm/i915: get a runtime PM ref in i915_wedged_set
URL : https://patchwork.freedesktop.org/series/21184/
State : success
== Summary ==
Series 21184v1 drm/i915: get a runtime PM ref in i915_wedged_set
https://patchwork.freedesktop.org/api/1.0/series/21184/revisions/1
At least in bxt (with decoupled mmio), it prevents a warning while
capturing the reg state:
[ ] WARNING: assert_rpm_wakelock_held.part.4+0x1e/0x20 [i915]
[ ] RPM wakelock ref not held during HW access
[ ] Call Trace:
[ ] dump_stack+0x63/0x87
[ ] __warn+0xd1/0xf0
[ ] ? fwtable_write3
On Mon, Mar 13, 2017 at 10:53:23PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Apparently some DP sinks are a little nuts and cause HPD to drop
> intermittently during modesets. This happens eg. on an ASUS PB287Q.
> In oder to recover from this we can't really use the pr
I am writing regarding this kernel patch: https://git.kernel.org/pub/sc
m/linux/kernel/git/stable/stable-queue.git/tree/releases/4.9.9/drm-
i915-execlists-reset-ring-registers-upon-resume.patch .
I have identified this by bisect to be the cause of a suspend and
resume issue. Please see https://git
== Series Details ==
Series: drm/i915: Fix DisplayPort Hotplug (rev3)
URL : https://patchwork.freedesktop.org/series/19601/
State : success
== Summary ==
Series 19601v3 drm/i915: Fix DisplayPort Hotplug
https://patchwork.freedesktop.org/api/1.0/series/19601/revisions/3/mbox/
fi-bdw-5557u
On 10/03/17 08:28, Oscar Mateo wrote:
While at it, fix a typo (s/ring_lcra/ring_lrca) and improve the naming of one
firware interface field (s/ring_tail/submit_element_info, since it can contain
more than just the ring tail).
No change in functionality.
Signed-off-by: Oscar Mateo
---
driver
On Mon, Mar 13, 2017 at 06:14:56PM +0200, Jani Nikula wrote:
> 1f7b847d72c3 ("drm/i915: Disable engine->irq_tasklet around resets")
Done.
> 370a81fb89cb ("drm/i915: Remove unused function intel_ddi_get_link_dpll()")
Don't bother, just code tidy?
> 262fd485ac6b ("drm/i915: Only enable hotplug inte
On Mon, Mar 13, 2017 at 10:53:23PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Apparently some DP sinks are a little nuts and cause HPD to drop
> intermittently during modesets. This happens eg. on an ASUS PB287Q.
> In oder to recover from this we can't really use the pr
== Series Details ==
Series: Revert "drm/i915: Ignore panel type from OpRegion on SKL"
URL : https://patchwork.freedesktop.org/series/20912/
State : success
== Summary ==
Series 20912v1 Revert "drm/i915: Ignore panel type from OpRegion on SKL"
https://patchwork.freedesktop.org/api/1.0/series/2
On 10/03/17 08:28, Oscar Mateo wrote:
Prepare for an alternate GuC communication interface.
v2: Make a few functions static and name them correctly while we are at it
(Oscar), but
leave an intel_guc_send_mmio interface for users that require old-style
communication.
v3: Send intel_uc_init_e
From: Ville Syrjälä
Apparently some DP sinks are a little nuts and cause HPD to drop
intermittently during modesets. This happens eg. on an ASUS PB287Q.
In oder to recover from this we can't really use the previous
connector status to determine if the link needs retraining, so let's
just ignore t
On 10/03/17 08:28, Oscar Mateo wrote:
Started adding proper teardown to guc_client_alloc, ended up removing
quite a few dead ends where errors communicating with the GuC were
silently ignored. There also seemed to be quite a few erronous
teardown actions performed in case of an error (ordering
On Wed, Mar 08, 2017 at 03:12:57PM +0100, Daniel Vetter wrote:
> Sadly there's only 1 driver which can use it, everyone else is special
> for some reason:
>
> - gma500 has a horrible runtime PM ioctl wrapper that probably doesn't
> really work but meh.
> - i915 needs special compat_ioctl handler
On Mon, Mar 13, 2017 at 03:31:40PM -0400, Sean Paul wrote:
> On Wed, Mar 08, 2017 at 03:12:56PM +0100, Daniel Vetter wrote:
> > Less code ftw.
> >
> > This converts all drivers except the tinydrm helper module. That one
> > needs more work, since it gets the THIS_MODULE reference from
> > tinydrm.
On Wed, Mar 08, 2017 at 03:12:56PM +0100, Daniel Vetter wrote:
> Less code ftw.
>
> This converts all drivers except the tinydrm helper module. That one
> needs more work, since it gets the THIS_MODULE reference from
> tinydrm.ko instead of the actual driver module like it should.
> Probably needs
On Wed, Mar 08, 2017 at 03:12:55PM +0100, Daniel Vetter wrote:
> With all drivers converted there's only legacy dri1 drivers using it.
> Not going to touch those, instead just hide it like we've done with
> other dri1 driver hooks like firstopen.
>
> In all this I didn't find any real reason why w
On Wed, Mar 08, 2017 at 03:12:54PM +0100, Daniel Vetter wrote:
> The core takes care of handling the send_event vs. close() issues, we
> can remove that driver code.
>
> Cc: Rob Clark
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Signed-off-by: Daniel Vetter
> ---
>
On Fri, Mar 10, 2017 at 12:07:53PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 09, 2017 at 09:26:36PM +, Chris Wilson wrote:
> > On Thu, Mar 09, 2017 at 05:44:34PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Use I915_{READ,WRITE}_FW() for updating the
On Wed, Mar 08, 2017 at 03:12:53PM +0100, Daniel Vetter wrote:
> Again no apparent explanation for the split except hysterical raisins.
> Merging them also makes it a bit more obviuos what's going on wrt the
> runtime pm refdancing.
Commit message copypasta.
The code is
Reviewed-by: Sean Paul
On Wed, Mar 08, 2017 at 03:12:50PM +0100, Daniel Vetter wrote:
> I didn't spot anything that would require ordering here (well not
> anywhere else either), and I'm trying to unify at least modern drivers
> on one close hook.
>
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
Reviewed-by: Sean
On Wed, Mar 08, 2017 at 03:12:49PM +0100, Daniel Vetter wrote:
> I didn't spot anything that would require ordering here (well not
> anywhere else either), and I'm trying to unify at least modern drivers
> on one close hook.
>
> Cc: Thierry Reding
> Cc: linux-te...@vger.kernel.org
> Signed-off-by
On Wed, Mar 08, 2017 at 03:12:47PM +0100, Daniel Vetter wrote:
> Again no apparent explanation for the split except hysterical raisins.
> Merging them also makes it a bit more obviuos what's going on wrt the
> runtime pm refdancing.
Yeah, holding the pm reference from preclose to postclose had me
On Wed, Mar 08, 2017 at 03:12:46PM +0100, Daniel Vetter wrote:
> I didn't spot anything that would require ordering here (well not
> anywhere else either), and I'm trying to unify at least modern drivers
> on one close hook.
>
> Cc: Rob Clark
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@li
On Wed, Mar 08, 2017 at 03:12:44PM +0100, Daniel Vetter wrote:
> Well, mostly drm_file.h, and clean up all related things:
>
> - I didnt' figure out the difference between preclose and postclose.
> The existing explanation in drm-internals.rst didn't convince me,
> since it's also really outda
== Series Details ==
Series: drm/i915: Optimize plane updates a bit
URL : https://patchwork.freedesktop.org/series/21002/
State : success
== Summary ==
Series 21002v1 drm/i915: Optimize plane updates a bit
https://patchwork.freedesktop.org/api/1.0/series/21002/revisions/1/mbox/
Test gem_exec_
Op 13-03-17 om 17:44 schreef Ville Syrjälä:
> On Mon, Mar 13, 2017 at 05:35:42PM +0100, Maarten Lankhorst wrote:
>> Op 13-03-17 om 17:22 schreef Ville Syrjälä:
>>> On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote:
As a proof of concept, first try to convert intel_tv, which is
From: Kenneth Graunke
This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0
(indicating the optional feature is not supported), and makes execbuf
always return -EINVAL if the flags are used.
Apparently, no userspace ever shipped which used this optional feature:
I checked the git
On Wed, Mar 08, 2017 at 03:12:43PM +0100, Daniel Vetter wrote:
> We might as well dump the drm_file pointer, that's about as useful
> a cookie as the pid. Noticed while typing docs for drm_file and friends.
>
> Since the only consumer of this is the tracepoints I think we can safely
> change this
On Wed, Mar 08, 2017 at 03:12:56PM +0100, Daniel Vetter wrote:
> Less code ftw.
>
> This converts all drivers except the tinydrm helper module. That one
> needs more work, since it gets the THIS_MODULE reference from
> tinydrm.ko instead of the actual driver module like it should.
> Probably needs
On Baytrail, we manually calculate busyness over the evaluation interval
to avoid issues with miscaluations with RC6 enabled. However, it turns
out that the DOWN_EI interrupt generator is completely bust - it
operates in two modes, continuous or never. Neither of which are
conducive to good behavio
In order to prevent accessing the hpd registers outside of the display
power wells, we should refrain from writing to the registers before the
display interrupts are enabled.
[4.740136] WARNING: CPU: 1 PID: 221 at
drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x44/0x50 [i915]
When we restart the engines, and we have active requests, a request on
the first engine may complete and queue a request to the second engine
before we try to restart the second engine. That queueing of the
request may race with the engine to restart, and so may corrupt the
current state. Disabling
Currently we do a reset prepare/finish around the call to reset the GPU,
but it looks like we need a later stage after the hw has been
reinitialised to allow GEM to restart itself. Start by splitting the 2
GEM phases into 3:
prepare - before the reset, check if GEM recovered, then stop GEM
re
On 03/13/2017 04:49 AM, Chris Wilson wrote:
On Fri, Mar 10, 2017 at 08:28:57AM -0800, Oscar Mateo wrote:
A GuC context and a HW context are in no way related, so the name "GuC context
descriptor"
is very unfortunate, because a new reader of the code gets overwhelmed very
quickly with
a lot o
On Wed, Mar 08, 2017 at 03:12:41PM +0100, Daniel Vetter wrote:
> This was originally added by David Herrmann for range checks, but
> entirely unused. It confused me, so let's remove it.
>
> Cc: David Herrmann
> Signed-off-by: Daniel Vetter
Reviewed-by: Sean Paul
> ---
> include/drm/drmP.h | 1
On 03/13/2017 04:46 AM, Chris Wilson wrote:
On Fri, Mar 10, 2017 at 08:28:55AM -0800, Oscar Mateo wrote:
Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go
to zero after updating db_status before we call the GuC to release the
doorbell.
Does this fix some of the '110' er
On Mon, Mar 13, 2017 at 05:35:42PM +0100, Maarten Lankhorst wrote:
> Op 13-03-17 om 17:22 schreef Ville Syrjälä:
> > On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote:
> >> As a proof of concept, first try to convert intel_tv, which is a rarely
> >> used connector. It has 5 properti
Op 13-03-17 om 17:22 schreef Ville Syrjälä:
> On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote:
>> As a proof of concept, first try to convert intel_tv, which is a rarely
>> used connector. It has 5 properties, tv format and 4 margins.
>>
>> I'm less certain about the state behavio
On Wed, Mar 08, 2017 at 03:12:35PM +0100, Daniel Vetter wrote:
> Plus a little bit more documentation.
>
> v2: Untangle the missing forward decls to make drm_prime|gem.h
> free-standing.
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-mm.rst | 3 ++
> drivers/gpu/drm/drm_prime.
Op 13-03-17 om 17:22 schreef Ville Syrjälä:
> On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote:
>> As a proof of concept, first try to convert intel_tv, which is a rarely
>> used connector. It has 5 properties, tv format and 4 margins.
>>
>> I'm less certain about the state behavio
On Mon, Mar 13, 2017 at 11:55:31AM +0200, Jani Nikula wrote:
> On Sat, 11 Mar 2017, Manasi Navare wrote:
> > On Fri, Mar 10, 2017 at 03:27:58PM +0200, Jani Nikula wrote:
> >> The main thing are the DDI ports. If there's a VBT that says there are
> >> no outputs, we should trust that, and not have
On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote:
> As a proof of concept, first try to convert intel_tv, which is a rarely
> used connector. It has 5 properties, tv format and 4 margins.
>
> I'm less certain about the state behavior itself, should we pass a size
> parameter to in
I'm already scripting my fixes backports quite a bit, and frankly don't
really manually backport anything that doesn't apply cleanly. I'm
thinking of automating some "failed to backport" reporting to authors,
not unlike the failed stable backport reports.
This is a manual report that the followin
As a proof of concept, first try to convert intel_tv, which is a rarely
used connector. It has 5 properties, tv format and 4 margins.
I'm less certain about the state behavior itself, should we pass a size
parameter to intel_connector_alloc instead, so duplicate_state
can be done globally if it ca
On Mon, Mar 13, 2017 at 01:09:10PM +0200, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/13/2017 12:53 PM, Ville Syrjälä wrote:
> > On Mon, Mar 13, 2017 at 12:22:53PM +0200, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>> From: Ville Syrjälä
> >>>
> >>> Check that
On Mon, Mar 13, 2017 at 04:29:47PM +0200, Petri Latvala wrote:
> On Mon, Mar 13, 2017 at 02:15:34PM +, Chris Wilson wrote:
> > On Mon, Mar 13, 2017 at 01:02:04PM +0200, Petri Latvala wrote:
> > > On Mon, Mar 13, 2017 at 10:50:04AM +, Chris Wilson wrote:
> > > > Still completely lacking just
For the record, I pushed this series so I could get the IGT release
out. I'm sure there are various ways this functionality can be
improved, so constructive suggestions are still definitely welcome.
--
Petri Latvala
___
Intel-gfx mailing list
Intel-gf
A new intel-gpu-tools quarterly release is available with the
following changes:
Library changes:
- Various changes to library functions so that they don't assume Intel
hardware. (Lyude)
- Added helper functions for managing synchronization primitives.
(Robert Foss)
- Added support for the
On Mon, Mar 13, 2017 at 10:17:25AM +0530, Kamble, Sagar A wrote:
> LGTM.
> Reviewed-by: Sagar Arun Kamble [1]
Thanks, pushed
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https:
On Mon, Mar 13, 2017 at 11:06:20AM +0200, Joonas Lahtinen wrote:
> On pe, 2017-03-10 at 00:09 +, Chris Wilson wrote:
> > If the object is coherent, we can simply update the cache domain on the
> > whole object rather than calculate the before/after clflushes. The
> > advantage is that we then g
On Mon, Mar 13, 2017 at 10:33:35AM +, Matthew Auld wrote:
> On 13 March 2017 at 10:07, Chris Wilson wrote:
> > The patch 6e32ab3d4777: "drm/i915: Fill different pages of the GTT"
> > from Feb 13, 2017, leads to the following static checker warning:
> >
> > drivers/gpu/drm/i915/selftest
On Mon, Mar 13, 2017 at 02:15:34PM +, Chris Wilson wrote:
> On Mon, Mar 13, 2017 at 01:02:04PM +0200, Petri Latvala wrote:
> > On Mon, Mar 13, 2017 at 10:50:04AM +, Chris Wilson wrote:
> > > Still completely lacking justification. The above is a non sequitur;
> > > static testlist generatio
On Mon, Mar 13, 2017 at 12:54:15PM +, Tvrtko Ursulin wrote:
>
> On 13/03/2017 12:47, Chris Wilson wrote:
> >The patch 791ff39ae32a: "drm/i915: Live testing for context
> >execution" from Feb 13, 2017, leads to the following static checker
> >warning:
> >
> >drivers/gpu/drm/i915/selftes
On Mon, Mar 13, 2017 at 01:24:41PM +, Chris Wilson wrote:
> On Mon, Mar 13, 2017 at 03:15:32PM +0200, Mika Kuoppala wrote:
> > Chris Wilson writes:
> >
> > > gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the
> > > object code.
> > >
> > > Signed-off-by: Chris Wilson
>
On Mon, Mar 13, 2017 at 03:41:34PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > i915_drpc_info missed covering a few register read with the runtime pm
> > wakelock. Be simple and cover the entire function with a single wakelock
> > so that new additions are not similarly missed in fut
Hi Jani
you are right, your weird(!) recommendation has worked!
Thanks for your help..
On 13-03-2017 13:45, Jani Nikula wrote:
On Mon, 13 Mar 2017, "M. selcuk karaca" wrote:
we have "HP ProOne 600 G2 21.5-in Touch AiO" PC, equipped with "Intel
HD Graphics 530" graphics card
We are using
On Mon, Mar 13, 2017 at 01:02:04PM +0200, Petri Latvala wrote:
> On Mon, Mar 13, 2017 at 10:50:04AM +, Chris Wilson wrote:
> > Still completely lacking justification. The above is a non sequitur;
> > static testlist generation can be done just from the source.
>
> Static testlist generation ca
On Mon, Mar 13, 2017 at 03:41:34PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > i915_drpc_info missed covering a few register read with the runtime pm
> > wakelock. Be simple and cover the entire function with a single wakelock
> > so that new additions are not similarly missed in fut
On 13/03/2017 13:48, Arkadiusz Hiler wrote:
On Mon, Mar 13, 2017 at 01:39:45PM +, Tvrtko Ursulin wrote:
On 13/03/2017 13:15, Arkadiusz Hiler wrote:
Currently fw->path values can represent one of three possible states:
1) NULL - device without the uC
2) '\0' - device with the uC but hav
== Series Details ==
Series: GuC Scrub vol. 1 (rev12)
URL : https://patchwork.freedesktop.org/series/16856/
State : failure
== Summary ==
Series 16856v12 GuC Scrub vol. 1
https://patchwork.freedesktop.org/api/1.0/series/16856/revisions/12/mbox/
Test drv_module_reload:
Subgroup basic-r
On Mon, Mar 13, 2017 at 01:39:45PM +, Tvrtko Ursulin wrote:
>
> On 13/03/2017 13:15, Arkadiusz Hiler wrote:
> > Currently fw->path values can represent one of three possible states:
> >
> > 1) NULL - device without the uC
> > 2) '\0' - device with the uC but have no firmware
> > 3) else -
On Sun, Mar 12, 2017 at 06:19:17PM +0100, David Weinehall wrote:
> On Sun, Mar 12, 2017 at 01:21:12PM +, Chris Wilson wrote:
> > On Fri, Mar 10, 2017 at 05:14:32PM -0800, Kenneth Graunke wrote:
> > > On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has
> > > had the surprising beha
Chris Wilson writes:
> i915_drpc_info missed covering a few register read with the runtime pm
> wakelock. Be simple and cover the entire function with a single wakelock
> so that new additions are not similarly missed in future.
>
> WARNING: CPU: 2 PID: 1334 at drivers/gpu/drm/i915/intel_drv.h:
On 13/03/2017 13:15, Arkadiusz Hiler wrote:
Currently fw->path values can represent one of three possible states:
1) NULL - device without the uC
2) '\0' - device with the uC but have no firmware
3) else - device with the uC and we have firmware
Second case is used only to WARN at a later s
On Fri, Mar 10, 2017 at 10:22:38AM +0800, Zhenyu Wang wrote:
> From commit a6508ded2a66 ("drm/i915: Use page coloring to provide the guard
> page at the end of the GTT"), we no longer explicitly subtract guard page
> at end for GGTT address space init, so shouldn't subtract that for vGPU
> balloon
On Fri, Mar 10, 2017 at 08:28:50AM -0800, Oscar Mateo wrote:
> Starting with intel_guc_loader, down to intel_guc_submission
> and finally to intel_guc_log.
>
> v2:
> - Null execbuf client outside guc_client_free (Daniele)
> - Assert if things try to get allocated twice (Daniele/Joonas)
> - N
On Mon, Mar 13, 2017 at 03:15:32PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the
> > object code.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 5
== Series Details ==
Series: drm/i915/selftests: Catch error from mock_file()
URL : https://patchwork.freedesktop.org/series/21156/
State : success
== Summary ==
Series 21156v1 drm/i915/selftests: Catch error from mock_file()
https://patchwork.freedesktop.org/api/1.0/series/21156/revisions/1/m
Chris Wilson writes:
> gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the
> object code.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_irq.c | 5 -
> drivers/gpu/drm/i915/intel_drv.h | 8 +++-
> 2 files changed, 7 insertio
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e36..9dcc8a0 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@
Currently fw->path values can represent one of three possible states:
1) NULL - device without the uC
2) '\0' - device with the uC but have no firmware
3) else - device with the uC and we have firmware
Second case is used only to WARN at a later stage.
We can WARN right away and merge cases 1
intel_{h,g}uc_init_fw selects correct firmware and then triggers it's
preparation (fetch + initial parsing).
This change separates out select steps, so those can be called by
the sanitize_options().
Then, during the init_fw(), we prepare the firmware if the firmware was
selected.
Cc: Michal Wini
Let intel_guc_init_fw() focus on determining and fetching the correct
firmware.
This patch introduces intel_uc_sanitize_options() that is called from
intel_sanitize_options().
Then, if we have GuC, we can call intel_guc_init_fw() conditionally
and we do not have to do the internal checks.
v2: fi
The file fits better.
Additionally rename it to intel_uc_prepare_fw(), as the function does
more than simple fetch.
`obj` cleanup in the function is also fixed (i.e. removed). In the fail
scenario it was always 'put' but there's no possible flow that
initializes the obj properly and then goes to
`guc_firmware_path` and `huc_firmware_path` module parameters are added.
Using the parameter disables version checks and loads desired firmware
instead of the default one.
v2: make params unsafe && notice about disabled fw check (J. Lahtinen)
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michal Win
Current version of intel_guc_init_hw() does a lot:
- cares about submission
- loads huc
- implement WA
This change offloads some of the logic to intel_uc_init_hw(), which now
cares about the above.
v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko)
v3: rename once again
v4: rem
Instead of calling intel_guc_init() and intel_huc_init() one by one this
patch introduces intel_uc_init_fw() function that calls them both.
Called functions are renamed accordingly.
Trying to have subject_verb_object ordering and more descriptive names,
the intel_huc_init() and intel_guc_init() f
Reasoning
=
General GuC/HuC cleanup simplifying logic and moving chunks around as the area
got pretty rusty.
This is the first part of effort to clean it up.
A lot of logic were extracted from intel_guc_load() to other functions - it did
not only handle the actual loading but had WA impl
Used to obtain "dev_priv" from huc struct pointer.
We already have similar thing for guc.
Cc: Michal Wajdeczko
Signed-off-by: Arkadiusz Hiler
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv
Externs are implicit and we generally try to avoid them.
Cc: Michal Wajdeczko
Signed-off-by: Arkadiusz Hiler
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_uc.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drive
GuC historically has two "startup" functions called _init() and _setup()
Then HuC came with it's _init() and _load().
This commit renames intel_guc_setup() and intel_huc_load() to
*uc_init_hw() as they called from the i915_gem_init_hw().
The aim is to be consistent in that entry points called du
On Mon, Mar 13, 2017 at 03:04:21PM +0200, Jani Nikula wrote:
> On Mon, 13 Mar 2017, Chris Wilson wrote:
> > To improve our historical record and to simplify userspace that wants to
> > include i915_pciids.h as its canonical breakdown of PCI IDs and their
> > respective generations, include the gen
On Mon, 13 Mar 2017, Chris Wilson wrote:
> To improve our historical record and to simplify userspace that wants to
> include i915_pciids.h as its canonical breakdown of PCI IDs and their
> respective generations, include the gen1 ids for i810 and i815.
Is this how you start sneaking in support f
On 13/03/2017 12:47, Chris Wilson wrote:
The patch 791ff39ae32a: "drm/i915: Live testing for context
execution" from Feb 13, 2017, leads to the following static checker
warning:
drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec()
error: 'file' dereferencing poss
== Series Details ==
Series: drm/i915: Add i810/i815 pci-ids for completeness
URL : https://patchwork.freedesktop.org/series/21149/
State : failure
== Summary ==
Series 21149v1 drm/i915: Add i810/i815 pci-ids for completeness
https://patchwork.freedesktop.org/api/1.0/series/21149/revisions/1/m
The patch 791ff39ae32a: "drm/i915: Live testing for context
execution" from Feb 13, 2017, leads to the following static checker
warning:
drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec()
error: 'file' dereferencing possible ERR_PTR()
Reported-by: Dan Carpenter
On Mon, Mar 13, 2017 at 03:34:29PM +0300, Dan Carpenter wrote:
> Hello Chris Wilson,
>
> The patch 791ff39ae32a: "drm/i915: Live testing for context
> execution" from Feb 13, 2017, leads to the following static checker
> warning:
>
> drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt
On Fri, Mar 10, 2017 at 01:11:06PM +0100, Michal Wajdeczko wrote:
> On Fri, Mar 10, 2017 at 12:46:06PM +0100, Arkadiusz Hiler wrote:
> > Current version of intel_guc_init_hw() does a lot:
> > - cares about submission
> > - loads huc
> > - implement WA
> >
> > This change offloads some of the lo
Hello Chris Wilson,
The patch 791ff39ae32a: "drm/i915: Live testing for context
execution" from Feb 13, 2017, leads to the following static checker
warning:
drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec()
error: 'file' dereferencing possible ERR_PTR()
drivers
Op 13-03-17 om 11:55 schreef Ville Syrjälä:
> On Mon, Mar 13, 2017 at 11:38:33AM +0100, Maarten Lankhorst wrote:
>> Op 13-03-17 om 10:29 schreef Ville Syrjälä:
>>> On Mon, Mar 13, 2017 at 10:22:51AM +0100, Maarten Lankhorst wrote:
Op 09-03-17 om 18:36 schreef Ville Syrjälä:
> On Thu, Mar 0
== Series Details ==
Series: HDMI 2.0: Scrambling in DRM layer (rev10)
URL : https://patchwork.freedesktop.org/series/19161/
State : success
== Summary ==
Series 19161v10 HDMI 2.0: Scrambling in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/19161/revisions/10/mbox/
Test gvt_basic
On Fri, Mar 10, 2017 at 08:28:57AM -0800, Oscar Mateo wrote:
> A GuC context and a HW context are in no way related, so the name "GuC
> context descriptor"
> is very unfortunate, because a new reader of the code gets overwhelmed very
> quickly with
> a lot of things called "context" that refer to
On Fri, Mar 10, 2017 at 08:28:55AM -0800, Oscar Mateo wrote:
> Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go
> to zero after updating db_status before we call the GuC to release the
> doorbell.
Does this fix some of the '110' errors?
-Chris
--
Chris Wilson, Intel Open
To improve our historical record and to simplify userspace that wants to
include i915_pciids.h as its canonical breakdown of PCI IDs and their
respective generations, include the gen1 ids for i810 and i815.
Signed-off-by: Chris Wilson
---
include/drm/i915_pciids.h | 8
1 file changed, 8
Signed-off-by: Petri Latvala
---
Marius has stepped down from being a maintainer a while ago, it's time
to make the file match reality.
I'd like to take this opportunity to thank Marius for his work and
wish him the best in his new endeavours.
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
== Series Details ==
Series: drm/i915/selftests: Fix error path for ggtt walk_hole()
URL : https://patchwork.freedesktop.org/series/21140/
State : success
== Summary ==
Series 21140v1 drm/i915/selftests: Fix error path for ggtt walk_hole()
https://patchwork.freedesktop.org/api/1.0/series/21140
Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.
V2: rebase
V3: rebase
V4: added r-b from Ander
V5: rebase
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
Cc: Ander Conselvan De Oliveira
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
V
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
1 - 100 of 164 matches
Mail list logo
