On 6/9/2020 8:17 AM, Chris Wilson wrote:
In commit 5ba32c7be81e ("drm/i915/execlists: Always force a context
reload when rewinding RING_TAIL"), we placed the check for rewinding a
context on actually submitting the next request in that context. This
was so that we only had to check once, and
== Series Details ==
Series: drm/i915/icl: Disable DIP on MST ports with the transcoder clock still
on
URL : https://patchwork.freedesktop.org/series/78172/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8604_full -> Patchwork_17917_full
On Jun 8, 2020, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2020-06-08 18:46:53)
>> Alexandre Oliva has recently removed these files from Linux Libre
>> with concerns that the sources weren't available.
>>
>> The sources are available on IGT repository, and only open source
>> tools are used
== Series Details ==
Series: drm/i915/icl: Disable DIP on MST ports with the transcoder clock still
on
URL : https://patchwork.freedesktop.org/series/78172/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8604 -> Patchwork_17917
According to BSpec the Data Island Packet should be disabled after
disabling the transcoder, but before the transcoder clock select is set
to none. On an ICL RVP, daisy-chained MST config not following this
leads to a hang with the following MCE when disabling the output:
[ 870.948739] mce:
== Series Details ==
Series: drm/i915: Fix the i915_dsc_fec_support debugfs file for DP MST
connectors (rev3)
URL : https://patchwork.freedesktop.org/series/78128/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8604_full -> Patchwork_17916_full
On Mon, Jun 08, 2020 at 12:25:20AM +0300, Imre Deak wrote:
> 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
== Series Details ==
Series: drm/i915: Fix the i915_dsc_fec_support debugfs file for DP MST
connectors (rev3)
URL : https://patchwork.freedesktop.org/series/78128/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8604 -> Patchwork_17916
On Tue, Jun 09, 2020 at 11:56:56AM -0700, Manasi Navare wrote:
> On Tue, Jun 09, 2020 at 09:08:52PM +0300, Imre Deak wrote:
> > On Tue, Jun 09, 2020 at 08:59:23PM +0300, Ville Syrjälä wrote:
> > > On Tue, Jun 09, 2020 at 08:40:35PM +0300, Imre Deak wrote:
> > > > On Tue, Jun 09, 2020 at 06:05:25PM
On Tue, Jun 09, 2020 at 09:41:40PM +0300, Imre Deak wrote:
> DSC is not supported on DP MST streams so just don't add this entry for
> MST connectors.
>
> This also fixes an OOPS, caused by the encoder->digport cast, which is
> not valid for MST encoders.
>
> v2:
> - Check encoder, which is
On Tue, Jun 09, 2020 at 09:08:52PM +0300, Imre Deak wrote:
> On Tue, Jun 09, 2020 at 08:59:23PM +0300, Ville Syrjälä wrote:
> > On Tue, Jun 09, 2020 at 08:40:35PM +0300, Imre Deak wrote:
> > > On Tue, Jun 09, 2020 at 06:05:25PM +0300, Ville Syrjälä wrote:
> > > > On Mon, Jun 08, 2020 at 09:10:23PM
DSC is not supported on DP MST streams so just don't add this entry for
MST connectors.
This also fixes an OOPS, caused by the encoder->digport cast, which is
not valid for MST encoders.
v2:
- Check encoder, which is unset for an MST connector, before it gets
enabled.
v3:
- Just don't add this
== Series Details ==
Series: drm/i915/gt: Incrementally check for rewinding (rev2)
URL : https://patchwork.freedesktop.org/series/78163/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8603_full -> Patchwork_17915_full
On Tue, Jun 09, 2020 at 08:59:23PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 09, 2020 at 08:40:35PM +0300, Imre Deak wrote:
> > On Tue, Jun 09, 2020 at 06:05:25PM +0300, Ville Syrjälä wrote:
> > > On Mon, Jun 08, 2020 at 09:10:23PM +0300, Imre Deak wrote:
> > > > DSC is not supported on DP MST
On Tue, Jun 09, 2020 at 11:58:18AM -0400, Lyude Paul wrote:
> Hi! Awesome patch series!
>
> Reviewed-by: Lyude Paul
Thanks.
> Also re merging via drm-intel-next-queued - I think that should be fine, fwiw
> merging via drm-misc-next might be another option (I've definitely done this
> in
> the
On Tue, Jun 09, 2020 at 08:40:35PM +0300, Imre Deak wrote:
> On Tue, Jun 09, 2020 at 06:05:25PM +0300, Ville Syrjälä wrote:
> > On Mon, Jun 08, 2020 at 09:10:23PM +0300, Imre Deak wrote:
> > > DSC is not supported on DP MST streams so just return -EINVAL when
> > > reading/writing the
On Tue, Jun 09, 2020 at 06:05:25PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 08, 2020 at 09:10:23PM +0300, Imre Deak wrote:
> > DSC is not supported on DP MST streams so just return -EINVAL when
> > reading/writing the i915_dsc_fec_support debugfs file for such
> > connectors.
> >
> > This also
On 6/8/20 5:15 PM, Christian König wrote:
When the current entry is rejected as candidate for the search
it does not mean that we can abort the subtree search.
It is perfectly possible that only the alignment, but not the
size is the reason for the rejection.
I know why I did that, I was
== Series Details ==
Series: drm/i915/gt: Incrementally check for rewinding (rev2)
URL : https://patchwork.freedesktop.org/series/78163/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8603 -> Patchwork_17915
Summary
---
Hi! Awesome patch series!
Reviewed-by: Lyude Paul
Also re merging via drm-intel-next-queued - I think that should be fine, fwiw
merging via drm-misc-next might be another option (I've definitely done this in
the past for series that touched MST and drivers, but I don't have a hard
preference
== Series Details ==
Series: drm/i915/gt: Incrementally check for rewinding (rev2)
URL : https://patchwork.freedesktop.org/series/78163/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
729184acbb94 drm/i915/gt: Incrementally check for rewinding
-:165: WARNING:FILE_PATH_CHANGES:
In commit 5ba32c7be81e ("drm/i915/execlists: Always force a context
reload when rewinding RING_TAIL"), we placed the check for rewinding a
context on actually submitting the next request in that context. This
was so that we only had to check once, and could do so with precision
avoiding as many
On Fri, Jun 05, 2020 at 07:57:37PM -0700, Matt Roper wrote:
> From: Aditya Swarup
>
> RKL doesn't have DSI outputs, so we shouldn't try to read out the DSI
> transcoder registers.
>
> v2(MattR):
> - Just set the 'extra panel mask' to edp | dsi0 | dsi1 and then mask
>against the platform's
Quoting Chris Wilson (2020-06-09 13:28:56)
> In commit 5ba32c7be81e ("drm/i915/execlists: Always force a context
> reload when rewinding RING_TAIL"), we placed the check for rewinding a
> context on actually submitting the next request in that context. This
> was so that we only had to check once,
On Fri, Jun 05, 2020 at 07:57:36PM -0700, Matt Roper wrote:
> HPD pin handling for RKL+TGP is a special case; we effectively select
> the HPD pin based on the DDI (A,B,D,E) rather than the PHY (A,B,C,D).
> This differs from the regular behavior of RKL+CMP (and also TGL+TGP).
>
> v2:
> - Rather
On Fri, Jun 05, 2020 at 07:57:34PM -0700, Matt Roper wrote:
> Rocket Lake uses the same 'abox0' mechanism to handle pixel data
> transfers from memory that gen11 platforms used, rather than the
> abox1/abox2 interfaces used by TGL/DG1. For the most part this is a
> hardware implementation detail
On Mon, Jun 08, 2020 at 09:10:23PM +0300, Imre Deak wrote:
> DSC is not supported on DP MST streams so just return -EINVAL when
> reading/writing the i915_dsc_fec_support debugfs file for such
> connectors.
>
> This also fixes an OOPS, caused by the encoder->digport cast, which is
> not valid for
== Series Details ==
Series: drm/i915/gt: Incrementally check for rewinding
URL : https://patchwork.freedesktop.org/series/78163/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8602_full -> Patchwork_17914_full
Summary
On Tue, Jun 09, 2020 at 03:44:18PM +0200, Hans de Goede wrote:
> On 6/9/20 1:32 PM, Andy Shevchenko wrote:
> > On Sun, Jun 07, 2020 at 08:18:35PM +0200, Hans de Goede wrote:
...
> > And again... :-(
>
> Well yes I cannot help it that the original code, as submitted by Intel,
> was of very
Hi,
On 6/9/20 1:29 PM, Andy Shevchenko wrote:
On Sun, Jun 07, 2020 at 08:18:31PM +0200, Hans de Goede wrote:
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
Hi,
On 6/9/20 1:32 PM, Andy Shevchenko wrote:
On Sun, Jun 07, 2020 at 08:18:35PM +0200, Hans de Goede wrote:
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
...
-static int crc_pwm_calc_clk_div(int period_ns)
+static int
== Series Details ==
Series: drm/i915/gt: Incrementally check for rewinding
URL : https://patchwork.freedesktop.org/series/78163/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8602 -> Patchwork_17914
Summary
---
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
on.
Thanks, Daniel
On Tue, Jun 9, 2020 at 2:08 PM Eugeniy Paltsev
wrote:
== Series Details ==
Series: drm/i915/gt: Incrementally check for rewinding
URL : https://patchwork.freedesktop.org/series/78163/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e9fc78f4bfec drm/i915/gt: Incrementally check for rewinding
-:165: WARNING:FILE_PATH_CHANGES: added,
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of
In commit 5ba32c7be81e ("drm/i915/execlists: Always force a context
reload when rewinding RING_TAIL"), we placed the check for rewinding a
context on actually submitting the next request in that context. This
was so that we only had to check once, and could do so with precision
avoiding as many
Hi Dave, Lyude,
are you ok to merge this patchset via the drm-intel-next-queued tree?
--Imre
On Thu, Jun 04, 2020 at 09:45:00PM +0300, Imre Deak wrote:
> Some TypeC -> native DP adapters, at least the Club 3D CAC-1557 adapter,
> incorrectly filter out HPD short pulses with a duration less than
Hi Daniel,
I've got pretty strange results so I need some time to investigate it and
probably retest.
I'll send you update in a few days.
---
Eugeniy Paltsev
From: Daniel Vetter
Sent: Friday, June 5, 2020 22:55
To: Eugeniy Paltsev
Cc: Intel Graphics
On 09/06/2020 11:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-06-09 11:39:11)
On 09/06/2020 11:29, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-06-09 07:59:27)
666
On 08/06/2020 10:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-06-08 08:44:01)
On 07/06/2020 23:20,
On Sun, Jun 07, 2020 at 08:18:35PM +0200, Hans de Goede wrote:
> Replace the enable, disable and config pwm_ops with an apply op,
> to support the new atomic PWM API.
...
> -static int crc_pwm_calc_clk_div(int period_ns)
> +static int crc_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
On Sun, Jun 07, 2020 at 08:18:36PM +0200, Hans de Goede wrote:
> Implement the pwm_ops.get_state() method to complete the support for the
> new atomic PWM API.
This one is good.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Hans de Goede
> ---
> drivers/pwm/pwm-crc.c | 29
On Sun, Jun 07, 2020 at 08:18:34PM +0200, Hans de Goede wrote:
> 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
On Sun, Jun 07, 2020 at 08:18:31PM +0200, Hans de Goede wrote:
> 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
Quoting Tvrtko Ursulin (2020-06-09 08:47:00)
>
> On 07/06/2020 23:20, Chris Wilson wrote:
> > 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
Quoting Tvrtko Ursulin (2020-06-09 11:39:11)
>
> On 09/06/2020 11:29, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-06-09 07:59:27)
> >> 666
> >> On 08/06/2020 10:33, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2020-06-08 08:44:01)
>
> On 07/06/2020 23:20, Chris Wilson
On 09/06/2020 11:29, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-06-09 07:59:27)
666
On 08/06/2020 10:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-06-08 08:44:01)
On 07/06/2020 23:20, Chris Wilson wrote:
From: Tvrtko Ursulin
Sentinels are supposed to be last reqeusts in the
Quoting Tvrtko Ursulin (2020-06-09 07:59:27)
> 666
> On 08/06/2020 10:33, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-06-08 08:44:01)
> >>
> >> On 07/06/2020 23:20, Chris Wilson wrote:
> >>> From: Tvrtko Ursulin
> >>>
> >>> Sentinels are supposed to be last reqeusts in the elsp queue,
On 07/06/2020 23:20, Chris Wilson wrote:
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
666
On 08/06/2020 10:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-06-08 08:44:01)
On 07/06/2020 23:20, Chris Wilson wrote:
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
49 matches
Mail list logo
