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

[Stephen Rothwell]

Hi all,

On Wed, 26 Aug 2020 10:18:53 +1000 Stephen Rothwell  
wrote:
>
> 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

[Intel-gfx] [PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave & Daniel -

drm-intel-fixes-2020-09-03:
drm/i915 fixes for v5.9-rc4:
- Clang build warning fix
- HDCP fixes

BR,
Jani.

The following changes since commit f75aef392f869018f78cfedf3c320a6b3fcfda6b:

  Linux 5.9-rc3 (2020-08-30 16:01:54 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-09-03

for you to fetch changes up to 57537b4e1d37002ed8cbd0a9be082104749e9d8f:

  drm/i915: Clear the repeater bit on HDCP disable (2020-09-02 10:48:23 +0300)


drm/i915 fixes for v5.9-rc4:
- Clang build warning fix
- HDCP fixes


Nathan Chancellor (1):
  drm/i915/display: Ensure that ret is always initialized in 
icl_combo_phy_verify_state

Sean Paul (2):
  drm/i915: Fix sha_text population code
  drm/i915: Clear the repeater bit on HDCP disable

 drivers/gpu/drm/i915/display/intel_combo_phy.c |  4 ++--
 drivers/gpu/drm/i915/display/intel_hdcp.c  | 32 +-
 include/drm/drm_hdcp.h |  3 +++
 3 files changed, 31 insertions(+), 8 deletions(-)

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

Re: [Intel-gfx] [PATCH 35/39] drm/i915: Encode fence specific waitqueue behaviour into the wait.flags

[Intel]

On 9/2/20 4:02 PM, Thomas Hellström (Intel) wrote:

Hi, Chris,

On 8/26/20 3:28 PM, Chris Wilson wrote:

Use the wait_queue_entry.flags to denote the special fence behaviour
(flattening continuations along fence chains, and for propagating
errors) rather than trying to detect ordinary waiters by their
functions.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_sw_fence.c | 25 +++--
  1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
b/drivers/gpu/drm/i915/i915_sw_fence.c

index 4cd2038cbe35..4e557d1c4644 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -18,10 +18,15 @@
  #define I915_SW_FENCE_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
  #endif
  -#define I915_SW_FENCE_FLAG_ALLOC BIT(3) /* after WQ_FLAG_* for 
safety */

-
  static DEFINE_SPINLOCK(i915_sw_fence_lock);
  +#define WQ_FLAG_BITS \
+    BITS_PER_TYPE(typeof_member(struct wait_queue_entry, flags))
+
+/* after WQ_FLAG_* for safety */
+#define I915_SW_FENCE_FLAG_FENCE BIT(WQ_FLAG_BITS - 1)
+#define I915_SW_FENCE_FLAG_ALLOC BIT(WQ_FLAG_BITS - 2)


Not sure if sharing the flags field with the wait.c implementation is 
fully OK either. Is the @key parameter to the wake function useable? I 
mean rather than passing just a list head could we pass something like


struct i915_sw_fence_key {
    bool no_recursion; /* Makes the wait function just put its entry 
on @continuation and return */

    int error;
    struct list_head continuation;
}

/Thomas


Actually, after doing some thinking, wouldn't just comparing against the 
internal wake function instead of the autoremove_wake_function remove 
the fragility. Would that be possible?


/Thomas


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

Re: [Intel-gfx] Various problems for the Xen for XenGT code and guide.

[Lv, Zhiyuan]

Hi Roman,

Sorry that I am a software guy and can only speak for software. In general 
there are various approaches to support graphics virtualization. GVT-g as a 
pure software approach, does not rely on any hardware I/O virtualization 
features, meanwhile, hypervisors need specific implementations. If the hardware 
supports standard virtual devices, both Xen and KVM can use them more easily. 
Thanks!

Regards,
-Zhiyuan

-Original Message-
From: Roman Shaposhnik 
Date: Thursday, September 3, 2020 at 3:56 AM
To: Zhiyuan Lv 
Cc: Jason Long , Mario Marietto , 
"igv...@lists.01.org" , "xen-de...@lists.xenproject.org" 
, "xen-de...@lists.xen.org" 
, "intel-gfx@lists.freedesktop.org" 
, "linux-ker...@vger.kernel.org" 
, Susie Li , "Tian, Kevin" 
, "Li, Weinan Z" , "Downs, Mike" 
, "Xu, Terrence" 
Subject: Re: Various problems for the Xen for XenGT code and guide.

On Wed, Sep 2, 2020 at 5:48 AM Lv, Zhiyuan  wrote:
>
> Hi,
>
> It is mainly due to the business priority change. XenGT project was 
> originally created for data center usages with XEON E3 servers which have 
> integrated processor graphics. After SkyLake E3, there are no new servers 
> capable of running GVT-g, and Intel future graphics for data center will have 
> different approaches for GPU sharing. Another reason is the XenGT upstream 
> difficulty. Different from KVMGT which has been fully merged to upstream, Xen 
> part of GVT-g still has technical opens that are hard to close quickly.

This is extremely useful -- thanks for sharing. Any chance you can
elaborate on the later part "and Intel future graphics for data center
will have different approaches for GPU sharing"?

IOW, is there anything that Intel is cooking up that may help Xen in
that department?

Thanks,
Roman.

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

Re: [Intel-gfx] Various problems for the Xen for XenGT code and guide.

[Lv, Zhiyuan]

Hi Jason,

We ever supported both XenGT and KVMGT for data center usages. Right now KVMGT 
is still used in client side for GPU sharing. That's why we are supporting 
KVMGT. Thanks!

Regards,
-Zhiyuan

-Original Message-
From: Jason Long 
Date: Wednesday, September 2, 2020 at 9:38 PM
To: Mario Marietto , "igv...@lists.01.org" 
, "xen-de...@lists.xenproject.org" 
, "xen-de...@lists.xen.org" 
, "intel-gfx@lists.freedesktop.org" 
, "linux-ker...@vger.kernel.org" 
, Susie Li , "Tian, Kevin" 
, "Li, Weinan Z" , "Downs, Mike" 
, "Xu, Terrence" , Zhiyuan Lv 

Subject: Re: Various problems for the Xen for XenGT code and guide.

Why not new XenGT for new GPU?
Intel migrated to the KVM?






On Wednesday, September 2, 2020, 05:19:18 PM GMT+4:30, Lv, Zhiyuan 
 wrote: 





Hi,

It is mainly due to the business priority change. XenGT project was originally 
created for data center usages with XEON E3 servers which have integrated 
processor graphics. After SkyLake E3, there are no new servers capable of 
running GVT-g, and Intel future graphics for data center will have different 
approaches for GPU sharing. Another reason is the XenGT upstream difficulty. 
Different from KVMGT which has been fully merged to upstream, Xen part of GVT-g 
still has technical opens that are hard to close quickly.

Sorry that we did not sync up with community in time the XenGT ramping down 
plan. Internally we have been testing XenGT until November 2019. We will update 
our setup guide for XenGT part to reflect the information. Going forward we 
will try our best to do XenGT consultant, but will not be able to do code 
rebase/test or debugging. Meanwhile, we are still maintaining KVMGT mainly for 
client integrated GPU usages. We will continue to fix issues that can be 
reproduced with KVMGT.

https://github.com/intel/gvt-linux/tree/topic/gvt-xengt
https://github.com/intel/Igvtg-xen/tree/xengt-stable-4.10

Hi Marietto, we appreciate your efforts trying GVT-g (XenGT). Hope Terrence's 
reply helps. By switching back to old gcc those compile errors should be gone. 
Meanwhile please be kindly noticed that we can only provide limited support on 
XenGT with old versions. Thanks!

Regards,
-Zhiyuan

-Original Message-

From: Jason Long 
Date: Wednesday, September 2, 2020 at 1:07 AM
To: Mario Marietto , "igv...@lists.01.org" 
, "xen-de...@lists.xenproject.org" 
, "xen-de...@lists.xen.org" 
, "intel-gfx@lists.freedesktop.org" 
, "linux-ker...@vger.kernel.org" 
, Susie Li , "Tian, Kevin" 
, Zhiyuan Lv , "Li, Weinan Z" 
, "Downs, Mike" , "Xu, Terrence" 

Subject: Re: Various problems for the Xen for XenGT code and guide.

Hello,
Why XenGT doesn't have any new version?






On Tuesday, September 1, 2020, 09:21:27 PM GMT+4:30, Xu, Terrence 
 wrote: 








Hi Mario,



Sorry to make you feel uncomfortable.



I think it is not setup guide problem, the main reason is the Xen code is very 
old (We are upgrading GVT-g code on Linux kernel side and we haven’t upgraded 
the Xen and Qemu source for XenGT for at least 2 years) but your GCC is new 
(You are using Ubuntu 20.4, the gcc version is 9+).

I have a way to workaround it, as below:

1.  apt-get install gcc-72.  ln -fs gcc-7 /usr/bin/gcc



Any more problem just let us know!



Thanks

Terrence





From: Mario Marietto  
Sent: Thursday, August 27, 2020 9:52 PM
To: Xu, Terrence ; igv...@lists.01.org; 
xen-de...@lists.xenproject.org; xen-de...@lists.xen.org; 
intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org; Li, Susie 
; Tian, Kevin ; Lv, Zhiyuan 
; Li, Weinan Z ; Downs, Mike 

Subject: Various problems for the Xen for XenGT code and guide.







Hello.










I would like to pass the integrated gpu from the host os (ubuntu 20.04) to the 
windows 10 guest os with xen. This is because xen works great for me,better 
than qemu-kvm for my specific needs and because I have only two graphic cards. 
The nvidia rtx 2080 ti that I have already passed to the guest,and the intel 
UHD 630,that can be duplicated from the host to the guest so that it can be 
used in both places without interruptions. So I'm trying to build this 
repository :

https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide#332-build-qemu--xen-for-xengt

I have to say that this guide is totally not very well written. And the code is 
full of unpatched bugs. It's a month that I'm working on that,trying to fix the 
bugs that are came out from the 2015 until today. This is not my job. This is 
my hobby. But,I need to activate the pass through for my integrated GPU so I 
don't to give up. I'm also very angry with those coders who do not do their job 
well and with those coders who do not respond to help messages. It is not 
enough to write good code to be a good programmer. It is also important to keep 
the documentation updated, to help those who cannot get the code to work. 
Anyway,I've documented every step that I did to make it work here :

https://github.com/intel/gvt-linux/issues/168

right now I'm tryi

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

[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 v9 00/17] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

[Hans de Goede]

Hi All,

So the bug-fix which prompted v8, lead to some discussion about the pwm-lpss
suspend/resume code. So as discussed this version drops the following 2
patches:

[PATCH v8 06/17] pwm: lpss: Use pwm_lpss_restore() when restoring state on 
resume
[PATCH v8 07/17] pwm: lpss: Always update state and set update bit

Replacing them with:

[PATCH v9 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on hardware state
[PATCH v9 07/17] pwm: lpss: Remove suspend/resume handlers

Andy, Thierry, can you review these 2 new patches please?

The plan still is to push the entire series to drm-intel-next-queued
(because of interdependencies) once the 2 new patches are reviewed and
the series has passed CI.

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 + LPSS PWM
-GPD Pocket  CHT + LPSS PWM
-Acer One S1003  CHT + LPSS PWM

Regards,

Hans


Changelog:

Changes in v9:
- Replace:
  [PATCH v8 06/17] pwm: lpss: Use pwm_lpss_restore() when restoring state on 
resume
  [PATCH v8 07/17] pwm: lpss: Always update state and set update bit
  with:
  [PATCH v9 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on hardware state
  [PATCH v9 07/17] pwm: lpss: Remove suspend/resume handlers

Changes in v8:
- Add a new patch dealing with the ACPI/DSDT GFX0._PS3 code poking the PWM 
controller
  in unexpected ways on some Cherry Trail devices

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 v9 02/17] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation)

[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 v9 04/17] pwm: lpss: Add range limit check for the base_unit register value

[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 
Acked-by: Thierry Reding 
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 v9 03/17] pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()

[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 
Acked-by: Thierry Reding 
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 v9 10/17] pwm: crc: Fix period changes not having any effect

[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 
Acked-by: Thierry Reding 
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 v9 16/17] drm/i915: panel: Honor the VBT PWM min setting for devs with an external PWM controller

[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 5a13089d2fc0..2b27f9b07403 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 v9 11/17] pwm: crc: Enable/disable PWM output on enable/disable

[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 
Acked-by: Thierry Reding 
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 v9 15/17] drm/i915: panel: Honor the VBT PWM frequency for devs with an external PWM controller

[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 df7472a3b9f8..5a13089d2fc0 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 v9 09/17] pwm: crc: Fix off-by-one error in the clock-divider calculations

[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 
Acked-by: Thierry Reding 
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 v9 12/17] pwm: crc: Implement apply() method to support the new atomic PWM API

[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 
Acked-by: Thierry Reding 
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,
+   

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

[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 2b27f9b07403..2eb1a3a93df1 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 v9 14/17] drm/i915: panel: Add get_vbt_pwm_freq() helper

[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 4072d7062efd..df7472a3b9f8 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] [PATCH v9 08/17] pwm: crc: Fix period / duty_cycle times being off by a factor of 256

[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 
Acked-by: Thierry Reding 
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 v9 13/17] pwm: crc: Implement get_state() method

[Hans de Goede]

Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.

Reviewed-by: Andy Shevchenko 
Acked-by: Thierry Reding 
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 v9 05/17] pwm: lpss: Add pwm_lpss_prepare_enable() helper

[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 
Acked-by: Thierry Reding 
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 v9 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware state

[Hans de Goede]

Before this commit pwm_lpss_apply() was making 2 assuming
2 pre-conditions were met by the existing hardware state:

1. That the base-unit and on-time-div read back from the
control register are those actually in use, so that it
can skip setting the update bit if the read-back value
matches the desired values.

2. That the controller is enabled when the cached
pwm_state.enabled says that the controller is enabled.

As the long history of fixes for subtle (often suspend/resume)
lpss-pwm issues shows, this assumptions are not necessary
always true.

1. Specifically is not true on some (*) Cherry Trail devices
with a nasty GFX0._PS3 method which: a. saves the ctrl reg value.
b. sets the base-unit to 0 and writes the update bit to apply/commit
c. restores the original ctrl value without setting the update bit,
so that the 0 base-unit value is still in use.

2. Assumption 2. currently is true, but only because of the code which
saves/restores the state on suspend/resume. By convention restoring the
PWM state should be done by the PWM consumer and the presence of this
code in the pmw-lpss driver is a bug. Therefor the save/restore code will
be dropped in the next patch in this series, after which this assumption
also is no longer true.

This commit changes the pwm_lpss_apply() to make any assumptions about the
state the hardware is in. Instead it makes pwm_lpss_apply() always fully
program the PWM controller, making it much less fragile.

*) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models
and various Medion models.

Signed-off-by: Hans de Goede 
---
 drivers/pwm/pwm-lpss.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 8a136ba2a583..9c5c7217c9b6 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -85,7 +85,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
unsigned long long on_time_div;
unsigned long c = lpwm->info->clk_rate, base_unit_range;
unsigned long long base_unit, freq = NSEC_PER_SEC;
-   u32 orig_ctrl, ctrl;
+   u32 ctrl;
 
do_div(freq, period_ns);
 
@@ -104,16 +104,14 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
do_div(on_time_div, period_ns);
on_time_div = 255ULL - on_time_div;
 
-   orig_ctrl = ctrl = pwm_lpss_read(pwm);
+   ctrl = pwm_lpss_read(pwm);
ctrl &= ~PWM_ON_TIME_DIV_MASK;
ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
ctrl |= on_time_div;
 
-   if (orig_ctrl != ctrl) {
-   pwm_lpss_write(pwm, ctrl);
-   pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
-   }
+   pwm_lpss_write(pwm, ctrl);
+   pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
 }
 
 static inline void pwm_lpss_cond_enable(struct pwm_device *pwm, bool cond)
@@ -124,8 +122,7 @@ static inline void pwm_lpss_cond_enable(struct pwm_device 
*pwm, bool cond)
 
 static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm,
   struct pwm_device *pwm,
-  const struct pwm_state *state,
-  bool enable)
+  const struct pwm_state *state)
 {
int ret;
 
@@ -134,12 +131,12 @@ static int pwm_lpss_prepare_enable(struct pwm_lpss_chip 
*lpwm,
return ret;
 
pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, state->period);
-   pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);
+   pwm_lpss_cond_enable(pwm, 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);
+   pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
return 0;
 }
 
@@ -152,11 +149,11 @@ static int pwm_lpss_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
pm_runtime_get_sync(chip->dev);
-   ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
+   ret = pwm_lpss_prepare_enable(lpwm, pwm, state);
if (ret)
pm_runtime_put(chip->dev);
} else {
-   ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
+   ret = pwm_lpss_prepare_enable(lpwm, pwm, state);
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
-- 
2.28.0

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

[Intel-gfx] [PATCH v9 07/17] pwm: lpss: Remove suspend/resume handlers

[Hans de Goede]

PWM controller drivers should not restore the PWM state on resume. The
convention is that PWM consumers do this by calling pwm_apply_state(),
so that it can be done at the exact moment when the consumer needs
the state to be stored, avoiding e.g. backlight flickering.

The only in kernel consumers of the pwm-lpss code, the i915 driver
and the pwm-class sysfs interface code both correctly restore the
state on resume, so there is no need to do this in the pwm-lpss code.

More-over the removed resume handler is buggy, since it blindly
restores the ctrl-register contents without setting the update
bit, which is necessary to get the controller to actually use/apply
the restored base-unit and on-time-div values.

Signed-off-by: Hans de Goede 
---
 drivers/pwm/pwm-lpss-platform.c |  1 -
 drivers/pwm/pwm-lpss.c  | 24 
 drivers/pwm/pwm-lpss.h  |  3 ---
 3 files changed, 28 deletions(-)

diff --git a/drivers/pwm/pwm-lpss-platform.c b/drivers/pwm/pwm-lpss-platform.c
index 48f34d20aecd..c6502cf7a7af 100644
--- a/drivers/pwm/pwm-lpss-platform.c
+++ b/drivers/pwm/pwm-lpss-platform.c
@@ -89,7 +89,6 @@ static int pwm_lpss_prepare(struct device *dev)
 
 static const struct dev_pm_ops pwm_lpss_platform_pm_ops = {
.prepare = pwm_lpss_prepare,
-   SET_SYSTEM_SLEEP_PM_OPS(pwm_lpss_suspend, pwm_lpss_resume)
 };
 
 static const struct acpi_device_id pwm_lpss_acpi_match[] = {
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 9c5c7217c9b6..3444c56b4bed 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -260,30 +260,6 @@ int pwm_lpss_remove(struct pwm_lpss_chip *lpwm)
 }
 EXPORT_SYMBOL_GPL(pwm_lpss_remove);
 
-int pwm_lpss_suspend(struct device *dev)
-{
-   struct pwm_lpss_chip *lpwm = dev_get_drvdata(dev);
-   int i;
-
-   for (i = 0; i < lpwm->info->npwm; i++)
-   lpwm->saved_ctrl[i] = readl(lpwm->regs + i * PWM_SIZE + PWM);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(pwm_lpss_suspend);
-
-int pwm_lpss_resume(struct device *dev)
-{
-   struct pwm_lpss_chip *lpwm = dev_get_drvdata(dev);
-   int i;
-
-   for (i = 0; i < lpwm->info->npwm; i++)
-   writel(lpwm->saved_ctrl[i], lpwm->regs + i * PWM_SIZE + PWM);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(pwm_lpss_resume);
-
 MODULE_DESCRIPTION("PWM driver for Intel LPSS");
 MODULE_AUTHOR("Mika Westerberg ");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/pwm/pwm-lpss.h b/drivers/pwm/pwm-lpss.h
index 7909fa12fca2..70db7e389d66 100644
--- a/drivers/pwm/pwm-lpss.h
+++ b/drivers/pwm/pwm-lpss.h
@@ -19,7 +19,6 @@ struct pwm_lpss_chip {
struct pwm_chip chip;
void __iomem *regs;
const struct pwm_lpss_boardinfo *info;
-   u32 saved_ctrl[MAX_PWMS];
 };
 
 struct pwm_lpss_boardinfo {
@@ -37,7 +36,5 @@ struct pwm_lpss_boardinfo {
 struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev, struct resource *r,
 const struct pwm_lpss_boardinfo *info);
 int pwm_lpss_remove(struct pwm_lpss_chip *lpwm);
-int pwm_lpss_suspend(struct device *dev);
-int pwm_lpss_resume(struct device *dev);
 
 #endif /* __PWM_LPSS_H */
-- 
2.28.0

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

Re: [Intel-gfx] [PATCH v9 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware state

[Thierry Reding]

On Thu, Sep 03, 2020 at 12:51:03PM +0200, Hans de Goede wrote:
> Before this commit pwm_lpss_apply() was making 2 assuming
> 2 pre-conditions were met by the existing hardware state:

I think that "making 2" is too much.

> 
> 1. That the base-unit and on-time-div read back from the
> control register are those actually in use, so that it
> can skip setting the update bit if the read-back value
> matches the desired values.
> 
> 2. That the controller is enabled when the cached
> pwm_state.enabled says that the controller is enabled.
> 
> As the long history of fixes for subtle (often suspend/resume)
> lpss-pwm issues shows, this assumptions are not necessary
> always true.
> 
> 1. Specifically is not true on some (*) Cherry Trail devices
> with a nasty GFX0._PS3 method which: a. saves the ctrl reg value.
> b. sets the base-unit to 0 and writes the update bit to apply/commit
> c. restores the original ctrl value without setting the update bit,
> so that the 0 base-unit value is still in use.
> 
> 2. Assumption 2. currently is true, but only because of the code which
> saves/restores the state on suspend/resume. By convention restoring the
> PWM state should be done by the PWM consumer and the presence of this
> code in the pmw-lpss driver is a bug. Therefor the save/restore code will
> be dropped in the next patch in this series, after which this assumption
> also is no longer true.
> 
> This commit changes the pwm_lpss_apply() to make any assumptions about the

Did you mean to say "... to _not_ make any assumptions ..."?

> state the hardware is in. Instead it makes pwm_lpss_apply() always fully
> program the PWM controller, making it much less fragile.
> 
> *) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models
> and various Medion models.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/pwm/pwm-lpss.c | 21 +
>  1 file changed, 9 insertions(+), 12 deletions(-)

Other than the two small nits, this looks much more idiomatic and true
to the atomic API, so:

Acked-by: Thierry Reding 


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

Re: [Intel-gfx] [PATCH v9 07/17] pwm: lpss: Remove suspend/resume handlers

[Thierry Reding]

On Thu, Sep 03, 2020 at 12:51:04PM +0200, Hans de Goede wrote:
> PWM controller drivers should not restore the PWM state on resume. The
> convention is that PWM consumers do this by calling pwm_apply_state(),
> so that it can be done at the exact moment when the consumer needs
> the state to be stored, avoiding e.g. backlight flickering.
> 
> The only in kernel consumers of the pwm-lpss code, the i915 driver
> and the pwm-class sysfs interface code both correctly restore the
> state on resume, so there is no need to do this in the pwm-lpss code.
> 
> More-over the removed resume handler is buggy, since it blindly
> restores the ctrl-register contents without setting the update
> bit, which is necessary to get the controller to actually use/apply
> the restored base-unit and on-time-div values.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/pwm/pwm-lpss-platform.c |  1 -
>  drivers/pwm/pwm-lpss.c  | 24 
>  drivers/pwm/pwm-lpss.h  |  3 ---
>  3 files changed, 28 deletions(-)

Nice!

Acked-by: Thierry Reding 


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

Re: [Intel-gfx] [PATCH v9 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware state

[Hans de Goede]

Hi,

On 9/3/20 12:59 PM, Thierry Reding wrote:

On Thu, Sep 03, 2020 at 12:51:03PM +0200, Hans de Goede wrote:

Before this commit pwm_lpss_apply() was making 2 assuming
2 pre-conditions were met by the existing hardware state:


I think that "making 2" is too much.


You're right at first the sentence had something about making
2 assumptions, then I added pre-conditions in there for it
to better describe the problem...


1. That the base-unit and on-time-div read back from the
control register are those actually in use, so that it
can skip setting the update bit if the read-back value
matches the desired values.

2. That the controller is enabled when the cached
pwm_state.enabled says that the controller is enabled.

As the long history of fixes for subtle (often suspend/resume)
lpss-pwm issues shows, this assumptions are not necessary
always true.

1. Specifically is not true on some (*) Cherry Trail devices
with a nasty GFX0._PS3 method which: a. saves the ctrl reg value.
b. sets the base-unit to 0 and writes the update bit to apply/commit
c. restores the original ctrl value without setting the update bit,
so that the 0 base-unit value is still in use.

2. Assumption 2. currently is true, but only because of the code which
saves/restores the state on suspend/resume. By convention restoring the
PWM state should be done by the PWM consumer and the presence of this
code in the pmw-lpss driver is a bug. Therefor the save/restore code will
be dropped in the next patch in this series, after which this assumption
also is no longer true.

This commit changes the pwm_lpss_apply() to make any assumptions about the


Did you mean to say "... to _not_ make any assumptions ..."?


Yes, oops. That is a small but important difference.

I'll do a v10 with your 2 Acked-by's added and both commit msg issues fixed.

Hopefully that will be the last version.


state the hardware is in. Instead it makes pwm_lpss_apply() always fully
program the PWM controller, making it much less fragile.

*) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models
and various Medion models.

Signed-off-by: Hans de Goede 
---
  drivers/pwm/pwm-lpss.c | 21 +
  1 file changed, 9 insertions(+), 12 deletions(-)


Other than the two small nits, this looks much more idiomatic and true
to the atomic API, so:

Acked-by: Thierry Reding 


Thank you.

Regards,

Hans

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

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

[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 v10 00/17] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

[Hans de Goede]

Hi All,

Here is hopefully the last version of this series, as everything seems
to be ready for merging this now.

The only difference from v9 is correcting some mistakes in the commit-msg of:
[PATCH v10 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on hardware state

I plan is to push the entire series to drm-intel-next-queued
(because of interdependencies) once the series has passed CI.

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 + LPSS PWM
-GPD Pocket  CHT + LPSS PWM
-Acer One S1003  CHT + LPSS PWM

Regards,

Hans


Changelog:

Changes in v10:
- Fixup the commit msg of:
  [PATCH v10 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on hardware state

Changes in v9:
- Replace:
  [PATCH v8 06/17] pwm: lpss: Use pwm_lpss_restore() when restoring state on 
resume
  [PATCH v8 07/17] pwm: lpss: Always update state and set update bit
  with:
  [PATCH v9 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on hardware state
  [PATCH v9 07/17] pwm: lpss: Remove suspend/resume handlers

Changes in v8:
- Add a new patch dealing with the ACPI/DSDT GFX0._PS3 code poking the PWM 
controller
  in unexpected ways on some Cherry Trail devices

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 v10 05/17] pwm: lpss: Add pwm_lpss_prepare_enable() helper

[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 
Acked-by: Thierry Reding 
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 v10 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware state

[Hans de Goede]

Before this commit pwm_lpss_apply() was assuming 2 pre-conditions
were met by the existing hardware state:

1. That the base-unit and on-time-div read back from the
control register are those actually in use, so that it
can skip setting the update bit if the read-back value
matches the desired values.

2. That the controller is enabled when the cached
pwm_state.enabled says that the controller is enabled.

As the long history of fixes for subtle (often suspend/resume)
lpss-pwm issues shows, these assumptions are not necessary
always true.

1. Specifically is not true on some (*) Cherry Trail devices
with a nasty GFX0._PS3 method which: a. saves the ctrl reg value.
b. sets the base-unit to 0 and writes the update bit to apply/commit
c. restores the original ctrl value without setting the update bit,
so that the 0 base-unit value is still in use.

2. Assumption 2. currently is true, but only because of the code which
saves/restores the state on suspend/resume. By convention restoring the
PWM state should be done by the PWM consumer and the presence of this
code in the pmw-lpss driver is a bug. Therefor the save/restore code will
be dropped in the next patch in this series, after which this assumption
also is no longer true.

This commit changes the pwm_lpss_apply() to not make any assumptions about
the state the hardware is in. Instead it makes pwm_lpss_apply() always
fully program the PWM controller, making it much less fragile.

*) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models
and various Medion models.

Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
---
Changes in v10:
- Fixup some wording / mistakes in the commit message

Changes in v9:
- This is a new patch in v9 of this series
---
 drivers/pwm/pwm-lpss.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 8a136ba2a583..9c5c7217c9b6 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -85,7 +85,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
unsigned long long on_time_div;
unsigned long c = lpwm->info->clk_rate, base_unit_range;
unsigned long long base_unit, freq = NSEC_PER_SEC;
-   u32 orig_ctrl, ctrl;
+   u32 ctrl;
 
do_div(freq, period_ns);
 
@@ -104,16 +104,14 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
do_div(on_time_div, period_ns);
on_time_div = 255ULL - on_time_div;
 
-   orig_ctrl = ctrl = pwm_lpss_read(pwm);
+   ctrl = pwm_lpss_read(pwm);
ctrl &= ~PWM_ON_TIME_DIV_MASK;
ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
ctrl |= on_time_div;
 
-   if (orig_ctrl != ctrl) {
-   pwm_lpss_write(pwm, ctrl);
-   pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
-   }
+   pwm_lpss_write(pwm, ctrl);
+   pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
 }
 
 static inline void pwm_lpss_cond_enable(struct pwm_device *pwm, bool cond)
@@ -124,8 +122,7 @@ static inline void pwm_lpss_cond_enable(struct pwm_device 
*pwm, bool cond)
 
 static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm,
   struct pwm_device *pwm,
-  const struct pwm_state *state,
-  bool enable)
+  const struct pwm_state *state)
 {
int ret;
 
@@ -134,12 +131,12 @@ static int pwm_lpss_prepare_enable(struct pwm_lpss_chip 
*lpwm,
return ret;
 
pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, state->period);
-   pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);
+   pwm_lpss_cond_enable(pwm, 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);
+   pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
return 0;
 }
 
@@ -152,11 +149,11 @@ static int pwm_lpss_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
pm_runtime_get_sync(chip->dev);
-   ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
+   ret = pwm_lpss_prepare_enable(lpwm, pwm, state);
if (ret)
pm_runtime_put(chip->dev);
} else {
-   ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
+   ret = pwm_lpss_prepare_enable(lpwm, pwm, state);
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
-- 
2.28.0

___
Intel-gfx mailing list
Intel-g

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

[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 v10 10/17] pwm: crc: Fix period changes not having any effect

[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 
Acked-by: Thierry Reding 
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 v10 13/17] pwm: crc: Implement get_state() method

[Hans de Goede]

Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.

Reviewed-by: Andy Shevchenko 
Acked-by: Thierry Reding 
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 v10 07/17] pwm: lpss: Remove suspend/resume handlers

[Hans de Goede]

PWM controller drivers should not restore the PWM state on resume. The
convention is that PWM consumers do this by calling pwm_apply_state(),
so that it can be done at the exact moment when the consumer needs
the state to be stored, avoiding e.g. backlight flickering.

The only in kernel consumers of the pwm-lpss code, the i915 driver
and the pwm-class sysfs interface code both correctly restore the
state on resume, so there is no need to do this in the pwm-lpss code.

More-over the removed resume handler is buggy, since it blindly
restores the ctrl-register contents without setting the update
bit, which is necessary to get the controller to actually use/apply
the restored base-unit and on-time-div values.

Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
---
Changes in v9:
- This is a new patch in v9 of this series
---
 drivers/pwm/pwm-lpss-platform.c |  1 -
 drivers/pwm/pwm-lpss.c  | 24 
 drivers/pwm/pwm-lpss.h  |  3 ---
 3 files changed, 28 deletions(-)

diff --git a/drivers/pwm/pwm-lpss-platform.c b/drivers/pwm/pwm-lpss-platform.c
index 48f34d20aecd..c6502cf7a7af 100644
--- a/drivers/pwm/pwm-lpss-platform.c
+++ b/drivers/pwm/pwm-lpss-platform.c
@@ -89,7 +89,6 @@ static int pwm_lpss_prepare(struct device *dev)
 
 static const struct dev_pm_ops pwm_lpss_platform_pm_ops = {
.prepare = pwm_lpss_prepare,
-   SET_SYSTEM_SLEEP_PM_OPS(pwm_lpss_suspend, pwm_lpss_resume)
 };
 
 static const struct acpi_device_id pwm_lpss_acpi_match[] = {
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 9c5c7217c9b6..3444c56b4bed 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -260,30 +260,6 @@ int pwm_lpss_remove(struct pwm_lpss_chip *lpwm)
 }
 EXPORT_SYMBOL_GPL(pwm_lpss_remove);
 
-int pwm_lpss_suspend(struct device *dev)
-{
-   struct pwm_lpss_chip *lpwm = dev_get_drvdata(dev);
-   int i;
-
-   for (i = 0; i < lpwm->info->npwm; i++)
-   lpwm->saved_ctrl[i] = readl(lpwm->regs + i * PWM_SIZE + PWM);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(pwm_lpss_suspend);
-
-int pwm_lpss_resume(struct device *dev)
-{
-   struct pwm_lpss_chip *lpwm = dev_get_drvdata(dev);
-   int i;
-
-   for (i = 0; i < lpwm->info->npwm; i++)
-   writel(lpwm->saved_ctrl[i], lpwm->regs + i * PWM_SIZE + PWM);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(pwm_lpss_resume);
-
 MODULE_DESCRIPTION("PWM driver for Intel LPSS");
 MODULE_AUTHOR("Mika Westerberg ");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/pwm/pwm-lpss.h b/drivers/pwm/pwm-lpss.h
index 7909fa12fca2..70db7e389d66 100644
--- a/drivers/pwm/pwm-lpss.h
+++ b/drivers/pwm/pwm-lpss.h
@@ -19,7 +19,6 @@ struct pwm_lpss_chip {
struct pwm_chip chip;
void __iomem *regs;
const struct pwm_lpss_boardinfo *info;
-   u32 saved_ctrl[MAX_PWMS];
 };
 
 struct pwm_lpss_boardinfo {
@@ -37,7 +36,5 @@ struct pwm_lpss_boardinfo {
 struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev, struct resource *r,
 const struct pwm_lpss_boardinfo *info);
 int pwm_lpss_remove(struct pwm_lpss_chip *lpwm);
-int pwm_lpss_suspend(struct device *dev);
-int pwm_lpss_resume(struct device *dev);
 
 #endif /* __PWM_LPSS_H */
-- 
2.28.0

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

[Intel-gfx] [PATCH v10 09/17] pwm: crc: Fix off-by-one error in the clock-divider calculations

[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 
Acked-by: Thierry Reding 
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 v10 16/17] drm/i915: panel: Honor the VBT PWM min setting for devs with an external PWM controller

[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 5a13089d2fc0..2b27f9b07403 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 v10 15/17] drm/i915: panel: Honor the VBT PWM frequency for devs with an external PWM controller

[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 df7472a3b9f8..5a13089d2fc0 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 v10 08/17] pwm: crc: Fix period / duty_cycle times being off by a factor of 256

[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 
Acked-by: Thierry Reding 
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 v10 04/17] pwm: lpss: Add range limit check for the base_unit register value

[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 
Acked-by: Thierry Reding 
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 v10 03/17] pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()

[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 
Acked-by: Thierry Reding 
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 v10 14/17] drm/i915: panel: Add get_vbt_pwm_freq() helper

[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 4072d7062efd..df7472a3b9f8 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] [PATCH v10 17/17] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller

[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 2b27f9b07403..2eb1a3a93df1 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 v10 12/17] pwm: crc: Implement apply() method to support the new atomic PWM API

[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 
Acked-by: Thierry Reding 
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,
+   

[Intel-gfx] [PATCH v10 11/17] pwm: crc: Enable/disable PWM output on enable/disable

[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 
Acked-by: Thierry Reding 
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] ✗ Fi.CI.CHECKPATCH: warning for acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

[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/81284/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
1697ae1e044d ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase
3d61460209ae ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at 
activation)
3323c5fd40fd pwm: lpss: Fix off by one error in base_unit math in 
pwm_lpss_prepare()
a5e5abaeb383 pwm: lpss: Add range limit check for the base_unit register value
35844baeea43 pwm: lpss: Add pwm_lpss_prepare_enable() helper
-:46: CHECK:BOOL_COMPARISON: Using comparison to false is error prone
#46: FILE: drivers/pwm/pwm-lpss.c:137:
+   pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);

-:51: CHECK:BOOL_COMPARISON: Using comparison to true is error prone
#51: 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
6d4f51125b5e pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware 
state
-:93: CHECK:BOOL_COMPARISON: Using comparison to false is error prone
#93: FILE: drivers/pwm/pwm-lpss.c:134:
+   pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);

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

total: 0 errors, 0 warnings, 2 checks, 63 lines checked
f1828c9c0d08 pwm: lpss: Remove suspend/resume handlers
1bcad686586e pwm: crc: Fix period / duty_cycle times being off by a factor of 
256
f35514f16ee3 pwm: crc: Fix off-by-one error in the clock-divider calculations
fba1b41f563c pwm: crc: Fix period changes not having any effect
17dac256640e pwm: crc: Enable/disable PWM output on enable/disable
c2ba8c2eec46 pwm: crc: Implement apply() method to support the new atomic PWM 
API
edc4cede8f26 pwm: crc: Implement get_state() method
4ab3de063861 drm/i915: panel: Add get_vbt_pwm_freq() helper
cb09d0ae8c40 drm/i915: panel: Honor the VBT PWM frequency for devs with an 
external PWM controller
5751ab4b4c97 drm/i915: panel: Honor the VBT PWM min setting for devs with an 
external PWM controller
71e10e2a06cb 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

Re: [Intel-gfx] [PATCH 35/39] drm/i915: Encode fence specific waitqueue behaviour into the wait.flags

[Chris Wilson]

Quoting Thomas Hellström (Intel) (2020-09-03 10:50:45)
> 
> On 9/2/20 4:02 PM, Thomas Hellström (Intel) wrote:
> > Hi, Chris,
> >
> > On 8/26/20 3:28 PM, Chris Wilson wrote:
> >> Use the wait_queue_entry.flags to denote the special fence behaviour
> >> (flattening continuations along fence chains, and for propagating
> >> errors) rather than trying to detect ordinary waiters by their
> >> functions.
> >>
> >> Signed-off-by: Chris Wilson 
> >> ---
> >>   drivers/gpu/drm/i915/i915_sw_fence.c | 25 +++--
> >>   1 file changed, 15 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
> >> b/drivers/gpu/drm/i915/i915_sw_fence.c
> >> index 4cd2038cbe35..4e557d1c4644 100644
> >> --- a/drivers/gpu/drm/i915/i915_sw_fence.c
> >> +++ b/drivers/gpu/drm/i915/i915_sw_fence.c
> >> @@ -18,10 +18,15 @@
> >>   #define I915_SW_FENCE_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
> >>   #endif
> >>   -#define I915_SW_FENCE_FLAG_ALLOC BIT(3) /* after WQ_FLAG_* for 
> >> safety */
> >> -
> >>   static DEFINE_SPINLOCK(i915_sw_fence_lock);
> >>   +#define WQ_FLAG_BITS \
> >> +    BITS_PER_TYPE(typeof_member(struct wait_queue_entry, flags))
> >> +
> >> +/* after WQ_FLAG_* for safety */
> >> +#define I915_SW_FENCE_FLAG_FENCE BIT(WQ_FLAG_BITS - 1)
> >> +#define I915_SW_FENCE_FLAG_ALLOC BIT(WQ_FLAG_BITS - 2)
> >
> > Not sure if sharing the flags field with the wait.c implementation is 
> > fully OK either. Is the @key parameter to the wake function useable? I 
> > mean rather than passing just a list head could we pass something like
> >
> > struct i915_sw_fence_key {
> >     bool no_recursion; /* Makes the wait function just put its entry 
> > on @continuation and return */
> >     int error;
> >     struct list_head continuation;
> > }

That would mean wait_event-esque routines do not work on a fence.

> internal wake function instead of the autoremove_wake_function remove 
> the fragility. Would that be possible?

autoremove is the function used by display for its wait_event loop over
multiple sources.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[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/81284/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8957 -> Patchwork_18436


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-n3050:   [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][5] -> [FAIL][6] ([i915#1372])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- 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_8957/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_18436/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-cfl-8109u:   [TIMEOUT][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/fi-cfl-8109u/igt@gem_exec_gttf...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/fi-cfl-8109u/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_parallel@engines@contexts:
- fi-cfl-8109u:   [INCOMPLETE][11] ([i915#2398]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/fi-cfl-8109u/igt@gem_exec_parallel@engi...@contexts.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/fi-cfl-8109u/igt@gem_exec_parallel@engi...@contexts.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka:   [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/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:  [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html

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

  [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2398]: https://gitlab.freedesktop.org/drm/intel/issues/2398


Participating hosts (38 -> 33)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper 


Build changes
-

  * Linux: CI_DRM_8957 -> Patchwork_18436

  CI-20190529: 20190529
  CI_DRM_8957: c3355f060f0d6b1c45f456c4cdb995edfd496603 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5777: c240b5c00d58860e376b012cc3c883c17ae63f37 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18436: 71e10e2a06cbcd64bf43e06ec96a07255108535a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

71e10e2a06cb drm/i915: panel: Use atomic PWM API for devs with an external PWM 
controller
5751ab4b4c97 drm/i915: panel: Honor the VBT PWM min setting for devs with an 
external PWM controller
cb09d0ae8c40 drm/i915: panel: Ho

[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

[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/81287/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
1168abd5ce8d ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase
49747f4e3a9e ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at 
activation)
97b4a9aebcb4 pwm: lpss: Fix off by one error in base_unit math in 
pwm_lpss_prepare()
2e7faec371d2 pwm: lpss: Add range limit check for the base_unit register value
94a41c16c5ba pwm: lpss: Add pwm_lpss_prepare_enable() helper
-:46: CHECK:BOOL_COMPARISON: Using comparison to false is error prone
#46: FILE: drivers/pwm/pwm-lpss.c:137:
+   pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);

-:51: CHECK:BOOL_COMPARISON: Using comparison to true is error prone
#51: 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
b6ce0150e736 pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware 
state
-:93: CHECK:BOOL_COMPARISON: Using comparison to false is error prone
#93: FILE: drivers/pwm/pwm-lpss.c:134:
+   pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);

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

total: 0 errors, 0 warnings, 2 checks, 63 lines checked
48f37ff234b3 pwm: lpss: Remove suspend/resume handlers
247ad837e2cd pwm: crc: Fix period / duty_cycle times being off by a factor of 
256
0b9d965a728a pwm: crc: Fix off-by-one error in the clock-divider calculations
666a424bb1a8 pwm: crc: Fix period changes not having any effect
f29b5d035a49 pwm: crc: Enable/disable PWM output on enable/disable
88ea19297024 pwm: crc: Implement apply() method to support the new atomic PWM 
API
ad30d11970a4 pwm: crc: Implement get_state() method
240678c00b3d drm/i915: panel: Add get_vbt_pwm_freq() helper
d1aacec4e432 drm/i915: panel: Honor the VBT PWM frequency for devs with an 
external PWM controller
7e1d6106ba3a drm/i915: panel: Honor the VBT PWM min setting for devs with an 
external PWM controller
5f2ad76ad27d 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

Re: [Intel-gfx] [PATCH 35/39] drm/i915: Encode fence specific waitqueue behaviour into the wait.flags

[Intel]

On 9/3/20 1:32 PM, Chris Wilson wrote:

Quoting Thomas Hellström (Intel) (2020-09-03 10:50:45)

On 9/2/20 4:02 PM, Thomas Hellström (Intel) wrote:

Hi, Chris,

On 8/26/20 3:28 PM, Chris Wilson wrote:

Use the wait_queue_entry.flags to denote the special fence behaviour
(flattening continuations along fence chains, and for propagating
errors) rather than trying to detect ordinary waiters by their
functions.

Signed-off-by: Chris Wilson 
---
   drivers/gpu/drm/i915/i915_sw_fence.c | 25 +++--
   1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 4cd2038cbe35..4e557d1c4644 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -18,10 +18,15 @@
   #define I915_SW_FENCE_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
   #endif
   -#define I915_SW_FENCE_FLAG_ALLOC BIT(3) /* after WQ_FLAG_* for
safety */
-
   static DEFINE_SPINLOCK(i915_sw_fence_lock);
   +#define WQ_FLAG_BITS \
+    BITS_PER_TYPE(typeof_member(struct wait_queue_entry, flags))
+
+/* after WQ_FLAG_* for safety */
+#define I915_SW_FENCE_FLAG_FENCE BIT(WQ_FLAG_BITS - 1)
+#define I915_SW_FENCE_FLAG_ALLOC BIT(WQ_FLAG_BITS - 2)

Not sure if sharing the flags field with the wait.c implementation is
fully OK either. Is the @key parameter to the wake function useable? I
mean rather than passing just a list head could we pass something like

struct i915_sw_fence_key {
     bool no_recursion; /* Makes the wait function just put its entry
on @continuation and return */
     int error;
     struct list_head continuation;
}

That would mean wait_event-esque routines do not work on a fence.


OK, that is a no-go then.




internal wake function instead of the autoremove_wake_function remove
the fragility. Would that be possible?

autoremove is the function used by display for its wait_event loop over
multiple sources.


Hmm. I don't think I follow. I meant instead of

if (pos->func == autoremove_wake_function)
   ...
else
   do_i915_specific_stuff;

we use

if (pos->func != i915_sw_fence_wake)
    ...
else
   do_i915_specific_stuff;

/Thomas





-Chris

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

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

[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/81287/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8957 -> Patchwork_18437


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.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_8957/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-cfl-8109u:   [TIMEOUT][5] -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/fi-cfl-8109u/igt@gem_exec_gttf...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/fi-cfl-8109u/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_parallel@engines@contexts:
- fi-cfl-8109u:   [INCOMPLETE][7] ([i915#2398]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/fi-cfl-8109u/igt@gem_exec_parallel@engi...@contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/fi-cfl-8109u/igt@gem_exec_parallel@engi...@contexts.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka:   [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/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:  [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html

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

  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2398]: https://gitlab.freedesktop.org/drm/intel/issues/2398


Participating hosts (38 -> 33)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper 


Build changes
-

  * Linux: CI_DRM_8957 -> Patchwork_18437

  CI-20190529: 20190529
  CI_DRM_8957: c3355f060f0d6b1c45f456c4cdb995edfd496603 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5777: c240b5c00d58860e376b012cc3c883c17ae63f37 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18437: 5f2ad76ad27d083865972d2c36d0c928b5117e75 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5f2ad76ad27d drm/i915: panel: Use atomic PWM API for devs with an external PWM 
controller
7e1d6106ba3a drm/i915: panel: Honor the VBT PWM min setting for devs with an 
external PWM controller
d1aacec4e432 drm/i915: panel: Honor the VBT PWM frequency for devs with an 
external PWM controller
240678c00b3d drm/i915: panel: Add get_vbt_pwm_freq() helper
ad30d11970a4 pwm: crc: Implement get_state() method
88ea19297024 pwm: crc: Implement apply() method to support the new atomic PWM 
API
f29b5d035a49 pwm: crc: Enable/disable PWM output on enable/disable
666a424bb1a8 pwm: crc: Fix period changes not having any effect
0b9d965a728a pwm: crc: Fix off-by-one error in the clock-divider calculations
247ad837e2cd pwm: crc: Fix period / duty_cycle times being off by a factor of 
256
48f37ff234b3 pwm: lpss: Remove suspend/resume handlers
b6ce0150e736 pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware 
state
94a41c16c5ba pwm: lpss: Add pwm_lpss_prepare_enable() helper
2e

[Intel-gfx] [PATCH 4/4] drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support

[Anshuman Gupta]

Enable HDCP 1.4 over DP MST for Gen12.
This also enable the stream encryption support for
older generations.

Cc: Ramalingam C 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 ++
 drivers/gpu/drm/i915/display/intel_hdcp.c   | 36 +
 2 files changed, 26 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index c6107182519f..932190526919 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -809,13 +809,9 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
 
-
-   /* TODO: Figure out how to make HDCP work on GEN12+ */
-   if (INTEL_GEN(dev_priv) < 12) {
-   ret = intel_dp_init_hdcp(dig_port, intel_connector);
-   if (ret)
-   DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
-   }
+   ret = intel_dp_init_hdcp(dig_port, intel_connector);
+   if (ret)
+   drm_dbg_kms(&dev_priv->drm, "HDCP init failed, skipping.\n");
 
/*
 * Reuse the prop from the SST connector because we're
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index f401fdaa7336..64dbd3cb0571 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -612,7 +612,12 @@ int intel_hdcp_auth_downstream(struct intel_connector 
*connector)
return ret;
 }
 
-/* Implements Part 1 of the HDCP authorization procedure */
+/*
+ * Implements Part 1 of the HDCP authorization procedure.
+ * Authentication Part 1 steps for Multi-stream DisplayPort.
+ * Step 1. Auth Part 1 sequence on the driving MST Trasport Link.
+ * Step 2. Enable encryption for each stream that requires encryption.
+ */
 static int intel_hdcp_auth(struct intel_connector *connector)
 {
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
@@ -766,10 +771,14 @@ static int intel_hdcp_auth(struct intel_connector 
*connector)
return -ETIMEDOUT;
}
 
-   /*
-* XXX: If we have MST-connected devices, we need to enable encryption
-* on those as well.
-*/
+   /* DP MST Auth Part 1 Step 2.a and Step 2.b */
+   if (shim->stream_encryption) {
+   ret = shim->stream_encryption(dig_port, true);
+   if (ret) {
+   drm_err(&dev_priv->drm, "Failed to enable HDCP 1.4 
stream enc\n");
+   return ret;
+   }
+   }
 
if (repeater_present)
return intel_hdcp_auth_downstream(connector);
@@ -793,15 +802,16 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
 
/*
 * If there are other connectors on this port using HDCP, don't disable
-* it. Instead, toggle the HDCP signalling off on that particular
-* connector/pipe and exit.
+* it. Instead, deselect HDCP Multiplestream Bit on that particular
+* connector/pipe (Step 1), poll for stream encryption status to be
+* to be disable (Step 2) and exit.
 */
-   if (dig_port->num_hdcp_streams > 0) {
-   ret = hdcp->shim->toggle_signalling(dig_port,
-   cpu_transcoder, false);
-   if (ret)
-   DRM_ERROR("Failed to disable HDCP signalling\n");
-   return ret;
+   if (dig_port->num_hdcp_streams > 0 && hdcp->shim->stream_encryption) {
+   ret = hdcp->shim->stream_encryption(dig_port, false);
+   if (ret) {
+   drm_err(&dev_priv->drm, "Failed to disable HDCP 1.4 
stream enc\n");
+   return ret;
+   }
}
 
hdcp->hdcp_encrypted = false;
-- 
2.26.2

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

[Intel-gfx] [PATCH 2/4] drm/i915/hdcp: Move HDCP enc status timeout to header

[Anshuman Gupta]

DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used by both HDCP{1.x,2.x} stream status timeout.

Related: 7e90e8d0c0ea ("drm/i915: Increase timeout for Encrypt
status change")
Cc: Ramalingam C 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 9 -
 drivers/gpu/drm/i915/display/intel_hdcp.h | 2 ++
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 1d5026bb45a4..f401fdaa7336 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -23,7 +23,6 @@
 #include "intel_connector.h"
 
 #define KEY_LOAD_TRIES 5
-#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS   50
 #define HDCP2_LC_RETRY_CNT 3
 
 static
@@ -762,7 +761,7 @@ static int intel_hdcp_auth(struct intel_connector 
*connector)
if (intel_de_wait_for_set(dev_priv,
  HDCP_STATUS(dev_priv, cpu_transcoder, port),
  HDCP_STATUS_ENC,
- ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
+ HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
drm_err(&dev_priv->drm, "Timed out waiting for encryption\n");
return -ETIMEDOUT;
}
@@ -809,7 +808,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
if (intel_de_wait_for_clear(dev_priv,
HDCP_STATUS(dev_priv, cpu_transcoder, port),
-   ~0, ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
+   ~0, HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) 
{
drm_err(&dev_priv->drm,
"Failed to disable HDCP, timeout clearing status\n");
return -ETIMEDOUT;
@@ -1662,7 +1661,7 @@ static int hdcp2_enable_encryption(struct intel_connector 
*connector)
HDCP2_STATUS(dev_priv, cpu_transcoder,
 port),
LINK_ENCRYPTION_STATUS,
-   ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
+   HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
 
return ret;
 }
@@ -1686,7 +1685,7 @@ static int hdcp2_disable_encryption(struct 
intel_connector *connector)
  HDCP2_STATUS(dev_priv, cpu_transcoder,
   port),
  LINK_ENCRYPTION_STATUS,
- ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
+ HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
if (ret == -ETIMEDOUT)
drm_dbg_kms(&dev_priv->drm, "Disable Encryption Timedout");
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index bc51c1e9b481..b912a3a0f5b8 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -8,6 +8,8 @@
 
 #include 
 
+#define HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS  50
+
 struct drm_connector;
 struct drm_connector_state;
 struct drm_i915_private;
-- 
2.26.2

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

[Intel-gfx] [PATCH 0/4] Gen12 HDCP 1.4 support on DP MST

[Anshuman Gupta]

This is the version after addressing the review comment from 
sean over RFC patch https://patchwork.freedesktop.org/series/81222/

Addressed Below Comments:
Typo fixes.
Cosmetic Fixes.
Used single hook for stream select and stream status validation. 

Anshuman Gupta (4):
  drm/i915/hdcp: DP MST transcoder for link and stream
  drm/i915/hdcp: Move HDCP enc status timeout to header
  drm/i915/hdcp: HDCP stream encryption support
  drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support

 drivers/gpu/drm/i915/display/intel_ddi.c  | 12 +--
 drivers/gpu/drm/i915/display/intel_ddi.h  |  6 +-
 .../drm/i915/display/intel_display_types.h|  6 ++
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c  | 80 ---
 drivers/gpu/drm/i915/display/intel_dp_mst.c   | 12 +--
 drivers/gpu/drm/i915/display/intel_hdcp.c | 60 +-
 drivers/gpu/drm/i915/display/intel_hdcp.h |  4 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c | 14 ++--
 drivers/gpu/drm/i915/i915_reg.h   |  1 +
 9 files changed, 138 insertions(+), 57 deletions(-)

-- 
2.26.2

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

[Intel-gfx] [PATCH 3/4] drm/i915/hdcp: HDCP stream encryption support

[Anshuman Gupta]

Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.

HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving that link
in order to enable/disable the stream encryption.

Both of above requirement are same for all Gen with respect to
B.Spec Documentation.

Cc: Ramalingam C 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  | 10 +--
 drivers/gpu/drm/i915/display/intel_ddi.h  |  6 +-
 .../drm/i915/display/intel_display_types.h|  4 +
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c  | 80 ---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 14 ++--
 drivers/gpu/drm/i915/i915_reg.h   |  1 +
 6 files changed, 90 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5bf3619c64f6..06f61d5c37be 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1849,9 +1849,9 @@ void intel_ddi_disable_transcoder_func(const struct 
intel_crtc_state *crtc_state
}
 }
 
-int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
-enum transcoder cpu_transcoder,
-bool enable)
+int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
+  enum transcoder cpu_transcoder,
+  bool enable, u32 hdcp_mask)
 {
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -1866,9 +1866,9 @@ int intel_ddi_toggle_hdcp_signalling(struct intel_encoder 
*intel_encoder,
 
tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
-   tmp |= TRANS_DDI_HDCP_SIGNALLING;
+   tmp |= hdcp_mask;
else
-   tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+   tmp &= ~hdcp_mask;
intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h 
b/drivers/gpu/drm/i915/display/intel_ddi.h
index f5fb62fc9400..69d9e495992c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -43,9 +43,9 @@ void intel_ddi_compute_min_voltage_level(struct 
drm_i915_private *dev_priv,
 struct intel_crtc_state *crtc_state);
 u32 bxt_signal_levels(struct intel_dp *intel_dp);
 u32 ddi_signal_levels(struct intel_dp *intel_dp);
-int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
-enum transcoder cpu_transcoder,
-bool enable);
+int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
+  enum transcoder cpu_transcoder,
+  bool enable, u32 hdcp_mask);
 void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
 
 #endif /* __INTEL_DDI_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 297cfd7ad622..63d83b75f89d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -317,6 +317,10 @@ struct intel_hdcp_shim {
 enum transcoder cpu_transcoder,
 bool enable);
 
+   /* Enable/Disable stream encryption on DP MST Transport Link */
+   int (*stream_encryption)(struct intel_digital_port *dig_port,
+bool enable);
+
/* Ensures the link is still protected */
bool (*check_link)(struct intel_digital_port *dig_port,
   struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 03424d20e9f7..652d4645f255 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -16,6 +16,30 @@
 #include "intel_dp.h"
 #include "intel_hdcp.h"
 
+static unsigned int transcoder_to_stream_enc_status(enum transcoder 
cpu_transcoder)
+{
+   u32 stream_enc_mask;
+
+   switch (cpu_transcoder) {
+   case TRANSCODER_A:
+   stream_enc_mask = HDCP_STATUS_STREAM_A_ENC;
+   break;
+   case TRANSCODER_B:
+   stream_enc_mask = HDCP_STATUS_STREAM_B_ENC;
+   break;
+   case TRANSCODER_C:
+   stream_enc_mask = HDCP_STATUS_STREAM_C_ENC;
+   break;
+   case TRANSCODER_D:
+   stream_enc_mask = HDCP_STATUS_STREAM_D_ENC;
+  

[Intel-gfx] [PATCH 1/4] drm/i915/hdcp: DP MST transcoder for link and stream

[Anshuman Gupta]

Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.

This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.

This will be used for both HDCP 1.4 and HDCP 2.2 over DP MST
on Gen12.

Cc: Ramalingam C 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  2 +-
 .../gpu/drm/i915/display/intel_display_types.h|  2 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +++
 drivers/gpu/drm/i915/display/intel_hdcp.h |  2 +-
 5 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 6af080542c96..5bf3619c64f6 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3967,7 +3967,7 @@ static void intel_enable_ddi(struct intel_atomic_state 
*state,
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
intel_hdcp_enable(to_intel_connector(conn_state->connector),
- crtc_state->cpu_transcoder,
+ crtc_state,
  (u8)conn_state->hdcp_content_type);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 413b60337a0b..297cfd7ad622 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -410,6 +410,8 @@ struct intel_hdcp {
 * Hence caching the transcoder here.
 */
enum transcoder cpu_transcoder;
+   /* Only used for DP MST stream encryption */
+   enum transcoder stream_transcoder;
 };
 
 struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index b6424bf5d544..c6107182519f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -564,7 +564,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
intel_hdcp_enable(to_intel_connector(conn_state->connector),
- pipe_config->cpu_transcoder,
+ pipe_config,
  (u8)conn_state->hdcp_content_type);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 5492076d1ae0..1d5026bb45a4 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2072,7 +2072,7 @@ int intel_hdcp_init(struct intel_connector *connector,
 }
 
 int intel_hdcp_enable(struct intel_connector *connector,
- enum transcoder cpu_transcoder, u8 content_type)
+ const struct intel_crtc_state *pipe_config, u8 
content_type)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
@@ -2088,10 +2088,17 @@ int intel_hdcp_enable(struct intel_connector *connector,
drm_WARN_ON(&dev_priv->drm,
hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
hdcp->content_type = content_type;
-   hdcp->cpu_transcoder = cpu_transcoder;
+
+   if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
+   hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
+   hdcp->stream_transcoder = pipe_config->cpu_transcoder;
+   } else {
+   hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
+   hdcp->stream_transcoder = INVALID_TRANSCODER;
+   }
 
if (INTEL_GEN(dev_priv) >= 12)
-   hdcp->port_data.fw_tc = intel_get_mei_fw_tc(cpu_transcoder);
+   hdcp->port_data.fw_tc = 
intel_get_mei_fw_tc(hdcp->cpu_transcoder);
 
/*
 * Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
@@ -2202,7 +2209,7 @@ void intel_hdcp_update_pipe(struct intel_atomic_state 
*state,
 
if (desired_and_not_enabled || content_protection_type_changed)
intel_hdcp_enable(connector,
- crtc_state->cpu_transcoder,
+ crtc_state,
  (u8)conn_state->hdcp_content_type);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 1bbf5b67ed0a..bc51c1e9b481 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -25,7 +25,7 @@ void intel_hdcp_atomic_check(struct drm_connector *connector,
 int intel_hdcp

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Gen12 HDCP 1.4 support on DP MST

[Patchwork]

== Series Details ==

Series: Gen12 HDCP 1.4 support on DP MST
URL   : https://patchwork.freedesktop.org/series/81289/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
f00dd9da6f69 drm/i915/hdcp: DP MST transcoder for link and stream
6bfdaa67e988 drm/i915/hdcp: Move HDCP enc status timeout to header
-:13: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 7e90e8d0c0ea ("drm/i915: 
Increase timeout for Encrypt status change")'
#13: 
Related: 7e90e8d0c0ea ("drm/i915: Increase timeout for Encrypt

total: 1 errors, 0 warnings, 0 checks, 47 lines checked
964259d21354 drm/i915/hdcp: HDCP stream encryption support
2f6741ef3a67 drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support


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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Gen12 HDCP 1.4 support on DP MST

[Patchwork]

== Series Details ==

Series: Gen12 HDCP 1.4 support on DP MST
URL   : https://patchwork.freedesktop.org/series/81289/
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/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1440:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1494:15: warning: memset with byte count of 
16777216
+./include/linux/seqlock.h:752:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:778:16: warning: trying to copy expression type 31
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block


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

Re: [Intel-gfx] [PATCH v10 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware state

[Andy Shevchenko]

On Thu, Sep 03, 2020 at 01:23:26PM +0200, Hans de Goede wrote:
> Before this commit pwm_lpss_apply() was assuming 2 pre-conditions
> were met by the existing hardware state:
> 
> 1. That the base-unit and on-time-div read back from the
> control register are those actually in use, so that it
> can skip setting the update bit if the read-back value
> matches the desired values.
> 
> 2. That the controller is enabled when the cached
> pwm_state.enabled says that the controller is enabled.
> 
> As the long history of fixes for subtle (often suspend/resume)
> lpss-pwm issues shows, these assumptions are not necessary
> always true.
> 
> 1. Specifically is not true on some (*) Cherry Trail devices
> with a nasty GFX0._PS3 method which: a. saves the ctrl reg value.
> b. sets the base-unit to 0 and writes the update bit to apply/commit
> c. restores the original ctrl value without setting the update bit,
> so that the 0 base-unit value is still in use.
> 
> 2. Assumption 2. currently is true, but only because of the code which
> saves/restores the state on suspend/resume. By convention restoring the
> PWM state should be done by the PWM consumer and the presence of this
> code in the pmw-lpss driver is a bug. Therefor the save/restore code will
> be dropped in the next patch in this series, after which this assumption
> also is no longer true.
> 
> This commit changes the pwm_lpss_apply() to not make any assumptions about
> the state the hardware is in. Instead it makes pwm_lpss_apply() always
> fully program the PWM controller, making it much less fragile.
> 
> *) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models
> and various Medion models.

Good one!
Reviewed-by: Andy Shevchenko 

> Acked-by: Thierry Reding 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v10:
> - Fixup some wording / mistakes in the commit message
> 
> Changes in v9:
> - This is a new patch in v9 of this series
> ---
>  drivers/pwm/pwm-lpss.c | 21 +
>  1 file changed, 9 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> index 8a136ba2a583..9c5c7217c9b6 100644
> --- a/drivers/pwm/pwm-lpss.c
> +++ b/drivers/pwm/pwm-lpss.c
> @@ -85,7 +85,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
> struct pwm_device *pwm,
>   unsigned long long on_time_div;
>   unsigned long c = lpwm->info->clk_rate, base_unit_range;
>   unsigned long long base_unit, freq = NSEC_PER_SEC;
> - u32 orig_ctrl, ctrl;
> + u32 ctrl;
>  
>   do_div(freq, period_ns);
>  
> @@ -104,16 +104,14 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip 
> *lpwm, struct pwm_device *pwm,
>   do_div(on_time_div, period_ns);
>   on_time_div = 255ULL - on_time_div;
>  
> - orig_ctrl = ctrl = pwm_lpss_read(pwm);
> + ctrl = pwm_lpss_read(pwm);
>   ctrl &= ~PWM_ON_TIME_DIV_MASK;
>   ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
>   ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
>   ctrl |= on_time_div;
>  
> - if (orig_ctrl != ctrl) {
> - pwm_lpss_write(pwm, ctrl);
> - pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
> - }
> + pwm_lpss_write(pwm, ctrl);
> + pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
>  }
>  
>  static inline void pwm_lpss_cond_enable(struct pwm_device *pwm, bool cond)
> @@ -124,8 +122,7 @@ static inline void pwm_lpss_cond_enable(struct pwm_device 
> *pwm, bool cond)
>  
>  static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm,
>  struct pwm_device *pwm,
> -const struct pwm_state *state,
> -bool enable)
> +const struct pwm_state *state)
>  {
>   int ret;
>  
> @@ -134,12 +131,12 @@ static int pwm_lpss_prepare_enable(struct pwm_lpss_chip 
> *lpwm,
>   return ret;
>  
>   pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, state->period);
> - pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);
> + pwm_lpss_cond_enable(pwm, 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);
> + pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
>   return 0;
>  }
>  
> @@ -152,11 +149,11 @@ static int pwm_lpss_apply(struct pwm_chip *chip, struct 
> pwm_device *pwm,
>   if (state->enabled) {
>   if (!pwm_is_enabled(pwm)) {
>   pm_runtime_get_sync(chip->dev);
> - ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
> + ret = pwm_lpss_prepare_enable(lpwm, pwm, state);
>   if (ret)
>   pm_runtime_put(chip->dev);
>   } else {
> - ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
> + ret = pwm_lpss_p

Re: [Intel-gfx] [PATCH v10 07/17] pwm: lpss: Remove suspend/resume handlers

[Andy Shevchenko]

On Thu, Sep 03, 2020 at 01:23:27PM +0200, Hans de Goede wrote:
> PWM controller drivers should not restore the PWM state on resume. The
> convention is that PWM consumers do this by calling pwm_apply_state(),
> so that it can be done at the exact moment when the consumer needs
> the state to be stored, avoiding e.g. backlight flickering.
> 
> The only in kernel consumers of the pwm-lpss code, the i915 driver
> and the pwm-class sysfs interface code both correctly restore the
> state on resume, so there is no need to do this in the pwm-lpss code.
> 
> More-over the removed resume handler is buggy, since it blindly
> restores the ctrl-register contents without setting the update
> bit, which is necessary to get the controller to actually use/apply
> the restored base-unit and on-time-div values.

While this is okay

Reviewed-by: Andy Shevchenko 

the question is do we need to have similar in acpi_lpss.c?
For example,
static const struct lpss_device_desc byt_pwm_dev_desc = {
.flags = LPSS_SAVE_CTX,
^^
.prv_offset = 0x800,
.setup = byt_pwm_setup,
};

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,
};


> Acked-by: Thierry Reding 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v9:
> - This is a new patch in v9 of this series
> ---
>  drivers/pwm/pwm-lpss-platform.c |  1 -
>  drivers/pwm/pwm-lpss.c  | 24 
>  drivers/pwm/pwm-lpss.h  |  3 ---
>  3 files changed, 28 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-lpss-platform.c b/drivers/pwm/pwm-lpss-platform.c
> index 48f34d20aecd..c6502cf7a7af 100644
> --- a/drivers/pwm/pwm-lpss-platform.c
> +++ b/drivers/pwm/pwm-lpss-platform.c
> @@ -89,7 +89,6 @@ static int pwm_lpss_prepare(struct device *dev)
>  
>  static const struct dev_pm_ops pwm_lpss_platform_pm_ops = {
>   .prepare = pwm_lpss_prepare,
> - SET_SYSTEM_SLEEP_PM_OPS(pwm_lpss_suspend, pwm_lpss_resume)
>  };
>  
>  static const struct acpi_device_id pwm_lpss_acpi_match[] = {
> diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> index 9c5c7217c9b6..3444c56b4bed 100644
> --- a/drivers/pwm/pwm-lpss.c
> +++ b/drivers/pwm/pwm-lpss.c
> @@ -260,30 +260,6 @@ int pwm_lpss_remove(struct pwm_lpss_chip *lpwm)
>  }
>  EXPORT_SYMBOL_GPL(pwm_lpss_remove);
>  
> -int pwm_lpss_suspend(struct device *dev)
> -{
> - struct pwm_lpss_chip *lpwm = dev_get_drvdata(dev);
> - int i;
> -
> - for (i = 0; i < lpwm->info->npwm; i++)
> - lpwm->saved_ctrl[i] = readl(lpwm->regs + i * PWM_SIZE + PWM);
> -
> - return 0;
> -}
> -EXPORT_SYMBOL_GPL(pwm_lpss_suspend);
> -
> -int pwm_lpss_resume(struct device *dev)
> -{
> - struct pwm_lpss_chip *lpwm = dev_get_drvdata(dev);
> - int i;
> -
> - for (i = 0; i < lpwm->info->npwm; i++)
> - writel(lpwm->saved_ctrl[i], lpwm->regs + i * PWM_SIZE + PWM);
> -
> - return 0;
> -}
> -EXPORT_SYMBOL_GPL(pwm_lpss_resume);
> -
>  MODULE_DESCRIPTION("PWM driver for Intel LPSS");
>  MODULE_AUTHOR("Mika Westerberg ");
>  MODULE_LICENSE("GPL v2");
> diff --git a/drivers/pwm/pwm-lpss.h b/drivers/pwm/pwm-lpss.h
> index 7909fa12fca2..70db7e389d66 100644
> --- a/drivers/pwm/pwm-lpss.h
> +++ b/drivers/pwm/pwm-lpss.h
> @@ -19,7 +19,6 @@ struct pwm_lpss_chip {
>   struct pwm_chip chip;
>   void __iomem *regs;
>   const struct pwm_lpss_boardinfo *info;
> - u32 saved_ctrl[MAX_PWMS];
>  };
>  
>  struct pwm_lpss_boardinfo {
> @@ -37,7 +36,5 @@ struct pwm_lpss_boardinfo {
>  struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev, struct resource *r,
>const struct pwm_lpss_boardinfo *info);
>  int pwm_lpss_remove(struct pwm_lpss_chip *lpwm);
> -int pwm_lpss_suspend(struct device *dev);
> -int pwm_lpss_resume(struct device *dev);
>  
>  #endif   /* __PWM_LPSS_H */
> -- 
> 2.28.0
> 

-- 
With Best Regards,
Andy Shevchenko


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

Re: [Intel-gfx] [PATCH v10 07/17] pwm: lpss: Remove suspend/resume handlers

[Andy Shevchenko]

On Thu, Sep 03, 2020 at 03:48:16PM +0300, Andy Shevchenko wrote:
> On Thu, Sep 03, 2020 at 01:23:27PM +0200, Hans de Goede wrote:

> the question is do we need to have similar in acpi_lpss.c?
> For example,
>   static const struct lpss_device_desc byt_pwm_dev_desc = {
>   .flags = LPSS_SAVE_CTX,
>   ^^
>   .prv_offset = 0x800,
>   .setup = byt_pwm_setup,
>   };
> 
>   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,
>   };

Okay, it's a private space which has clock and reset gating, so means we still
need to handle it.

-- 
With Best Regards,
Andy Shevchenko


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

Re: [Intel-gfx] [PATCH v10 07/17] pwm: lpss: Remove suspend/resume handlers

[Hans de Goede]

Hi,

On 9/3/20 2:56 PM, Andy Shevchenko wrote:

On Thu, Sep 03, 2020 at 03:48:16PM +0300, Andy Shevchenko wrote:

On Thu, Sep 03, 2020 at 01:23:27PM +0200, Hans de Goede wrote:



the question is do we need to have similar in acpi_lpss.c?
For example,
static const struct lpss_device_desc byt_pwm_dev_desc = {
.flags = LPSS_SAVE_CTX,
^^
.prv_offset = 0x800,
.setup = byt_pwm_setup,
};

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,
};


Okay, it's a private space which has clock and reset gating, so means we still
need to handle it.


Right I was about to say the same.

As always, thank you for your reviews.

Regards,

Hans

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Gen12 HDCP 1.4 support on DP MST

[Patchwork]

== Series Details ==

Series: Gen12 HDCP 1.4 support on DP MST
URL   : https://patchwork.freedesktop.org/series/81289/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8958 -> Patchwork_18438


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  
 Possible fixes 

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

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

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

  
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2276]: https://gitlab.freedesktop.org/drm/intel/issues/2276


Participating hosts (39 -> 32)
--

  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-kbl-guc fi-ctg-p8600 fi-byt-clapper 


Build changes
-

  * Linux: CI_DRM_8958 -> Patchwork_18438

  CI-20190529: 20190529
  CI_DRM_8958: c45d2896ceff5e085d0590e265e4ad02c600d1fa @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5777: c240b5c00d58860e376b012cc3c883c17ae63f37 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18438: 2f6741ef3a67382a48cb26d480393b5ddbedddb7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2f6741ef3a67 drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support
964259d21354 drm/i915/hdcp: HDCP stream encryption support
6bfdaa67e988 drm/i915/hdcp: Move HDCP enc status timeout to header
f00dd9da6f69 drm/i915/hdcp: DP MST transcoder for link and stream

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Unlock the shared hwsp_gtt object after pinning

[Mika Kuoppala]

From: Thomas Hellström 

The hwsp_gtt object is used for sub-allocation and could therefore
be shared by many contexts causing unnecessary contention during
concurrent context pinning.
However since we're currently locking it only for pinning, it remains
resident until we unpin it, and therefore it's safe to drop the
lock early, allowing for concurrent thread access.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gt/intel_context.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 61b05cd4c47a..65e956ba19e1 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -271,6 +271,13 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
i915_active_release(&ce->active);
 err_ctx_unpin:
intel_context_post_unpin(ce);
+
+   /*
+* Unlock the hwsp_ggtt object since it's shared. This is fine for now
+* since the lock has been used for pinning only, not fencing.
+*/
+   i915_gem_ww_unlock_single(ce->timeline->hwsp_ggtt->obj);
+
return err;
 }
 
-- 
2.17.1

___
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/managed: Cleanup of unused functions and polishing docs

[Patchwork]

== Series Details ==

Series: drm/managed: Cleanup of unused functions and polishing docs
URL   : https://patchwork.freedesktop.org/series/81253/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8953_full -> Patchwork_18431_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18431_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18431_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_18431_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_render_copy@y-tiled-ccs-to-y-tiled:
- shard-glk:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8953/shard-glk1/igt@gem_render_c...@y-tiled-ccs-to-y-tiled.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18431/shard-glk7/igt@gem_render_c...@y-tiled-ccs-to-y-tiled.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox:
- shard-skl:  [PASS][3] -> [FAIL][4] ([i915#2374])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8953/shard-skl3/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18431/shard-skl5/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html

  * igt@gem_eio@kms:
- shard-snb:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8953/shard-snb5/igt@gem_...@kms.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18431/shard-snb4/igt@gem_...@kms.html

  * igt@gem_exec_reloc@basic-concurrent0:
- shard-apl:  [PASS][7] -> [TIMEOUT][8] ([i915#1635] / [i915#1958]) 
+2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8953/shard-apl2/igt@gem_exec_re...@basic-concurrent0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18431/shard-apl6/igt@gem_exec_re...@basic-concurrent0.html

  * igt@gem_exec_whisper@basic-contexts-forked:
- shard-glk:  [PASS][9] -> [TIMEOUT][10] ([i915#1958]) +1 similar 
issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8953/shard-glk2/igt@gem_exec_whis...@basic-contexts-forked.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18431/shard-glk7/igt@gem_exec_whis...@basic-contexts-forked.html

  * igt@gem_exec_whisper@basic-fds-priority:
- shard-kbl:  [PASS][11] -> [TIMEOUT][12] ([i915#1958])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8953/shard-kbl1/igt@gem_exec_whis...@basic-fds-priority.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18431/shard-kbl4/igt@gem_exec_whis...@basic-fds-priority.html

  * igt@gem_partial_pwrite_pread@reads-display:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#2261])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8953/shard-glk5/igt@gem_partial_pwrite_pr...@reads-display.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18431/shard-glk2/igt@gem_partial_pwrite_pr...@reads-display.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#644])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8953/shard-glk9/igt@gem_pp...@flink-and-close-vma-leak.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18431/shard-glk5/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gem_userptr_blits@unsync-unmap-cycles:
- shard-skl:  [PASS][17] -> [TIMEOUT][18] ([i915#1958])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8953/shard-skl10/igt@gem_userptr_bl...@unsync-unmap-cycles.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18431/shard-skl3/igt@gem_userptr_bl...@unsync-unmap-cycles.html

  * igt@gen9_exec_parse@allowed-all:
- shard-skl:  [PASS][19] -> [DMESG-WARN][20] ([i915#1436] / 
[i915#716]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8953/shard-skl4/igt@gen9_exec_pa...@allowed-all.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18431/shard-skl2/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_selftest@mock@contexts:
- shard-skl:  [PASS][21] -> [INCOMPLETE][22] ([i915#198] / 
[i915#2278])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8953/shard-skl7/igt@i915_selftest@m...@contexts.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18431/shard-skl2/igt@i915_selftest@m...@contexts.html

  * igt@i915_suspend@debugfs-reader:
- shard

Re: [Intel-gfx] [PATCH] drm/i915: fix regression leading to display audio probe failure on GLK

[Ville Syrjälä]

On Tue, Sep 01, 2020 at 06:10:36PM +0300, Kai Vehmanen wrote:
> In commit 4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking
> to separate function") the order of force_min_cdclk_changed check and
> intel_modeset_checks(), was reversed. This broke the mechanism to
> immediately force a new CDCLK minimum, and lead to driver probe
> errors for display audio on GLK platform with 5.9-rc1 kernel. Fix
> the issue by moving intel_modeset_checks() call later.
> 
> Fixes: 4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking to 
> separate function)"
> BugLink: https://github.com/thesofproject/linux/issues/2410
> Signed-off-by: Kai Vehmanen 

Amended the commit msg with a bit more details:
"[vsyrjala: It also broke the ability of planes to bump up the cdclk
and thus could lead to underruns when eg. flipping from 32bpp to
64bpp framebuffer. To be clear, we still compute the new cdclk
correctly but fail to actually program it to the hardware due to 
intel_set_cdclk_{pre,post}_plane_update() not getting called on 
account of state->modeset==false.]"

The "Fixes" line was also a bit wrong: )" vs ") at the end. Took
me a while to figure out what dim was complaining about :)

Pushed to dinq. Thanks!

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 7d50b7177d40..8caeed23037c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15009,12 +15009,6 @@ static int intel_atomic_check(struct drm_device *dev,
>   if (dev_priv->wm.distrust_bios_wm)
>   any_ms = true;
>  
> - if (any_ms) {
> - ret = intel_modeset_checks(state);
> - if (ret)
> - goto fail;
> - }
> -
>   intel_fbc_choose_crtc(dev_priv, state);
>   ret = calc_watermark_data(state);
>   if (ret)
> @@ -15029,6 +15023,10 @@ static int intel_atomic_check(struct drm_device *dev,
>   goto fail;
>  
>   if (any_ms) {
> + ret = intel_modeset_checks(state);
> + if (ret)
> + goto fail;
> +
>   ret = intel_modeset_calc_cdclk(state);
>   if (ret)
>   return ret;
> -- 
> 2.27.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Unlock the shared hwsp_gtt object after pinning

[Chris Wilson]

Quoting Mika Kuoppala (2020-09-03 14:31:44)
> From: Thomas Hellström 
> 
> The hwsp_gtt object is used for sub-allocation and could therefore
> be shared by many contexts causing unnecessary contention during
> concurrent context pinning.
> However since we're currently locking it only for pinning, it remains
> resident until we unpin it, and therefore it's safe to drop the
> lock early, allowing for concurrent thread access.
> 
> Signed-off-by: Thomas Hellström 
> ---
>  drivers/gpu/drm/i915/gt/intel_context.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
> b/drivers/gpu/drm/i915/gt/intel_context.c
> index 61b05cd4c47a..65e956ba19e1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -271,6 +271,13 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
> i915_active_release(&ce->active);
>  err_ctx_unpin:
> intel_context_post_unpin(ce);
> +
> +   /*
> +* Unlock the hwsp_ggtt object since it's shared. This is fine for now
> +* since the lock has been used for pinning only, not fencing.
> +*/
> +   i915_gem_ww_unlock_single(ce->timeline->hwsp_ggtt->obj);

The timeline is not special here, the same rules for locking/unlock can
equally be applied to all the global state. You may even go as far as
putting a local acquire context here, which would then have avoided the
cross driver pollution.

Anyway, if it works for the timeline, there is no reason to keep the
other globals locked. They are pinned and on completely different usage
cycles to the user objects. [They can't be evicted without interacting
with the HW to ensure the context has been flushed, so far there has
been no way to do so without stalling for a freshly submitted request,
hence we let them retire gracefully and kick the kernel timelines to
flush completed contexts.]
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Unlock the shared hwsp_gtt object after pinning

[Intel]

On 9/3/20 4:01 PM, Chris Wilson wrote:

Quoting Mika Kuoppala (2020-09-03 14:31:44)

From: Thomas Hellström 

The hwsp_gtt object is used for sub-allocation and could therefore
be shared by many contexts causing unnecessary contention during
concurrent context pinning.
However since we're currently locking it only for pinning, it remains
resident until we unpin it, and therefore it's safe to drop the
lock early, allowing for concurrent thread access.

Signed-off-by: Thomas Hellström 
---
  drivers/gpu/drm/i915/gt/intel_context.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 61b05cd4c47a..65e956ba19e1 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -271,6 +271,13 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
 i915_active_release(&ce->active);
  err_ctx_unpin:
 intel_context_post_unpin(ce);
+
+   /*
+* Unlock the hwsp_ggtt object since it's shared. This is fine for now
+* since the lock has been used for pinning only, not fencing.
+*/
+   i915_gem_ww_unlock_single(ce->timeline->hwsp_ggtt->obj);

The timeline is not special here, the same rules for locking/unlock can
equally be applied to all the global state. You may even go as far as
putting a local acquire context here, which would then have avoided the
cross driver pollution.

Anyway, if it works for the timeline, there is no reason to keep the
other globals locked. They are pinned and on completely different usage
cycles to the user objects.


Agreed.  In principle everything we want to perma-pin we can unlock 
early, Keeping it under the same acquire context makes it possible to do 
this as part of a bigger ww transaction. Although initially this 
solution was discarded in favour of removing the suballocation to be 
able to ditch the perma-pinning in the future.


But is this acceptable to address the pi-isolated issue until we have 
something more thought-through in place? Or is there somethin specific 
you want me to change for a R-B?


Thanks,

Thomas


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

Re: [Intel-gfx] Various problems for the Xen for XenGT code and guide.

[Roman Shaposhnik]

On Wed, Sep 2, 2020 at 5:48 AM Lv, Zhiyuan  wrote:
>
> Hi,
>
> It is mainly due to the business priority change. XenGT project was 
> originally created for data center usages with XEON E3 servers which have 
> integrated processor graphics. After SkyLake E3, there are no new servers 
> capable of running GVT-g, and Intel future graphics for data center will have 
> different approaches for GPU sharing. Another reason is the XenGT upstream 
> difficulty. Different from KVMGT which has been fully merged to upstream, Xen 
> part of GVT-g still has technical opens that are hard to close quickly.

This is extremely useful -- thanks for sharing. Any chance you can
elaborate on the later part "and Intel future graphics for data center
will have different approaches for GPU sharing"?

IOW, is there anything that Intel is cooking up that may help Xen in
that department?

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

[Intel-gfx] i915: boot/load regression since Linux v5.7-rc1 on Iris Pro (Crystal Well)

[Peter Vollmer]

Hi,

since kernel v5.7-rc1 my graphical output hangs on boot or if the i915
module is blacklisted on modprobe.
I've already found and extended a bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=208737

But sadly there has been little reaction so I would appreciate any
help in further debugging or better yet resolving this issue.

Thanks in advance

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

Re: [Intel-gfx] [PATCH 00/37] Replace obj->mm.lock with reservation_ww_class

[Tvrtko Ursulin]

On 10/08/2020 10:51, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2020-08-06 10:21:38)


On 05/08/2020 17:22, Thomas Hellström (Intel) wrote:

Hi, Chris,


On 8/5/20 2:21 PM, Chris Wilson wrote:

Long story short, we need to manage evictions using dma_resv & dma_fence
tracking. The backing storage will then be managed using the ww_mutex
borrowed from (and shared via) obj->base.resv, rather than the current
obj->mm.lock.

Skipping over the breadcrumbs,


While perhaps needed fixes, could we submit them as a separate series,
since they, from what I can tell, are not a direct part of the locking
rework, and some of them were actually part of a series that Dave NaK'ed
and may require additional justification?



   the first step is to remove the final
crutches of struct_mutex from execbuf and to broaden the hold for the
dma-resv to guard not just publishing the dma-fences, but for the
duration of the execbuf submission (holding all objects and their
backing store from the point of acquisition to publishing of the final
GPU work, after which the guard is delegated to the dma-fences).

This is of course made complicated by our history. On top of the user's
objects, we also have the HW/kernel objects with their own lifetimes,
and a bunch of auxiliary objects used for working around unhappy HW and
for providing the legacy relocation mechanism. We add every auxiliary
object to the list of user objects required, and attempt to acquire them
en masse. Since all the objects can be known a priori, we can build a
list of those objects and pass that to a routine that can resolve the
-EDEADLK (and evictions). [To avoid relocations imposing a penalty on
sane userspace that avoids them, we do not touch any relocations until
necessary, at will point we have to unroll the state, and rebuild a new
list with more auxiliary buffers to accommodate the extra
copy_from_user].
More examples are included as to how we can break down operations
involving multiple objects into an acquire phase prior to those
operations, keeping the -EDEADLK handling under control.

execbuf is the unique interface in that it deals with multiple user
and kernel buffers. After that, we have callers that in principle care
about accessing a single buffer, and so can be migrated over to a helper
that permits only holding one such buffer at a time. That enables us to
swap out obj->mm.lock for obj->base.resv->lock, and use lockdep to spot
illegal nesting, and to throw away the temporary pins by replacing them
with holding the ww_mutex for the duration instead.

What's changed? Some patch splitting and we need to pull in Matthew's
patch to map the page directories under the ww_mutex.


I would still like to see a justification for the newly introduced async
work, as opposed to add it as an optimizing / regression fixing series
follow the locking rework. That async work introduces a bunch of code
complexity and it would be beneficial to see a discussion of the
tradeoffs and how it alignes with the upstream proposed dma-fence
annotations


On the topic of annotations, maybe do a trybot run with them enabled
with the latest series and then see what pops up.


It didn't change since the run Daniel did. In that run there were two
splats I found,

vm->mutex -> dma_fence_is_signaled/dma_fence_signal -> async work + vm->mutex


Coming back to this after a few weeks - was there any further discussion 
on the dma_fence_is_signaled problem? I don't think Daniel you ever 
replied, or at least I did not see it. Can the signaling section in 
there possibly remain and not be obviously incorrect?


Regards,

Tvrtko



This is the overconstraint Daniel mentioned, it's an entirely false
coupling from the assumption that the async work runs inside the
parent's signaling context. Gut feeling says that should be resolvable
by using lockdep's dependency analysis between local execution/signal
contexts.

The other was

userptr mmu_notifier -> i915_vma_unbind + i915_vma_revoke -> mmu_notifier
[with the interplay between the two global lockmap's, two strikes?]

And that is the well known false positive for userptr that we break by
never allowing the userptr to in be the dev->mapping.

A path not exercised but it should find is synchronous fence eviction.
While binding a fresh fence ensures the vma is idle before starting, we
do not do the same for the fence we steal. That's why care was taken for
execbuf, and it just means teaching the synchronous path to similarly
move the wait outside of the mutex (the simplest will be to wrap the
async handling).
-Chris


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

Re: [Intel-gfx] [PATCH] drm/managed: Cleanup of unused functions and polishing docs

[Daniel Vetter]

On Wed, Sep 02, 2020 at 09:26:27AM +0200, Daniel Vetter wrote:
> Following functions are only used internally, not by drivers:
> - devm_drm_dev_init
> 
> Also, now that we have a very slick and polished way to allocate a
> drm_device with devm_drm_dev_alloc, update all the docs to reflect the
> new reality. Mostly this consists of deleting old and misleading
> hints. Two main ones:
> 
> - it is no longer required that the drm_device base class is first in
>   the structure. devm_drm_dev_alloc can cope with it being anywhere
> 
> - obviously embedded now strongly recommends using devm_drm_dev_alloc
> 
> v2: Fix typos (Noralf)
> 
> v3: Split out the removal of drm_dev_init, that's blocked on some
> discussions on how to convert vgem/vkms/i915-selftests. Adjust commit
> message to reflect that.
> 
> Cc: Noralf Trønnes 
> Acked-by: Noralf Trønnes  (v2)
> Acked-by: Sam Ravnborg 
> Cc: Luben Tuikov 
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 

Ok pushed that now to drm-misc-next. I'm also working on getting the
remaining bits of the basic drm managed conversion resubmitted. That was
unfortunately massively sidelined for the dma-fence discussions.

Quick heads-up:
drmm_add_final_kfree and drm_dev_init will both disappear, please use
devm_drm_dev_alloc.

Cheers, Daniel

> ---
>  .../driver-api/driver-model/devres.rst|  2 +-
>  drivers/gpu/drm/drm_drv.c | 78 +--
>  drivers/gpu/drm/drm_managed.c |  2 +-
>  include/drm/drm_device.h  |  2 +-
>  include/drm/drm_drv.h | 16 ++--
>  5 files changed, 30 insertions(+), 70 deletions(-)
> 
> diff --git a/Documentation/driver-api/driver-model/devres.rst 
> b/Documentation/driver-api/driver-model/devres.rst
> index efc21134..aa4d2420f79e 100644
> --- a/Documentation/driver-api/driver-model/devres.rst
> +++ b/Documentation/driver-api/driver-model/devres.rst
> @@ -263,7 +263,7 @@ DMA
>dmam_pool_destroy()
>  
>  DRM
> -  devm_drm_dev_init()
> +  devm_drm_dev_alloc()
>  
>  GPIO
>devm_gpiod_get()
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index d4506f7a234e..7c1689842ec0 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -240,13 +240,13 @@ void drm_minor_release(struct drm_minor *minor)
>   * DOC: driver instance overview
>   *
>   * A device instance for a drm driver is represented by &struct drm_device. 
> This
> - * is initialized with drm_dev_init(), usually from bus-specific ->probe()
> - * callbacks implemented by the driver. The driver then needs to initialize 
> all
> - * the various subsystems for the drm device like memory management, vblank
> - * handling, modesetting support and intial output configuration plus 
> obviously
> - * initialize all the corresponding hardware bits. Finally when everything 
> is up
> - * and running and ready for userspace the device instance can be published
> - * using drm_dev_register().
> + * is allocated and initialized with devm_drm_dev_alloc(), usually from
> + * bus-specific ->probe() callbacks implemented by the driver. The driver 
> then
> + * needs to initialize all the various subsystems for the drm device like 
> memory
> + * management, vblank handling, modesetting support and initial output
> + * configuration plus obviously initialize all the corresponding hardware 
> bits.
> + * Finally when everything is up and running and ready for userspace the 
> device
> + * instance can be published using drm_dev_register().
>   *
>   * There is also deprecated support for initalizing device instances using
>   * bus-specific helpers and the &drm_driver.load callback. But due to
> @@ -274,7 +274,7 @@ void drm_minor_release(struct drm_minor *minor)
>   *
>   * The following example shows a typical structure of a DRM display driver.
>   * The example focus on the probe() function and the other functions that is
> - * almost always present and serves as a demonstration of 
> devm_drm_dev_init().
> + * almost always present and serves as a demonstration of 
> devm_drm_dev_alloc().
>   *
>   * .. code-block:: c
>   *
> @@ -294,22 +294,12 @@ void drm_minor_release(struct drm_minor *minor)
>   *   struct drm_device *drm;
>   *   int ret;
>   *
> - *   // devm_kzalloc() can't be used here because the drm_device '
> - *   // lifetime can exceed the device lifetime if driver unbind
> - *   // happens when userspace still has open file descriptors.
> - *   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> - *   if (!priv)
> - *   return -ENOMEM;
> - *
> + *   priv = devm_drm_dev_alloc(&pdev->dev, &driver_drm_driver,
> + * struct driver_device, drm);
> + *   if (IS_ERR(priv))
> + *   return PTR_ERR(priv);
>   *   drm = &priv->drm;
>   *
> - *   ret = devm_drm_dev_init(&pdev->dev, drm, &driver_drm_driver);
>

Re: [Intel-gfx] [PATCH] drm/i915: fix regression leading to display audio probe failure on GLK

[Kai Vehmanen]

Hey,

On Thu, 3 Sep 2020, Ville Syrjälä wrote:

> On Tue, Sep 01, 2020 at 06:10:36PM +0300, Kai Vehmanen wrote:
>> In commit 4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking
>> to separate function") the order of force_min_cdclk_changed check and
>> intel_modeset_checks(), was reversed. This broke the mechanism to
> 
> Amended the commit msg with a bit more details:
> "[vsyrjala: It also broke the ability of planes to bump up the cdclk
> and thus could lead to underruns when eg. flipping from 32bpp to
> 64bpp framebuffer. To be clear, we still compute the new cdclk

ack on that, thanks!

> The "Fixes" line was also a bit wrong: )" vs ") at the end. Took
> me a while to figure out what dim was complaining about :)
> 
> Pushed to dinq. Thanks!

Uh, sorry about that. I actually fixed that in some (?) version due to 
checkpatch warnings, but apparently it slipped though. Sorry about that, 
took me a while to figure it out, as well :)

Br, Kai___
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: Unlock the shared hwsp_gtt object after pinning

[Patchwork]

== Series Details ==

Series: drm/i915: Unlock the shared hwsp_gtt object after pinning
URL   : https://patchwork.freedesktop.org/series/81290/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8959 -> Patchwork_18439


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2:  [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8959/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18439/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2:  [INCOMPLETE][3] ([i915#2045]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8959/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18439/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html

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

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-7500u:   [DMESG-FAIL][7] ([i915#165]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8959/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18439/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html

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

  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
  [i915#1958]: https://gitlab.freedesktop.org/drm/intel/issues/1958
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2045]: https://gitlab.freedesktop.org/drm/intel/issues/2045
  [i915#2417]: https://gitlab.freedesktop.org/drm/intel/issues/2417


Participating hosts (39 -> 33)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-byt-clapper 


Build changes
-

  * Linux: CI_DRM_8959 -> Patchwork_18439

  CI-20190529: 20190529
  CI_DRM_8959: b570f98019dd32803271895707fb3ec98eb9636a @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5777: c240b5c00d58860e376b012cc3c883c17ae63f37 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18439: d8b76f0b3574014ed467342e9b5aa029e449235e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d8b76f0b3574 drm/i915: Unlock the shared hwsp_gtt object after pinning

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/kms: Add separate hotplug event call for drm connector (rev2)

[Patchwork]

== Series Details ==

Series: drm/kms: Add separate hotplug event call for drm connector (rev2)
URL   : https://patchwork.freedesktop.org/series/81257/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8954_full -> Patchwork_18433_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2] ([i915#198]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8954/shard-skl7/igt@gem_ctx_isolation@preservation...@vcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18433/shard-skl1/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_exec_reloc@basic-active@all:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4] ([i915#2395])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8954/shard-tglb5/igt@gem_exec_reloc@basic-act...@all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18433/shard-tglb5/igt@gem_exec_reloc@basic-act...@all.html

  * igt@gem_exec_reloc@basic-concurrent0:
- shard-kbl:  [PASS][5] -> [TIMEOUT][6] ([i915#1958]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8954/shard-kbl7/igt@gem_exec_re...@basic-concurrent0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18433/shard-kbl1/igt@gem_exec_re...@basic-concurrent0.html

  * igt@gem_exec_schedule@preemptive-hang@vecs0:
- shard-skl:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +8 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8954/shard-skl7/igt@gem_exec_schedule@preemptive-h...@vecs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18433/shard-skl1/igt@gem_exec_schedule@preemptive-h...@vecs0.html

  * igt@gem_exec_whisper@basic-contexts-all:
- shard-apl:  [PASS][9] -> [TIMEOUT][10] ([i915#1635] / 
[i915#1958]) +2 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8954/shard-apl1/igt@gem_exec_whis...@basic-contexts-all.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18433/shard-apl4/igt@gem_exec_whis...@basic-contexts-all.html

  * igt@gem_exec_whisper@basic-contexts-forked:
- shard-glk:  [PASS][11] -> [TIMEOUT][12] ([i915#1958]) +2 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8954/shard-glk8/igt@gem_exec_whis...@basic-contexts-forked.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18433/shard-glk7/igt@gem_exec_whis...@basic-contexts-forked.html

  * igt@gem_exec_whisper@basic-forked:
- shard-iclb: [PASS][13] -> [TIMEOUT][14] ([i915#1958]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8954/shard-iclb7/igt@gem_exec_whis...@basic-forked.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18433/shard-iclb5/igt@gem_exec_whis...@basic-forked.html

  * igt@gem_exec_whisper@basic-forked-all:
- shard-glk:  [PASS][15] -> [DMESG-WARN][16] ([i915#118] / 
[i915#95])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8954/shard-glk1/igt@gem_exec_whis...@basic-forked-all.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18433/shard-glk4/igt@gem_exec_whis...@basic-forked-all.html

  * igt@gem_sync@basic-store-all:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#2356])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8954/shard-glk6/igt@gem_s...@basic-store-all.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18433/shard-glk5/igt@gem_s...@basic-store-all.html

  * igt@i915_module_load@reload:
- shard-iclb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8954/shard-iclb3/igt@i915_module_l...@reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18433/shard-iclb3/igt@i915_module_l...@reload.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][21] -> [FAIL][22] ([i915#454])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8954/shard-iclb5/igt@i915_pm...@dc6-psr.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18433/shard-iclb6/igt@i915_pm...@dc6-psr.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-hdmi-a1:
- shard-glk:  [PASS][23] -> [FAIL][24] ([i915#2122])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8954/shard-glk3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a1.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18433/shard-glk1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a1.html

  * igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-glk:  [PASS][25] -> [DMESG-WARN][26] ([i915#1982])
   [25]: 
https://intel-gfx-c

[Intel-gfx] [PATCH v2] drm/i915: Unlock the shared hwsp_gtt object after pinning

[Thomas Hellström]

From: Thomas Hellström 

The hwsp_gtt object is used for sub-allocation and could therefore
be shared by many contexts causing unnecessary contention during
concurrent context pinning.
However since we're currently locking it only for pinning, it remains
resident until we unpin it, and therefore it's safe to drop the
lock early, allowing for concurrent thread access.

Signed-off-by: Thomas Hellström 
Reviewed-by: Chris Wilson 
---
v2: Added additional clarifying code comments (Chris Wilson)
---
 drivers/gpu/drm/i915/gt/intel_context.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 61b05cd4c47a..d301dda1b261 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -271,6 +271,15 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
i915_active_release(&ce->active);
 err_ctx_unpin:
intel_context_post_unpin(ce);
+
+   /*
+* Unlock the hwsp_ggtt object since it's shared.
+* In principle we can unlock all the global state locked above
+* since it's pinned and doesn't need fencing, and will
+* thus remain resident until it is explicitly unpinned.
+*/
+   i915_gem_ww_unlock_single(ce->timeline->hwsp_ggtt->obj);
+
return err;
 }
 
-- 
2.25.1

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

[Intel-gfx] [PULL] drm-misc-next

[Maxime Ripard]

Hi Dave, Daniel,

Here's this week PR for drm-misc-next

Thanks!
Maxime

drm-misc-next-2020-09-03:
drm-misc-next for 5.10:

UAPI Changes:

Cross-subsystem Changes:

Core Changes:
  - doc: update the doc to encourage drivers to use devm_drm_dev_alloc
  - ttm: More reworks / cleanups

Driver Changes:
  - sun4i: Minor fix in the LVDS encoder
  - panels: New panel: AM-1280800N3TZQW-T00H
The following changes since commit cd6da0b113512b15a4d35f355f9ecd8858297369:

  drm/mgag200: fix spelling mistake "expeced" -> "expected" (2020-08-27 
11:17:52 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-09-03

for you to fetch changes up to 4c8e84b8876dc726a7e5327b3113d75423c46728:

  drm/managed: Cleanup of unused functions and polishing docs (2020-09-03 
16:25:06 +0200)


drm-misc-next for 5.10:

UAPI Changes:

Cross-subsystem Changes:

Core Changes:
  - doc: update the doc to encourage drivers to use devm_drm_dev_alloc
  - ttm: More reworks / cleanups

Driver Changes:
  - sun4i: Minor fix in the LVDS encoder
  - panels: New panel: AM-1280800N3TZQW-T00H


Christian König (3):
  drm/ttm: make sure that we always zero init mem.bus v2
  drm/nouveau: move io_reserve_lru handling into the driver v5
  drm/ttm: remove io_reserve_lru handling v3

Daniel Vetter (1):
  drm/managed: Cleanup of unused functions and polishing docs

Dave Airlie (2):
  drm/amdgpu/ttm: remove unused parameter to move blit
  drm/radeon/ttm: don't store driver copy of device pointer.

Dinghao Liu (1):
  drm/crc-debugfs: Fix memleak in crc_control_write

Gerd Hoffmann (2):
  drm/virtio: fix unblank
  drm/virtio: drop virtio_gpu_output->enabled

Jagan Teki (2):
  dt-bindings: display: simple: Add AM-1280800N3TZQW-T00H
  drm/panel: simple: Add AM-1280800N3TZQW-T00H

Laurent Pinchart (1):
  drm: panel: Fix bpc for OrtusTech COM43H4M85ULC panel

Maxime Ripard (1):
  drm/sun4i: lvds: Invert the LVDS polarity

Melissa Wen (1):
  drm/vkms: add alpha-premultiplied color blending

Randy Dunlap (3):
  drm: virtio: fix kconfig dependency warning
  dma-buf: fix kernel-doc warning in dma-fence.c
  dma-buf: fix kernel-doc warning in 

Rikard Falkeborn (1):
  drm/gma500: Constify static structs

Robert Chiras (1):
  drm/panel: rm67191: Remove CLOCK_NON_CONTINUOUS flag

Sam McNally (1):
  drm/dp_mst: Support remote i2c writes

Sidong Yang (1):
  drm/vkms: avoid warning in vkms_get_vblank_timestamp

Tian Tao (1):
  drm/hisilicon: Removed the dependency on the mmu

Ville Syrjälä (2):
  drm: Nuke mode->private_flags
  drm: Replace mode->export_head with a boolean

Vinod Koul (1):
  drm/bridge: Fix the dsi remote end-points

 .../bindings/display/panel/panel-simple.yaml   |   2 +
 Documentation/driver-api/driver-model/devres.rst   |   2 +-
 drivers/dma-buf/dma-fence.c|   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   8 +-
 drivers/gpu/drm/bridge/lontium-lt9611.c|   4 +-
 drivers/gpu/drm/drm_connector.c|  45 +---
 drivers/gpu/drm/drm_debugfs_crc.c  |   4 +-
 drivers/gpu/drm/drm_dp_mst_topology.c  | 106 +++---
 drivers/gpu/drm/drm_drv.c  |  78 -
 drivers/gpu/drm/drm_managed.c  |   2 +-
 drivers/gpu/drm/gma500/framebuffer.c   |   6 +-
 drivers/gpu/drm/hisilicon/hibmc/Kconfig|   2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c   | 101 +
 drivers/gpu/drm/nouveau/nouveau_bo.h   |   3 +
 drivers/gpu/drm/nouveau/nouveau_drv.h  |   2 +
 drivers/gpu/drm/nouveau/nouveau_ttm.c  |  44 +++-
 drivers/gpu/drm/panel/panel-raydium-rm67191.c  |   3 +-
 drivers/gpu/drm/panel/panel-simple.c   |  31 +-
 drivers/gpu/drm/radeon/radeon_ttm.c|   8 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c |   4 +-
 drivers/gpu/drm/ttm/ttm_bo.c   |  43 +++-
 drivers/gpu/drm/ttm/ttm_bo_util.c  | 121 ++---
 drivers/gpu/drm/ttm/ttm_bo_vm.c|  39 ++-
 drivers/gpu/drm/ttm/ttm_resource.c |   3 -
 drivers/gpu/drm/virtio/Kconfig |   2 +-
 drivers/gpu/drm/virtio/virtgpu_display.c   |  15 ++-
 drivers/gpu/drm/virtio/virtgpu_drv.h   |   2 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c |   6 +-
 drivers/gpu/drm/vkms/vkms_composer.c   |  55 +++---
 drivers/gpu/drm/vkms/vkms_crtc.c   |   5 +
 include/drm/drm_device.h   |   2 +-
 include/drm/drm_drv.h  |  16 +--
 include/drm/drm_modes.h|  

[Intel-gfx] [RESEND] Requests For Proposals for hosting XDC2021 are now open

[Lyude Paul]

(Including a bunch more emails in the To: that got missed the first time)

Hello everyone!

The X.org board is soliciting proposals to host XDC in 2021. Since
XDC2020 is being held virtually this year, we've decided to host in
either North America or Europe. However, the board is open to other
locations, especially if there's an interesting co-location with another
conference.

Of course though, due to the ongoing COVID-19 pandemic it's not yet
clear whether or not it will be possible to host XDC2021 in person.
Because of this, we would like to make it clear that sponsors should
prepare for both the possibility of an in person conference, and the
possibility of a virtual conference. We will work with organizers on
coming up with a deadline for deciding whether or not we'll be going
virtual, likely sometime around July.

If you're considering hosting XDC, we've assembled a wiki page with
what's generally expected and needed:

https://www.x.org/wiki/Events/RFP/

When submitting your proposal, please make sure to include at least the
key information about the potential location in question, possible dates
along with estimated costs. Proposals can be submitted to board at
foundation.x.org until the deadline of November 1st. Additionally, an
quirk early heads-up to the board if you're considering hosting would be
appreciated, in case we need to adjust the schedule a bit. Also, earlier
is better since there generally will be a bit of Q&A with organizers.

And if you just have some questions about what organizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

___
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: Unlock the shared hwsp_gtt object after pinning (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Unlock the shared hwsp_gtt object after pinning (rev2)
URL   : https://patchwork.freedesktop.org/series/81290/
State : failure

== Summary ==

Applying: drm/i915: Unlock the shared hwsp_gtt object after pinning
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gt/intel_context.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] ✓ Fi.CI.IGT: success for drm/i915: modeset probe cleanup

[Patchwork]

== Series Details ==

Series: drm/i915: modeset probe cleanup
URL   : https://patchwork.freedesktop.org/series/81267/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8955_full -> Patchwork_18435_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_read@short-buffer-wakeup:
- shard-skl:  [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +8 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8955/shard-skl4/igt@drm_r...@short-buffer-wakeup.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18435/shard-skl3/igt@drm_r...@short-buffer-wakeup.html

  * igt@gem_exec_reloc@basic-many-active@vecs0:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2389]) +2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8955/shard-glk7/igt@gem_exec_reloc@basic-many-act...@vecs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18435/shard-glk5/igt@gem_exec_reloc@basic-many-act...@vecs0.html

  * igt@gem_exec_whisper@basic-contexts-forked:
- shard-glk:  [PASS][5] -> [TIMEOUT][6] ([i915#1958]) +2 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8955/shard-glk2/igt@gem_exec_whis...@basic-contexts-forked.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18435/shard-glk2/igt@gem_exec_whis...@basic-contexts-forked.html

  * igt@gem_exec_whisper@basic-forked:
- shard-iclb: [PASS][7] -> [TIMEOUT][8] ([i915#1958])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8955/shard-iclb8/igt@gem_exec_whis...@basic-forked.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18435/shard-iclb1/igt@gem_exec_whis...@basic-forked.html

  * igt@gem_userptr_blits@unsync-unmap-cycles:
- shard-skl:  [PASS][9] -> [TIMEOUT][10] ([i915#1958])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8955/shard-skl10/igt@gem_userptr_bl...@unsync-unmap-cycles.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18435/shard-skl2/igt@gem_userptr_bl...@unsync-unmap-cycles.html

  * igt@i915_selftest@mock@contexts:
- shard-apl:  [PASS][11] -> [INCOMPLETE][12] ([i915#1635] / 
[i915#2278])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8955/shard-apl3/igt@i915_selftest@m...@contexts.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18435/shard-apl7/igt@i915_selftest@m...@contexts.html

  * igt@i915_suspend@fence-restore-untiled:
- shard-skl:  [PASS][13] -> [INCOMPLETE][14] ([i915#198])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8955/shard-skl4/igt@i915_susp...@fence-restore-untiled.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18435/shard-skl3/igt@i915_susp...@fence-restore-untiled.html

  * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-kbl:  [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +10 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8955/shard-kbl7/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18435/shard-kbl4/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html

  * igt@kms_frontbuffer_tracking@fbc-badstride:
- shard-apl:  [PASS][17] -> [DMESG-WARN][18] ([i915#1635] / 
[i915#1982]) +2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8955/shard-apl8/igt@kms_frontbuffer_track...@fbc-badstride.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18435/shard-apl2/igt@kms_frontbuffer_track...@fbc-badstride.html

  * igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8955/shard-tglb2/igt@kms_frontbuffer_track...@fbc-stridechange.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18435/shard-tglb1/igt@kms_frontbuffer_track...@fbc-stridechange.html
- shard-glk:  [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +1 
similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8955/shard-glk2/igt@kms_frontbuffer_track...@fbc-stridechange.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18435/shard-glk1/igt@kms_frontbuffer_track...@fbc-stridechange.html

  * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-wc:
- shard-skl:  [PASS][23] -> [FAIL][24] ([i915#49]) +1 similar issue
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8955/shard-skl9/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-wc.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18435/shard-skl3/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-wc.html

  * igt@kms_psr@psr2_cursor_blt:
- shard-iclb:

Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE register lookup

[Srivatsa, Anusha]

> -Original Message-
> From: Vivi, Rodrigo 
> Sent: Wednesday, September 2, 2020 2:32 PM
> To: Srivatsa, Anusha 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE register
> lookup
> 
> 
> 
> > On Sep 2, 2020, at 12:30 PM, Srivatsa, Anusha
>  wrote:
> >
> >
> >
> >> -Original Message-
> >> From: Rodrigo Vivi 
> >> Sent: Tuesday, September 1, 2020 12:30 PM
> >> To: Srivatsa, Anusha 
> >> Cc: intel-gfx@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE
> >> register lookup
> >>
> >> On Tue, Sep 01, 2020 at 11:27:58AM -0700, Anusha Srivatsa wrote:
> >>> We currenty check for platform at multiple parts in the driver to
> >>> grab the correct PLL. Let us begin to centralize it through a helper
> >>> function.
> >>>
> >>> v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg()
> >>> (Ville)
> >>>
> >>> Suggested-by: Matt Roper 
> >>> Cc: Ville Syrjälä 
> >>> Cc: Matt Roper 
> >>> Signed-off-by: Anusha Srivatsa 
> >>> ---
> >>> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 25
> >>> +++
> >>> 1 file changed, 15 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> >>> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> >>> index c9013f8f766f..7440836c5e44 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> >>> @@ -147,6 +147,18 @@ void assert_shared_dpll(struct
> drm_i915_private
> >> *dev_priv,
> >>>   pll->info->name, onoff(state), onoff(cur_state));  }
> >>>
> >>> +static
> >>> +i915_reg_t intel_combo_pll_enable_reg(struct drm_i915_private
> >> *dev_priv,
> >>> + struct intel_shared_dpll *pll) {
> >>> +
> >>> + if (IS_ELKHARTLAKE(dev_priv) && (pll->info->id ==
> >> DPLL_ID_EHL_DPLL4))
> >>> + return MG_PLL_ENABLE(0);
> >>> +
> >>> + return CNL_DPLL_ENABLE(pll->info->id);
> >>> +
> >>> +
> >>> +}
> >>> /**
> >>>  * intel_prepare_shared_dpll - call a dpll's prepare hook
> >>>  * @crtc_state: CRTC, and its state, which has a shared dpll @@
> >>> -3842,12 +3854,7 @@ static bool combo_pll_get_hw_state(struct
> >> drm_i915_private *dev_priv,
> >>>  struct intel_shared_dpll *pll,
> >>>  struct intel_dpll_hw_state *hw_state)  {
> >>> - i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
> >>> -
> >>> - if (IS_ELKHARTLAKE(dev_priv) &&
> >>> - pll->info->id == DPLL_ID_EHL_DPLL4) {
> >>> - enable_reg = MG_PLL_ENABLE(0);
> >>> - }
> >>> + i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
> >>>
> >>>   return icl_pll_get_hw_state(dev_priv, pll, hw_state, enable_reg);
> >>> } @@ -4045,11 +4052,10 @@ static void icl_pll_enable(struct
> >>> drm_i915_private *dev_priv,  static void combo_pll_enable(struct
> >> drm_i915_private *dev_priv,
> >>>struct intel_shared_dpll *pll)  {
> >>> - i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
> >>> + i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
> >>>
> >>>   if (IS_ELKHARTLAKE(dev_priv) &&
> >>>   pll->info->id == DPLL_ID_EHL_DPLL4) {
> >>
> >> there's probably something else that we can do now with the
> >> power_{put,get} to get rid of the, now, doubled if checks...
> >
> > Don't follow you here Rodrigo.
> 
> me neither ;)
> I'm just brainstorming... thinking out lout.
> 
> > Are you suggesting using power_{put/get} to somehow get rid of doubled
> if?
> 
> after this patch, on this path we will do this if check twice.
> not a big deal, but we can probably do something better.
> 
> However I don't understand why we had this get/put here at first place.
> Only for this platform and only for this pll4. So, what I am wondering is that
> we have something better to do with the power_well infrastructure in
> general that would allow us to avoid the if (platform && pll4) in favor of
> something more generic.
> 
> but definitely not a blocker for this patch itself.
Ok. So maybe the power well infrastructure change can be part a later patch?

> 
> >
> >>> - enable_reg = MG_PLL_ENABLE(0);
> >>>
> >>>   /*
> >>>* We need to disable DC states when this DPLL is enabled.
> >>> @@ -4157,11 +4163,10 @@ static void icl_pll_disable(struct
> >>> drm_i915_private *dev_priv,  static void combo_pll_disable(struct
> >> drm_i915_private *dev_priv,
> >>> struct intel_shared_dpll *pll)  {
> >>> - i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
> >>> + i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
> >>>
> >>>   if (IS_ELKHARTLAKE(dev_priv) &&
> >>>   pll->info->id == DPLL_ID_EHL_DPLL4) {
> >>> - enable_reg = MG_PLL_ENABLE(0);
> >>>   icl_pll_disable(dev_priv, pll, enable_reg);
> >>
> >> but here, at least, let's clean this function now...
> >> move t

Re: [Intel-gfx] [PATCH v6 02/11] drm/i915: Remove hw.mode

[Ville Syrjälä]

On Wed, Jul 15, 2020 at 03:42:13PM -0700, Manasi Navare wrote:
> From: Maarten Lankhorst 
> 
> The members in hw.mode can be used from adjusted_mode as well,
> use that when available.
> 
> Some places that use hw.mode can be converted to use adjusted_mode
> as well.
> 
> v2:
> * Manual rebase (Manasi)
> * remove the use of pipe_mode defined in patch 3 (Manasi)
> 
> v3:
> * Rebase on drm-tip (Manasi)

Previous review was apparently ignored. Or is there a better version
somewhere? If not, this still looks very wrong.

> 
> Signed-off-by: Maarten Lankhorst 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c  | 29 ++-
>  .../drm/i915/display/intel_display_types.h|  2 +-
>  drivers/gpu/drm/i915/display/intel_dvo.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_sdvo.c | 16 --
>  4 files changed, 23 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 729ec6e0d43a..8652a7c6bf11 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8892,9 +8892,6 @@ static void intel_get_pipe_src_size(struct intel_crtc 
> *crtc,
>   tmp = intel_de_read(dev_priv, PIPESRC(crtc->pipe));
>   pipe_config->pipe_src_h = (tmp & 0x) + 1;
>   pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1;
> -
> - pipe_config->hw.mode.vdisplay = pipe_config->pipe_src_h;
> - pipe_config->hw.mode.hdisplay = pipe_config->pipe_src_w;
>  }
>  
>  void intel_mode_from_pipe_config(struct drm_display_mode *mode,
> @@ -13079,7 +13076,7 @@ static void intel_dump_pipe_config(const struct 
> intel_crtc_state *pipe_config,
>   intel_dump_dp_vsc_sdp(dev_priv, &pipe_config->infoframes.vsc);
>  
>   drm_dbg_kms(&dev_priv->drm, "requested mode:\n");
> - drm_mode_debug_printmodeline(&pipe_config->hw.mode);
> + drm_mode_debug_printmodeline(&pipe_config->uapi.mode);
>   drm_dbg_kms(&dev_priv->drm, "adjusted mode:\n");
>   drm_mode_debug_printmodeline(&pipe_config->hw.adjusted_mode);
>   intel_dump_crtc_timings(dev_priv, &pipe_config->hw.adjusted_mode);
> @@ -13221,17 +13218,17 @@ intel_crtc_copy_uapi_to_hw_state(struct 
> intel_crtc_state *crtc_state)
>  {
>   crtc_state->hw.enable = crtc_state->uapi.enable;
>   crtc_state->hw.active = crtc_state->uapi.active;
> - crtc_state->hw.mode = crtc_state->uapi.mode;
>   crtc_state->hw.adjusted_mode = crtc_state->uapi.adjusted_mode;
>   intel_crtc_copy_uapi_to_hw_state_nomodeset(crtc_state);
>  }
>  
> -static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state 
> *crtc_state)
> +static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state 
> *crtc_state,
> +  struct drm_display_mode *user_mode)
>  {
>   crtc_state->uapi.enable = crtc_state->hw.enable;
>   crtc_state->uapi.active = crtc_state->hw.active;
>   drm_WARN_ON(crtc_state->uapi.crtc->dev,
> - drm_atomic_set_mode_for_crtc(&crtc_state->uapi, 
> &crtc_state->hw.mode) < 0);
> + drm_atomic_set_mode_for_crtc(&crtc_state->uapi, user_mode) 
> < 0);
>  
>   crtc_state->uapi.adjusted_mode = crtc_state->hw.adjusted_mode;
>  
> @@ -13277,6 +13274,10 @@ intel_crtc_prepare_cleared_state(struct 
> intel_crtc_state *crtc_state)
>   memcpy(crtc_state, saved_state, sizeof(*crtc_state));
>   kfree(saved_state);
>  
> + /* Clear I915_MODE_FLAG_INHERITED */
> + crtc_state->uapi.mode.private_flags = 0;
> + crtc_state->uapi.adjusted_mode.private_flags = 0;
> +
>   intel_crtc_copy_uapi_to_hw_state(crtc_state);
>  
>   return 0;
> @@ -13324,7 +13325,7 @@ intel_modeset_pipe_config(struct intel_crtc_state 
> *pipe_config)
>* computation to clearly distinguish it from the adjusted mode, which
>* can be changed by the connectors in the below retry loop.
>*/
> - drm_mode_get_hv_timing(&pipe_config->hw.mode,
> + drm_mode_get_hv_timing(&pipe_config->hw.adjusted_mode,
>  &pipe_config->pipe_src_w,
>  &pipe_config->pipe_src_h);
>  
> @@ -18461,15 +18462,11 @@ static void intel_modeset_readout_hw_state(struct 
> drm_device *dev)
>   int min_cdclk = 0;
>  
>   if (crtc_state->hw.active) {
> - struct drm_display_mode *mode = &crtc_state->hw.mode;
> + struct drm_display_mode mode;
>  
>   
> intel_mode_from_pipe_config(&crtc_state->hw.adjusted_mode,
>   crtc_state);
>  
> - *mode = crtc_state->hw.adjusted_mode;
> - mode->hdisplay = crtc_state->pipe_src_w;
> - mode->vdisplay = crtc_state->pipe_src_h;
> -
>   /*
>* The initial mode needs to be set in o

Re: [Intel-gfx] [PATCH v6 03/11] drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split

[Ville Syrjälä]

On Wed, Jul 15, 2020 at 03:42:14PM -0700, Manasi Navare wrote:
> From: Maarten Lankhorst 
> 
> v4:
> * Manual rebase (Manasi)
> v3:
> * Change state to crtc_state, fix rebase err  (Manasi)
> v2:
> * Manual Rebase (Manasi)
> 
> Signed-off-by: Maarten Lankhorst 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c  | 61 ---
>  .../drm/i915/display/intel_display_types.h| 11 ++-
>  drivers/gpu/drm/i915/intel_pm.c   | 76 +--
>  3 files changed, 79 insertions(+), 69 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8652a7c6bf11..78cbfefbfa62 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -152,7 +152,7 @@ static void ilk_pch_clock_get(struct intel_crtc *crtc,
>  static int intel_framebuffer_init(struct intel_framebuffer *ifb,
> struct drm_i915_gem_object *obj,
> struct drm_mode_fb_cmd2 *mode_cmd);
> -static void intel_set_pipe_timings(const struct intel_crtc_state 
> *crtc_state);
> +static void intel_set_transcoder_timings(const struct intel_crtc_state 
> *crtc_state);

These renames make it hard to see what changed. Should be split out.

>  static void intel_set_pipe_src_size(const struct intel_crtc_state 
> *crtc_state);
>  static void intel_cpu_transcoder_set_m_n(const struct intel_crtc_state 
> *crtc_state,
>const struct intel_link_m_n *m_n,
> @@ -6110,18 +6110,16 @@ skl_update_scaler(struct intel_crtc_state 
> *crtc_state, bool force_detach,
>  
>  static int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state)
>  {
> - const struct drm_display_mode *adjusted_mode =
> - &crtc_state->hw.adjusted_mode;
> + const struct drm_display_mode *pipe_mode = &crtc_state->hw.pipe_mode;
>   int width, height;
>  
>   if (crtc_state->pch_pfit.enabled) {
>   width = drm_rect_width(&crtc_state->pch_pfit.dst);
>   height = drm_rect_height(&crtc_state->pch_pfit.dst);
>   } else {
> - width = adjusted_mode->crtc_hdisplay;
> - height = adjusted_mode->crtc_vdisplay;
> + width = pipe_mode->crtc_hdisplay;
> + height = pipe_mode->crtc_vdisplay;
>   }
> -
>   return skl_update_scaler(crtc_state, !crtc_state->hw.active,
>SKL_CRTC_INDEX,
>&crtc_state->scaler_state.scaler_id,
> @@ -6901,7 +6899,7 @@ static void ilk_crtc_enable(struct intel_atomic_state 
> *state,
>   if (intel_crtc_has_dp_encoder(new_crtc_state))
>   intel_dp_set_m_n(new_crtc_state, M1_N1);
>  
> - intel_set_pipe_timings(new_crtc_state);
> + intel_set_transcoder_timings(new_crtc_state);
>   intel_set_pipe_src_size(new_crtc_state);
>  
>   if (new_crtc_state->has_pch_encoder)
> @@ -7046,7 +7044,7 @@ static void hsw_crtc_enable(struct intel_atomic_state 
> *state,
>   intel_encoders_pre_enable(state, crtc);
>  
>   if (!transcoder_is_dsi(cpu_transcoder))
> - intel_set_pipe_timings(new_crtc_state);
> + intel_set_transcoder_timings(new_crtc_state);
>  
>   intel_set_pipe_src_size(new_crtc_state);
>  
> @@ -7429,7 +7427,7 @@ static void valleyview_crtc_enable(struct 
> intel_atomic_state *state,
>   if (intel_crtc_has_dp_encoder(new_crtc_state))
>   intel_dp_set_m_n(new_crtc_state, M1_N1);
>  
> - intel_set_pipe_timings(new_crtc_state);
> + intel_set_transcoder_timings(new_crtc_state);
>   intel_set_pipe_src_size(new_crtc_state);
>  
>   if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B) {
> @@ -7497,7 +7495,7 @@ static void i9xx_crtc_enable(struct intel_atomic_state 
> *state,
>   if (intel_crtc_has_dp_encoder(new_crtc_state))
>   intel_dp_set_m_n(new_crtc_state, M1_N1);
>  
> - intel_set_pipe_timings(new_crtc_state);
> + intel_set_transcoder_timings(new_crtc_state);
>   intel_set_pipe_src_size(new_crtc_state);
>  
>   i9xx_set_pipeconf(new_crtc_state);
> @@ -7971,7 +7969,7 @@ static bool intel_crtc_supports_double_wide(const 
> struct intel_crtc *crtc)
>  
>  static u32 ilk_pipe_pixel_rate(const struct intel_crtc_state *crtc_state)
>  {
> - u32 pixel_rate = crtc_state->hw.adjusted_mode.crtc_clock;
> + u32 pixel_rate = crtc_state->hw.pipe_mode.crtc_clock;
>   unsigned int pipe_w, pipe_h, pfit_w, pfit_h;
>  
>   /*
> @@ -8008,7 +8006,7 @@ static void intel_crtc_compute_pixel_rate(struct 
> intel_crtc_state *crtc_state)
>   if (HAS_GMCH(dev_priv))
>   /* FIXME calculate proper pipe pixel rate for GMCH pfit */
>   crtc_state->pixel_rate =
> - crtc_state->hw.adjusted_mode.crtc_clock;
> + crtc_state->hw.pipe_mode.crtc_clock;
>   else
>   crtc_st

Re: [Intel-gfx] [PATCH v6 02/11] drm/i915: Remove hw.mode

[Navare, Manasi]

On Thu, Sep 03, 2020 at 08:49:44PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 15, 2020 at 03:42:13PM -0700, Manasi Navare wrote:
> > From: Maarten Lankhorst 
> > 
> > The members in hw.mode can be used from adjusted_mode as well,
> > use that when available.
> > 
> > Some places that use hw.mode can be converted to use adjusted_mode
> > as well.
> > 
> > v2:
> > * Manual rebase (Manasi)
> > * remove the use of pipe_mode defined in patch 3 (Manasi)
> > 
> > v3:
> > * Rebase on drm-tip (Manasi)
> 
> Previous review was apparently ignored. Or is there a better version
> somewhere? If not, this still looks very wrong.

This was the latest rev that Maarten had in his local tree which he said should 
address all the review comments.
What in particular looks wrong or what review comments were unaddressed here?

@Maarten any feedback on Ville's unaddressed comments?

Manasi

> 
> > 
> > Signed-off-by: Maarten Lankhorst 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c  | 29 ++-
> >  .../drm/i915/display/intel_display_types.h|  2 +-
> >  drivers/gpu/drm/i915/display/intel_dvo.c  |  2 +-
> >  drivers/gpu/drm/i915/display/intel_sdvo.c | 16 --
> >  4 files changed, 23 insertions(+), 26 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 729ec6e0d43a..8652a7c6bf11 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -8892,9 +8892,6 @@ static void intel_get_pipe_src_size(struct intel_crtc 
> > *crtc,
> > tmp = intel_de_read(dev_priv, PIPESRC(crtc->pipe));
> > pipe_config->pipe_src_h = (tmp & 0x) + 1;
> > pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1;
> > -
> > -   pipe_config->hw.mode.vdisplay = pipe_config->pipe_src_h;
> > -   pipe_config->hw.mode.hdisplay = pipe_config->pipe_src_w;
> >  }
> >  
> >  void intel_mode_from_pipe_config(struct drm_display_mode *mode,
> > @@ -13079,7 +13076,7 @@ static void intel_dump_pipe_config(const struct 
> > intel_crtc_state *pipe_config,
> > intel_dump_dp_vsc_sdp(dev_priv, &pipe_config->infoframes.vsc);
> >  
> > drm_dbg_kms(&dev_priv->drm, "requested mode:\n");
> > -   drm_mode_debug_printmodeline(&pipe_config->hw.mode);
> > +   drm_mode_debug_printmodeline(&pipe_config->uapi.mode);
> > drm_dbg_kms(&dev_priv->drm, "adjusted mode:\n");
> > drm_mode_debug_printmodeline(&pipe_config->hw.adjusted_mode);
> > intel_dump_crtc_timings(dev_priv, &pipe_config->hw.adjusted_mode);
> > @@ -13221,17 +13218,17 @@ intel_crtc_copy_uapi_to_hw_state(struct 
> > intel_crtc_state *crtc_state)
> >  {
> > crtc_state->hw.enable = crtc_state->uapi.enable;
> > crtc_state->hw.active = crtc_state->uapi.active;
> > -   crtc_state->hw.mode = crtc_state->uapi.mode;
> > crtc_state->hw.adjusted_mode = crtc_state->uapi.adjusted_mode;
> > intel_crtc_copy_uapi_to_hw_state_nomodeset(crtc_state);
> >  }
> >  
> > -static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state 
> > *crtc_state)
> > +static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state 
> > *crtc_state,
> > +struct drm_display_mode *user_mode)
> >  {
> > crtc_state->uapi.enable = crtc_state->hw.enable;
> > crtc_state->uapi.active = crtc_state->hw.active;
> > drm_WARN_ON(crtc_state->uapi.crtc->dev,
> > -   drm_atomic_set_mode_for_crtc(&crtc_state->uapi, 
> > &crtc_state->hw.mode) < 0);
> > +   drm_atomic_set_mode_for_crtc(&crtc_state->uapi, user_mode) 
> > < 0);
> >  
> > crtc_state->uapi.adjusted_mode = crtc_state->hw.adjusted_mode;
> >  
> > @@ -13277,6 +13274,10 @@ intel_crtc_prepare_cleared_state(struct 
> > intel_crtc_state *crtc_state)
> > memcpy(crtc_state, saved_state, sizeof(*crtc_state));
> > kfree(saved_state);
> >  
> > +   /* Clear I915_MODE_FLAG_INHERITED */
> > +   crtc_state->uapi.mode.private_flags = 0;
> > +   crtc_state->uapi.adjusted_mode.private_flags = 0;
> > +
> > intel_crtc_copy_uapi_to_hw_state(crtc_state);
> >  
> > return 0;
> > @@ -13324,7 +13325,7 @@ intel_modeset_pipe_config(struct intel_crtc_state 
> > *pipe_config)
> >  * computation to clearly distinguish it from the adjusted mode, which
> >  * can be changed by the connectors in the below retry loop.
> >  */
> > -   drm_mode_get_hv_timing(&pipe_config->hw.mode,
> > +   drm_mode_get_hv_timing(&pipe_config->hw.adjusted_mode,
> >&pipe_config->pipe_src_w,
> >&pipe_config->pipe_src_h);
> >  
> > @@ -18461,15 +18462,11 @@ static void intel_modeset_readout_hw_state(struct 
> > drm_device *dev)
> > int min_cdclk = 0;
> >  
> > if (crtc_state->hw.active) {
> > -   struct drm_display_mode *mode = &crtc_state->hw.mode;
> > +   struct drm_display_

Re: [Intel-gfx] [PATCH v6 05/11] drm/i915: Try to make bigjoiner work in atomic check

[Ville Syrjälä]

On Wed, Jul 15, 2020 at 03:42:16PM -0700, Manasi Navare wrote:
> From: Maarten Lankhorst 
> 
>  When the clock is higher than the dotclock, try with 2 pipes enabled.
>  If we can enable 2, then we will go into big joiner mode, and steal
>  the adjacent crtc.
> 
>  This only links the crtc's in software, no hardware or plane
>  programming is done yet. Blobs are also copied from the master's
>  crtc_state, so it doesn't depend at commit time on the other
>  crtc_state.
> 
> v3:
> * Manual Rebase (Manasi)
>  Changes since v1:
>  - Rename pipe timings to transcoder timings, as they are now different.
>   Changes since v2:
>  - Rework bigjoiner checks; always disable slave when recalculating
>master. No need to have a separate bigjoiner pass any more.
>  - Use pipe_mode instead of transcoder_mode, to clean up the code.
> 
> Signed-off-by: Maarten Lankhorst 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/display/intel_atomic.c   |   9 +-
>  drivers/gpu/drm/i915/display/intel_atomic.h   |   3 +-
>  drivers/gpu/drm/i915/display/intel_display.c  | 201 --
>  .../drm/i915/display/intel_display_types.h|   9 +
>  drivers/gpu/drm/i915/display/intel_dp.c   |  22 +-
>  5 files changed, 211 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 630f49b7aa01..b9dcdc74a10d 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -270,14 +270,15 @@ void intel_crtc_free_hw_state(struct intel_crtc_state 
> *crtc_state)
>   intel_crtc_put_color_blobs(crtc_state);
>  }
>  
> -void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state)
> +void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
> +  const struct intel_crtc_state *from_crtc_state)
>  {
>   drm_property_replace_blob(&crtc_state->hw.degamma_lut,
> -   crtc_state->uapi.degamma_lut);
> +   from_crtc_state->uapi.degamma_lut);
>   drm_property_replace_blob(&crtc_state->hw.gamma_lut,
> -   crtc_state->uapi.gamma_lut);
> +   from_crtc_state->uapi.gamma_lut);
>   drm_property_replace_blob(&crtc_state->hw.ctm,
> -   crtc_state->uapi.ctm);
> +   from_crtc_state->uapi.ctm);
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h 
> b/drivers/gpu/drm/i915/display/intel_atomic.h
> index 11146292b06f..fc556c032c8f 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.h
> @@ -43,7 +43,8 @@ struct drm_crtc_state *intel_crtc_duplicate_state(struct 
> drm_crtc *crtc);
>  void intel_crtc_destroy_state(struct drm_crtc *crtc,
>  struct drm_crtc_state *state);
>  void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state);
> -void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state);
> +void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
> +  const struct intel_crtc_state 
> *from_crtc_state);
>  struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
>  void intel_atomic_state_free(struct drm_atomic_state *state);
>  void intel_atomic_state_clear(struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3ecb642805a6..955e19abb563 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8016,9 +8016,24 @@ static int intel_crtc_compute_config(struct intel_crtc 
> *crtc,
>struct intel_crtc_state *pipe_config)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - const struct drm_display_mode *pipe_mode = &pipe_config->hw.pipe_mode;
> + struct drm_display_mode *pipe_mode = &pipe_config->hw.pipe_mode;
>   int clock_limit = dev_priv->max_dotclk_freq;
>  
> + *pipe_mode = pipe_config->hw.adjusted_mode;
> +
> + /* Adjust pipe_mode for bigjoiner, with half the horizontal mode */
> + if (pipe_config->bigjoiner) {
> + pipe_mode->crtc_clock /= 2;
> + pipe_mode->crtc_hdisplay /= 2;
> + pipe_mode->crtc_hblank_start /= 2;
> + pipe_mode->crtc_hblank_end /= 2;
> + pipe_mode->crtc_hsync_start /= 2;
> + pipe_mode->crtc_hsync_end /= 2;
> + pipe_mode->crtc_htotal /= 2;
> + pipe_mode->crtc_hskew /= 2;
> + pipe_config->pipe_src_w /= 2;
> + }
> +
>   if (INTEL_GEN(dev_priv) < 4) {
>   clock_limit = dev_priv->max_cdclk_freq * 9 / 10;
>  
> @@ -8079,7 +8094,7 @@ static int intel_crtc_compute_config(struct intel_crtc 
> *crtc,
>* WaPruneM

Re: [Intel-gfx] [PATCH v6 02/11] drm/i915: Remove hw.mode

[Ville Syrjälä]

On Thu, Sep 03, 2020 at 11:04:33AM -0700, Navare, Manasi wrote:
> On Thu, Sep 03, 2020 at 08:49:44PM +0300, Ville Syrjälä wrote:
> > On Wed, Jul 15, 2020 at 03:42:13PM -0700, Manasi Navare wrote:
> > > From: Maarten Lankhorst 
> > > 
> > > The members in hw.mode can be used from adjusted_mode as well,
> > > use that when available.
> > > 
> > > Some places that use hw.mode can be converted to use adjusted_mode
> > > as well.
> > > 
> > > v2:
> > > * Manual rebase (Manasi)
> > > * remove the use of pipe_mode defined in patch 3 (Manasi)
> > > 
> > > v3:
> > > * Rebase on drm-tip (Manasi)
> > 
> > Previous review was apparently ignored. Or is there a better version
> > somewhere? If not, this still looks very wrong.
> 
> This was the latest rev that Maarten had in his local tree which he said 
> should address all the review comments.
> What in particular looks wrong or what review comments were unaddressed here?

The dvo/sdvo changes.

> 
> @Maarten any feedback on Ville's unaddressed comments?
> 
> Manasi
> 
> > 
> > > 
> > > Signed-off-by: Maarten Lankhorst 
> > > Signed-off-by: Manasi Navare 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c  | 29 ++-
> > >  .../drm/i915/display/intel_display_types.h|  2 +-
> > >  drivers/gpu/drm/i915/display/intel_dvo.c  |  2 +-
> > >  drivers/gpu/drm/i915/display/intel_sdvo.c | 16 --
> > >  4 files changed, 23 insertions(+), 26 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 729ec6e0d43a..8652a7c6bf11 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -8892,9 +8892,6 @@ static void intel_get_pipe_src_size(struct 
> > > intel_crtc *crtc,
> > >   tmp = intel_de_read(dev_priv, PIPESRC(crtc->pipe));
> > >   pipe_config->pipe_src_h = (tmp & 0x) + 1;
> > >   pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1;
> > > -
> > > - pipe_config->hw.mode.vdisplay = pipe_config->pipe_src_h;
> > > - pipe_config->hw.mode.hdisplay = pipe_config->pipe_src_w;
> > >  }
> > >  
> > >  void intel_mode_from_pipe_config(struct drm_display_mode *mode,
> > > @@ -13079,7 +13076,7 @@ static void intel_dump_pipe_config(const struct 
> > > intel_crtc_state *pipe_config,
> > >   intel_dump_dp_vsc_sdp(dev_priv, &pipe_config->infoframes.vsc);
> > >  
> > >   drm_dbg_kms(&dev_priv->drm, "requested mode:\n");
> > > - drm_mode_debug_printmodeline(&pipe_config->hw.mode);
> > > + drm_mode_debug_printmodeline(&pipe_config->uapi.mode);
> > >   drm_dbg_kms(&dev_priv->drm, "adjusted mode:\n");
> > >   drm_mode_debug_printmodeline(&pipe_config->hw.adjusted_mode);
> > >   intel_dump_crtc_timings(dev_priv, &pipe_config->hw.adjusted_mode);
> > > @@ -13221,17 +13218,17 @@ intel_crtc_copy_uapi_to_hw_state(struct 
> > > intel_crtc_state *crtc_state)
> > >  {
> > >   crtc_state->hw.enable = crtc_state->uapi.enable;
> > >   crtc_state->hw.active = crtc_state->uapi.active;
> > > - crtc_state->hw.mode = crtc_state->uapi.mode;
> > >   crtc_state->hw.adjusted_mode = crtc_state->uapi.adjusted_mode;
> > >   intel_crtc_copy_uapi_to_hw_state_nomodeset(crtc_state);
> > >  }
> > >  
> > > -static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state 
> > > *crtc_state)
> > > +static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state 
> > > *crtc_state,
> > > +  struct drm_display_mode *user_mode)
> > >  {
> > >   crtc_state->uapi.enable = crtc_state->hw.enable;
> > >   crtc_state->uapi.active = crtc_state->hw.active;
> > >   drm_WARN_ON(crtc_state->uapi.crtc->dev,
> > > - drm_atomic_set_mode_for_crtc(&crtc_state->uapi, 
> > > &crtc_state->hw.mode) < 0);
> > > + drm_atomic_set_mode_for_crtc(&crtc_state->uapi, user_mode) 
> > > < 0);
> > >  
> > >   crtc_state->uapi.adjusted_mode = crtc_state->hw.adjusted_mode;
> > >  
> > > @@ -13277,6 +13274,10 @@ intel_crtc_prepare_cleared_state(struct 
> > > intel_crtc_state *crtc_state)
> > >   memcpy(crtc_state, saved_state, sizeof(*crtc_state));
> > >   kfree(saved_state);
> > >  
> > > + /* Clear I915_MODE_FLAG_INHERITED */
> > > + crtc_state->uapi.mode.private_flags = 0;
> > > + crtc_state->uapi.adjusted_mode.private_flags = 0;
> > > +
> > >   intel_crtc_copy_uapi_to_hw_state(crtc_state);
> > >  
> > >   return 0;
> > > @@ -13324,7 +13325,7 @@ intel_modeset_pipe_config(struct intel_crtc_state 
> > > *pipe_config)
> > >* computation to clearly distinguish it from the adjusted mode, which
> > >* can be changed by the connectors in the below retry loop.
> > >*/
> > > - drm_mode_get_hv_timing(&pipe_config->hw.mode,
> > > + drm_mode_get_hv_timing(&pipe_config->hw.adjusted_mode,
> > >  &pipe_config->pipe_src_w,
> > >  &pipe_config->pipe_src_h);
> > >  
> > > @@ -18461,15 +18462,11 @@ static void 
> > > intel_modeset_readou

Re: [Intel-gfx] [PATCH v6 08/11] drm/i915: Link planes in a bigjoiner configuration, v3.

[Ville Syrjälä]

On Wed, Jul 15, 2020 at 03:42:19PM -0700, Manasi Navare wrote:
> From: Maarten Lankhorst 
> 
>  Make sure that when a plane is set in a bigjoiner mode, we will add
>  their counterpart to the atomic state as well. This will allow us to
>  make sure all state is available when planes are checked.
> 
> Because of the funny interactions with bigjoiner and planar YUV
> formats, we may end up adding a lot of planes, so we have to keep
> iterating until we no longer add any planes.
> 
> Also fix the atomic intel plane iterator, so things watermarks start
> working automagically.
> 
> v5:
> * Rebase after adding sagv support (Manasi)
> v4:
> * Manual rebase (Manasi)
> Changes since v1:
> - Rebase on top of plane_state split, cleaning up the code a lot.
> - Make intel_atomic_crtc_state_for_each_plane_state() bigjoiner capable.
> - Add iter macro to intel_atomic_crtc_state_for_each_plane_state() to
>   keep iteration working.
> Changes since v2:
> - Add icl_(un)set_bigjoiner_plane_links, to make it more clear where
>   links are made and broken.
> 
> Signed-off-by: Maarten Lankhorst 
> Signed-off-by: Manasi Navare 
> ---
>  .../gpu/drm/i915/display/intel_atomic_plane.c |  52 -
>  .../gpu/drm/i915/display/intel_atomic_plane.h |   3 +-
>  drivers/gpu/drm/i915/display/intel_display.c  | 207 --
>  drivers/gpu/drm/i915/display/intel_display.h  |  20 +-
>  .../drm/i915/display/intel_display_types.h|  11 +
>  drivers/gpu/drm/i915/intel_pm.c   |  20 +-
>  6 files changed, 274 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 79032701873a..5c6e72063fac 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -246,11 +246,17 @@ static void intel_plane_clear_hw_state(struct 
> intel_plane_state *plane_state)
>   memset(&plane_state->hw, 0, sizeof(plane_state->hw));
>  }
>  
> -void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state *plane_state,
> +void intel_plane_copy_uapi_to_hw_state(const struct intel_crtc_state 
> *crtc_state,
> +struct intel_plane_state *plane_state,
>  const struct intel_plane_state 
> *from_plane_state)
>  {
>   intel_plane_clear_hw_state(plane_state);
>  
> + if (from_plane_state->uapi.crtc)
> + plane_state->hw.crtc = crtc_state->uapi.crtc;
> + else
> + plane_state->hw.crtc = NULL;
> +
>   plane_state->hw.crtc = from_plane_state->uapi.crtc;

eh?

>   plane_state->hw.fb = from_plane_state->uapi.fb;
>   if (plane_state->hw.fb)
> @@ -319,15 +325,36 @@ int intel_plane_atomic_check_with_state(const struct 
> intel_crtc_state *old_crtc_
>  }
>  
>  static struct intel_crtc *
> -get_crtc_from_states(const struct intel_plane_state *old_plane_state,
> +get_crtc_from_states(struct intel_atomic_state *state,
> +  const struct intel_plane_state *old_plane_state,
>const struct intel_plane_state *new_plane_state)
>  {
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_plane *plane = to_intel_plane(new_plane_state->uapi.plane);
> +
>   if (new_plane_state->uapi.crtc)
>   return to_intel_crtc(new_plane_state->uapi.crtc);
>  
>   if (old_plane_state->uapi.crtc)
>   return to_intel_crtc(old_plane_state->uapi.crtc);
>  
> + if (new_plane_state->bigjoiner_slave) {
> + const struct intel_plane_state *new_master_plane_state =
> + intel_atomic_get_new_plane_state(state, 
> new_plane_state->bigjoiner_plane);
> +
> + /* need to use uapi here, new_master_plane_state might not be 
> copied to hw yet */
> + if (new_master_plane_state->uapi.crtc)
> + return intel_get_crtc_for_pipe(dev_priv, plane->pipe);
> + }
> +
> + if (old_plane_state->bigjoiner_slave) {
> + const struct intel_plane_state *old_master_plane_state =
> + intel_atomic_get_old_plane_state(state, 
> old_plane_state->bigjoiner_plane);
> +
> + if (old_master_plane_state->uapi.crtc)
> + return intel_get_crtc_for_pipe(dev_priv, plane->pipe);
> + }
> +
>   return NULL;
>  }
>  
> @@ -338,18 +365,33 @@ int intel_plane_atomic_check(struct intel_atomic_state 
> *state,
>   intel_atomic_get_new_plane_state(state, plane);
>   const struct intel_plane_state *old_plane_state =
>   intel_atomic_get_old_plane_state(state, plane);
> + const struct intel_plane_state *new_master_plane_state;
>   struct intel_crtc *crtc =
> - get_crtc_from_states(old_plane_state, new_plane_state);
> + get_crtc_from_states(state, old_plane_state,
> +  new_plane_state);
>   const struct intel_crtc_st

Re: [Intel-gfx] [PATCH v6 10/11] drm/i915: Add intel_update_bigjoiner handling.

[Ville Syrjälä]

On Wed, Jul 15, 2020 at 03:42:21PM -0700, Manasi Navare wrote:
> From: Maarten Lankhorst 
> 
> Enabling is done in a special sequence and so should plane updates
> be. Ideally the end user never notices the second pipe is used,
> so use the vblank evasion to cover both pipes.
> 
> This way ideally everything will be tear free, and updates are
> really atomic as userspace expects it.
> 
> This needs to be checked if it still works since lot of refactoring
> in skl_commit_modeset_enables
> 
> v2:
> * Manual Rebase (Manasi)
> * Refactoring on intel_update_crtc and enable_crtc and removing
> special trans_port_sync_update (Manasi)
> 
> Signed-off-by: Maarten Lankhorst 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 120 +--
>  drivers/gpu/drm/i915/display/intel_sprite.c  |  25 +++-
>  drivers/gpu/drm/i915/display/intel_sprite.h  |   3 +-
>  3 files changed, 129 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index a1011414da6d..00b26863ffc6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15656,7 +15656,7 @@ static void intel_update_crtc(struct 
> intel_atomic_state *state,
>   else
>   i9xx_update_planes_on_crtc(state, crtc);
>  
> - intel_pipe_update_end(new_crtc_state);
> + intel_pipe_update_end(new_crtc_state, NULL);
>  
>   /*
>* We usually enable FIFO underrun interrupts as part of the
> @@ -15754,6 +15754,52 @@ static void intel_commit_modeset_disables(struct 
> intel_atomic_state *state)
>   }
>  }
>  
> +static void intel_update_bigjoiner(struct intel_crtc *crtc,
> +struct intel_atomic_state *state,
> +struct intel_crtc_state *old_crtc_state,
> +struct intel_crtc_state *new_crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + bool modeset = needs_modeset(new_crtc_state);
> + struct intel_crtc *slave = new_crtc_state->bigjoiner_linked_crtc;
> + struct intel_crtc_state *new_slave_crtc_state =
> + intel_atomic_get_new_crtc_state(state, slave);
> +
> + if (modeset) {
> + /* Enable slave first */
> + intel_crtc_update_active_timings(new_slave_crtc_state);
> + dev_priv->display.crtc_enable(state, slave);
> +
> + /* Then master */
> + intel_crtc_update_active_timings(new_crtc_state);
> + dev_priv->display.crtc_enable(state, crtc);
> +
> + /* vblanks work again, re-enable pipe CRC. */
> + intel_crtc_enable_pipe_crc(crtc);
> +
> + } else {
> + intel_pre_plane_update(state, crtc);
> + intel_pre_plane_update(state, slave);
> +
> + if (new_crtc_state->update_pipe)
> + intel_encoders_update_pipe(state, crtc);
> + }
> +
> + /*
> +  * Perform vblank evasion around commit operation, and make sure to
> +  * commit both planes simultaneously for best results.
> +  */
> + intel_pipe_update_start(new_crtc_state);
> +
> + commit_pipe_config(state, crtc);
> + commit_pipe_config(state, slave);
> +
> + skl_update_planes_on_crtc(state, crtc);
> + skl_update_planes_on_crtc(state, slave);
> +
> + intel_pipe_update_end(new_crtc_state, new_slave_crtc_state);
> +}

I think this should ideally all go away and just the normal logic
in commit_modeset_enables() should deal with it. Just like it does
for port sync/mst pipe dependencies.

> +
>  static void intel_commit_modeset_enables(struct intel_atomic_state *state)
>  {
>   struct intel_crtc_state *new_crtc_state;
> @@ -15772,15 +15818,22 @@ static void intel_commit_modeset_enables(struct 
> intel_atomic_state *state)
>  static void skl_commit_modeset_enables(struct intel_atomic_state *state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - struct intel_crtc *crtc;
> + struct intel_crtc *crtc, *slave;
>   struct intel_crtc_state *old_crtc_state, *new_crtc_state;
>   struct skl_ddb_entry entries[I915_MAX_PIPES] = {};
> + struct skl_ddb_entry new_entries[I915_MAX_PIPES] = {};
>   u8 update_pipes = 0, modeset_pipes = 0;
> + const struct intel_crtc_state *slave_crtc_state;
>   int i;
>  
>   for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state, 
> new_crtc_state, i) {
>   enum pipe pipe = crtc->pipe;
>  
> + if (new_crtc_state->bigjoiner_slave) {
> + /* We're updated from master */
> + continue;
> + }
> +
>   if (!new_crtc_state->hw.active)
>   continue;
>  
> @@ -15791,6 +15844,34 @@ static void skl_commit_modeset_enables(struct 
> intel_atomic_state *state)
>   } else {

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

[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/81284/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8957_full -> Patchwork_18436_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +6 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_exec_reloc@basic-active@all:
- shard-kbl:  [PASS][3] -> [INCOMPLETE][4] ([i915#2395])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-kbl4/igt@gem_exec_reloc@basic-act...@all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/shard-kbl7/igt@gem_exec_reloc@basic-act...@all.html

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

  * igt@gem_exec_whisper@basic-contexts:
- shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-glk6/igt@gem_exec_whis...@basic-contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/shard-glk7/igt@gem_exec_whis...@basic-contexts.html

  * igt@gem_exec_whisper@basic-fds:
- shard-iclb: [PASS][9] -> [TIMEOUT][10] ([i915#1958])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-iclb4/igt@gem_exec_whis...@basic-fds.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/shard-iclb5/igt@gem_exec_whis...@basic-fds.html

  * igt@gem_exec_whisper@basic-normal:
- shard-tglb: [PASS][11] -> [TIMEOUT][12] ([i915#1958]) +2 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-tglb1/igt@gem_exec_whis...@basic-normal.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/shard-tglb2/igt@gem_exec_whis...@basic-normal.html

  * igt@gem_userptr_blits@unsync-unmap-cycles:
- shard-skl:  [PASS][13] -> [TIMEOUT][14] ([i915#1958]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-skl5/igt@gem_userptr_bl...@unsync-unmap-cycles.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/shard-skl1/igt@gem_userptr_bl...@unsync-unmap-cycles.html

  * igt@kms_big_fb@linear-64bpp-rotate-180:
- shard-glk:  [PASS][15] -> [DMESG-FAIL][16] ([i915#118] / 
[i915#95])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-glk4/igt@kms_big...@linear-64bpp-rotate-180.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html

  * igt@kms_cursor_legacy@flip-vs-cursor-toggle:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#2346])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-skl4/igt@kms_cursor_leg...@flip-vs-cursor-toggle.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/shard-skl10/igt@kms_cursor_leg...@flip-vs-cursor-toggle.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1:
- shard-skl:  [PASS][19] -> [FAIL][20] ([i915#79])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html

  * igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a1:
- shard-glk:  [PASS][21] -> [FAIL][22] ([i915#2122])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-glk3/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a1.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/shard-glk9/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a1.html

  * igt@kms_flip@modeset-vs-vblank-race@b-hdmi-a2:
- shard-glk:  [PASS][23] -> [FAIL][24] ([i915#407])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-glk2/igt@kms_flip@modeset-vs-vblank-r...@b-hdmi-a2.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18436/shard-glk2/igt@kms_flip@modeset-vs-vblank-r...@b-hdmi-a2.html

  * igt@kms_flip_tiling@flip-changes-tiling:
- shard-skl:

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

[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/81287/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8957_full -> Patchwork_18437_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_whisper@basic-forked:
- shard-tglb: [PASS][1] -> [TIMEOUT][2] ([i915#1958])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-tglb3/igt@gem_exec_whis...@basic-forked.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/shard-tglb1/igt@gem_exec_whis...@basic-forked.html

  * igt@gem_exec_whisper@basic-normal:
- shard-apl:  [PASS][3] -> [TIMEOUT][4] ([i915#1635] / [i915#1958])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-apl8/igt@gem_exec_whis...@basic-normal.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/shard-apl7/igt@gem_exec_whis...@basic-normal.html

  * igt@gem_exec_whisper@basic-queues:
- shard-kbl:  [PASS][5] -> [TIMEOUT][6] ([i915#1958])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-kbl7/igt@gem_exec_whis...@basic-queues.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/shard-kbl1/igt@gem_exec_whis...@basic-queues.html
- shard-iclb: [PASS][7] -> [TIMEOUT][8] ([i915#1958])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-iclb8/igt@gem_exec_whis...@basic-queues.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/shard-iclb4/igt@gem_exec_whis...@basic-queues.html
- shard-glk:  [PASS][9] -> [TIMEOUT][10] ([i915#1958]) +1 similar 
issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-glk8/igt@gem_exec_whis...@basic-queues.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/shard-glk3/igt@gem_exec_whis...@basic-queues.html

  * igt@gem_sync@basic-store-all:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2356])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-tglb7/igt@gem_s...@basic-store-all.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/shard-tglb5/igt@gem_s...@basic-store-all.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-180:
- shard-glk:  [PASS][13] -> [DMESG-FAIL][14] ([i915#118] / 
[i915#95])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-glk2/igt@kms_big...@y-tiled-64bpp-rotate-180.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html

  * igt@kms_flip@flip-vs-expired-vblank@b-edp1:
- shard-skl:  [PASS][15] -> [FAIL][16] ([i915#79])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/shard-skl6/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html

  * igt@kms_flip@wf_vblank-ts-check-interruptible@a-dp1:
- shard-kbl:  [PASS][17] -> [DMESG-WARN][18] ([i915#1982])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-kbl4/igt@kms_flip@wf_vblank-ts-check-interrupti...@a-dp1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/shard-kbl4/igt@kms_flip@wf_vblank-ts-check-interrupti...@a-dp1.html

  * igt@kms_flip_tiling@flip-changes-tiling:
- shard-skl:  [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +13 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-skl4/igt@kms_flip_til...@flip-changes-tiling.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/shard-skl4/igt@kms_flip_til...@flip-changes-tiling.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move:
- shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +2 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-tglb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/shard-tglb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html

  * igt@kms_hdr@bpc-switch-dpms:
- shard-skl:  [PASS][23] -> [FAIL][24] ([i915#1188])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-skl5/igt@kms_...@bpc-switch-dpms.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18437/shard-skl7/igt@kms_...@bpc-switch-dpms.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-glk:  [PASS][25] -> [DMESG-WARN][26] ([i915#1982])
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8957/shard-glk9/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

[Intel-gfx] ✗ Fi.CI.IGT: failure for Gen12 HDCP 1.4 support on DP MST

[Patchwork]

== Series Details ==

Series: Gen12 HDCP 1.4 support on DP MST
URL   : https://patchwork.freedesktop.org/series/81289/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8958_full -> Patchwork_18438_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18438_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18438_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_18438_full:

### IGT changes ###

 Possible regressions 

  * igt@perf@oa-formats:
- shard-iclb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8958/shard-iclb5/igt@p...@oa-formats.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18438/shard-iclb2/igt@p...@oa-formats.html

  
Known issues


  Here are the changes found in Patchwork_18438_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]) 
+3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8958/shard-apl6/igt@gem_exec_re...@basic-concurrent0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18438/shard-apl4/igt@gem_exec_re...@basic-concurrent0.html

  * igt@gem_exec_whisper@basic-normal:
- shard-skl:  [PASS][5] -> [TIMEOUT][6] ([i915#1958])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8958/shard-skl5/igt@gem_exec_whis...@basic-normal.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18438/shard-skl2/igt@gem_exec_whis...@basic-normal.html

  * igt@gem_exec_whisper@basic-queues:
- shard-glk:  [PASS][7] -> [TIMEOUT][8] ([i915#1958])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8958/shard-glk7/igt@gem_exec_whis...@basic-queues.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18438/shard-glk6/igt@gem_exec_whis...@basic-queues.html

  * igt@gem_mmap@short-mmap:
- shard-tglb: [PASS][9] -> [TIMEOUT][10] ([i915#1958]) +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8958/shard-tglb7/igt@gem_m...@short-mmap.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18438/shard-tglb5/igt@gem_m...@short-mmap.html

  * igt@gem_partial_pwrite_pread@reads-display:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2261])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8958/shard-glk5/igt@gem_partial_pwrite_pr...@reads-display.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18438/shard-glk8/igt@gem_partial_pwrite_pr...@reads-display.html

  * igt@i915_module_load@reload:
- shard-tglb: [PASS][13] -> [TIMEOUT][14] ([i915#1418] / 
[i915#1958])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8958/shard-tglb7/igt@i915_module_l...@reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18438/shard-tglb5/igt@i915_module_l...@reload.html
- shard-iclb: [PASS][15] -> [TIMEOUT][16] ([i915#1418] / 
[i915#1958])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8958/shard-iclb5/igt@i915_module_l...@reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18438/shard-iclb2/igt@i915_module_l...@reload.html

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

  * igt@kms_color@pipe-c-ctm-blue-to-red:
- shard-iclb: [PASS][19] -> [TIMEOUT][20] ([i915#1149] / 
[i915#1958])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8958/shard-iclb5/igt@kms_co...@pipe-c-ctm-blue-to-red.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18438/shard-iclb2/igt@kms_co...@pipe-c-ctm-blue-to-red.html
- shard-tglb: [PASS][21] -> [TIMEOUT][22] ([i915#1149] / 
[i915#1958])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8958/shard-tglb7/igt@kms_co...@pipe-c-ctm-blue-to-red.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18438/shard-tglb5/igt@kms_co...@pipe-c-ctm-blue-to-red.html

  * igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled:
- shard-skl:  [PASS][23] -> [FAIL][24] ([i915#177] / [i915#52] / 
[i915#54])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8958/shard-skl9/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html
   [24]: 
https://intel-gfx-ci.01.

[Intel-gfx] [PATCH 1/3] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3

[Vidya Srinivas]

From: Khaled Almahallawy 

Add the missing CP2520 pattern 2 and 3 phy compliance patterns

v2: cosemtic changes

Reviewed-by: Manasi Navare  (v1)
Signed-off-by: Khaled Almahallawy 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 include/drm/drm_dp_helper.h | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a3c82e726057..d0fb78c6aca6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1583,7 +1583,7 @@ int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
return err;
 
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
   &data->hbr2_reset,
   sizeof(data->hbr2_reset));
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e2d2df5e869e..73285b4c25a0 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -708,7 +708,9 @@
 # define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
 # define DP_PHY_TEST_PATTERN_PRBS7  0x3
 # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
-# define DP_PHY_TEST_PATTERN_CP2520 0x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT10x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT20x6
+# define DP_PHY_TEST_PATTERN_CP2520_PAT30x7
 
 #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
 #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
-- 
2.7.4

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

[Intel-gfx] [PATCH 3/3] [RFC] drm/i915/dp: DP PHY compliance for EHL/JSL

[Vidya Srinivas]

Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.

v2: Rebased patch on top of Khaled's (yet to be merged):
https://patchwork.freedesktop.org/series/79779/
Fixed phy patterns for JSL/EHL
Add TPS4 support for JSL/EHL

Signed-off-by: Khaled Almahallawy 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 81 +
 drivers/gpu/drm/i915/i915_reg.h | 18 ++--
 2 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a8a3ffcef5dc..1773f3d5d0f4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5405,25 +5405,32 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
enum pipe pipe = crtc->pipe;
u32 pattern_val, dp_tp_ctl;
 
+   i915_reg_t dp_comp_reg;
+
+   if (IS_ELKHARTLAKE(dev_priv))
+   dp_comp_reg = EHL_DDI_DP_COMP_CTL(dig_port->base.port);
+   else if (IS_TIGERLAKE(dev_priv))
+   dp_comp_reg = DDI_DP_COMP_CTL(pipe);
+
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   intel_de_write(dev_priv, dp_comp_reg, 0x0);
break;
case DP_PHY_TEST_PATTERN_D10_2:
DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
break;
case DP_PHY_TEST_PATTERN_ERROR_COUNT:
DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_SCRAMBLED_0);
break;
case DP_PHY_TEST_PATTERN_PRBS7:
DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
break;
case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
@@ -5432,14 +5439,27 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 * current firmware of DPR-100 could not set it, so hardcoding
 * now for complaince test.
 */
-   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern 0x3e0f83e0 
0x0f83e0f8 0xf83e\n");
+   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern \
+ 0x3e0f83e0 0x0f83e0f8 0xf83e\n");
pattern_val = 0x3e0f83e0;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 0),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), 
pattern_val);
pattern_val = 0x0f83e0f8;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 1),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), 
pattern_val);
pattern_val = 0xf83e;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 2),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), 
pattern_val);
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
@@ -5451,7 +5471,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 */
DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
pattern_val = 0xFB;
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+

[Intel-gfx] [PATCH 2/3] drm/i915/dp: TPS4 PHY test pattern compliance support

[Vidya Srinivas]

From: Khaled Almahallawy 

Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.

v2: uniform bit names TP4a/b/c (Manasi)

Signed-off-by: Khaled Almahallawy 
Reviewed-by: Manasi Navare 
Tested-by: Khaled Almahallawy 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 14 --
 drivers/gpu/drm/i915/i915_reg.h |  4 
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 04231ca5643b..a8a3ffcef5dc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5403,7 +5403,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
&intel_dp->compliance.test_data.phytest;
struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
enum pipe pipe = crtc->pipe;
-   u32 pattern_val;
+   u32 pattern_val, dp_tp_ctl;
 
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
@@ -5443,7 +5443,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
/*
 * FIXME: Ideally pattern should come from DPCD 0x24A. As
 * current firmware of DPR-100 could not set it, so hardcoding
@@ -5455,6 +5455,16 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
   pattern_val);
break;
+   case DP_PHY_TEST_PATTERN_CP2520_PAT3:
+   DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
+   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   dp_tp_ctl = intel_de_read(dev_priv, 
TGL_DP_TP_CTL(pipe));
+   dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
+   dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
+   dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
+   dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
+   intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), 
dp_tp_ctl);
+   break;
default:
WARN(1, "Invalid Phy Test Pattern\n");
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ab4b1abd4364..4850890918dc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9974,6 +9974,10 @@ enum skl_power_gate {
 #define  DP_TP_CTL_MODE_SST(0 << 27)
 #define  DP_TP_CTL_MODE_MST(1 << 27)
 #define  DP_TP_CTL_FORCE_ACT   (1 << 25)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
 #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE   (1 << 18)
 #define  DP_TP_CTL_FDI_AUTOTRAIN   (1 << 15)
 #define  DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
-- 
2.7.4

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

[Intel-gfx] [PATCH] drm/i915/dp: DP PHY compliance for EHL/JSL

[Vidya Srinivas]

v2: Rebased patch on top of:
https://patchwork.freedesktop.org/series/79779/
Fixed phy patterns for JSL/EHL
Add TPS4 support for JSL/EHL

Signed-off-by: Khaled Almahallawy 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 81 +
 drivers/gpu/drm/i915/i915_reg.h | 18 ++--
 2 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a8a3ffcef5dc..1773f3d5d0f4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5405,25 +5405,32 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
enum pipe pipe = crtc->pipe;
u32 pattern_val, dp_tp_ctl;
 
+   i915_reg_t dp_comp_reg;
+
+   if (IS_ELKHARTLAKE(dev_priv))
+   dp_comp_reg = EHL_DDI_DP_COMP_CTL(dig_port->base.port);
+   else if (IS_TIGERLAKE(dev_priv))
+   dp_comp_reg = DDI_DP_COMP_CTL(pipe);
+
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   intel_de_write(dev_priv, dp_comp_reg, 0x0);
break;
case DP_PHY_TEST_PATTERN_D10_2:
DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
break;
case DP_PHY_TEST_PATTERN_ERROR_COUNT:
DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_SCRAMBLED_0);
break;
case DP_PHY_TEST_PATTERN_PRBS7:
DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
break;
case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
@@ -5432,14 +5439,27 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 * current firmware of DPR-100 could not set it, so hardcoding
 * now for complaince test.
 */
-   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern 0x3e0f83e0 
0x0f83e0f8 0xf83e\n");
+   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern \
+ 0x3e0f83e0 0x0f83e0f8 0xf83e\n");
pattern_val = 0x3e0f83e0;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 0),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), 
pattern_val);
pattern_val = 0x0f83e0f8;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 1),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), 
pattern_val);
pattern_val = 0xf83e;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 2),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), 
pattern_val);
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
@@ -5451,7 +5471,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 */
DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
pattern_val = 0xFB;
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
   pattern_val);
break;
@@ -5478,22 +5498,32 @@ intel_dp_autotest_phy_ddi_disable(struct intel_dp 
*intel_dp)
struct 

[Intel-gfx] [PATCH 3/3] [RFC] drm/i915/dp: DP PHY compliance for EHL/JSL

[Vidya Srinivas]

Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.

v2: Rebased patch on top of Khaled's (yet to be merged):
https://patchwork.freedesktop.org/series/79779/
Fixed phy patterns for JSL/EHL
Add TPS4 support for JSL/EHL

Signed-off-by: Khaled Almahallawy 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 81 +
 drivers/gpu/drm/i915/i915_reg.h | 18 ++--
 2 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a8a3ffcef5dc..1773f3d5d0f4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5405,25 +5405,32 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
enum pipe pipe = crtc->pipe;
u32 pattern_val, dp_tp_ctl;
 
+   i915_reg_t dp_comp_reg;
+
+   if (IS_ELKHARTLAKE(dev_priv))
+   dp_comp_reg = EHL_DDI_DP_COMP_CTL(dig_port->base.port);
+   else if (IS_TIGERLAKE(dev_priv))
+   dp_comp_reg = DDI_DP_COMP_CTL(pipe);
+
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   intel_de_write(dev_priv, dp_comp_reg, 0x0);
break;
case DP_PHY_TEST_PATTERN_D10_2:
DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
break;
case DP_PHY_TEST_PATTERN_ERROR_COUNT:
DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_SCRAMBLED_0);
break;
case DP_PHY_TEST_PATTERN_PRBS7:
DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
break;
case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
@@ -5432,14 +5439,27 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 * current firmware of DPR-100 could not set it, so hardcoding
 * now for complaince test.
 */
-   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern 0x3e0f83e0 
0x0f83e0f8 0xf83e\n");
+   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern \
+ 0x3e0f83e0 0x0f83e0f8 0xf83e\n");
pattern_val = 0x3e0f83e0;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 0),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), 
pattern_val);
pattern_val = 0x0f83e0f8;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 1),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), 
pattern_val);
pattern_val = 0xf83e;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 2),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), 
pattern_val);
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
@@ -5451,7 +5471,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 */
DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
pattern_val = 0xFB;
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+

[Intel-gfx] [PATCH 1/3] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3

[Vidya Srinivas]

From: Khaled Almahallawy 

Add the missing CP2520 pattern 2 and 3 phy compliance patterns

v2: cosemtic changes

Reviewed-by: Manasi Navare  (v1)
Signed-off-by: Khaled Almahallawy 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 include/drm/drm_dp_helper.h | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a3c82e726057..d0fb78c6aca6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1583,7 +1583,7 @@ int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
return err;
 
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
   &data->hbr2_reset,
   sizeof(data->hbr2_reset));
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e2d2df5e869e..73285b4c25a0 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -708,7 +708,9 @@
 # define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
 # define DP_PHY_TEST_PATTERN_PRBS7  0x3
 # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
-# define DP_PHY_TEST_PATTERN_CP2520 0x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT10x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT20x6
+# define DP_PHY_TEST_PATTERN_CP2520_PAT30x7
 
 #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
 #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
-- 
2.7.4

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

[Intel-gfx] [PATCH 2/3] drm/i915/dp: TPS4 PHY test pattern compliance support

[Vidya Srinivas]

From: Khaled Almahallawy 

Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.

v2: uniform bit names TP4a/b/c (Manasi)

Signed-off-by: Khaled Almahallawy 
Reviewed-by: Manasi Navare 
Tested-by: Khaled Almahallawy 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 14 --
 drivers/gpu/drm/i915/i915_reg.h |  4 
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 04231ca5643b..a8a3ffcef5dc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5403,7 +5403,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
&intel_dp->compliance.test_data.phytest;
struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
enum pipe pipe = crtc->pipe;
-   u32 pattern_val;
+   u32 pattern_val, dp_tp_ctl;
 
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
@@ -5443,7 +5443,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
/*
 * FIXME: Ideally pattern should come from DPCD 0x24A. As
 * current firmware of DPR-100 could not set it, so hardcoding
@@ -5455,6 +5455,16 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
   pattern_val);
break;
+   case DP_PHY_TEST_PATTERN_CP2520_PAT3:
+   DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
+   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   dp_tp_ctl = intel_de_read(dev_priv, 
TGL_DP_TP_CTL(pipe));
+   dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
+   dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
+   dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
+   dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
+   intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), 
dp_tp_ctl);
+   break;
default:
WARN(1, "Invalid Phy Test Pattern\n");
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ab4b1abd4364..4850890918dc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9974,6 +9974,10 @@ enum skl_power_gate {
 #define  DP_TP_CTL_MODE_SST(0 << 27)
 #define  DP_TP_CTL_MODE_MST(1 << 27)
 #define  DP_TP_CTL_FORCE_ACT   (1 << 25)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
 #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE   (1 << 18)
 #define  DP_TP_CTL_FDI_AUTOTRAIN   (1 << 15)
 #define  DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
-- 
2.7.4

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

[Intel-gfx] [PATCH 3/3] [RFC] drm/i915/dp: DP PHY compliance for EHL/JSL

[Vidya Srinivas]

Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.

v2: Rebased patch on top of Khaled's (yet to be merged):
https://patchwork.freedesktop.org/series/79779/
Fixed phy patterns for JSL/EHL
Add TPS4 support for JSL/EHL

Signed-off-by: Khaled Almahallawy 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 81 +
 drivers/gpu/drm/i915/i915_reg.h | 18 ++--
 2 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a8a3ffcef5dc..1773f3d5d0f4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5405,25 +5405,32 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
enum pipe pipe = crtc->pipe;
u32 pattern_val, dp_tp_ctl;
 
+   i915_reg_t dp_comp_reg;
+
+   if (IS_ELKHARTLAKE(dev_priv))
+   dp_comp_reg = EHL_DDI_DP_COMP_CTL(dig_port->base.port);
+   else if (IS_TIGERLAKE(dev_priv))
+   dp_comp_reg = DDI_DP_COMP_CTL(pipe);
+
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   intel_de_write(dev_priv, dp_comp_reg, 0x0);
break;
case DP_PHY_TEST_PATTERN_D10_2:
DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
break;
case DP_PHY_TEST_PATTERN_ERROR_COUNT:
DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_SCRAMBLED_0);
break;
case DP_PHY_TEST_PATTERN_PRBS7:
DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
break;
case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
@@ -5432,14 +5439,27 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 * current firmware of DPR-100 could not set it, so hardcoding
 * now for complaince test.
 */
-   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern 0x3e0f83e0 
0x0f83e0f8 0xf83e\n");
+   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern \
+ 0x3e0f83e0 0x0f83e0f8 0xf83e\n");
pattern_val = 0x3e0f83e0;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 0),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), 
pattern_val);
pattern_val = 0x0f83e0f8;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 1),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), 
pattern_val);
pattern_val = 0xf83e;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 2),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), 
pattern_val);
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
@@ -5451,7 +5471,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 */
DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
pattern_val = 0xFB;
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+

[Intel-gfx] [PATCH 2/3] drm/i915/dp: TPS4 PHY test pattern compliance support

[Vidya Srinivas]

From: Khaled Almahallawy 

Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.

v2: uniform bit names TP4a/b/c (Manasi)

Signed-off-by: Khaled Almahallawy 
Reviewed-by: Manasi Navare 
Tested-by: Khaled Almahallawy 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 14 --
 drivers/gpu/drm/i915/i915_reg.h |  4 
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 04231ca5643b..a8a3ffcef5dc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5403,7 +5403,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
&intel_dp->compliance.test_data.phytest;
struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
enum pipe pipe = crtc->pipe;
-   u32 pattern_val;
+   u32 pattern_val, dp_tp_ctl;
 
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
@@ -5443,7 +5443,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
/*
 * FIXME: Ideally pattern should come from DPCD 0x24A. As
 * current firmware of DPR-100 could not set it, so hardcoding
@@ -5455,6 +5455,16 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
   pattern_val);
break;
+   case DP_PHY_TEST_PATTERN_CP2520_PAT3:
+   DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
+   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   dp_tp_ctl = intel_de_read(dev_priv, 
TGL_DP_TP_CTL(pipe));
+   dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
+   dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
+   dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
+   dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
+   intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), 
dp_tp_ctl);
+   break;
default:
WARN(1, "Invalid Phy Test Pattern\n");
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ab4b1abd4364..4850890918dc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9974,6 +9974,10 @@ enum skl_power_gate {
 #define  DP_TP_CTL_MODE_SST(0 << 27)
 #define  DP_TP_CTL_MODE_MST(1 << 27)
 #define  DP_TP_CTL_FORCE_ACT   (1 << 25)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
 #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE   (1 << 18)
 #define  DP_TP_CTL_FDI_AUTOTRAIN   (1 << 15)
 #define  DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
-- 
2.7.4

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

[Intel-gfx] [PATCH 1/3] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3

[Vidya Srinivas]

From: Khaled Almahallawy 

Add the missing CP2520 pattern 2 and 3 phy compliance patterns

v2: cosemtic changes

Reviewed-by: Manasi Navare  (v1)
Signed-off-by: Khaled Almahallawy 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 include/drm/drm_dp_helper.h | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a3c82e726057..d0fb78c6aca6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1583,7 +1583,7 @@ int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
return err;
 
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
   &data->hbr2_reset,
   sizeof(data->hbr2_reset));
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e2d2df5e869e..73285b4c25a0 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -708,7 +708,9 @@
 # define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
 # define DP_PHY_TEST_PATTERN_PRBS7  0x3
 # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
-# define DP_PHY_TEST_PATTERN_CP2520 0x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT10x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT20x6
+# define DP_PHY_TEST_PATTERN_CP2520_PAT30x7
 
 #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
 #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
-- 
2.7.4

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