On Sun, Jun 07, 2020 at 08:18:29PM +0200, Hans de Goede wrote:
> 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 b
On Sun, Jun 07, 2020 at 08:18:28PM +0200, Hans de Goede wrote:
> 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 clo
== Series Details ==
Series: series starting with [01/28] drm/i915: Adjust the sentinel assert to
match implementation
URL : https://patchwork.freedesktop.org/series/78103/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8597_full -> Patchwork_17902_full
===
== Series Details ==
Series: series starting with [1/3] drm/dp_mst: Fix the DDC I2C device
unregistration of an MST port
URL : https://patchwork.freedesktop.org/series/78100/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8597_full -> Patchwork_17901_full
=
On Mon, Jun 08, 2020 at 01:11:44AM +0300, Souza, Jose wrote:
> On Fri, 2020-06-05 at 12:48 +0300, Imre Deak wrote:
> > Currently MST on a port can get enabled/disabled from the hotplug work
> > and get disabled from the short pulse work in a racy way. Fix this by
> > relying on the MST state checki
== Series Details ==
Series: series starting with [01/28] drm/i915: Adjust the sentinel assert to
match implementation
URL : https://patchwork.freedesktop.org/series/78103/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8597 -> Patchwork_17902
=
== Series Details ==
Series: series starting with [01/28] drm/i915: Adjust the sentinel assert to
match implementation
URL : https://patchwork.freedesktop.org/series/78103/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won'
== Series Details ==
Series: series starting with [01/28] drm/i915: Adjust the sentinel assert to
match implementation
URL : https://patchwork.freedesktop.org/series/78103/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f23f25433228 drm/i915: Adjust the sentinel assert to match
Treat the dependency between bonded requests as weak and leave the
remainder of the pair on the GPU if one hangs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i
Pull the repeated check for the last active request being completed to a
single spot, when deciding whether or not execlist preemption is
required.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --gi
For a modeset/pageflip, there is a very precise deadline by which the
frame must be completed in order to hit the vblank and be shown. While
we don't pass along that exact information, we can at least inform the
scheduler that this request-chain needs to be completed asap.
Signed-off-by: Chris Wil
Rather than going back and forth between the rb_node entry and the
virtual_engine type, store the ve local and reuse it. As the
container_of conversion from rb_node to virtual_engine requires a
variable offset, performing that conversion just once shaves off a bit
of code.
v2: Keep a single virtua
The first "scheduler" was a topographical sorting of requests into
priority order. The execution order was deterministic, the earliest
submitted, highest priority request would be executed first. Priority
inherited ensured that inversions were kept at bay, and allowed us to
dynamically boost priori
Since we are not using any internal priority levels, and in the next few
patches will introduce a new index for which the optimisation is not so
lear cut, discard the small table within the priolist.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +-
drivers/g
Having recognised that we do not change the sibling until we schedule
out, we can then defer the decision to resubmit the virtual engine from
the unwind of the active queue to scheduling out of the virtual context.
By keeping the unwind order intact on the local engine, we can preserve
data depend
Lift the list iteration defines for traversing the signaler/waiter lists
into i915_scheduler.h for reuse.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 10 --
drivers/gpu/drm/i915/i915_scheduler_types.h | 10 ++
2 files changed, 10 insertions(+), 1
Asynchronous waits and signaling form a traditional semaphore with all
the usual ordering problems with taking multiple locks. If we want to
add more than one wait on a shared resource by the GPU, we must ensure
that all the associated timelines are advanced atomically, ergo we must
lock all the ti
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real f
With the removal of the internal wait-priority boosting, we can also
remove the selftest to ensure that those waits were being suppressed
from causing preemptions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 178 -
1 file changed, 178 deletion
Once a virtual engine has been bound to a sibling, it will remain bound
until we finally schedule out the last active request. We can not rebind
the context to a new sibling while it is inflight as the context save
will conflict, hence we wait. As we cannot then use any other sibliing
while the con
Currently, we construct and teardown the i915_dependency chains using a
global spinlock. As the lists are entirely local, it should be possible
to use an double-lock with an explicit nesting [signaler -> waiter,
always] and so avoid the costly convenience of a global spinlock.
Signed-off-by: Chris
---
drivers/gpu/drm/i915/i915_scheduler.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 320d3720ba34..4c189b81cc62 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/
If the real target for a proxy fence is known at the time we are
attaching our awaits, use the real target in preference to hooking up to
the proxy. If use the real target instead, we can optimize the awaits,
e.g. if it along the same engine, we can order the submission and avoid
the wait-for-compl
As we know when we expect the heartbeat to be checked for completion,
pass this information along as its deadline. We still do not complain if
the deadline is missed, at least until we have tried a few times, but it
will allow for quicker hang detection on systems where deadlines are
adhered to.
S
Over the next couple of patches, we will want to lock all the modified
vma for relocation processing under a single ww_mutex. We neither want
to have to include the vma that are skipped (due to no modifications
required) nor do we want those to be marked as written too. So separate
out the reloc va
== Series Details ==
Series: series starting with [1/3] drm/dp_mst: Fix the DDC I2C device
unregistration of an MST port
URL : https://patchwork.freedesktop.org/series/78100/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8597 -> Patchwork_17901
===
We have a test case to exercise resetting an engine while the other
engines are busy, all the TEST_SELF adds on top is that the target
engine also has background activity. In this case it is useful to first
test resetting the engine while there is background activity, as a
separate flag from exerci
Since we have reduced the relocations paths to just use the async GPU,
we can lift the request allocation to the start of the relocations.
Knowing that we use one request for all relocations will simplify
tracking the relocation fence.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_ge
If we get interrupted in the middle of chaining up the relocation
entries, we will fail to submit the relocation batch. However, we will
report having already completed some of the relocations, and so the
reloc.presumed_offset will no longer match the batch contents, causing
confusion and invalid f
In anticipation of wanting to be able to call pi from underneath an
engine's active.lock, rework the priority inheritance to primarily work
along an engine's priority queue, delegating any other engine that the
chain may traverse to a worker. This reduces the global spinlock from
governing the enti
From: Tvrtko Ursulin
Sentinels are supposed to be last reqeusts in the elsp queue, not the
only one, so adjust the assert accordingly.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drive
Although we may chide userspace for reusing the same batches
concurrently from multiple threads, at the same time we must be very
careful to only execute the batch and its relocations as supplied by the
user. If we are not careful, we may allow another thread to rewrite the
current batch with its o
In some of our hangtests, we try to reset an active engine while it is
spinning inside the recursive spinner. However, we also try to flood the
engine with requests that preempt the hang, and so should disable the
preemption to be sure that we reset the right request.
Signed-off-by: Chris Wilson
One more list iterator variant, for when we want to unwind from inside
one list iterator with the intention of restarting from the current
entry as the new head of the list.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_utils.h | 6 ++
1 file changed,
Looking to the future, we want to set the scheduling attributes
explicitly and so replace the generic engine->schedule() with the more
direct i915_request_set_priority()
What it loses in removing the 'schedule' name from the function, it
gains in having an explicit entry point with a stated goal.
Reduce the smoke depth by trimming the number of contexts, repetitions
and wait times. This is in preparation for a less greedy scheduler that
tries to be fair across contexts, resulting in a great many more context
switches. A thousand context switches may be 50-100ms, causing us to
timeout as the
As we do not have any internal priority levels, the priority can be set
directed from the user values.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +--
.../i915/gem/selftests/i915_gem_object_blt.c | 4
On Fri, 2020-06-05 at 12:48 +0300, Imre Deak wrote:
> Currently MST on a port can get enabled/disabled from the hotplug work
> and get disabled from the short pulse work in a racy way. Fix this by
> relying on the MST state checking in the hotplug work and just schedule
> a hotplug work from the sh
== Series Details ==
Series: series starting with [1/3] drm/dp_mst: Fix the DDC I2C device
unregistration of an MST port
URL : https://patchwork.freedesktop.org/series/78100/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
be4cb6213842 drm/dp_mst: Fix the DDC I2C device unregist
During the initial MST probing an MST port's I2C device will be
registered using the kdev of the DRM device as a parent. Later after MST
Connection Status Notifications this I2C device will be re-registered
with the kdev of the port's connector. This will also move
inconsistently the I2C device's s
Atm, a pending delayed destroy work during module removal will be
canceled, leaving behind MST ports, mstbs. Fix this by using a dedicated
workqueue which will be drained of requeued items as well when
destroying it.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 17 +++
The WARN below triggers during the removal of an MST port. The problem
is that the parent device's (the connector's kdev) sysfs directory is
removed recursively when the connector is unregistered (even though the
I2C device holds a reference on the parent device). To fix this set
first the Peer Dev
== Series Details ==
Series: pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic
PWM API
URL : https://patchwork.freedesktop.org/series/78089/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8596_full -> Patchwork_17900_full
==
On Sun, 2020-06-07 at 16:08 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/psr: Program default IO buffer Wake and Fast Wake (rev4)
> URL : https://patchwork.freedesktop.org/series/78019/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8596_full ->
== Series Details ==
Series: pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic
PWM API
URL : https://patchwork.freedesktop.org/series/78089/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8596 -> Patchwork_17900
== Series Details ==
Series: pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic
PWM API
URL : https://patchwork.freedesktop.org/series/78089/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e5cf553c0dcc ACPI / LPSS: Resume Cherry Trail PWM controller in no-ir
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 i
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Signed-off-by: Hans de Goede
---
drivers/pwm/pwm-crc.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 58c7e9ef7278.
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 m
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
---
drivers/pwm/pwm-crc.c | 107 +++---
1 file changed, 59 insertions(+), 48 deletions(-)
diff --git a/drivers/pwm/pwm-crc.c b/dri
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 fastse
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 clo
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 grea
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
backlight-ena
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()).
Signed-off-by: Hans de Goede
---
drivers/gp
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 f
On the LPSS PWM controller found on Bay Trail (BYT) and Cherry Trail (CHT)
platforms, the following sequence results in an output duty-cycle of 100%
independent of what the duty-cycle requested in the ctrl-reg is:
1. Clear ENABLE bit in ctrl register
2. Let the machine reach a S0i3 low power state
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 = PSA
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 cl
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 /* \_SB_.PCI
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 ove
Hi All,
Here is v2 dropping a debugging-patch which I accidentally kept for v1
and addressing a minor review remark from Andy for the 2nd patch.
This patch series converts the i915 driver's code for controlling the
panel's backlight with an external PWM controller to use the atomic PWM API.
Init
Hi All,
I forgot the [PATCH 0/16] part of the subject here and I accidentally
left a patch adding some debugging printk-s in the series. I will
send out a v2 addressing this.
Regards,
Hans
On 6/6/20 10:25 PM, Hans de Goede wrote:
Hi All,
This patch series converts the i915 driver's cpde for
Hi,
On 6/7/20 7:03 PM, Andy Shevchenko wrote:
On Sat, Jun 06, 2020 at 10:25:47PM +0200, Hans de Goede wrote:
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, Serializ
On Sun, 2020-06-07 at 17:36 +0300, Gwan-gyeong Mun wrote:
> The IO buffer Wake and Fast Wake bit size and value have been changed from
> Gen12+. It programs the default value of IO buffer Wake and Fast Wake on
> Gen12+. It adds definitions of IO buffer Wake and Fast Wake for pre Gen12
> and Gen12+.
On Sat, Jun 06, 2020 at 10:25:47PM +0200, Hans de Goede wrote:
> 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
> {
== Series Details ==
Series: drm/i915/psr: Program default IO buffer Wake and Fast Wake (rev4)
URL : https://patchwork.freedesktop.org/series/78019/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8596_full -> Patchwork_17899_full
== Series Details ==
Series: drm/i915/psr: Program default IO buffer Wake and Fast Wake (rev4)
URL : https://patchwork.freedesktop.org/series/78019/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8596 -> Patchwork_17899
Summ
== Series Details ==
Series: drm/i915/psr: Program default IO buffer Wake and Fast Wake (rev4)
URL : https://patchwork.freedesktop.org/series/78019/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c063779ca557 drm/i915/psr: Program default IO buffer Wake and Fast Wake
-:90: WARNI
== Series Details ==
Series: drm/i915/psr: Program default IO buffer Wake and Fast Wake (rev3)
URL : https://patchwork.freedesktop.org/series/78019/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8596 -> Patchwork_17898
Summ
The IO buffer Wake and Fast Wake bit size and value have been changed from
Gen12+. It programs the default value of IO buffer Wake and Fast Wake on
Gen12+. It adds definitions of IO buffer Wake and Fast Wake for pre Gen12
and Gen12+. And it aligns PSR2 definition macros.
v2: Fix macro definitions.
== Series Details ==
Series: drm/i915/psr: Program default IO buffer Wake and Fast Wake (rev3)
URL : https://patchwork.freedesktop.org/series/78019/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ffef3ca6c982 drm/i915/psr: Program default IO buffer Wake and Fast Wake
-:89: CHECK
The IO buffer Wake and Fast Wake bit size and value have been changed from
Gen12+. It programs the default value of IO buffer Wake and Fast Wake on
Gen12+. It adds definitions of IO buffer Wake and Fast Wake for pre Gen12
and Gen12+. And it aligns PSR2 definition macros.
v2: Fix macro definitions.
73 matches
Mail list logo
