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: primary,
== 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: WARNING:COMMIT
== 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
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
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 is
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 inse
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 don't
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ä
> ---
> drivers/gpu/d
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 ear
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 alway
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 cu
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 hdmi_deep_color_po
== 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: Co-a
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 &dev_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 v
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 Syrjälä
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, 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 does
== 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
---
**SUCCESS**
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
+++ b/tes
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
> > > t
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 m
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 poin
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
AZX_DCAPS_I915_PO
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 it'
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
comf
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 firmwar
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 +-
drivers/gpu/drm/i915/intel_
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 pi
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 100644
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, it
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 inaccessi
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: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 m
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
https://lists.freedesktop.org/
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 it
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 i915_gem_resume(stru
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 GuC
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 intel_huc_init_mi
== 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
-
== 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: drm/i915/uc:
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
>>
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 disp
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 firmware
== 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
---
**
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 drm_i9
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
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
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).
> > D
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 Fri,
== 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
---
**FAILURE**
== 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
Summary
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 t
== 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 usel
== 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 : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5897_full -> Patchwork_12742_full
==
On Wed, Apr 10, 2019 at 01:17:19PM +1000, Alastair D'Silva wrote:
> @@ -107,7 +108,7 @@ EXPORT_SYMBOL(bin2hex);
> * string if enough space had been available.
> */
> int hex_dump_to_buffer(const void *buf, size_t len, int rowsize, int
> groupsize,
> -char *linebuf, size_t
101 - 154 of 154 matches
Mail list logo
