On 29/08/2019 09:45, Lionel Landwerlin wrote:
On 28/08/2019 22:41, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-08-28 15:33:26)
+ rq = i915_request_create(i915->engine[RCS0]->kernel_context);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ err =
i915_active_r
On Wed, Aug 28, 2019 at 08:31:27PM +, Souza, Jose wrote:
> On Wed, 2019-08-28 at 21:13 +0100, Chris Wilson wrote:
> > Quoting Souza, Jose (2019-08-28 21:11:53)
> > > Reviewed-by: José Roberto de Souza
> >
> > It's using a non-standard for i915 error code, and get_tiling is not
>
> Huum shoul
On 28/08/2019 22:41, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-08-28 15:33:26)
+ rq = i915_request_create(i915->engine[RCS0]->kernel_context);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ err = i915_active_request_set(&i915->engine[RCS0]->last_oa_config,
On Wed, 28 Aug 2019, Manasi Navare wrote:
> Thanks Jani for your feedback, please see my comments inline
>
> On Wed, Aug 28, 2019 at 10:46:44AM +0300, Jani Nikula wrote:
>> On Tue, 27 Aug 2019, Manasi Navare wrote:
>> > On Tue, Aug 27, 2019 at 01:34:15PM +0300, Jani Nikula wrote:
>> >> On Tue, 27
On 28/08/2019 22:39, Chris Wilson wrote:
Quoting kbuild test robot (2019-08-28 20:34:14)
Hi Lionel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to v5.3-rc6 next-20190828]
[if your patch is applied to the wrong git
On 29/08/2019 08:26, Zhou, David(ChunMing) wrote:
v6 is fine to me as well, RB on it to go ahead.
Out of curious, why " [PATCH v11 01/10] " is on subject?
v11 is the series on the intel-gfx mailing list which depends on the
timeline semaphore feature in our driver.
That's why I included th
Hi Dave and Daniel, fixes for v5.3-rc7, all cc: stable.
drm-intel-fixes-2019-08-29:
drm/i915 fixes for v5.3-rc7:
- Fix DP MST max BPC property creation after DRM register
- Fix unused ggtt deballooning and NULL dereference in guest
- Fix DSC eDP transcoder identification
- Fix WARN from DMA API d
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev12)
URL : https://patchwork.freedesktop.org/series/60916/
State : failure
== Summary ==
Applying: drm/syncobj: add sideband payload
error: sha1 information is lacking or useless (drivers/gpu/drm/drm_internal.h).
error:
v6 is fine to me as well, RB on it to go ahead.
Out of curious, why " [PATCH v11 01/10] " is on subject?
-David
-Original Message-
From: Lionel Landwerlin
Sent: Wednesday, August 28, 2019 10:33 PM
To: intel-gfx@lists.freedesktop.org
Cc: Lionel Landwerlin ; Zhou, David(ChunMing)
; Koen
== Series Details ==
Series: Transcoder Port Sync preparation refactoring/renaming (rev2)
URL : https://patchwork.freedesktop.org/series/65899/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6800 -> Patchwork_14218
Summary
-
On 2019-08-28 at 23:23:42 +0530, Winkler, Tomas wrote:
> > FW
> >
> > I915 converts it's port value into ddi index defiend by ME FW and pass it
> > as a
> > member of hdcp_port_data structure.
> >
> > Hence expose the enum mei_fw_ddi to I915 through i915_mei_interface.h.
> >
> > v2:
> > Copyr
Hi Lionel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.3-rc6 next-20190828]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Janusz,
On 8/28/19 10:17 PM, Janusz Krzysztofik wrote:
We should avoid kernel panic when a intel_unmap() is called against
a non-existent domain.
Does that mean you suggest to replace
BUG_ON(!domain);
with something like
if (WARN_ON(!domain))
return;
and to no
On Fri, Aug 23, 2019 at 01:20:53AM -0700, Lucas De Marchi wrote:
> From: Dhinakaran Pandiyan
>
> Gen-12 decompression is supported with Y-tiled main surface. The CCS is
> linear and has 4 bits of data for each main surface cache line pair, a
> ratio of 1:256. Gen-12 display decompression is incom
On Wed, Aug 28, 2019 at 04:04:01PM -0700, Matt Roper wrote:
On Fri, Aug 23, 2019 at 01:20:51AM -0700, Lucas De Marchi wrote:
From: Dhinakaran Pandiyan
Yf tiling was removed in gen-12, make the necessary to changes to not
expose the modifier to user space. Gen-12 display also is incompatible wi
== Series Details ==
Series: drm/i915: add port info to debugfs (rev2)
URL : https://patchwork.freedesktop.org/series/65695/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6786_full -> Patchwork_14191_full
Summary
---
== Series Details ==
Series: Transcoder Port Sync preparation refactoring/renaming (rev2)
URL : https://patchwork.freedesktop.org/series/65899/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f857f08fb9b0 drm/i915/display: Rename update_crtcs() to commit_modeset_enables()
f9427f4
On Fri, Aug 23, 2019 at 01:20:51AM -0700, Lucas De Marchi wrote:
> From: Dhinakaran Pandiyan
>
> Yf tiling was removed in gen-12, make the necessary to changes to not
> expose the modifier to user space. Gen-12 display also is incompatible with
> pre-gen12 Y-tiled compression, so do not expose
>
Sending the PR for the latest ICL DMC-
The following changes since commit 7307a29961ad2765ebcad162da699d2497c5c3f8:
brcm: Add 43455 based AP6255 NVRAM for the Minix Neo Z83-4 Mini PC
(2019-08-27 08:04:55 -0400)
are available in the Git repository at:
https://cgit.freedesktop.org/drm/drm-fi
Create a new function intel_commit_modeset_disables() consistent with the naming
in drm atomic helpers and similar to the enable function.
This helps better organize the disable sequence in atomic_commit_tail()
No functional change
v4:
* Do not create a function pointer, just a function (Maarten)
On Wed, Aug 28, 2019 at 07:29:38PM +0300, Imre Deak wrote:
On Tue, Aug 27, 2019 at 09:50:24AM -0700, Lucas De Marchi wrote:
On Mon, Aug 26, 2019 at 08:28:33PM +0300, Imre Deak wrote:
> On Fri, Aug 23, 2019 at 01:20:35AM -0700, Lucas De Marchi wrote:
> > From: José Roberto de Souza
> >
> > It wa
BTW, this patch should be enough for
https://bugs.freedesktop.org/show_bug.cgi?id=110943, because we disable
interrupts on _stop and therefore we don't leave them enabled even if we
skip fini_hw (which still needs to be fixed for the submission side of
things).
Daniele
On 8/28/19 1:47 PM, Da
On 28/08/2019 16:19, Chris Wilson wrote:
> Quoting Chris Clayton (2019-08-28 16:14:20)
>> Hi,
>>
>> I've just copying 319G of data from a partition on one USB-attached
>> (/dev/sdb3) to a partition on another USB-attached
>> drive (/dev/sdc1). It's not quite finished but as it's progressed, I ha
On 29-Aug-19 2:18 AM, Sharma, Swati2 wrote:
On 28-Aug-19 9:38 PM, Shankar, Uma wrote:
-Original Message-
From: Sharma, Swati2
Sent: Monday, August 26, 2019 11:56 AM
To:intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani; Sharma, Shashank
; Manna, Animesh;
Nautiyal, Ankit K;daniel.vet...@ffw
== Series Details ==
Series: drm/i915: fix broadwell EU computation (rev2)
URL : https://patchwork.freedesktop.org/series/52355/
State : failure
== Summary ==
Applying: drm/i915: fix broadwell EU computation
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/intel_devi
On 29/08/2019 00:02, Rodrigo Vivi wrote:
From: Lionel Landwerlin
commit 6a67a20366f894c172734f28c5646bdbe48a46e3 upstream.
subslice_mask is an array indexed by slice, not subslice.
Signed-off-by: Lionel Landwerlin
Fixes: 8cc7669355136f ("drm/i915: store all subslice masks")
Bugzilla: https:/
From: Lionel Landwerlin
commit 6a67a20366f894c172734f28c5646bdbe48a46e3 upstream.
subslice_mask is an array indexed by slice, not subslice.
Signed-off-by: Lionel Landwerlin
Fixes: 8cc7669355136f ("drm/i915: store all subslice masks")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10871
On 28-Aug-19 9:38 PM, Shankar, Uma wrote:
-Original Message-
From: Sharma, Swati2
Sent: Monday, August 26, 2019 11:56 AM
To: intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani ; Sharma, Shashank
; Manna, Animesh ;
Nautiyal, Ankit K ; daniel.vet...@ffwll.ch;
ville.syrj...@linux.intel.com;
On 8/27/19 5:45 PM, Fernando Pacheco wrote:
During normal driver unload we attempt to disable GuC communication
while it is currently stopped. This results in a nop'd call to
intel_guc_ct_disable within guc_disable_communication because
stop/disable rely on the same flag to prevent further comm
On Wed, 2019-08-28 at 21:13 +0100, Chris Wilson wrote:
> Quoting Souza, Jose (2019-08-28 21:11:53)
> > Reviewed-by: José Roberto de Souza
>
> It's using a non-standard for i915 error code, and get_tiling is not
Huum should it use ENOTSUPP then?!
> affected, it will always return LINEAR. You can
On 28-Aug-19 9:25 PM, Shankar, Uma wrote:
-Original Message-
From: Sharma, Swati2
Sent: Monday, August 26, 2019 11:56 AM
To: intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani ; Sharma, Shashank
; Manna, Animesh ;
Nautiyal, Ankit K ; daniel.vet...@ffwll.ch;
ville.syrj...@linux.intel.com;
Quoting Souza, Jose (2019-08-28 21:11:53)
> Reviewed-by: José Roberto de Souza
It's using a non-standard for i915 error code, and get_tiling is not
affected, it will always return LINEAR. You cannot set tiling as there
is no fence (according to the new abi).
-Chris
___
Reviewed-by: José Roberto de Souza
Pushing this one in a few minutes.
On Thu, 2019-08-22 at 14:25 -0500, Jason Ekstrand wrote:
> Acked-by: Jason Ekstrand
>
> On Wed, Aug 21, 2019 at 10:20 AM Daniel Vetter <
> daniel.vet...@ffwll.ch> wrote:
> > On Wed, Aug 21, 2019 at 3:55 PM Ville Syrjälä
> >
Thanks for the patch and reviews, pushed to dinq
Regards
Manasi
On Thu, Aug 22, 2019 at 05:46:55PM -0700, Madhumitha Tolakanahalli Pradeep
wrote:
> DSC was not supported on Pipe A for previous platforms. Tigerlake onwards,
> all the pipes support DSC. Hence, the DSC and FEC restriction on
> Pipe
Hi Lionel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to v5.3-rc6 next-20190827]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Thanks Jani for your feedback, please see my comments inline
On Wed, Aug 28, 2019 at 10:46:44AM +0300, Jani Nikula wrote:
> On Tue, 27 Aug 2019, Manasi Navare wrote:
> > On Tue, Aug 27, 2019 at 01:34:15PM +0300, Jani Nikula wrote:
> >> On Tue, 27 Aug 2019, "Nautiyal, Ankit K"
> >> wrote:
> >> >
Quoting Lionel Landwerlin (2019-08-28 15:33:26)
> + rq = i915_request_create(i915->engine[RCS0]->kernel_context);
> + if (IS_ERR(rq))
> + return PTR_ERR(rq);
> +
> + err = i915_active_request_set(&i915->engine[RCS0]->last_oa_config,
> +
Quoting kbuild test robot (2019-08-28 20:34:14)
> Hi Lionel,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on drm-intel/for-linux-next]
> [cannot apply to v5.3-rc6 next-20190828]
> [if your patch is applied to the wrong git tree, ple
Hi Lionel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to v5.3-rc6 next-20190828]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
Hi Dave and Danvet,
drm-misc-fixes for v5.3, enjoy!
drm-misc-fixes-2019-08-28:
drm-misc-fixes for v5.3 (rc7?):
- Make qxl reservel the vga ports using vgaargb to prevent switching to vga
compatibility mode.
- Fix omap port lookup for SDI output
- Use virtio_max_dma_size to fix an issue with swio
Now I'm reading this other patch about DG1 ' drm/i915/dg1: Initialize DDI ports
for DG1' , is this condition still correct here?
Is the condition 'INTEL_GEN(dev_priv) >= 12' sufficient ?
>
> >From Gen12 onwards, HDCP HW block is implemented within transcoders.
> Till Gen11 HDCP HW block was part
Reviewed-by: Lyude Paul
On Wed, 2019-08-28 at 13:20 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> My attempt at allowing MST to use the higher color depths has
> regressed some configurations. Apparently people have setups
> where all MST streams will fit into the DP link with 8bpc but
From: Ville Syrjälä
Reogranize the HDMI deep color state computation to just
loop over possible bpc values. Avoids having to maintain
so many variants of the clock etc.
The current code also looks confused w.r.t. port_clock vs.
bw_constrained. It would happily update port_clock for
deep color bu
On 8/28/2019 12:40 AM, Animesh Manna wrote:
Gamma lut programming can be programmed using DSB
where bulk register programming can be done using indexed
register write which takes number of data and the mmio offset
to be written.
v1: Initial version.
v2: Directly call dsb-api at callsites. (Jani
Quoting Chris Wilson (2019-08-28 14:09:23)
> Quoting Mika Kuoppala (2019-08-28 13:49:55)
> > Chris Wilson writes:
> >
> > > Quite rarely we see that the CS completion event fires before the
> > > breadcrumb is coherent, which presumably is a result of the CS_STALL not
> > > waiting for the post-s
> FW
>
> I915 converts it's port value into ddi index defiend by ME FW and pass it as a
> member of hdcp_port_data structure.
>
> Hence expose the enum mei_fw_ddi to I915 through i915_mei_interface.h.
>
> v2:
> Copyright years are bumped [Tomas]
>
> Signed-off-by: Ramalingam C
> Acked-by: Ja
If the object needs to be migrated, it may will need GPU relocs and so
have an exclusive fence showing up in the write domain.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_balancer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/i915/gem_exec_balancer.c b/t
On Tue, Aug 27, 2019 at 12:30:52PM +0300, Jani Nikula wrote:
> On Thu, 22 Aug 2019, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Reogranize the HDMI deep color state computation to just
> > loop over possible bpc values. Avoids having to maintain
> > so many variants of the clock etc.
> >
So here is the documentation, this resolves atleast one review comment
from me :)
- Shashank
On 8/28/2019 12:40 AM, Animesh Manna wrote:
Added docbook info regarding Display State Buffer(DSB) which
is added from gen12 onwards to batch submit display HW programming.
v1: Initial version as RFC.
On 8/28/2019 12:40 AM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated simultane
== Series Details ==
Series: drm/i915/selftests: Remove accidental serialization between gpu_fill
URL : https://patchwork.freedesktop.org/series/65886/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6794_full -> Patchwork_14203_full
=
On Tue, Aug 27, 2019 at 03:17:34PM -0700, Manasi Navare wrote:
> This patch has no functional changes. This just renames the update_crtcs()
> hooks to commit_modeset_enables() to match the drm_atomic helper naming
> conventions.
Maarten, do you also want to avoid having a separate hook here for en
On Wed, Aug 28, 2019 at 08:30:23AM +0200, Maarten Lankhorst wrote:
> Op 28-08-2019 om 00:17 schreef Manasi Navare:
> > Create a new hook commit_modeset_disables() consistent with the naming
> > in drm atomic helpers and similar to the commit_modeset_enables() hook.
> > This helps better organize th
On 8/28/2019 12:40 AM, Animesh Manna wrote:
DSB will be used for performance improvement for some special scenario.
DSB engine will be enabled based on need and after completion of its work
will be disabled. Api added for enable/disable operation by using DSB_CTRL
register.
Cc: Michel Thierry
On 8/28/2019 12:40 AM, Animesh Manna wrote:
Added key register definitions of DSB.
dsb-ctrl register is required to enable dsb-engine.
head-ptr register hold the head of buffer address from where the
execution will start.
Programming tail-ptr register is a trigger point to start execution.
C
On Mon, 26 Aug 2019 at 08:22, Chris Wilson wrote:
>
> Trust our own workers to not cause unnecessary delays and disable the
> automatic timeout on their asynchronous fence waits. (Along the same
> lines that we trust our own requests to complete eventually, if
> necessary by force.)
>
> Signed-off
On 2019-08-28 at 22:12:10 +0530, Ramalingam C wrote:
> Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
> from DDI into transcoder.
>
> v12:
> r-b and ack are collected.
> few review comments are addressed.
Tomas,
Thanks for reviewing the patches and providing the Ack/
On 8/28/2019 12:40 AM, Animesh Manna wrote:
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. Will be using for bulk register programming
Reshuffle-> This feature can be used for bulk register programming e.g.
e.g. gamma lut programming, HDR meta data p
I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_tc and add as a member into
the struct hdcp_port_data.
v2:
Typo in commit msg is fixed [Shashank]
v3:
kdoc is added for mei_fw_tc [Tomas]
s/MEI_TC_x/MEI_TRANSCODER_x
Signed-off-by: Ramalingam C
I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.
Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.
v2:
Copyright years are bumped [Tomas]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
Reviewed-by: Shas
We dont need the definition of the enum port outside I915, anymore.
Hence move enum port definition into I915 driver itself.
v2:
intel_display.h is included in intel_hdcp.h
v3:
enum port is declared in headers.
v4:
commit msg is rephrased.
v5:
copyright year is updated [Tomas]
Signed-off-
For gen12+ platform we need to pass the transcoder info
as part of the port info into ME FW.
This change fills the payload for ME FW from hdcp_port_data.
v2:
Doc is enhanced for physical_port and attached_transcoder [Tomas]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
Reviewed-by: Shash
>From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in hdcp_port_dat
On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.
v2:
s/trans/cpu_transcoder [Jani]
v3:
comment is added for fw_ddi init for gen12+ [Shashank]
only hdcp capable transcoder is translated into fw_t
Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
from DDI into transcoder.
v12:
r-b and ack are collected.
few review comments are addressed.
Ramalingam C (6):
drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
drm: Move port definition back to i915 header
drm:
On Fri, Aug 23, 2019 at 12:49:46PM +0300, Simon Ser wrote:
> This patch adds a line with the port name to connectors in
> debugfs/i915_debug_info. If the port is Type-C, the Type-C port number is
> printed too.
>
> Signed-off-by: Simon Ser
> Cc: Imre Deak
> Cc: Manasi Navare
> Reviewed-by: Imre
On Sat, Aug 24, 2019 at 04:27:14PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Align power domain names with port names (rev2)
> URL : https://patchwork.freedesktop.org/series/65682/
> State : success
Thanks for the review, pushed to -dinq.
>
> == Summary ==
>
> CI B
>-Original Message-
>From: Sharma, Swati2
>Sent: Monday, August 26, 2019 11:56 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Nikula, Jani ; Sharma, Shashank
>; Manna, Animesh ;
>Nautiyal, Ankit K ; daniel.vet...@ffwll.ch;
>ville.syrj...@linux.intel.com; Shankar, Uma ; Sharma,
>Swati2
>Sub
On Tue, Aug 27, 2019 at 09:50:24AM -0700, Lucas De Marchi wrote:
> On Mon, Aug 26, 2019 at 08:28:33PM +0300, Imre Deak wrote:
> > On Fri, Aug 23, 2019 at 01:20:35AM -0700, Lucas De Marchi wrote:
> > > From: José Roberto de Souza
> > >
> > > It was enabling and checking PSR interruptions in every
On Tue, Aug 27, 2019 at 01:45:16AM -0700, Dhinakaran Pandiyan wrote:
> Yf tiling was removed in gen-12, so do not expose Yf modifiers to user
> space. Gen-12 display also is incompatible with pre-gen12 Y-tiled
> CCS, so do not expose I915_FORMAT_MOD_Y_TILED_CCS.
>
> v2: Rebase to carry forward rec
>-Original Message-
>From: Sharma, Swati2
>Sent: Monday, August 26, 2019 11:56 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Nikula, Jani ; Sharma, Shashank
>; Manna, Animesh ;
>Nautiyal, Ankit K ; daniel.vet...@ffwll.ch;
>ville.syrj...@linux.intel.com; Shankar, Uma ; Sharma,
>Swati2
>Sub
Switch to using sw_sync to avoid the builtin timeout on vgem's fences.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_exec_schedule.c | 157 -
1 file changed, 95 insertions(+), 62 deletions(-)
diff --git a/tests/i915/gem_exec_schedule.c b/tests
>-Original Message-
>From: Sharma, Swati2
>Sent: Monday, August 26, 2019 11:56 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Nikula, Jani ; Sharma, Shashank
>; Manna, Animesh ;
>Nautiyal, Ankit K ; daniel.vet...@ffwll.ch;
>ville.syrj...@linux.intel.com; Shankar, Uma ; Sharma,
>Swati2
>Sub
>-Original Message-
>From: Intel-gfx On Behalf Of Shankar,
>Uma
>Sent: Wednesday, August 28, 2019 9:38 PM
>To: Sharma, Swati2 ; intel-gfx@lists.freedesktop.org
>Cc: Nikula, Jani ; daniel.vet...@ffwll.ch; Nautiyal,
>Ankit K
>
>Subject: Re: [Intel-gfx] [v8][PATCH 06/10] drm/i91/display: E
On Mon, 26 Aug 2019 at 14:38, Chris Wilson wrote:
>
> We've been ignoring similar coherency issues in IGT for Broadwater, and
> specifically Broadwater (original gen4) and not, for example, Crestline
> (same generation as Broadwater, but the mobile variant). Without any
> means to reproduce locall
>-Original Message-
>From: Sharma, Swati2
>Sent: Monday, August 26, 2019 11:56 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Nikula, Jani ; Sharma, Shashank
>; Manna, Animesh ;
>Nautiyal, Ankit K ; daniel.vet...@ffwll.ch;
>ville.syrj...@linux.intel.com; Shankar, Uma ; Sharma,
>Swati2
>Sub
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev11)
URL : https://patchwork.freedesktop.org/series/60916/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.
On Tue, 27 Aug 2019 at 15:58, Chris Wilson wrote:
>
> If we are writing the relocations using the GPU they will not be written
> into the batch immediately. Instead there will be a write-fence while
> the relocation is being performed, giving us something to conveniently
> wait upon.
>
> Signed-of
>-Original Message-
>From: Sharma, Swati2
>Sent: Monday, August 26, 2019 11:56 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Nikula, Jani ; Sharma, Shashank
>; Manna, Animesh ;
>Nautiyal, Ankit K ; daniel.vet...@ffwll.ch;
>ville.syrj...@linux.intel.com; Shankar, Uma ; Sharma,
>Swati2
>Sub
>-Original Message-
>From: Sharma, Swati2
>Sent: Monday, August 26, 2019 11:56 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Nikula, Jani ; Sharma, Shashank
>; Manna, Animesh ;
>Nautiyal, Ankit K ; daniel.vet...@ffwll.ch;
>ville.syrj...@linux.intel.com; Shankar, Uma ; Sharma,
>Swati2
>Sub
== Series Details ==
Series: linux-next: build failure after merge of the drm-misc tree
URL : https://patchwork.freedesktop.org/series/65916/
State : failure
== Summary ==
Applying: linux-next: build failure after merge of the drm-misc tree
Using index info to reconstruct a base tree...
M
>-Original Message-
>From: Sharma, Swati2
>Sent: Monday, August 26, 2019 11:56 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Nikula, Jani ; Sharma, Shashank
>; Manna, Animesh ;
>Nautiyal, Ankit K ; daniel.vet...@ffwll.ch;
>ville.syrj...@linux.intel.com; Shankar, Uma ; Sharma,
>Swati2
>Sub
Quoting Chris Clayton (2019-08-28 16:14:20)
> Hi,
>
> I've just copying 319G of data from a partition on one USB-attached
> (/dev/sdb3) to a partition on another USB-attached
> drive (/dev/sdc1). It's not quite finished but as it's progressed, I have
> been reading email and browsing web sites,
On 8/28/2019 12:40 AM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Si
Hi,
I've just copying 319G of data from a partition on one USB-attached (/dev/sdb3)
to a partition on another USB-attached
drive (/dev/sdc1). It's not quite finished but as it's progressed, I have been
reading email and browsing web sites, so
switching between windows from time to time.
I found
On Wed, 2019-08-28 at 10:34 +0100, Chris Wilson wrote:
> Quoting Stuart Summers (2019-08-28 00:14:35)
> > Add a new module parameter, ring_mask, to allow for disabling
> > engines during i915 load. This mask follows the intel_engine_id
> > enum and can be used to hide specified engines from i915 an
On Wed, Aug 14, 2019 at 12:44:59PM +0200, Dariusz Marcinkiewicz wrote:
> Pass the connector info to the CEC adapter. This makes it possible
> to associate the CEC adapter with the corresponding drm connector.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Signed-off-by: Hans Verkuil
> Tested-by: Han
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: f1477219869c drm/i915: Remove the 8bpc shackles from DP MST.
The bot has tested the following trees: v5.2.10.
v5.2.10: Failed to apply! Possible dependencies:
Unable to calcula
== Series Details ==
Series: drm/i915: Enable HDCP 1.4 and 2.2 on Gen12+ (rev9)
URL : https://patchwork.freedesktop.org/series/63432/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fe0b94ff1a36 drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
2611f3e340d7 drm: Move port def
On 8/28/2019 12:40 AM, Animesh Manna wrote:
The function will internally get the gem buffer from global GTT
This patch adds a function, which will internally get the gem buffer for
DSB engine.
which is mapped in cpu domain to feed the data + opcode for DSB engine.
This GEM buffer is from globa
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
---
We haven't run into issues with programming the global OA/NOA
registers configuration from CPU so far, but HW engineers actually
recommend doing this from the command streamer. On TGL in particular
one of the clock domain in which some of that programming goes might
not be powered when we poke thin
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
v
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process m
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use BIT_UL
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particu
NOA configuration take some amount of time to apply. That amount of
time depends on the size of the GT. There is no documented time for
this. For example, past experimentations with powergating
configuration changes seem to indicate a 60~70us delay. We go with
500us as default for now which should
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack of
Reporting this version will help application figure out what level of
the support the running kernel provides.
v2: Add i915_perf_ioctl_version() (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_getparam.c | 4
drivers/gpu/drm/i915/i915_perf
Hi all,
This is a rebase on top of some of the i915/perf refactoring that
landed. It also changes a few things to allocate BOs onto the
i915_perf_stream to make the landed refactoring. It also makes things
a bit less contentious on global state :)
As the previous iterations of this series, this a
1 - 100 of 151 matches
Mail list logo
