Re: [Intel-gfx] [PATCH v5 1/5] drm: Introduce plane and CRTC scaling filter properties

2020-08-25 Thread Laxminarayan Bharadiya, Pankaj



> -Original Message-
> From: Shankar, Uma 
> Sent: 19 August 2020 13:44
> To: Laxminarayan Bharadiya, Pankaj
> ; jani.nik...@linux.intel.com;
> dan...@ffwll.ch; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> dani...@collabora.com; Lattannavar, Sameer
> ; Maarten Lankhorst
> ; Maxime Ripard ;
> Thomas Zimmermann ; David Airlie 
> Subject: RE: [Intel-gfx] [PATCH v5 1/5] drm: Introduce plane and CRTC scaling
> filter properties
> 
> 
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Pankaj Bharadiya
> > Sent: Monday, August 3, 2020 10:00 AM
> > To: jani.nik...@linux.intel.com; dan...@ffwll.ch;
> > intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> > ville.syrj...@linux.intel.com; dani...@collabora.com; Lattannavar,
> > Sameer ; Maarten Lankhorst
> > ; Maxime Ripard
> > ; Thomas Zimmermann ;
> David
> > Airlie 
> > Subject: [Intel-gfx] [PATCH v5 1/5] drm: Introduce plane and CRTC
> > scaling filter properties
> >
> > Introduce per-plane and per-CRTC scaling filter properties to allow
> > userspace to select the driver's default scaling filter or
> > Nearest-neighbor(NN) filter for upscaling operations on CRTC and plane.
> >
> > Drivers can set up this property for a plane by calling
> > drm_plane_create_scaling_filter() and for a CRTC by calling
> > drm_crtc_create_scaling_filter().
> >
> > NN filter works by filling in the missing color values in the upscaled
> > image with that of the coordinate-mapped nearest source pixel value.
> >
> > NN filter for integer multiple scaling can be particularly useful for
> > for pixel art games that rely on sharp, blocky images to deliver their 
> > distinctive
> look.
> >
> > changes since v3:
> > * Refactor code, add new function for common code (Ville) changes since v2:
> > * Create per-plane and per-CRTC scaling filter property (Ville) changes 
> > since
> v1:
> > * None
> > changes since RFC:
> > * Add separate properties for plane and CRTC (Ville)
> >
> > Signed-off-by: Pankaj Bharadiya
> > 
> > ---
> >  drivers/gpu/drm/drm_atomic_uapi.c   |  8 +++
> >  drivers/gpu/drm/drm_crtc.c  | 48 +++
> >  drivers/gpu/drm/drm_crtc_internal.h |  3 +
> >  drivers/gpu/drm/drm_plane.c | 90 +
> >  include/drm/drm_crtc.h  | 16 +
> >  include/drm/drm_plane.h | 21 +++
> >  6 files changed, 186 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 25c269bc4681..ef82009035e6 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct
> > drm_crtc *crtc,
> > return -EFAULT;
> >
> > set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> > +   } else if (property == crtc->scaling_filter_property) {
> > +   state->scaling_filter = val;
> > } else if (crtc->funcs->atomic_set_property) {
> > return crtc->funcs->atomic_set_property(crtc, state, property,
> > val);
> > } else {
> > @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> > else if (property == config->prop_out_fence_ptr)
> > *val = 0;
> > +   else if (property == crtc->scaling_filter_property)
> > +   *val = state->scaling_filter;
> > else if (crtc->funcs->atomic_get_property)
> > return crtc->funcs->atomic_get_property(crtc, state, property,
> > val);
> > else
> > @@ -585,6 +589,8 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane,
> > sizeof(struct drm_rect),
> > &replaced);
> > return ret;
> > +   } else if (property == plane->scaling_filter_property) {
> > +   state->scaling_filter = val;
> > } else if (plane->funcs->atomic_set_property) {
> > return plane->funcs->atomic_set_property(plane, state,
> > property, val);
> > @@ -643,6 +649,8 @@ drm_atomic_plane_get_property(struct drm_plane
> > *plane,
> > } else if (property == config->prop_fb_damage_clips) {
> > *val = (state->fb_damage_clips) ?
> > state->fb_damage_clips->base.id : 0;
> > +   } else if (property == plane->scaling_filter_property) {
> > +   *val = state->scaling_filter;
> > } else if (plane->funcs->atomic_get_property) {
> > return plane->funcs->atomic_get_property(plane, state,
> property,
> > val);
> > } else {
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 283bcc4362ca..70f5cd9704ba 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -776,3 +776,51 @@ int drm_mode_crtc_set_obj_prop(struct
> > drm_mode_object *obj,
> >
>

Re: [Intel-gfx] [PATCH v2 07/24] drm/i915: Parse command buffer earlier in eb_relocate(slow)

2020-08-25 Thread Maarten Lankhorst
Op 19-08-2020 om 16:08 schreef Maarten Lankhorst:
> We want to introduce backoff logic, but we need to lock the
> pool object as well for command parsing. Because of this, we
> will need backoff logic for the engine pool obj, move the batch
> validation up slightly to eb_lookup_vmas, and the actual command
> parsing in a separate function which can get called from execbuf
> relocation fast and slowpath.
>
> Signed-off-by: Maarten Lankhorst 
Missing from the previous version:

Reviewed-by: Thomas Hellström  And pushed, thanks 
for reviews. :-)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/5] Critical-KlockWork-Fixes-intel_display.c-NullDeref

2020-08-25 Thread Dan Carpenter
Hi Nischal,

Thank you for the patch! Perhaps something to improve:

url:
https://github.com/0day-ci/linux/commits/Nischal-Varide/Critical-KclockWork-Fixes-intel_atomi-c-PossibleNull/20200819-193249
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-m021-20200824 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 

New smatch warnings:
drivers/gpu/drm/i915/display/intel_display.c:2271 intel_pin_and_fence_fb_obj() 
error: uninitialized symbol 'vma'.
drivers/gpu/drm/i915/display/intel_display.c:11280 intel_cursor_base() error: 
uninitialized symbol 'base'.

Old smatch warnings:
drivers/gpu/drm/i915/display/intel_display.c:6183 skl_update_scaler_plane() 
error: we previously assumed 'fb' could be null (see line 6167)

# 
https://github.com/0day-ci/linux/commit/5d862961b8571914f726e947570316016ec67c5d
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Nischal-Varide/Critical-KclockWork-Fixes-intel_atomi-c-PossibleNull/20200819-193249
git checkout 5d862961b8571914f726e947570316016ec67c5d
vim +/vma +2271 drivers/gpu/drm/i915/display/intel_display.c

058d88c4330f96 drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2016-08-15  2217  struct i915_vma *
5935485f8eee35 drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2018-02-20  2218  intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
f5929c5309a6a4 drivers/gpu/drm/i915/intel_display.c Ville Syrjälä   
   2018-09-07  2219const struct i915_ggtt_view *view,
f7a02ad7d16b24 drivers/gpu/drm/i915/intel_display.c Ville Syrjälä   
   2018-02-21  2220bool uses_fence,
5935485f8eee35 drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2018-02-20  2221unsigned long *out_flags)
6b95a207c1fd55 drivers/gpu/drm/i915/intel_display.c Kristian Høgsberg   
   2009-11-18    {
850c4cdc6c223d drivers/gpu/drm/i915/intel_display.c Tvrtko Ursulin  
   2014-10-30  2223 struct drm_device *dev = fb->dev;
fac5e23e3c385f drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2016-07-04  2224 struct drm_i915_private *dev_priv = to_i915(dev);
850c4cdc6c223d drivers/gpu/drm/i915/intel_display.c Tvrtko Ursulin  
   2014-10-30  2225 struct drm_i915_gem_object *obj = intel_fb_obj(fb);
1d264d91befc31 drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2019-01-14  2226 intel_wakeref_t wakeref;
058d88c4330f96 drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2016-08-15  2227 struct i915_vma *vma;
5935485f8eee35 drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2018-02-20  2228 unsigned int pinctl;
6b95a207c1fd55 drivers/gpu/drm/i915/intel_display.c Kristian Høgsberg   
   2009-11-18  2229 u32 alignment;
6b95a207c1fd55 drivers/gpu/drm/i915/intel_display.c Kristian Høgsberg   
   2009-11-18  2230  
e57291c2d39522 drivers/gpu/drm/i915/display/intel_display.c Pankaj Bharadiya
   2020-02-20  2231 if (drm_WARN_ON(dev, 
!i915_gem_object_is_framebuffer(obj)))
5a90606df7cb73 drivers/gpu/drm/i915/display/intel_display.c Chris Wilson
   2019-09-02  2232 return ERR_PTR(-EINVAL);
ebcdd39eafb1d8 drivers/gpu/drm/i915/intel_display.c Matt Roper  
   2014-07-09  2233  
d88c4afddc5519 drivers/gpu/drm/i915/intel_display.c Ville Syrjälä   
   2017-03-07  2234 alignment = intel_surf_alignment(fb, 0);
e57291c2d39522 drivers/gpu/drm/i915/display/intel_display.c Pankaj Bharadiya
   2020-02-20  2235 if (drm_WARN_ON(dev, alignment && 
!is_power_of_2(alignment)))
7361bdb26c2ca6 drivers/gpu/drm/i915/display/intel_display.c Imre Deak   
   2019-12-25  2236 return ERR_PTR(-EINVAL);
6b95a207c1fd55 drivers/gpu/drm/i915/intel_display.c Kristian Høgsberg   
   2009-11-18  2237  
693db1842d864c drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2013-03-05  2238 /* Note that the w/a also requires 64 PTE of padding 
following the
693db1842d864c drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2013-03-05  2239  * bo. We currently fill all unused PTE with the shadow 
page and so
693db1842d864c drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2013-03-05  2240  * we should always have valid PTE following the 
scanout preventing
693db1842d864c drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2013-03-05  2241  * the VT-d warning.
693db1842d864c drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2013-03-05  2242  */
48f112fed3b078 drivers/gpu/drm/i915/intel_display.c Chris Wilson
   2016-06-24  2243 if (intel_s

Re: [Intel-gfx] [PATCH 4/5] Critical-KlockWork-Fix-intel_tv.c-Possible-Null

2020-08-25 Thread Dan Carpenter
Hi Nischal,

Thank you for the patch! Perhaps something to improve:

url:
https://github.com/0day-ci/linux/commits/Nischal-Varide/Critical-KclockWork-Fixes-intel_atomi-c-PossibleNull/20200819-193249
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-m021-20200824 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 

smatch warnings:
drivers/gpu/drm/i915/display/intel_tv.c:1842 intel_tv_atomic_check() warn: 
variable dereferenced before check 'new_state' (see line 1840)

# 
https://github.com/0day-ci/linux/commit/6fb528c1b424d3c8095085afa7e777ac5502450b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Nischal-Varide/Critical-KclockWork-Fixes-intel_atomi-c-PossibleNull/20200819-193249
git checkout 6fb528c1b424d3c8095085afa7e777ac5502450b
vim +/new_state +1842 drivers/gpu/drm/i915/display/intel_tv.c

0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1831  static int intel_tv_atomic_check(struct drm_connector 
*connector,
6f3b62781bbd26 drivers/gpu/drm/i915/intel_tv.c Sean Paul 
2019-06-11  1832struct drm_atomic_state *state)
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1833  {
6f3b62781bbd26 drivers/gpu/drm/i915/intel_tv.c Sean Paul 
2019-06-11  1834   struct drm_connector_state *new_state;
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1835   struct drm_crtc_state *new_crtc_state;
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1836   struct drm_connector_state *old_state;
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1837  
6f3b62781bbd26 drivers/gpu/drm/i915/intel_tv.c Sean Paul 
2019-06-11  1838   new_state = drm_atomic_get_new_connector_state(state, 
connector);
6f3b62781bbd26 drivers/gpu/drm/i915/intel_tv.c Sean Paul 
2019-06-11  1839   old_state = drm_atomic_get_old_connector_state(state, 
connector);
6f3b62781bbd26 drivers/gpu/drm/i915/intel_tv.c Sean Paul 
2019-06-11 @1840   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
new_state->crtc);

  
^^^
Dereference

0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1841  
6fb528c1b424d3 drivers/gpu/drm/i915/display/intel_tv.c Nischal Varide
2020-08-19 @1842   if (!(old_state && new_state && new_crtc_state))

   ^
Checked too late

6fb528c1b424d3 drivers/gpu/drm/i915/display/intel_tv.c Nischal Varide
2020-08-19  1843   return 0;
6fb528c1b424d3 drivers/gpu/drm/i915/display/intel_tv.c Nischal Varide
2020-08-19  1844  
6fb528c1b424d3 drivers/gpu/drm/i915/display/intel_tv.c Nischal Varide
2020-08-19  1845   if (!new_state->crtc)
6fb528c1b424d3 drivers/gpu/drm/i915/display/intel_tv.c Nischal Varide
2020-08-19  1846   return 0;
6fb528c1b424d3 drivers/gpu/drm/i915/display/intel_tv.c Nischal Varide
2020-08-19  1847  
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1848   if (old_state->tv.mode != new_state->tv.mode ||
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1849   old_state->tv.margins.left != 
new_state->tv.margins.left ||
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1850   old_state->tv.margins.right != 
new_state->tv.margins.right ||
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1851   old_state->tv.margins.top != 
new_state->tv.margins.top ||
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1852   old_state->tv.margins.bottom != 
new_state->tv.margins.bottom) {
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1853   /* Force a modeset. */
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1854  
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1855   new_crtc_state->connectors_changed = true;
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1856   }
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1857  
0e891b3f447f4d drivers/gpu/drm/i915/intel_tv.c Maarten Lankhorst 
2017-04-10  1858   

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

2020-08-25 Thread Jani Nikula
On Fri, 21 Aug 2020, Pavel Machek  wrote:
> On Thu 2020-08-20 09:16:18, Linus Torvalds wrote:
>> On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek  wrote:
>> >
>> > Yes, it seems they make things work. (Chris asked for new patch to be
>> > tested, so I am switching to his kernel, but it survived longer than
>> > it usually does.)
>> 
>> Ok, so at worst we know how to solve it, at best the reverts won't be
>> needed because Chris' patch will fix the issue properly.
>> 
>> So I'll archive this thread, but remind me if this hasn't gotten
>> sorted out in the later rc's.
>
> Yes, thank you, it seems we have a solution w/o the revert.

For posterity, I'm told the fix is [1].

BR,
Jani.


[1] https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/


-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 02/16] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation)

2020-08-25 Thread Hans de Goede
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:

Method (_PS3, 0, Serialized)  // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
...
}

Where PSAT is the power-status register of the PWM controller.

Since the i915 driver will do a pwm_get on the pwm device as it uses it to
control the LCD panel backlight, there is a device-link marking the i915
device as a consumer of the pwm device. So that the PWM controller will
always be suspended after the i915 driver suspends (which is the right
thing to do). This causes the above GFX0 PS3 AML code to run before
acpi_lpss.c calls acpi_lpss_save_ctx().

So on these devices the PWM controller will already be off when
acpi_lpss_save_ctx() runs. This causes it to read/save all 1-s (0x)
as ctx register values.

When these bogus values get restored on resume the PWM controller actually
keeps working, since most bits are reserved, but this does set bit 3 of
the LPSS General purpose register, which for the PWM controller has the
following function: "This bit is re-used to support 32kHz slow mode.
Default is 19.2MHz as PWM source clock".

This causes the clock of the PWM controller to switch from 19.2MHz to
32KHz, which is a slow-down of a factor 600. Surprisingly enough so far
there have been few bug reports about this. This is likely because the
i915 driver was hardcoding the PWM frequency to 46 KHz, which divided
by 600 would result in a PWM frequency of approx. 78 Hz, which mostly
still works fine. There are some bug reports about the LCD backlight
flickering after suspend/resume which are likely caused by this issue.

But with the upcoming patch-series to finally switch the i915 drivers
code for external PWM controllers to use the atomic API and to honor
the PWM frequency specified in the video BIOS (VBT), this becomes a much
bigger problem. On most cases the VBT specifies either 200 Hz or 20
KHz as PWM frequency, which with the mentioned issue ends up being either
1/3 Hz, where the backlight actually visible blinks on and off every 3s,
or in 33 Hz and horrible flickering of the backlight.

There are a number of possible solutions to this problem:

1. Make acpi_lpss_save_ctx() run before GFX0._PS3
 Pro: Clean solution from pov of not medling with save/restore ctx code
 Con: As mentioned the current ordering is the right thing to do
 Con: Requires assymmetry in at what suspend/resume phase we do the save vs
  restore, requiring more suspend/resume ordering hacks in already
  convoluted acpi_lpss.c suspend/resume code.
2. Do some sort of save once mode for the LPSS ctx
 Pro: Reasonably clean
 Con: Needs a new LPSS flag + code changes to handle the flag
3. Detect we have failed to save the ctx registers and do not restore them
 Pro: Not PWM specific, might help with issues on other LPSS devices too
 Con: If we can get away with not restoring the ctx why bother with it at
  all?
4. Do not save the ctx for CHT PWM controllers
 Pro: Clean, as simple as dropping a flag?
 Con: Not so simple as dropping a flag, needs a new flag to ensure that
  we still do lpss_deassert_reset() on device activation.
5. Make the pwm-lpss code fixup the LPSS-context registers
 Pro: Keeps acpi_lpss.c code clean
 Con: Moves knowledge of LPSS-context into the pwm-lpss.c code

1 and 5 both do not seem to be a desirable way forward.

3 and 4 seem ok, but they both assume that restoring the LPSS-context
registers is not necessary. I have done a couple of test and those do
show that restoring the LPSS-context indeed does not seem to be necessary
on devices using s2idle suspend (and successfully reaching S0i3). But I
have no hardware to test deep / S3 suspend. So I'm not sure that not
restoring the context is safe.

That leaves solution 2, which is about as simple / clean as 3 and 4,
so this commit fixes the described problem by implementing a new
LPSS_SAVE_CTX_ONCE flag and setting that for the CHT PWM controllers.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
Changes in v2:
- Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX
---
 drivers/acpi/acpi_lpss.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 67892fc0b822..a8d7d83ac761 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -67,7 +67,15 @@ ACPI_MODULE_NAME("acpi_lpss");
 #define LPSS_CLK_DIVIDER   BIT(2)
 #define LPSS_LTR   BIT(3)
 #define LPSS_SAVE_CTX  BIT(4)
-#define LPSS_NO_D3_DELAY   BIT(5)
+/*
+ * For some devices the DSDT AML code for another device turns off the device
+ * before our s

[Intel-gfx] [PATCH v7 05/16] pwm: lpss: Add pwm_lpss_prepare_enable() helper

2020-08-25 Thread Hans de Goede
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.

This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the not-enabled -> enabled transition there, so that we can error check
the entire transition in a single place and only have one pm_runtime_put()
on failure call site.

While working on this I noticed that the enabled -> enabled (update
settings) path was quite similar, so I've added an enable parameter to
the new pwm_lpss_prepare_enable() helper, which allows using it in that
path too.

Suggested-by: Andy Shevchenko 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
 drivers/pwm/pwm-lpss.c | 45 --
 1 file changed, 26 insertions(+), 19 deletions(-)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index da9bc3d10104..8a136ba2a583 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -122,41 +122,48 @@ static inline void pwm_lpss_cond_enable(struct pwm_device 
*pwm, bool cond)
pwm_lpss_write(pwm, pwm_lpss_read(pwm) | PWM_ENABLE);
 }
 
+static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm,
+  struct pwm_device *pwm,
+  const struct pwm_state *state,
+  bool enable)
+{
+   int ret;
+
+   ret = pwm_lpss_is_updating(pwm);
+   if (ret)
+   return ret;
+
+   pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, state->period);
+   pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);
+   ret = pwm_lpss_wait_for_update(pwm);
+   if (ret)
+   return ret;
+
+   pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == true);
+   return 0;
+}
+
 static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
  const struct pwm_state *state)
 {
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
-   int ret;
+   int ret = 0;
 
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
pm_runtime_get_sync(chip->dev);
-   ret = pwm_lpss_is_updating(pwm);
-   if (ret) {
-   pm_runtime_put(chip->dev);
-   return ret;
-   }
-   pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, 
state->period);
-   pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
-   ret = pwm_lpss_wait_for_update(pwm);
-   if (ret) {
+   ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
+   if (ret)
pm_runtime_put(chip->dev);
-   return ret;
-   }
-   pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
} else {
-   ret = pwm_lpss_is_updating(pwm);
-   if (ret)
-   return ret;
-   pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, 
state->period);
-   return pwm_lpss_wait_for_update(pwm);
+   ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
pm_runtime_put(chip->dev);
}
 
-   return 0;
+   return ret;
 }
 
 static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 04/16] pwm: lpss: Add range limit check for the base_unit register value

2020-08-25 Thread Hans de Goede
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.

But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency. Adding 0
to the counter is a no-op. The data-sheet even explicitly states that
writing 0 to the base_unit bits will result in the PWM outputting a
continuous 0 signal.

When the user requestes a low enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value
which is bigger then base_unit_range - 1. Currently the codes for this
deals with this by applying a mask:

base_unit &= (base_unit_range - 1);

But this means that we let the value overflow the range, we throw away the
higher bits and store whatever value is left in the lower bits into the
register leading to a random output frequency, rather then clamping the
output frequency to the highest frequency which the hardware can do.

This commit fixes both issues by clamping the base_unit value to be
between 1 and (base_unit_range - 1).

Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v5:
- Use clamp_val(... instead of clam_t(unsigned long long, ...

Changes in v3:
- Change upper limit of clamp to (base_unit_range - 1)
- Add Fixes tag
---
 drivers/pwm/pwm-lpss.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 43b1fc634af1..da9bc3d10104 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -97,6 +97,8 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
freq *= base_unit_range;
 
base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);
+   /* base_unit must not be 0 and we also want to avoid overflowing it */
+   base_unit = clamp_val(base_unit, 1, base_unit_range - 1);
 
on_time_div = 255ULL * duty_ns;
do_div(on_time_div, period_ns);
@@ -105,7 +107,6 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
orig_ctrl = ctrl = pwm_lpss_read(pwm);
ctrl &= ~PWM_ON_TIME_DIV_MASK;
ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
-   base_unit &= (base_unit_range - 1);
ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
ctrl |= on_time_div;
 
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 07/16] pwm: crc: Fix period / duty_cycle times being off by a factor of 256

2020-08-25 Thread Hans de Goede
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 duty-cycle steps.

The pwm-crc code before this commit assumed that a clock-divider
setting of 1 means that the PWM output is running at 6 MHZ, if that
is true, where do these 256 duty-cycle steps come from?

This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that
seems unlikely for a PMIC which is using a silicon process optimized for
power-switching transistors. It is way more likely that there is an 8
bit counter for the duty cycle which acts as an extra fixed divider
wrt the PWM output frequency.

The main user of the pwm-crc driver is the i915 GPU driver which uses it
for backlight control. Lets compare the PWM register values set by the
video-BIOS (the GOP), assuming the extra fixed divider is present versus
the PWM frequency specified in the Video-BIOS-Tables:

Device: PWM Hz set by BIOS  PWM Hz specified in VBT
Asus T100TA 200 200
Asus T100HA 200 200
Lenovo Miix 2 8 23437   2
Toshiba WT8-A   23437   2

So as we can see if we assume the extra division by 256 then the register
values set by the GOP are an exact match for the VBT values, where as
otherwise the values would be of by a factor of 256.

This commit fixes the period / duty_cycle calculations to take the
extra division by 256 into account.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v3:
- Use NSEC_PER_USEC instead of adding a new (non-sensical) NSEC_PER_MHZ define
---
 drivers/pwm/pwm-crc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 272eeb071147..c056eb9b858c 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -21,8 +21,8 @@
 
 #define PWM_MAX_LEVEL  0xFF
 
-#define PWM_BASE_CLK   600  /* 6 MHz */
-#define PWM_MAX_PERIOD_NS  21333/* 46.875KHz */
+#define PWM_BASE_CLK_MHZ   6   /* 6 MHz */
+#define PWM_MAX_PERIOD_NS  5461333 /* 183 Hz */
 
 /**
  * struct crystalcove_pwm - Crystal Cove PWM controller
@@ -72,7 +72,7 @@ static int crc_pwm_config(struct pwm_chip *c, struct 
pwm_device *pwm,
 
/* changing the clk divisor, need to disable fisrt */
crc_pwm_disable(c, pwm);
-   clk_div = PWM_BASE_CLK * period_ns / NSEC_PER_SEC;
+   clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
 
regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
clk_div | PWM_OUTPUT_ENABLE);
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 01/16] ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase

2020-08-25 Thread Hans de Goede
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:

Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
RSTA = Zero
RSTF = Zero
RSTA = One
RSTF = One
PWMB |= 0xC000
PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
}

Where PSAT is the power-status register of the PWM controller, so if it
is in D3 when the GFX0 device's PS0 method runs then it will turn it on
and restore the PWM ctrl register value it saved from its PS3 handler.
Note not only does it restore it, it ors it with 0xC000 turning it
on at a time where we may not want it to get turned on at all.

The pwm_get call which the i915 driver does to get a reference to the
PWM controller, already adds a device-link making the GFX0 device a
consumer of the PWM device. So it should already have been resumed when
the above AML runs and the AML should thus not do its undesirable poking
of the PWM controller register.

But the PCI core powers on PCI devices in the no-irq resume phase and
thus calls the troublesome PS0 method in the no-irq resume phase.
Where as LPSS devices by default are resumed in the early resume phase.

This commit sets the resume_from_noirq flag in the bsw_pwm_dev_desc
struct, so that Cherry Trail PWM controllers will be resumed in the
no-irq phase. Together with the device-link added by the pwm-get this
ensures that the PWM controller will be on when the troublesome PS0
method runs, which stops it from poking the PWM controller.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/acpi_lpss.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 5e2bfbcf526f..67892fc0b822 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -257,6 +257,7 @@ static const struct lpss_device_desc bsw_pwm_dev_desc = {
.flags = LPSS_SAVE_CTX | LPSS_NO_D3_DELAY,
.prv_offset = 0x800,
.setup = bsw_pwm_setup,
+   .resume_from_noirq = true,
 };
 
 static const struct lpss_device_desc byt_uart_dev_desc = {
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 00/16] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

2020-08-25 Thread Hans de Goede
Hi All,

I missed on 64-bit divide caused by pwm_state.period and pwm_state.duty_cycle 
being changed
to u64-s in 5.9. This new version fixes this, otherwise this is identical to v6:

Here is v6 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below for the changelog.

This version of the series has been rebased on 5.9-rc1 and has
a Reviewed-by or Acked-by for all patches.

The main purpose of sending this new version out is to allow the
intel-gfx CI to play with it.

As discussed before, because of interdependencies of the patches
I plan to push the entire series to drm-intel-next-queued once it
has passed CI.

Thierry, I believe from our previous discussion that you are ok with
pushing the pwm-crc and pwm-lpss patches through the drm-intel tree,
but you have not given your Acked-by for this. If you are not ok with
me pushing these out this way please let me now ASAP. If you are ok
with this an Acked-by would be appreciated.

This series has been tested (and re-tested after adding various bug-fixes)
extensively. It has been tested on the following devices:

-Asus T100TA  BYT + CRC-PMIC PWM
-Toshiba WT8-A  BYT + CRC-PMIC PWM
-Thundersoft TS178 BYT + CRC-PMIC PWM, inverse PWM
-Asus T100HA  CHT + CRC-PMIC PWM
-Terra Pad 1061  BYT + LPSS PWM
-Trekstor Twin 10.1 BYT + LPSS PWM
-Asus T101HA  CHT + CRC-PMIC PWM
-GPD Pocket  CHT + CRC-PMIC PWM

Regards,

Hans


Changelog:

Changes in v7:
- Fix a u64 divide leading to undefined reference to `__udivdi3' errors on 32 
bit
  platforms by casting the divisor to an unsigned long

Changes in v6:
- Rebase on v5.9-rc1
- Adjust pwm-crc patches for pwm_state.period and .duty_cycle now being u64

Changes in v5:
- Dropped the "pwm: lpss: Correct get_state result for base_unit == 0"
  patch. The base_unit == 0 condition should never happen and sofar it is
  unclear what the proper behavior / correct values to store in the
  pwm_state should be when this does happen.  Since this patch was added as
  an extra pwm-lpss fix in v4 of this patch-set and otherwise is orthogonal
  to the of this patch-set just drop it (again).
- "[PATCH 04/16] pwm: lpss: Add range limit check for the base_unit register 
value"
  - Use clamp_val(... instead of clam_t(unsigned long long, ...
- "[PATCH 05/16] pwm: lpss: Add pwm_lpss_prepare_enable() helper"
  - This is a new patch in v5 of this patchset
- [PATCH 06/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume
  - Use the new pwm_lpss_prepare_enable() helper

Changes in v4:
- "[PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0"
  - This is a new patch in v4 of this patchset
- "[PATCH v4 12/16] pwm: crc: Implement get_state() method"
  - Use DIV_ROUND_UP when calculating the period and duty_cycle values
- "[PATCH v4 16/16] drm/i915: panel: Use atomic PWM API for devs with an 
external PWM controller"
  - Add a note to the commit message about the changes in 
pwm_disable_backlight()
  - Use the pwm_set/get_relative_duty_cycle() helpers

Changes in v3:
- "[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register 
value"
  - Use base_unit_range - 1 as maximum value for the clamp()
- "[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state on 
resume"
  - This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM"
patch from previous versions of this patch-set, which really was a hack
working around the resume issue which this patch fixes properly.
- PATCH v3 6 - 11 pwm-crc changes:
  - Various small changes resulting from the reviews by Andy and Uwe,
including some refactoring of the patches to reduce the amount of churn
in the patch-set

Changes in v2:
- Fix coverletter subject
- Drop accidentally included debugging patch
- "[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (
  - Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 06/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume

2020-08-25 Thread Hans de Goede
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.

This problem has been masked so far because the main consumer
(the i915 driver) was always making duty-cycle changes on resume.
With the conversion of the i915 driver to the atomic PWM API the
driver now only disables/enables the PWM on suspend/resume leaving
the output-freq and duty as is, triggering this problem.

The LPSS PWM controller has a mechanism where the ctrl register value
and the actual base-unit and on-time-div values used are latched. When
software sets the SW_UPDATE bit then at the end of the current PWM cycle,
the new values from the ctrl-register will be latched into the actual
registers, and the SW_UPDATE bit will be cleared.

The problem is that before this commit our suspend/resume handling
consisted of simply saving the PWM ctrl register on suspend and
restoring it on resume, without setting the PWM_SW_UPDATE bit.
When the controller has lost its state over a suspend/resume and thus
has been reset to the defaults, just restoring the register is not
enough. We must also set the SW_UPDATE bit to tell the controller to
latch the restored values into the actual registers.

Fixing this problem is not as simple as just or-ing in the value which
is being restored with SW_UPDATE. If the PWM was enabled before we must
write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE.
We must also wait for PWM_SW_UPDATE to become 0 again and depending on the
model we must do this either before or after the setting of PWM_ENABLE.

All the necessary logic for doing this is already present inside
pwm_lpss_apply(), so instead of duplicating this inside the resume
handler, this commit makes the resume handler use pwm_lpss_apply() to
restore the settings when necessary. This fixes the output-freq and
duty-cycle being reset to their defaults on resume.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v6:
- Add a pwm_lpss_restore_state() helper for re-applying the PWM state on resume

Changes in v5:
- The changes to pwm_lpss_apply() are much cleaner now thanks to the new
  pwm_lpss_prepare_enable() helper.

Changes in v3:
- This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM"
  patch from previous versions of this patch-set, which really was a hack
  working around the resume issue which this patch fixes properly.
---
 drivers/pwm/pwm-lpss.c | 49 +++---
 1 file changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 8a136ba2a583..d77869be053c 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -166,6 +166,24 @@ static int pwm_lpss_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
return ret;
 }
 
+/*
+ * This is a mirror of pwm_lpss_apply() without pm_runtime reference handling
+ * for restoring the PWM state on resume.
+ */
+static int pwm_lpss_restore_state(struct pwm_lpss_chip *lpwm,
+ struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+   int ret = 0;
+
+   if (state->enabled)
+   ret = pwm_lpss_prepare_enable(lpwm, pwm, state, 
!pwm_is_enabled(pwm));
+   else if (pwm_is_enabled(pwm))
+   pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
+
+   return ret;
+}
+
 static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
   struct pwm_state *state)
 {
@@ -278,10 +296,35 @@ EXPORT_SYMBOL_GPL(pwm_lpss_suspend);
 int pwm_lpss_resume(struct device *dev)
 {
struct pwm_lpss_chip *lpwm = dev_get_drvdata(dev);
-   int i;
+   struct pwm_state saved_state;
+   struct pwm_device *pwm;
+   int i, ret;
+   u32 ctrl;
 
-   for (i = 0; i < lpwm->info->npwm; i++)
-   writel(lpwm->saved_ctrl[i], lpwm->regs + i * PWM_SIZE + PWM);
+   for (i = 0; i < lpwm->info->npwm; i++) {
+   pwm = &lpwm->chip.pwms[i];
+
+   ctrl = pwm_lpss_read(pwm);
+   /* If we did not reach S0i3/S3 the controller keeps its state */
+   if (ctrl == lpwm->saved_ctrl[i])
+   continue;
+
+   /*
+* We cannot just blindly restore the old value here. Since we
+* are changing the settings we must set SW_UPDATE and if the
+* PWM was enabled before we must write the new settings +
+* PWM_SW_UPDATE before setting PWM_ENABLE. We must also wait
+* for PWM_SW_UPDATE to become 0 again and depending on the
+* model we must do this either before or after the setting of
+* PWM_ENABLE.
+*/
+   saved_state = pwm->state;
+   /* Update e

[Intel-gfx] [PATCH v7 03/16] pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()

2020-08-25 Thread Hans de Goede
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.

So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input clock-cycles the counter has been increased from 0 to
65535 and it will overflow on the next cycle, so it will overflow after
every 65536 clock cycles and thus the calculations done in
pwm_lpss_prepare() should use 65536 and not 65535.

This commit fixes this. Note this also aligns the calculations in
pwm_lpss_prepare() with those in pwm_lpss_get_state().

Note this effectively reverts commit 684309e5043e ("pwm: lpss: Avoid
potential overflow of base_unit"). The next patch in this series really
fixes the potential overflow of the base_unit value.

Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko 
Acked-by: Uwe Kleine-König 
Signed-off-by: Hans de Goede 
---
Changes in v3:
- Add Fixes tag
- Add Reviewed-by: Andy Shevchenko tag
---
 drivers/pwm/pwm-lpss.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 9d965ffe66d1..43b1fc634af1 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -93,7 +93,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
 * The equation is:
 * base_unit = round(base_unit_range * freq / c)
 */
-   base_unit_range = BIT(lpwm->info->base_unit_bits) - 1;
+   base_unit_range = BIT(lpwm->info->base_unit_bits);
freq *= base_unit_range;
 
base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);
@@ -104,8 +104,8 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
 
orig_ctrl = ctrl = pwm_lpss_read(pwm);
ctrl &= ~PWM_ON_TIME_DIV_MASK;
-   ctrl &= ~(base_unit_range << PWM_BASE_UNIT_SHIFT);
-   base_unit &= base_unit_range;
+   ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
+   base_unit &= (base_unit_range - 1);
ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
ctrl |= on_time_div;
 
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 09/16] pwm: crc: Fix period changes not having any effect

2020-08-25 Thread Hans de Goede
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

The BACKLIGHT_EN register at address 0x51 really controls a separate
output-only GPIO which is earmarked to be used as output connected to the
backlight-enable pin for LCD panels, this GPO is part of the PMIC's
"Display Panel Control Block." . This pin should probably be moved over
to a GPIO provider driver (and consumers modified accordingly), but that
is something for an(other) patch.

Enabling / disabling the actual PWM output is controlled by the
PWM_OUTPUT_ENABLE bit of the PWM0_CLK_DIV register.

As the comment in the old code already indicates we must disable the PWM
before we can change the clock divider. But the crc_pwm_disable() and
crc_pwm_enable() calls the old code make for this only change the
BACKLIGHT_EN register; and the value of that register does not matter for
changing the period / the divider. What does matter is that the
PWM_OUTPUT_ENABLE bit must be cleared before a new value can be written.

This commit modifies crc_pwm_config() to clear PWM_OUTPUT_ENABLE instead
when changing the period, so that period changes actually work.

Note this fix will cause a significant behavior change on some devices
using the CRC PWM output to drive their backlight. Before the PWM would
always run with the output frequency configured by the BIOS at boot, now
the period time specified by the i915 driver will actually be honored.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
 drivers/pwm/pwm-crc.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 44ec7d5b63e1..81232da0c767 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -82,14 +82,11 @@ static int crc_pwm_config(struct pwm_chip *c, struct 
pwm_device *pwm,
if (pwm_get_period(pwm) != period_ns) {
int clk_div = crc_pwm_calc_clk_div(period_ns);
 
-   /* changing the clk divisor, need to disable fisrt */
-   crc_pwm_disable(c, pwm);
+   /* changing the clk divisor, clear PWM_OUTPUT_ENABLE first */
+   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, 0);
 
regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
clk_div | PWM_OUTPUT_ENABLE);
-
-   /* enable back */
-   crc_pwm_enable(c, pwm);
}
 
/* change the pwm duty cycle */
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 08/16] pwm: crc: Fix off-by-one error in the clock-divider calculations

2020-08-25 Thread Hans de Goede
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.

So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested frequency was so high that the
calculation has already resulted in a (rounded) divider value of 0.

Note that before this fix, setting a period of PWM_MAX_PERIOD_NS which
corresponds to the max. divider value of 128 could have resulted in a
bug where the code would use 128 as divider-register value which would
have resulted in an actual divider value of 0 (and the enable bit being
set). A rounding error stopped this bug from actually happen. This
same rounding error means that after the subtraction of 1 it is impossible
to set the divider to 128. Also bump PWM_MAX_PERIOD_NS by 1 ns to allow
setting a divider of 128 (register-value 127).

Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v3:
- Introduce crc_pwm_calc_clk_div() here instead of later in the patch-set
  to reduce the amount of churn in the patch-set a bit
---
 drivers/pwm/pwm-crc.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index c056eb9b858c..44ec7d5b63e1 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -22,7 +22,7 @@
 #define PWM_MAX_LEVEL  0xFF
 
 #define PWM_BASE_CLK_MHZ   6   /* 6 MHz */
-#define PWM_MAX_PERIOD_NS  5461333 /* 183 Hz */
+#define PWM_MAX_PERIOD_NS  5461334 /* 183 Hz */
 
 /**
  * struct crystalcove_pwm - Crystal Cove PWM controller
@@ -39,6 +39,18 @@ static inline struct crystalcove_pwm *to_crc_pwm(struct 
pwm_chip *pc)
return container_of(pc, struct crystalcove_pwm, chip);
 }
 
+static int crc_pwm_calc_clk_div(int period_ns)
+{
+   int clk_div;
+
+   clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
+   /* clk_div 1 - 128, maps to register values 0-127 */
+   if (clk_div > 0)
+   clk_div--;
+
+   return clk_div;
+}
+
 static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
 {
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
@@ -68,11 +80,10 @@ static int crc_pwm_config(struct pwm_chip *c, struct 
pwm_device *pwm,
}
 
if (pwm_get_period(pwm) != period_ns) {
-   int clk_div;
+   int clk_div = crc_pwm_calc_clk_div(period_ns);
 
/* changing the clk divisor, need to disable fisrt */
crc_pwm_disable(c, pwm);
-   clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
 
regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
clk_div | PWM_OUTPUT_ENABLE);
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 14/16] drm/i915: panel: Honor the VBT PWM frequency for devs with an external PWM controller

2020-08-25 Thread Hans de Goede
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.

I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which greatly exceeds
the PWM_MAX_PERIOD_NS define in the Crystal Cove PMIC PWM driver, which
used to be 21333.

This PWM_MAX_PERIOD_NS define was actually based on a bug in the PWM
driver where its period and duty-cycle times where off by a factor of 256.

Due to this bug the hardcoded CRC_PMIC_PWM_PERIOD_NS value of 21333 would
result in the PWM driver using its divider of 128, which would result in
a PWM output frequency of 600 Hz / 256 / 128 = 183 Hz. So actually
pretty close to the default VBT value of 200 Hz.

Now that this bug in the pwm-crc driver is fixed, we can actually use
the VBT defined frequency.

This is important because:

a) With the pwm-crc driver fixed it will now translate the hardcoded
CRC_PMIC_PWM_PERIOD_NS value of 21333 ns / 46 Khz to a PWM output
frequency of 23 KHz (the max it can do).

b) The pwm-lpss driver used on many models has always honored the
21333 ns / 46 Khz request

Some panels do not like such high output frequencies. E.g. on a Terra
Pad 1061 tablet, using the LPSS PWM controller, the backlight would go
from off to max, when changing the sysfs backlight brightness value from
90-100%, anything under aprox. 90% would turn the backlight fully off.

Honoring the VBT specified PWM frequency will also hopefully fix the
various bug reports which we have received about users perceiving the
backlight to flicker after a suspend/resume cycle.

Acked-by: Jani Nikula 
Signed-off-by: Hans de Goede 
---
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_panel.c| 19 +++
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index e8f809161c75..7171e7c8d928 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -223,6 +223,7 @@ struct intel_panel {
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
+   int pwm_period_ns;
 
/* DPCD backlight */
u8 pwmgen_bit_count;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index ec6b9d704542..7fb162fac8a1 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -40,8 +40,6 @@
 #include "intel_dsi_dcs_backlight.h"
 #include "intel_panel.h"
 
-#define CRC_PMIC_PWM_PERIOD_NS 21333
-
 void
 intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
   struct drm_display_mode *adjusted_mode)
@@ -597,7 +595,7 @@ static u32 pwm_get_backlight(struct intel_connector 
*connector)
int duty_ns;
 
duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
-   return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
+   return DIV_ROUND_UP(duty_ns * 100, panel->backlight.pwm_period_ns);
 }
 
 static void lpt_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
@@ -671,9 +669,10 @@ static void bxt_set_backlight(const struct 
drm_connector_state *conn_state, u32
 static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
 {
struct intel_panel *panel = 
&to_intel_connector(conn_state->connector)->panel;
-   int duty_ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+   int duty_ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
 
-   pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
+   pwm_config(panel->backlight.pwm, duty_ns,
+  panel->backlight.pwm_period_ns);
 }
 
 static void
@@ -1917,6 +1916,9 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
return -ENODEV;
}
 
+   panel->backlight.pwm_period_ns = NSEC_PER_SEC /
+get_vbt_pwm_freq(dev_priv);
+
/*
 * FIXME: pwm_apply_args() should be removed when switching to
 * the atomic PWM API.
@@ -1926,9 +1928,10 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
panel->backlight.min = 0; /* 0% */
panel->backlight.max = 100; /* 100% */
level = intel_panel_compute_brightness(connector, 100);
-   ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+   ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
 
-   retval = pwm_config(panel->backlight.pwm, ns, CRC_PMIC_PWM_PERIOD_NS);
+   retval = pwm_config(panel->backlight.pwm, ns,
+   panel->backlight.pwm_period_ns);
i

[Intel-gfx] [PATCH v7 15/16] drm/i915: panel: Honor the VBT PWM min setting for devs with an external PWM controller

2020-08-25 Thread Hans de Goede
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.

Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the minimum level.

Acked-by: Jani Nikula 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 7fb162fac8a1..6d27630dd1e4 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1925,8 +1925,8 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
 */
pwm_apply_args(panel->backlight.pwm);
 
-   panel->backlight.min = 0; /* 0% */
panel->backlight.max = 100; /* 100% */
+   panel->backlight.min = get_backlight_min_vbt(connector);
level = intel_panel_compute_brightness(connector, 100);
ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
 
@@ -1941,8 +1941,9 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
 
level = DIV_ROUND_UP_ULL(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
 panel->backlight.pwm_period_ns);
-   panel->backlight.level =
-   intel_panel_compute_brightness(connector, level);
+   level = intel_panel_compute_brightness(connector, level);
+   panel->backlight.level = clamp(level, panel->backlight.min,
+  panel->backlight.max);
panel->backlight.enabled = panel->backlight.level != 0;
 
drm_info(&dev_priv->drm, "Using %s PWM for LCD backlight control\n",
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 10/16] pwm: crc: Enable/disable PWM output on enable/disable

2020-08-25 Thread Hans de Goede
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 makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set it again on re-enable.

Acked-by: Uwe Kleine-König 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v3:
- Remove paragraph about tri-stating the output from the commit message,
  we don't have a datasheet so this was just an unfounded guess
---
 drivers/pwm/pwm-crc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 81232da0c767..b72008c9b072 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -54,7 +54,9 @@ static int crc_pwm_calc_clk_div(int period_ns)
 static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
 {
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+   int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
 
+   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div | PWM_OUTPUT_ENABLE);
regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
 
return 0;
@@ -63,8 +65,10 @@ static int crc_pwm_enable(struct pwm_chip *c, struct 
pwm_device *pwm)
 static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
 {
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+   int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
 
regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
+   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div);
 }
 
 static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 12/16] pwm: crc: Implement get_state() method

2020-08-25 Thread Hans de Goede
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v6:
- Rebase on 5.9-rc1
- Use DIV_ROUND_UP_ULL because pwm_state.period and .duty_cycle are now u64

Changes in v5:
- Fix an indentation issue

Changes in v4:
- Use DIV_ROUND_UP when calculating the period and duty_cycle from the
  controller's register values

Changes in v3:
- Add Andy's Reviewed-by tag
- Remove extra whitespace to align some code after assignments (requested by
  Uwe Kleine-König)
---
 drivers/pwm/pwm-crc.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 27dc30882424..ecfdfac0c2d9 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -121,8 +121,39 @@ static int crc_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
return 0;
 }
 
+static void crc_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(chip);
+   struct device *dev = crc_pwm->chip.dev;
+   unsigned int clk_div, clk_div_reg, duty_cycle_reg;
+   int error;
+
+   error = regmap_read(crc_pwm->regmap, PWM0_CLK_DIV, &clk_div_reg);
+   if (error) {
+   dev_err(dev, "Error reading PWM0_CLK_DIV %d\n", error);
+   return;
+   }
+
+   error = regmap_read(crc_pwm->regmap, PWM0_DUTY_CYCLE, &duty_cycle_reg);
+   if (error) {
+   dev_err(dev, "Error reading PWM0_DUTY_CYCLE %d\n", error);
+   return;
+   }
+
+   clk_div = (clk_div_reg & ~PWM_OUTPUT_ENABLE) + 1;
+
+   state->period =
+   DIV_ROUND_UP(clk_div * NSEC_PER_USEC * 256, PWM_BASE_CLK_MHZ);
+   state->duty_cycle =
+   DIV_ROUND_UP_ULL(duty_cycle_reg * state->period, PWM_MAX_LEVEL);
+   state->polarity = PWM_POLARITY_NORMAL;
+   state->enabled = !!(clk_div_reg & PWM_OUTPUT_ENABLE);
+}
+
 static const struct pwm_ops crc_pwm_ops = {
.apply = crc_pwm_apply,
+   .get_state = crc_pwm_get_state,
 };
 
 static int crystalcove_pwm_probe(struct platform_device *pdev)
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 11/16] pwm: crc: Implement apply() method to support the new atomic PWM API

2020-08-25 Thread Hans de Goede
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v6:
- Rebase on 5.9-rc1
- Use do_div when calculating level because pwm_state.period and .duty_cycle 
are now u64

Changes in v3:
- Keep crc_pwm_calc_clk_div() helper to avoid needless churn
---
 drivers/pwm/pwm-crc.c | 89 ++-
 1 file changed, 54 insertions(+), 35 deletions(-)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index b72008c9b072..27dc30882424 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -51,59 +51,78 @@ static int crc_pwm_calc_clk_div(int period_ns)
return clk_div;
 }
 
-static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
+static int crc_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+const struct pwm_state *state)
 {
-   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
-   int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(chip);
+   struct device *dev = crc_pwm->chip.dev;
+   int err;
 
-   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div | PWM_OUTPUT_ENABLE);
-   regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
+   if (state->period > PWM_MAX_PERIOD_NS) {
+   dev_err(dev, "un-supported period_ns\n");
+   return -EINVAL;
+   }
 
-   return 0;
-}
+   if (state->polarity != PWM_POLARITY_NORMAL)
+   return -EOPNOTSUPP;
 
-static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
-{
-   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
-   int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
+   if (pwm_is_enabled(pwm) && !state->enabled) {
+   err = regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
+   if (err) {
+   dev_err(dev, "Error writing BACKLIGHT_EN %d\n", err);
+   return err;
+   }
+   }
 
-   regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
-   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div);
-}
+   if (pwm_get_duty_cycle(pwm) != state->duty_cycle ||
+   pwm_get_period(pwm) != state->period) {
+   u64 level = state->duty_cycle * PWM_MAX_LEVEL;
 
-static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
- int duty_ns, int period_ns)
-{
-   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
-   struct device *dev = crc_pwm->chip.dev;
-   int level;
+   do_div(level, state->period);
 
-   if (period_ns > PWM_MAX_PERIOD_NS) {
-   dev_err(dev, "un-supported period_ns\n");
-   return -EINVAL;
+   err = regmap_write(crc_pwm->regmap, PWM0_DUTY_CYCLE, level);
+   if (err) {
+   dev_err(dev, "Error writing PWM0_DUTY_CYCLE %d\n", err);
+   return err;
+   }
}
 
-   if (pwm_get_period(pwm) != period_ns) {
-   int clk_div = crc_pwm_calc_clk_div(period_ns);
-
+   if (pwm_is_enabled(pwm) && state->enabled &&
+   pwm_get_period(pwm) != state->period) {
/* changing the clk divisor, clear PWM_OUTPUT_ENABLE first */
-   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, 0);
+   err = regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, 0);
+   if (err) {
+   dev_err(dev, "Error writing PWM0_CLK_DIV %d\n", err);
+   return err;
+   }
+   }
 
-   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
-   clk_div | PWM_OUTPUT_ENABLE);
+   if (pwm_get_period(pwm) != state->period ||
+   pwm_is_enabled(pwm) != state->enabled) {
+   int clk_div = crc_pwm_calc_clk_div(state->period);
+   int pwm_output_enable = state->enabled ? PWM_OUTPUT_ENABLE : 0;
+
+   err = regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
+  clk_div | pwm_output_enable);
+   if (err) {
+   dev_err(dev, "Error writing PWM0_CLK_DIV %d\n", err);
+   return err;
+   }
}
 
-   /* change the pwm duty cycle */
-   level = duty_ns * PWM_MAX_LEVEL / period_ns;
-   regmap_write(crc_pwm->regmap, PWM0_DUTY_CYCLE, level);
+   if (!pwm_is_enabled(pwm) && state->enabled) {
+   err = regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
+   if (err) {
+   dev_err(dev, "Error writing BACKLIGHT_EN %d\n", err);
+   return err;
+   }
+   }
 
return 0;
 }
 
 static const struct pwm_ops crc_pwm_ops = {
-   .config = crc_pwm_config,
-   .enable = crc_pwm_enable,
-   .disable = crc_pwm_disable,
+   .apply = crc_pwm_apply

[Intel-gfx] [PATCH v7 16/16] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller

2020-08-25 Thread Hans de Goede
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.

The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastset path.

Note that this commit also simplifies pwm_disable_backlight(), by dropping
the intel_panel_actually_set_backlight(..., 0) call. This call sets the
PWM to 0% duty-cycle. I believe that this call was only present as a
workaround for a bug in the pwm-crc.c driver where it failed to clear the
PWM_OUTPUT_ENABLE bit. This is fixed by an earlier patch in this series.

After the dropping of this workaround, the usleep call, which seems
unnecessary to begin with, has no useful effect anymore, so drop that too.

Acked-by: Jani Nikula 
Signed-off-by: Hans de Goede 
---
Changes in v7:
- Fix a u64 divide leading to undefined reference to `__udivdi3' errors on 32 
bit
  platforms by casting the divisor to an unsigned long

Changes in v6:
- Drop the pwm_get_period() check in pwm_setup(), it is now longer needed
  now that we use pwm_get_relative_duty_cycle()

Changes in v4:
- Add a note to the commit message about the dropping of the
  intel_panel_actually_set_backlight() and usleep() calls from
  pwm_disable_backlight()
- Use the pwm_set/get_relative_duty_cycle() helpers instead of using DIY code
  for this
---
 .../drm/i915/display/intel_display_types.h|  3 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 70 ---
 2 files changed, 33 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 7171e7c8d928..e3ebe7c313ba 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -223,7 +224,7 @@ struct intel_panel {
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
-   int pwm_period_ns;
+   struct pwm_state pwm_state;
 
/* DPCD backlight */
u8 pwmgen_bit_count;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 6d27630dd1e4..5a201fe8de11 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -592,10 +592,10 @@ static u32 bxt_get_backlight(struct intel_connector 
*connector)
 static u32 pwm_get_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = &connector->panel;
-   int duty_ns;
+   struct pwm_state state;
 
-   duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
-   return DIV_ROUND_UP(duty_ns * 100, panel->backlight.pwm_period_ns);
+   pwm_get_state(panel->backlight.pwm, &state);
+   return pwm_get_relative_duty_cycle(&state, 100);
 }
 
 static void lpt_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
@@ -669,10 +669,9 @@ static void bxt_set_backlight(const struct 
drm_connector_state *conn_state, u32
 static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
 {
struct intel_panel *panel = 
&to_intel_connector(conn_state->connector)->panel;
-   int duty_ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
 
-   pwm_config(panel->backlight.pwm, duty_ns,
-  panel->backlight.pwm_period_ns);
+   pwm_set_relative_duty_cycle(&panel->backlight.pwm_state, level, 100);
+   pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 static void
@@ -841,10 +840,8 @@ static void pwm_disable_backlight(const struct 
drm_connector_state *old_conn_sta
struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
struct intel_panel *panel = &connector->panel;
 
-   /* Disable the backlight */
-   intel_panel_actually_set_backlight(old_conn_state, 0);
-   usleep_range(2000, 3000);
-   pwm_disable(panel->backlight.pwm);
+   panel->backlight.pwm_state.enabled = false;
+   pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 void intel_panel_disable_backlight(const struct drm_connector_state 
*old_conn_state)
@@ -1176,9 +1173,12 @@ static void pwm_enable_backlight(const struct 
intel_crtc_state *crtc_state,
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_panel *panel = &connector->panel;
+   int level = panel->backlight.level;
 
-   pwm_enable(panel->backlight.pwm);
-   intel_panel_actually_set_backlight(conn_state, panel->backlight.level);
+   level = intel_panel_compute_brightness(connector, level);
+   pwm_set_relative_duty_cycle(&panel->backlight.pwm_state, level, 100);
+ 

[Intel-gfx] [PATCH v7 13/16] drm/i915: panel: Add get_vbt_pwm_freq() helper

2020-08-25 Thread Hans de Goede
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().

This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).

Acked-by: Jani Nikula 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 27 ++
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index bbde3b12c311..ec6b9d704542 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1543,18 +1543,9 @@ static u32 vlv_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)
return DIV_ROUND_CLOSEST(clock, pwm_freq_hz * mul);
 }
 
-static u32 get_backlight_max_vbt(struct intel_connector *connector)
+static u16 get_vbt_pwm_freq(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   struct intel_panel *panel = &connector->panel;
u16 pwm_freq_hz = dev_priv->vbt.backlight.pwm_freq_hz;
-   u32 pwm;
-
-   if (!panel->backlight.hz_to_pwm) {
-   drm_dbg_kms(&dev_priv->drm,
-   "backlight frequency conversion not supported\n");
-   return 0;
-   }
 
if (pwm_freq_hz) {
drm_dbg_kms(&dev_priv->drm,
@@ -1567,6 +1558,22 @@ static u32 get_backlight_max_vbt(struct intel_connector 
*connector)
pwm_freq_hz);
}
 
+   return pwm_freq_hz;
+}
+
+static u32 get_backlight_max_vbt(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = &connector->panel;
+   u16 pwm_freq_hz = get_vbt_pwm_freq(dev_priv);
+   u32 pwm;
+
+   if (!panel->backlight.hz_to_pwm) {
+   drm_dbg_kms(&dev_priv->drm,
+   "backlight frequency conversion not supported\n");
+   return 0;
+   }
+
pwm = panel->backlight.hz_to_pwm(connector, pwm_freq_hz);
if (!pwm) {
drm_dbg_kms(&dev_priv->drm,
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

2020-08-25 Thread Patchwork
== Series Details ==

Series: acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the 
atomic PWM API
URL   : https://patchwork.freedesktop.org/series/80976/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
ef85c003b00a ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase
1d26b9fe569e ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at 
activation)
5dd4db0dc219 pwm: lpss: Fix off by one error in base_unit math in 
pwm_lpss_prepare()
a4e4727f40e6 pwm: lpss: Add range limit check for the base_unit register value
0d3912600257 pwm: lpss: Add pwm_lpss_prepare_enable() helper
-:45: CHECK:BOOL_COMPARISON: Using comparison to false is error prone
#45: FILE: drivers/pwm/pwm-lpss.c:137:
+   pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);

-:50: CHECK:BOOL_COMPARISON: Using comparison to true is error prone
#50: FILE: drivers/pwm/pwm-lpss.c:142:
+   pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == true);

total: 0 errors, 0 warnings, 2 checks, 67 lines checked
9fb3d675a6b6 pwm: lpss: Use pwm_lpss_apply() when restoring state on resume
2dda19e1952a pwm: crc: Fix period / duty_cycle times being off by a factor of 
256
2061f911c93f pwm: crc: Fix off-by-one error in the clock-divider calculations
2e80db8eb3ff pwm: crc: Fix period changes not having any effect
04e01429ab69 pwm: crc: Enable/disable PWM output on enable/disable
f0758f16468b pwm: crc: Implement apply() method to support the new atomic PWM 
API
9a833ba135f1 pwm: crc: Implement get_state() method
ace83a7f4e48 drm/i915: panel: Add get_vbt_pwm_freq() helper
6c5200023ed2 drm/i915: panel: Honor the VBT PWM frequency for devs with an 
external PWM controller
5cba5633c584 drm/i915: panel: Honor the VBT PWM min setting for devs with an 
external PWM controller
871bbce513b9 drm/i915: panel: Use atomic PWM API for devs with an external PWM 
controller


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/fbc: Disable fbc with VT-d also with cometlake

2020-08-25 Thread Lee Shawn C
Both VT-d and FBC enabled that caused display flicker
issue very randomly. According to sighting report,
it recommend to disable FBC to workaround this issue.

Cc: Ville Syrjälä 
Cc: Rodrigo Vivi 
Cc: Mika Kuoppala 
Cc: Jani Nikula 
Cc: William Tseng 
Signed-off-by: Lee Shawn C 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 135f5e8a4d70..327af428d73f 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1443,7 +1443,8 @@ static bool need_fbc_vtd_wa(struct drm_i915_private 
*dev_priv)
 {
/* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */
if (intel_vtd_active() &&
-   (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))) {
+   (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv) ||
+IS_COMETLAKE(dev_priv))) {
drm_info(&dev_priv->drm,
 "Disabling framebuffer compression (FBC) to prevent 
screen flicker with VT-d enabled\n");
return true;
-- 
2.17.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

2020-08-25 Thread Patchwork
== Series Details ==

Series: acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the 
atomic PWM API
URL   : https://patchwork.freedesktop.org/series/80976/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18396


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18396 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18396, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_18396:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_parallel@engines@contexts:
- fi-kbl-x1275:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@gem_exec_parallel@engi...@contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/fi-kbl-x1275/igt@gem_exec_parallel@engi...@contexts.html

  
Known issues


  Here are the changes found in Patchwork_18396 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-bxt-dsi: [PASS][3] -> [TIMEOUT][4] ([i915#1418] / [i915#1635])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-bxt-dsi/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/fi-bxt-dsi/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@module-reload:
- fi-bxt-dsi: [PASS][5] -> [SKIP][6] ([fdo#109271] / [i915#1635])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-bxt-dsi/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/fi-bxt-dsi/igt@i915_pm_...@module-reload.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][15] ([i915#2203]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [INCOMPLETE][17] ([i915#1635] / [i915#337]) -> 
[PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [DMESG-FAIL][19] ([i915#62] / [i915#95]) -> 
[DMESG-FAIL][20] ([i915#62])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275:   [DMESG-WARN][21] ([i915#62] / [i915#92]) -> 
[DMESG-WAR

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

2020-08-25 Thread Hans de Goede

Hi,

On 8/25/20 12:44 PM, Patchwork wrote:

*Patch Details*
*Series:*   acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to 
use the atomic PWM API
*URL:*  https://patchwork.freedesktop.org/series/80976/
*State:*failure
*Details:*  
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/index.html


  CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18396


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_18396 absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18396, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18396/index.html


Possible new issues

Here are the unknown changes that may have been introduced in Patchwork_18396:


  IGT changes


Possible regressions

  * igt@gem_exec_parallel@engines@contexts:
  o fi-kbl-x1275: PASS 

 -> INCOMPLETE 



v6 of this patch-set did pass the BAT tests yesterday and nothing has really
changed other then a single cast to avoid a 64 bit divide which only does
anything on 32 bit archs. And that divide is a param to a drm_dbg statement.

So this seems to be a false-positive. I guess that this test sometimes
failing should be added to the known issues list ?

Anyways since v6 did pass and nothing has really changed I'm going to
ignore this test result.

Regards,

Hans








Known issues

Here are the changes found in Patchwork_18396 that come from known issues:


  IGT changes


Issues hit

  *

igt@i915_module_load@reload:

  o fi-bxt-dsi: PASS 
 
-> TIMEOUT 

 (i915#1418  / i915#1635 
)
  *

igt@i915_pm_rpm@module-reload:

  o fi-bxt-dsi: PASS 
 
-> SKIP 

 (fdo#109271  / i915#1635 
)
  *

igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:

  o fi-icl-u2: PASS 

 -> DMESG-WARN 

 (i915#1982 ) +1 similar issue


Possible fixes

  *

igt@i915_pm_rpm@basic-pci-d3-state:

  o fi-bsw-kefka: DMESG-WARN 

 (i915#1982 ) -> PASS 

  *

igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:

  o fi-byt-j1900: DMESG-WARN 

 (i915#1982 ) -> PASS 

 +1 similar issue
  *

igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:

  o fi-icl-u2: DMESG-WARN 

 (i915#1982 ) -> PASS 

  *

igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:

  o fi-skl-guc: DMESG-WARN 

 (i915#2203 ) -> PASS 

  *

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:

  o fi-apl-guc: INCOMPLETE 


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbc: Disable fbc with VT-d also with cometlake

2020-08-25 Thread Patchwork
== Series Details ==

Series: drm/i915/fbc: Disable fbc with VT-d also with cometlake
URL   : https://patchwork.freedesktop.org/series/80977/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18397


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/index.html

Known issues


  Here are the changes found in Patchwork_18397 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [PASS][1] -> [INCOMPLETE][2] ([i915#2276])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/fi-icl-y/igt@i915_selftest@l...@execlists.html

  
 Possible fixes 

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [DMESG-WARN][3] ([i915#1982]) -> [PASS][4] +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [INCOMPLETE][7] ([i915#1635] / [i915#337]) -> 
[PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [DMESG-FAIL][9] ([i915#62] / [i915#95]) -> [SKIP][10] 
([fdo#109271])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][12] ([i915#62] / [i915#92]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275:   [DMESG-WARN][13] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2276]: https://gitlab.freedesktop.org/drm/intel/issues/2276
  [i915#337]: https://gitlab.freedesktop.org/drm/intel/issues/337
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (37 -> 34)
--

  Missing(3): fi-byt-clapper fi-byt-squawks fi-bsw-cyan 


Build changes
-

  * Linux: CI_DRM_8924 -> Patchwork_18397

  CI-20190529: 20190529
  CI_DRM_8924: a8c0611e412aab46eab5475b0117d074892b96e2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5770: f1d0c240ea2e631dfb9f493f37f8fb61cb2b1cf2 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18397: 8ddeaeb4b15ce2d9392a7995f53a534ece03f9c6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8ddeaeb4b15c drm/i915/fbc: Disable fbc with VT-d also with cometlake

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/fbc: Disable fbc with VT-d also with cometlake

2020-08-25 Thread Patchwork
== Series Details ==

Series: drm/i915/fbc: Disable fbc with VT-d also with cometlake
URL   : https://patchwork.freedesktop.org/series/80977/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8924_full -> Patchwork_18397_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18397_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18397_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_18397_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_reloc@basic-many-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/shard-iclb4/igt@gem_exec_reloc@basic-many-act...@vcs1.html

  
Known issues


  Here are the changes found in Patchwork_18397_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl:  [PASS][2] -> [INCOMPLETE][3] ([i915#198])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-skl7/igt@gem_ctx_isolation@preservation...@vcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/shard-skl2/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_exec_reloc@basic-concurrent0:
- shard-apl:  [PASS][4] -> [TIMEOUT][5] ([i915#1635] / [i915#1958]) 
+1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-apl8/igt@gem_exec_re...@basic-concurrent0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/shard-apl8/igt@gem_exec_re...@basic-concurrent0.html

  * igt@gem_exec_reloc@basic-concurrent16:
- shard-skl:  [PASS][6] -> [TIMEOUT][7] ([i915#1958])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-skl3/igt@gem_exec_re...@basic-concurrent16.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/shard-skl5/igt@gem_exec_re...@basic-concurrent16.html

  * igt@gem_exec_whisper@basic-contexts:
- shard-kbl:  [PASS][8] -> [TIMEOUT][9] ([i915#1958]) +1 similar 
issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-kbl7/igt@gem_exec_whis...@basic-contexts.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/shard-kbl2/igt@gem_exec_whis...@basic-contexts.html

  * igt@gem_exec_whisper@basic-contexts-forked:
- shard-iclb: [PASS][10] -> [TIMEOUT][11] ([i915#1958])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-iclb6/igt@gem_exec_whis...@basic-contexts-forked.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/shard-iclb4/igt@gem_exec_whis...@basic-contexts-forked.html

  * igt@gem_exec_whisper@basic-fds-priority:
- shard-glk:  [PASS][12] -> [TIMEOUT][13] ([i915#1958]) +2 similar 
issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-glk6/igt@gem_exec_whis...@basic-fds-priority.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/shard-glk3/igt@gem_exec_whis...@basic-fds-priority.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#454])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-iclb7/igt@i915_pm...@dc6-psr.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/shard-iclb6/igt@i915_pm...@dc6-psr.html

  * igt@i915_selftest@mock@contexts:
- shard-apl:  [PASS][16] -> [INCOMPLETE][17] ([i915#1635] / 
[i915#2278])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-apl3/igt@i915_selftest@m...@contexts.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/shard-apl1/igt@i915_selftest@m...@contexts.html

  * igt@kms_big_fb@linear-64bpp-rotate-180:
- shard-glk:  [PASS][18] -> [DMESG-FAIL][19] ([i915#118] / 
[i915#95]) +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-glk6/igt@kms_big...@linear-64bpp-rotate-180.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl:  [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +7 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18397/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-dp1:
- shard-apl:  [PASS][22] -> [FAIL][23] ([i915#1635] / [i915#79])
   [22]: 
https://intel-gfx-ci.01

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

2020-08-25 Thread Harald Arnesen
Jani Nikula [25.08.2020 11:55]:

> On Fri, 21 Aug 2020, Pavel Machek  wrote:
>> On Thu 2020-08-20 09:16:18, Linus Torvalds wrote:
>>> On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek  wrote:
>>> >
>>> > Yes, it seems they make things work. (Chris asked for new patch to be
>>> > tested, so I am switching to his kernel, but it survived longer than
>>> > it usually does.)
>>> 
>>> Ok, so at worst we know how to solve it, at best the reverts won't be
>>> needed because Chris' patch will fix the issue properly.
>>> 
>>> So I'll archive this thread, but remind me if this hasn't gotten
>>> sorted out in the later rc's.
>>
>> Yes, thank you, it seems we have a solution w/o the revert.
> 
> For posterity, I'm told the fix is [1].
> 
> BR,
> Jani.
> 
> 
> [1] https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/

Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard
freeezes. I can still ssh into the machine

The three reverts (763fedd6a216, 7ac2d2536dfa and 9e0f9464e2ab) fixes
the bug for me.
-- 
Hilsen Harald
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v3 2/3] drm/i915/display: Disable DRRS when needed in fastsets

2020-08-25 Thread José Roberto de Souza
Changes in the configuration could cause PSR to be compatible and
enabled so driver must also be able to disable DRRS when doing
fastsets.

v2: Fixed name of DRRS compute function (Anshuman)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/209
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/173
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/209
Cc: Srinivas K 
Cc: Hariom Pandey 
Cc: Anshuman Gupta 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_ddi.c |  2 +-
 drivers/gpu/drm/i915/display/intel_dp.c  | 71 +---
 drivers/gpu/drm/i915/display/intel_dp.h  |  2 +
 3 files changed, 65 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index de5b216561d8..ff05a852417c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4012,7 +4012,7 @@ static void intel_ddi_update_pipe_dp(struct 
intel_atomic_state *state,
 
intel_psr_update(intel_dp, crtc_state, conn_state);
intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
-   intel_edp_drrs_enable(intel_dp, crtc_state);
+   intel_edp_drrs_update(intel_dp, crtc_state);
 
intel_panel_update_backlight(state, encoder, crtc_state, conn_state);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a08d03c61b02..c57ac83bf563 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7736,6 +7736,15 @@ static void intel_dp_set_drrs_state(struct 
drm_i915_private *dev_priv,
refresh_rate);
 }
 
+static void
+intel_edp_drrs_enable_locked(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+   dev_priv->drrs.busy_frontbuffer_bits = 0;
+   dev_priv->drrs.dp = intel_dp;
+}
+
 /**
  * intel_edp_drrs_enable - init drrs struct if supported
  * @intel_dp: DP struct
@@ -7754,19 +7763,34 @@ void intel_edp_drrs_enable(struct intel_dp *intel_dp,
drm_dbg_kms(&dev_priv->drm, "Enabling DRRS\n");
 
mutex_lock(&dev_priv->drrs.mutex);
+
if (dev_priv->drrs.dp) {
-   drm_dbg_kms(&dev_priv->drm, "DRRS already enabled\n");
+   drm_warn(&dev_priv->drm, "DRRS already enabled\n");
goto unlock;
}
 
-   dev_priv->drrs.busy_frontbuffer_bits = 0;
-
-   dev_priv->drrs.dp = intel_dp;
+   intel_edp_drrs_enable_locked(intel_dp);
 
 unlock:
mutex_unlock(&dev_priv->drrs.mutex);
 }
 
+static void
+intel_edp_drrs_disable_locked(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+   if (dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR) {
+   int refresh;
+
+   refresh = 
drm_mode_vrefresh(intel_dp->attached_connector->panel.fixed_mode);
+   intel_dp_set_drrs_state(dev_priv, crtc_state, refresh);
+   }
+
+   dev_priv->drrs.dp = NULL;
+}
+
 /**
  * intel_edp_drrs_disable - Disable DRRS
  * @intel_dp: DP struct
@@ -7787,16 +7811,45 @@ void intel_edp_drrs_disable(struct intel_dp *intel_dp,
return;
}
 
-   if (dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR)
-   intel_dp_set_drrs_state(dev_priv, old_crtc_state,
-   
drm_mode_vrefresh(intel_dp->attached_connector->panel.fixed_mode));
-
-   dev_priv->drrs.dp = NULL;
+   intel_edp_drrs_disable_locked(intel_dp, old_crtc_state);
mutex_unlock(&dev_priv->drrs.mutex);
 
cancel_delayed_work_sync(&dev_priv->drrs.work);
 }
 
+/**
+ * intel_edp_drrs_update - Update DRRS state
+ * @intel_dp: Intel DP
+ * @crtc_state: new CRTC state
+ *
+ * This function will update DRRS states, disabling or enabling DRRS when
+ * executing fastsets. For full modeset, intel_edp_drrs_disable() and
+ * intel_edp_drrs_enable() should be called instead.
+ */
+void
+intel_edp_drrs_update(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+   if (dev_priv->drrs.type != SEAMLESS_DRRS_SUPPORT)
+   return;
+
+   mutex_lock(&dev_priv->drrs.mutex);
+
+   /* New state matches current one? */
+   if (crtc_state->has_drrs == !!dev_priv->drrs.dp)
+   goto unlock;
+
+   if (crtc_state->has_drrs)
+   intel_edp_drrs_enable_locked(intel_dp);
+   else
+   intel_edp_drrs_disable_locked(intel_dp, crtc_state);
+
+unlock:
+   mutex_unlock(&dev_priv->drrs.mutex);
+}
+
 static void intel_edp_drrs_downclock_work(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index b901ab850c

[Intel-gfx] [PATCH v3 1/3] drm/i915/display: Compute has_drrs after compute has_psr

2020-08-25 Thread José Roberto de Souza
DRRS and PSR can't be enable together, so giving preference to PSR
as it allows more power-savings by complete shutting down display,
so to guarantee this, it should compute DRRS state after compute PSR.

Cc: Srinivas K 
Cc: Hariom Pandey 
Reviewed-by: Anshuman Gupta 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 52 +++--
 1 file changed, 32 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 79c27f91f42c..a08d03c61b02 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2575,6 +2575,34 @@ intel_dp_compute_hdr_metadata_infoframe_sdp(struct 
intel_dp *intel_dp,
intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA);
 }
 
+static void
+intel_dp_drrs_compute_config(struct intel_dp *intel_dp,
+struct intel_crtc_state *pipe_config,
+int output_bpp, bool constant_n)
+{
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+   /*
+* DRRS and PSR can't be enable together, so giving preference to PSR
+* as it allows more power-savings by complete shutting down display,
+* so to guarantee this, intel_dp_drrs_compute_config() must be called
+* after intel_psr_compute_config().
+*/
+   if (pipe_config->has_psr)
+   return;
+
+   if (!intel_connector->panel.downclock_mode ||
+   dev_priv->drrs.type != SEAMLESS_DRRS_SUPPORT)
+   return;
+
+   pipe_config->has_drrs = true;
+   intel_link_compute_m_n(output_bpp, pipe_config->lane_count,
+  intel_connector->panel.downclock_mode->clock,
+  pipe_config->port_clock, &pipe_config->dp_m2_n2,
+  constant_n, pipe_config->fec_enable);
+}
+
 int
 intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
@@ -2605,7 +2633,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (ret)
return ret;
 
-   pipe_config->has_drrs = false;
if (!intel_dp_port_has_audio(dev_priv, port))
pipe_config->has_audio = false;
else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
@@ -2657,21 +2684,12 @@ intel_dp_compute_config(struct intel_encoder *encoder,
   &pipe_config->dp_m_n,
   constant_n, pipe_config->fec_enable);
 
-   if (intel_connector->panel.downclock_mode != NULL &&
-   dev_priv->drrs.type == SEAMLESS_DRRS_SUPPORT) {
-   pipe_config->has_drrs = true;
-   intel_link_compute_m_n(output_bpp,
-  pipe_config->lane_count,
-  
intel_connector->panel.downclock_mode->clock,
-  pipe_config->port_clock,
-  &pipe_config->dp_m2_n2,
-  constant_n, 
pipe_config->fec_enable);
-   }
-
if (!HAS_DDI(dev_priv))
intel_dp_set_clock(encoder, pipe_config);
 
intel_psr_compute_config(intel_dp, pipe_config);
+   intel_dp_drrs_compute_config(intel_dp, pipe_config, output_bpp,
+constant_n);
intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, pipe_config, 
conn_state);
 
@@ -7730,16 +7748,10 @@ void intel_edp_drrs_enable(struct intel_dp *intel_dp,
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
 
-   if (!crtc_state->has_drrs) {
-   drm_dbg_kms(&dev_priv->drm, "Panel doesn't support DRRS\n");
+   if (!crtc_state->has_drrs)
return;
-   }
 
-   if (dev_priv->psr.enabled) {
-   drm_dbg_kms(&dev_priv->drm,
-   "PSR enabled. Not enabling DRRS.\n");
-   return;
-   }
+   drm_dbg_kms(&dev_priv->drm, "Enabling DRRS\n");
 
mutex_lock(&dev_priv->drrs.mutex);
if (dev_priv->drrs.dp) {
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v3 3/3] drm/i915/display: Fix DRRS debugfs

2020-08-25 Thread José Roberto de Souza
Supported and enabled are different things so printing both.

v3: using drrs->type instead of vbt.drrs_type

Cc: Anshuman Gupta 
Cc: Srinivas K 
Cc: Hariom Pandey 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display_debugfs.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index f549381048b3..65ccf5d6cd39 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1069,10 +1069,18 @@ static void drrs_status_per_crtc(struct seq_file *m,
 
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
+   bool supported = false;
+
if (connector->state->crtc != &intel_crtc->base)
continue;
 
seq_printf(m, "%s:\n", connector->name);
+
+   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP &&
+   drrs->type == SEAMLESS_DRRS_SUPPORT)
+   supported = true;
+
+   seq_printf(m, "\tDRRS Supported: %s\n", yesno(supported));
}
drm_connector_list_iter_end(&conn_iter);
 
@@ -1083,7 +1091,7 @@ static void drrs_status_per_crtc(struct seq_file *m,
 
mutex_lock(&drrs->mutex);
/* DRRS Supported */
-   seq_puts(m, "\tDRRS Supported: Yes\n");
+   seq_puts(m, "\tDRRS Enabled: Yes\n");
 
/* disable_drrs() will make drrs->dp NULL */
if (!drrs->dp) {
@@ -1118,7 +1126,7 @@ static void drrs_status_per_crtc(struct seq_file *m,
mutex_unlock(&drrs->mutex);
} else {
/* DRRS not supported. Print the VBT parameter*/
-   seq_puts(m, "\tDRRS Supported : No");
+   seq_puts(m, "\tDRRS Enabled : No");
}
seq_puts(m, "\n");
 }
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/3] drm/i915/display: Compute has_drrs after compute has_psr

2020-08-25 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/3] drm/i915/display: Compute has_drrs after 
compute has_psr
URL   : https://patchwork.freedesktop.org/series/80989/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18398


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/index.html

Known issues


  Here are the changes found in Patchwork_18398 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [PASS][1] -> [INCOMPLETE][2] ([i915#2276])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html

  
 Possible fixes 

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [DMESG-WARN][7] ([i915#1982]) -> [PASS][8] +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [INCOMPLETE][11] ([i915#1635] / [i915#337]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [DMESG-FAIL][13] ([i915#62] / [i915#95]) -> 
[DMESG-FAIL][14] ([i915#62])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275:   [DMESG-WARN][15] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2276]: https://gitlab.freedesktop.org/drm/intel/issues/2276
  [i915#337]: https://gitlab.freedesktop.org/drm/intel/issues/337
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (37 -> 34)
--

  Missing(3): fi-byt-clapper fi-byt-squawks fi-bsw-cyan 


Build changes
-

  * Linux: CI_DRM_8924 -> Patchwork_18398

  CI-20190529: 20190529
  CI_DRM_8924: a8c0611e412aab46eab5475b0117d074892b96e2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5770: f1d0c240ea2e631dfb9f493f37f8fb61cb2b1cf2 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18398: 7d42e19c12ea5344d13aa31756cf847649e9985b @ 
git://anongit.freedesktop.org/gfx-ci/l

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

2020-08-25 Thread Linus Torvalds
On Tue, Aug 25, 2020 at 9:32 AM Harald Arnesen  wrote:
>
> > For posterity, I'm told the fix is [1].
> >
> > [1] 
> > https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/
>
> Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard
> freeezes. I can still ssh into the machine
>
> The three reverts (763fedd6a216, 7ac2d2536dfa and 9e0f9464e2ab) fixes
> the bug for me.

Do you get any oops or other indication of what ends up going wrong?
Since ssh works that should be fairly easy to see.

Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 2/3] drm/i915/display/ehl: Use EHL DP tables for eDP ports without low power support

2020-08-25 Thread José Roberto de Souza
Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
being used when the eDP port don't support low power voltage swing table.

v2: Only use icl_combo_phy_ddi_translations_edp_hbr3 if low_vswing is
set as EHL combo phy supports HBR3 (Matt R)

Cc: Lee Shawn C 
Cc: Khaled Almahallawy 
Cc: Matt Roper 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9a035bb7bd06..699511872290 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1074,12 +1074,28 @@ static const struct cnl_ddi_buf_trans *
 ehl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
int *n_entries)
 {
-   if (type != INTEL_OUTPUT_HDMI && type != INTEL_OUTPUT_EDP) {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+   switch (type) {
+   case INTEL_OUTPUT_HDMI:
+   *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
+   return icl_combo_phy_ddi_translations_hdmi;
+   case INTEL_OUTPUT_EDP:
+   if (dev_priv->vbt.edp.low_vswing) {
+   if (rate > 54) {
+   *n_entries = 
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
+   return icl_combo_phy_ddi_translations_edp_hbr3;
+   } else {
+   *n_entries = 
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
+   return icl_combo_phy_ddi_translations_edp_hbr2;
+   }
+   }
+   /* fall through */
+   default:
+   /* All combo DP and eDP ports that do not support low_vswing */
*n_entries = ARRAY_SIZE(ehl_combo_phy_ddi_translations_dp);
return ehl_combo_phy_ddi_translations_dp;
}
-
-   return icl_get_combo_buf_trans(encoder, type, rate, n_entries);
 }
 
 static const struct cnl_ddi_buf_trans *
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support

2020-08-25 Thread José Roberto de Souza
Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
being used when the eDP port don't support low power voltage swing table.

Cc: Lee Shawn C 
Cc: Khaled Almahallawy 
Cc: Matt Roper 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 52 +++-
 1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index de5b216561d8..9a035bb7bd06 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1088,30 +1088,44 @@ tgl_get_combo_buf_trans(struct intel_encoder *encoder, 
int type, int rate,
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
 
-   if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.hobl) {
-   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-
-   if (!intel_dp->hobl_failed && rate <= 54) {
-   /* Same table applies to TGL, RKL and DG1 */
-   *n_entries = 
ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
-   return tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
+   switch (type) {
+   case INTEL_OUTPUT_HDMI:
+   *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
+   return icl_combo_phy_ddi_translations_hdmi;
+   case INTEL_OUTPUT_EDP:
+   if (dev_priv->vbt.edp.hobl) {
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   if (!intel_dp->hobl_failed && rate <= 54) {
+   /* Same table applies to TGL, RKL and DG1 */
+   *n_entries = 
ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
+   return 
tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
+   }
}
-   }
 
-   if (type == INTEL_OUTPUT_HDMI || type == INTEL_OUTPUT_EDP) {
-   return icl_get_combo_buf_trans(encoder, type, rate, n_entries);
-   } else if (rate > 27) {
-   if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
-   *n_entries = 
ARRAY_SIZE(tgl_uy_combo_phy_ddi_translations_dp_hbr2);
-   return tgl_uy_combo_phy_ddi_translations_dp_hbr2;
+   if (rate > 54) {
+   *n_entries = 
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
+   return icl_combo_phy_ddi_translations_edp_hbr3;
+   } else if (dev_priv->vbt.edp.low_vswing) {
+   *n_entries = 
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
+   return icl_combo_phy_ddi_translations_edp_hbr2;
+   }
+   /* fall through */
+   default:
+   /* All combo DP and eDP ports that do not support low_vswing */
+   if (rate > 27) {
+   if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
+   *n_entries = 
ARRAY_SIZE(tgl_uy_combo_phy_ddi_translations_dp_hbr2);
+   return 
tgl_uy_combo_phy_ddi_translations_dp_hbr2;
+   }
+
+   *n_entries = 
ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr2);
+   return tgl_combo_phy_ddi_translations_dp_hbr2;
}
 
-   *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr2);
-   return tgl_combo_phy_ddi_translations_dp_hbr2;
+   *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr);
+   return tgl_combo_phy_ddi_translations_dp_hbr;
}
-
-   *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr);
-   return tgl_combo_phy_ddi_translations_dp_hbr;
 }
 
 static const struct tgl_dkl_phy_ddi_buf_trans *
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 3/3] drm/i915/ehl: Update voltage swing table

2020-08-25 Thread José Roberto de Souza
Update with latest tunning in the table.

BSpec: 21257
Cc: Matt Roper 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 699511872290..c7e64e20a772 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -572,14 +572,14 @@ static const struct cnl_ddi_buf_trans 
ehl_combo_phy_ddi_translations_dp[] = {
/* NT mV Trans mV db*/
{ 0xA, 0x33, 0x3F, 0x00, 0x00 },/* 350   350  0.0   */
{ 0xA, 0x47, 0x36, 0x00, 0x09 },/* 350   500  3.1   */
-   { 0xC, 0x64, 0x30, 0x00, 0x0F },/* 350   700  6.0   */
-   { 0x6, 0x7F, 0x2C, 0x00, 0x13 },/* 350   900  8.2   */
+   { 0xC, 0x64, 0x34, 0x00, 0x0B },/* 350   700  6.0   */
+   { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 350   900  8.2   */
{ 0xA, 0x46, 0x3F, 0x00, 0x00 },/* 500   500  0.0   */
-   { 0xC, 0x64, 0x36, 0x00, 0x09 },/* 500   700  2.9   */
-   { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 500   900  5.1   */
+   { 0xC, 0x64, 0x38, 0x00, 0x07 },/* 500   700  2.9   */
+   { 0x6, 0x7F, 0x32, 0x00, 0x0D },/* 500   900  5.1   */
{ 0xC, 0x61, 0x3F, 0x00, 0x00 },/* 650   700  0.6   */
-   { 0x6, 0x7F, 0x37, 0x00, 0x08 },/* 600   900  3.5   */
-   { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900   900  0.0   */
+   { 0x6, 0x7F, 0x37, 0x00, 0x07 },/* 600   900  3.5   */
+   { 0x6, 0x7F, 0x38, 0x00, 0x00 },/* 900   900  0.0   */
 };
 
 struct icl_mg_phy_ddi_buf_trans {
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support

2020-08-25 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/3] drm/i915/display/tgl: Use TGL DP tables 
for eDP ports without low power support
URL   : https://patchwork.freedesktop.org/series/80990/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
5b6227b45a69 drm/i915/display/tgl: Use TGL DP tables for eDP ports without low 
power support
-:43: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#43: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1101:
+   *n_entries = 
ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);

-:62: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthrough;' over fallthrough comment
#62: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1113:
+   /* fall through */

total: 0 errors, 2 warnings, 0 checks, 63 lines checked
3aa5a2ba6712 drm/i915/display/ehl: Use EHL DP tables for eDP ports without low 
power support
-:41: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or 
return
#41: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1088:
+   return icl_combo_phy_ddi_translations_edp_hbr3;
+   } else {

-:46: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthrough;' over fallthrough comment
#46: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1093:
+   /* fall through */

total: 0 errors, 2 warnings, 0 checks, 31 lines checked
f88ee990640a drm/i915/ehl: Update voltage swing table
-:9: WARNING:TYPO_SPELLING: 'tunning' may be misspelled - perhaps 'tuning'?
#9: 
Update with latest tunning in the table.

total: 0 errors, 1 warnings, 0 checks, 20 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/3] drm/i915/display: Compute has_drrs after compute has_psr

2020-08-25 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/3] drm/i915/display: Compute has_drrs after 
compute has_psr
URL   : https://patchwork.freedesktop.org/series/80989/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8924_full -> Patchwork_18398_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18398_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18398_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_18398_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_sync@basic-store-all:
- shard-tglb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-tglb5/igt@gem_s...@basic-store-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/shard-tglb7/igt@gem_s...@basic-store-all.html

  
Known issues


  Here are the changes found in Patchwork_18398_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_reloc@basic-concurrent0:
- shard-apl:  [PASS][3] -> [TIMEOUT][4] ([i915#1635] / [i915#1958]) 
+1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-apl8/igt@gem_exec_re...@basic-concurrent0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/shard-apl2/igt@gem_exec_re...@basic-concurrent0.html

  * igt@gem_exec_whisper@basic-fds-forked-all:
- shard-kbl:  [PASS][5] -> [TIMEOUT][6] ([i915#1958]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-kbl4/igt@gem_exec_whis...@basic-fds-forked-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/shard-kbl2/igt@gem_exec_whis...@basic-fds-forked-all.html

  * igt@gem_exec_whisper@basic-queues-priority-all:
- shard-glk:  [PASS][7] -> [TIMEOUT][8] ([i915#1958]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-glk7/igt@gem_exec_whis...@basic-queues-priority-all.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/shard-glk6/igt@gem_exec_whis...@basic-queues-priority-all.html

  * igt@i915_pm_dc@dc5-psr:
- shard-skl:  [PASS][9] -> [INCOMPLETE][10] ([i915#198])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-skl5/igt@i915_pm...@dc5-psr.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/shard-skl7/igt@i915_pm...@dc5-psr.html

  * igt@kms_big_fb@x-tiled-64bpp-rotate-0:
- shard-glk:  [PASS][11] -> [DMESG-FAIL][12] ([i915#118] / 
[i915#95]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-glk1/igt@kms_big...@x-tiled-64bpp-rotate-0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html

  * igt@kms_big_fb@x-tiled-8bpp-rotate-0:
- shard-apl:  [PASS][13] -> [DMESG-WARN][14] ([i915#1635] / 
[i915#1982]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-apl3/igt@kms_big...@x-tiled-8bpp-rotate-0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/shard-apl1/igt@kms_big...@x-tiled-8bpp-rotate-0.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw:  [PASS][15] -> [FAIL][16] ([i915#96])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html

  * igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic:
- shard-kbl:  [PASS][17] -> [DMESG-WARN][18] ([i915#1982])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-kbl1/igt@kms_cursor_leg...@flip-vs-cursor-crc-atomic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/shard-kbl4/igt@kms_cursor_leg...@flip-vs-cursor-crc-atomic.html

  * igt@kms_cursor_legacy@flip-vs-cursor-legacy:
- shard-skl:  [PASS][19] -> [FAIL][20] ([i915#2346])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-skl7/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/shard-skl1/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html

  * igt@kms_flip@flip-vs-expired-vblank@c-dp1:
- shard-apl:  [PASS][21] -> [FAIL][22] ([i915#1635] / [i915#79])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-apl6/igt@kms_flip@flip-vs-expired-vbl...@c-dp1.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support

2020-08-25 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/3] drm/i915/display/tgl: Use TGL DP tables 
for eDP ports without low power support
URL   : https://patchwork.freedesktop.org/series/80990/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18399


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/index.html

Known issues


  Here are the changes found in Patchwork_18399 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-tgl-u2:  [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-tgl-u2/igt@i915_module_l...@reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/fi-tgl-u2/igt@i915_module_l...@reload.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2:  [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html

  
 Possible fixes 

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [DMESG-WARN][5] ([i915#1982]) -> [PASS][6] +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [INCOMPLETE][9] ([i915#1635] / [i915#337]) -> 
[PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275:   [DMESG-WARN][11] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [DMESG-FAIL][13] ([i915#62] / [i915#95]) -> 
[DMESG-FAIL][14] ([i915#62])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  
  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#337]: https://gitlab.freedesktop.org/drm/intel/issues/337
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (37 -> 34)
--

  Missing(3): fi-byt-clapper fi-byt-squawks fi-bsw-cyan 


Build changes
-

  * Linux: CI_DRM_8924 -> Patchwork_18399

  CI-20190529: 20190529
  CI_DRM_8924: a8c0611e412aab46eab5475b0117d074892b96e2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5770: f1d0c240ea2e631dfb9f493f37f8fb61cb2b1cf2 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18399: f88ee990640a57e8215c745a94a8e5d2334d72b8 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f88ee990640a drm/i915/ehl: Update voltage swing table
3aa5a2ba6712 drm/i915/display/ehl: Use EHL DP tables for eDP ports without low 
power support
5b6227b45a69 drm/i915/display/tgl: Use TGL DP tables for eDP ports without low 
power support

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/tgl: Fix stepping WA matching

2020-08-25 Thread Souza, Jose
On Wed, 2020-08-19 at 13:33 -0700, José Roberto de Souza wrote:
> TGL made stepping a litte mess, workarounds refer to the stepping of
> the IP(GT or Display) not of the GPU stepping so it would already
> require the same solution as used in commit 96c5a15f9f39
> ("drm/i915/kbl: Fix revision ID checks").
> But to make things even more messy it have a different IP stepping
> mapping between SKUs and the same stepping revision of GT do not match
> the same HW between TGL U/Y and regular TGL.
> 
> So it was required to have 2 different macros to check GT WAs while
> for Display we are able to use just one macro that uses the right
> revids table.
> 
> All TGL workarounds checked and updated accordingly.
> 
> BSpec: 52890
> BSpec: 55378
> BSpec: 44455
> Cc: Penne Lee <
> penne.y@intel.com
> >
> Cc: Guangyao Bai <
> guangyao@intel.com
> >
> Cc: Matt Roper <
> matthew.d.ro...@intel.com
> >
> Signed-off-by: José Roberto de Souza <
> jose.so...@intel.com
> >
> ---
>  .../drm/i915/display/intel_display_power.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_psr.c  |  4 +-
>  drivers/gpu/drm/i915/display/intel_sprite.c   |  2 +-
>  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 24 ++--
>  drivers/gpu/drm/i915/i915_drv.h   | 39 ---
>  drivers/gpu/drm/i915/intel_pm.c   |  2 +-
>  6 files changed, 59 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 7946c6af4b1e..7277e58b01f1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -5263,7 +5263,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private 
> *dev_priv)
>   unsigned long abox_mask = INTEL_INFO(dev_priv)->abox_mask;
>   int config, i;
>  
> - if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
> + if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
>   /* Wa_1409767108: tgl */
>   table = wa_1409767108_buddy_page_masks;
>   else
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 2b004ee9619c..8a9d0bdde1bf 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -555,7 +555,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>  
>   if (dev_priv->psr.psr2_sel_fetch_enabled) {
>   /* WA 1408330847 */
> - if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
> + if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
>   IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
>   intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
>DIS_RAM_BYPASS_PSR2_MAN_TRACK,
> @@ -1109,7 +1109,7 @@ static void intel_psr_disable_locked(struct intel_dp 
> *intel_dp)
>  
>   /* WA 1408330847 */
>   if (dev_priv->psr.psr2_sel_fetch_enabled &&
> - (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
> + (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
>IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)))
>   intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
>DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index c26ca029fc0a..1797a06cfd60 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -2845,7 +2845,7 @@ static bool gen12_plane_supports_mc_ccs(struct 
> drm_i915_private *dev_priv,
>  {
>   /* Wa_14010477008:tgl[a0..c0],rkl[all] */
>   if (IS_ROCKETLAKE(dev_priv) ||
> - IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
> + IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
>   return false;
>  
>   return plane_id < PLANE_SPRITE4;
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index be5a4685c991..860d6ae1d866 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -70,6 +70,19 @@ const struct i915_rev_steppings kbl_revids[] = {
>   [7] = { .gt_stepping = KBL_REVID_G0, .disp_stepping = KBL_REVID_C0 },
>  };
>  
> +const struct i915_rev_steppings tgl_uy_revids[] = {
> + [0] = { .gt_stepping = TGL_REVID_A0, .disp_stepping = TGL_REVID_A0 },
> + [1] = { .gt_stepping = TGL_REVID_B0, .disp_stepping = TGL_REVID_C0 },
> + [2] = { .gt_stepping = TGL_REVID_B1, .disp_stepping = TGL_REVID_C0 },
> + [3] = { .gt_stepping = TGL_REVID_C0, .disp_stepping = TGL_REVID_D0 },
> +};
> +
> +/* Same GT stepping between tgl_uy_revids and tgl_revids don't mean the same 
> HW */
> +const struct i915_rev_steppings tgl_revids[] = {
> + [0] = { .gt_steppin

[Intel-gfx] [RFC v4 00/20] drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915

2020-08-25 Thread Lyude Paul
Most of the reason I'm asking for an RFC here is because this
code pulls a lot of code out of i915 and into shared DP helpers.

Anyway-nouveau's HPD related code has been collecting dust for a while.
Other then the occasional runtime PM related and MST related fixes,
we're missing a lot of nice things that have been added to DRM since
this was originally written. Additionally, the code is just really
unoptimized in general:

* We handle connector probing in the same context that we handle short
  IRQs in for DP, which means connector probing could potentially block
  ESI handling for MST
* When we receive a hotplug event from a connector, we reprobe every
  single connector instead of just the connector that was hotplugged
* Additionally because of the above reason, combined with the fact I had
  the bad idea of reusing some of the MST locks when I last rewrote
  nouveau's DP MST detection, trying to handle any other events that
  require short HPD IRQs is a bit awkward to actually implement.
* We don't actually properly check whether EDIDs change or not when
  reprobing, which means we basically send out a hotplug event every
  single time we receive one even if nothing has changed

Additionally, the code for handling DP that we have in nouveau is also
quite unoptimized in general, doesn't use a lot of helpers that have
been added since it was written, and is also missing quite a number of
features:

* Downstream port capability probing
* Extended DPRX cap parsing
* SINK_COUNT handling for hpd on dongles

Luckily for us - all of these are implemented in i915 already. Since
there's no reason for us to reinvent the wheel, and having more shared
code is always nice, I decided to take the opportunity to extract the
code for all of these features from i915 into a set of core DP helpers,
which both i915 and nouveau (and hopefully other drivers in the future)
can use.

As well, this patch series also addesses the other general
connector probing related issues I mentioned above, along with rewriting
how we handle MST probing so we don't hit any surprise locking design
issues in the future.

As a note - most of this work is motivated by the fact that I'm
planning on adding max_bpc/output_bpc prop support, DSC support (for
both MST and SST, along with proper helpers for handling bandwidth
limitations and DSC), and fallback link retraining. I figured I might as
clean this code up and implement missing DP features like the ones
mentioned here before moving on to those tasks.

Lyude Paul (20):
  drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()
  drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc()
  drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c
  drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c
  drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new()
  drm/nouveau/kms: Search for encoders' connectors properly
  drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in
nv50_sor_disable()
  drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling
  drm/i915/dp: Extract drm_dp_has_mst()
  drm/nouveau/kms: Use new drm_dp_has_mst() helper for checking MST caps
  drm/nouveau/kms: Move drm_dp_cec_unset_edid() into
nouveau_connector_detect()
  drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths
  drm/i915/dp: Extract drm_dp_downstream_read_info()
  drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode
validation
  drm/i915/dp: Extract drm_dp_has_sink_count()
  drm/i915/dp: Extract drm_dp_get_sink_count()
  drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT
  drm/nouveau/kms: Don't change EDID when it hasn't actually changed
  drm/i915/dp: Extract drm_dp_read_dpcd_caps()
  drm/nouveau/kms: Start using drm_dp_read_dpcd_caps()

 drivers/gpu/drm/drm_dp_helper.c | 167 +++
 drivers/gpu/drm/i915/display/intel_dp.c | 124 ++--
 drivers/gpu/drm/i915/display/intel_dp.h |   1 -
 drivers/gpu/drm/i915/display/intel_lspcon.c |   2 +-
 drivers/gpu/drm/nouveau/dispnv04/dac.c  |   2 +-
 drivers/gpu/drm/nouveau/dispnv04/dfp.c  |   7 +-
 drivers/gpu/drm/nouveau/dispnv04/disp.c |  24 +-
 drivers/gpu/drm/nouveau/dispnv04/disp.h |   4 +
 drivers/gpu/drm/nouveau/dispnv04/tvnv04.c   |   2 +-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c   |   2 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 305 +++-
 drivers/gpu/drm/nouveau/nouveau_connector.c | 132 -
 drivers/gpu/drm/nouveau/nouveau_connector.h |   1 +
 drivers/gpu/drm/nouveau/nouveau_display.c   |  72 -
 drivers/gpu/drm/nouveau/nouveau_display.h   |   3 +-
 drivers/gpu/drm/nouveau/nouveau_dp.c| 211 +++---
 drivers/gpu/drm/nouveau/nouveau_drm.c   |   4 +-
 drivers/gpu/drm/nouveau/nouveau_drv.h   |   2 +
 drivers/gpu/drm/nouveau/nouveau_encoder.h   |  48 ++-
 include/drm/drm_dp_helper.h |  15 +-
 include/drm/drm_dp_mst_helper.h |  22 ++
 21 files changed, 761 insertions(+),

[Intel-gfx] [RFC v4 01/20] drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()

2020-08-25 Thread Lyude Paul
Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nouveau_dp.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8a0f7994e1aeb..ee778ddc95fae 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -76,10 +76,10 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK;
 
NV_DEBUG(drm, "display: %dx%d dpcd 0x%02x\n",
-nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, dpcd[0]);
+nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, dpcd[0]);
NV_DEBUG(drm, "encoder: %dx%d\n",
-nv_encoder->dcb->dpconf.link_nr,
-nv_encoder->dcb->dpconf.link_bw);
+nv_encoder->dcb->dpconf.link_nr,
+nv_encoder->dcb->dpconf.link_bw);
 
if (nv_encoder->dcb->dpconf.link_nr < nv_encoder->dp.link_nr)
nv_encoder->dp.link_nr = nv_encoder->dcb->dpconf.link_nr;
@@ -87,7 +87,7 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
nv_encoder->dp.link_bw = nv_encoder->dcb->dpconf.link_bw;
 
NV_DEBUG(drm, "maximum: %dx%d\n",
-nv_encoder->dp.link_nr, nv_encoder->dp.link_bw);
+nv_encoder->dp.link_nr, nv_encoder->dp.link_bw);
 
nouveau_dp_probe_oui(dev, aux, dpcd);
 
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC v4 04/20] drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c

2020-08-25 Thread Lyude Paul
No functional changes.

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8db9216d52c69..4030806e3522b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -50,11 +50,13 @@ nouveau_dp_detect(struct nouveau_connector *nv_connector,
if (ret != sizeof(dpcd))
return ret;
 
-   nv_encoder->dp.link_bw = 27000 * dpcd[1];
-   nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK;
+   nv_encoder->dp.link_bw = 27000 * dpcd[DP_MAX_LINK_RATE];
+   nv_encoder->dp.link_nr =
+   dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK;
 
NV_DEBUG(drm, "display: %dx%d dpcd 0x%02x\n",
-nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, dpcd[0]);
+nv_encoder->dp.link_nr, nv_encoder->dp.link_bw,
+dpcd[DP_DPCD_REV]);
NV_DEBUG(drm, "encoder: %dx%d\n",
 nv_encoder->dcb->dpconf.link_nr,
 nv_encoder->dcb->dpconf.link_bw);
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC v4 02/20] drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc()

2020-08-25 Thread Lyude Paul
Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c |  3 ++-
 drivers/gpu/drm/nouveau/nouveau_dp.c| 30 +++--
 drivers/gpu/drm/nouveau/nouveau_encoder.h   |  4 ++-
 3 files changed, 14 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 7674025a4bfe8..e12957e6faa7c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -435,7 +435,8 @@ nouveau_connector_ddc_detect(struct drm_connector 
*connector)
 
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_DP:
-   ret = nouveau_dp_detect(nv_encoder);
+   ret = nouveau_dp_detect(nouveau_connector(connector),
+   nv_encoder);
if (ret == NOUVEAU_DP_MST)
return NULL;
else if (ret == NOUVEAU_DP_SST)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index ee778ddc95fae..c4e9c21d4dd2b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -36,27 +36,9 @@ MODULE_PARM_DESC(mst, "Enable DisplayPort multi-stream 
(default: enabled)");
 static int nouveau_mst = 1;
 module_param_named(mst, nouveau_mst, int, 0400);
 
-static void
-nouveau_dp_probe_oui(struct drm_device *dev, struct nvkm_i2c_aux *aux, u8 
*dpcd)
-{
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   u8 buf[3];
-
-   if (!(dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
-   return;
-
-   if (!nvkm_rdaux(aux, DP_SINK_OUI, buf, 3))
-   NV_DEBUG(drm, "Sink OUI: %02hx%02hx%02hx\n",
-buf[0], buf[1], buf[2]);
-
-   if (!nvkm_rdaux(aux, DP_BRANCH_OUI, buf, 3))
-   NV_DEBUG(drm, "Branch OUI: %02hx%02hx%02hx\n",
-buf[0], buf[1], buf[2]);
-
-}
-
 int
-nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
+nouveau_dp_detect(struct nouveau_connector *nv_connector,
+ struct nouveau_encoder *nv_encoder)
 {
struct drm_device *dev = nv_encoder->base.base.dev;
struct nouveau_drm *drm = nouveau_drm(dev);
@@ -89,7 +71,13 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
NV_DEBUG(drm, "maximum: %dx%d\n",
 nv_encoder->dp.link_nr, nv_encoder->dp.link_bw);
 
-   nouveau_dp_probe_oui(dev, aux, dpcd);
+   ret = drm_dp_read_desc(&nv_connector->aux, &nv_encoder->dp.desc,
+  drm_dp_is_branch(dpcd));
+   if (ret) {
+   NV_ERROR(drm, "Failed to read DP descriptor on %s: %d\n",
+nv_connector->base.name, ret);
+   return ret;
+   }
 
ret = nv50_mstm_detect(nv_encoder->dp.mstm, dpcd, nouveau_mst);
if (ret == 1)
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h 
b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index a72c412ac8b14..6424cdcb4913f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -33,6 +33,7 @@
 #include 
 #include "dispnv04/disp.h"
 struct nv50_head_atom;
+struct nouveau_connector;
 
 #define NV_DPMS_CLEARED 0x80
 
@@ -64,6 +65,7 @@ struct nouveau_encoder {
struct nv50_mstm *mstm;
int link_nr;
int link_bw;
+   struct drm_dp_desc desc;
} dp;
};
 
@@ -104,7 +106,7 @@ enum nouveau_dp_status {
NOUVEAU_DP_MST,
 };
 
-int nouveau_dp_detect(struct nouveau_encoder *);
+int nouveau_dp_detect(struct nouveau_connector *, struct nouveau_encoder *);
 enum drm_mode_status nv50_dp_mode_valid(struct drm_connector *,
struct nouveau_encoder *,
const struct drm_display_mode *,
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC v4 03/20] drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c

2020-08-25 Thread Lyude Paul
Since this actually logs accesses, we should probably always be using
this imho…

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nouveau_dp.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index c4e9c21d4dd2b..8db9216d52c69 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -42,16 +42,12 @@ nouveau_dp_detect(struct nouveau_connector *nv_connector,
 {
struct drm_device *dev = nv_encoder->base.base.dev;
struct nouveau_drm *drm = nouveau_drm(dev);
-   struct nvkm_i2c_aux *aux;
-   u8 dpcd[8];
+   struct drm_dp_aux *aux = &nv_connector->aux;
+   u8 dpcd[DP_RECEIVER_CAP_SIZE];
int ret;
 
-   aux = nv_encoder->aux;
-   if (!aux)
-   return -ENODEV;
-
-   ret = nvkm_rdaux(aux, DP_DPCD_REV, dpcd, sizeof(dpcd));
-   if (ret)
+   ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
+   if (ret != sizeof(dpcd))
return ret;
 
nv_encoder->dp.link_bw = 27000 * dpcd[1];
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC v4 14/20] drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation

2020-08-25 Thread Lyude Paul
This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.

Note as well, we also start marking the connector as disconnected if we
can't read the DPCD, since we wouldn't be able to do anything without
DPCD access anyway.

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |  3 +++
 drivers/gpu/drm/nouveau/nouveau_dp.c  | 15 +++
 drivers/gpu/drm/nouveau/nouveau_encoder.h |  1 +
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 8e1effb10425d..d2141ca16107b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1258,7 +1258,10 @@ nv50_mstc_detect(struct drm_connector *connector,
 
ret = drm_dp_mst_detect_port(connector, ctx, mstc->port->mgr,
 mstc->port);
+   if (ret != connector_status_connected)
+   goto out;
 
+out:
pm_runtime_mark_last_busy(connector->dev->dev);
pm_runtime_put_autosuspend(connector->dev->dev);
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 71d095409c90d..c200f197083f9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -61,6 +61,11 @@ nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
mstm->can_mst = drm_dp_has_mst(aux, dpcd);
}
 
+   ret = drm_dp_downstream_read_info(aux, dpcd,
+ outp->dp.downstream_ports);
+   if (ret < 0)
+   return connector_status_disconnected;
+
return connector_status_connected;
 }
 
@@ -176,8 +181,6 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
 /* TODO:
  * - Use the minimum possible BPC here, once we add support for the max bpc
  *   property.
- * - Validate the mode against downstream port caps (see
- *   drm_dp_downstream_max_clock())
  * - Validate against the DP caps advertised by the GPU (we don't check these
  *   yet)
  */
@@ -188,15 +191,19 @@ nv50_dp_mode_valid(struct drm_connector *connector,
   unsigned *out_clock)
 {
const unsigned min_clock = 25000;
-   unsigned max_clock, clock;
+   unsigned max_clock, ds_clock, clock;
enum drm_mode_status ret;
 
if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
return MODE_NO_INTERLACE;
 
max_clock = outp->dp.link_nr * outp->dp.link_bw;
-   clock = mode->clock * (connector->display_info.bpc * 3) / 10;
+   ds_clock = drm_dp_downstream_max_clock(outp->dp.dpcd,
+  outp->dp.downstream_ports);
+   if (ds_clock)
+   max_clock = min(max_clock, ds_clock);
 
+   clock = mode->clock * (connector->display_info.bpc * 3) / 10;
ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
&clock);
if (out_clock)
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h 
b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index eef4643f5f982..c1924a4529a7b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -72,6 +72,7 @@ struct nouveau_encoder {
struct mutex hpd_irq_lock;
 
u8 dpcd[DP_RECEIVER_CAP_SIZE];
+   u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
struct drm_dp_desc desc;
} dp;
};
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC v4 17/20] drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT

2020-08-25 Thread Lyude Paul
This is another bit that we never implemented for nouveau: dongle
detection. When a "dongle", e.g. an active display adaptor, is hooked up
to the system and causes an HPD to be fired, we don't actually know
whether or not there's anything plugged into the dongle without checking
the sink count. As a result, plugging in a dongle without anything
plugged into it currently results in a bogus EDID retrieval error in the kernel 
log.

Additionally, most dongles won't send another long HPD signal if the
user suddenly plugs something in, they'll only send a short HPD IRQ with
the expectation that the source will check the sink count and reprobe
the connector if it's changed - something we don't actually do. As a
result, nothing will happen if the user plugs the dongle in before
plugging something into the dongle.

So, let's fix this by checking the sink count in both
nouveau_dp_probe_dpcd() and nouveau_dp_irq(), and reprobing the
connector if things change.

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nouveau_dp.c  | 54 ---
 drivers/gpu/drm/nouveau/nouveau_encoder.h |  2 +
 2 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index c200f197083f9..89afc97ee2591 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -36,12 +36,22 @@ MODULE_PARM_DESC(mst, "Enable DisplayPort multi-stream 
(default: enabled)");
 static int nouveau_mst = 1;
 module_param_named(mst, nouveau_mst, int, 0400);
 
+static bool
+nouveau_dp_has_sink_count(struct drm_connector *connector,
+ struct nouveau_encoder *outp)
+{
+   return drm_dp_has_sink_count(connector, outp->dp.dpcd,
+&outp->dp.desc);
+}
+
 static enum drm_connector_status
 nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
  struct nouveau_encoder *outp)
 {
+   struct drm_connector *connector = &nv_connector->base;
struct drm_dp_aux *aux = &nv_connector->aux;
struct nv50_mstm *mstm = NULL;
+   enum drm_connector_status status = connector_status_disconnected;
int ret;
u8 *dpcd = outp->dp.dpcd;
 
@@ -50,9 +60,9 @@ nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
ret = drm_dp_read_desc(aux, &outp->dp.desc,
   drm_dp_is_branch(dpcd));
if (ret < 0)
-   return connector_status_disconnected;
+   goto out;
} else {
-   return connector_status_disconnected;
+   goto out;
}
 
if (nouveau_mst) {
@@ -61,12 +71,33 @@ nouveau_dp_probe_dpcd(struct nouveau_connector 
*nv_connector,
mstm->can_mst = drm_dp_has_mst(aux, dpcd);
}
 
+   if (nouveau_dp_has_sink_count(connector, outp)) {
+   ret = drm_dp_get_sink_count(aux);
+   if (ret < 0)
+   goto out;
+
+   outp->dp.sink_count = ret;
+
+   /*
+* Dongle connected, but no display. Don't bother reading
+* downstream port info
+*/
+   if (!outp->dp.sink_count)
+   return connector_status_disconnected;
+   }
+
ret = drm_dp_downstream_read_info(aux, dpcd,
  outp->dp.downstream_ports);
if (ret < 0)
-   return connector_status_disconnected;
+   goto out;
 
-   return connector_status_connected;
+   status = connector_status_connected;
+out:
+   if (status != connector_status_connected) {
+   /* Clear any cached info */
+   outp->dp.sink_count = 0;
+   }
+   return status;
 }
 
 int
@@ -159,6 +190,8 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
struct drm_connector *connector = &nv_connector->base;
struct nouveau_encoder *outp = find_encoder(connector, DCB_OUTPUT_DP);
struct nv50_mstm *mstm;
+   int ret;
+   bool send_hpd = false;
 
if (!outp)
return;
@@ -170,12 +203,23 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
 
if (mstm && mstm->is_mst) {
if (!nv50_mstm_service(drm, nv_connector, mstm))
-   nouveau_connector_hpd(connector);
+   send_hpd = true;
} else {
drm_dp_cec_irq(&nv_connector->aux);
+
+   if (nouveau_dp_has_sink_count(connector, outp)) {
+   ret = drm_dp_get_sink_count(&nv_connector->aux);
+   if (ret != outp->dp.sink_count)
+   send_hpd = true;
+   if (ret >= 0)
+   outp->dp.sink_count = ret;
+   }
}
 
mutex_unlock(&outp->dp.hpd_irq_lock);
+
+   if (s

[Intel-gfx] [RFC v4 09/20] drm/i915/dp: Extract drm_dp_has_mst()

2020-08-25 Thread Lyude Paul
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.

Signed-off-by: Lyude Paul 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
 include/drm/drm_dp_mst_helper.h | 22 ++
 2 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 79c27f91f42c0..1e29d3a012856 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4699,20 +4699,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
return true;
 }
 
-static bool
-intel_dp_sink_can_mst(struct intel_dp *intel_dp)
-{
-   u8 mstm_cap;
-
-   if (intel_dp->dpcd[DP_DPCD_REV] < 0x12)
-   return false;
-
-   if (drm_dp_dpcd_readb(&intel_dp->aux, DP_MSTM_CAP, &mstm_cap) != 1)
-   return false;
-
-   return mstm_cap & DP_MST_CAP;
-}
-
 static bool
 intel_dp_can_mst(struct intel_dp *intel_dp)
 {
@@ -4720,7 +4706,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
 
return i915->params.enable_dp_mst &&
intel_dp->can_mst &&
-   intel_dp_sink_can_mst(intel_dp);
+   drm_dp_has_mst(&intel_dp->aux, intel_dp->dpcd);
 }
 
 static void
@@ -4729,7 +4715,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_encoder *encoder =
&dp_to_dig_port(intel_dp)->base;
-   bool sink_can_mst = intel_dp_sink_can_mst(intel_dp);
+   bool sink_can_mst = drm_dp_has_mst(&intel_dp->aux, intel_dp->dpcd);
 
drm_dbg_kms(&i915->drm,
"[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam: 
%s\n",
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 8b9eb4db3381c..2d8983a713e8c 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -911,4 +911,26 @@ __drm_dp_mst_state_iter_get(struct drm_atomic_state *state,
for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr), 
NULL, &(new_state), (__i)))
 
+/**
+ * drm_dp_has_mst() - check whether or not a sink supports MST
+ * @aux: The DP AUX channel to use
+ * @dpcd: A cached copy of the DPCD capabilities for this sink
+ *
+ * Returns: %True if the sink supports MST, %false otherwise
+ */
+static inline bool
+drm_dp_has_mst(struct drm_dp_aux *aux,
+  const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   u8 mstm_cap;
+
+   if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
+   return false;
+
+   if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, &mstm_cap) != 1)
+   return false;
+
+   return !!(mstm_cap & DP_MST_CAP);
+}
+
 #endif
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC v4 15/20] drm/i915/dp: Extract drm_dp_has_sink_count()

2020-08-25 Thread Lyude Paul
Since other drivers are also going to need to be aware of the sink count
in order to do proper dongle detection, we might as well steal i915's
DP_SINK_COUNT helpers and move them into DRM helpers so that other
dirvers can use them as well.

Note that this also starts using intel_dp_has_sink_count() in
intel_dp_detect_dpcd(), which is a functional change.

Signed-off-by: Lyude Paul 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/drm_dp_helper.c | 22 ++
 drivers/gpu/drm/i915/display/intel_dp.c | 21 -
 include/drm/drm_dp_helper.h |  8 +++-
 3 files changed, 41 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4f845995f1f66..863e0babc1903 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -714,6 +714,28 @@ void drm_dp_set_subconnector_property(struct drm_connector 
*connector,
 }
 EXPORT_SYMBOL(drm_dp_set_subconnector_property);
 
+/**
+ * drm_dp_has_sink_count() - Check whether a given connector has a valid sink
+ * count
+ * @connector: The DRM connector to check
+ * @dpcd: A cached copy of the connector's DPCD RX capabilities
+ * @desc: A cached copy of the connector's DP descriptor
+ *
+ * Returns: %True if the (e)DP connector has a valid sink count that should
+ * be probed, %false otherwise.
+ */
+bool drm_dp_has_sink_count(struct drm_connector *connector,
+  const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+  const struct drm_dp_desc *desc)
+{
+   /* Some eDP panels don't set a valid value for the sink count */
+   return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
+   dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
+   dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
+   !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+}
+EXPORT_SYMBOL(drm_dp_has_sink_count);
+
 /*
  * I2C-over-AUX implementation
  */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 984e49194ca31..35a4779a442e2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4634,6 +4634,16 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
return true;
 }
 
+static bool
+intel_dp_has_sink_count(struct intel_dp *intel_dp)
+{
+   if (!intel_dp->attached_connector)
+   return false;
+
+   return drm_dp_has_sink_count(&intel_dp->attached_connector->base,
+intel_dp->dpcd,
+&intel_dp->desc);
+}
 
 static bool
 intel_dp_get_dpcd(struct intel_dp *intel_dp)
@@ -4653,13 +4663,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
intel_dp_set_common_rates(intel_dp);
}
 
-   /*
-* Some eDP panels do not set a valid value for sink count, that is why
-* it don't care about read it here and in intel_edp_init_dpcd().
-*/
-   if (!intel_dp_is_edp(intel_dp) &&
-   !drm_dp_has_quirk(&intel_dp->desc, 0,
- DP_DPCD_QUIRK_NO_SINK_COUNT)) {
+   if (intel_dp_has_sink_count(intel_dp)) {
u8 count;
ssize_t r;
 
@@ -5939,9 +5943,8 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
return connector_status_connected;
 
/* If we're HPD-aware, SINK_COUNT changes dynamically */
-   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
+   if (intel_dp_has_sink_count(intel_dp) &&
intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
-
return intel_dp->sink_count ?
connector_status_connected : connector_status_disconnected;
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1349f16564ace..a1413a531eaf4 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1631,6 +1631,11 @@ void drm_dp_set_subconnector_property(struct 
drm_connector *connector,
  const u8 *dpcd,
  const u8 port_cap[4]);
 
+struct drm_dp_desc;
+bool drm_dp_has_sink_count(struct drm_connector *connector,
+  const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+  const struct drm_dp_desc *desc);
+
 void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
 void drm_dp_aux_init(struct drm_dp_aux *aux);
 int drm_dp_aux_register(struct drm_dp_aux *aux);
@@ -1689,7 +1694,8 @@ enum drm_dp_quirk {
 * @DP_DPCD_QUIRK_NO_SINK_COUNT:
 *
 * The device does not set SINK_COUNT to a non-zero value.
-* The driver should ignore SINK_COUNT during detection.
+* The driver should ignore SINK_COUNT during detection. Note that
+* drm_dp_has_sink_count() automatically checks for this quirk.
 */
DP_DPCD_QUIRK_NO_SINK_COUNT,
/**
-- 
2.26.2

___

[Intel-gfx] [RFC v4 12/20] drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths

2020-08-25 Thread Lyude Paul
Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a connector hotplug happens to occur in parallel
with a modeset.

I haven't seen this actually happen yet, but since we're cleaning up
nouveau's hotplug handling code anyway and we already have a hpd worker,
we can simply fix this by only relying on the HPD worker to actually
reprobe connectors when we receive a HPD IRQ. We also add a mask to
nouveau_drm to keep track of which connectors are waiting to be reprobed
in response to an HPD IRQ.

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 42 +
 drivers/gpu/drm/nouveau/nouveau_connector.h |  1 +
 drivers/gpu/drm/nouveau/nouveau_display.c   | 70 ++---
 drivers/gpu/drm/nouveau/nouveau_display.h   |  1 +
 drivers/gpu/drm/nouveau/nouveau_dp.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  4 +-
 drivers/gpu/drm/nouveau/nouveau_drv.h   |  2 +
 7 files changed, 86 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 4a29f691c08e4..637e91594fbe8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1138,6 +1138,20 @@ nouveau_connector_funcs_lvds = {
.early_unregister = nouveau_connector_early_unregister,
 };
 
+void
+nouveau_connector_hpd(struct drm_connector *connector)
+{
+   struct nouveau_drm *drm = nouveau_drm(connector->dev);
+   u32 mask = drm_connector_mask(connector);
+
+   mutex_lock(&drm->hpd_lock);
+   if (!(drm->hpd_pending & mask)) {
+   drm->hpd_pending |= mask;
+   schedule_work(&drm->hpd_work);
+   }
+   mutex_unlock(&drm->hpd_lock);
+}
+
 static int
 nouveau_connector_hotplug(struct nvif_notify *notify)
 {
@@ -1147,8 +1161,6 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
struct drm_device *dev = connector->dev;
struct nouveau_drm *drm = nouveau_drm(dev);
const struct nvif_notify_conn_rep_v0 *rep = notify->data;
-   const char *name = connector->name;
-   int ret;
bool plugged = (rep->mask != NVIF_NOTIFY_CONN_V0_UNPLUG);
 
if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) {
@@ -1156,31 +1168,9 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
return NVIF_NOTIFY_KEEP;
}
 
-   ret = pm_runtime_get(drm->dev->dev);
-   if (ret == 0) {
-   /* We can't block here if there's a pending PM request
-* running, as we'll deadlock nouveau_display_fini() when it
-* calls nvif_put() on our nvif_notify struct. So, simply
-* defer the hotplug event until the device finishes resuming
-*/
-   NV_DEBUG(drm, "Deferring HPD on %s until runtime resume\n",
-name);
-   schedule_work(&drm->hpd_work);
-
-   pm_runtime_put_noidle(drm->dev->dev);
-   return NVIF_NOTIFY_KEEP;
-   } else if (ret != 1 && ret != -EACCES) {
-   NV_WARN(drm, "HPD on %s dropped due to RPM failure: %d\n",
-   name, ret);
-   return NVIF_NOTIFY_DROP;
-   }
-
-   NV_DEBUG(drm, "%splugged %s\n", plugged ? "" : "un", name);
-
-   drm_helper_hpd_irq_event(connector->dev);
+   NV_DEBUG(drm, "%splugged %s\n", plugged ? "" : "un", connector->name);
+   nouveau_connector_hpd(connector);
 
-   pm_runtime_mark_last_busy(drm->dev->dev);
-   pm_runtime_put_autosuspend(drm->dev->dev);
return NVIF_NOTIFY_KEEP;
 }
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h 
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index d6de5cb8e2238..d0b859c4a80ea 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -187,6 +187,7 @@ nouveau_crtc_connector_get(struct nouveau_crtc *nv_crtc)
 
 struct drm_connector *
 nouveau_connector_create(struct drm_device *, const struct dcb_output *);
+void nouveau_connector_hpd(struct drm_connector *connector);
 
 extern int nouveau_tv_disable;
 extern int nouveau_ignorelid;
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 13016769a194b..bceb48a2dfca6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -457,16 +457,70 @@ static struct nouveau_drm_prop_enum_list dither_depth[] = 
{
}  \
 } while(0)
 
+void
+nouveau_display_hpd_resume(struct drm_device *dev)
+{
+   struct nouveau_drm *drm = nouveau_drm(dev);
+
+   mutex_lock(&drm->hpd_lock);
+   

[Intel-gfx] [RFC v4 13/20] drm/i915/dp: Extract drm_dp_downstream_read_info()

2020-08-25 Thread Lyude Paul
We're going to be doing the same probing process in nouveau for
determining downstream DP port capabilities, so let's deduplicate the
work by moving i915's code for handling this into a shared helper:
drm_dp_downstream_read_info().

Note that when we do this, we also do make some functional changes while
we're at it:
* We always clear the downstream port info before trying to read it,
  just to make things easier for the caller
* We skip reading downstream port info if the DPCD indicates that we
  don't support downstream port info
* We only read as many bytes as needed for the reported number of
  downstream ports, no sense in reading the whole thing every time

v2:
* Fixup logic for calculating the downstream port length to account for
  the fact that downstream port caps can be either 1 byte or 4 bytes
  long. We can actually skip fixing the max_clock/max_bpc helpers here
  since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway.
* Fix ret code check for drm_dp_dpcd_read

Reviewed-by: Sean Paul 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_helper.c | 46 +
 drivers/gpu/drm/i915/display/intel_dp.c | 14 ++--
 include/drm/drm_dp_helper.h |  3 ++
 3 files changed, 51 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4c21cf69dad5a..4f845995f1f66 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -423,6 +423,52 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
 }
 EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
 
+static u8 drm_dp_downstream_port_count(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   u8 port_count = dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_PORT_COUNT_MASK;
+
+   if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE && 
port_count > 4)
+   port_count = 4;
+
+   return port_count;
+}
+
+/**
+ * drm_dp_downstream_read_info() - read DPCD downstream port info if available
+ * @aux: DisplayPort AUX channel
+ * @dpcd: A cached copy of the port's DPCD
+ * @downstream_ports: buffer to store the downstream port info in
+ *
+ * Returns: 0 if either the downstream port info was read successfully or
+ * there was no downstream info to read, or a negative error code otherwise.
+ */
+int drm_dp_downstream_read_info(struct drm_dp_aux *aux,
+   const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+   u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS])
+{
+   int ret;
+   u8 len;
+
+   memset(downstream_ports, 0, DP_MAX_DOWNSTREAM_PORTS);
+
+   /* No downstream info to read */
+   if (!drm_dp_is_branch(dpcd) ||
+   dpcd[DP_DPCD_REV] < DP_DPCD_REV_10 ||
+   !(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
+   return 0;
+
+   len = drm_dp_downstream_port_count(dpcd);
+   if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE)
+   len *= 4;
+
+   ret = drm_dp_dpcd_read(aux, DP_DOWNSTREAM_PORT_0, downstream_ports, 
len);
+   if (ret < 0)
+   return ret;
+
+   return ret == len ? 0 : -EIO;
+}
+EXPORT_SYMBOL(drm_dp_downstream_read_info);
+
 /**
  * drm_dp_downstream_max_clock() - extract branch device max
  * pixel rate for legacy VGA
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1e29d3a012856..984e49194ca31 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4685,18 +4685,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
return false;
}
 
-   if (!drm_dp_is_branch(intel_dp->dpcd))
-   return true; /* native DP sink */
-
-   if (intel_dp->dpcd[DP_DPCD_REV] == 0x10)
-   return true; /* no per-port downstream info */
-
-   if (drm_dp_dpcd_read(&intel_dp->aux, DP_DOWNSTREAM_PORT_0,
-intel_dp->downstream_ports,
-DP_MAX_DOWNSTREAM_PORTS) < 0)
-   return false; /* downstream port status fetch failed */
-
-   return true;
+   return drm_dp_downstream_read_info(&intel_dp->aux, intel_dp->dpcd,
+  intel_dp->downstream_ports) == 0;
 }
 
 static bool
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 5c28199248626..1349f16564ace 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1613,6 +1613,9 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
 bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
u8 real_edid_checksum);
 
+int drm_dp_downstream_read_info(struct drm_dp_aux *aux,
+   const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+   u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS]);
 int drm_dp_downstream_max_cl

[Intel-gfx] [RFC v4 05/20] drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new()

2020-08-25 Thread Lyude Paul
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
enabling") we've been clearing DP_MST_CTRL before we start enabling MST.
Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary
and redundant, so let's remove it.

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index e7874877da858..c4d138f0ca054 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1535,17 +1535,6 @@ nv50_mstm_new(struct nouveau_encoder *outp, struct 
drm_dp_aux *aux, int aux_max,
struct drm_device *dev = outp->base.base.dev;
struct nv50_mstm *mstm;
int ret;
-   u8 dpcd;
-
-   /* This is a workaround for some monitors not functioning
-* correctly in MST mode on initial module load.  I think
-* some bad interaction with the VBIOS may be responsible.
-*
-* A good ol' off and on again seems to work here ;)
-*/
-   ret = drm_dp_dpcd_readb(aux, DP_DPCD_REV, &dpcd);
-   if (ret >= 0 && dpcd >= 0x12)
-   drm_dp_dpcd_writeb(aux, DP_MSTM_CTRL, 0);
 
if (!(mstm = *pmstm = kzalloc(sizeof(*mstm), GFP_KERNEL)))
return -ENOMEM;
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC v4 08/20] drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling

2020-08-25 Thread Lyude Paul
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.

Back when I originally wrote this, I did this piggy-backing with the
intention that I'd eventually be teaching our MST helpers how to recover
when an MST device has stopped responding, which in turn would require
the MST helpers having a way of disabling MST independently of the
driver. Note that this was before I reworked locking in the MST helpers,
so at the time we were sticking random things under &mgr->lock - which
grabbing this lock was meant to protect against.

This never came to fruition because doing such a reset safely turned out
to be a lot more painful and impossible then it sounds, and also just
risks us working around issues with our MST handlers that should be
properly fixed instead. Even if it did though, simply calling
drm_dp_mst_topology_mgr_set_mst() from the MST helpers (with the
exception of when we're tearing down our MST managers, that's always OK)
wouldn't have been a bad idea, since drivers like nouveau and i915 need
to do their own book keeping immediately after disabling MST.
So-implementing that would likely require adding a hook for
helper-triggered MST disables anyway.

So, fast forward to now - we want to start adding support for all of the
miscellaneous bits of the DP protocol (for both SST and MST) we're
missing before moving on to supporting more complicated features like
supporting different BPP values on MST, DSC, etc. Since many of these
features only exist on SST and make use of DP HPD IRQs, we want to be
able to atomically check whether we're servicing an MST IRQ or SST IRQ
in nouveau_connector_hotplug(). Currently we literally don't do this at
all, and just handle any kind of possible DP IRQ we could get including
ESIs - even if MST isn't actually enabled.

This would be very complicated and difficult to fix if we need to hold
&mgr->lock while handling SST IRQs to ensure that the MST topology
state doesn't change under us. What we really want here is to do our own
tracking of whether MST is enabled or not, similar to drivers like i915,
and define our own locking order to decomplicate things and avoid
hitting locking issues in the future.

So, let's do this by refactoring our MST probing/enabling code to use
our own MST bookkeeping, along with adding a lock for protecting DP
state that needs to be checked outside of our connector probing
functions. While we're at it, we also remove a bunch of unneeded steps
we perform when probing/enabling MST:

* Enabling bits in MSTM_CTRL before calling drm_dp_mst_topology_mgr_set_mst().
  I don't think these ever actually did anything, since the nvif methods
  for enabling MST don't actually do anything DPCD related and merely
  indicate to nvkm that we've turned on MST.
* Checking the MSTM_CTRL bit is intact when checking the state of an
  enabled MST topology in nv50_mstm_detect(). I just added this to be safe
  originally, but now that we try reading the DPCD when probing DP
  connectors it shouldn't be needed as that will abort our hotplug probing
  if the device was removed well before we start checking for MST..
* All of the duplicate DPCD version checks.

This leaves us with much nicer looking code, a much more sensible
locking scheme, and an easy way of checking whether MST is enabled or
not for handling DP HPD IRQs.

v2:
* Get rid of accidental newlines
v4:
* Fix uninitialized usage of mstm in nv50_mstm_detect() - thanks kernel
  bot!

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/dispnv04/disp.c |   6 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 192 +---
 drivers/gpu/drm/nouveau/nouveau_connector.c |  14 +-
 drivers/gpu/drm/nouveau/nouveau_display.c   |   2 +-
 drivers/gpu/drm/nouveau/nouveau_display.h   |   2 +-
 drivers/gpu/drm/nouveau/nouveau_dp.c| 132 --
 drivers/gpu/drm/nouveau/nouveau_encoder.h   |  33 +++-
 7 files changed, 244 insertions(+), 137 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 3f046b917c85c..3ee836dc5058f 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -54,8 +54,9 @@ nv04_encoder_get_connector(struct nouveau_encoder *encoder)
 }
 
 static void
-nv04_display_fini(struct drm_device *dev, bool suspend)
+nv04_display_fini(struct drm_device *dev, bool runtime, bool suspend)
 {
+   struct nouveau_drm *drm = nouveau_drm(dev);
struct nv04_display *disp = nv04_display(dev);
struct drm_crtc *crtc;
 
@@ -67,6 +68,9 @@ nv04_display_fini(struct drm_device *dev, bool suspend)
if (nv_two_heads(dev))
NVWriteCRTC(dev, 1, NV_PCRTC_INTR_EN_0, 0);
 
+   if (!runtime)
+   cancel_work_sync(&drm->hpd_work);

[Intel-gfx] [RFC v4 06/20] drm/nouveau/kms: Search for encoders' connectors properly

2020-08-25 Thread Lyude Paul
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.

Fix this by removing nouveau_encoder_connector_get(), and replacing it
with nv04_encoder_get_connector(), nv50_outp_get_old_connector(), and
nv50_outp_get_new_connector().

v2:
* Don't line-wrap for_each_(old|new)_connector_in_state in
  nv50_outp_get_(old|new)_connector() - sravn
v3:
* Fix potential uninitialized usage of nv_connector (needs to be
  initialized to NULL at the start). Thanks kernel test robot!
v4:
* Actually fix uninitialized nv_connector usage in
  nv50_audio_component_get_eld(). The previous fix wouldn't have worked
  since we would have started out with nv_connector == NULL, but
  wouldn't clear it after a single drm_for_each_encoder() iteration.
  Thanks again Kernel bot!

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/dispnv04/dac.c  |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/dfp.c  |  7 +-
 drivers/gpu/drm/nouveau/dispnv04/disp.c | 18 +
 drivers/gpu/drm/nouveau/dispnv04/disp.h |  4 +
 drivers/gpu/drm/nouveau/dispnv04/tvnv04.c   |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c   |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 88 +
 drivers/gpu/drm/nouveau/nouveau_connector.c | 14 
 drivers/gpu/drm/nouveau/nouveau_encoder.h   |  6 +-
 9 files changed, 105 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/dac.c 
b/drivers/gpu/drm/nouveau/dispnv04/dac.c
index ffdd447d87068..22d10f3285597 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dac.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dac.c
@@ -419,7 +419,7 @@ static void nv04_dac_commit(struct drm_encoder *encoder)
helper->dpms(encoder, DRM_MODE_DPMS_ON);
 
NV_DEBUG(drm, "Output %s is running on CRTC %d using output %c\n",
-nouveau_encoder_connector_get(nv_encoder)->base.name,
+nv04_encoder_get_connector(nv_encoder)->base.name,
 nv_crtc->index, '@' + ffs(nv_encoder->dcb->or));
 }
 
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c 
b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index f9f4482c79b54..42687ea2a4ca3 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -184,7 +184,8 @@ static bool nv04_dfp_mode_fixup(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
-   struct nouveau_connector *nv_connector = 
nouveau_encoder_connector_get(nv_encoder);
+   struct nouveau_connector *nv_connector =
+   nv04_encoder_get_connector(nv_encoder);
 
if (!nv_connector->native_mode ||
nv_connector->scaling_mode == DRM_MODE_SCALE_NONE ||
@@ -478,7 +479,7 @@ static void nv04_dfp_commit(struct drm_encoder *encoder)
helper->dpms(encoder, DRM_MODE_DPMS_ON);
 
NV_DEBUG(drm, "Output %s is running on CRTC %d using output %c\n",
-nouveau_encoder_connector_get(nv_encoder)->base.name,
+nv04_encoder_get_connector(nv_encoder)->base.name,
 nv_crtc->index, '@' + ffs(nv_encoder->dcb->or));
 }
 
@@ -591,7 +592,7 @@ static void nv04_dfp_restore(struct drm_encoder *encoder)
 
if (nv_encoder->dcb->type == DCB_OUTPUT_LVDS) {
struct nouveau_connector *connector =
-   nouveau_encoder_connector_get(nv_encoder);
+   nv04_encoder_get_connector(nv_encoder);
 
if (connector && connector->native_mode)
call_lvds_script(dev, nv_encoder->dcb, head,
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 900ab69df7e8f..3f046b917c85c 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -35,6 +35,24 @@
 
 #include 
 
+struct nouveau_connector *
+nv04_encoder_get_connector(struct nouveau_encoder *encoder)
+{
+   struct drm_device *dev = to_drm_encoder(encoder)->dev;
+   struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
+   struct nouveau_connector *nv_connector = NULL;
+
+   drm_connector_list_iter_begin(dev, &conn_iter);
+   drm_for_each_connector_iter(connector, &conn_iter) {
+   if (connector->encoder == to_drm_encoder(encoder))
+   nv_connector = nouveau_connector(connector);
+   }
+   drm_connector_list_iter_end(&conn_iter);
+
+   return nv_connector;
+}
+
 static void
 nv04_display_fini(struct drm_device *dev, bool suspend)
 {
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.h 
b/drivers/gpu/drm/nouveau/dispnv04/disp.h
index 495d3284e8766..5ace5e906949a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.h
@@

[Intel-gfx] [RFC v4 07/20] drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in nv50_sor_disable()

2020-08-25 Thread Lyude Paul
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 255a281249bc8..612d98fa0a2dc 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1630,19 +1630,22 @@ nv50_sor_disable(struct drm_encoder *encoder,
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
+   struct nouveau_connector *nv_connector =
+   nv50_outp_get_old_connector(nv_encoder, state);
 
nv_encoder->crtc = NULL;
 
if (nv_crtc) {
-   struct nvkm_i2c_aux *aux = nv_encoder->aux;
+   struct drm_dp_aux *aux = &nv_connector->aux;
u8 pwr;
 
-   if (aux) {
-   int ret = nvkm_rdaux(aux, DP_SET_POWER, &pwr, 1);
+   if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
+   int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
+
if (ret == 0) {
pwr &= ~DP_SET_POWER_MASK;
pwr |=  DP_SET_POWER_D3;
-   nvkm_wraux(aux, DP_SET_POWER, &pwr, 1);
+   drm_dp_dpcd_writeb(aux, DP_SET_POWER, pwr);
}
}
 
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC v4 11/20] drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect()

2020-08-25 Thread Lyude Paul
For whatever reason we currently unset the EDID for DP CEC support when
responding to the connector being unplugged, instead of just doing it in
nouveau_connector_detect() where we set the CEC EDID. This isn't really
needed and could even potentially cause us to forget to unset the EDID
if the connector is removed without a corresponding hpd event, so let's
fix that.

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index b90591114faaf..4a29f691c08e4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -633,10 +633,11 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
conn_status = connector_status_connected;
goto out;
}
-
}
 
  out:
+   if (!nv_connector->edid)
+   drm_dp_cec_unset_edid(&nv_connector->aux);
 
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
@@ -1174,8 +1175,6 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
return NVIF_NOTIFY_DROP;
}
 
-   if (!plugged)
-   drm_dp_cec_unset_edid(&nv_connector->aux);
NV_DEBUG(drm, "%splugged %s\n", plugged ? "" : "un", name);
 
drm_helper_hpd_irq_event(connector->dev);
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC v4 16/20] drm/i915/dp: Extract drm_dp_get_sink_count()

2020-08-25 Thread Lyude Paul
And of course, we'll also need to read the sink count from other drivers
as well if we're checking whether or not it's supported. So, let's
extract the code for this into another helper.

v2:
* Fix drm_dp_dpcd_readb() ret check
* Add back comment and move back sink_count assignment in intel_dp_get_dpcd()

Signed-off-by: Lyude Paul 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/drm_dp_helper.c | 22 ++
 drivers/gpu/drm/i915/display/intel_dp.c | 11 +--
 include/drm/drm_dp_helper.h |  1 +
 3 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 863e0babc1903..67ad05eb05b7e 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -736,6 +736,28 @@ bool drm_dp_has_sink_count(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_dp_has_sink_count);
 
+/**
+ * drm_dp_get_sink_count() - Retrieve the sink count for a given sink
+ * @aux: The DP AUX channel to use
+ *
+ * Returns: The current sink count reported by @aux, or a negative error code
+ * otherwise.
+ */
+int drm_dp_get_sink_count(struct drm_dp_aux *aux)
+{
+   u8 count;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_SINK_COUNT, &count);
+   if (ret < 0)
+   return ret;
+   if (ret != 1)
+   return -EIO;
+
+   return DP_GET_SINK_COUNT(count);
+}
+EXPORT_SYMBOL(drm_dp_get_sink_count);
+
 /*
  * I2C-over-AUX implementation
  */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 35a4779a442e2..4337321a3be4f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4648,6 +4648,8 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
 static bool
 intel_dp_get_dpcd(struct intel_dp *intel_dp)
 {
+   int ret;
+
if (!intel_dp_read_dpcd(intel_dp))
return false;
 
@@ -4664,11 +4666,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
}
 
if (intel_dp_has_sink_count(intel_dp)) {
-   u8 count;
-   ssize_t r;
-
-   r = drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_COUNT, &count);
-   if (r < 1)
+   ret = drm_dp_get_sink_count(&intel_dp->aux);
+   if (ret < 0)
return false;
 
/*
@@ -4676,7 +4675,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
 * a member variable in intel_dp will track any changes
 * between short pulse interrupts.
 */
-   intel_dp->sink_count = DP_GET_SINK_COUNT(count);
+   intel_dp->sink_count = ret;
 
/*
 * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index a1413a531eaf4..0c141fc81aaa8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1635,6 +1635,7 @@ struct drm_dp_desc;
 bool drm_dp_has_sink_count(struct drm_connector *connector,
   const u8 dpcd[DP_RECEIVER_CAP_SIZE],
   const struct drm_dp_desc *desc);
+int drm_dp_get_sink_count(struct drm_dp_aux *aux);
 
 void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
 void drm_dp_aux_init(struct drm_dp_aux *aux);
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC v4 19/20] drm/i915/dp: Extract drm_dp_read_dpcd_caps()

2020-08-25 Thread Lyude Paul
Since DP 1.3, it's been possible for DP receivers to specify an
additional set of DPCD capabilities, which can take precedence over the
capabilities reported at DP_DPCD_REV.

Basically any device supporting DP is going to need to read these in an
identical manner, in particular nouveau, so let's go ahead and just move
this code out of i915 into a shared DRM DP helper that we can use in
other drivers.

v2:
* Remove redundant dpcd[DP_DPCD_REV] == 0 check
* Fix drm_dp_dpcd_read() ret checks

Signed-off-by: Lyude Paul 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/drm_dp_helper.c | 77 +
 drivers/gpu/drm/i915/display/intel_dp.c | 60 +---
 drivers/gpu/drm/i915/display/intel_dp.h |  1 -
 drivers/gpu/drm/i915/display/intel_lspcon.c |  2 +-
 include/drm/drm_dp_helper.h |  3 +
 5 files changed, 83 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 67ad05eb05b7e..9c99d21b42c15 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -433,6 +433,83 @@ static u8 drm_dp_downstream_port_count(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
return port_count;
 }
 
+static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
+ u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   u8 dpcd_ext[6];
+   int ret;
+
+   /*
+* Prior to DP1.3 the bit represented by
+* DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
+* If it is set DP_DPCD_REV at h could be at a value less than
+* the true capability of the panel. The only way to check is to
+* then compare h and 2200h.
+*/
+   if (!(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT))
+   return 0;
+
+   ret = drm_dp_dpcd_read(aux, DP_DP13_DPCD_REV, &dpcd_ext,
+  sizeof(dpcd_ext));
+   if (ret < 0)
+   return ret;
+   if (ret != sizeof(dpcd_ext))
+   return -EIO;
+
+   if (dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV]) {
+   DRM_DEBUG_KMS("%s: Extended DPCD rev less than base DPCD rev 
(%d > %d)\n",
+ aux->name, dpcd[DP_DPCD_REV],
+ dpcd_ext[DP_DPCD_REV]);
+   return 0;
+   }
+
+   if (!memcmp(dpcd, dpcd_ext, sizeof(dpcd_ext)))
+   return 0;
+
+   DRM_DEBUG_KMS("%s: Base DPCD: %*ph\n",
+ aux->name, DP_RECEIVER_CAP_SIZE, dpcd);
+
+   memcpy(dpcd, dpcd_ext, sizeof(dpcd_ext));
+
+   return 0;
+}
+
+/**
+ * drm_dp_read_dpcd_caps() - read DPCD caps and extended DPCD caps if
+ * available
+ * @aux: DisplayPort AUX channel
+ * @dpcd: Buffer to store the resulting DPCD in
+ *
+ * Attempts to read the base DPCD caps for @aux. Additionally, this function
+ * checks for and reads the extended DPRX caps (%DP_DP13_DPCD_REV) if
+ * present.
+ *
+ * Returns: %0 if the DPCD was read successfully, negative error code
+ * otherwise.
+ */
+int drm_dp_read_dpcd_caps(struct drm_dp_aux *aux,
+ u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   int ret;
+
+   ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
+   if (ret < 0)
+   return ret;
+   if (ret != DP_RECEIVER_CAP_SIZE || dpcd[DP_DPCD_REV] == 0)
+   return -EIO;
+
+   ret = drm_dp_read_extended_dpcd_caps(aux, dpcd);
+   if (ret < 0)
+   return ret;
+
+   DRM_DEBUG_KMS("%s: DPCD: %*ph\n",
+ aux->name, DP_RECEIVER_CAP_SIZE, dpcd);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_dp_read_dpcd_caps);
+
 /**
  * drm_dp_downstream_read_info() - read DPCD downstream port info if available
  * @aux: DisplayPort AUX channel
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4337321a3be4f..fb7872e2a0b93 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4449,62 +4449,6 @@ intel_dp_link_down(struct intel_encoder *encoder,
}
 }
 
-static void
-intel_dp_extended_receiver_capabilities(struct intel_dp *intel_dp)
-{
-   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
-   u8 dpcd_ext[6];
-
-   /*
-* Prior to DP1.3 the bit represented by
-* DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
-* if it is set DP_DPCD_REV at h could be at a value less than
-* the true capability of the panel. The only way to check is to
-* then compare h and 2200h.
-*/
-   if (!(intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
- DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT))
-   return;
-
-   if (drm_dp_dpcd_read(&intel_dp->aux, DP_DP13_DPCD_REV,
-&dpcd_ext, sizeof(dpcd_ext)) != sizeof(dpcd_ext)) {
-   drm_err(&i915->drm,
- 

[Intel-gfx] [RFC v4 10/20] drm/nouveau/kms: Use new drm_dp_has_mst() helper for checking MST caps

2020-08-25 Thread Lyude Paul
Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 032afc73e2a33..201c0b4335563 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -44,7 +44,6 @@ nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
struct nv50_mstm *mstm = NULL;
int ret;
u8 *dpcd = outp->dp.dpcd;
-   u8 tmp;
 
ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
if (ret == DP_RECEIVER_CAP_SIZE && dpcd[DP_DPCD_REV]) {
@@ -56,19 +55,10 @@ nouveau_dp_probe_dpcd(struct nouveau_connector 
*nv_connector,
return connector_status_disconnected;
}
 
-   if (nouveau_mst)
+   if (nouveau_mst) {
mstm = outp->dp.mstm;
-
-   if (mstm) {
-   if (dpcd[DP_DPCD_REV] >= DP_DPCD_REV_12) {
-   ret = drm_dp_dpcd_readb(aux, DP_MSTM_CAP, &tmp);
-   if (ret < 0)
-   return connector_status_disconnected;
-
-   mstm->can_mst = !!(tmp & DP_MST_CAP);
-   } else {
-   mstm->can_mst = false;
-   }
+   if (mstm)
+   mstm->can_mst = drm_dp_has_mst(aux, dpcd);
}
 
return connector_status_connected;
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC v4 20/20] drm/nouveau/kms: Start using drm_dp_read_dpcd_caps()

2020-08-25 Thread Lyude Paul
Now that we've extracted i915's code for reading both the normal DPCD
caps and extended DPCD caps into a shared helper, let's start using this
in nouveau to enable us to start checking extended DPCD caps for free.

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nouveau_dp.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 89afc97ee2591..271a0a863a0e1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -55,15 +55,13 @@ nouveau_dp_probe_dpcd(struct nouveau_connector 
*nv_connector,
int ret;
u8 *dpcd = outp->dp.dpcd;
 
-   ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
-   if (ret == DP_RECEIVER_CAP_SIZE && dpcd[DP_DPCD_REV]) {
-   ret = drm_dp_read_desc(aux, &outp->dp.desc,
-  drm_dp_is_branch(dpcd));
-   if (ret < 0)
-   goto out;
-   } else {
+   ret = drm_dp_read_dpcd_caps(aux, dpcd);
+   if (ret < 0)
+   goto out;
+
+   ret = drm_dp_read_desc(aux, &outp->dp.desc, drm_dp_is_branch(dpcd));
+   if (ret < 0)
goto out;
-   }
 
if (nouveau_mst) {
mstm = outp->dp.mstm;
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC v4 18/20] drm/nouveau/kms: Don't change EDID when it hasn't actually changed

2020-08-25 Thread Lyude Paul
Currently in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds(), we start the connector probing process
by releasing the previous EDID and informing DRM of the change. However,
since commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") drm_connector_update_edid_property() actually checks
whether the new EDID we've specified is different from the previous one,
and updates the connector's epoch accordingly if it is. But, because we
always set the EDID to NULL first in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds() we end up making DRM think that the EDID
changes every single time we do a connector probe - which isn't needed.

So, let's fix this by not clearing the EDID at the start of the
connector probing process, and instead simply changing or removing it
once near the end of the probing process. This will help prevent us from
sending unneeded hotplug events to userspace when nothing has actually
changed.

Signed-off-by: Lyude Paul 
Reviewed-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 54 ++---
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 637e91594fbe8..49dd0cbc332ff 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -528,6 +528,17 @@ nouveau_connector_set_encoder(struct drm_connector 
*connector,
}
 }
 
+static void
+nouveau_connector_set_edid(struct nouveau_connector *nv_connector,
+  struct edid *edid)
+{
+   struct edid *old_edid = nv_connector->edid;
+
+   drm_connector_update_edid_property(&nv_connector->base, edid);
+   kfree(old_edid);
+   nv_connector->edid = edid;
+}
+
 static enum drm_connector_status
 nouveau_connector_detect(struct drm_connector *connector, bool force)
 {
@@ -541,13 +552,6 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
int ret;
enum drm_connector_status conn_status = connector_status_disconnected;
 
-   /* Cleanup the previous EDID block. */
-   if (nv_connector->edid) {
-   drm_connector_update_edid_property(connector, NULL);
-   kfree(nv_connector->edid);
-   nv_connector->edid = NULL;
-   }
-
/* Outputs are only polled while runtime active, so resuming the
 * device here is unnecessary (and would deadlock upon runtime suspend
 * because it waits for polling to finish). We do however, want to
@@ -560,22 +564,23 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
ret = pm_runtime_get_sync(dev->dev);
if (ret < 0 && ret != -EACCES) {
pm_runtime_put_autosuspend(dev->dev);
+   nouveau_connector_set_edid(nv_connector, NULL);
return conn_status;
}
}
 
nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
+   struct edid *new_edid;
+
if ((vga_switcheroo_handler_flags() &
 VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
nv_connector->type == DCB_CONNECTOR_LVDS)
-   nv_connector->edid = drm_get_edid_switcheroo(connector,
-i2c);
+   new_edid = drm_get_edid_switcheroo(connector, i2c);
else
-   nv_connector->edid = drm_get_edid(connector, i2c);
+   new_edid = drm_get_edid(connector, i2c);
 
-   drm_connector_update_edid_property(connector,
-   nv_connector->edid);
+   nouveau_connector_set_edid(nv_connector, new_edid);
if (!nv_connector->edid) {
NV_ERROR(drm, "DDC responded, but no EDID for %s\n",
 connector->name);
@@ -609,6 +614,8 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
conn_status = connector_status_connected;
drm_dp_cec_set_edid(&nv_connector->aux, nv_connector->edid);
goto out;
+   } else {
+   nouveau_connector_set_edid(nv_connector, NULL);
}
 
nv_encoder = nouveau_connector_of_detect(connector);
@@ -652,18 +659,12 @@ nouveau_connector_detect_lvds(struct drm_connector 
*connector, bool force)
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_encoder *nv_encoder = NULL;
+   struct edid *edid = NULL;
enum drm_connector_status status = connector_status_disconnected;
 
-   /* Cleanup the previous EDID block. */
-   if (nv_connector->edid) {
-   drm_

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev6)

2020-08-25 Thread Patchwork
== Series Details ==

Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from 
i915 (rev6)
URL   : https://patchwork.freedesktop.org/series/80542/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
eb602825d26c drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

total: 0 errors, 1 warnings, 0 checks, 21 lines checked
72930d9382f6 drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc()
-:102: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct 
nouveau_connector *' should also have an identifier name
#102: FILE: drivers/gpu/drm/nouveau/nouveau_encoder.h:109:
+int nouveau_dp_detect(struct nouveau_connector *, struct nouveau_encoder *);

-:102: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct 
nouveau_encoder *' should also have an identifier name
#102: FILE: drivers/gpu/drm/nouveau/nouveau_encoder.h:109:
+int nouveau_dp_detect(struct nouveau_connector *, struct nouveau_encoder *);

total: 0 errors, 2 warnings, 0 checks, 74 lines checked
8759e1743599 drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c
e43e30c39e26 drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c
8f3b7f3b21f2 drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new()
-:7: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit fa3cdf8d0b09 ("drm/nouveau: 
Reset MST branching unit before enabling")'
#7: 
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before

total: 1 errors, 0 warnings, 0 checks, 17 lines checked
8f57184d747b drm/nouveau/kms: Search for encoders' connectors properly
09f88a09f081 drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in 
nv50_sor_disable()
7a508e1c0b76 drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling
-:53: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#53: 
* Enabling bits in MSTM_CTRL before calling drm_dp_mst_topology_mgr_set_mst().

-:465: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct 
drm_device *' should also have an identifier name
#465: FILE: drivers/gpu/drm/nouveau/nouveau_display.h:21:
+   void (*fini)(struct drm_device *, bool suspend, bool runtime);

total: 0 errors, 2 warnings, 0 checks, 574 lines checked
fd0c71a5229b drm/i915/dp: Extract drm_dp_has_mst()
fc79d4524d15 drm/nouveau/kms: Use new drm_dp_has_mst() helper for checking MST 
caps
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

total: 0 errors, 1 warnings, 0 checks, 29 lines checked
a6246286cc09 drm/nouveau/kms: Move drm_dp_cec_unset_edid() into 
nouveau_connector_detect()
a122aee25a76 drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths
-:279: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment
#279: FILE: drivers/gpu/drm/nouveau/nouveau_drv.h:201:
+   struct mutex hpd_lock;

total: 0 errors, 0 warnings, 1 checks, 219 lines checked
41fcfb67337b drm/i915/dp: Extract drm_dp_downstream_read_info()
cca56ef60b60 drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode 
validation
-:63: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#63: FILE: drivers/gpu/drm/nouveau/nouveau_dp.c:194:
+   unsigned max_clock, ds_clock, clock;

total: 0 errors, 1 warnings, 0 checks, 57 lines checked
31c957b672ab drm/i915/dp: Extract drm_dp_has_sink_count()
05083fd03635 drm/i915/dp: Extract drm_dp_get_sink_count()
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#12: 
* Add back comment and move back sink_count assignment in intel_dp_get_dpcd()

total: 0 errors, 1 warnings, 0 checks, 64 lines checked
390fb4de03ef drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#11: 
plugged into it currently results in a bogus EDID retrieval error in the kernel 
log.

total: 0 errors, 1 warnings, 0 checks, 108 lines checked
774099851b4b drm/nouveau/kms: Don't change EDID when it hasn't actually changed
016677842b85 drm/i915/dp: Extract drm_dp_read_dpcd_caps()
14b3532be864 drm/nouveau/kms: Start using drm_dp_read_dpcd_caps()


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev6)

2020-08-25 Thread Patchwork
== Series Details ==

Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from 
i915 (rev6)
URL   : https://patchwork.freedesktop.org/series/80542/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:expected unsigned int 
[addressable] [usertype] ulClockParams
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:got restricted __le32 
[usertype]
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: warning: incorrect type 
in assignment (different base types)
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1028:50: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1029:49: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1037:47: warning: too many 
warnings
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:184:44: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:283:14: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:320:14: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:323:14: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:326:14: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:329:18: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:330:26: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:338:30: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:340:38: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:342:30: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:346:30: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:348:30: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:353:33: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:367:43: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:369:38: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:374:67: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:375:53: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:378:66: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:389:80: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:395:57: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:402:69: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:403:53: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:406:66: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:414:66: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:423:69: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:424:69: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:473:30: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:476:45: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:477:45: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:484:54: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:52:28: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:531:35: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:53:29: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:533:25: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:54:26: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:55:27: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:56:25: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:57:26: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:577:21: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:581:25: warning: cast to 
restricted __le32
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:58:25: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:583:21: warning: cast to 
restricted __le32
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:586:25: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:590:25: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:59:26: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:5

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support

2020-08-25 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/3] drm/i915/display/tgl: Use TGL DP tables 
for eDP ports without low power support
URL   : https://patchwork.freedesktop.org/series/80990/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8924_full -> Patchwork_18399_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_18399_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@device_reset@unbind-reset-rebind:
- shard-iclb: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-iclb7/igt@device_re...@unbind-reset-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/shard-iclb8/igt@device_re...@unbind-reset-rebind.html

  * igt@gem_exec_whisper@basic-fds-priority:
- shard-glk:  [PASS][3] -> [TIMEOUT][4] ([i915#1958]) +3 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-glk6/igt@gem_exec_whis...@basic-fds-priority.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/shard-glk9/igt@gem_exec_whis...@basic-fds-priority.html

  * igt@gem_exec_whisper@basic-forked:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-glk1/igt@gem_exec_whis...@basic-forked.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/shard-glk2/igt@gem_exec_whis...@basic-forked.html

  * igt@gem_exec_whisper@basic-queues:
- shard-kbl:  [PASS][7] -> [TIMEOUT][8] ([i915#1958]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-kbl4/igt@gem_exec_whis...@basic-queues.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/shard-kbl1/igt@gem_exec_whis...@basic-queues.html
- shard-skl:  [PASS][9] -> [TIMEOUT][10] ([i915#1958]) +1 similar 
issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-skl9/igt@gem_exec_whis...@basic-queues.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/shard-skl1/igt@gem_exec_whis...@basic-queues.html

  * igt@kms_big_fb@x-tiled-32bpp-rotate-180:
- shard-skl:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +10 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-skl3/igt@kms_big...@x-tiled-32bpp-rotate-180.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/shard-skl7/igt@kms_big...@x-tiled-32bpp-rotate-180.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl:  [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +7 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_flip@flip-vs-suspend@c-hdmi-a1:
- shard-hsw:  [PASS][15] -> [INCOMPLETE][16] ([i915#2055])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-hsw1/igt@kms_flip@flip-vs-susp...@c-hdmi-a1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/shard-hsw8/igt@kms_flip@flip-vs-susp...@c-hdmi-a1.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#2122])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-skl6/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-wc:
- shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-tglb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-wc.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/shard-tglb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-wc.html

  * igt@kms_hdr@bpc-switch-suspend:
- shard-skl:  [PASS][21] -> [FAIL][22] ([i915#1188]) +1 similar 
issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-skl1/igt@kms_...@bpc-switch-suspend.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/shard-skl3/igt@kms_...@bpc-switch-suspend.html

  * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl:  [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/shard-skl7/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18399/shard-skl10/igt@kms_plane_alpha_bl...@pipe

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev6)

2020-08-25 Thread Patchwork
== Series Details ==

Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from 
i915 (rev6)
URL   : https://patchwork.freedesktop.org/series/80542/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18400


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18400 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18400, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18400/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_18400:

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- fi-kbl-7500u:   NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18400/fi-kbl-7500u/igt@run...@aborted.html

  
Known issues


  Here are the changes found in Patchwork_18400 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_parallel@engines@fds:
- fi-kbl-guc: [PASS][2] -> [INCOMPLETE][3] ([i915#794])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-guc/igt@gem_exec_parallel@engi...@fds.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18400/fi-kbl-guc/igt@gem_exec_parallel@engi...@fds.html

  * igt@kms_busy@basic@flip:
- fi-kbl-x1275:   [PASS][4] -> [DMESG-WARN][5] ([i915#62] / [i915#92] / 
[i915#95])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18400/fi-kbl-x1275/igt@kms_busy@ba...@flip.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2:  [PASS][6] -> [DMESG-WARN][7] ([i915#1982]) +1 similar 
issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18400/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html

  
 Possible fixes 

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050:   [DMESG-WARN][8] ([i915#1982]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18400/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-byt-j1900:   [DMESG-WARN][10] ([i915#1982]) -> [PASS][11] +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18400/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [DMESG-WARN][12] ([i915#1982]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18400/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [INCOMPLETE][14] ([i915#1635] / [i915#337]) -> 
[PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18400/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275:   [DMESG-WARN][16] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][17] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18400/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275:   [DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][19] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18400/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [DMESG-FAIL][20] ([i915#62] / [i915#95]) -> 
[DMESG-FAIL][21] ([i915#62])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@i915_pm_...@mod

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

2020-08-25 Thread Harald Arnesen
Linus Torvalds [25.08.2020 20:19]:

>> Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard
>> freeezes. I can still ssh into the machine
>>
>> The three reverts (763fedd6a216, 7ac2d2536dfa and 9e0f9464e2ab) fixes
>> the bug for me.
> Do you get any oops or other indication of what ends up going wrong?
> Since ssh works that should be fairly easy to see.

Away from the machine now, will check tomorrow morning (CET).
-- 
Hilsen Harald
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v3] drm/i915/gt: Implement WA_1406941453

2020-08-25 Thread clinton . a . taylor
From: Clint Taylor 

Enable HW Default flip for small PL.

bspec: 52890
bspec: 53508
bspec: 53273

v2: rebase to drm-tip
v3: move from ctx to gt workarounds. Remove whitelist.

Cc: Matt Atwood 
Cc: Matt Roper 
Cc: José Roberto de Souza 
Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a3f72b75c61e..0aecb97fd41c 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1211,6 +1211,9 @@ gen12_gt_workarounds_init(struct drm_i915_private *i915,
  struct i915_wa_list *wal)
 {
wa_init_mcr(i915, wal);
+
+   /* Wa_1406941453:gen12 */
+   WA_SET_BIT_MASKED(GEN10_SAMPLER_MODE, ENABLE_SMALLPL);
 }
 
 static void
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ac691927e29d..ab4b1abd4364 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9315,6 +9315,7 @@ enum {
 #define   GEN11_LSN_UNSLCVC_GAFS_HALF_SF_MAXALLOC  (1 << 7)
 
 #define GEN10_SAMPLER_MODE _MMIO(0xE18C)
+#define   ENABLE_SMALLPL   REG_BIT(15)
 #define   GEN11_SAMPLER_ENABLE_HEADLESS_MSGREG_BIT(5)
 
 /* IVYBRIDGE DPF */
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v3] drm/i915/gt: Implement WA_1406941453

2020-08-25 Thread Matt Roper
On Tue, Aug 25, 2020 at 02:54:34PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor 
> 
> Enable HW Default flip for small PL.
> 
> bspec: 52890
> bspec: 53508
> bspec: 53273
> 
> v2: rebase to drm-tip
> v3: move from ctx to gt workarounds. Remove whitelist.

I think we actually want to move this one to the rcs_engine_wa_init()
since the register appears to be part of the render engine specifically.
Since this register doesn't hold its value across engine resets[*] we
want to re-apply the workaround any time the RCS engine is reset.

[*] There's been a bit of ambiguity and confusion about what registers
do/don't survive engine resets, but we're starting to get more clarity
on that from the hardware teams now.  There's usually a field in the
bspec's register description that says "GTIReset" --- if that says "DEV"
it's an engine register that should be handled in rcs_engine_wa_init (or
xcs_engine_wa_init for other engine types), whereas if it says "BUS"
it's a GT register that should go in gt_workarounds_init.


Matt

> 
> Cc: Matt Atwood 
> Cc: Matt Roper 
> Cc: José Roberto de Souza 
> Signed-off-by: Clint Taylor 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
>  drivers/gpu/drm/i915/i915_reg.h | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index a3f72b75c61e..0aecb97fd41c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1211,6 +1211,9 @@ gen12_gt_workarounds_init(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
>  {
>   wa_init_mcr(i915, wal);
> +
> + /* Wa_1406941453:gen12 */
> + WA_SET_BIT_MASKED(GEN10_SAMPLER_MODE, ENABLE_SMALLPL);
>  }
>  
>  static void
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ac691927e29d..ab4b1abd4364 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9315,6 +9315,7 @@ enum {
>  #define   GEN11_LSN_UNSLCVC_GAFS_HALF_SF_MAXALLOC(1 << 7)
>  
>  #define GEN10_SAMPLER_MODE   _MMIO(0xE18C)
> +#define   ENABLE_SMALLPL REG_BIT(15)
>  #define   GEN11_SAMPLER_ENABLE_HEADLESS_MSG  REG_BIT(5)
>  
>  /* IVYBRIDGE DPF */
> -- 
> 2.28.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Implement WA_1406941453 (rev3)

2020-08-25 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Implement WA_1406941453 (rev3)
URL   : https://patchwork.freedesktop.org/series/78243/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18401


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18401 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18401, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18401/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_18401:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@workarounds:
- fi-tgl-u2:  [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-tgl-u2/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18401/fi-tgl-u2/igt@i915_selftest@l...@workarounds.html

  * igt@runner@aborted:
- fi-kbl-7500u:   NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18401/fi-kbl-7500u/igt@run...@aborted.html

  
Known issues


  Here are the changes found in Patchwork_18401 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@requests:
- fi-icl-y:   [PASS][4] -> [INCOMPLETE][5] ([i915#1958])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-y/igt@i915_selftest@l...@requests.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18401/fi-icl-y/igt@i915_selftest@l...@requests.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka:   [PASS][6] -> [DMESG-WARN][7] ([i915#1982])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18401/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  
 Possible fixes 

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [DMESG-WARN][8] ([i915#1982]) -> [PASS][9] +1 similar 
issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18401/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [DMESG-WARN][10] ([i915#1982]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18401/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][12] ([i915#2203]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18401/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [INCOMPLETE][14] ([i915#1635] / [i915#337]) -> 
[PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18401/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275:   [DMESG-WARN][16] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18401/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [DMESG-FAIL][18] ([i915#62] / [i915#95]) -> 
[DMESG-FAIL][19] ([i915#62])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18401/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][21] ([i915#62] / [i915#92])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@kms_force_connector_ba..

Re: [Intel-gfx] [PATCH v3] drm/i915/gt: Implement WA_1406941453

2020-08-25 Thread Taylor, Clinton A
CI failed with lost value on reset

<3> [300.632894] [drm:wa_verify [i915]] *ERROR* GT_REF workaround lost on 
before reset! (e18c=3020/0, expected 80008000)
<3> [300.665974] i915/intel_workarounds_live_selftests: 
live_gpu_reset_workarounds failed with error -3

I will move the W/A to the RCS engine.

Clint


-Original Message-
From: Matt Roper  
Sent: Tuesday, August 25, 2020 3:11 PM
To: Taylor, Clinton A 
Cc: Intel-gfx@lists.freedesktop.org; Atwood, Matthew S 
; Souza, Jose 
Subject: Re: [PATCH v3] drm/i915/gt: Implement WA_1406941453
CI failed with 
On Tue, Aug 25, 2020 at 02:54:34PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor 
> 
> Enable HW Default flip for small PL.
> 
> bspec: 52890
> bspec: 53508
> bspec: 53273
> 
> v2: rebase to drm-tip
> v3: move from ctx to gt workarounds. Remove whitelist.

I think we actually want to move this one to the rcs_engine_wa_init() since the 
register appears to be part of the render engine specifically.
Since this register doesn't hold its value across engine resets[*] we want to 
re-apply the workaround any time the RCS engine is reset.

[*] There's been a bit of ambiguity and confusion about what registers do/don't 
survive engine resets, but we're starting to get more clarity on that from the 
hardware teams now.  There's usually a field in the bspec's register 
description that says "GTIReset" --- if that says "DEV"
it's an engine register that should be handled in rcs_engine_wa_init (or 
xcs_engine_wa_init for other engine types), whereas if it says "BUS"
it's a GT register that should go in gt_workarounds_init.


Matt

> 
> Cc: Matt Atwood 
> Cc: Matt Roper 
> Cc: José Roberto de Souza 
> Signed-off-by: Clint Taylor 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
>  drivers/gpu/drm/i915/i915_reg.h | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index a3f72b75c61e..0aecb97fd41c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1211,6 +1211,9 @@ gen12_gt_workarounds_init(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
>  {
>   wa_init_mcr(i915, wal);
> +
> + /* Wa_1406941453:gen12 */
> + WA_SET_BIT_MASKED(GEN10_SAMPLER_MODE, ENABLE_SMALLPL);
>  }
>  
>  static void
> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> b/drivers/gpu/drm/i915/i915_reg.h index ac691927e29d..ab4b1abd4364 
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9315,6 +9315,7 @@ enum {
>  #define   GEN11_LSN_UNSLCVC_GAFS_HALF_SF_MAXALLOC(1 << 7)
>  
>  #define GEN10_SAMPLER_MODE   _MMIO(0xE18C)
> +#define   ENABLE_SMALLPL REG_BIT(15)
>  #define   GEN11_SAMPLER_ENABLE_HEADLESS_MSG  REG_BIT(5)
>  
>  /* IVYBRIDGE DPF */
> --
> 2.28.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/ehl: Update voltage swing table

2020-08-25 Thread Matt Roper
On Tue, Aug 25, 2020 at 11:43:43AM -0700, José Roberto de Souza wrote:
> Update with latest tunning in the table.
> 
> BSpec: 21257
> Cc: Matt Roper 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 699511872290..c7e64e20a772 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -572,14 +572,14 @@ static const struct cnl_ddi_buf_trans 
> ehl_combo_phy_ddi_translations_dp[] = {
>   /* NT mV Trans mV db*/
>   { 0xA, 0x33, 0x3F, 0x00, 0x00 },/* 350   350  0.0   */
>   { 0xA, 0x47, 0x36, 0x00, 0x09 },/* 350   500  3.1   */
> - { 0xC, 0x64, 0x30, 0x00, 0x0F },/* 350   700  6.0   */
> - { 0x6, 0x7F, 0x2C, 0x00, 0x13 },/* 350   900  8.2   */
> + { 0xC, 0x64, 0x34, 0x00, 0x0B },/* 350   700  6.0   */
> + { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 350   900  8.2   */
>   { 0xA, 0x46, 0x3F, 0x00, 0x00 },/* 500   500  0.0   */
> - { 0xC, 0x64, 0x36, 0x00, 0x09 },/* 500   700  2.9   */
> - { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 500   900  5.1   */
> + { 0xC, 0x64, 0x38, 0x00, 0x07 },/* 500   700  2.9   */
> + { 0x6, 0x7F, 0x32, 0x00, 0x0D },/* 500   900  5.1   */
>   { 0xC, 0x61, 0x3F, 0x00, 0x00 },/* 650   700  0.6   */
> - { 0x6, 0x7F, 0x37, 0x00, 0x08 },/* 600   900  3.5   */
> - { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900   900  0.0   */
> + { 0x6, 0x7F, 0x37, 0x00, 0x07 },/* 600   900  3.5   */
> + { 0x6, 0x7F, 0x38, 0x00, 0x00 },/* 900   900  0.0   */

I think it got missed at the bottom of my last response, but I see
slightly different values for the last two rows here in the EHL table.
Specifically the third column (cursor coeff dw4) -- I see 0x38 and 0x3F
as the last two values?


Matt

>  };
>  
>  struct icl_mg_phy_ddi_buf_trans {
> -- 
> 2.28.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support

2020-08-25 Thread Matt Roper
On Tue, Aug 25, 2020 at 11:43:41AM -0700, José Roberto de Souza wrote:
> Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
> being used when the eDP port don't support low power voltage swing table.
> 
> Cc: Lee Shawn C 
> Cc: Khaled Almahallawy 
> Cc: Matt Roper 
> Signed-off-by: José Roberto de Souza 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 52 +++-
>  1 file changed, 33 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index de5b216561d8..9a035bb7bd06 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1088,30 +1088,44 @@ tgl_get_combo_buf_trans(struct intel_encoder 
> *encoder, int type, int rate,
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>  
> - if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.hobl) {
> - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> -
> - if (!intel_dp->hobl_failed && rate <= 54) {
> - /* Same table applies to TGL, RKL and DG1 */
> - *n_entries = 
> ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
> - return tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
> + switch (type) {
> + case INTEL_OUTPUT_HDMI:
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
> + return icl_combo_phy_ddi_translations_hdmi;
> + case INTEL_OUTPUT_EDP:
> + if (dev_priv->vbt.edp.hobl) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + if (!intel_dp->hobl_failed && rate <= 54) {
> + /* Same table applies to TGL, RKL and DG1 */
> + *n_entries = 
> ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
> + return 
> tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
> + }
>   }
> - }
>  
> - if (type == INTEL_OUTPUT_HDMI || type == INTEL_OUTPUT_EDP) {
> - return icl_get_combo_buf_trans(encoder, type, rate, n_entries);
> - } else if (rate > 27) {
> - if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
> - *n_entries = 
> ARRAY_SIZE(tgl_uy_combo_phy_ddi_translations_dp_hbr2);
> - return tgl_uy_combo_phy_ddi_translations_dp_hbr2;
> + if (rate > 54) {
> + *n_entries = 
> ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
> + return icl_combo_phy_ddi_translations_edp_hbr3;
> + } else if (dev_priv->vbt.edp.low_vswing) {
> + *n_entries = 
> ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
> + return icl_combo_phy_ddi_translations_edp_hbr2;
> + }
> + /* fall through */
> + default:
> + /* All combo DP and eDP ports that do not support low_vswing */
> + if (rate > 27) {
> + if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
> + *n_entries = 
> ARRAY_SIZE(tgl_uy_combo_phy_ddi_translations_dp_hbr2);
> + return 
> tgl_uy_combo_phy_ddi_translations_dp_hbr2;
> + }
> +
> + *n_entries = 
> ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr2);
> + return tgl_combo_phy_ddi_translations_dp_hbr2;
>   }
>  
> - *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr2);
> - return tgl_combo_phy_ddi_translations_dp_hbr2;
> + *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr);
> + return tgl_combo_phy_ddi_translations_dp_hbr;
>   }
> -
> - *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr);
> - return tgl_combo_phy_ddi_translations_dp_hbr;
>  }
>  
>  static const struct tgl_dkl_phy_ddi_buf_trans *
> -- 
> 2.28.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/display/ehl: Use EHL DP tables for eDP ports without low power support

2020-08-25 Thread Matt Roper
On Tue, Aug 25, 2020 at 11:43:42AM -0700, José Roberto de Souza wrote:
> Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
> being used when the eDP port don't support low power voltage swing table.
> 
> v2: Only use icl_combo_phy_ddi_translations_edp_hbr3 if low_vswing is
> set as EHL combo phy supports HBR3 (Matt R)
> 
> Cc: Lee Shawn C 
> Cc: Khaled Almahallawy 
> Cc: Matt Roper 
> Signed-off-by: José Roberto de Souza 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 22 +++---
>  1 file changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 9a035bb7bd06..699511872290 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1074,12 +1074,28 @@ static const struct cnl_ddi_buf_trans *
>  ehl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
>   int *n_entries)
>  {
> - if (type != INTEL_OUTPUT_HDMI && type != INTEL_OUTPUT_EDP) {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + switch (type) {
> + case INTEL_OUTPUT_HDMI:
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
> + return icl_combo_phy_ddi_translations_hdmi;
> + case INTEL_OUTPUT_EDP:
> + if (dev_priv->vbt.edp.low_vswing) {
> + if (rate > 54) {
> + *n_entries = 
> ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
> + return icl_combo_phy_ddi_translations_edp_hbr3;
> + } else {
> + *n_entries = 
> ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
> + return icl_combo_phy_ddi_translations_edp_hbr2;
> + }
> + }
> + /* fall through */
> + default:
> + /* All combo DP and eDP ports that do not support low_vswing */
>   *n_entries = ARRAY_SIZE(ehl_combo_phy_ddi_translations_dp);
>   return ehl_combo_phy_ddi_translations_dp;
>   }
> -
> - return icl_get_combo_buf_trans(encoder, type, rate, n_entries);
>  }
>  
>  static const struct cnl_ddi_buf_trans *
> -- 
> 2.28.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/display: fix uninitialized variable

2020-08-25 Thread trix
From: Tom Rix 

clang static analysis flags this error

intel_combo_phy.c:268:7: warning: The left expression of the
  compound assignment is an uninitialized value.
  The computed value will also be garbage
ret &= check_phy_reg(...
~~~ ^

ret has no initial values, in icl_combo_phy_verify_state() ret is
set by the next statment and then updated by similar &= logic.

Because the check_phy_req() are only register reads, reorder the
statements.

Fixes: 239bef676d8e ("drm/i915/display: Implement new combo phy initialization 
step")
Signed-off-by: Tom Rix 
---
 drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c 
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 6968de4f3477..7622ef66c987 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -264,6 +264,8 @@ static bool icl_combo_phy_verify_state(struct 
drm_i915_private *dev_priv,
if (!icl_combo_phy_enabled(dev_priv, phy))
return false;
 
+   ret = cnl_verify_procmon_ref_values(dev_priv, phy);
+
if (INTEL_GEN(dev_priv) >= 12) {
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy),
 ICL_PORT_TX_DW8_ODCC_CLK_SEL |
@@ -276,8 +278,6 @@ static bool icl_combo_phy_verify_state(struct 
drm_i915_private *dev_priv,
 DCC_MODE_SELECT_CONTINUOSLY);
}
 
-   ret = cnl_verify_procmon_ref_values(dev_priv, phy);
-
if (phy_is_master(dev_priv, phy)) {
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
 IREFGEN, IREFGEN);
-- 
2.18.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: fix uninitialized variable

2020-08-25 Thread Patchwork
== Series Details ==

Series: drm/i915/display: fix uninitialized variable
URL   : https://patchwork.freedesktop.org/series/80998/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18402


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18402 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18402, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18402/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_18402:

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- fi-kbl-7500u:   NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18402/fi-kbl-7500u/igt@run...@aborted.html

  
Known issues


  Here are the changes found in Patchwork_18402 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2:  [PASS][2] -> [DMESG-WARN][3] ([i915#1982])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18402/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html

  
 Possible fixes 

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [DMESG-WARN][4] ([i915#1982]) -> [PASS][5] +1 similar 
issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18402/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [DMESG-WARN][6] ([i915#1982]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18402/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][8] ([i915#2203]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18402/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [INCOMPLETE][10] ([i915#1635] / [i915#337]) -> 
[PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18402/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [DMESG-FAIL][12] ([i915#62] / [i915#95]) -> 
[DMESG-FAIL][13] ([i915#62])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18402/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  * igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275:   [DMESG-WARN][14] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18402/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][17] ([i915#62] / [i915#92]) +2 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8924/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18402/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#2335]: https://gitlab.freedesktop.org/drm/intel/issues/2335
  [i915#337]: https:

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

2020-08-25 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-misc tree got conflicts in:

  drivers/video/fbdev/arcfb.c
  drivers/video/fbdev/atmel_lcdfb.c
  drivers/video/fbdev/savage/savagefb_driver.c

between commit:

  df561f6688fe ("treewide: Use fallthrough pseudo-keyword")

from Linus' tree and commit:

  ad04fae0de07 ("fbdev: Use fallthrough pseudo-keyword")

from the drm-misc tree.

I fixed it up (they are much the same, I just used the version from Linus'
tree) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be mentioned
to your upstream maintainer when your tree is submitted for merging.
You may also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.



-- 
Cheers,
Stephen Rothwell


pgpywQjuMbT7H.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2020-08-25 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-misc tree got conflicts in:

  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c

between commits:

  cacbbe7c0065 ("drm/amdgpu: move stolen memory from gmc to mman")
  72de33f8f7ba ("drm/amdgpu: move IP discovery data to mman")
  87ded5caeec3 ("drm/amdgpu: move vram usage by vbios to mman (v2)")
  1348969ab68c ("drm/amdgpu: drm_device to amdgpu_device by inline-f (v2)")

from the amdgpu tree and commits:

  6c28aed6e5b7 ("drm/amdgfx/ttm: use wrapper to get ttm memory managers")
  9de59bc20149 ("drm/ttm: rename ttm_mem_type_manager -> ttm_resource_manager.")
  4f297b9c82e1 ("drm/amdgpu/ttm: move vram/gtt mgr allocations to mman.")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index e1b66898cb76,697bc2c6fdb2..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@@ -47,10 -46,10 +46,10 @@@ static ssize_t amdgpu_mem_info_gtt_tota
struct device_attribute *attr, char *buf)
  {
struct drm_device *ddev = dev_get_drvdata(dev);
 -  struct amdgpu_device *adev = ddev->dev_private;
 +  struct amdgpu_device *adev = drm_to_adev(ddev);
- 
+   struct ttm_resource_manager *man = ttm_manager_type(&adev->mman.bdev, 
TTM_PL_TT);
return snprintf(buf, PAGE_SIZE, "%llu\n",
-   (adev->mman.bdev.man[TTM_PL_TT].size) * PAGE_SIZE);
+   man->size * PAGE_SIZE);
  }
  
  /**
@@@ -65,10 -64,10 +64,10 @@@ static ssize_t amdgpu_mem_info_gtt_used
struct device_attribute *attr, char *buf)
  {
struct drm_device *ddev = dev_get_drvdata(dev);
 -  struct amdgpu_device *adev = ddev->dev_private;
 +  struct amdgpu_device *adev = drm_to_adev(ddev);
- 
+   struct ttm_resource_manager *man = ttm_manager_type(&adev->mman.bdev, 
TTM_PL_TT);
return snprintf(buf, PAGE_SIZE, "%llu\n",
-   amdgpu_gtt_mgr_usage(&adev->mman.bdev.man[TTM_PL_TT]));
+   amdgpu_gtt_mgr_usage(man));
  }
  
  static DEVICE_ATTR(mem_info_gtt_total, S_IRUGO,
diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 63e541409549,fc5f7ac53d0a..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@@ -2316,8 -2251,8 +2261,8 @@@ static int amdgpu_mm_dump_table(struct 
struct drm_info_node *node = (struct drm_info_node *)m->private;
unsigned ttm_pl = (uintptr_t)node->info_ent->data;
struct drm_device *dev = node->minor->dev;
 -  struct amdgpu_device *adev = dev->dev_private;
 +  struct amdgpu_device *adev = drm_to_adev(dev);
-   struct ttm_mem_type_manager *man = &adev->mman.bdev.man[ttm_pl];
+   struct ttm_resource_manager *man = ttm_manager_type(&adev->mman.bdev, 
ttm_pl);
struct drm_printer p = drm_seq_file_printer(m);
  
man->func->debug(man, &p);
diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index de37ceff0e56,7ba2be37e6ba..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@@ -60,22 -75,8 +75,24 @@@ struct amdgpu_mman 
/* Scheduler entity for buffer moves */
struct drm_sched_entity entity;
  
 +  uint64_tstolen_vga_size;
 +  struct amdgpu_bo*stolen_vga_memory;
 +  uint64_tstolen_extended_size;
 +  struct amdgpu_bo*stolen_extended_memory;
 +  boolkeep_stolen_vga_memory;
 +
 +  /* discovery */
 +  uint8_t *discovery_bin;
 +  uint32_tdiscovery_tmr_size;
 +  struct amdgpu_bo*discovery_memory;
 +
 +  /* firmware VRAM reservation */
 +  u64 fw_vram_usage_start_offset;
 +  u64 fw_vram_usage_size;
 +  struct amdgpu_bo*fw_vram_usage_reserved_bo;
 +  void*fw_vram_usage_va;
+   struct amdgpu_vram_mgr vram_mgr;
+   struct amdgpu_gtt_mgr gtt_mgr;
  };
  
  struct amdgpu_copy_mem {
diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 91098a385ed6,7574be6cd7a0..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@@ -81,10 -84,10 +84,10 @@@ static ssize_t amdgpu_mem_info_vram_use
struct device_attribute *attr, char *buf)
  {
struct drm_device *ddev = dev_ge

[Intel-gfx] linux-next: build failure after merge of the drm-misc tree

2020-08-25 Thread Stephen Rothwell
Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/qxl/qxl_display.c: In function 
'qxl_display_read_client_monitors_config':
include/drm/drm_modeset_lock.h:167:7: error: implicit declaration of function 
'drm_drv_uses_atomic_modeset' [-Werror=implicit-function-declaration]
  167 |  if (!drm_drv_uses_atomic_modeset(dev))\
  |   ^~~
drivers/gpu/drm/qxl/qxl_display.c:187:2: note: in expansion of macro 
'DRM_MODESET_LOCK_ALL_BEGIN'
  187 |  DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
  |  ^~
drivers/gpu/drm/qxl/qxl_display.c:189:35: error: macro 
"DRM_MODESET_LOCK_ALL_END" requires 3 arguments, but only 2 given
  189 |  DRM_MODESET_LOCK_ALL_END(ctx, ret);
  |   ^
In file included from include/drm/drm_crtc.h:36,
 from include/drm/drm_atomic.h:31,
 from drivers/gpu/drm/qxl/qxl_display.c:29:
include/drm/drm_modeset_lock.h:194: note: macro "DRM_MODESET_LOCK_ALL_END" 
defined here
  194 | #define DRM_MODESET_LOCK_ALL_END(dev, ctx, ret)\
  | 
drivers/gpu/drm/qxl/qxl_display.c:189:2: error: 'DRM_MODESET_LOCK_ALL_END' 
undeclared (first use in this function)
  189 |  DRM_MODESET_LOCK_ALL_END(ctx, ret);
  |  ^~~~
drivers/gpu/drm/qxl/qxl_display.c:189:2: note: each undeclared identifier is 
reported only once for each function it appears in
drivers/gpu/drm/qxl/qxl_display.c:187:2: error: label 'modeset_lock_fail' used 
but not defined
  187 |  DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
  |  ^~
In file included from include/drm/drm_crtc.h:36,
 from include/drm/drm_atomic.h:31,
 from drivers/gpu/drm/qxl/qxl_display.c:29:
include/drm/drm_modeset_lock.h:170:1: warning: label 'modeset_lock_retry' 
defined but not used [-Wunused-label]
  170 | modeset_lock_retry:   \
  | ^~
drivers/gpu/drm/qxl/qxl_display.c:187:2: note: in expansion of macro 
'DRM_MODESET_LOCK_ALL_BEGIN'
  187 |  DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
  |  ^~
drivers/gpu/drm/qxl/qxl_display.c: In function 'qxl_framebuffer_surface_dirty':
drivers/gpu/drm/qxl/qxl_display.c:434:35: error: macro 
"DRM_MODESET_LOCK_ALL_END" requires 3 arguments, but only 2 given
  434 |  DRM_MODESET_LOCK_ALL_END(ctx, ret);
  |   ^
In file included from include/drm/drm_crtc.h:36,
 from include/drm/drm_atomic.h:31,
 from drivers/gpu/drm/qxl/qxl_display.c:29:
include/drm/drm_modeset_lock.h:194: note: macro "DRM_MODESET_LOCK_ALL_END" 
defined here
  194 | #define DRM_MODESET_LOCK_ALL_END(dev, ctx, ret)\
  | 
drivers/gpu/drm/qxl/qxl_display.c:434:2: error: 'DRM_MODESET_LOCK_ALL_END' 
undeclared (first use in this function)
  434 |  DRM_MODESET_LOCK_ALL_END(ctx, ret);
  |  ^~~~
drivers/gpu/drm/qxl/qxl_display.c:411:2: error: label 'modeset_lock_fail' used 
but not defined
  411 |  DRM_MODESET_LOCK_ALL_BEGIN(fb->dev, ctx, 
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
  |  ^~
In file included from include/drm/drm_crtc.h:36,
 from include/drm/drm_atomic.h:31,
 from drivers/gpu/drm/qxl/qxl_display.c:29:
include/drm/drm_modeset_lock.h:170:1: warning: label 'modeset_lock_retry' 
defined but not used [-Wunused-label]
  170 | modeset_lock_retry:   \
  | ^~
drivers/gpu/drm/qxl/qxl_display.c:411:2: note: in expansion of macro 
'DRM_MODESET_LOCK_ALL_BEGIN'
  411 |  DRM_MODESET_LOCK_ALL_BEGIN(fb->dev, ctx, 
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
  |  ^~

Caused by commit

  bbaac1354cc9 ("drm/qxl: Replace deprecated function in qxl_display")

interacting with commit

  77ef38574beb ("drm/modeset-lock: Take the modeset BKL for legacy drivers")

from the drm-misc-fixes tree.

drivers/gpu/drm/qxl/qxl_display.c manages to include
drm/drm_modeset_lock.h by some indirect route, but fails to have
drm/drm_drv.h similarly included.  In fact, drm/drm_modeset_lock.h should
have included drm/drm_drv.h since it uses things declared there, and
drivers/gpu/drm/qxl/qxl_display.c should include drm/drm_modeset_lock.h
similarly.

I have added the following hack patch for today.

From: Stephen Rothwell 
Date: Wed, 26 Aug 2020 10:40:18 +1000
Subject: [PATCH] fix interaction with drm-misc-fix commit

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index fa79688013b7..6063f3a15329 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -26,6 +26,7 @@
 #include 
 #

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Expose list of clients in sysfs

2020-08-25 Thread Lucas De Marchi
Hi,

Any update on this? It now conflicts in a few places so it needs a rebase.

Lucas De Marchi

On Wed, Apr 15, 2020 at 3:11 AM Tvrtko Ursulin
 wrote:
>
> From: Tvrtko Ursulin 
>
> Expose a list of clients with open file handles in sysfs.
>
> This will be a basis for a top-like utility showing per-client and per-
> engine GPU load.
>
> Currently we only expose each client's pid and name under opaque numbered
> directories in /sys/class/drm/card0/clients/.
>
> For instance:
>
> /sys/class/drm/card0/clients/3/name: Xorg
> /sys/class/drm/card0/clients/3/pid: 5664
>
> v2:
>  Chris Wilson:
>  * Enclose new members into dedicated structs.
>  * Protect against failed sysfs registration.
>
> v3:
>  * sysfs_attr_init.
>
> v4:
>  * Fix for internal clients.
>
> v5:
>  * Use cyclic ida for client id. (Chris)
>  * Do not leak pid reference. (Chris)
>  * Tidy code with some locals.
>
> v6:
>  * Use xa_alloc_cyclic to simplify locking. (Chris)
>  * No need to unregister individial sysfs files. (Chris)
>  * Rebase on top of fpriv kref.
>  * Track client closed status and reflect in sysfs.
>
> v7:
>  * Make drm_client more standalone concept.
>
> v8:
>  * Simplify sysfs show. (Chris)
>  * Always track name and pid.
>
> v9:
>  * Fix cyclic id assignment.
>
> v10:
>  * No need for a mutex around xa_alloc_cyclic.
>  * Refactor sysfs into own function.
>  * Unregister sysfs before freeing pid and name.
>  * Move clients setup into own function.
>
> v11:
>  * Call clients init directly from driver init. (Chris)
>
> Signed-off-by: Tvrtko Ursulin 
> Reviewed-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/Makefile  |   3 +-
>  drivers/gpu/drm/i915/i915_drm_client.c | 179 +
>  drivers/gpu/drm/i915/i915_drm_client.h |  64 +
>  drivers/gpu/drm/i915/i915_drv.c|   3 +
>  drivers/gpu/drm/i915/i915_drv.h|   5 +
>  drivers/gpu/drm/i915/i915_gem.c|  25 +++-
>  drivers/gpu/drm/i915/i915_sysfs.c  |   8 ++
>  7 files changed, 283 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
>  create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 44c506b7e117..b30f3d51c66a 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -33,7 +33,8 @@ subdir-ccflags-y += -I$(srctree)/$(src)
>  # Please keep these build lists sorted!
>
>  # core driver code
> -i915-y += i915_drv.o \
> +i915-y += i915_drm_client.o \
> + i915_drv.o \
>   i915_irq.o \
>   i915_getparam.o \
>   i915_params.o \
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
> b/drivers/gpu/drm/i915/i915_drm_client.c
> new file mode 100644
> index ..2067fbcdb795
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> @@ -0,0 +1,179 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2020 Intel Corporation
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "i915_drm_client.h"
> +#include "i915_gem.h"
> +#include "i915_utils.h"
> +
> +void i915_drm_clients_init(struct i915_drm_clients *clients)
> +{
> +   clients->next_id = 0;
> +   xa_init_flags(&clients->xarray, XA_FLAGS_ALLOC);
> +}
> +
> +static ssize_t
> +show_client_name(struct device *kdev, struct device_attribute *attr, char 
> *buf)
> +{
> +   struct i915_drm_client *client =
> +   container_of(attr, typeof(*client), attr.name);
> +
> +   return snprintf(buf, PAGE_SIZE,
> +   READ_ONCE(client->closed) ? "<%s>" : "%s",
> +   client->name);
> +}
> +
> +static ssize_t
> +show_client_pid(struct device *kdev, struct device_attribute *attr, char 
> *buf)
> +{
> +   struct i915_drm_client *client =
> +   container_of(attr, typeof(*client), attr.pid);
> +
> +   return snprintf(buf, PAGE_SIZE,
> +   READ_ONCE(client->closed) ? "<%u>" : "%u",
> +   pid_nr(client->pid));
> +}
> +
> +static int
> +__client_register_sysfs(struct i915_drm_client *client)
> +{
> +   const struct {
> +   const char *name;
> +   struct device_attribute *attr;
> +   ssize_t (*show)(struct device *dev,
> +   struct device_attribute *attr,
> +   char *buf);
> +   } files[] = {
> +   { "name", &client->attr.name, show_client_name },
> +   { "pid", &client->attr.pid, show_client_pid },
> +   };
> +   unsigned int i;
> +   char buf[16];
> +   int ret;
> +
> +   ret = scnprintf(buf, sizeof(buf), "%u", client->id);
> +   if (ret == sizeof(buf))
> +   return -EINVAL;
> +
> +   client->root = kobject_create_and_add(buf, client->clients->root);
> +   if (!client->root)
> +   return -ENOMEM;
> +
> +   for (i = 0; i < ARRAY_SIZE(files); i++) {
> +   struct de

[Intel-gfx] ✗ Fi.CI.BAT: failure for linux-next: build failure after merge of the drm-misc tree

2020-08-25 Thread Patchwork
== Series Details ==

Series: linux-next: build failure after merge of the drm-misc tree
URL   : https://patchwork.freedesktop.org/series/81001/
State : failure

== Summary ==

Applying: linux-next: build failure after merge of the drm-misc tree
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/qxl/qxl_display.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v4] drm/i915/gt: Implement WA_1406941453

2020-08-25 Thread clinton . a . taylor
From: Clint Taylor 

Enable HW Default flip for small PL.

bspec: 52890
bspec: 53508
bspec: 53273

v2: rebase to drm-tip
v3: move from ctx to gt workarounds. Remove whitelist.
v4: move to rcs WA init

Cc: Matt Atwood 
Cc: Matt Roper 
Cc: José Roberto de Souza 
Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 +++
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a3f72b75c61e..b0a7cb056633 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1725,6 +1725,13 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
 FF_DOP_CLOCK_GATE_DISABLE);
}
 
+   if (IS_GEN(i915, 12)) {
+   /* Wa_1406941453:gen12 */
+   wa_masked_en(wal,
+GEN10_SAMPLER_MODE,
+ENABLE_SMALLPL);
+   }
+
if (IS_GEN(i915, 11)) {
/* This is not an Wa. Enable for better image quality */
wa_masked_en(wal,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ac691927e29d..ab4b1abd4364 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9315,6 +9315,7 @@ enum {
 #define   GEN11_LSN_UNSLCVC_GAFS_HALF_SF_MAXALLOC  (1 << 7)
 
 #define GEN10_SAMPLER_MODE _MMIO(0xE18C)
+#define   ENABLE_SMALLPL   REG_BIT(15)
 #define   GEN11_SAMPLER_ENABLE_HEADLESS_MSGREG_BIT(5)
 
 /* IVYBRIDGE DPF */
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Implement WA_1406941453 (rev4)

2020-08-25 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Implement WA_1406941453 (rev4)
URL   : https://patchwork.freedesktop.org/series/78243/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8925 -> Patchwork_18404


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/index.html

Known issues


  Here are the changes found in Patchwork_18404 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_busy@basic@flip:
- fi-kbl-x1275:   [PASS][1] -> [DMESG-WARN][2] ([i915#62] / [i915#92] / 
[i915#95])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/fi-kbl-x1275/igt@kms_busy@ba...@flip.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2:  [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2:  [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html

  
 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [DMESG-FAIL][9] ([i915#62] / [i915#95]) -> 
[DMESG-FAIL][10] ([i915#62])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  * igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275:   [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][12] ([i915#62] / [i915#92]) +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][13] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html

  
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (37 -> 34)
--

  Missing(3): fi-byt-clapper fi-byt-squawks fi-bsw-cyan 


Build changes
-

  * Linux: CI_DRM_8925 -> Patchwork_18404

  CI-20190529: 20190529
  CI_DRM_8925: b0f0c5e0b08e7d93135a27141919e765db3aaeef @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5771: f1d0c240ea2e631dfb9f493f37f8fb61cb2b1cf2 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18404: 8b63f6a0a82d5b831461a1bcc9d15294aadc3084 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8b63f6a0a82d drm/i915/gt: Implement WA_1406941453

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4] drm/i915/gt: Implement WA_1406941453

2020-08-25 Thread Matt Roper
On Tue, Aug 25, 2020 at 07:57:24PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor 
> 
> Enable HW Default flip for small PL.
> 
> bspec: 52890
> bspec: 53508
> bspec: 53273
> 
> v2: rebase to drm-tip
> v3: move from ctx to gt workarounds. Remove whitelist.
> v4: move to rcs WA init
> 
> Cc: Matt Atwood 
> Cc: Matt Roper 
> Cc: José Roberto de Souza 
> Signed-off-by: Clint Taylor 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 +++
>  drivers/gpu/drm/i915/i915_reg.h | 1 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index a3f72b75c61e..b0a7cb056633 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1725,6 +1725,13 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
> struct i915_wa_list *wal)
>FF_DOP_CLOCK_GATE_DISABLE);
>   }
>  
> + if (IS_GEN(i915, 12)) {
> + /* Wa_1406941453:gen12 */
> + wa_masked_en(wal,
> +  GEN10_SAMPLER_MODE,
> +  ENABLE_SMALLPL);
> + }
> +
>   if (IS_GEN(i915, 11)) {
>   /* This is not an Wa. Enable for better image quality */
>   wa_masked_en(wal,
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ac691927e29d..ab4b1abd4364 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9315,6 +9315,7 @@ enum {
>  #define   GEN11_LSN_UNSLCVC_GAFS_HALF_SF_MAXALLOC(1 << 7)
>  
>  #define GEN10_SAMPLER_MODE   _MMIO(0xE18C)
> +#define   ENABLE_SMALLPL REG_BIT(15)
>  #define   GEN11_SAMPLER_ENABLE_HEADLESS_MSG  REG_BIT(5)
>  
>  /* IVYBRIDGE DPF */
> -- 
> 2.28.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW

2020-08-25 Thread Kai-Heng Feng
Hi,

> On Aug 25, 2020, at 02:46, Runyan, Arthur J  wrote:
> 
> I remember some strangeness about the blnclegdisbl.  I'll see if I can dig up 
> some more.


The register read can be found at [1] and [2].

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/119
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/120

Kai-Heng

> 
> -Original Message-
> From: Ville Syrjälä  
> Sent: Monday, August 24, 2020 11:05 AM
> To: Kai-Heng Feng 
> Cc: Runyan, Arthur J ; Vivi, Rodrigo 
> ; intel-gfx 
> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI 
> on ASUS GL552VW
> 
> On Mon, Aug 17, 2020 at 02:17:49PM +0800, Kai-Heng Feng wrote:
>> 
>> 
>>> On Aug 17, 2020, at 00:22, Runyan, Arthur J  
>>> wrote:
>>> 
>>> You'll need to read out the DDI_BUF_TRANS_* and DISPIO_CR_TX_BMU_CR0 
>>> registers at boot before i915 programs them and compare with what driver 
>>> programs.  
>>> Rodrigo can probably show you how. 
>> 
>> Right, I'll wait for a patch then :)
> 
> To grab the BIOS reg values we just have to make sure the driver doesn't 
> load. Eg. pass something like "modprobe.blacklist=i915,snd_hda_intel 3" to 
> the kernel cmdline (+ whatever other magic ubuntu might require). Confirm 
> with something like "lsmod | grep i915" to make sure the driver didn't sneak 
> in despite our best efforts.
> 
> Then we can dump the registers with intel_reg from igt-gpu-tools:
> intel_reg read --count 20 0x64E00 0x64E60 0x64EC0 0x64F20 0x64F80 intel_reg 
> read 0x64000 0x64100 0x64200 0x64300 0x64400 0x6C00C
> 
> The only somewhat suspicious thing I noticed is that we treat 
> DISPIO_CR_TX_BMU_CR0:tx_blnclegdisbl as a bitmask (bit 23 -> DDI A, bit 24 -> 
> DDI B, etc.) whereas the spec seems to be saying that we should just zero out 
> all the bits of tx_blnclegdisbl when any DDI needs iboost. Art, is our 
> interpretation of the bits correct or just a fairy tale?
> 
>> 
>> Kai-Heng
>> 
>>> 
>>> -Original Message-
>>> From: Kai-Heng Feng 
>>> Sent: Thursday, August 13, 2020 10:14 PM
>>> To: Runyan, Arthur J 
>>> Cc: Vivi, Rodrigo ; Ville Syrjälä 
>>> ; intel-gfx 
>>> 
>>> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" 
>>> breaks HDMI on ASUS GL552VW
>>> 
>>> Hi,
>>> 
 On Aug 14, 2020, at 01:56, Runyan, Arthur J  
 wrote:
 
 The workaround is freeing up stuck vswing values to let new vswing 
 programming kick in.  Maybe the new vswing values are wrong.
 Try checking the vswing that driver programs against what BIOS/GOP 
 programs.
>>> 
>>> Do you mean to print out value of I915_READ()?
>>> val = I915_READ(CHICKEN_TRANS(transcoder));
>>> 
>>> Kai-Heng
>>> 
 
 -Original Message-
 From: Vivi, Rodrigo 
 Sent: Thursday, August 13, 2020 9:50 AM
 To: Kai-Heng Feng ; Runyan, Arthur J 
 
 Cc: Ville Syrjälä ; intel-gfx 
 
 Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" 
 breaks HDMI on ASUS GL552VW
 
 Art, any comment here?
 
 I just checked and the  W/a 1143 is implemented as described, but it is 
 failing HDMI on this hybrid system.
 
> On Aug 12, 2020, at 9:07 PM, Kai-Heng Feng  
> wrote:
> 
> Hi,
> 
> There's a regression reported that HDMI output stops working after os 
> upgrade:
> https://bugs.launchpad.net/bugs/1871721
> 
> Here's the bisect result:
> 0519c102f5285476d7868a387bdb6c58385e4074 is the first bad commit 
> commit 0519c102f5285476d7868a387bdb6c58385e4074
> Author: Ville Syrjälä 
> Date:   Mon Jan 22 19:41:31 2018 +0200
> 
> drm/i915: Implement display w/a #1143
> 
> Apparently SKL/KBL/CFL need some manual help to get the  
> programmed HDMI vswing to stick. Implement the relevant  
> workaround (display w/a #1143).
> 
> Note that the relevant chicken bits live in a transcoder register  
> even though the bits affect a specific DDI port rather than a  
> specific transcoder. Hence we must pick the correct transcoder  
> register instance based on the port rather than based on the  
> cpu_transcoder.
> 
> Also note that for completeness I included support for DDI A/E  
> in the code even though we never have HDMI on those ports.
> 
> v2: CFL needs the w/a as well (Rodrigo and Art)
> 
> Cc: Rodrigo Vivi 
> Cc: Art Runyan 
> Signed-off-by: Ville Syrjälä 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20180122174131.28046
> -1-ville.syrj...@linux.intel.com
> Reviewed-by: Rodrigo Vivi 
> 
> 
> dmesg from drm-tip with drm.debug=0xe can be found here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comme
> nts
> /
> 64
> 
> Kai-Heng
 
 
>>> 
> 
> --
> Ville Syrjälä
> Intel

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://list

[Intel-gfx] [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444

2020-08-25 Thread Kai-Heng Feng
LSPCON only supports 8 bpc for RGB/YCbCr444.

Set the correct bpp otherwise it renders blank screen.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index b781bf469644..c7a44fcaade8 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector *connector,
crtc_state->port_clock /= 2;
crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
crtc_state->lspcon_downsampling = true;
-   }
+   } else
+   crtc_state->pipe_bpp = 24;
 }
 
 static bool lspcon_probe(struct intel_lspcon *lspcon)
-- 
2.17.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444

2020-08-25 Thread Patchwork
== Series Details ==

Series: drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
URL   : https://patchwork.freedesktop.org/series/81004/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a73a2592d427 drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
-:22: CHECK:BRACES: Unbalanced braces around else statement
#22: FILE: drivers/gpu/drm/i915/display/intel_lspcon.c:199:
+   } else

total: 0 errors, 0 warnings, 1 checks, 9 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Implement WA_1406941453 (rev4)

2020-08-25 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Implement WA_1406941453 (rev4)
URL   : https://patchwork.freedesktop.org/series/78243/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8925_full -> Patchwork_18404_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18404_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18404_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_18404_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_vblank@pipe-c-ts-continuation-modeset-hang:
- shard-hsw:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/shard-hsw4/igt@kms_vbl...@pipe-c-ts-continuation-modeset-hang.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/shard-hsw1/igt@kms_vbl...@pipe-c-ts-continuation-modeset-hang.html

  * igt@sysfs_preempt_timeout@timeout@rcs0:
- shard-skl:  [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/shard-skl2/igt@sysfs_preempt_timeout@time...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/shard-skl10/igt@sysfs_preempt_timeout@time...@rcs0.html

  
Known issues


  Here are the changes found in Patchwork_18404_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_reloc@basic-concurrent0:
- shard-kbl:  [PASS][5] -> [TIMEOUT][6] ([i915#1958]) +3 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/shard-kbl2/igt@gem_exec_re...@basic-concurrent0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/shard-kbl2/igt@gem_exec_re...@basic-concurrent0.html

  * igt@gem_exec_reloc@basic-concurrent16:
- shard-apl:  [PASS][7] -> [TIMEOUT][8] ([i915#1635] / [i915#1958])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/shard-apl2/igt@gem_exec_re...@basic-concurrent16.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/shard-apl6/igt@gem_exec_re...@basic-concurrent16.html

  * igt@gem_exec_whisper@basic-contexts-priority:
- shard-iclb: [PASS][9] -> [TIMEOUT][10] ([i915#1958]) +1 similar 
issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/shard-iclb2/igt@gem_exec_whis...@basic-contexts-priority.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/shard-iclb7/igt@gem_exec_whis...@basic-contexts-priority.html

  * igt@gem_exec_whisper@basic-fds-priority:
- shard-glk:  [PASS][11] -> [TIMEOUT][12] ([i915#1958]) +3 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/shard-glk7/igt@gem_exec_whis...@basic-fds-priority.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/shard-glk6/igt@gem_exec_whis...@basic-fds-priority.html

  * igt@gem_exec_whisper@basic-normal:
- shard-tglb: [PASS][13] -> [TIMEOUT][14] ([i915#1958])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/shard-tglb7/igt@gem_exec_whis...@basic-normal.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/shard-tglb3/igt@gem_exec_whis...@basic-normal.html

  * igt@gem_exec_whisper@basic-queues-forked:
- shard-skl:  [PASS][15] -> [TIMEOUT][16] ([i915#1958])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/shard-skl8/igt@gem_exec_whis...@basic-queues-forked.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/shard-skl7/igt@gem_exec_whis...@basic-queues-forked.html

  * igt@gem_sync@basic-store-all:
- shard-apl:  [PASS][17] -> [FAIL][18] ([i915#1635] / [i915#2356])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/shard-apl3/igt@gem_s...@basic-store-all.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/shard-apl8/igt@gem_s...@basic-store-all.html
- shard-glk:  [PASS][19] -> [FAIL][20] ([i915#2356])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/shard-glk4/igt@gem_s...@basic-store-all.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/shard-glk8/igt@gem_s...@basic-store-all.html
- shard-skl:  [PASS][21] -> [FAIL][22] ([i915#2356])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/shard-skl5/igt@gem_s...@basic-store-all.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/shard-skl2/igt@gem_s...@basic-store-all.html

  * igt@i915_selftest@mock@contexts:
- shard-skl:  [PASS][23] -> [INCOMPLETE][24] ([i915#198] / 
[i915#2278])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/shard-skl7/igt@i915_self

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444

2020-08-25 Thread Patchwork
== Series Details ==

Series: drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
URL   : https://patchwork.freedesktop.org/series/81004/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8925 -> Patchwork_18405


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18405 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18405, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18405/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_18405:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_parallel@engines@basic:
- fi-icl-u2:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-icl-u2/igt@gem_exec_parallel@engi...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18405/fi-icl-u2/igt@gem_exec_parallel@engi...@basic.html

  * igt@runner@aborted:
- fi-icl-u2:  NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18405/fi-icl-u2/igt@run...@aborted.html

  
Known issues


  Here are the changes found in Patchwork_18405 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2:  [PASS][4] -> [FAIL][5] ([i915#1888])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18405/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_module_load@reload:
- fi-apl-guc: [PASS][6] -> [DMESG-WARN][7] ([i915#1635] / 
[i915#1982])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-apl-guc/igt@i915_module_l...@reload.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18405/fi-apl-guc/igt@i915_module_l...@reload.html

  * igt@kms_busy@basic@flip:
- fi-kbl-x1275:   [PASS][8] -> [DMESG-WARN][9] ([i915#62] / [i915#92] / 
[i915#95])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18405/fi-kbl-x1275/igt@kms_busy@ba...@flip.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   [DMESG-WARN][10] ([i915#1982]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18405/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [INCOMPLETE][12] ([i915#2276]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18405/fi-icl-y/igt@i915_selftest@l...@execlists.html

  
 Warnings 

  * igt@debugfs_test@read_all_entries:
- fi-kbl-x1275:   [DMESG-WARN][14] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18405/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275:   [DMESG-WARN][16] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][17] ([i915#1982] / [i915#62] / [i915#92])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18405/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [DMESG-FAIL][18] ([i915#62] / [i915#95]) -> 
[DMESG-FAIL][19] ([i915#62])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18405/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275:   [DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][21] ([i915#62] / [i915#92]) +4 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8925/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18405/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the 

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

2020-08-25 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_gvt.h/intel_gvt.c and
move the actual implementation to gvt.h/gvt.c. (zhenyu)
- Check gvt config on and active with intel_gvt_active(). (zhenyu)

Colin Xu (2):
  drm/i915/gvt: Save/restore HW status for GVT during suspend/resume
  drm/i915/gvt: Add GVT suspend/resume routine to i915

 drivers/gpu/drm/i915/gvt/gtt.c  | 73 +
 drivers/gpu/drm/i915/gvt/gtt.h  |  2 +
 drivers/gpu/drm/i915/gvt/gvt.c  | 15 ++
 drivers/gpu/drm/i915/gvt/gvt.h  |  6 +++
 drivers/gpu/drm/i915/gvt/handlers.c | 20 
 drivers/gpu/drm/i915/gvt/mmio.h |  3 ++
 drivers/gpu/drm/i915/gvt/vgpu.c |  1 +
 drivers/gpu/drm/i915/i915_drv.c |  4 ++
 drivers/gpu/drm/i915/intel_gvt.c| 29 
 drivers/gpu/drm/i915/intel_gvt.h| 10 
 10 files changed, 163 insertions(+)

-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 1/2] drm/i915/gvt: Save/restore HW status for GVT during suspend/resume

2020-08-25 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 into GVT in suspend routine, and restore the saved entries
and re-init fence regs in resume routine.

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.h/intel_gvt.c and
move the actual implementation to gvt.h/gvt.c. (zhenyu)
- Check gvt config on and active with intel_gvt_active(). (zhenyu)

Signed-off-by: Hang Yuan 
Signed-off-by: Colin Xu 
---
 drivers/gpu/drm/i915/gvt/gtt.c  | 73 +
 drivers/gpu/drm/i915/gvt/gtt.h  |  2 +
 drivers/gpu/drm/i915/gvt/gvt.c  | 15 ++
 drivers/gpu/drm/i915/gvt/gvt.h  |  6 +++
 drivers/gpu/drm/i915/gvt/handlers.c | 20 
 drivers/gpu/drm/i915/gvt/mmio.h |  3 ++
 drivers/gpu/drm/i915/gvt/vgpu.c |  1 +
 drivers/gpu/drm/i915/intel_gvt.c| 29 
 drivers/gpu/drm/i915/intel_gvt.h| 10 
 9 files changed, 159 insertions(+)

diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 04bf018ecc34..7907a535d49f 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -2533,6 +2533,11 @@ static void intel_vgpu_destroy_ggtt_mm(struct intel_vgpu 
*vgpu)
}
intel_vgpu_destroy_mm(vgpu->gtt.ggtt_mm);
vgpu->gtt.ggtt_mm = NULL;
+
+   if (vgpu->ggtt_entries) {
+   vfree(vgpu->ggtt_entries);
+   vgpu->ggtt_entries = NULL;
+   }
 }
 
 /**
@@ -2834,3 +2839,71 @@ void intel_vgpu_reset_ggtt(struct intel_vgpu *vgpu, bool 
invalidate_old)
 
ggtt_invalidate(gvt->gt);
 }
+
+/**
+ * intel_gvt_save_ggtt - save all vGPU's ggtt entries
+ * @gvt: intel gvt device
+ *
+ * This function is called at driver suspend stage to save
+ * GGTT entries of every active vGPU.
+ *
+ */
+void intel_gvt_save_ggtt(struct intel_gvt *gvt)
+{
+   struct intel_vgpu *vgpu;
+   int id;
+   u32 index, num_low, num_hi;
+   void __iomem *addr;
+
+   for_each_active_vgpu(gvt, vgpu, id) {
+   num_low = vgpu_aperture_sz(vgpu) >> PAGE_SHIFT;
+   num_hi = vgpu_hidden_sz(vgpu) >> PAGE_SHIFT;
+   vgpu->ggtt_entries = vzalloc((num_low + num_hi) * sizeof(u64));
+   if (!vgpu->ggtt_entries)
+   continue;
+
+   index = vgpu_aperture_gmadr_base(vgpu) >> PAGE_SHIFT;
+   addr = (gen8_pte_t __iomem *)gvt->gt->i915->ggtt.gsm + index;
+   memcpy(vgpu->ggtt_entries, addr, num_low);
+
+   index = vgpu_hidden_gmadr_base(vgpu) >> PAGE_SHIFT;
+   addr = (gen8_pte_t __iomem *)gvt->gt->i915->ggtt.gsm + index;
+   memcpy((u64 *)vgpu->ggtt_entries + num_low, addr, num_hi);
+   }
+}
+
+/**
+ * intel_gvt_restore_ggtt - restore all vGPU's ggtt entries
+ * @gvt: intel gvt device
+ *
+ * This function is called at driver resume stage to restore
+ * GGTT entries of every active vGPU.
+ *
+ */
+void intel_gvt_restore_ggtt(struct intel_gvt *gvt)
+{
+   struct intel_vgpu *vgpu;
+   int id;
+   u32 index, num_low, num_hi;
+   void __iomem *addr;
+
+   for_each_active_vgpu(gvt, vgpu, id) {
+   if (!vgpu->ggtt_entries) {
+   gvt_vgpu_err("fail to get saved ggtt\n");
+   continue;
+   }
+
+   num_low = vgpu_aperture_sz(vgpu) >> PAGE_SHIFT;
+   num_hi = vgpu_hidden_sz(vgpu) >> PAGE_SHIFT;
+
+   index = vgpu_aperture_gmadr_base(vgpu) >> PAGE_SHIFT;
+   addr = (gen8_pte_t __iomem *)gvt->gt->i915->ggtt.gsm + index;
+   memcpy(addr, vgpu->ggtt_entries, num_low);
+   index = vgpu_hidden_gmadr_base(vgpu) >> PAGE_SHIFT;
+   addr = (gen8_pte_t __iomem *)gvt->gt->i915->ggtt.gsm + index;
+   memcpy(addr, (u64 *)vgpu->ggtt_entries + num_low, num_hi);
+
+   vfree(vgpu->ggtt_entries);
+   vgpu->ggtt_entries = NULL;
+   }
+}
diff --git a/drivers/gpu/drm/i915/gvt/gtt.h b/drivers/gpu/drm/i915/gvt/gtt.h
index b76a262dd9bc..0d2fb2714852 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.h
+++ b/drivers/gpu/drm/i915/gvt/gtt.h
@@ -279,5 +279,7 @@ int intel_vgpu_emulate_ggtt_mmio_write(struct intel_vgpu 
*vgpu,
unsigned int off, void *p_data, unsigned int bytes);
 
 void intel_vgpu_destroy_all_ppgtt_mm(struct intel_vgpu *vgpu);
+void intel_gvt_save_ggtt(struct intel_gvt *gvt);
+void intel_gvt_restore_ggtt(struct intel_gvt *gvt);
 
 #endif /* _GVT_GTT_H_ */
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index c7c561237883..3de740fa0911 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -405,6 +405,21 @@ int intel_gvt_init_device(struct drm_i915_private *i915)
   

[Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table related issues

2020-08-25 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_map_sg().

struct sg_table is a common structure used for describing a non-contiguous
memory buffer, used commonly in the DRM and graphics subsystems. It
consists of a scatterlist with memory pages and DMA addresses (sgl entry),
as well as the number of scatterlist entries: CPU pages (orig_nents entry)
and DMA mapped pages (nents entry).

It turned out that it was a common mistake to misuse nents and orig_nents
entries, calling DMA-mapping functions with a wrong number of entries or
ignoring the number of mapped entries returned by the dma_map_sg()
function.

This driver creatively uses sg_table->orig_nents to store the size of the
allocated scatterlist and ignores the number of the entries returned by
dma_map_sg function. The sg_table->orig_nents is (mis)used to properly
free the (over)allocated scatterlist.

This patch only introduces the common DMA-mapping wrappers operating
directly on the struct sg_table objects to the dmabuf related functions,
so the other drivers, which might share buffers with i915 could rely on
the properly set nents and orig_nents values.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   | 11 +++
 drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c |  7 +++
 2 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 2679380159fc..8a988592715b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -48,12 +48,9 @@ static struct sg_table *i915_gem_map_dma_buf(struct 
dma_buf_attachment *attachme
src = sg_next(src);
}
 
-   if (!dma_map_sg_attrs(attachment->dev,
- st->sgl, st->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC)) {
-   ret = -ENOMEM;
+   ret = dma_map_sgtable(attachment->dev, st, dir, DMA_ATTR_SKIP_CPU_SYNC);
+   if (ret)
goto err_free_sg;
-   }
 
return st;
 
@@ -73,9 +70,7 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
 {
struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
 
-   dma_unmap_sg_attrs(attachment->dev,
-  sg->sgl, sg->nents, dir,
-  DMA_ATTR_SKIP_CPU_SYNC);
+   dma_unmap_sgtable(attachment->dev, sg, dir, DMA_ATTR_SKIP_CPU_SYNC);
sg_free_table(sg);
kfree(sg);
 
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c 
b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
index debaf7b18ab5..be30b27e2926 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
@@ -28,10 +28,9 @@ static struct sg_table *mock_map_dma_buf(struct 
dma_buf_attachment *attachment,
sg = sg_next(sg);
}
 
-   if (!dma_map_sg(attachment->dev, st->sgl, st->nents, dir)) {
-   err = -ENOMEM;
+   err = dma_map_sgtable(attachment->dev, st, dir, 0);
+   if (err)
goto err_st;
-   }
 
return st;
 
@@ -46,7 +45,7 @@ static void mock_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
   struct sg_table *st,
   enum dma_data_direction dir)
 {
-   dma_unmap_sg(attachment->dev, st->sgl, st->nents, dir);
+   dma_unmap_sgtable(attachment->dev, st, dir, 0);
sg_free_table(st);
kfree(st);
 }
-- 
2.17.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2020-08-25 Thread Colin Xu
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 check and call gvt routine. (zhenyu)

Signed-off-by: Hang Yuan 
Signed-off-by: Colin Xu 
---
 drivers/gpu/drm/i915/i915_drv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 00292a849c34..99c15a9183c2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1177,6 +1177,8 @@ static int i915_drm_suspend(struct drm_device *dev)
 
drm_kms_helper_poll_disable(dev);
 
+   intel_gvt_suspend(dev_priv);
+
pci_save_state(pdev);
 
intel_display_suspend(dev);
@@ -1354,6 +1356,8 @@ static int i915_drm_resume(struct drm_device *dev)
 
intel_power_domains_enable(dev_priv);
 
+   intel_gvt_resume(dev_priv);
+
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
 
return 0;
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [RFC v4 09/20] drm/i915/dp: Extract drm_dp_has_mst()

2020-08-25 Thread Jani Nikula
On Tue, 25 Aug 2020, Lyude Paul  wrote:
> Just a tiny drive-by cleanup, we can consolidate i915's code for
> checking for MST support into a helper to be shared across drivers.
>
> Signed-off-by: Lyude Paul 
> Reviewed-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
>  include/drm/drm_dp_mst_helper.h | 22 ++
>  2 files changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 79c27f91f42c0..1e29d3a012856 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4699,20 +4699,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   return true;
>  }
>  
> -static bool
> -intel_dp_sink_can_mst(struct intel_dp *intel_dp)
> -{
> - u8 mstm_cap;
> -
> - if (intel_dp->dpcd[DP_DPCD_REV] < 0x12)
> - return false;
> -
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_MSTM_CAP, &mstm_cap) != 1)
> - return false;
> -
> - return mstm_cap & DP_MST_CAP;
> -}
> -
>  static bool
>  intel_dp_can_mst(struct intel_dp *intel_dp)
>  {
> @@ -4720,7 +4706,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
>  
>   return i915->params.enable_dp_mst &&
>   intel_dp->can_mst &&
> - intel_dp_sink_can_mst(intel_dp);
> + drm_dp_has_mst(&intel_dp->aux, intel_dp->dpcd);
>  }
>  
>  static void
> @@ -4729,7 +4715,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>   struct intel_encoder *encoder =
>   &dp_to_dig_port(intel_dp)->base;
> - bool sink_can_mst = intel_dp_sink_can_mst(intel_dp);
> + bool sink_can_mst = drm_dp_has_mst(&intel_dp->aux, intel_dp->dpcd);
>  
>   drm_dbg_kms(&i915->drm,
>   "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam: 
> %s\n",
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 8b9eb4db3381c..2d8983a713e8c 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -911,4 +911,26 @@ __drm_dp_mst_state_iter_get(struct drm_atomic_state 
> *state,
>   for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
>   for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr), 
> NULL, &(new_state), (__i)))
>  
> +/**
> + * drm_dp_has_mst() - check whether or not a sink supports MST
> + * @aux: The DP AUX channel to use
> + * @dpcd: A cached copy of the DPCD capabilities for this sink
> + *
> + * Returns: %True if the sink supports MST, %false otherwise
> + */
> +static inline bool

I've become more and more critical of accumulating a lot of inlines in
headers. Do we really want this in the header?

> +drm_dp_has_mst(struct drm_dp_aux *aux,
> +const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + u8 mstm_cap;
> +
> + if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
> + return false;
> +
> + if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, &mstm_cap) != 1)
> + return false;
> +
> + return !!(mstm_cap & DP_MST_CAP);

The !! is superfluous.

BR,
Jani.

> +}
> +
>  #endif

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [v3] drm/nouveau: utilize subconnector property for DP

2020-08-25 Thread Jeevan B
From: Oleg Vasilev 

Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.

v2: rebase

v3: renamed a function call

Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Jeevan B 
Signed-off-by: Oleg Vasilev 
Reviewed-by: Emil Velikov 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +
 drivers/gpu/drm/nouveau/nouveau_dp.c|  9 +
 drivers/gpu/drm/nouveau/nouveau_encoder.h   |  1 +
 3 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 7674025..955afed 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -654,6 +654,17 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
 
+   if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+   connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+   enum drm_mode_subconnector subconnector = 
DRM_MODE_SUBCONNECTOR_Unknown;
+
+   if (conn_status == connector_status_connected && nv_encoder)
+   subconnector = nv_encoder->dp.subconnector;
+   drm_object_property_set_value(&connector->base,
+   connector->dev->mode_config.dp_subconnector_property,
+   subconnector);
+   }
+
return conn_status;
 }
 
@@ -1390,6 +1401,8 @@ nouveau_connector_create(struct drm_device *dev,
kfree(nv_connector);
return ERR_PTR(ret);
}
+
+   drm_connector_attach_dp_subconnector_property(connector);
funcs = &nouveau_connector_funcs;
break;
default:
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8a0f799..3eff884 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -62,6 +62,7 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_i2c_aux *aux;
u8 dpcd[8];
+   u8 port_cap[DP_MAX_DOWNSTREAM_PORTS] = {};
int ret;
 
aux = nv_encoder->aux;
@@ -72,6 +73,14 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
if (ret)
return ret;
 
+   if (dpcd[DP_DPCD_REV] > 0x10) {
+   ret = nvkm_rdaux(aux, DP_DOWNSTREAM_PORT_0,
+port_cap, DP_MAX_DOWNSTREAM_PORTS);
+   if (ret)
+   memset(port_cap, 0, DP_MAX_DOWNSTREAM_PORTS);
+   }
+   nv_encoder->dp.subconnector = drm_dp_subconnector_type(dpcd, port_cap);
+
nv_encoder->dp.link_bw = 27000 * dpcd[1];
nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK;
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h 
b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index a72c412..49b5c10 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -64,6 +64,7 @@ struct nouveau_encoder {
struct nv50_mstm *mstm;
int link_nr;
int link_bw;
+   enum drm_mode_subconnector subconnector;
} dp;
};
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx