Since extracting the reset wakeup into a independent waitqueue, we only
need to consider the possibility of there being an outstanding
breadcrumb interrupt when advancing onto the next waiter. Both paths can
now use the same code, so refactor it to a common function.
Signed-off-by: Chris Wilson
-
On Thu, Mar 02, 2017 at 11:02:11PM +, Chris Wilson wrote:
> Whenever we advance from one completed waiter to the next, give it a
> kick so that it can check to see if its seqno completed during the
> switch. We used to rely on faking an interrupt to determine when the
> wake up was required, bu
== Series Details ==
Series: HDMI 2.0: Scrambling in DRM layer (rev6)
URL : https://patchwork.freedesktop.org/series/19161/
State : success
== Summary ==
Series 19161v6 HDMI 2.0: Scrambling in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/19161/revisions/6/mbox/
Test drv_module_r
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
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
Reviewed-by:
HDMI 2.0 spec defines a method to reduce the RF footprint while
operating at higher pixel clocks, which is called Scrambling.
Scrambling can be controlled over a new set of I2C registers
which are accessible over existing DDC I2C lines, called SCDC
register set.
This patch series contains 6 patche
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
V2: Rebase.
V3: Added
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
From: Thierry Reding
This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.
V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
V6: Rebase
Signed-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
Reviewed-by: Jose Abreu
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
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
that depends on whether native can accept this log level degraded.
let's see if there another opinions from community~
-Original Message-
From: Wang, Zhi A
Sent: Friday, March 03, 2017 10:56 AM
To: Niu, Bing ; intel-gfx@lists.freedesktop.org
Cc: Lv, Zhiyuan
Subject: Re: [Intel-gfx][PATC
== Series Details ==
Series: drm/i915: suppress atomic commit error message under gvt-g env
URL : https://patchwork.freedesktop.org/series/20600/
State : warning
== Summary ==
Series 20600v1 drm/i915: suppress atomic commit error message under gvt-g env
https://patchwork.freedesktop.org/api/1.
Can we directly use DRM_DEBUG_KMS() for this periodic error message?
On 03/03/17 19:53, bing@intel.com wrote:
From: Bing Niu
under virtualization enviroment, it is possible guest update pipe
registers across vblank intervals due to overhead of mmio traps or vm
schedule out. However, it is
From: Bing Niu
under virtualization enviroment, it is possible guest update pipe
registers across vblank intervals due to overhead of mmio traps or vm
schedule out. However, it is safe since those pipe update happen in
virual registers and will not be committed to hardware. suppress that
atomic c
error is irrelevant . but will resend a patch to correct commit message
this patch just suppresses one error message under virtualization environment,
not functionality change.
and below error already happen in previous testing and has a bug tracking that.
-Original Message-
From: Patch
The intent of the test is to provide an incorrect input to a command.
Since the driver doesn't do any command validation, this test is removed
as non applicable.
Signed-off-by: Antonio Argenziano
---
tests/Makefile.sources | 1 -
tests/gem_bad_address.c | 75 ---
== Series Details ==
Series: drm/i915: Always wakeup the next breadcrumb waiter
URL : https://patchwork.freedesktop.org/series/20590/
State : success
== Summary ==
Series 20590v1 drm/i915: Always wakeup the next breadcrumb waiter
https://patchwork.freedesktop.org/api/1.0/series/20590/revisions
Whenever we advance from one completed waiter to the next, give it a
kick so that it can check to see if its seqno completed during the
switch. We used to rely on faking an interrupt to determine when the
wake up was required, but now the irq should always be enabled and so no
longer receive the ki
On Thu, Mar 02, 2017 at 12:48:31PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Drop spinlocks around adding to the client request list
> URL : https://patchwork.freedesktop.org/series/20555/
> State : failure
>
> == Summary ==
>
> Series 20555v1 drm/i915: Drop spinlock
IRC acked by Harry Wentland
" dhnkrn, the patch for driver-private atomic state object
makes sense to me. Didn't realize that's the same one from early
February. Feel free to add my Acked-by"
-DK
On Wed, 2017-02-08 at 22:38 -0800, Dhinakaran Pandiyan wrote:
> It is necessary to track states fo
On Thu, Mar 02, 2017 at 09:01:06PM +, Chris Wilson wrote:
> Check timer_pending() as well as work_pending() to see if the timer for
> the hangcheck has already expired and the work is pending execution on
> some list somewhere.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> dri
Didn't spot anything wrong with this,
Reviewed-by: Dhinakaran Pandiyan
-DK
On Tue, 2017-02-21 at 18:23 -0300, Paulo Zanoni wrote:
> Move the {skl,bxt}_{i,uni}nit_cdclk declarations to the place where
> the intel_cdclk.c functions are declared since these functions have
> moved there.
>
> Sign
== Series Details ==
Series: drm/i915: Differentiate between hangcheck waiting for timer or scheduler
URL : https://patchwork.freedesktop.org/series/20585/
State : success
== Summary ==
Series 20585v1 drm/i915: Differentiate between hangcheck waiting for timer or
scheduler
https://patchwork.f
Check timer_pending() as well as work_pending() to see if the timer for
the hangcheck has already expired and the work is pending execution on
some list somewhere.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 -
1 file changed, 8 inserti
On Mon, Feb 20, 2017 at 05:00:40PM -0300, Paulo Zanoni wrote:
> There's a lot of duplicated platform-independent logic in the current
> modeset_calc_cdclk() functions. Adding cdclk support for more
> platforms will only add more copies of this code.
>
> To solve this problem, in this patch we crea
On Thu, 2017-03-02 at 21:20 +0200, Ville Syrjälä wrote:
> On Thu, Mar 02, 2017 at 11:15:29AM -0800, Rodrigo Vivi wrote:
> > No functional change. Just a proper organization of the gen9 workarounds.
> >
> > Cc: Imre Deak
> > Cc: Mika Kuoppala
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: Rodrig
On Mon, Feb 20, 2017 at 04:04:43PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently ILK-BDW explicitly disable LP1+ watermarks from their
> .init_clock_gating() hooks. Unfortunately that hook gets called way too
> late since by that time we've already initialized al
== Series Details ==
Series: drm/i915: Move bxt exclusive workarounds from gen9 func to bxt one.
URL : https://patchwork.freedesktop.org/series/20582/
State : success
== Summary ==
Series 20582v1 drm/i915: Move bxt exclusive workarounds from gen9 func to bxt
one.
https://patchwork.freedesktop
Bring the test/set/clear bit functions we have into a single place.
v2: Add gtk-doc comment blocks (Daniel)
v3: Restore inline keyword.
Cc: Daniel Vetter
Reviewed-by: Joonas Lahtinen (v1)
Signed-off-by: Michel Thierry
---
.../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 +
lib/Makefil
== Series Details ==
Series: drm/i915: Extend residency counter ranges on chv and byt
URL : https://patchwork.freedesktop.org/series/20578/
State : success
== Summary ==
Series 20578v1 drm/i915: Extend residency counter ranges on chv and byt
https://patchwork.freedesktop.org/api/1.0/series/205
On 01/03/17 23:45, Daniel Vetter wrote:
On Wed, Mar 01, 2017 at 04:14:31PM +, Chris Wilson wrote:
On Wed, Mar 01, 2017 at 07:52:26AM -0800, Michel Thierry wrote:
Bring the test/set/clear bit functions we have into a single place.
v2: Add gtk-doc comment blocks (Daniel)
Hiss, boo! Will s
On Thu, Mar 02, 2017 at 11:15:29AM -0800, Rodrigo Vivi wrote:
> No functional change. Just a proper organization of the gen9 workarounds.
>
> Cc: Imre Deak
> Cc: Mika Kuoppala
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 42
> ++
== Series Details ==
Series: drm/i915: VLV/CHV two-stage watermarks (rev3)
URL : https://patchwork.freedesktop.org/series/16712/
State : success
== Summary ==
Series 16712v3 drm/i915: VLV/CHV two-stage watermarks
https://patchwork.freedesktop.org/api/1.0/series/16712/revisions/3/mbox/
Test ge
No functional change. Just a proper organization of the gen9 workarounds.
Cc: Imre Deak
Cc: Mika Kuoppala
Cc: Dhinakaran Pandiyan
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_engine_cs.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
On Thu, Mar 02, 2017 at 06:21:37PM +, Chris Wilson wrote:
> On Thu, Mar 02, 2017 at 08:13:31PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote:
> > > We were passively acting on the high counter value bit
> > > and as it was never set, we were only
On Thu, Mar 02, 2017 at 04:18:05PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/guc: Disable irq for __i915_guc_submit wq_lock
> URL : https://patchwork.freedesktop.org/series/20564/
> State : success
>
> == Summary ==
>
> Series 20564v1 drm/i915/guc: Disable irq for __i
On Thu, Mar 02, 2017 at 06:02:09PM +, Patchwork wrote:
> == Series Details ==
>
> Series: GuC Scrub vol. 1 (rev8)
> URL : https://patchwork.freedesktop.org/series/16856/
> State : failure
>
> == Summary ==
>
> CC [M] drivers/gpu/drm/i915/gvt/execlist.o
> LD drivers/misc/built-in.
On Thu, Mar 02, 2017 at 08:20:24PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote:
> >> We were passively acting on the high counter value bit
> >> and as it was never set, we were only utilizing the
> >> the 32bits of resolu
On Thu, Mar 02, 2017 at 08:13:31PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote:
> > We were passively acting on the high counter value bit
> > and as it was never set, we were only utilizing the
> > the 32bits of resolution. As the divisor with these
Chris Wilson writes:
> On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote:
>> We were passively acting on the high counter value bit
>> and as it was never set, we were only utilizing the
>> the 32bits of resolution. As the divisor with these platforms
>> is quite high, the wrap around
Ville Syrjälä writes:
> On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote:
>> We were passively acting on the high counter value bit
>> and as it was never set, we were only utilizing the
>> the 32bits of resolution. As the divisor with these platforms
>> is quite high, the wrap aroun
On Thu, Mar 02, 2017 at 06:13:15PM +, Chris Wilson wrote:
> On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote:
> > We were passively acting on the high counter value bit
> > and as it was never set, we were only utilizing the
> > the 32bits of resolution. As the divisor with these p
On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote:
> We were passively acting on the high counter value bit
> and as it was never set, we were only utilizing the
> the 32bits of resolution. As the divisor with these platforms
> is quite high, the wrap around happened in the less than 13
On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote:
> We were passively acting on the high counter value bit
> and as it was never set, we were only utilizing the
> the 32bits of resolution. As the divisor with these platforms
> is quite high, the wrap around happened in the less than 13
We were passively acting on the high counter value bit
and as it was never set, we were only utilizing the
the 32bits of resolution. As the divisor with these platforms
is quite high, the wrap around happened in the less than 13 seconds.
If we toggle the resolution bit in the control register and
== Series Details ==
Series: GuC Scrub vol. 1 (rev8)
URL : https://patchwork.freedesktop.org/series/16856/
State : failure
== Summary ==
CC [M] drivers/gpu/drm/i915/gvt/execlist.o
LD drivers/misc/built-in.o
LD drivers/pinctrl/built-in.o
CC [M] drivers/gpu/drm/i915/gvt/sched
== Series Details ==
Series: drm/i915: Include GT/seqno activity in engine/hangcheck debugfs (rev2)
URL : https://patchwork.freedesktop.org/series/20562/
State : success
== Summary ==
Series 20562v2 drm/i915: Include GT/seqno activity in engine/hangcheck debugfs
https://patchwork.freedesktop.o
From: Ville Syrjälä
Add tracepoints for display FIFO underruns. Makes it more convenient to
correlate the underruns with other display tracepoints.
v2: s/i915/intel/ in the tracepoint name
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_trace.h
From: Ville Syrjälä
Add a tracepoint for observing changes in the cxsr state. The tracepoint
will dump out the frame and scanline counters for each pipe so that the
information can be compared with eg. plane update tracepoints.
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
---
d
From: Ville Syrjälä
Add tracepoints for observing the WM/FIFO programming on VLV/CHV. When
compared with the plane and pipe update tracepoints this can be used
to verify that everything is performed in the right sequence.
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
---
drivers
From: Ville Syrjälä
Check whether anything relevant has actually change when we compute new
watermarks for each plane in the state. If the watermarks for no
primary/sprite planes changed we don't have to recompute the FIFO split
or reprogram the DSBARB registers. And even the cursor watermarks di
From: Ville Syrjälä
Add tracepoints for plane programming. The tracepoints will dump
the frame and scanline counters, so this can be used to verify eg. that
the plane gets reprogrammed at the right time with respect to watermark
programming (if we have appropriate tracepoints for that as well).
From: Ville Syrjälä
We now compute the watermarks correctly, so just return an error if we
can't support the configuration.
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i9
From: Ville Syrjälä
Since the watermark registers arent double buffered on VLV/CHV, we'll
need to play around with intermediate watermarks same was as we do on
ILK-BDW.
The watermark registers on VLV/CHV contain inverted values, so to find
the intermediate watermark value we just take the minimu
From: Ville Syrjälä
In a lot of place we wish to know which planes on the crtc are actually
visible, or how many of them there are. Let's start tracking that in a
bitmask in the crtc state.
We already track enabled planes (ie. ones with an fb and crtc specified by
the user) but that's not quite
From: Ville Syrjälä
Move the vlv/chv FIFO size tracking into the crtc_state. As with the wms
for now this just acts as temporary storage.
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_drv.h | 12 ++--
drivers/gpu/drm/i915/intel_pm.c | 26 +
From: Ville Syrjälä
Clear out the watermark for all disabled planes to 0. This is required
to avoid falsely thinking that the inherited watermarks are bogus in
case the watermark is actually higher than the FIFO size.
v2: s/noninverted/raw/ for consistency with other platforms
Signed-off-by: Vi
From: Ville Syrjälä
On VLV/CHV enabling sprite0 when sprite1 has already been enabled may
lead to an underrun. This only happens when sprite0 FIFO size is zero
prior to enabling it. Hence an effective workaround is to always
allocate at least one cacheline for sprite0 when sprite1 is active.
I'v
From: Ville Syrjälä
Now that vlv/chv have more proper wm programming support, let's reduce
the the update_wm_{pre,post} flags to only cover the pre-ilk platforms.
When we finally convert those as well we can drop these flags entirely.
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
From: Ville Syrjälä
Track the plane fifo sizes under intel_crtc instead of under each
intel_plane. Avoids looping over the planes in a bunch of places,
and later we'll move this tracking into the crtc state properly.
v2: Nuke intel_plane_wm_parameters (Maarten)
Signed-off-by: Ville Syrjälä
Rev
From: Ville Syrjälä
In an effort to make the vlv/chv wm code look and behave more like the
ilk+ code, let's move the current active wms next to the
corresponding ilk wms.
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_drv.h | 3 +--
drivers/gpu/drm
From: Ville Syrjälä
Remove crtc->wm.cxsr_allowed and just rely on crtc_state->disable_cxsr
instead. This was used only by vlv/chv to indicate whether to enable
cxsr in the wm computation. That doesn't really work anymore, and as far
as the optimal watermarks go we'll just consider the number of p
From: Ville Syrjälä
Let's compute the watermarks first and the FIFO size second. This way we
can make sure the FIFO split is the most accommodating to the watermarks.
Previously we could have potentially computed a FIFO split that couldn't
accommodate the PM2 watermarks simply due to a bad split
From: Ville Syrjälä
Start computing the vlv/chv watermarks the atomic way, from the
.compute_pipe_wm() hook. We'll recompute the actual watermarks
for only planes that are part of the state, the other planes will
keep their watermark from the last time it was computed.
And the actual watermark p
From: Ville Syrjälä
Everything is r-b'd already, but I wanted to do a few mostly
cosmetic changes so that things will look more similar to my
upcoming g4x two stage watermarks work.
The changes are:
* rename the 'noninverted' watermarks to 'raw' since
g4x doesn't have any inverted watermarks
From: Ville Syrjälä
Relocate the vlv/chv wm state to live under intel_crtc_state. Note
that for now this just behaves as a temporary storage. But it'll be
easier to conver the thing over to properly pre-computing the state
when it's already in the right place.
Signed-off-by: Ville Syrjälä
Revie
On Thu, Mar 02, 2017 at 05:03:45PM +0100, Arkadiusz Hiler wrote:
> 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 i9
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Assert that fence->lock is held
in an irq-safe manner
URL : https://patchwork.freedesktop.org/series/20566/
State : success
== Summary ==
Series 20566v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/s
Chris Wilson writes:
> On Thu, Mar 02, 2017 at 05:29:18PM +0200, Mika Kuoppala wrote:
>> Chris Wilson writes:
>>
>> > Useful for double checking that the device is powered up when it hung,
>> > include both the status of the power management and our rpm wakelock.
>> >
>> > Signed-off-by: Chris
On Thu, Mar 02, 2017 at 04:36:05PM +, Chris Wilson wrote:
> On Thu, Mar 02, 2017 at 05:03:48PM +0100, Arkadiusz Hiler wrote:
> > The file fits better.
> >
> > Additionally rename it to intel_uc_prepare_fw(), as the function does
> > more than simple fetch.
> >
> > v2: remove second declaratio
On Thu, Mar 02, 2017 at 05:03:48PM +0100, Arkadiusz Hiler wrote:
> The file fits better.
>
> Additionally rename it to intel_uc_prepare_fw(), as the function does
> more than simple fetch.
>
> v2: remove second declaration, reorder (M. Wajdeczko)
>
> Cc: Michal Wajdeczko
> Signed-off-by: Arkadi
== Series Details ==
Series: drm/i915/guc: Disable irq for __i915_guc_submit wq_lock
URL : https://patchwork.freedesktop.org/series/20564/
State : success
== Summary ==
Series 20564v1 drm/i915/guc: Disable irq for __i915_guc_submit wq_lock
https://patchwork.freedesktop.org/api/1.0/series/20564
`guc_firmware_path` and `huc_firmware_path` module parameters are added.
Using the parameter disabled 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
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 Winia
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
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
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
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
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
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
General GuC/HuC cleanup simplifying logic, and moving chunks around as the area
got pretty rusty.
A lot of logic were extracted from intel_guc_load() to other functions - it did
not only handle the actual loading but had WA implementations and the code
that enabled submission baked into it.
This
The file fits better.
Additionally rename it to intel_uc_prepare_fw(), as the function does
more than simple fetch.
v2: remove second declaration, reorder (M. Wajdeczko)
Cc: Michal Wajdeczko
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/intel_guc_loader.c | 137 +
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
Hi Dave,
topic/designware-baytrail-2017-03-02:
Baytrail PMIC vs. PMU race fixes from Hans de Goede
This time the right version (v4), with the compile fix.
Updated pull request with new tag, same story as before
Cheers, Daniel
The following changes since commit 64a577196d66b44e37384bc5c4d78c61
On Thu, Mar 02, 2017 at 05:29:18PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Useful for double checking that the device is powered up when it hung,
> > include both the status of the power management and our rpm wakelock.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
Chris Wilson writes:
> Useful for double checking that the device is powered up when it hung,
> include both the status of the power management and our rpm wakelock.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915
Chris Wilson writes:
> Whilst investigating some mysterious failures with hangcheck not running
> during gem_busy/basic-hang-default, the question is why did we decide to
> cancel the retire_work (which queues the hangcheck)? That decision is
> based around GT activity, so include that informatio
Hi,
On 02-03-17 15:47, Daniel Vetter wrote:
On Thu, Mar 2, 2017 at 3:38 PM, Hans de Goede wrote:
On 02-03-17 08:00, Daniel Vetter wrote:
On Wed, Mar 01, 2017 at 11:42:48AM +0100, Daniel Vetter wrote:
Hi all,
topic/designware-baytrail-2017-03-01:
Baytrail PMIC vs. PMU race fixes from Hans
Useful for double checking that the device is powered up when it hung,
include both the status of the power management and our rpm wakelock.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gpu_error.c | 4
2 files ch
Whilst investigating some mysterious failures with hangcheck not running
during gem_busy/basic-hang-default, the question is why did we decide to
cancel the retire_work (which queues the hangcheck)? That decision is
based around GT activity, so include that information in the debug
report.
v2: Inc
On 02/03/2017 16:53, Chris Wilson wrote:
__i915_guc_submit may be, despite my assertion, called from outside of
an irq-safe spinlock so we need to use a full spin_lock_irqsave and not
cheat using a spin_lock. (The initial notify callback from the completed
fence is called before the spinlock is
assert_spin_locked() becomes an unconditionally compiled BUG_ON(),
adding debug code right into the heart of critical routines like
interrupt handlers.
textdata bss dec hex
1296480 199442272 1318696 141f28 before (lockdep disabled)
1295984 199442272 1318200 141d38
Everytime we take the fence->lock (aka request->lock), we must do so
with irqs disabled since it may be used from within an hardirq context.
As sometimes we are taking the lock in a nested manner, assert that the
caller did disable the irqs for us.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
On Sat, Feb 25, 2017 at 04:31:04PM +0100, Maarten Lankhorst wrote:
> Op 24-02-17 om 14:11 schreef Ville Syrjälä:
> > On Mon, Feb 20, 2017 at 03:30:58PM +0100, Maarten Lankhorst wrote:
> >> Op 20-02-17 om 14:38 schreef Ville Syrjälä:
> >>> On Mon, Feb 20, 2017 at 10:04:06AM +0100, Maarten Lankhorst
On Thu, Mar 02, 2017 at 02:53:23PM +, Chris Wilson wrote:
> __i915_guc_submit may be, despite my assertion, called from outside of
> an irq-safe spinlock so we need to use a full spin_lock_irqsave and not
> cheat using a spin_lock. (The initial notify callback from the completed
> fence is call
__i915_guc_submit may be, despite my assertion, called from outside of
an irq-safe spinlock so we need to use a full spin_lock_irqsave and not
cheat using a spin_lock. (The initial notify callback from the completed
fence is called before the spinlock is taken to wake up all waiters and
call their
On Thu, Mar 2, 2017 at 3:38 PM, Hans de Goede wrote:
> On 02-03-17 08:00, Daniel Vetter wrote:
>>
>> On Wed, Mar 01, 2017 at 11:42:48AM +0100, Daniel Vetter wrote:
>>>
>>> Hi all,
>>>
>>> topic/designware-baytrail-2017-03-01:
>>> Baytrail PMIC vs. PMU race fixes from Hans de Goede
>>>
>>> I opted
On Wed, 01 Mar 2017, Madhav Chauhan wrote:
> One of the if statement covers the next line in enable I/O sequence.
> This patch correct the same by adding error message.
>
> Signed-off-by: Madhav Chauhan
Pushed, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 1 +
>
Hi,
On 02-03-17 08:00, Daniel Vetter wrote:
On Wed, Mar 01, 2017 at 11:42:48AM +0100, Daniel Vetter wrote:
Hi all,
topic/designware-baytrail-2017-03-01:
Baytrail PMIC vs. PMU race fixes from Hans de Goede
I opted to put all the patches for all subsystems into the topic branches,
so that if ne
== Series Details ==
Series: drm/i915: suppress automic commit error message under gvt-g env
URL : https://patchwork.freedesktop.org/series/20558/
State : failure
== Summary ==
Series 20558v1 drm/i915: suppress automic commit error message under gvt-g env
https://patchwork.freedesktop.org/api/
1 - 100 of 152 matches
Mail list logo
