On Tue, Jun 09, 2020 at 03:02:14PM +0200, Daniel Vetter wrote:
> Hi Eugeniy,
>
> Very much appreciated, and kinda expected. That 2nd backtrace really
> confuses me, so "something strange is going on" and the bisect looks
> funny is within expectations. Hopefully we can track down what's going
>
Quoting Tvrtko Ursulin (2020-07-17 09:13:21)
>
> On 16/07/2020 18:28, Chris Wilson wrote:
> > @@ -341,8 +325,10 @@ static void insert_breadcrumb(struct i915_request *rq,
> > break;
> > }
> > list_add(>signal_link, pos);
> > - if (pos == >signals) /* catch
On 16/07/2020 18:28, Chris Wilson wrote:
After staring at the breadcrumb enabling/cancellation and coming to the
conclusion that the cause of the mysterious stale breadcrumbs must the
act of submitting a completed requests, we can then redirect those
completed requests onto a dedicated
On 17/07/2020 04:57, Umesh Nerlige Ramappa wrote:
From: Piotr Maciejewski
OA reports can be triggered into the OA buffer by writing into the
OAREPORTTRIG registers. Whitelist the registers to allow user to trigger
reports.
Signed-off-by: Piotr Maciejewski
Signed-off-by: Umesh Nerlige Ramappa
Chris Wilson writes:
> Since we want to read the values from the HWSP as written to by the GPU,
> warn the compiler that the values are volatile.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Yes, for consistency (and accuracy) this should be nudged also, even
tho it is on the safe
to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Umesh-Nerlige-Ramappa/drm-i915-perf-Whitelist-OA-report-trigger-registers/20200717-095850
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386
On 16/07/2020 21:44, Chris Wilson wrote:
This is an attempt to chase down some preempt-to-busy races with
breadcrumb signaling on the virtual engines. By using more semaphore
spinners than available engines, we encourage very short timeslices, and
we make each batch of random duration to try
Chris Wilson writes:
> Add a SRM read back of the aux invalidation register after poking
> hsdes: 1809175790, as failing to do so leads to writes going astray.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2169
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
>
On 17/07/2020 04:57, Umesh Nerlige Ramappa wrote:
From: Piotr Maciejewski
It is useful to have markers in the OA reports to identify triggered
reports. Whitelist some OA counters that can be used as markers.
A triggered report can be found faster if we can sample the HW tail and
head
On 17/07/2020 09:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-17 09:13:21)
On 16/07/2020 18:28, Chris Wilson wrote:
@@ -341,8 +325,10 @@ static void insert_breadcrumb(struct i915_request *rq,
break;
}
list_add(>signal_link, pos);
- if (pos
On the virtual engines, we only use the intel_breadcrumbs for tracking
signaling of stale breadcrumbs from the irq_workers. They do not have
any associated interrupt handling, active requests are passed to a
physical engine and associated breadcrumb interrupt handler. This causes
issues for us as
== Series Details ==
Series: series starting with [1/4] drm/i915: Remove requirement for holding
i915_request.lock for breadcrumbs (rev2)
URL : https://patchwork.freedesktop.org/series/79589/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8760 -> Patchwork_18201
On 15/07/2020 12:50, Chris Wilson wrote:
We use i915_active_fini() as a debug check on the i915_active state
before freeing. If we forget to call it, we may end up angering the
debugobjects contained within.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_frontbuffer.c
On 15/07/2020 12:50, Chris Wilson wrote:
Rather than require the next timeline after idling to match the MRU
before idling, reset the index on the node and allow it to match the
first request. However, this requires cmpxchg(u64) and so is not trivial
on 32b, so for compatibility we just
Quoting Tvrtko Ursulin (2020-07-17 09:34:07)
>
> On 16/07/2020 21:44, Chris Wilson wrote:
> I am not sure if the batch duration is not too short in practice, the
> add loop will really rapidly end all, just needs 64 iterations on
> average to end all 32 I think. So 64 WC writes from the CPU
On 15/07/2020 12:50, Chris Wilson wrote:
Whenever an i915_active idles, we prune its tree of old fence slots to
prevent a gradual leak should it be used to track many, many timelines.
The downside is that we then have to frequently reallocate the rbtree.
A compromise is that we keep the most
Quoting Mika Kuoppala (2020-07-17 09:30:07)
> Chris Wilson writes:
>
> > Add a SRM read back of the aux invalidation register after poking
> > hsdes: 1809175790, as failing to do so leads to writes going astray.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2169
> >
== Series Details ==
Series: drm/i915: Disable connector polling at runtime suspend
URL : https://patchwork.freedesktop.org/series/79593/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8760 -> Patchwork_18202
Summary
Since the breadcrumb enabling/cancelling itself is serialised by the
breadcrumbs.irq_lock, with a bit of care we can remove the outer
serialisation with i915_request.lock for concurrent
dma_fence_enable_signaling(). This has the important side-effect of
eliminating the nested i915_request.lock
On the virtual engines, we only use the intel_breadcrumbs for tracking
signaling of stale breadcrumbs from the irq_workers. They do not have
any associated interrupt handling, active requests are passed to a
physical engine and associated breadcrumb interrupt handler. This causes
issues for us as
After staring at the breadcrumb enabling/cancellation and coming to the
conclusion that the cause of the mysterious stale breadcrumbs must the
act of submitting a completed requests, we can then redirect those
completed requests onto a dedicated signaled_list at the time of
construction and so
One more complication of preempt-to-busy with respect to the virtual
engine is that we may have retired the last request along the virtual
engine at the same time as preparing to submit the completed request to
a new engine. That submit will be shortcircuited, but not before we have
updated the
== Series Details ==
Series: drm/i915: Drop i915_request.lock serialisation around await_start
URL : https://patchwork.freedesktop.org/series/79588/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8760 -> Patchwork_18200
On 15/07/2020 12:50, Chris Wilson wrote:
> Sometimes we have to be very careful not to allocate underneath a mutex
> (or spinlock) and yet still want to track activity. Enter
> i915_active_acquire_for_context(). This raises the activity counter on
> i915_active prior to use and ensures that the
On 17/07/2020 13:45, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-17 13:21:54)
On 15/07/2020 12:50, Chris Wilson wrote:
Sometimes we have to be very careful not to allocate underneath a mutex
(or spinlock) and yet still want to track activity. Enter
i915_active_acquire_for_context().
Quoting Chris Wilson (2020-07-17 10:35:39)
> After staring at the breadcrumb enabling/cancellation and coming to the
> conclusion that the cause of the mysterious stale breadcrumbs must the
> act of submitting a completed requests, we can then redirect those
> completed requests onto a dedicated
While i915 device is in runtime suspend, DRM connector polling
causing device to wakeup from runtime suspend.
This harm overall cpu idle statistics, therefore
disabling polling while in runtime suspend.
Cc: Imre Deak
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_drv.c | 4
1
Quoting Tvrtko Ursulin (2020-07-17 13:21:54)
>
> On 15/07/2020 12:50, Chris Wilson wrote:
> > Sometimes we have to be very careful not to allocate underneath a mutex
> > (or spinlock) and yet still want to track activity. Enter
> > i915_active_acquire_for_context(). This raises the activity
== Series Details ==
Series: drm/i915: Drop i915_request.lock serialisation around await_start
URL : https://patchwork.freedesktop.org/series/79588/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: series starting with [1/4] drm/i915: Remove requirement for holding
i915_request.lock for breadcrumbs (rev2)
URL : https://patchwork.freedesktop.org/series/79589/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8f0edc6118db drm/i915: Remove
== Series Details ==
Series: series starting with [1/4] drm/i915: Remove requirement for holding
i915_request.lock for breadcrumbs (rev2)
URL : https://patchwork.freedesktop.org/series/79589/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8760_full -> Patchwork_18201_full
On 15/07/2020 12:50, Chris Wilson wrote:
If no active callback is defined for i915_active, we do not need to
serialise its enabling with the mutex. We still do only want to call the
debug activate once, and must still serialise with a concurrent retire.
Signed-off-by: Chris Wilson
---
On 17/07/2020 04:57, Umesh Nerlige Ramappa wrote:
From: Piotr Maciejewski
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
On 15/07/2020 12:50, Chris Wilson wrote:
Before we can execute a request, we must wait for all of its vma to be
bound. This is a frequent operation for which we can optimise away a
few atomic operations (notably a cmpxchg) in lieu of the RCU protection.
Signed-off-by: Chris Wilson
---
Originally, we used the signal->lock as a means of following the
previous link in its timeline and peeking at the previous fence.
However, we have replaced the explicit serialisation with a series of
very careful probes that anticipate the links being deleted and the
fences recycled before we are
== Series Details ==
Series: series starting with [1/4] drm/i915: Remove requirement for holding
i915_request.lock for breadcrumbs (rev2)
URL : https://patchwork.freedesktop.org/series/79589/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode
Quoting Anshuman Gupta (2020-07-17 13:04:25)
> While i915 device is in runtime suspend, DRM connector polling
> causing device to wakeup from runtime suspend.
> This harm overall cpu idle statistics, therefore
> disabling polling while in runtime suspend.
So what about the devices where there is
== Series Details ==
Series: drm/i915: Disable connector polling at runtime suspend
URL : https://patchwork.freedesktop.org/series/79593/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
From: Ville Syrjälä
Add a TODO for plumbing drm_atomic_state all over to ease
the hurdles of accessing additional object states.
Reviewed-by: Daniel Vetter #irc
Signed-off-by: Ville Syrjälä
---
Documentation/gpu/todo.rst | 46 ++
1 file changed, 46
On 15/07/2020 12:50, Chris Wilson wrote:
Remove the stub i915_vma_pin() used for incrementally pining objects for
execbuf (under the severe restriction that they must not wait on a
resource as we may have already pinned it) and replace it with a
i915_vma_pin_inplace() that is only allowed to
The i915 doesn't depend on IOSF_MBI, asm/iosf_mbi.h already defines
isof_mbi_* APIs when ISOF_MBI is disabled.
Don't force IOSF_MBI to allow disabling IOSF_MBI for non SoC platforms.
Signed-off-by: Jisheng Zhang
---
drivers/gpu/drm/i915/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git
On 17/07/2020 15:09, Chris Wilson wrote:
I915_GEM_THROTTLE dates back to the time before contexts where there was
just a single engine, and therefore a single timeline and request list
per file. That request list was in execution/retirement order, and so
walking it to find a particular aged
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
Changes in v5:
- Fix an indentation issue
Changes in v4:
- Use DIV_ROUND_UP when calculating the period and duty_cycle from the
== Series Details ==
Series: drm/i915: Disable connector polling at runtime suspend
URL : https://patchwork.freedesktop.org/series/79593/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8760_full -> Patchwork_18202_full
== Series Details ==
Series: drm/i915/gem: Remove disordered per-file request list for throttling
(rev4)
URL : https://patchwork.freedesktop.org/series/79600/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked
Hi All,
Here is v5 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below for the changelog.
This series consists of 4 parts:
1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 =
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /*
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input
== Series Details ==
Series: drm/i915/gem: Remove disordered per-file request list for throttling
(rev2)
URL : https://patchwork.freedesktop.org/series/79600/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked
== Series Details ==
Series: drm/todo: Plumb drm_atomic_state all over
URL : https://patchwork.freedesktop.org/series/79598/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8760_full -> Patchwork_18203_full
Summary
---
On Tue, Jul 14, 2020 at 07:32:36PM +0300, Imre Deak wrote:
> Apply Display WA #22010492432 for combo PHY PLLs too. This should fix a
> problem where the PLL output frequency is slightly off with the current
> PLL fractional divider value.
>
> I haven't seen an actual case where this causes a
I915_GEM_THROTTLE dates back to the time before contexts where there was
just a single engine, and therefore a single timeline and request list
per file. That request list was in execution/retirement order, and so
walking it to find a particular aged request made sense.
That is no more. We now
== Series Details ==
Series: drm/todo: Plumb drm_atomic_state all over
URL : https://patchwork.freedesktop.org/series/79598/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8760 -> Patchwork_18203
Summary
---
== Series Details ==
Series: drm/i915/gem: Remove disordered per-file request list for throttling
(rev4)
URL : https://patchwork.freedesktop.org/series/79600/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8760 -> Patchwork_18205
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
I strongly suspect that the BACKLIGHT_EN register at address 0x51 really
controls a separate output-only GPIO which is connected to the LCD panels
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.
I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Signed-off-by: Hans de Goede
---
Changes in v3:
- Keep crc_pwm_calc_clk_div() helper to avoid needless churn
---
drivers/pwm/pwm-crc.c | 89 ++-
1 file
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().
This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).
Acked-by: Jani Nikula
Signed-off-by: Hans
to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Umesh-Nerlige-Ramappa/drm-i915-perf-Whitelist-OA-report-trigger-registers/20200717-095850
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.
Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the
I915_GEM_THROTTLE dates back to the time before contexts where there was
just a single engine, and therefore a single timeline and request list
per file. That request list was in execution/retirement order, and so
walking it to find a particular aged request made sense.
That is no more. We now
== Series Details ==
Series: drm/i915/gem: Remove disordered per-file request list for throttling
(rev2)
URL : https://patchwork.freedesktop.org/series/79600/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8760 -> Patchwork_18204
Hi Chris,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20200717]
[cannot apply to linus/master v5.8-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note
== Series Details ==
Series: drm/i915/gem: Remove disordered per-file request list for throttling
(rev2)
URL : https://patchwork.freedesktop.org/series/79600/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8760_full -> Patchwork_18204_full
On Fri, Jul 17, 2020 at 01:53:18AM +, Patchwork wrote:
> == Series Details ==
>
> Series: Remaining RKL patches (rev7)
> URL : https://patchwork.freedesktop.org/series/77971/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8758_full -> Patchwork_18197_full
>
I915_GEM_THROTTLE dates back to the time before contexts where there was
just a single engine, and therefore a single timeline and request list
globally. That request list was in execution/retirement order, and so
walking it to find a particular aged request made sense and could be
split per file.
I915_GEM_THROTTLE dates back to the time before contexts where there was
just a single engine, and therefore a single timeline and request list
globally. That request list was in execution/retirement order, and so
walking it to find a particular aged request made sense and could be
split per file.
== Series Details ==
Series: drm/i915: Finish (de)gamma readout
URL : https://patchwork.freedesktop.org/series/79614/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8761 -> Patchwork_18207
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/kmb: Add support for KeemBay Display
URL : https://patchwork.freedesktop.org/series/79615/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
09ff5d4b7f4c drm/kmb: Add support for KeemBay Display
-:48: WARNING:FILE_PATH_CHANGES: added, moved or
== Series Details ==
Series: drm/i915: Finish (de)gamma readout
URL : https://patchwork.freedesktop.org/series/79614/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8761_full -> Patchwork_18207_full
Summary
---
On Wed, Jul 01, 2020 at 03:25:05AM -0700, Anusha Srivatsa wrote:
> The latest firmware contains fix for PSR2 power saving.
>
> Cc: Matt Roper
> Signed-off-by: Anusha Srivatsa
Has a pull request for the firmware itself already been sent?
Matt
> ---
> drivers/gpu/drm/i915/display/intel_csr.c
From: Ville Syrjälä
Just like ivb+, ilk/snb can select whether the hw lut acts as
gamma or degamma. Make the readout cognizant of that fact.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
From: Ville Syrjälä
Extract a few helpers to check whether the hw degamma or
gamma LUT is enabled.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 27 --
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git
From: Ville Syrjälä
Some gen2/gen3 parts have a 10bit gamma mode, on some pipes.
Expose it.
The format is different to the later i965+ style in that we
store a 10bit value and a 6 bit floating point slope for each
entry. Ie. the hardware extrapolates the intermediate steps
from the current LUT
From: Ville Syrjälä
Every platform now implemnts .read_luts(). Make it not optional.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
From: Ville Syrjälä
Add new .gamma_equal() and .degamma_equal() vfuncs to be used
by the state checker to verify the gamma/degamma LUTs. We need
somewhat custom behaviour for some platforms due to sometimes
swapping the roles of the gamma and degamma LUTs (due to
RGB limited color range or YCbCr
== Series Details ==
Series: drm/kmb: Add support for KeemBay Display
URL : https://patchwork.freedesktop.org/series/79615/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8761 -> Patchwork_18208
Summary
---
== Series Details ==
Series: drm/kmb: Add support for KeemBay Display
URL : https://patchwork.freedesktop.org/series/79615/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8761_full -> Patchwork_18208_full
Summary
---
From: Piotr Maciejewski
OA reports can be triggered into the OA buffer by writing into the
OAREPORTTRIG registers. Whitelist the registers to allow user to trigger
reports.
v2:
- Move related change to this patch (Lionel)
- Bump up perf revision (Lionel)
Signed-off-by: Piotr Maciejewski
From: Piotr Maciejewski
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach
From: Ville Syrjälä
Move the MST master transcoder dump next to the other transcoder
bits.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
From: Ville Syrjälä
Previously intel_dump_pipe_config() used to dump the full crtc state
whether or not the crtc was logically enabled or not. As that meant
occasionally dumping confusing stale garbage I changed it to
check whether the crtc is logically enabled or not. However I did
not realize
== Series Details ==
Series: drm/i915: Finish (de)gamma readout
URL : https://patchwork.freedesktop.org/series/79614/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Allow privileged user to map the OA buffer (rev2)
URL : https://patchwork.freedesktop.org/series/79460/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
24740597e5f9 drm/i915/perf: Ensure observation logic is not clock gated
216ee54f6578
== Series Details ==
Series: Allow privileged user to map the OA buffer (rev2)
URL : https://patchwork.freedesktop.org/series/79460/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Allow privileged user to map the OA buffer (rev2)
URL : https://patchwork.freedesktop.org/series/79460/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8761 -> Patchwork_18209
Summary
---
From: Ville Syrjälä
Read out the degamma LUT on glk+. No state cheker as of yet since
it requires dealing with he glk csc vs. degamma mess.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 44 ++
1 file changed, 44 insertions(+)
diff --git
From: Ville Syrjälä
CGM_PIPE_GAMMA_RED_MASK & co. are misplaced. Move then below the
relevant register. And while at it add the degamma counterparts.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
From: Ville Syrjälä
The gamma readout stuff was left half finished. No degamma
readout, and no readout whatsoever on ivb/bdw/skl/bxt.
Let's finish it. A bit more involved/ugly than I'd prefer
but there are certainly some complications with the way
some of the hw works.
There are a few
From: Ville Syrjälä
glk_read_lut_10() works just find for all bdw+ platforms, so
rename it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
From: Ville Syrjälä
Make ilk_load_luts() ready for a degamma lut. Currently we never
have one, but soon we may get one from readout, and I think we
may want to change the state computation such that we may end up
with one even when userspace has simply supplied a gamma lut.
At least the code
From: Ville Syrjälä
Since CHV has the dedicate CGM degamma unit readout is trivial.
Just do it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 36 ++
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
1 - 100 of 118 matches
Mail list logo
