This patchset enables GVT suspend/resume so that GVT enabled VM can
continue running after host resuming from suspend state.
V2:
- Change kzalloc/kfree to vzalloc/vfree since the space allocated
from kmalloc may not enough for all saved GGTT entries.
- Keep gvt suspend/resume wrapper in intel_gvt.
This patch save/restore necessary GVT info during i915 suspend/resume so
that GVT enabled QEMU VM can continue running.
Only GGTT and fence regs are saved/restored now. GVT will save GGTT
entries into GVT in suspend routine, and restore the saved entries
and re-init fence regs in resume routine.
This patch add gvt suspend/resume wrapper into i915: i915_drm_suspend()
and i915_drm_resume(). GVT relies on i915 so suspend gvt ahead of other
i915 sub-routine and resume gvt at last.
V2:
- Direct call into gvt suspend/resume wrapper in intel_gvt.h/intel_gvt.c.
The wrapper and implementation will
Hi Stephen,
On 9/8/20 6:00 AM, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_panel.c
between commit:
f8bd54d21904 ("drm/i915: panel: Use atomic PWM API for devs with an external PWM
controller")
fr
== Series Details ==
Series: series starting with [1/3] drm/atomic-helper: Extract
drm_atomic_helper_calc_timestamping_constants()
URL : https://patchwork.freedesktop.org/series/81419/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8971_full -> Patchwork_18448_full
===
On 01/09/2020 08:22, Sam McNally wrote:
> From: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> [sa...@chromium.org:
> - rebased
> - removed polling-related changes
> - moved the calls to drm_dp_cec_(un)set_edid() into the next patch
> ]
> Signed-off-by: Sam McNally
> ---
>
> .../display/am
On 2020/9/8 14:23, Christoph Hellwig wrote:
On Tue, Sep 08, 2020 at 02:04:53PM +0800, Lu Baolu wrote:
Do you mind telling where can I find Marek's series?
[PATCH v10 00/30] DRM: fix struct sg_table nents vs. orig_nents misuse
on various lists including the iommu one.
Get it. Thank you!
Be
On 2020.09.07 23:02:03 +0300, Zhi Wang wrote:
> To support ww locking and per-object implemented in i915, GVT scheduler needs
> to be refined. Most of the changes are located in shadow batch buffer, shadow
> wa context in GVT-g, where use quite a lot of i915 gem object APIs.
>
> Cc: Maarten Lankho
Hi Hans,
On Tue, 8 Sep 2020 10:22:06 +0200 Hans de Goede wrote:
>
> On 9/8/20 6:00 AM, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the drm-intel tree got a conflict in:
> >
> >drivers/gpu/drm/i915/display/intel_panel.c
> >
> > between commit:
> >
> >f8bd54d21904 ("drm/
== Series Details ==
Series: drm/i915: Nuke dpio_phy_iosf_port[]
URL : https://patchwork.freedesktop.org/series/81431/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8973_full -> Patchwork_18449_full
Summary
---
**SUC
On Mon, Sep 07, 2020 at 08:14:38PM +0200, Daniel Vetter wrote:
> On Mon, Sep 07, 2020 at 03:00:26PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We update the timestamping constants per-crtc explicitly in
> > intel_crtc_update_active_timings(). Furtermore the helper will
> > use ua
== Series Details ==
Series: drm/i915/gvt: Introduce per object locking in GVT scheduler.
URL : https://patchwork.freedesktop.org/series/81434/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8973_full -> Patchwork_18450_full
This is a note to let you know that I've just added the patch titled
drm/i915: Fix sha_text population code
to the 5.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-fix-sha
== Series Details ==
Series: Patch "drm/i915: Fix sha_text population code" has been added to the
5.8-stable tree
URL : https://patchwork.freedesktop.org/series/81458/
State : failure
== Summary ==
Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to
Hi,
On 9/8/20 1:04 PM, Stephen Rothwell wrote:
Hi Hans,
On Tue, 8 Sep 2020 10:22:06 +0200 Hans de Goede wrote:
On 9/8/20 6:00 AM, Stephen Rothwell wrote:
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_panel.c
between commit:
From: Ville Syrjälä
We don't save/restore PCH_PORT_HOTPLUG so no point in reseving
space for the value.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a4
From: Ville Syrjälä
The FBC_CONTROL save restore is there just to preserve the
compression interval setting. Since commit a68ce21ba0c4
("drm/i915/fbc: Store the fbc1 compression interval in the params")
we've been explicitly setting the interval to a specific
value, so the sace/restore is now ent
From: Ville Syrjälä
Originally added in commit 1f84e550a870 ("drm/i915 more registers for
S3 (DSPCLK_GATE_D, CACHE_MODE_0, MI_ARB_STATE)") to fix some underruns.
I suspect that was due to the trickle feed settings getting clobbered
during suspend. We've been disabling trickle feed explicitly sinc
From: Ville Syrjälä
The CACHE_MODE_0 save/restore was added without explanation in
commit 1f84e550a870 ("drm/i915 more registers for S3 (DSPCLK_GATE_D,
CACHE_MODE_0, MI_ARB_STATE)"). If there are any bits we care about
those should be set explicitly during some appropriate init function.
Let's as
On 2020-09-03 10:26 a.m., Daniel Vetter wrote:
> On Wed, Sep 02, 2020 at 09:26:27AM +0200, Daniel Vetter wrote:
>> Following functions are only used internally, not by drivers:
>> - devm_drm_dev_init
>>
>> Also, now that we have a very slick and polished way to allocate a
>> drm_device with devm_dr
On Fri, 28 Aug 2020 at 00:34, Tom Murphy wrote:
>
> On Thu, 27 Aug 2020 at 22:36, Logan Gunthorpe wrote:
> >
> >
> >
> > On 2020-08-23 6:04 p.m., Tom Murphy wrote:
> > > I have added a check for the sg_dma_len == 0 :
> > > """
> > > } __sgt_iter(struct scatterlist *sgl, bool dma) {
> > >
On Thu, Sep 03, 2020 at 09:18:37PM +0100, Tom Murphy wrote:
> Disable combining sg segments in the dma-iommu api.
> Combining the sg segments exposes a bug in the intel i915 driver which
> causes visual artifacts and the screen to freeze. This is most likely
> because of how the i915 handles the re
On Tue, Sep 08, 2020 at 06:36:19AM +0100, Christoph Hellwig wrote:
> On Mon, Sep 07, 2020 at 09:18:50PM +0100, Tom Murphy wrote:
> > Yeah we talked about passing an attr to map_sg to disable merging at
> > the following microconfernce:
> > https://linuxplumbersconf.org/event/7/contributions/846/
>
On Mon, Sep 07, 2020 at 09:18:50PM +0100, Tom Murphy wrote:
> Yeah we talked about passing an attr to map_sg to disable merging at
> the following microconfernce:
> https://linuxplumbersconf.org/event/7/contributions/846/
> As far as I can remember everyone seemed happy with that solution. I
> won'
On Mon, 7 Sep 2020 at 08:00, Christoph Hellwig wrote:
>
> On Thu, Sep 03, 2020 at 09:18:37PM +0100, Tom Murphy wrote:
> > Disable combining sg segments in the dma-iommu api.
> > Combining the sg segments exposes a bug in the intel i915 driver which
> > causes visual artifacts and the screen to fre
In the function intel_vgpu_reg_rw_edid of gvt/kvmgt.c, pos can get equal to
NULL for GPUs that do not
properly support EDID. In those cases, when pos gets passed to the handle_edid
functions, it
gets added a short offset then it's dereferenced in memcpy's, leading to a
kernel
oops: null pointer
On 11.02.20 18:04, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> WARN if the encoder possible_crtcs is effectively empty or contains
>> bits for non-existing crtcs.
>>
>> v2: Move to drm_mode_config_validate() (Daniel)
>> Mak
On Tue, Sep 08, 2020 at 02:04:53PM +0800, Lu Baolu wrote:
> Do you mind telling where can I find Marek's series?
[PATCH v10 00/30] DRM: fix struct sg_table nents vs. orig_nents misuse
on various lists including the iommu one.
___
Intel-gfx mailing list
== Series Details ==
Series: series starting with [1/4] drm/i915: Kill unused savePCH_PORT_HOTPLUG
URL : https://patchwork.freedesktop.org/series/81461/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8982 -> Patchwork_18453
== Series Details ==
Series: Fixed NULL pointer dereference in handle_edid functions for GPUs that
do not support EDID
URL : https://patchwork.freedesktop.org/series/81463/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
24f0f91b0b97 Fixed NULL pointer dereference in handle_edid
== Series Details ==
Series: Fixed NULL pointer dereference in handle_edid functions for GPUs that
do not support EDID
URL : https://patchwork.freedesktop.org/series/81463/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8982 -> Patchwork_18454
=
Hi,
On 27/08/2020 22:36, Logan Gunthorpe wrote:
On 2020-08-23 6:04 p.m., Tom Murphy wrote:
I have added a check for the sg_dma_len == 0 :
"""
} __sgt_iter(struct scatterlist *sgl, bool dma) {
struct sgt_iter s = { .sgp = sgl };
+ if (sgl && sg_dma_len(sgl) == 0)
+
From: Sean Paul
commit 9ab57658a608f879469ffa22b723c4539c05a58f upstream.
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers
On 2020-09-08 9:28 a.m., Tvrtko Ursulin wrote:
>>
>> diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
>> b/drivers/gpu/drm/i915/i915
>> index b7b59328cb76..9367ac801f0c 100644
>> --- a/drivers/gpu/drm/i915/i915_scatterlist.h
>> +++ b/drivers/gpu/drm/i915/i915_scatterlist.h
>> @@ -27,13 +27,19
On 08/09/2020 16:44, Logan Gunthorpe wrote:
On 2020-09-08 9:28 a.m., Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
b/drivers/gpu/drm/i915/i915
index b7b59328cb76..9367ac801f0c 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.h
+++ b/drivers/gpu/drm/i915/i915_scat
> In the function intel_vgpu_reg_rw_edid of gvt/kvmgt.c, pos can get equal to
> NULL for GPUs that do not
> properly support EDID. …
* I propose to reconsider the previous patch subject once more.
* Did the script “checkpatch.pl” point any adjustment possibilities out
for the change descriptio
On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> We need to go up to AUX_CH_I (aka. AUX CH USBC6) these days.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
> ---
>
On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> We need to go up to PORT_I (aka. TC6) these days.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
> ---
> drivers/g
On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> AUX CH H/I need their power domains too.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
> ---
> drivers/gpu/drm/i9
On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> VBT has ports H and I since version 217.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
> ---
> drivers/gpu/drm/i9
On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> As with everything else VBT can now specify AUX CH H or I.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
> ---
>
On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> We have nice parametrized GEN11_{TC,TBT}_HOTPLUG() so nuke
> the overlapping defines.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä <
> ville.syrj...@li
On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> gen11_hpd_detection_setup() is missing ports TC5/6. Add them.
>
> TODO: Might be nice to only enable the hpd detection logic
> for ports we actually have. Should be rolled out f
On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> No reason to stuff both DDI and TC port handling into the same
> function. Split it into two.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä <
> ville.sy
On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> Currently DP/HDMI/DDI encoders init their hpd_pin from the
> connector init. Let's move it to the encoder init so that
> we don't need to add platform specific junk to the connec
On Wed, 2020-07-01 at 00:56 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> No point in assigning the function return value to a local
> variable if we're just going to use it the one time.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a few helpers to let us better identify which kind of DFP
> we're dealing with.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 60 +
> include/drm/d
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Deal with more cases in drm_dp_downstream_max_bpc():
> - DPCD 1.0 -> assume 8bpc for non-DP
> - DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything
> - DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value is
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Deal with more cases in drm_dp_downstream_max_bpc():
> - DPCD 1.0 -> assume 8bpc for non-DP
> - DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything
> - DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value is
BTW - we started using drm_dp_downstream_max_clock() in nouveau, so you'll
need to update the function call there too.
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to differentiate between the DFP dotclock and TMDS clock
> limits. Let's convert the cu
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add helpers to get the TMDS clock limits for HDMI/DVI downstream
> facing ports.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 116
> include/drm/drm_
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add helpers to get the TMDS clock limits for HDMI/DVI downstream
> facing ports.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 116
> include/drm/drm_
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> DP 1.3 adds some extra control knobs for DP->HDMI protocol conversion.
> Let's use that to configure the "HDMI mode" (ie. infoframes vs. not)
> based on the capabilities of the sink.
>
> Signed-off-by: Ville Syrjäl
In the function intel_vgpu_reg_rw_edid of kvmgt.c, pos can be equal
to NULL for GPUs that do not properly support EDID. In those cases, when
pos gets passed to the handle_edid functions, it gets added a short offset
then it's dereferenced in memcpy's, leading to NULL pointer
dereference kernel oops
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The downstream facing port caps in the DPCD can give us a hint
> as to what kind of display mode the sink can use if it doesn't
> have an EDID. Use that information to pick a suitable mode.
>
> Signed-off-by: Ville
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add helpers to determine whether the DFP supports
> YCbCr 4:2:0 passthrough or YCbCr 4:4:4->4:2:0 conversion.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 44
== Series Details ==
Series: drm/i915/gvt: Prevent NULL pointer dereference in
intel_vgpu_reg_rw_edid()
URL : https://patchwork.freedesktop.org/series/81470/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cc442c9d2d41 drm/i915/gvt: Prevent NULL pointer dereference in
intel_vgp
With the nitpicks addressed (note there were a couple of other spots where we
wanted to use Return: in the kdocs, but I didn't bother pointing all of them
out), all but patch 07 is:
Reviewed-by: Lyude Paul
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Attemp
== Series Details ==
Series: drm/i915/gvt: Prevent NULL pointer dereference in
intel_vgpu_reg_rw_edid()
URL : https://patchwork.freedesktop.org/series/81470/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8982 -> Patchwork_18455
== Series Details ==
Series: drm/i915/gvt: Prevent NULL pointer dereference in
intel_vgpu_reg_rw_edid()
URL : https://patchwork.freedesktop.org/series/81470/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8982_full -> Patchwork_18455_full
==
> On Sep 3, 2020, at 10:04 AM, Srivatsa, Anusha
> wrote:
>
>
>
>> -Original Message-
>> From: Vivi, Rodrigo
>> Sent: Wednesday, September 2, 2020 2:32 PM
>> To: Srivatsa, Anusha
>> Cc: intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_
Hi!
> > > > Thanks for the patches. I assume this should fix problem from
> > > > "5.9-rc1: graphics regression moved from -next to mainline" thread.
> > > >
> > > > I have applied them over current -next, and my machine seems to be
> > > > working so far (but uptime is less than 30 minutes).
> >
Hi Daniel,
Thanks for this work.
This change works smoothly to me. However, there is a check in the vkms_exit
that doesn't look very good. Please, see inline comment.
On 09/04, Daniel Vetter wrote:
> This means we also need to slightly restructure the exit code, so that
> final cleanup of the dr
We currenty check for platform at multiple parts in the driver
to grab the correct PLL. Let us begin to centralize it through a
helper function.
v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg() (Ville)
v3: Clean up combo_pll_disable() (Rodrigo)
Suggested-by: Matt Roper
Cc: Ville Sy
== Series Details ==
Series: drm/i915/pll: Centralize PLL_ENABLE register lookup (rev3)
URL : https://patchwork.freedesktop.org/series/81150/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3be3651c4fb7 drm/i915/pll: Centralize PLL_ENABLE register lookup
-:33: CHECK:PARENTHESIS_A
== Series Details ==
Series: drm/i915/pll: Centralize PLL_ENABLE register lookup (rev3)
URL : https://patchwork.freedesktop.org/series/81150/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8985 -> Patchwork_18456
Summary
---
On Wed, 2020-07-01 at 00:56 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> Introduce intel_hpd_hotplug_irqs() as a partner to
> intel_hpd_enabled_irqs(). There's no need to care about the
> encoders which we're not exposing, so we can avoid hardocoding
I tested this patch on the suspend/resume case with vGPU created (no
need really activate), can still observer the system freeze issue as
mentioned in another patch I sent. So I suppose we still need decouple
context pin/unpin with submission setup/clean, but move to workload
create/destroy?
Hi Christoph,
On 9/8/20 2:23 PM, Christoph Hellwig wrote:
On Tue, Sep 08, 2020 at 02:04:53PM +0800, Lu Baolu wrote:
Do you mind telling where can I find Marek's series?
[PATCH v10 00/30] DRM: fix struct sg_table nents vs. orig_nents misuse
on various lists including the iommu one.
It seem
On 2020.09.09 09:43:21 +0800, Colin Xu wrote:
> I tested this patch on the suspend/resume case with vGPU created (no need
> really activate), can still observer the system freeze issue as mentioned in
> another patch I sent. So I suppose we still need decouple context pin/unpin
> with submission se
On 2020-09-09 10:06, Zhenyu Wang wrote:
On 2020.09.09 09:43:21 +0800, Colin Xu wrote:
I tested this patch on the suspend/resume case with vGPU created (no need
really activate), can still observer the system freeze issue as mentioned in
another patch I sent. So I suppose we still need decouple
71 matches
Mail list logo
