Re: [Intel-gfx] [PATCH v3 05/16] drm/i915/hdcp: Move HDCP enc status timeout to header

2020-10-26 Thread Shankar, Uma
> -Original Message- > From: Anshuman Gupta > Sent: Friday, October 23, 2020 5:51 PM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: seanp...@chromium.org; Nikula, Jani ; C, > Ramalingam ; Li, Juston ; > Shankar, Uma ; Gupta, Anshuman > > Subject: [PATCH

Re: [Intel-gfx] [PATCH v3 02/16] drm/i915/hdcp: Get conn while content_type changed

2020-10-26 Thread Anshuman Gupta
On 2020-10-27 at 11:04:17 +0530, Shankar, Uma wrote: > > > > -Original Message- > > From: Anshuman Gupta > > Sent: Friday, October 23, 2020 5:51 PM > > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > > Cc: seanp...@chromium.org; Nikula, Jani ; C, > > Ramalingam ;

[Intel-gfx] [PATCH v12 05/12] drm/i915/dp: Prep for bigjoiner atomic check

2020-10-26 Thread Manasi Navare
No functional changes here. Just pass intel_atomic_state along with crtc_state to certain atomic_check functions. This will lay the foundation for adding bigjoiner master/slave states in atomic check. v2: * More prep with intel_atomic_state (Ville) Cc: Ville Syrjälä Signed-off-by: Manasi Navare

[Intel-gfx] [PATCH v12 04/12] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.

2020-10-26 Thread Manasi Navare
From: Maarten Lankhorst Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source

[Intel-gfx] [PATCH v12 06/12] drm/i915: Try to make bigjoiner work in atomic check

2020-10-26 Thread Manasi Navare
From: Maarten Lankhorst When the clock is higher than the dotclock, try with 2 pipes enabled. If we can enable 2, then we will go into big joiner mode, and steal the adjacent crtc. This only links the crtc's in software, no hardware or plane programming is done yet. Blobs are also copied

[Intel-gfx] [PATCH v12 08/12] drm/i915/dp: Master/Slave enable/disable sequence for bigjoiner

2020-10-26 Thread Manasi Navare
Enabling is done in a special sequence and so should plane updates be. Ideally the end user never notices the second pipe is used. This way ideally everything will be tear free, and updates are really atomic as userspace expects it. This uses generic modeset_enables() calls like trans port sync

Re: [Intel-gfx] [PATCH v3 04/16] drm/i915/hdcp: DP MST transcoder for link and stream

2020-10-26 Thread Shankar, Uma
> -Original Message- > From: Anshuman Gupta > Sent: Friday, October 23, 2020 5:51 PM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: seanp...@chromium.org; Nikula, Jani ; C, > Ramalingam ; Li, Juston ; > Shankar, Uma ; Gupta, Anshuman > > Subject: [PATCH

Re: [Intel-gfx] [PATCH v3 03/16] drm/i915/hotplug: Handle CP_IRQ for DP-MST

2020-10-26 Thread Shankar, Uma
> -Original Message- > From: Anshuman Gupta > Sent: Friday, October 23, 2020 5:51 PM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: seanp...@chromium.org; Nikula, Jani ; C, > Ramalingam ; Li, Juston ; > Shankar, Uma ; Gupta, Anshuman > ; Ville Syrjälä >

Re: [Intel-gfx] [PATCH v3 02/16] drm/i915/hdcp: Get conn while content_type changed

2020-10-26 Thread Shankar, Uma
> -Original Message- > From: Anshuman Gupta > Sent: Friday, October 23, 2020 5:51 PM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: seanp...@chromium.org; Nikula, Jani ; C, > Ramalingam ; Li, Juston ; > Shankar, Uma ; Gupta, Anshuman > > Subject: [PATCH

Re: [Intel-gfx] [PATCH v3 01/16] drm/i915/hdcp: Update CP property in update_pipe

2020-10-26 Thread Shankar, Uma
> -Original Message- > From: Anshuman Gupta > Sent: Friday, October 23, 2020 5:51 PM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: seanp...@chromium.org; Nikula, Jani ; C, > Ramalingam ; Li, Juston ; > Shankar, Uma ; Gupta, Anshuman > > Subject: [PATCH

[Intel-gfx] [PATCH v7 2/2] drm/i915/gvt: Add GVT resume routine to i915

2020-10-26 Thread Colin Xu
This patch add gvt resume wrapper into i915_drm_resume(). GVT relies on i915 so resume gvt at last. V2: - Direct call into gvt suspend/resume wrapper in intel_gvt.h/intel_gvt.c. The wrapper and implementation will check and call gvt routine. (zhenyu) V3: Refresh. V4: Rebase. V5: Fail

[Intel-gfx] [PATCH v7 1/2] drm/i915/gvt: Save/restore HW status to support GVT suspend/resume

2020-10-26 Thread Colin Xu
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 on each host_entry update, restore the saved dirty entries and re-init fence regs in resume routine.

[Intel-gfx] [PATCH v7 0/2] Enable GVT suspend/resume

2020-10-26 Thread Colin Xu
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-gfx] [PATCH 1/3] drm/i915: Guard debugfs against invalid access without display

2020-10-26 Thread Lucas De Marchi
Do not create the display debugfs files when we don't have display. Based on previous patch by José Souza. Cc: José Roberto de Souza Cc: Jani Nikula Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/i915_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 3/3] drm/i915: remove some debug-only registers from MCHBAR

2020-10-26 Thread Lucas De Marchi
GT_PERF_STATUS and RP_STATE_LIMITS were added a long time ago in commit 3b8d8d91d51c ("drm/i915: dynamic render p-state support for Sandy Bridge"). Other than printing their values in debugfs we don't do anything with them. There's not much useful information in them. These registers may change

[Intel-gfx] [PATCH 2/3] drm/i915/display: remove debug message from error path

2020-10-26 Thread Lucas De Marchi
First check in the function is if swsci() is supported. All the error paths are easy to figure out the reason, so remove the extra debug message: it's normal not to support swsci() e.g. in dgfx. v2: Rather than special case dgfx, just remove the debug message (from Ville) Signed-off-by:

Re: [Intel-gfx] [PATCH 1/3] drm/i915/dg1: map/unmap pll clocks

2020-10-26 Thread Lucas De Marchi
On Mon, Oct 26, 2020 at 09:32:26PM -0700, Lucas De Marchi wrote: DG1 uses 2 registers for the ddi clock mapping, with PHY A and B using DPCLKA_CFGCR0 and PHY C and D using DPCLKA1_CFGCR0. Hide this behind a single macro that chooses the correct register according to the phy being accessed, use

[Intel-gfx] [PATCH 1/3] drm/i915/dg1: map/unmap pll clocks

2020-10-26 Thread Lucas De Marchi
DG1 uses 2 registers for the ddi clock mapping, with PHY A and B using DPCLKA_CFGCR0 and PHY C and D using DPCLKA1_CFGCR0. Hide this behind a single macro that chooses the correct register according to the phy being accessed, use the correct bitfields for each pll/phy and implement separate

[Intel-gfx] [PATCH 3/3] drm/i915/dg1: make Wa_22010271021 permanent

2020-10-26 Thread Lucas De Marchi
Just like for rkl and tgl, this should be permanent as well for dg1 instead just for A0. The commit making it permanent for those platforms ended up "racing" with the commit adding the DG1 WAs, so now fix that up. v2: Add "tgl,dg1" to WA comment (Matt) Cc: Swathi Dhanavanthri Signed-off-by:

[Intel-gfx] [PATCH 2/3] drm/i915/dg1: Enable ports

2020-10-26 Thread Lucas De Marchi
From: Aditya Swarup For DG1 we have a little of mix up wrt to DDI/port names and indexes. Bspec refers to the ports as DDIA, DDIB, DDI USBC1 and DDI USBC2 (besides the DDIA, DDIB, DDIC, DDID), but the previous naming is the most unambiguous one. This means that for any register on Display Engine

[Intel-gfx] [PULL] gvt-fixes

2020-10-26 Thread Zhenyu Wang
Hi, Here's first gvt fixes for 5.10 which includes more vGPU suspend/resume fix in HWSP reset handling, and also fix for host i915 suspend regression when vGPU is created (not need to be active), and one workaround for APL guest hang issue. Thanks -- The following changes since commit

Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/gvt: Save/restore HW status to support GVT suspend/resume

2020-10-26 Thread Zhenyu Wang
On 2020.10.27 10:16:08 +0800, Colin Xu wrote: > > On 2020-10-27 09:49, Zhenyu Wang wrote: > > On 2020.10.27 08:42:40 +0800, Colin Xu wrote: > > > On 2020-10-26 17:19, Zhenyu Wang wrote: > > > > On 2020.10.23 16:17:19 +0800, Colin Xu wrote: > > > > > This patch save/restore necessary GVT info

Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/gvt: Save/restore HW status to support GVT suspend/resume

2020-10-26 Thread Colin Xu
On 2020-10-27 09:49, Zhenyu Wang wrote: On 2020.10.27 08:42:40 +0800, Colin Xu wrote: On 2020-10-26 17:19, Zhenyu Wang wrote: On 2020.10.23 16:17:19 +0800, Colin Xu wrote: This patch save/restore necessary GVT info during i915 suspend/resume so that GVT enabled QEMU VM can continue running.

Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/gvt: Save/restore HW status to support GVT suspend/resume

2020-10-26 Thread Zhenyu Wang
On 2020.10.27 08:42:40 +0800, Colin Xu wrote: > > On 2020-10-26 17:19, Zhenyu Wang wrote: > > On 2020.10.23 16:17:19 +0800, Colin Xu wrote: > > > This patch save/restore necessary GVT info during i915 suspend/resume so > > > that GVT enabled QEMU VM can continue running. > > > > > > Only GGTT

[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree

2020-10-26 Thread Stephen Rothwell
Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/virtio/virtgpu_vq.c between commit: 75ef337bdba4 ("drm: virtio: fix common struct sg_table related issues") from Linus' tree and commit: 50c3d1938ee3 ("drm/virtio: implement blob resources: fix

[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree

2020-10-26 Thread Stephen Rothwell
Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c between commit: e12e5263bf1d ("drm/msm/dpu: clean up some impossibilities") from Linus' tree and commit: 351f950db4ab ("drm/atomic: Pass the full state to CRTC atomic

[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree

2020-10-26 Thread Stephen Rothwell
Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: include/drm/drm_dp_helper.h between commit: a77ed90da6bb ("drm/dp: Define protocol converter DPCD registers") from Linus' tree and commit: 6e5702980b14 ("drm/dp: add subheadings to DPCD address definitions") from

Re: [Intel-gfx] [PATCH 2/6] drm/i915/display/psr: Use plane damage clips to calculate damaged area

2020-10-26 Thread Souza, Jose
On Mon, 2020-10-26 at 21:40 +, Mun, Gwan-gyeong wrote: > On Tue, 2020-10-13 at 16:01 -0700, José Roberto de Souza wrote: > > Now using plane damage clips property to calcualte the damaged area. > > Selective fetch only supports one region to be fetched so software > > needs to calculate a

Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/gvt: Save/restore HW status to support GVT suspend/resume

2020-10-26 Thread Colin Xu
On 2020-10-26 17:19, Zhenyu Wang wrote: On 2020.10.23 16:17:19 +0800, Colin Xu wrote: 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 on each

Re: [Intel-gfx] [PATCH 1/6] drm/i915/display/psr: Calculate selective fetch plane registers

2020-10-26 Thread Souza, Jose
On Mon, 2020-10-26 at 21:13 +, Mun, Gwan-gyeong wrote: > On Tue, 2020-10-13 at 16:01 -0700, José Roberto de Souza wrote: > > Add the calculations to set plane selective fetch registers depending > > in the value of the area damaged. > > It is still using the whole plane area as damaged but

Re: [Intel-gfx] [PATCH v11 04/12] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.

2020-10-26 Thread Navare, Manasi
On Fri, Oct 23, 2020 at 09:44:00PM +0300, Ville Syrjälä wrote: > On Fri, Oct 23, 2020 at 11:30:08AM -0700, Navare, Manasi wrote: > > On Fri, Oct 23, 2020 at 08:32:00PM +0300, Ville Syrjälä wrote: > > > On Wed, Oct 21, 2020 at 10:42:15PM -0700, Manasi Navare wrote: > > > > From: Maarten Lankhorst

Re: [Intel-gfx] [PATCH v11 10/12] drm/i915: Link planes in a bigjoiner configuration, v3.

2020-10-26 Thread Navare, Manasi
On Mon, Oct 26, 2020 at 10:18:54PM +0200, Ville Syrjälä wrote: > On Wed, Oct 21, 2020 at 10:42:21PM -0700, Manasi Navare wrote: > > From: Maarten Lankhorst > > > > Make sure that when a plane is set in a bigjoiner mode, we will add > > their counterpart to the atomic state as well. This will

Re: [Intel-gfx] [PATCH v11 10/12] drm/i915: Link planes in a bigjoiner configuration, v3.

2020-10-26 Thread Navare, Manasi
@Ville, assuming no comments or concerns as a Ack By you on this Manasi On Mon, Oct 26, 2020 at 10:18:54PM +0200, Ville Syrjälä wrote: > On Wed, Oct 21, 2020 at 10:42:21PM -0700, Manasi Navare wrote: > > From: Maarten Lankhorst > > > > Make sure that when a plane is set in a bigjoiner mode,

Re: [Intel-gfx] [PATCH v11 09/12] drm/i915: HW state readout for Bigjoiner case

2020-10-26 Thread Navare, Manasi
On Fri, Oct 23, 2020 at 09:00:25PM +0300, Ville Syrjälä wrote: > On Wed, Oct 21, 2020 at 10:42:20PM -0700, Manasi Navare wrote: > > Skip iterating over bigjoiner slaves, only the master has the state we > > care about. > > > > Add the width of the bigjoiner slave to the reconstructed fb. > > > >

Re: [Intel-gfx] [PATCH v11 09/12] drm/i915: HW state readout for Bigjoiner case

2020-10-26 Thread Navare, Manasi
@Ville all your review comments addressed and as per IRC, considering your ACK on this Manasi On Wed, Oct 21, 2020 at 10:42:20PM -0700, Manasi Navare wrote: > Skip iterating over bigjoiner slaves, only the master has the state we > care about. > > Add the width of the bigjoiner slave to the

Re: [Intel-gfx] [PATCH v11 08/12] drm/i915/dp: Master/Slave enable/disable sequence for bigjoiner

2020-10-26 Thread Navare, Manasi
@Ville, Addressed your review comments from prev review and assuming your Ack on this Manasi On Wed, Oct 21, 2020 at 10:42:19PM -0700, Manasi Navare wrote: > Enabling is done in a special sequence and so should plane updates > be. Ideally the end user never notices the second pipe is used. > >

Re: [Intel-gfx] [PATCH v11 07/12] drm/i915/dp: Modify VDSC helpers to configure DSC for Bigjoiner slave

2020-10-26 Thread Navare, Manasi
@Ville, as per our IRC discussions, I am taking your Ack on this patch Manasi On Wed, Oct 21, 2020 at 10:42:18PM -0700, Manasi Navare wrote: > Make vdsc work when no output is enabled. The big joiner needs VDSC > on the slave, so enable it and set the appropriate bits. > So remove encoder usage

Re: [Intel-gfx] [PATCH 2/6] drm/i915/display/psr: Use plane damage clips to calculate damaged area

2020-10-26 Thread Mun, Gwan-gyeong
On Tue, 2020-10-13 at 16:01 -0700, José Roberto de Souza wrote: > Now using plane damage clips property to calcualte the damaged area. > Selective fetch only supports one region to be fetched so software > needs to calculate a bounding box around all damage clips. > > Cc: Ville Syrjälä > Cc:

Re: [Intel-gfx] [PATCH 1/6] drm/i915/display/psr: Calculate selective fetch plane registers

2020-10-26 Thread Mun, Gwan-gyeong
On Tue, 2020-10-13 at 16:01 -0700, José Roberto de Souza wrote: > Add the calculations to set plane selective fetch registers depending > in the value of the area damaged. > It is still using the whole plane area as damaged but that will > change > in next patches. > > BSpec: 55229 > Cc:

Re: [Intel-gfx] [PATCH v11 10/12] drm/i915: Link planes in a bigjoiner configuration, v3.

2020-10-26 Thread Ville Syrjälä
On Wed, Oct 21, 2020 at 10:42:21PM -0700, Manasi Navare wrote: > From: Maarten Lankhorst > > Make sure that when a plane is set in a bigjoiner mode, we will add > their counterpart to the atomic state as well. This will allow us to > make sure all state is available when planes are checked. >

Re: [Intel-gfx] [PATCH 13/65] drm/omapdrm: Annotate dma-fence critical section in commit path

2020-10-26 Thread Tomi Valkeinen
On 23/10/2020 15:21, Daniel Vetter wrote: > Nothing special, just put the end right after hw_done(). Note that in > one path there's a wait for the flip/update to complete. But as far as > I understand from comments and code that's only relevant for modesets, > and skipped if there wasn't a

Re: [Intel-gfx] [PATCH] i915: Add QUIRK_EDP_CHANNEL_EQ for Dell 7200 2-in-1

2020-10-26 Thread Jason Andryuk
On Fri, Oct 23, 2020 at 8:48 AM Jason Andryuk wrote: > > We're seeing channel equalization "fail" consistently coming out of DPMS > on the eDP of a Dell Latitude 7200 2-in-1. When the display tries to > come out of DPMS, it briefly flashes on before going dark. This repeats > once per second,

Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/gvt: Save/restore HW status to support GVT suspend/resume

2020-10-26 Thread Zhenyu Wang
On 2020.10.23 16:17:19 +0800, Colin Xu wrote: > 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 on each host_entry update, restore the saved

Re: [Intel-gfx] [PATCH 2/5] drm: Compile out legacy chunks from struct drm_device

2020-10-26 Thread Daniel Vetter
On Mon, Oct 26, 2020 at 9:37 AM Thomas Zimmermann wrote: > > Hi > > Am 23.10.20 um 14:28 schrieb Daniel Vetter: > > This means some very few #ifdef in code, but it allows us to > > enlist the compiler to make sure this stuff isn't used anymore. > > > > More important, only legacy drivers change

Re: [Intel-gfx] [PATCH 5/5] drm/: Constify struct drm_driver

2020-10-26 Thread Daniel Vetter
On Mon, Oct 26, 2020 at 9:43 AM Thomas Zimmermann wrote: > > Hi > > Am 23.10.20 um 14:28 schrieb Daniel Vetter: > > Only the following drivers aren't converted: > > - amdgpu, because of the driver_feature mangling due to virt support > > - nouveau, because DRIVER_ATOMIC uapi is still not the

Re: [Intel-gfx] [PATCH] drm: Don't create the IN_FORMATS blob when the driver does not provide .format_mod_supported()

2020-10-26 Thread Daniel Vetter
On Sat, Oct 24, 2020 at 12:52 AM Ville Syrjälä wrote: > > On Fri, Oct 23, 2020 at 10:03:50PM +, Simon Ser wrote: > > On Friday, October 23, 2020 10:39 PM, Ville Syrjala > > wrote: > > > > > From: Ville Syrjälä ville.syrj...@linux.intel.com > > > > > > The code responsible for creating the

Re: [Intel-gfx] [PATCH 5/5] drm/: Constify struct drm_driver

2020-10-26 Thread Thomas Zimmermann
Hi Am 23.10.20 um 14:28 schrieb Daniel Vetter: > Only the following drivers aren't converted: > - amdgpu, because of the driver_feature mangling due to virt support > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > platforms where it's supported (i.e. again

Re: [Intel-gfx] [PATCH 4/5] drm: Allow const struct drm_driver

2020-10-26 Thread Thomas Zimmermann
Hi Am 23.10.20 um 14:28 schrieb Daniel Vetter: > It's nice if a big function/ioctl table like this is const. Only > downside here is that we need a few more #ifdef to paper over the > differences when CONFIG_DRM_LEGACY is enabled. Maybe provides more > motivation to sunset that horror show :-) >

Re: [Intel-gfx] [PATCH 2/5] drm: Compile out legacy chunks from struct drm_device

2020-10-26 Thread Thomas Zimmermann
Hi Am 23.10.20 um 14:28 schrieb Daniel Vetter: > This means some very few #ifdef in code, but it allows us to > enlist the compiler to make sure this stuff isn't used anymore. > > More important, only legacy drivers change drm_device (for the > legacy_dev_list shadow attach management),