== 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
---
== 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 : warning
== Summary ==
$ dim checkpatch origin/drm-tip
24740597e5f9 drm/i915/perf: Ensure observation logic is not clock gated
216ee54f6578
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 registers when the report was triggered. Whitelist OA buffer
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
This cover letter is included to trigger "Test-with" an IGT patch.
Tests - https://patchwork.freedesktop.org/patch/377905/?series=79617=1
Signed-off-by: Umesh Nerlige Ramappa
Test-with: 20200717235842.68574-1-umesh.nerlige.rama...@intel.com
Piotr Maciejewski (4):
drm/i915/perf: Ensure
From: Piotr Maciejewski
A clock gating switch can control if the performance monitoring and
observation logic is enaled or not. Ensure that we enable the clocks.
v2: Separate code from other patches (Lionel)
Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL")
Signed-off-by: Piotr
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
== 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
---
== 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
---
== 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 : 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 : success
== Summary ==
CI Bug Log - changes from CI_DRM_8761 -> Patchwork_18207
Summary
---
**SUCCESS**
== 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.
This is a new DRM driver for Intel's KeemBay SOC.
The SoC couples an ARM Cortex A53 CPU with an Intel
Movidius VPU.
This driver is tested with the KMB EVM board which is the refernce baord
for Keem Bay SOC. The SOC's display pipeline is as follows
+--++-+
From: Ville Syrjälä
Since bdw_read_lut_10() uses the auto-increment mode we must
have an equal number of entries in the software LUT and the
hardware LUT. WARN if that is not the case.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 7 +--
1 file changed, 5
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
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
From: Ville Syrjälä
We now have all the code necessary for gamma/degamma readout on
ivb/hsw. Plug it all in.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 32 ++
1 file changed, 32 insertions(+)
diff --git
From: Ville Syrjälä
Read out both gamma and degamma when usng the split gamma mode
on bdw+. We can't use the auto increment mode to iterate the
LUTs since we want to read out less entries than what we stuff
into the software LUT.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Move chv_cgm_gamma_pack() next to the other CGM gamma functions.
Right now it's stuck in the middle of the CGM degamma functions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 14 +++---
1 file changed, 7 insertions(+), 7
From: Ville Syrjälä
Since gamma_mode can have more than two values on ilk+
let's use switch statemnts when interpreting them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 93 --
1 file changed, 70 insertions(+), 23 deletions(-)
diff --git
From: Ville Syrjälä
Just for some extra consistency let's reset the glk degamma LUT
index back to 0 after we're dong trawling the LUT.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
Dump the sizes of the software LUTs in the state dump. Makes
it a bit easier to see which is is present without having to
decode it from the gamma_mode and other bits of state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 ++
1 file
From: Ville Syrjälä
Read out the gamme/degamma LUT on bdw+. Not entirely complete
as we need a bit more special sauce to handle the split gamma
mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 27 ++
1 file changed, 27 insertions(+)
diff
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ä
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ä
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
Quoting Jisheng Zhang (2020-07-17 07:11:38)
> 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.
But it is required for Valleyview/Cherryview and we want to
== Series Details ==
Series: drm/i915: Don't force IOSF_MBI
URL : https://patchwork.freedesktop.org/series/79607/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8760_full -> Patchwork_18206_full
Summary
---
== Series Details ==
Series: drm/i915/gem: Remove disordered per-file request list for throttling
(rev4)
URL : https://patchwork.freedesktop.org/series/79600/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8760_full -> Patchwork_18205_full
On Fri, Jul 17, 2020 at 08:37:23PM +0300, Imre Deak wrote:
> On Fri, Jul 17, 2020 at 07:10:39PM +0300, Ville Syrjälä wrote:
> > 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
== Series Details ==
Series: drm/i915: Don't force IOSF_MBI
URL : https://patchwork.freedesktop.org/series/79607/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8760 -> Patchwork_18206
Summary
---
**SUCCESS**
No
On Fri, Jul 17, 2020 at 07:10:39PM +0300, Ville Syrjälä wrote:
> 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
== 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
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
== 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
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.
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
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.
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
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
>
== 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
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/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 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
== 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
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
== 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/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/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
---
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
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
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
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
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
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
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
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
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
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
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
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
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
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 /*
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 =
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
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
---
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().
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
== 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
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
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
== 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.
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
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
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
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:
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 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
== 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
== 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
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
> >
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
== 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
== 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: 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
1 - 100 of 118 matches
Mail list logo
