As we are careful not to register external interfaces before the
internals are brought up, we are not dependent upon a synchronous
probing and can allow ourselves to be probed from a secondary thread
during system bootup. We already do relegate some configuration to
asynchronous tasks (such as sett
Michal,
Can you send this with the enable_guc HAX patch to get a run in the CI
with GuC.
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi,
Yunwei Zhang writes:
> WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
> read into Slice/Subslice specific registers, MCR packet control
> register(0xFDC) needs to be programmed to point to any enabled
> slice/subslice pair. Otherwise, incorrect value will be retu
For the off-chance we have an interrupt posted and haven't processed the
CSB.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engi
Quoting Patchwork (2018-03-22 21:52:05)
> == Series Details ==
>
> Series: series starting with [v2,3/3] HAX: Enable GuC for CI (rev4)
> URL : https://patchwork.freedesktop.org/series/40516/
> State : failure
>
> == Summary ==
>
> Applying: HAX: Enable GuC for CI
> Applying: drm/i915/uc: Fetch
== Series Details ==
Series: drm/i915: Request driver probe from an async task
URL : https://patchwork.freedesktop.org/series/40547/
State : failure
== Summary ==
Series 40547v1 drm/i915: Request driver probe from an async task
https://patchwork.freedesktop.org/api/1.0/series/40547/revisions/1
Commit 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
reset") got confused and only applied the flush to the set-wedge path
(which itself is proving troublesome), but we also need the
serialisation on the regular reset path. Oops.
Move the interrupt into reset_irq() and make it c
== Series Details ==
Series: drm/i915: Include submission tasklet state in engine dump
URL : https://patchwork.freedesktop.org/series/40548/
State : success
== Summary ==
Series 40548v1 drm/i915: Include submission tasklet state in engine dump
https://patchwork.freedesktop.org/api/1.0/series/4
On 22/03/2018 17:44, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-03-22 17:24:16)
From: Tvrtko Ursulin
If we stop relying on regular GPU hangs to be detected, but trigger them
manually as soon as we know our batch of interest is actually executing
on the GPU, we can dramatically speed up
On 22/03/2018 18:14, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-03-22 17:32:46)
On 22/03/18 05:42, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-03-22 12:36:58)
On 22/03/2018 11:39, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-03-22 11:17:11)
trigger_reset(fd
Quoting Tvrtko Ursulin (2018-03-23 09:46:49)
>
> On 22/03/2018 17:44, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-03-22 17:24:16)
> >> + itv.it_value.tv_usec = us % 100;
> >> + setitimer(ITIMER_REAL, &itv, NULL);
> >
> > Ok, that gives a single shot signal.
> >
> > I wou
== Series Details ==
Series: drm/i915: Actually flush interrupts on reset not just wedging
URL : https://patchwork.freedesktop.org/series/40550/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cac6dd787287 drm/i915: Actually flush interrupts on reset not just wedging
-:17: WARNIN
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-03-20 15:17:33)
>> Looping through rps frequencies when both min and max are zero
>> ends up into an endless loop. This can happen during hardware
>> enablement.
>>
>> Bail out early if rps frequencies are not correctly set yet.
>>
>> Cc: Chris
On 19/03/2018 20:58, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-03-19 18:22:04)
From: Tvrtko Ursulin
Simple tests to check reported queue depths are correct.
Signed-off-by: Tvrtko Ursulin
---
tests/perf_pmu.c | 224 +++
1 file cha
== Series Details ==
Series: drm/i915: Include submission tasklet state in engine dump
URL : https://patchwork.freedesktop.org/series/40548/
State : success
== Summary ==
Known issues:
Test kms_cursor_legacy:
Subgroup 2x-long-flip-vs-cursor-atomic:
fail -> P
On Fri, 23 Mar 2018 09:49:45 +0100, Joonas Lahtinen
wrote:
Michal,
Can you send this with the enable_guc HAX patch to get a run in the CI
with GuC.
Piotr will send it with CI prefix very soon.
Thanks,
Michal
___
Intel-gfx mailing list
Intel-gfx
== Series Details ==
Series: drm/i915: Actually flush interrupts on reset not just wedging
URL : https://patchwork.freedesktop.org/series/40550/
State : failure
== Summary ==
Series 40550v1 drm/i915: Actually flush interrupts on reset not just wedging
https://patchwork.freedesktop.org/api/1.0/
Commit 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
reset") got confused and only applied the flush to the set-wedge path
(which itself is proving troublesome), but we also need the
serialisation on the regular reset path. Oops.
Move the interrupt into reset_irq() and make it c
On 22/03/2018 21:22, Lionel Landwerlin wrote:
On 19/03/18 18:22, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
---
tests/i915_query.c | 381
+
1 file changed, 381 insertions(+)
diff --git a/tests/i915_q
On Tue, Mar 20, 2018 at 09:19:48PM +, Daniel Stone wrote:
> Chamelium support requires igt_frame to be built, which requires both
> GSL and Pixman.
>
> Signed-off-by: Daniel Stone
Reviewed-by: Petri Latvala
Also a reminder about https://lists.freedesktop.org/mailman/listinfo/igt-dev
> ---
Quoting Chris Wilson (2018-03-16 18:03:25)
> Some platforms may execute the heavy workload very slowly, such that
> using a batch of 1024 takes tens of seconds and immediately overrunning
> the 5s timeout on a pass. Added up over a few dozen passes, this turns a
> 120 second test into 10 minutes. C
== Series Details ==
Series: drm/i915: Request driver probe from an async task
URL : https://patchwork.freedesktop.org/series/40547/
State : success
== Summary ==
Series 40547v1 drm/i915: Request driver probe from an async task
https://patchwork.freedesktop.org/api/1.0/series/40547/revisions/1
On 23/03/18 10:18, Tvrtko Ursulin wrote:
On 22/03/2018 21:22, Lionel Landwerlin wrote:
On 19/03/18 18:22, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
---
tests/i915_query.c | 381
+
1 file changed, 38
Chris Wilson writes:
> Commit 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
> reset") got confused and only applied the flush to the set-wedge path
> (which itself is proving troublesome), but we also need the
> serialisation on the regular reset path. Oops.
>
> Move the interr
Quoting Tvrtko Ursulin (2018-03-23 10:18:37)
>
> On 22/03/2018 21:22, Lionel Landwerlin wrote:
> > I guess we could add a group for the topology too.
>
> My dilemma was whether to stuff tests for any query into i915_query.c,
> or split out to separate binaries.
>
> I can imagine, if/when the nu
Quoting Mika Kuoppala (2018-03-23 10:53:00)
> Chris Wilson writes:
>
> > Commit 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
> > reset") got confused and only applied the flush to the set-wedge path
> > (which itself is proving troublesome), but we also need the
> > serialisat
Quoting Chris Wilson (2018-03-23 08:30:48)
> As we are careful not to register external interfaces before the
> internals are brought up, we are not dependent upon a synchronous
> probing and can allow ourselves to be probed from a secondary thread
> during system bootup. We already do relegate som
Op 22-03-18 om 08:42 schreef Thomas Hellstrom:
> On 03/21/2018 10:12 PM, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> Apparently xf86-video-vmware leaves the mode->type uninitialized
>> when feeding the mode to the kernel. Thus we have no choice but
>> to accept the garbage in. We'll just ign
On 21 March 2018 at 21:12, Ville Syrjala wrote:
> Apparently xf86-video-vmware leaves the mode->type uninitialized
> when feeding the mode to the kernel. Thus we have no choice but
> to accept the garbage in. We'll just ignore any of the bits we
> don't want. The mode type is just a hint anyway, a
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index c963603..53037b5 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/
In upcoming patch, we want to perform more actions in early
initialization of the uC. This reordering will help resolve
new dependencies that will be introduced by future patch.
v2: s/i915_gem_load_init/i915_gem_init_early (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursu
We were fetching uC firmwares in separate uc_init_fw step, while
there is no reason why we can't fetch them during init_early.
This will also simplify upcoming patches, as size of the firmware
may be used for register initialization.
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Sagar
== Series Details ==
Series: drm/i915: Request driver probe from an async task
URL : https://patchwork.freedesktop.org/series/40547/
State : failure
== Summary ==
Possible new issues:
Test drv_selftest:
Subgroup live_objects:
pass -> INCOMPLETE (shard-apl)
T
If GuC firmware is not available on the system and we load i915 with enable
GuC, then we hit this null pointer dereference issue:
[ 71.098873] BUG: unable to handle kernel NULL pointer dereference at
0008
[ 71.098938] IP: intel_uc_fw_upload+0x1f/0x360 [i915]
[ 71.098947] PGD 0 P
Signed-off-by: Piotr Piórkowski
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index c96360398072..53037b5eff22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++
On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
>
>
> Den 22.03.2018 21.27, skrev Ville Syrjala:
> > From: Ville Syrjälä
> >
> > mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
> > bowels of the .atomic_enable() hook. That prevents us from taking the
> > plane
== Series Details ==
Series: drm/i915: Actually flush interrupts on reset not just wedging (rev2)
URL : https://patchwork.freedesktop.org/series/40550/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a91768efb72a drm/i915: Actually flush interrupts on reset not just wedging
-:21:
On Thu, Mar 22, 2018 at 08:42:11AM +0100, Thomas Hellstrom wrote:
> On 03/21/2018 10:12 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Apparently xf86-video-vmware leaves the mode->type uninitialized
> > when feeding the mode to the kernel. Thus we have no choice but
> > to accept the ga
From: Tvrtko Ursulin
If we stop relying on regular GPU hangs to be detected, but trigger them
manually as soon as we know our batch of interest is actually executing
on the GPU, we can dramatically speed up various subtests.
This is enabled by the pollable spin batch added in the previous patch.
== Series Details ==
Series: drm/i915: Actually flush interrupts on reset not just wedging (rev2)
URL : https://patchwork.freedesktop.org/series/40550/
State : failure
== Summary ==
Series 40550v2 drm/i915: Actually flush interrupts on reset not just wedging
https://patchwork.freedesktop.org/a
Quoting Tvrtko Ursulin (2018-03-23 11:54:28)
> From: Tvrtko Ursulin
>
> If we stop relying on regular GPU hangs to be detected, but trigger them
> manually as soon as we know our batch of interest is actually executing
> on the GPU, we can dramatically speed up various subtests.
>
> This is enab
Quoting Patchwork (2018-03-23 11:56:41)
> == Series Details ==
>
> Series: drm/i915: Actually flush interrupts on reset not just wedging (rev2)
> URL : https://patchwork.freedesktop.org/series/40550/
> State : failure
>
> == Summary ==
>
> Series 40550v2 drm/i915: Actually flush interrupts on
On 3/23/2018 4:53 PM, Piotr Piórkowski wrote:
If GuC firmware is not available on the system and we load i915 with enable
GuC, then we hit this null pointer dereference issue:
Patch looks good but I have query on usage of enable_guc modparam.
enable_guc modparam will enable GuC/HuC only if fir
Quoting Matt Roper (2018-03-17 02:08:57)
> This is the fourth iteration of the work previously posted here:
> (v1)
> https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
> (v2)
> https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html
> (v3) https://
On Fri, 23 Mar 2018 13:07:15 +0100, Sagar Arun Kamble
wrote:
On 3/23/2018 4:53 PM, Piotr Piórkowski wrote:
If GuC firmware is not available on the system and we load i915 with
enable
GuC, then we hit this null pointer dereference issue:
Patch looks good but I have query on usage of enab
For the off-chance we have an interrupt posted and haven't processed the
CSB.
v2: Include tasklet enable/disable state for good measure.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/
On Thu, 22 Mar 2018 21:48:16 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2018-03-22 20:36:57)
/snip/
@@ -962,8 +961,8 @@ static int i915_driver_init_early(struct
drm_i915_private *dev_priv,
*/
static void i915_driver_cleanup_early(struct drm_i915_private
*dev_priv)
{
-
Quoting Jani Nikula (2018-03-21 14:16:37)
> On Wed, 21 Mar 2018, Chris Wilson wrote:
> > Quoting Jani Nikula (2018-03-21 11:47:06)
> >>
> >> > Quoting Chris Wilson (2018-03-21 10:41:37)
> >> >>
> >> >> Just idly testing the waters...
> >> >>
> >> >> In yaml, this would be
> >> >> "- slice%d:
While we need to know WOPCM size to do this sanity check, it has more to
do with FW than with WOPCM. Let's move the check to fetch phase, it's
not like WOPCM is going to grow in the meantime. We're also reducing
some of the code movement in following patches.
Signed-off-by: Michał Winiarski
Cc: C
We're seeing "RPM wakelock ref not held during HW access" warning
otherwise. And since IRQ are synced for runtime suspend, we can use the
variant without wakeref assert.
Reported-by: Marta Löfstedt
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105710
Signed-off-by: Michał Winiarski
Cc:
In the following patches we're going to support constraints checking on
an already locked partitioning. Let's structure the code now to allow
for code reuse and reduce the churn later on.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Jackie Li
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
-
We imposed additional restrictions to GEN9 WOPCM partitioning. However,
we ignored early steppings of CNL, to which those restrictions also
apply. Let's also tweak the logic a bit by having separate helpers for
returning extra size needed for the restriction to be satisfied, and
handle the results
We need GuC to load HuC, but it's also possible for GuC to operate on
its own. We don't know what the size of HuC FW may be, so, not wanting
to make any platform-specific hardcoded guesses, we assume that its size
is 0... Which is a very bad approximation.
This has a very unfortunate consequence -
It's possible that when we're being loaded, the write-once registers were
already programmed. It's also possible, that values present in those registers
match our FW size and HW restrictions.
Rather than failing the module load when we detect any differences from our
preferred values, let's replace
We probably shouldn't print out WOPCM size on platforms that don't have
GuC. We also want to make sure we don't hit any asserts if user explicitly
sets enable_guc != 0 on non-guc platforms.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Jackie Li
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index c96360398072..53037b5eff22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_param
Chris Wilson writes:
> Commit 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
> reset") got confused and only applied the flush to the set-wedge path
> (which itself is proving troublesome), but we also need the
> serialisation on the regular reset path. Oops.
>
> Move the interr
Quoting Joonas Lahtinen (2018-03-23 12:29:54)
> Quoting Jani Nikula (2018-03-21 14:16:37)
> > On Wed, 21 Mar 2018, Chris Wilson wrote:
> > > Quoting Jani Nikula (2018-03-21 11:47:06)
> > >>
> > >> > Quoting Chris Wilson (2018-03-21 10:41:37)
> > >> >>
> > >> >> Just idly testing the waters...
>
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index c963603..53037b5 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/
We were fetching uC firmwares in separate uc_init_fw step, while
there is no reason why we can't fetch them during init_early.
This will also simplify upcoming patches, as size of the firmware
may be used for register initialization.
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Sagar
In upcoming patch, we want to perform more actions in early
initialization of the uC. This reordering will help resolve
new dependencies that will be introduced by future patch.
v2: s/i915_gem_load_init/i915_gem_init_early (Chris)
v3: s/i915_gem_load_cleanup/i915_gem_cleanup_early (Michal)
Signed
On 30.01.2018 00:12, Rodrigo Vivi wrote:
> On Mon, Jan 29, 2018 at 05:42:53AM +, Kai Heng Feng wrote:
>>
>>> On 26 Jan 2018, at 6:25 AM, Rodrigo Vivi wrote:
>>>
>>> If the table result is out of bounds on the array map
>>> there is something really wrong with VBT pin so we don't
>>> return tha
== Series Details ==
Series: series starting with [v3,1/3] drm/i915: Reorder early initialization
URL : https://patchwork.freedesktop.org/series/40556/
State : success
== Summary ==
Series 40556v1 series starting with [v3,1/3] drm/i915: Reorder early
initialization
https://patchwork.freedeskt
Quoting Bloomfield, Jon (2018-03-22 21:59:33)
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Jeff McGee
> > Sent: Thursday, March 22, 2018 12:09 PM
> > To: Tvrtko Ursulin
> > Cc: Kondapally, Kalyan ; intel-
> > g...@lists.freedesktop.org; b...@bwidawsk.net
>
On Thu, Mar 22, 2018 at 04:36:42PM +0200, Imre Deak wrote:
> After
>
> commit dd9f31c7a3887950cbd0d49eb9d43f7a1518a356
> Author: Imre Deak
> Date: Wed Aug 16 17:46:07 2017 +0300
>
> drm/i915/gen9+: Set same power state before hibernation image
> save/restore
>
> during hibernation/sus
Den 23.03.2018 12.31, skrev Ville Syrjälä:
On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
Den 22.03.2018 21.27, skrev Ville Syrjala:
From: Ville Syrjälä
mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us
Quoting Joonas Lahtinen (2018-03-23 13:20:40)
> So far nobody has been succesful in selling this to the userspace
> compositors (the most likely user) or has somebody?
I hadn't even contemplated selling it. However, it does seem applicable
to the RealTime priorities for Vk and
https://www.khronos
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
Signed-off-by: Daniel Stone
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c | 15 ---
drive
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.
Signed-off-by: Daniel Stone
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_debugfs.c
On Fri, Mar 23, 2018 at 02:37:23PM +0100, Noralf Trønnes wrote:
>
> Den 23.03.2018 12.31, skrev Ville Syrjälä:
> > On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
> >>
> >> Den 22.03.2018 21.27, skrev Ville Syrjala:
> >>> From: Ville Syrjälä
> >>>
> >>> mipi_dbi_enable_flush() wan
On Thu, Mar 22, 2018 at 02:27:59PM -0700, Yaodong Li wrote:
> On 03/22/2018 01:38 PM, Michał Winiarski wrote:
> > On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
> > > In current code, we only compare the locked WOPCM register values with the
> > > calculated values. However, we can cont
Quoting Yaodong Li (2018-03-22 23:27:59)
> On 03/22/2018 01:38 PM, Michał Winiarski wrote:
> > On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
> >> @@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> >> return -E2BIG;
> >> }
> >>
> >> -guc_wop
On Thu, Mar 22, 2018 at 06:47:21PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Don't spew errors when resetting HDMI scrambling/bit clock
> ratio fails (rev4)
> URL : https://patchwork.freedesktop.org/series/40461/
> State : warning
>
> == Summary ==
>
> Possible
Quoting Stephen Rothwell (2018-03-23 02:50:18)
> Hi all,
>
> On Thu, 22 Mar 2018 13:21:29 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the drm-intel tree got a conflict in:
> >
> > drivers/gpu/drm/i915/gvt/scheduler.c
> >
> > between commit:
> >
> > fa3dd623e559 ("d
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/guc: Fix null pointer
dereference when GuC FW is not available
URL : https://patchwork.freedesktop.org/series/40559/
State : success
== Summary ==
Series 40559v1 series starting with [CI,1/2] drm/i915/guc: Fix null pointer
d
On Fri, Mar 23, 2018 at 04:02:47PM +0200, Joonas Lahtinen wrote:
> Quoting Yaodong Li (2018-03-22 23:27:59)
> > On 03/22/2018 01:38 PM, Michał Winiarski wrote:
> > > On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
> > >> @@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopc
On Fri, Mar 23, 2018 at 01:45:50PM +, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass.
>
> Signed-off-by: Daniel Stone
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-gfx@lists.freedes
GuC can respond to our commands not only by updating SEND buffer
descriptor, but can also send a response message over RECV buffer.
Guc can also send unsolicited request messages over RECV buffer.
Let's start reading those messages and make placeholders
for actual response/request handlers.
v2: mi
We will need them in G2H communication to properly handle
responses and requests from the Guc.
v2: keep irq enabled while disabling GuC logging (Oscar)
v3: rebase.
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Daniele Ceraolo Spurio
Cc: Michel Thierry
Acked-by: Oscar Mateo
---
drivers
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index c963603..53037b5 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/
In next patch we will introduce another way of waiting for the response
that will use RECV buffer. To avoid misleading names, rename old wait
function to reflect the fact that it is based on descriptor update.
v2: fix comment style (Michal)
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i9
Instead of returning small data in response status dword,
GuC may append longer data as response message payload.
If caller provides response buffer, we will copy received
data and use number of received data dwords as new success
return value. We will WARN if response from GuC does not
match calle
This is a preparation step for the upcoming patches.
We already can return some small data decoded from the command
status, but we will need more in the future.
v2: add explicit response buf size
v3: squash with helper patch
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Michel Thierry
Cc
As we are going to extend our use of MMIO based communication,
try to explain its mechanics and update corresponding definitions.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Kelvin Gardiner
---
drivers/gpu/drm/i915/intel_guc.c | 20
drive
With this series we will be able to receive more data from the Guc.
New Guc firmwares will be required to actually use that feature.
v4: respin series after 1/2 year break
Michal Wajdeczko (13):
drm/i915/guc: Add documentation for MMIO based communication
drm/i915/guc: Add support for data re
GuC may return additional data in the response message.
Format and meaning of this data is action specific. We will
use this non-negative data as a new success return value.
Currently used actions don't return data that way yet.
v2: fix prohibited space after '~' (Michel)
update commit message
On platforms with CTB based GuC communications, we will handle
GuC events in a different way. Let's make event handler a virtual
function to allow easy switch between those variants.
Credits-to: Oscar Mateo
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Oscar Mateo
---
drivers
Requests are read from CT in the irq handler, but actual processing
will be done in the work thread. Processing of specific actions will
be added in the upcoming patches.
v2: don't use GEM_BUG_ON (Chris)
don't kmalloc too large buffer (Michal)
v3: rebased
Signed-off-by: Michal Wajdeczko
Cc:
During debug we may want to investigate all communication
from the Guc. Add proper tracing macros in debug config.
v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal)
v3: use dedicated Kconfig (Daniele)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Acked-by
We're using data encoded in the status MMIO as return value from send
function, but GuC may also write more data in remaining MMIO regs.
Let's copy content of these registers to the buffer provided by caller.
v2: new line (Michel)
v3: updated commit message
Signed-off-by: Michal Wajdeczko
Cc: Da
When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.
Signe
Hi Ville,
On 23 March 2018 at 14:42, Ville Syrjälä wrote:
> On Fri, Mar 23, 2018 at 01:45:50PM +, Daniel Stone wrote:
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -13916,7 +13916,8 @@ static void intel_user_framebuffer_destroy(struct
>> dr
== Series Details ==
Series: drm/i915: Actually flush interrupts on reset not just wedging (rev2)
URL : https://patchwork.freedesktop.org/series/40550/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b3648d43615e drm/i915: Actually flush interrupts on reset not just wedging
-:21:
v2: except running with HYPERVISOR
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/intel_uc.c| 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
inde
Since commit 6ca9a2beb54a ("drm/i915: Unwind i915_gem_init() failure")
we believed that we correctly handle all errors encountered during
GuC initialization, including special one that indicates request to
run driver with disabled GPU submission (-EIO).
Unfortunately since commit 121981fafe69 ("dr
In function gem_init_hw() we are calling uc_init_hw() but in case
of error later in function, we missed to call matching uc_fini_hw()
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 6 ++
1 file changed, 6 insertions(+)
diff --g
Some functions already use i915 name instead of dev_priv.
Let's rename this param in all remaining functions, except
those that still use legacy macros.
v2: don't forget about function descriptions (Sagar)
v3: rebased
Signed-off-by: Michal Wajdeczko
Reviewed-by: Sagar Arun Kamble
---
drivers/g
We should not leave GuC submission enabled after sanitize,
as we are going to reset all GuC/HuC hardware.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_uc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel
We don't have to check load status values.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_huc.c | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
Today uc_fini_hw is subset of uc_sanitize, but remaining
code in sanitize function is also desired for uc_fini_hw.
Instead of duplicating the code, just call uc_sanitize,
but leave as separate function to maintain symmetry with
uc_init_hw.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc
1 - 100 of 187 matches
Mail list logo
