e of 1s instead.
>
> v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option
> v3:
> (Daniel Vetter)
> - Use hardcoded value of 1s rather than config option
if this is v3 then it's likely still my patch, so I can't give r-b
>
> Signed-off-by: Matthew Brost
> Cc: Michal Wajd
On 10.06.2021 22:46, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Various UMDs need to know the L3 bank count. So add a query API for it.
>
> Signed-off-by: John Harrison
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c | 15 +++
> drivers/gpu/drm/i915/gt/intel_gt.h |
so it could
happen that GuC will return new/updated klvs, so shouldn't we make this
klv list more external and maybe even define as uabi header?
>
> Cc: Tvrtko Ursulin
> Cc: Kenneth Graunke
> Cc: Michal Wajdeczko
> Cc: Slawomir Milczarek
> Signed-off-by: Rodrigo Vivi
l in the buffer.
>
> This patch also adds a header file which lists all the attribute values
> currently defined for the table. This is included for reference as
> these are not currently used by the i915 driver itself.
>
> Note that the table is only available on ADL-P and later pla
drm/i915/guc: Support per context scheduling policies
> drm/i915/guc: Unified GuC log
> drm/i915/guc: Update firmware to v62.0.0
>
> Michal Wajdeczko (10):
> drm/i915/guc: Introduce unified HXG messages
> drm/i915/guc: Update MMIO based communication
> drm/i915/guc
On 10.06.2021 06:38, Matthew Brost wrote:
> On Wed, Jun 09, 2021 at 10:07:21PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 09.06.2021 19:36, John Harrison wrote:
>>> On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
>>>> On 6/7/2021 11:03 AM, Matthew
On 09.06.2021 19:36, John Harrison wrote:
> On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
>> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>>> From: Michal Wajdeczko
>>>
>>> Definition of the CTB registration action has changed.
>>> Add some ABI
On 08.06.2021 03:23, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> Definition of the CTB registration action has changed.
>> Add some ABI documentation and implement required changes.
>
On 08.06.2021 02:59, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> Definition of the CTB descriptor has changed, leaving only
>> minimal shared fields like HEAD/TAIL/STATUS.
>>
>> Bo
On 07.06.2021 19:31, Matthew Brost wrote:
> On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
>>
>> On 27/05/2021 15:35, Matthew Brost wrote:
>>> On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
On 26/05/2021 19:10, Matthew Brost wrote:
[snip]
On 08.06.2021 10:39, Tvrtko Ursulin wrote:
>
> On 07/06/2021 18:31, Matthew Brost wrote:
>> On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
>>>
>>> On 27/05/2021 15:35, Matthew Brost wrote:
On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
>
> On
On 08.06.2021 02:05, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> Format of the STATUS dword in CTB response message now follows
>> definition of the HXG header. Update our code and remove a
On 08.06.2021 01:06, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> The MMIO based Host-to-GuC communication protocol has been
>> updated to use unified HXG messages.
>>
>> Update ou
On 08.06.2021 00:46, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> New GuC firmware will unify format of MMIO and CTB H2G messages.
>> Introduce their definitions now to allow gradual trans
On 07.06.2021 19:45, Matthew Brost wrote:
> On Mon, Jun 07, 2021 at 11:03:51AM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> GuC ABI documentation is now ready to be included in i915.rst
>>
>> Signed-off-by: Michal Wajdeczko
>> Sig
On 04.06.2021 10:20, Daniel Vetter wrote:
> On Thu, Jun 03, 2021 at 04:04:08PM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> Future GuC will require CTB buffers sizes to be multiple of 4K.
>> Make these changes now as this shouldn't impact us too much.
> Signed-off-by: Matthew Brost
> Cc: Michal Wajdeczko
> Reviewed-by: John Harrison
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 28 +++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/drive
On 06.05.2021 21:14, Matthew Brost wrote:
> Implement GuC context operations which includes GuC specific operations
> pin, unpin, and destroy.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_context.c | 5 +
>
On 28.05.2021 03:13, John Harrison wrote:
> On 5/26/2021 10:58, Matthew Brost wrote:
>> On Wed, May 26, 2021 at 02:36:18PM +0200, Michal Wajdeczko wrote:
>>> On 26.05.2021 08:42, Matthew Brost wrote:
>>>> Ensure H2G buffer updates are visible before descriptor
an 1 H2G can be inflight at once.
>
> Signed-off-by: Matthew Brost
> Cc: Michal Wajdeczko
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/dr
On 26.05.2021 08:42, Matthew Brost wrote:
> From: Michal Wajdeczko
>
> In upcoming patch we will allow more CTB requests to be sent in
> parallel to the GuC for processing, so we shouldn't assume any more
> that GuC will always reply without 10ms.
>
>
On 25.05.2021 20:15, Matthew Brost wrote:
> On Thu, May 06, 2021 at 12:13:32PM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> In irq handler try to receive just single G2H message, let other
>> messages to be received from tasklet.
>>
>> Sig
On 25.05.2021 20:08, Matthew Brost wrote:
> On Thu, May 06, 2021 at 12:13:29PM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> In upcoming patch we will allow more CTB requests to be sent in
>> parallel to the GuC for procesing, so we shouldn't
On 24.05.2021 20:35, Matthew Brost wrote:
> On Mon, May 24, 2021 at 02:58:12PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 06.05.2021 21:13, Matthew Brost wrote:
>>> Implement a stall timer which fails H2G CTBs once a period of time
>>> with no forward
On 25.05.2021 05:21, Matthew Brost wrote:
> On Thu, May 06, 2021 at 12:13:30PM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> We want to stop using guc.send_mutex while sending CTB messages
>> so we have to start protecting access to CTB send descrip
On 25.05.2021 04:53, Matthew Brost wrote:
> On Thu, May 06, 2021 at 12:13:26PM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> We can retrieve offsets to cmds buffers and descriptor from
>> actual pointers that we already keep locally.
>>
&
On 25.05.2021 04:47, Matthew Brost wrote:
> On Thu, May 06, 2021 at 12:13:25PM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> In upcoming GuC firmware, CTB size will be removed from the CTB
>> descriptor so we must keep it locally for any calculations.
nt err;
>
> + err = i915_inject_probe_error(guc_to_gt(guc)->i915, -ENXIO);
> + if (err)
> + return err;
> +
> GEM_BUG_ON(ct->vma);
>
> blob_size = 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE +
> CTB_G2H_BUFFER_SIZE;
>
likely could be introd
On 06.05.2021 21:13, Matthew Brost wrote:
> With the introduction of non-blocking CTBs more than one CTB can be in
> flight at a time. Increasing the size of the CTBs should reduce how
> often software hits the case where no space is available in the CTB
> buffer.
>
> Cc: John Harrison
>
On 06.05.2021 21:13, Matthew Brost wrote:
> CTB writes are now in the path of command submission and should be
> optimized for performance. Rather than reading CTB descriptor values
> (e.g. head, tail, size) which could result in accesses across the PCIe
size was removed from the descriptor in
On 06.05.2021 21:13, Matthew Brost wrote:
> Implement a stall timer which fails H2G CTBs once a period of time
> with no forward progress is reached to prevent deadlock.
>
> Also update to ct_write to return -EDEADLK rather than -EPIPE on a
> corrupted descriptor.
broken descriptor is really
On 06.05.2021 21:13, Matthew Brost wrote:
> Add non blocking CTB send function, intel_guc_send_nb. In order to
> support a non blocking CTB send function a spin lock is needed to
spin lock was added in 16/97
> protect the CTB descriptors fields. Also the non blocking call must not
> update the
On 06.05.2021 21:13, Matthew Brost wrote:
> Improve the error message when a unsolicited CT response is received by
> printing fence that couldn't be found, the last fence, and all requests
> with a response outstanding.
>
> Signed-off-by: Matthew Brost
> ---
>
aolo Spurio
> Signed-off-by: Matthew Brost
> Cc: Michal Wajdeczko
> Cc: John Harrison
> ---
> 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_pa
nay Belgaumkar
> Signed-off-by: Rodrigo Vivi
> Signed-off-by: Matthew Brost
Acked-by: Michal Wajdeczko
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 16
> drivers/gpu/drm/i915/gt/uc/intel_guc.h | 1 -
> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif
itch (type) {
> @@ -264,7 +266,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> err_deregister:
> ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> err_out:
> - CT_ERROR(ct, "Failed to open open CT channel (err=%d)\n", err);
> + CT_PROBE_ERROR(ct, "Failed to open channel (err=%d)\n", err);
nit: while here we can start using %pe to print error
Reviewed-by: Michal Wajdeczko
> return err;
> }
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 11.05.2021 17:16, Daniel Vetter wrote:
> On Thu, May 06, 2021 at 12:13:34PM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> New GuC firmware will unify format of MMIO and CTB H2G messages.
>> Introduce their definitions now to allow gradual transition
On 29.03.2021 00:56, Daniele Ceraolo Spurio wrote:
> From: Vitaly Lubart
>
> Export PAVP client to work with i915 driver,
> for binding it uses kernel component framework.
>
> Signed-off-by: Vitaly Lubart
> Signed-off-by: Tomas Winkler
> Signed-off-by: Daniele Ceraolo Spurio
> ---
>
On 29.03.2021 00:56, Daniele Ceraolo Spurio wrote:
> This will be used for communication between the i915 driver and the mei
> one. Defining it in a stand-alone patch to avoid circualr dependedencies
typos
> between the patches modifying the 2 drivers.
>
> Split out from an original patch
Generic helpers should be placed in i915_utils.h.
Signed-off-by: Michal Wajdeczko
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Matthew Brost
---
drivers/gpu/drm/i915/i915_utils.h | 5 +
drivers/gpu/drm/i915/i915_vma.h | 5 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git
Our fwif.h file is now mix of strict firmware ABI definitions and
set of our helpers. In anticipation of upcoming changes to the GuC
interface try to keep them separate in smaller maintainable files.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Jon Ewins
On 22.01.2021 16:49, Chris Wilson wrote:
> Quoting Michal Wajdeczko (2021-01-22 15:43:26)
>>
>>
>> On 22.01.2021 16:06, Chris Wilson wrote:
>>> Clean up the SPDX licence declarations to comply with checkpatch.
>>
>> typo here and in the commit
On 22.01.2021 16:06, Chris Wilson wrote:
> Clean up the SPDX licence declarations to comply with checkpatch.
typo here and in the commit message 04/10
>
> Signed-off-by: Chris Wilson
for the whole series, with above typos fixed,
Reviewed-by: Michal Wajdeczko
Thank
t will come back with GuC submission.
>
>>
>> Signed-off-by: John Harrison
>> Author: Daniele Ceraolo Spurio
>> Author: John Harrison
>> Author: Matthew Brost
>> Author: Michal Wajdeczko
>> Author: Michel Thierry
>> Author: Oscar Mateo
>>
Since VGT ballooning nodes are GGTT specific, we can move them
to i915_ggtt struct close to some other similar nodes. This way
we drop another place in driver that uses static data.
Signed-off-by: Michal Wajdeczko
Cc: Xiong Zhang
Cc: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/gt
Rebase forgotten series [1]
[1] https://patchwork.freedesktop.org/series/71920/
Michal Wajdeczko (2):
drm/i915/ggtt: Add generic i915_ggtt ballooning support
drm/i915/vgt: Move VGT GGTT ballooning nodes to i915_ggtt
drivers/gpu/drm/i915/gt/intel_ggtt.c | 69
Reserving part of the GGTT for the GuC requires same steps
as in VGT GGTT ballooning. Add generic GGTT ballooning
helpers to intel_ggtt.c to avoid code duplication.
Signed-off-by: Michal Wajdeczko
Cc: Xiong Zhang
Cc: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 69
description, but repeating it
will definitely help
>> + add_taint_for_CI(TAINT_WARN);
btw, today we are tainting kernel for CI silently and from different
places, so maybe it is worth to add there some debug log with
__builtin_return_addr
On 09.04.2020 02:56, Daniele Ceraolo Spurio wrote:
> We stopped using the parameter in commit dd18cedfa36f
> ("drm/i915/guc: Move the pin bias value from GuC to GGTT"),
> so we can safely remove it.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matthew Brost
On 30.03.2020 16:12, Chris Wilson wrote:
> Quoting Michal Wajdeczko (2020-03-30 15:02:53)
>>
>>
>> On 30.03.2020 14:28, Chris Wilson wrote:
>>> There's nothing else between us loading the fw and the huc rejecting
>>> it?
>>>
>>> FIRMWARE
On 30.03.2020 14:28, Chris Wilson wrote:
> Quoting Michal Wajdeczko (2020-03-30 12:33:02)
>> There might be many reasons why we failed to successfully
>> load and authenticate HuC firmware, but today we only use
>> single error in case of no HuC hardware. Add some more
&g
We report HuC status in debugfs using register read, but
we missed that on Gen11+ HuC uses different register.
Use correct one.
While here, correct placement of the colon.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c
There might be many reasons why we failed to successfully
load and authenticate HuC firmware, but today we only use
single error in case of no HuC hardware. Add some more
error codes for most common cases (disabled, not installed,
corrupted or mismatched firmware).
Signed-off-by: Michal Wajdeczko
On 28.02.2020 12:33, Joonas Lahtinen wrote:
>>> --+--
>>> HuC state | option B
>>> --+--
>>> no HuC hardware | -ENODEV
>>> GuC fw disabled | -EOPNOTSUPP -> user decision, why error?
>>> HuC fw disabled |
On 25.02.2020 08:49, Ye, Tony wrote:
>
>
> On 2/21/2020 11:32 PM, Michal Wajdeczko wrote:
>> From commit 84b1ca2f0e68 ("drm/i915/uc: prefer intel_gt over i915
>> in GuC/HuC paths") we stopped using HUC_STATUS error -ENODEV only
>> to indicate lack
relying again on HAS_GT_UC macro, since currently
used function intel_huc_is_supported() is based on HuC firmware
support which could be unsupported also due to force disabled
GuC firmware.
v2: use 0 only for disabled, add more error codes for other failures
Signed-off-by: Michal Wajdeczko
Cc: Daniele C
On Tue, 11 Feb 2020 18:53:05 +0100, Fosha, Robert M
wrote:
On 2/4/20 4:43 PM, Ye, Tony wrote:
On 1/27/2020 1:41 AM, Michal Wajdeczko wrote:
On Thu, 23 Jan 2020 16:51:58 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2020-01-23 15:38:52)
On Thu, 23 Jan 2020 16:02:17 +0100
Wilson
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 10 --
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 3 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 7 +--
drivers/gpu/drm/i915/gt/uc/intel_uc
with redundant (?) fw cleanups clarified,
Reviewed-by: Michal Wajdeczko
The re-org of the fw_cleanups is done separately in the next patch,
since it isn't as straightforward as just dropping the call. Is that
enough for the r-b on this patch or do you want something more?
somehow I
with the debugfs cleanup after this is merged?
sure, with promise that there will be follow-up series,
Reviewed-by: Michal Wajdeczko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
;
+intel_uc_ops_function(init, init, int, 0);
intel_uc_ops_function(fini, fini, void, );
intel_uc_ops_function(init_hw, init_hw, int, 0);
intel_uc_ops_function(fini_hw, fini_hw, void, );
with redundant (?) fw cleanups clarified,
Reviewed-by: Michal Wajdeczko
___
On Tue, 04 Feb 2020 00:28:35 +0100, Daniele Ceraolo Spurio
wrote:
To be able to differentiate the before and after of our commitment to
GuC submission, which will be used in follow-up patches to early set-up
the submission structures.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal
nly if GuC is wanted, improve "used" state
description (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Reviewed-by: Fernando Pacheco #v1
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8 +
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
Reviewed-by: Michal Wajdeczko
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/d
Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Reviewed-by: Michal Wajdeczko
some diff could be smaller after updating 1/10
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 15 +--
drivers/gpu/drm/i915/i915_drv.h | 1 -
3 files changed
: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e75e8212f03b..7264c0ff766c 100644
+ /* CTB_RECV lock will be used with irq disabled */
...will be used inside the interrupt handler
I think is a more descriptive comment.
Well, we usually call intel_guc_ct_event_handler() from irq handler,
but we are also calling it from guc_enable_communication(), that's
ed_locks WARN (Chris)
v4: mark CTB_RECV as used with irq disabled (Chris)
reuse helper macro in intel_engine_init_active (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1
On Mon, 03 Feb 2020 10:58:08 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2020-02-03 09:54:13)
void intel_guc_ct_init_early(struct intel_guc_ct *ct)
{
+ int i;
+
spin_lock_init(>requests.lock);
INIT_LIST_HEAD(>requests.pending);
INIT_LIS
locks WARN (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 146 --
drivers/gpu/drm/i915/gt/uc/intel
or option only for our new one-way requests, for which
status can be temporary ignored.
Since we only need to protect CT descriptor during reading/writing
from the command buffer, we can drop mutex and switch to spinlock.
v2: use separate locks, and set subclass (Chris)
Signed-off-by: Michal W
On Fri, 31 Jan 2020 17:40:12 +0100, Matthew Brost
wrote:
On Fri, Jan 31, 2020 at 03:33:55PM +, Chris Wilson wrote:
Quoting Michal Wajdeczko (2020-01-31 14:58:34)
While we are always using CT "send" buffer to send request messages
to GuC, we usually don't ask GuC to use C
On Fri, 31 Jan 2020 16:33:55 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2020-01-31 14:58:34)
While we are always using CT "send" buffer to send request messages
to GuC, we usually don't ask GuC to use CT "receive" buffer to send
back response messages, since
We already have guc_is_running function, but it only reflects
firmware status, while to fully use GuC we need to know if we've
already established communication with it.
v2: also s/intel_guc_is_running/intel_guc_is_fw_running (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
or option only for our new one-way requests, for which
status can be temporary ignored.
Since we only need to protect CT descriptor during reading/writing
from the command buffer, we can drop mutex and switch to spinlock.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo
We already have guc_is_running function, but it only reflects
firmware status, while to fully use GuC we need to know if we've
already established communication with it.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 5
On Thu, 23 Jan 2020 16:51:58 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2020-01-23 15:38:52)
On Thu, 23 Jan 2020 16:02:17 +0100, Chris Wilson
wrote:
> Quoting Daniele Ceraolo Spurio (2020-01-22 23:52:33)
>>
>>
>> On 1/22/20 11:48 AM, Michal Wajdeczko wro
On Thu, 23 Jan 2020 19:26:58 +0100, Ye, Tony wrote:
On 1/23/2020 7:38 AM, Michal Wajdeczko wrote:
On Thu, 23 Jan 2020 16:02:17 +0100, Chris Wilson
wrote:
Quoting Daniele Ceraolo Spurio (2020-01-22 23:52:33)
On 1/22/20 11:48 AM, Michal Wajdeczko wrote:
> From commit 84b1ca2f0
On Thu, 23 Jan 2020 16:02:17 +0100, Chris Wilson
wrote:
Quoting Daniele Ceraolo Spurio (2020-01-22 23:52:33)
On 1/22/20 11:48 AM, Michal Wajdeczko wrote:
> From commit 84b1ca2f0e68 ("drm/i915/uc: prefer intel_gt over i915
> in GuC/HuC paths") we stopped using HUC_STAT
On Thu, 23 Jan 2020 03:43:04 +0100, Patchwork
wrote:
== Series Details ==
Series: drm/i915/huc: Fix error reported by I915_PARAM_HUC_STATUS
URL : https://patchwork.freedesktop.org/series/72419/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7799 -> Patchwork_16219
relying again on HAS_GT_UC macro, since currently
used function intel_huc_is_supported() is based on HuC firmware
support which could be unsupported also due to force disabled
GuC firmware.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Tony Ye
---
drivers/gpu/d
We should never BUG_ON on any corruption in CTB descriptor as
data there can be also modified by the GuC. Instead we can
use flag "is_in_error" to indicate that we will not process
any further messages over this CTB (until reset).
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
C
e function that actually
touches that descriptor.
Note that unexpected content of the specific CT messages, that
still complies with generic CT message format, shall not trigger
disabling whole CTB, as that might just indicate new unsupported
message types.
v2: drop redundant message (Daniele)
Signed-off-
As we now have "ct" available in ct_read function we can switch
from generic DRM_ERROR to our custom CT_ERROR.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 16
1 file changed, 8 insert
Since we only have one SEND buffer we don't need to explicitly pass
it to the write function.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 13 +++--
1 file changed, 7
Since we only have one RECV buffer we don't need to explicitly pass
it to the read function.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++---
1 file changed, 3 insertions
v2: drop redundant message + rebase
Michal Wajdeczko (5):
drm/i915/guc: Don't GEM_BUG_ON on corrupted G2H CTB
drm/i915/guc: Don't pass CTB while writing
drm/i915/guc: Don't pass CTB while reading
drm/i915/guc: Switch to CT_ERROR in ct_read
drm/i915/guc: Introduce CT_DEBUG
drivers/gpu
As we now have "ct" available almost in all functions we can
start using dev variants of logs also for debug.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc
-if (USES_GUC_SUBMISSION(dev_priv)) {
+if (intel_uc_uses_guc_submission(_priv->gt.uc)) {
nit: that old macro was helpful exactly in cases where only dev_priv
is known and component might have no idea where to find uc
maybe we should have helper like:
#define to_intel_uc(i915)
On Wed, 15 Jan 2020 02:31:38 +0100, Daniele Ceraolo Spurio
wrote:
use intel_uc_uses_guc_submission() directly instead, to be consistent in
the way we check what we want to do with the GuC.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
On Wed, 15 Jan 2020 02:31:37 +0100, Daniele Ceraolo Spurio
wrote:
use intel_uc_uses_guc() directly instead, to be consistent in the way we
check what we want to do with the GuC.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
drivers
On Thu, 16 Jan 2020 19:53:08 +0100, Daniele Ceraolo Spurio
wrote:
On 1/15/20 6:08 AM, Michal Wajdeczko wrote:
Since we only have one SEND buffer we don't need to explicitly pass
it to the write function.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
On Thu, 16 Jan 2020 19:46:35 +0100, Daniele Ceraolo Spurio
wrote:
On 1/15/20 6:08 AM, Michal Wajdeczko wrote:
We should never BUG_ON on any corruption in CTB descriptor as
data there can be also modified by the GuC. Instead we can
use flag "is_in_error" to indica
Since we only have one RECV buffer we don't need to explicitly pass
it to the read function.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
As we now have "ct" available in ct_read function we can switch
from generic DRM_ERROR to our custom CT_ERROR.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 18 +-
1 file changed, 9 insert
e function that actually
touches that descriptor.
Note that unexpected content of the specific CT messages, that
still complies with generic CT message format, shall not trigger
disabling whole CTB, as that might just indicate new unsupported
message types.
Signed-off-by: Michal Wajdeczko
Cc: Chris
As we now have "ct" available almost in all functions we can
start using dev variants of logs also for debug.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 41 +++
1 file changed, 19
Since we only have one SEND buffer we don't need to explicitly pass
it to the write function.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff
Michal Wajdeczko (5):
drm/i915/guc: Don't GEM_BUG_ON on corrupted G2H CTB
i915/drm/guc: Don't pass CTB while writing
i915/drm/guc: Don't pass CTB while reading
drm/i915/guc: Switch to CT_ERROR in ct_read
drm/i915/guc: Introduce CT_DEBUG
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 114
On Mon, 13 Jan 2020 22:59:46 +0100, Daniele Ceraolo Spurio
wrote:
On 1/13/2020 12:52 PM, Michal Wajdeczko wrote:
On Mon, 13 Jan 2020 21:20:25 +0100, Daniele Ceraolo Spurio
wrote:
On 1/11/2020 3:11 PM, Michal Wajdeczko wrote:
We should start using dev variants of error logging
201 - 300 of 1919 matches
Mail list logo
