== Series Details ==
Series: snd/hda: Balance hda->need_i915_power across runtime_suspend (rev2)
URL : https://patchwork.freedesktop.org/series/59253/
State : failure
== Summary ==
Applying: snd/hda: Balance hda->need_i915_power across runtime_suspend
error: sha1 information is lacking or
On Wed, 10 Apr 2019 00:53:31 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-04-09 22:35:28)
> > On Tue, 09 Apr 2019 23:27:41 +0200,
> > Chris Wilson wrote:
> > >
> > > In runtime_resume, we release the local display_power wakeref if we can
> > > rely on i915 providing a wakeref along
== Series Details ==
Series: drm/i915: Bump ready tasks ahead of busywaits (rev2)
URL : https://patchwork.freedesktop.org/series/59232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5897_full -> Patchwork_12740_full
== Series Details ==
Series: drm/i915: Fix SDVO HDMI audio
URL : https://patchwork.freedesktop.org/series/59233/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5897_full -> Patchwork_12739_full
Summary
---
On Mon, 8 Apr 2019 12:11:15 +0300
Ville Syrjälä wrote:
Hi,
> On Fri, Apr 05, 2019 at 04:33:30PM -0700, Vivek Kasireddy wrote:
> > On Fri, 5 Apr 2019 21:39:11 +0300
> > Ville Syrjälä wrote:
> > Hi Ville,
> >
> > > On Fri, Apr 05, 2019 at 09:33:56PM +0300, Ville Syrjälä wrote:
> > > > On
On Fri, 5 Apr 2019 17:46:38 -0700
Lucas De Marchi wrote:
Hi,
> On Fri, Apr 05, 2019 at 10:59:53AM -0700, Vivek Kasireddy wrote:
> >This patch adds support for DPLL4 on EHL that include the
> >following restrictions:
> >
> >- DPLL4 cannot be used with DDIA (combo port A internal eDP usage).
> >
On 4/9/19 3:11 PM, Chris Wilson wrote:
> Quoting Fernando Pacheco (2019-04-09 22:31:01)
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index bf3d12f94365..160959785589 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++
Quoting Fernando Pacheco (2019-04-09 23:53:08)
>
> On 4/9/19 2:53 PM, Chris Wilson wrote:
> > Quoting Fernando Pacheco (2019-04-09 22:31:01)
> >> +int intel_uc_fw_ggtt_pin(struct intel_uc_fw *uc_fw,
> >> +struct i915_ggtt *ggtt, u64 start)
> >> +{
> >> + struct
== Series Details ==
Series: Perma-pin uC firmware and re-enable global reset
URL : https://patchwork.freedesktop.org/series/59255/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12747
Summary
---
On 4/9/19 2:53 PM, Chris Wilson wrote:
> Quoting Fernando Pacheco (2019-04-09 22:31:01)
>> Currently we pin the GuC or HuC firmware image just
>> before uploading. Perma-pin during uC initialization
>> instead and use the range reserved at the top of the
>> address space.
>>
>> Moving the
Quoting Takashi Iwai (2019-04-09 22:35:28)
> On Tue, 09 Apr 2019 23:27:41 +0200,
> Chris Wilson wrote:
> >
> > In runtime_resume, we release the local display_power wakeref if we can
> > rely on i915 providing a wakeref along the component. On suspend
> > therefore, we should only release the
On 4/9/19 2:41 PM, Chris Wilson wrote:
> Quoting Fernando Pacheco (2019-04-09 22:31:00)
>> GuC and HuC depend on struct_mutex for device
>> reinitialization. Moving away from this dependency
>> requires perma-pinning the firmware images in GGTT.
>> The upper portion of the GuC address space has
== Series Details ==
Series: Perma-pin uC firmware and re-enable global reset
URL : https://patchwork.freedesktop.org/series/59255/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/uc: Rename uC firmware init function
Okay!
Commit:
== Series Details ==
Series: snd/hda: Balance hda->need_i915_power across runtime_suspend
URL : https://patchwork.freedesktop.org/series/59253/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12746
Summary
Quoting Fernando Pacheco (2019-04-09 22:31:01)
> diff --git a/drivers/gpu/drm/i915/intel_huc.c
> b/drivers/gpu/drm/i915/intel_huc.c
> index 94c04f16a2ad..89e0b942ae86 100644
> --- a/drivers/gpu/drm/i915/intel_huc.c
> +++ b/drivers/gpu/drm/i915/intel_huc.c
> @@ -40,6 +40,59 @@ int
On 4/9/19 2:31 PM, Fernando Pacheco wrote:
GuC and HuC depend on struct_mutex for device
reinitialization. Moving away from this dependency
requires perma-pinning the firmware images in GGTT.
The upper portion of the GuC address space has
a sizeable hole (several MB) that is inaccessible
by
Quoting Fernando Pacheco (2019-04-09 22:31:01)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index bf3d12f94365..160959785589 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4508,6 +4508,8 @@ void
Quoting Fernando Pacheco (2019-04-09 22:30:59)
> static inline
> -void intel_uc_fw_init(struct intel_uc_fw *uc_fw, enum intel_uc_fw_type type)
> +void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
> + enum intel_uc_fw_type type)
I followed right up until the point
Quoting Fernando Pacheco (2019-04-09 22:31:02)
> This reverts commit fe62365f9f80a1c1d438c54fba21f5108a182de8.
And don't forget the test code that skips guc.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Quoting Fernando Pacheco (2019-04-09 22:31:01)
> Currently we pin the GuC or HuC firmware image just
> before uploading. Perma-pin during uC initialization
> instead and use the range reserved at the top of the
> address space.
>
> Moving the firmware resulted in needing to:
> - restore the ggtt
Quoting Chris Wilson (2019-04-09 22:41:40)
> Quoting Fernando Pacheco (2019-04-09 22:31:00)
> > @@ -3370,7 +3388,8 @@ int i915_ggtt_probe_hw(struct drm_i915_private
> > *dev_priv)
> > * restriction!
> > */
> > if (USES_GUC(dev_priv)) {
> > - ggtt->vm.total
Quoting Fernando Pacheco (2019-04-09 22:31:00)
> GuC and HuC depend on struct_mutex for device
> reinitialization. Moving away from this dependency
> requires perma-pinning the firmware images in GGTT.
> The upper portion of the GuC address space has
> a sizeable hole (several MB) that is
On Tue, 09 Apr 2019 23:27:41 +0200,
Chris Wilson wrote:
>
> In runtime_resume, we release the local display_power wakeref if we can
> rely on i915 providing a wakeref along the component. On suspend
> therefore, we should only release the display_power if we kept it from
> runtime_resume.
Hrm,
This reverts commit fe62365f9f80a1c1d438c54fba21f5108a182de8.
Signed-off-by: Fernando Pacheco
---
drivers/gpu/drm/i915/i915_reset.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 68875ba43b8d..6f823d81c428
Currently we pin the GuC or HuC firmware image just
before uploading. Perma-pin during uC initialization
instead and use the range reserved at the top of the
address space.
Moving the firmware resulted in needing to:
- restore the ggtt mapping during the suspend/resume path.
- use an additional
The uC firmware init function is called during
GuC/HuC init early phases. Rename to include "_early"
and properly reflect which phase we are at.
Signed-off-by: Fernando Pacheco
---
drivers/gpu/drm/i915/intel_guc_fw.c | 2 +-
drivers/gpu/drm/i915/intel_huc_fw.c | 2 +-
GuC and HuC depend on struct_mutex for device
reinitialization. Moving away from this dependency
requires perma-pinning the firmware images in GGTT.
The upper portion of the GuC address space has
a sizeable hole (several MB) that is inaccessible
by GuC. Reserve this range within GGTT as it can
The intent is to move the GuC and HuC firmware images to the
top of the address space. This portion is inaccessible during
normal GuC operations and should be relatively safe to house
both firmware images. By making the move we can re-enable the
full gpu reset with GuC enabled.
Placing the
Quoting Ville Syrjala (2019-04-09 15:40:50)
> From: Ville Syrjälä
>
> The "audio enable" bit on the SDVO/HDMI control register is only meant
> for HDMI. Audio is never delivered over the SDVO bus. Rename the define
> to reflect this fact.
>
> Signed-off-by: Ville Syrjälä
Just going by that
In runtime_resume, we release the local display_power wakeref if we can
rely on i915 providing a wakeref along the component. On suspend
therefore, we should only release the display_power if we kept it from
runtime_resume.
Fixes: e454ff8e89b6 ("ALSA: hda/intel: Drop superfluous
Quoting Ville Syrjala (2019-04-09 15:40:48)
> From: Ville Syrjälä
>
> The AVI infoframe readout code currently issues a
> SDVO_CMD_GET_HBUF_TXRATE before SDVO_CMD_SET_HBUF_INDEX, which is
> not the correct order for these two operations. So far this wasn't
> a problem since we left the index
Quoting Ville Syrjälä (2019-04-09 20:59:43)
> On Tue, Apr 09, 2019 at 08:46:42PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjala (2019-04-09 15:40:51)
> > > From: Ville Syrjälä
> > >
> > > Before we go writing the infoframe let's make sure we have
> > > the space for it. Not that it really
On Tue, 2019-04-09 at 23:38 +0300, Ville Syrjälä wrote:
> On Tue, Apr 09, 2019 at 01:28:18PM -0700, Dhinakaran Pandiyan wrote:
> > On Tue, 2019-03-26 at 16:25 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > 6bpc is only legal for RGB and RAW pixel encodings. For the rest
> > >
Try papering over the icl memleak with a spot of buffer recycling.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ppgtt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/i915/gem_ppgtt.c b/tests/i915/gem_ppgtt.c
index ae9869c2c..4bff5cf98 100644
--- a/tests/i915/gem_ppgtt.c
+++
== Series Details ==
Series: drm/i915: Fix setting 10 bit color mode
URL : https://patchwork.freedesktop.org/series/59246/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12745
Summary
---
On Tue, Apr 09, 2019 at 01:28:18PM -0700, Dhinakaran Pandiyan wrote:
> On Tue, 2019-03-26 at 16:25 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > 6bpc is only legal for RGB and RAW pixel encodings. For the rest
> > the minimum is 8bpc. Set our lower limit accordingly.
>
> Patch
On Tue, Apr 09, 2019 at 08:44:26PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-04-09 15:40:54)
> > From: Ville Syrjälä
> >
> > It's much easier to figure out why the SDVO encoder refuses to cooperate
> > if we can see what status we got back.
> >
> > Signed-off-by: Ville Syrjälä
>
On Tue, 2019-03-26 at 16:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> 6bpc is only legal for RGB and RAW pixel encodings. For the rest
> the minimum is 8bpc. Set our lower limit accordingly.
Patch doesn't apply anymore, got a conflict in intel_drv.h.
> Signed-off-by: Ville
On Mon, Apr 08, 2019 at 05:37:29PM -0700, Paulo Zanoni wrote:
> Make them take the uncore argument from the caller instead of passing
> the implicit _priv->uncore directly. This will allow us to finally
> pass something that's not dev_priv->uncore in the future, and gets rid
> of the implicit
== Series Details ==
Series: drm/i915: Fix setting 10 bit color mode
URL : https://patchwork.freedesktop.org/series/59246/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d76f6b458d07 drm/i915: Fix setting 10 bit color mode
-:22: WARNING:BAD_SIGN_OFF: Non-standard signature:
On Tue, Apr 09, 2019 at 12:58:58PM -0700, Aditya Swarup wrote:
> Currently, we cannot set 10 bit color mode in
> intel_hdmi_compute_config() because desired_bpp is always set to 12
> which makes pipe_bpp = 36.(As most platforms support 12 bit color which
> always returns true for
Currently, we cannot set 10 bit color mode in
intel_hdmi_compute_config() because desired_bpp is always set to 12
which makes pipe_bpp = 36.(As most platforms support 12 bit color which
always returns true for hdmi_deep_color_possible() in the if block for
12 bit color)
pipe_bpp value is always
On Tue, Apr 09, 2019 at 08:46:42PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-04-09 15:40:51)
> > From: Ville Syrjälä
> >
> > Before we go writing the infoframe let's make sure we have
> > the space for it. Not that it really matters since the write
> > loop would just terminate
On Tue, Apr 09, 2019 at 05:40:49PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Our SDVO audio support is pretty bogus. We can't push audio over the
> SDVO bus, so trying to enable audio in the SDVO control register doesn't
> do anything. In fact it looks like the SDVO encoder will
Quoting Ville Syrjala (2019-04-09 15:40:51)
> From: Ville Syrjälä
>
> Before we go writing the infoframe let's make sure we have
> the space for it. Not that it really matters since the write
> loop would just terminate early in that case.
>
> Signed-off-by: Ville Syrjälä
> ---
>
Quoting Ville Syrjala (2019-04-09 15:40:54)
> From: Ville Syrjälä
>
> It's much easier to figure out why the SDVO encoder refuses to cooperate
> if we can see what status we got back.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_sdvo.c | 5 +++--
> 1 file changed, 3
On Tue, Apr 09, 2019 at 07:15:20PM +, Jim Zhang wrote:
> Ville:
>
> Yes, if this patch is needed by kernel 3.10.61, please get somebody to
> review it. What do I need do to speed up the review process?
> Please generate a patch against kernel 3.10.61 if possible.
3.10 is so ancient I
Quoting Ville Syrjala (2019-04-09 15:40:53)
> From: Ville Syrjälä
>
> Pass the length returned by hdmi_infoframe_pack_only() to
> intel_sdvo_write_infoframe() so that we don't end up writing
> stack garbage into the hbuf.
>
> Signed-off-by: Ville Syrjälä
Ok, write_infoframe 0 extends if len
Quoting Ville Syrjala (2019-04-09 15:40:52)
> From: Ville Syrjälä
>
> Pass the length returned by intel_sdvo_read_infoframe() to
> hdmi_infoframe_unpack() so that we don't try to unpack any
> leftover stack garbage.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
== Series Details ==
Series: drm/i915: Avoiding reclaim tainting from runtime-pm debug
URL : https://patchwork.freedesktop.org/series/59242/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12744
Summary
== Series Details ==
Series: drm/i915: Avoiding reclaim tainting from runtime-pm debug
URL : https://patchwork.freedesktop.org/series/59242/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8a7f63e2f75d drm/i915: Avoiding reclaim tainting from runtime-pm debug
-:15:
Hi Jani,
git blame says you are familiar with intel_primary_plane_create! Would
you have some time to review this patch?
Thanks!
--
Simon Ser
https://emersion.fr
> From: Ville Syrjälä
>
> This adds basic immutable support for the zpos property. The zpos increases
> from bottom to top:
== Series Details ==
Series: Add HDR Metadata Parsing and handling in DRM layer (rev8)
URL : https://patchwork.freedesktop.org/series/25091/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12743
Summary
On Tue, Apr 09, 2019 at 10:34:22AM -0700, Paulo Zanoni wrote:
> Em ter, 2019-04-09 às 00:44 +, Patchwork escreveu:
> > == Series Details ==
> >
> > Series: IRQ initialization debloat and conversion to uncore
> > URL : https://patchwork.freedesktop.org/series/59202/
> > State : warning
> >
On Mon, Apr 08, 2019 at 05:37:27PM -0700, Paulo Zanoni wrote:
> The whole point of having macros here is for the token pasting
> necessary to automatically have IMR, IIR and IER selected. We don't
> really need or want all the inlining that happens as a consequence.
> The good thing about the
== Series Details ==
Series: Add HDR Metadata Parsing and handling in DRM layer (rev8)
URL : https://patchwork.freedesktop.org/series/25091/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6f71d6db5493 drm: Add HDR source metadata property
-:67: CHECK:PARENTHESIS_ALIGNMENT:
== Series Details ==
Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling
sequence for gen11
URL : https://patchwork.freedesktop.org/series/59237/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12742
As intel_runtime_pm_get/_put may be called from any blockable context,
we need to avoid allowing reclaim from our mallocs, as we need to
avoid tainting any mutexes held by the callers (as they may themselves
not allow for allocations as they are taken in the shrinker).
<4> [435.339331] WARNING:
Em ter, 2019-04-09 às 00:44 +, Patchwork escreveu:
> == Series Details ==
>
> Series: IRQ initialization debloat and conversion to uncore
> URL : https://patchwork.freedesktop.org/series/59202/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
> 7f73d1fe31bb
== Series Details ==
Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling
sequence for gen11
URL : https://patchwork.freedesktop.org/series/59237/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
18e95bd1432c drm/i915: Use dedicated rc6 enabling sequence for
== Series Details ==
Series: drm/i915: Update HDMI max TMDS data rate definition for VBT (rev2)
URL : https://patchwork.freedesktop.org/series/59220/
State : failure
== Summary ==
Applying: drm/i915: Update HDMI max TMDS data rate definition for VBT
error: corrupt patch at line 13
error:
== Series Details ==
Series: drm/i915: Bump ready tasks ahead of busywaits (rev2)
URL : https://patchwork.freedesktop.org/series/59232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12740
Summary
---
Quoting Michal Wajdeczko (2019-04-09 17:57:58)
> On Tue, 09 Apr 2019 18:13:04 +0200, Mika Kuoppala
> wrote:
>
> [snip]
>
> > +
> > + /*
> > + * 2c: Program Coarse Power Gating Policies.
> > + *
> > + * Bspec's guidance is to use 25us (really 25 * 1280ns) here. What we
> > +
On Tue, 09 Apr 2019 18:13:04 +0200, Mika Kuoppala
wrote:
[snip]
+
+ /*
+* 2c: Program Coarse Power Gating Policies.
+*
+* Bspec's guidance is to use 25us (really 25 * 1280ns) here. What we
+* use instead is a more conservative estimate for the maximum
On Tue, 09 Apr 2019 18:13:05 +0200, Mika Kuoppala
wrote:
On gen11 the recommended rc6 threshold differs from previous
gens, apply it.
References: bspec#52070
Is this correct number? I found it at 33149
And note that we are using different tag:
Bspec: 33149
Signed-off-by: Mika Kuoppala
Quoting Mika Kuoppala (2019-04-09 17:13:07)
> Enable media sampler powergate as recommended.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5 +++--
> drivers/gpu/drm/i915/intel_pm.c | 4 +++-
> 2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git
Quoting Mika Kuoppala (2019-04-09 17:13:08)
> There is no video turbo mode for gen11, so don't set it.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_pm.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
Quoting Mika Kuoppala (2019-04-09 17:13:04)
> In order not to inflate gen9 rc6 enabling sequence with
> gen11 specifics, use a separate function for it.
And disable_rc6 remains as simple as before.
> Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
-Chris
Quoting Mika Kuoppala (2019-04-09 17:13:10)
> With gen11 the interrupt registers are shared between 2 engines,
> with Engine1 instance being upper word and Engine0 instance being
> lower. Annoyingly gen11 selected the pm interrupts to be in the
> Engine1 instance.
Sounds weird, but I can't fault
== Series Details ==
Series: drm/i915: Fix SDVO HDMI audio
URL : https://patchwork.freedesktop.org/series/59233/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12739
Summary
---
**SUCCESS**
No
Quoting Mika Kuoppala (2019-04-09 17:13:09)
> Unlike previous gens, we already hold the irq_lock on
> entering the rps handler so we can't use it as it is.
>
> Make a gen11 specific rps interrupt handler without
> locking.
>
> Signed-off-by: Mika Kuoppala
> ---
>
HDR metadata requires a infoframe to be set. Due to fastset,
full modeset is not performed hence adding it to update_pipe
to handle that.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c | 13 +
drivers/gpu/drm/i915/intel_hdmi.c | 7
BYT/CHT doesn't support DRM Infoframe. This caused
a WARN_ON due to a missing CASE while executing
intel_hdmi_infoframes_enabled function. This patch
fixes the same.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
This patch series enables HDR support in drm. It basically defines
HDR metadata structures, property to pass content (after blending)
metadata from user space compositors to driver.
Dynamic Range and Mastering infoframe creation and sending.
ToDo:
1. We need to get the color framework in place
This patch enables modeset whenever HDR metadata
needs to be updated to sink.
v2: Addressed Shashank's review comments.
v3: Added Shashank's RB.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_atomic.c | 14 +-
Attach HDR metadata property to connector object.
v2: Rebase
v3: Updated the property name as per updated name
while creating hdr metadata property
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
v3: No Change
v4: Addressed Shashank's review comments
v5: Addressed Shashank's comment and added his RB.
v6: Addressed Jonas Karlman
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.
From: Ville Syrjälä
This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.
v2: Addressed Shashank's review comment.
v3: Addressed Shashank's review comment.
v4: Added Shashank's RB.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank
This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.
It also implements get() and set() functions for HDR output
metadata property.The blob data is received from userspace and
saved in connector state, the same is
From: Ville Syrjälä
ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve and the upper half
of the signal values use a
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Rebase. Added infoframe
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Jonas
>Karlman
>Sent: Monday, April 8, 2019 3:51 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org
>Cc: seanp...@chromium.org;
Quoting Mika Kuoppala (2019-04-09 17:13:06)
> Use a recommended idle hysteresis for media and render powergates.
>
> References: bspec#52070
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
In order not to inflate gen9 rc6 enabling sequence with
gen11 specifics, use a separate function for it.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 72 +
1 file changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
There is no video turbo mode for gen11, so don't set it.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 47f98e064de5..d6abba5c0b32
Use a recommended idle hysteresis for media and render powergates.
References: bspec#52070
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
Unlike previous gens, we already hold the irq_lock on
entering the rps handler so we can't use it as it is.
Make a gen11 specific rps interrupt handler without
locking.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c | 18 +-
1 file changed, 17 insertions(+), 1
With gen11 the interrupt registers are shared between 2 engines,
with Engine1 instance being upper word and Engine0 instance being
lower. Annoyingly gen11 selected the pm interrupts to be in the
Engine1 instance.
Rectify the situation by shifting the access accordingly,
based on gen.
Bugzilla:
On gen11 the recommended rc6 threshold differs from previous
gens, apply it.
References: bspec#52070
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
Enable media sampler powergate as recommended.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 5 +++--
drivers/gpu/drm/i915/intel_pm.c | 4 +++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
On Tue, Apr 09, 2019 at 03:46:20PM +, Chiou, Cooper wrote:
> Hi Ville,
>
> The bits is 5-7 means it’s 001x for 2.97Gbps, and 010x for 1.65Gbps.
> So correct value should be 2 not 1 for HDMI_MAX_DATA_RATE_297.
No. The bitfield is defined as something:3.
> And HDMI_MAX_DATA_RATE_165
== Series Details ==
Series: drm/i915: adding state checker for gamma lut values (rev3)
URL : https://patchwork.freedesktop.org/series/58039/
State : failure
== Summary ==
Applying: drm/i915: Introduce vfunc intel_get_color_config to create hw lut
Using index info to reconstruct a base
== Series Details ==
Series: adding state checker for gamma lut values
URL : https://patchwork.freedesktop.org/series/59226/
State : failure
== Summary ==
Applying: drm/i915: Introduce vfunc intel_get_color_config to create hw lut
Using index info to reconstruct a base tree...
M
On 4/9/2019 8:29 AM, Anshuman Gupta wrote:
There were few system hung observed while running i915_pm_rpm igt test.
FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840
Root cause is believed to due to page fault in ACPI idle driver.
(FDO comment 18).
It has been suggested by Daniel Vetter to
Hi Ville,
The bits is 5-7 means it’s 001x for 2.97Gbps, and 010x for 1.65Gbps.
So correct value should be 2 not 1 for HDMI_MAX_DATA_RATE_297.
And HDMI_MAX_DATA_RATE_165 is 4 not 2.
I checked kernel i915 log and modified VBT to limit HDMI 1.4 from HDMI 2.0 then
found this error. And I
Quoting Tvrtko Ursulin (2019-04-09 16:38:37)
>
> On 09/04/2019 16:29, Chris Wilson wrote:
> > Consider two tasks that are running in parallel on a pair of engines
> > (vcs0, vcs1), but then must complete on a shared engine (rcs0). To
> > maximise throughput, we want to run the first ready task on
On 09/04/2019 14:56, Chris Wilson wrote:
If we have two tasks running on xcs0 and xcs1 independently, but who
queue subsequent work onto rcs, we may insert semaphores before the rcs
work and pick unwisely which task to run first. To maximise throughput,
we want to run on rcs whichever task is
On 09/04/2019 16:29, Chris Wilson wrote:
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0
== Series Details ==
Series: drm/i915: Update HDMI max TMDS data rate definition for VBT
URL : https://patchwork.freedesktop.org/series/59220/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5895_full -> Patchwork_12736_full
1 - 100 of 155 matches
Mail list logo
