Hi Dave and Daniel,
this is the forth pull request for drm-misc-next for what will become v5.8.
It's fairly small number of patches without major changes. There's one fix
to the UAPI headers, but it only affects comments.
Best regards
Thomsa
drm-misc-next-2020-05-14:
drm-misc-next for 5.8:
UAPI
On Thu, May 14, 2020 at 8:42 AM Daniel Stone wrote:
>
> On Wed, 8 Apr 2020 at 17:24, Daniel Vetter wrote:
> > Resending because last attempt failed CI and meanwhile the results are
> > lost :-/
>
> Did anything happen with this?
Nope. There's an igt now that fails with this, and I'm not sure
whe
Hi
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> There's no direct harm, because for the shmem helpers these are noops
> on imported buffers. The trouble is in the locks these take - I want
> to change dma_buf_vmap locking, and so need to make sure that we only
> ever take certain locks on one sid
Hi,
On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote:
> > Did anything happen with this?
>
> Nope. There's an igt now that fails with this, and I'm not sure
> whether changing the igt is the right idea or not.
>
> I'm kinda now thinking about changing this to instead document under
> which exact
== Series Details ==
Series: drm/i915: Show per-engine default property values in sysfs (rev2)
URL : https://patchwork.freedesktop.org/series/76396/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8481 -> Patchwork_17655
Summ
Hi
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> Currently this seems to work by converting the sgt into a pages array,
> and then treating it like a native object. Do the right thing and
> redirect mmap to the exporter.
>
> With this nothing is calling get_pages anymore on imported dma-buf,
> an
Hi,
given the upcoming removal of this file, I don't know if you really want
to merge this patch. If so, please see my comment on patch 6 and
Acked-by: Thomas Zimmermann
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> There's no direct harm, because for the shmem helpers these are noops
> on impo
On Thu, May 14, 2020 at 9:18 AM Daniel Stone wrote:
>
> Hi,
>
> On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote:
> > > Did anything happen with this?
> >
> > Nope. There's an igt now that fails with this, and I'm not sure
> > whether changing the igt is the right idea or not.
> >
> > I'm kinda
Hi
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> Just a bit of light paranoia. Also sprinkle this check over
> drm_gem_shmem_get_sg_table, which should only be called when
> exporting, same for the pin/unpin functions, on which it relies to
> work correctly.
>
> Cc: Gerd Hoffmann
> Cc: Rob Herri
Hi!
Here's this week's drm-misc-fixes PR
Maxime
drm-misc-fixes-2020-05-14:
Just one meson patch this time to propagate an error code
The following changes since commit 5fe89a6acd668cbd1817fcdef5caa9fee568c2e8:
drm: Fix HDCP failures when SRM fw is missing (2020-05-05 14:01:53 -0400)
are avai
On Thu, 14 May 2020 at 08:25, Daniel Vetter wrote:
> On Thu, May 14, 2020 at 9:18 AM Daniel Stone wrote:
> > On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote:
> > I'd be very much in favour of putting the blocking down in the kernel
> > at least until the kernel can give us a clear indication t
Hi
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> - Ditch the ->pages array
> - Make it a private gem bo, which means no shmem object, which means
> fireworks if anyone calls drm_gem_object_get_pages. But we've just
> made sure that's all covered.
>
> Cc: Gerd Hoffmann
> Cc: Rob Herring
> Cc
We need each test in an isolated context, so that bad results from one
test do not interfere with the next. In particular, we want to clean up
the device and reset it to the defaults so that they are known for the
next test, and the test can focus on behaviour it wants to control.
Signed-off-by: C
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> No real functional change, since this just converts an annoying Oops
> into a more harmless WARNING backtrace. It's still a driver bug.
>
> Signed-off-by: Daniel Vetter
Acked-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem.c | 8
>
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> drm_gem_shmem_get_sg_table is meant to implement
> obj->funcs->get_sg_table, for prime exporting. The one we want is
> drm_gem_shmem_get_pages_sgt, which also handles imported dma-buf, not
> just native objects.
>
> v2: Rebase, this stuff moved aroun
Flip the switch and enable SAGV support
for Gen12 also.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f34dca8b13fb..f4469d730d9b 100644
--- a/dr
Starting from TGL we need to have a separate wm0
values for SAGV and non-SAGV which affects
how calculations are done.
v2: Remove long lines
v3: Removed COLOR_PLANE enum references
v4, v5, v6: Fixed rebase conflict
v7: - Removed skl_plane_wm_level accessor from skl_allocate_pipe_ddb(Ville)
- R
For Gen11+ platforms BSpec suggests disabling specific
QGV points separately, depending on bandwidth limitations
and current display configuration. Thus it required adding
a new PCode request for disabling QGV points and some
refactoring of already existing SAGV code.
Also had to refactor intel_can
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
v2: Fixed wrong PCode reply mask, removed hardcoded
values.
v3: Forbid si
Chris Wilson writes:
> While this does not appear to fix any issues, the backend itself knows
> when it wants to emit a breadcrumb, so let it make the final call.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/selftests/i915_perf.c | 3 +--
> driver
Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
function which also includes pinning and map in cpu domain.
No functional change is dsb write/commit functions.
Now dsb get/put function is removed and ref-count mechanism is
not needed. Below dsb api added to do respective job
On 13/05/2020 08:47, Chris Wilson wrote:
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrumb lock on the first. So in commit 6c81e21a4742
("drm/i915/gt: Stage the transfer of the
== Series Details ==
Series: In order to readout DP SDPs, refactors the handling of DP SDPs (rev14)
URL : https://patchwork.freedesktop.org/series/72853/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8481_full -> Patchwork_17654_full
===
== Series Details ==
Series: SAGV support for Gen12+ (rev38)
URL : https://patchwork.freedesktop.org/series/75129/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4806d3748f45 drm/i915: Add TGL+ SAGV support
-:250: WARNING:LONG_LINE: line over 100 characters
#250: FILE: drivers/g
On Thu, 14 May 2020, Animesh Manna wrote:
> Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
> function which also includes pinning and map in cpu domain.
>
> No functional change is dsb write/commit functions.
>
> Now dsb get/put function is removed and ref-count mechanism is
== Series Details ==
Series: SAGV support for Gen12+ (rev38)
URL : https://patchwork.freedesktop.org/series/75129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8483 -> Patchwork_17656
Summary
---
**SUCCESS**
No r
== Series Details ==
Series: drm/i915: Show per-engine default property values in sysfs (rev2)
URL : https://patchwork.freedesktop.org/series/76396/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8481_full -> Patchwork_17655_full
On Wed, 13 May 2020, Anshuman Gupta wrote:
> HDCP code doesn't require to access power_well internal stuff,
> instead it should use the intel_display_power_well_is_enabled()
> to get the status of desired power_well.
> No functional change.
>
> Cc: Jani Nikula
> Signed-off-by: Anshuman Gupta
> -
On Monday, May 11, 2020 11:01:41 PM CEST Francisco Jerez wrote:
>
> --==-=-=
> Content-Type: multipart/mixed; boundary="=-=-="
>
> --=-=-=
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> Peter Zijlstra writes:
>
> > On M
== Series Details ==
Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev5)
URL : https://patchwork.freedesktop.org/series/73036/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8484 -> Patchwork_17657
Summa
Thanks Jani for review, added the changes in next version.
Regards,
Animesh
On 14-05-2020 14:51, Jani Nikula wrote:
On Thu, 14 May 2020, Animesh Manna wrote:
Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
function which also includes pinning and map in cpu domain.
No f
this patch adds hdr capabilities checks for Gen9 devices with
lspcon support.
This patch is dependent on patch series
https://patchwork.kernel.org/cover/11192807/
Signed-off-by: Vipin Anand
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 11 +--
1 file changed, 9 insertions(+), 2 delet
On Thu, 14 May 2020, Gwan-gyeong Mun wrote:
> In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
> Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
> It adds new compute routines for DP HDR Metadata Infoframe SDP
> and DP VSC SDP.
> And new writing routines of DP
Investigate the impact of timeslicing on the virtal request, both with
independent and dependent workloads.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_balancer.c | 101 +
1 file changed, 101 insertions(+)
diff --git a/tests/i915/gem_e
On Tue, May 12, 2020 at 9:12 AM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 4:14 AM Dave Airlie wrote:
> >
> > On Mon, 11 May 2020 at 19:37, Oded Gabbay wrote:
> > >
> > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter
> > > wrote:
> > > >
> > > > It's the default.
> > > Thanks for catchi
Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
function which also includes pinning and map in cpu domain.
No functional change is dsb write/commit functions.
Now dsb get/put function is removed and ref-count mechanism is
not needed. Below dsb api added to do respective job
== Series Details ==
Series: HDCP minor refactoring
URL : https://patchwork.freedesktop.org/series/77224/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8474_full -> Patchwork_17646_full
Summary
---
**SUCCESS**
No
Op 14-05-2020 om 13:27 schreef Animesh Manna:
> Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
> function which also includes pinning and map in cpu domain.
>
> No functional change is dsb write/commit functions.
>
> Now dsb get/put function is removed and ref-count mechanism
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gt: Suspend tasklets before
resume sanitization
URL : https://patchwork.freedesktop.org/series/77226/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8474_full -> Patchwork_17647_full
==
On Thu, May 14, 2020 at 08:40:21AM +0100, Daniel Stone wrote:
> On Thu, 14 May 2020 at 08:25, Daniel Vetter wrote:
> > On Thu, May 14, 2020 at 9:18 AM Daniel Stone wrote:
> > > On Thu, 14 May 2020 at 08:08, Daniel Vetter
> > > wrote:
> > > I'd be very much in favour of putting the blocking down
From: Ville Syrjälä
Document the fact that we aren't reading out the actual FSB
frequency but rather just the state of the FSB straps.
Some BIOSen allow you to configure the two independently.
So if someone sets the two up in an inconsistent manner
we'll get the wrong answer here and thus will en
From: Ville Syrjälä
I've checked a bunch of gen3/4 machines and all seem to have
consistent FSB frequency information in the CLKCFG register.
So let's read out hrawclk on all gen3+ machines. Although
apart from g4x/pnv aux/pps dividers we only really need this
for for i965g/gm cs timestamp increm
From: Ville Syrjälä
Looks like elk redefines some of the CLKCFG FSB values to
make room for 400 MHz FSB. The setting overlaps with one of
the 266MHz settings (which is even documented in the ctg docs,
and cofirmed to be correct on my ctg). So we limit the special
case to elk only.
Though it migh
(+Lukasz)
On 11/05/20 22:01, Francisco Jerez wrote:
>> What I'm missing is an explanation for why this isn't using the
>> infrastructure that was build for these kinds of things? The thermal
>> framework, was AFAIU, supposed to help with these things, and the IPA
>> thing in particular is used b
> Ok, but what does that mean for us?
>
> You need to say why you are sending a patch, otherwise we will guess wrong.
In drivers/gpu/drm/i915/i915_gem_execbuffer.c, ioctl functions does
user_access_begin() without doing access_ok(Checks if a user space pointer is
valid) first.
A local attacker
== Series Details ==
Series: drm:i915:display: add checks for Gen9 devices with hdr capability (rev2)
URL : https://patchwork.freedesktop.org/series/75114/
State : failure
== Summary ==
Applying: drm:i915:display: add checks for Gen9 devices with hdr capability
Using index info to reconstruct
On Thu, May 14, 2020 at 09:23:37AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > Currently this seems to work by converting the sgt into a pages array,
> > and then treating it like a native object. Do the right thing and
> > redirect mmap to the exporter
On Thu, May 14, 2020 at 09:25:18AM +0200, Thomas Zimmermann wrote:
> Hi,
>
> given the upcoming removal of this file, I don't know if you really want
> to merge this patch. If so, please see my comment on patch 6 and
Yeah I can wait for your patch to land, I just looked at that series. I'm
kinda
On Thu, May 14, 2020 at 09:16:54AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > There's no direct harm, because for the shmem helpers these are noops
> > on imported buffers. The trouble is in the locks these take - I want
> > to change dma_buf_vmap lock
On Thu, May 14, 2020 at 09:44:02AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > - Ditch the ->pages array
> > - Make it a private gem bo, which means no shmem object, which means
> > fireworks if anyone calls drm_gem_object_get_pages. But we've just
>
== Series Details ==
Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev6)
URL : https://patchwork.freedesktop.org/series/73036/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8485 -> Patchwork_17659
Summa
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Fix 400 MHz FSB readout on elk
URL : https://patchwork.freedesktop.org/series/77264/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8485 -> Patchwork_17660
== Series Details ==
Series: SAGV support for Gen12+ (rev38)
URL : https://patchwork.freedesktop.org/series/75129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8483_full -> Patchwork_17656_full
Summary
---
**SUCCESS
Quoting Dave Airlie (2020-05-14 04:28:17)
> On Thu, 14 May 2020 at 03:10, Joonas Lahtinen
> wrote:
> >
> > Ping for merging this? If there are no issues, I'd prefer to pull in
> > next gvt-next and tag the final pull sooner than later.
>
> Can you check that I'm correct and this isn;'t in patchwo
Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
function which also includes pinning and map in cpu domain.
No functional change is dsb write/commit functions.
Now dsb get/put function is removed and ref-count mechanism is
not needed. Below dsb api added to do respective job
The virtual timeslicing failed under a series of unfortunate events.
Suppose the user submitted a virtual request, over [vcs0, vcs1] and also
a request that dependent upon the result of the virtal request to vcs0.
submit {veng, vcs0}
time slice expires: unsubmit vcs0, veng
submit { vcs0 } # no tim
If we decide to timeslice out the current virtual request, we will
unsubmit it while it is still busy (ve->context.inflight == sibling[0]).
If the virtual tasklet and then the other sibling tasklets run before we
completely schedule out the active virtual request for the preemption,
those other tas
It was quite the oversight to only factor in the normal queue to decide
the timeslicing switch priority. By leaving out the next virtual request
from the priority decision, we would not timeslice the current engine if
there was an available virtual request.
Testcase: igt/gem_exec_balancer/sliced
F
We need to calculate cdclk after watermarks/ddb has been calculated
as with recent hw CDCLK needs to be adjusted accordingly to DBuf
requirements, which is not possible with current code organization.
Setting CDCLK according to DBuf BW requirements and not just rejecting
if it doesn't satisfy BW r
From: Stanislav Lisovskiy
Checking with hweight8 if plane configuration had
changed seems to be wrong as different plane configs
can result in a same hamming weight.
So lets check the bitmask itself.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_display.c | 8 ++
The virtual timeslicing failed under a series of unfortunate events.
Suppose the user submitted a virtual request, over [vcs0, vcs1] and also
a request that dependent upon the result of the virtal request to vcs0.
submit {veng, vcs0}
time slice expires: unsubmit vcs0, veng
submit { vcs0 } # no tim
We quite often need now to iterate only particular dbuf slices
in mask, whether they are active or related to particular crtc.
v2: - Minor code refactoring
v3: - Use enum for max slices instead of macro
Let's make our life a bit easier and use a macro for that.
Signed-off-by: Stanislav Lisovskiy
From: Stanislav Lisovskiy
So lets support it.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
ind
According to BSpec max BW per slice is calculated using formula
Max BW = CDCLK * 64. Currently when calculating min CDCLK we
account only per plane requirements, however in order to avoid
FIFO underruns we need to estimate accumulated BW consumed by
all planes(ddb entries basically) residing on tha
In Gen11+ whenever we might exceed DBuf bandwidth we might need to
recalculate CDCLK which DBuf bandwidth is scaled with.
Total Dbuf bw used might change based on particular plane needs.
Thus to calculate if cdclk needs to be changed it is not enough
anymore to check plane configuration and plane
We need to calculate cdclk after watermarks/ddb has been calculated
as with recent hw CDCLK needs to be adjusted accordingly to DBuf
requirements, which is not possible with current code organization.
Setting CDCLK according to DBuf BW requirements and not just rejecting
if it doesn't satisfy BW r
No need to bump up CDCLK now, as it is now correctly
calculated, accounting for DBuf BW as BSpec says.
Reviewed-by: Manasi Navare
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i9
Hi
Am 14.05.20 um 14:55 schrieb Daniel Vetter:
> On Thu, May 14, 2020 at 09:44:02AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
>>> - Ditch the ->pages array
>>> - Make it a private gem bo, which means no shmem object, which means
>>> fireworks if anyo
fake_lmem_start does not need to be mutable via module param sysfs. It's
only used during driver probe.
Fixes: 1629224324b6 ("drm/i915/lmem: add the fake lmem region")
Cc: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_params.c | 2 +
The parameter only makes sense as a module parameter only.
Fixes: c43c5a8818d4 ("drm/i915/params: add i915 parameters to debugfs")
Cc: Juha-Pekka Heikkilä
Cc: Venkata Sandeep Dhanalakota
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1
Only support runtime changes through the debugfs.
i915.verbose_state_checks remains an exception, and is not exposed via
debugfs.
This depends on IGT having been updated to use the debugfs for modifying
the parameters.
Cc: Juha-Pekka Heikkilä
Cc: Venkata Sandeep Dhanalakota
Signed-off-by: Jani
Start using device specific parameters instead of module parameters for
most things. The module parameters become the immutable initial values
for i915 parameters. The device specific parameters in i915->params
start life as a copy of i915_modparams. Any later changes are only
reflected in the debu
According to BSpec max BW per slice is calculated using formula
Max BW = CDCLK * 64. Currently when calculating min CDCLK we
account only per plane requirements, however in order to avoid
FIFO underruns we need to estimate accumulated BW consumed by
all planes(ddb entries basically) residing on tha
> -Original Message-
> From: Intel-gfx On Behalf Of
> Anshuman Gupta
> Sent: Monday, March 30, 2020 9:43 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [CI v2] drm/i915/hdcp: Update CP as per the kernel
> internal
> state
>
> Content Protection property should be upda
Quoting Zhenyu Wang (2020-05-12 12:40:17)
>
> Hi,
>
> This includes support for ppgtt update by LRI command which gvt
> replaces by shadow ppgtt, another small optimization for shadow
> ctx and one workload destroy cleanup.
This is now pulled. Thanks for the PR.
Regards, Joonas
>
> Thanks
> -
On Thu, May 14, 2020 at 10:48:51AM +0300, Stanislav Lisovskiy wrote:
> Starting from TGL we need to have a separate wm0
> values for SAGV and non-SAGV which affects
> how calculations are done.
>
> v2: Remove long lines
> v3: Removed COLOR_PLANE enum references
> v4, v5, v6: Fixed rebase conflict
Make sure that we can execute a virtual request on an already busy
engine, and conversely that we can execute a normal request if the
engines are already fully occupied by virtual requests.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 182 +
1
Make sure that we can execute a virtual request on an already busy
engine, and conversely that we can execute a normal request if the
engines are already fully occupied by virtual requests.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 177 +
1
If we decide to timeslice out the current virtual request, we will
unsubmit it while it is still busy (ve->context.inflight == sibling[0]).
If the virtual tasklet and then the other sibling tasklets run before we
completely schedule out the active virtual request for the preemption,
those other tas
The virtual timeslicing failed under a series of unfortunate slices.
Suppose the user submitted a virtual request, over [vcs0, vcs1] and also
a request that dependent upon the result of the virtal request to vcs0.
submit {veng, vcs0}
time slice expires: unsubmit vcs0, veng
submit { vcs0 } # no tim
It was quite the oversight to only factor in the normal queue to decide
the timeslicing switch priority. By leaving out the next virtual request
from the priority decision, we would not timeslice the current engine if
there was an available virtual request.
Testcase: igt/gem_exec_balancer/sliced
F
Pushed using the note:: block. Thanks for the review and ack.
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Fix 400 MHz FSB readout on elk
URL : https://patchwork.freedesktop.org/series/77264/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8485_full -> Patchwork_17660_full
===
Hi Stanislav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20200514]
[cannot apply to drm-tip/drm-tip v5.7-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
From: Ville Syrjälä
To make it easier to figure out what caused a particular debug
message let's print out aux->name.
v2: Convert drm_dp_send_real_edid_checksum() too
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
IIRC Sam suggested that I switch to per-device logging functions at the
same
Hi Ville.
On Thu, May 14, 2020 at 09:40:40PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make it easier to figure out what caused a particular debug
> message let's print out aux->name.
>
> v2: Convert drm_dp_send_real_edid_checksum() too
>
> Cc: Sam Ravnborg
> Signed-off-by: Vil
Reviewed-by: Juha-Pekka Heikkila
On 14.5.2020 18.40, Jani Nikula wrote:
The parameter only makes sense as a module parameter only.
Fixes: c43c5a8818d4 ("drm/i915/params: add i915 parameters to debugfs")
Cc: Juha-Pekka Heikkilä
Cc: Venkata Sandeep Dhanalakota
Signed-off-by: Jani Nikula
---
Reviewed-by: Juha-Pekka Heikkila
On 14.5.2020 18.40, Jani Nikula wrote:
Only support runtime changes through the debugfs.
i915.verbose_state_checks remains an exception, and is not exposed via
debugfs.
This depends on IGT having been updated to use the debugfs for modifying
the parameters.
C
On Thu, May 14, 2020 at 06:21:40PM +0300, Stanislav Lisovskiy wrote:
> In Gen11+ whenever we might exceed DBuf bandwidth we might need to
> recalculate CDCLK which DBuf bandwidth is scaled with.
> Total Dbuf bw used might change based on particular plane needs.
>
> Thus to calculate if cdclk needs
On Thu, May 14, 2020 at 06:21:41PM +0300, Stanislav Lisovskiy wrote:
> From: Stanislav Lisovskiy
>
> Checking with hweight8 if plane configuration had
> changed seems to be wrong as different plane configs
> can result in a same hamming weight.
> So lets check the bitmask itself.
>
> Signed-off-
On Thu, May 14, 2020 at 06:21:42PM +0300, Stanislav Lisovskiy wrote:
> From: Stanislav Lisovskiy
>
> So lets support it.
>
> Signed-off-by: Stanislav Lisovskiy
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Thu, May 14, 2020 at 06:21:43PM +0300, Stanislav Lisovskiy wrote:
> We quite often need now to iterate only particular dbuf slices
> in mask, whether they are active or related to particular crtc.
>
> v2: - Minor code refactoring
> v3: - Use enum for max slices instead of macro
>
> Let's make
On Mon, May 11, 2020 at 01:12:49PM +0200, Thomas Zimmermann wrote:
>
>
> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > - Move the shmem helper section to the drm-mm.rst file, next to the
> > vram helpers. Makes a lot more sense there with the now wider scope.
> > Also, that's where the all
The logic seems fine, some comments below:
On Thu, May 14, 2020 at 06:43:37PM +0300, Stanislav Lisovskiy wrote:
> According to BSpec max BW per slice is calculated using formula
> Max BW = CDCLK * 64. Currently when calculating min CDCLK we
> account only per plane requirements, however in order t
If there are no internal levels and the user priority-shift is zero, we
can help the compiler eliminate some dead code:
Function old new delta
start_timeslice 169 154 -15
__execlists_submission_tasklet 4696
Make sure to select the port's AUX power domain while holding the TC
port lock. The domain depends on the port's current TC mode, which may
get changed under us if we're not holding the lock.
This was left out from
commit 8c10e2262663 ("drm/i915: Keep the TypeC port mode fixed for detect/AUX
tran
Reduce the irq_work llist for attaching the callbacks to the signal for
both smaller structs (two fewer pointers!) and simpler [debug] code:
Function old new delta
irq_execute_cb35 34 -1
__igt_breadcrumbs_smoketest
On Thu, 2020-05-14 at 23:45 +0300, Imre Deak wrote:
> Make sure to select the port's AUX power domain while holding the TC
> port lock. The domain depends on the port's current TC mode, which may
> get changed under us if we're not holding the lock.
>
> This was left out from
> commit 8c10e2262663
On Thu, May 14, 2020 at 06:40:04PM +0300, Jani Nikula wrote:
> fake_lmem_start does not need to be mutable via module param sysfs. It's
> only used during driver probe.
>
> Fixes: 1629224324b6 ("drm/i915/lmem: add the fake lmem region")
> Cc: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
On Thu, May 14, 2020 at 06:40:06PM +0300, Jani Nikula wrote:
> Start using device specific parameters instead of module parameters for
> most things. The module parameters become the immutable initial values
> for i915 parameters. The device specific parameters in i915->params
> start life as a cop
1 - 100 of 105 matches
Mail list logo
