date:20211230

https://bugzilla.kernel.org/show_bug.cgi?id=215436

--- Comment #3 from spassw...@web.de ---
I added printk at the beginnig and exit(s) of rn_clocks_update:
This is the result when resuming from suspend on commit
d020970959169627d59a711769f8c4b87bf5f90c

Dec 30 13:55:42 lisa kernel: [  140.198849] PM: suspend exit
Dec 30 13:55:42 lisa kernel: [  140.208063] amdgpu: entering rn_update_clocks
...
Dec 30 13:55:42 lisa kernel: [  140.209251] amdgpu: leaving rn_update_clocks
...
Dec 30 13:55:42 lisa kernel: [  140.211147] amdgpu: entering rn_update_clocks
...
Dec 30 13:55:42 lisa kernel: [  140.211148] amdgpu: leaving rn_update_clocks
...
Dec 30 13:55:42 lisa kernel: [  140.226830] Generic FE-GE Realtek PHY
r8169-0-500:00: attached PHY driver (mii_bus:phy_addr=r8169-0-500:00, irq=MAC)
Dec 30 13:55:42 lisa kernel: [  140.277915] amdgpu: entering rn_update_clocks
...
Dec 30 13:55:42 lisa kernel: [  140.277925] amdgpu: leaving rn_update_clocks
...
Dec 30 13:55:42 lisa kernel: [  140.278233] amdgpu: entering rn_update_clocks
...
Dec 30 13:55:42 lisa kernel: [  140.278234] amdgpu: leaving rn_update_clocks
...

In this case the system does not hang, but suspend doesn't seem to work
properly, either (Fan and keyboard do not switch off). I probably missed that
during the first bisection.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215436] admgpu: suspend and resuming from suspend don't work

https://bugzilla.kernel.org/show_bug.cgi?id=215436

--- Comment #4 from spassw...@web.de ---
Unfortunately I optimized my .config to make bisections faster, but now I
cannot reproduce the Hang with commit 2a50edbf10c8c56e930bfb53d8f9f00a33fd837e.
So now I will start over with the bisection ...

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [syzbot] general protection fault in sg_alloc_append_table_from_pages

2021-12-30 Thread Pavel Skripkin


On 10/13/21 19:51, syzbot wrote:

Hello,

syzbot found the following issue on:

HEAD commit:717478d89fe2 Merge tag 'riscv-for-linus-5.15-rc5' of git:/..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12489abf30
kernel config:  https://syzkaller.appspot.com/x/.config?x=32e6048063923b7b
dashboard link: https://syzkaller.appspot.com/bug?extid=2c56b725ec547fa9cb29
compiler:   gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for 
Debian) 2.35.2
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=167b9e4f30

The issue was bisected to:

commit 284562e1f34874e267d4f499362c3816f8f6bc3f
Author: Gurchetan Singh 
Date:   Tue Dec 3 01:36:27 2019 +

 udmabuf: implement begin_cpu_access/end_cpu_access hooks

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=12d6844730
final oops: https://syzkaller.appspot.com/x/report.txt?x=11d6844730
console output: https://syzkaller.appspot.com/x/log.txt?x=16d6844730



zero ubuf->pagecount will cause kmalloc_array() to return ZERO_PTR, that 
is unsafe to deref


#syz test
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master



With regards,
Pavel Skripkindiff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index c57a609db75b..e7330684d3b8 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -190,6 +190,10 @@ static long udmabuf_create(struct miscdevice *device,
if (ubuf->pagecount > pglimit)
goto err;
}
+
+   if (!ubuf->pagecount)
+   goto err;
+
ubuf->pages = kmalloc_array(ubuf->pagecount, sizeof(*ubuf->pages),
GFP_KERNEL);
if (!ubuf->pages) {

Re: [pull] amdgpu drm-fixes-5.16

2021-12-30 Thread Alex Deucher

On Thu, Dec 30, 2021 at 12:29 AM Dave Airlie  wrote:
>
> On Thu, 30 Dec 2021 at 01:51, Alex Deucher  wrote:
> >
> > Hi Dave, Daniel,
>
> Just FYI on merging this into tip I got a conflict I'm not sure what
> answer is right.
>
> fixes has:
> ee2698cf79cc759a397c61086c758d4cc85938bf
> Author: Angus Wang 
> Date:   Thu Dec 9 17:27:01 2021 -0500
>
> drm/amd/display: Changed pipe split policy to allow for
> multi-display pipe split
>
> next has:
> 1edf5ae1fdaffb67c1b93e98df670cbe535d13cf
> Author: Zhan Liu 
> Date:   Mon Nov 8 19:31:00 2021 -0500
>
> drm/amd/display: enable seamless boot for DCN301
>
> -.pipe_split_policy = MPC_SPLIT_AVOID_MULT_DISP,
> fixes is +.pipe_split_policy = MPC_SPLIT_DYNAMIC,
> next is +.pipe_split_policy = MPC_SPLIT_AVOID,
>
> I've chosen the -fixes answer for now, but it would be good to have
> someone review it before Linus merges.

It should ultimately be MPC_SPLIT_DYNAMIC.  -next has an extra patch
which changes it to an intermediate value before this patch changes it
to MPC_SPLIT_DYNAMIC.

Alex


>
> Dave.

Re: [v1 1/2] dt-bindings: msm/dsi: Add 10nm dsi phy tuning properties

On Thu, 30 Dec 2021 at 12:25, Rajeev Nandan  wrote:
>
> Add 10nm dsi phy tuning properties for phy drive strength and
> phy drive level adjustemnt.
>
> Signed-off-by: Rajeev Nandan 
> ---
>  .../devicetree/bindings/display/msm/dsi-phy-10nm.yaml | 19 
> +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml 
> b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
> index 4399715..9406982 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
> @@ -35,6 +35,18 @@ properties:
>Connected to DSI0_MIPI_DSI_PLL_VDDA0P9 pin for sc7180 target and
>connected to VDDA_MIPI_DSI_0_PLL_0P9 pin for sdm845 target
>
> +  phy-drive-strength-cfg:
> +type: array
> +description:
> +  Register values of DSIPHY_RESCODE_OFFSET_TOP and 
> DSIPHY_RESCODE_OFFSET_BOT
> +  for all five lanes to adjust the phy drive strength.
> +
> +  phy-drive-level-cfg:
> +type: array
> +description:
> +  Register values of DSIPHY_RESCODE_OFFSET_TOP for all five lanes to 
> adjust
> +  phy drive level/amplitude.


Description is incorrect, it's not the RESCODE_OFFSET_TOP register.

> +
>  required:
>- compatible
>- reg
> @@ -64,5 +76,12 @@ examples:
>   clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
><&rpmhcc RPMH_CXO_CLK>;
>   clock-names = "iface", "ref";
> +
> + phy-drive-strength-cfg = [00 00
> +   00 00
> +   00 00
> +   00 00
> +   00 00];
> + phy-drive-level-cfg = [59 59 59 59 59];

You are writing this value into the PHY_CMN_VREG_CTRL register. So
specifying 5 values here does not make sense.

>   };
>  ...
> --
> 2.7.4
>


-- 
With best wishes
Dmitry

[pull] amdgpu, amdkfd drm-next-5.17

2021-12-30 Thread Alex Deucher

Hi Dave, Daniel,

Fixes for 5.17.  Now with more S-o-b.

The following changes since commit a342655865b2f14d1fbf346356d3b3360e63e872:

  drm/radeon: Fix syntax errors in comments (2021-12-14 16:11:02 -0500)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-next-5.17-2021-12-30

for you to fetch changes up to 0637d41786a3a9551f33ad8e15bdb40416362028:

  drm/amdgpu: no DC support for headless chips (2021-12-30 08:54:45 -0500)


amd-drm-next-5.17-2021-12-30:

amdgpu:
- Suspend/resume fixes
- Fence fix
- Misc code cleanups
- IP discovery fixes
- SRIOV fixes
- RAS fixes
- GMC 8 VRAM detection fix
- FRU fixes for Aldebaran
- Display fixes

amdkfd:
- SVM fixes
- IP discovery fixes


Alex Deucher (5):
  drm/amdgpu: clean up some leftovers from bring up
  drm/amdgpu: add support for IP discovery gc_info table v2
  drm/amdgpu: fix runpm documentation
  drm/amdgpu: always reset the asic in suspend (v2)
  drm/amdgpu: no DC support for headless chips

Alvin Lee (1):
  drm/amd/display: Fix check for null function ptr

Angus Wang (1):
  drm/amd/display: Changed pipe split policy to allow for multi-display 
pipe split

Anthony Koo (1):
  drm/amd/display: [FW Promotion] Release 0.0.98

Aric Cyr (1):
  drm/amd/display: 3.2.167

Bokun Zhang (1):
  drm/amdgpu: Filter security violation registers

Changcheng Deng (1):
  drm/amdkfd: use max() and min() to make code cleaner

Charlene Liu (1):
  drm/amd/display: fix B0 TMDS deepcolor no dislay issue

Evan Quan (1):
  drm/amdgpu: put SMU into proper state on runpm suspending for BOCO 
capable platform

George Shen (2):
  drm/amd/display: Limit max link cap with LTTPR caps
  drm/amd/display: Remove CR AUX RD Interval limit for LTTPR

Guchun Chen (2):
  drm/amdkfd: correct sdma queue number in kfd device init (v3)
  drm/amdgpu: drop redundant semicolon

Huang Rui (1):
  drm/amdgpu: introduce new amdgpu_fence object to indicate the job 
embedded fence

Jiapeng Chong (1):
  drm/amd/display: Fix warning comparing pointer to 0

José Expósito (1):
  drm/amd/display: fix dereference before NULL check

Kent Russell (4):
  drm/amdgpu: Increase potential product_name to 64 characters
  drm/amdgpu: Enable unique_id for Aldebaran
  drm/amdgpu: Only overwrite serial if field is empty
  drm/amdgpu: Access the FRU on Aldebaran

Lai, Derek (1):
  drm/amd/display: Added power down for DCN10

Leslie Shi (1):
  drm/amdgpu: Call amdgpu_device_unmap_mmio() if device is unplugged to 
prevent crash in GPU initialization failure

Lijo Lazar (1):
  drm/amd/pm: Fix xgmi link control on aldebaran

Marina Nikolic (1):
  amdgpu/pm: Make sysfs pm attributes as read-only for VFs

Mario Limonciello (2):
  drivers/amd/pm: smu13: use local variable adev
  drm/amd/pm: restore SMU version print statement for dGPUs

Martin Leung (1):
  drm/amd/display: Undo ODM combine

Nicholas Kazlauskas (4):
  drm/amd/display: Fix USB4 null pointer dereference in 
update_psp_stream_config
  drm/amd/display: Block z-states when stutter period exceeds criteria
  drm/amd/display: Send s0i2_rdy in stream_count == 0 optimization
  drm/amd/display: Set optimize_pwr_state for DCN31

Philip Yang (1):
  drm/amdkfd: fix svm_bo release invalid wait context warning

Prike Liang (1):
  drm/amd/pm: skip setting gfx cgpg in the s0ix suspend-resume

Rajneesh Bhardwaj (1):
  drm/amdgpu: Don't inherit GEM object VMAs in child process

Shen, George (1):
  drm/amd/display: Refactor vendor specific link training sequence

Surbhi Kakarya (1):
  drm/amdgpu: Check the memory can be accesssed by 
ttm_device_clear_dma_mappings.

Tao Zhou (5):
  drm/amdgpu: add gpu reset control for umc page retirement
  drm/amdkfd: add reset parameter for unmap queues
  drm/amdkfd: add reset queue function for RAS poison (v2)
  drm/amdkfd: reset queue which consumes RAS poison (v2)
  drm/amdgpu: save error count in RAS poison handler

Victor Skvortsov (6):
  drm/amdgpu: Separate vf2pf work item init from virt data exchange
  drm/amdgpu: Add *_SOC15_IP_NO_KIQ() macro definitions
  drm/amdgpu: Modify indirect register access for gmc_v9_0 sriov
  drm/amdgpu: Modify indirect register access for amdkfd_gfx_v9 sriov
  drm/amdgpu: get xgmi info before ip_init
  drm/amdgpu: Modify indirect register access for gfx9 sriov

Wenjing Liu (5):
  drm/amd/display: define link res and make it accessible to all link 
interfaces
  drm/amd/display: populate link res in both detection and validation
  drm/amd/display: access hpo dp link encoder only through link resource
  drm/amd/display: support dynamic HPO DP link encoder allocation
  drm/amd/display: get and restore link res map

Wesley Chal

Re: [v1 1/2] dt-bindings: msm/dsi: Add 10nm dsi phy tuning properties

On Thu, 30 Dec 2021 at 12:25, Rajeev Nandan  wrote:
>
> Add 10nm dsi phy tuning properties for phy drive strength and
> phy drive level adjustemnt.
>
> Signed-off-by: Rajeev Nandan 
> ---
>  .../devicetree/bindings/display/msm/dsi-phy-10nm.yaml | 19 
> +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml 
> b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
> index 4399715..9406982 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
> @@ -35,6 +35,18 @@ properties:
>Connected to DSI0_MIPI_DSI_PLL_VDDA0P9 pin for sc7180 target and
>connected to VDDA_MIPI_DSI_0_PLL_0P9 pin for sdm845 target
>
> +  phy-drive-strength-cfg:
> +type: array
> +description:
> +  Register values of DSIPHY_RESCODE_OFFSET_TOP and 
> DSIPHY_RESCODE_OFFSET_BOT
> +  for all five lanes to adjust the phy drive strength.
> +
> +  phy-drive-level-cfg:
> +type: array
> +description:
> +  Register values of DSIPHY_RESCODE_OFFSET_TOP for all five lanes to 
> adjust
> +  phy drive level/amplitude.
> +
>  required:
>- compatible
>- reg
> @@ -64,5 +76,12 @@ examples:
>   clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
><&rpmhcc RPMH_CXO_CLK>;
>   clock-names = "iface", "ref";
> +
> + phy-drive-strength-cfg = [00 00
> +   00 00
> +   00 00
> +   00 00
> +   00 00];
> + phy-drive-level-cfg = [59 59 59 59 59];

And second notice. This interface seems to be too register-centric.
You provide register values without any actual way to interpret them.
I'd prefer to have something closer to pinctrl. Specify strength and
level in some logical way and then in the driver interpret that into
register values.

-- 
With best wishes
Dmitry

[PATCH] udmabuf: validate ubuf->pagecount

2021-12-30 Thread Pavel Skripkin

Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The
problem was in ubuf->pages == ZERO_PTR.

ubuf->pagecount is calculated from arguments passed from user-space. If
user creates udmabuf with list.size == 0 then ubuf->pagecount will be
also equal to zero; it causes kmalloc_array() to return ZERO_PTR.

Fix it by validating ubuf->pagecount before passing it to
kmalloc_array().

Fixes: fbb0de795078 ("Add udmabuf misc device")
Reported-and-tested-by: syzbot+2c56b725ec547fa9c...@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin 
---

Happy New Year and Merry Christmas! :)


With regards,
Pavel Skripkin

---
 drivers/dma-buf/udmabuf.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index c57a609db75b..e7330684d3b8 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -190,6 +190,10 @@ static long udmabuf_create(struct miscdevice *device,
if (ubuf->pagecount > pglimit)
goto err;
}
+
+   if (!ubuf->pagecount)
+   goto err;
+
ubuf->pages = kmalloc_array(ubuf->pagecount, sizeof(*ubuf->pages),
GFP_KERNEL);
if (!ubuf->pages) {
-- 
2.34.1

[Bug 215436] admgpu: suspend and resuming from suspend don't work

https://bugzilla.kernel.org/show_bug.cgi?id=215436

--- Comment #5 from spassw...@web.de ---
There might also be different suspend errors we're dealing with:
linux-5.16-rc7 e.g. seems to hang when going into suspend with the last log
message before reboot being:
Dec 30 14:53:19 lisa kernel: [   85.056243] PM: suspend entry (s2idle)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [v1 2/2] drm/msm/dsi: Add 10nm dsi phy tuning configuration support

On Thu, 30 Dec 2021 at 12:25, Rajeev Nandan  wrote:
>
> In most cases the default values of DSI PHY tuning registers
> should be sufficient as they are fully optimized. However, in
> some cases (for example, where extreme board parasitics cause
> the eye shape to degrade), the override bits can be used to
> improve the signal quality.
>
> As per the MSM DSI PHY (10nm) tuning guideline, the drive strength
> can be adjusted using DSIPHY_RESCODE_OFFSET_TOP & DSIPHY_RESCODE_OFFSET_BOT
> registers, and the drive level can be adjusted using DSIPHY_CMN_VREG_CTRL
> register.
>
> Add DSI PHY tuning support for 10nm PHY. This can be extended to other
> DSI PHY versions if needed.

Could you please split this patch into generic code and 10nm-specific part?

>
> Signed-off-by: Rajeev Nandan 
> ---
>  drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  | 55 
> ++
>  drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  | 23 +
>  drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 31 +
>  3 files changed, 103 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
> b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> index 8c65ef6..bf630b7 100644
> --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> @@ -669,10 +669,42 @@ static int dsi_phy_get_id(struct msm_dsi_phy *phy)
> return -EINVAL;
>  }
>
> +static int dsi_phy_parse_dt_per_lane_cfgs(struct platform_device *pdev,
> + struct dsi_phy_per_lane_cfgs *cfg,
> + char *property)
> +{
> +   int i = 0, j = 0;
> +   const u8 *data;
> +   u32 len = 0;
> +
> +   data = of_get_property(pdev->dev.of_node, property, &len);
> +   if (!data) {
> +   DRM_DEV_ERROR(&pdev->dev, "couldn't find %s property\n", 
> property);
> +   return -EINVAL;
> +   }
> +
> +   if (len != DSI_LANE_MAX * cfg->count_per_lane) {
> +   DRM_DEV_ERROR(&pdev->dev, "incorrect phy %s settings, exp=%d, 
> act=%d\n",
> +  property, (DSI_LANE_MAX * cfg->count_per_lane), len);
> +   return -EINVAL;
> +   }
> +
> +   for (i = 0; i < DSI_LANE_MAX; i++) {
> +   for (j = 0; j < cfg->count_per_lane; j++) {
> +   cfg->val[i][j] = *data;
> +   data++;
> +   }
> +   }
> +
> +   return 0;
> +}
> +
>  static int dsi_phy_driver_probe(struct platform_device *pdev)
>  {
> struct msm_dsi_phy *phy;
> struct device *dev = &pdev->dev;
> +   struct dsi_phy_per_lane_cfgs *strength;
> +   struct dsi_phy_per_lane_cfgs *level;
> u32 phy_type;
> int ret;
>
> @@ -707,6 +739,29 @@ static int dsi_phy_driver_probe(struct platform_device 
> *pdev)
> if (!of_property_read_u32(dev->of_node, "phy-type", &phy_type))
> phy->cphy_mode = (phy_type == PHY_TYPE_CPHY);
>
> +   /* dsi phy tuning configurations */
> +   if (phy->cfg->drive_strength_cfg_count) {
> +   strength = &phy->tuning_cfg.drive_strength;
> +   strength->count_per_lane = phy->cfg->drive_strength_cfg_count;
> +   ret = dsi_phy_parse_dt_per_lane_cfgs(pdev, strength,
> +   "phy-drive-strength-cfg");
> +   if (ret) {
> +   DRM_DEV_ERROR(dev, "failed to parse PHY drive 
> strength cfg, %d\n", ret);
> +   goto fail;
> +   }
> +   }
> +
> +   if (phy->cfg->drive_level_cfg_count) {
> +   level = &phy->tuning_cfg.drive_level;
> +   level->count_per_lane = phy->cfg->drive_level_cfg_count;
> +   ret = dsi_phy_parse_dt_per_lane_cfgs(pdev, level,
> +   "phy-drive-level-cfg");
> +   if (ret) {
> +   DRM_DEV_ERROR(dev, "failed to parse PHY drive level 
> cfg, %d\n", ret);
> +   goto fail;
> +   }
> +   }

After reading the code (and the way you use those values later), I'd
suggest adding the parse_dt hook instead of parsing it from the
generic code and putting the values into phy-specific data instead.
This way in the parse_dt you can read, validate and prepare register
values that are going to be written into the hardware. Then in the
phy_enable you can write those values directly, without any ifs.

> +
> phy->base = msm_ioremap_size(pdev, "dsi_phy", "DSI_PHY", 
> &phy->base_size);
> if (IS_ERR(phy->base)) {
> DRM_DEV_ERROR(dev, "%s: failed to map phy base\n", __func__);
> diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h 
> b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
> index b91303a..9ff733a 100644
> --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
> +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
> @@ -39,6 +39,10 @@ struct msm_dsi_phy_cfg {
> const int q

Re: [PATCH] drm: get rid of DRM_DEBUG_* log calls in drm core, files drm_{b,c}*.c

2021-12-30 Thread kernel test robot

Hi Claudio,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip v5.16-rc7 
next-20211224]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Claudio-Suarez/drm-get-rid-of-DRM_DEBUG_-log-calls-in-drm-core-files-drm_-b-c-c/20211230-185446
base:   git://anongit.freedesktop.org/drm/drm drm-next
config: hexagon-randconfig-r041-20211230 
(https://download.01.org/0day-ci/archive/20211230/202112302236.ikd2et5w-...@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 
cd284b7ac0615afc6e0f1a30da2777e361de27a3)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/9cfa12f89e858cd6d2eb5eb17c6db7ab689343e3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Claudio-Suarez/drm-get-rid-of-DRM_DEBUG_-log-calls-in-drm-core-files-drm_-b-c-c/20211230-185446
git checkout 9cfa12f89e858cd6d2eb5eb17c6db7ab689343e3
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/gpu/drm/

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

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/drm_bufs.c:174:14: error: incompatible pointer types passing 
'struct drm_device *' to parameter of type 'const struct device *' 
[-Werror,-Wincompatible-pointer-types]
   drm_dev_dbg(dev, "offset = 0x%08llx, size = 0x%08lx, type = %d\n",
   ^~~
   include/drm/drm_print.h:337:39: note: passing argument to parameter 'dev' 
here
   void drm_dev_dbg(const struct device *dev, enum drm_debug_category category,
 ^
>> drivers/gpu/drm/drm_bufs.c:174:19: warning: incompatible pointer to integer 
>> conversion passing 'char[46]' to parameter of type 'enum drm_debug_category' 
>> [-Wint-conversion]
   drm_dev_dbg(dev, "offset = 0x%08llx, size = 0x%08lx, type = %d\n",
^~~~
   include/drm/drm_print.h:337:68: note: passing argument to parameter 
'category' here
   void drm_dev_dbg(const struct device *dev, enum drm_debug_category category,
  ^
>> drivers/gpu/drm/drm_bufs.c:175:7: warning: incompatible integer to pointer 
>> conversion passing 'unsigned long long' to parameter of type 'const char *' 
>> [-Wint-conversion]
   (unsigned long long)map->offset, map->size, map->type);
   ^~~
   include/drm/drm_print.h:338:16: note: passing argument to parameter 'format' 
here
const char *format, ...);
^
   drivers/gpu/drm/drm_bufs.c:208:17: error: incompatible pointer types passing 
'struct drm_device *' to parameter of type 'const struct device *' 
[-Werror,-Wincompatible-pointer-types]
   drm_dev_dbg(dev,
   ^~~
   include/drm/drm_print.h:337:39: note: passing argument to parameter 'dev' 
here
   void drm_dev_dbg(const struct device *dev, enum drm_debug_category category,
 ^
   drivers/gpu/drm/drm_bufs.c:209:10: warning: incompatible pointer to integer 
conversion passing 'char[62]' to parameter of type 'enum drm_debug_category' 
[-Wint-conversion]
   "Matching maps of type %d with 
mismatched sizes, (%ld vs %ld)\n",
   
^~~~
   include/drm/drm_print.h:337:68: note: passing argument to parameter 
'category' here
   void drm_dev_dbg(const struct device *dev, enum drm_debug_category category,
  ^
>> drivers/gpu/drm/drm_bufs.c:210:10: warning: incompatible integer to pointer 
>> conversion passing 'enum drm_map_type' to parameter of type 'const char *' 
>> [-Wint-conversion]
   map->type, map->size, 
list->map->size);

Re: [PATCH] phy: mediatek: Fix missing check in mtk_mipi_tx_probe

2021-12-30 Thread Chun-Kuang Hu

Hi, Miaoqian:

Miaoqian Lin  於 2021年12月24日 週五 下午4:21寫道：
>
> The of_device_get_match_data() function may return NULL.
> Add check to prevent potential null dereference.
>
> Signed-off-by: Miaoqian Lin 
> ---
>  drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c 
> b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
> index 28ad9403c441..67b005d5b9e3 100644
> --- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
> +++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
> @@ -146,6 +146,8 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> mipi_tx->driver_data = of_device_get_match_data(dev);
> +   if (!mipi_tx->driver_data)

I'm confused. mtk_mipi_tx_probe() is called because this device node's
compatible match one in mtk_mipi_tx_match[]. So I think the return
value of of_device_get_match_data(dev) would not be NULL. If this is
true, this checking is redundant.

Regards,
Chun-Kuang.

> +   return -ENODEV;
>
> mipi_tx->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(mipi_tx->regs))
> --
> 2.17.1
>

Re: [PATCH] gpu/drm/radeon:Fix null pointer risk

2021-12-30 Thread Christian König


Am 28.12.21 um 08:31 schrieb Wen Zhiwei:

If the null pointer is not judged in advance,
there is a risk that the pointer will cross
the boundary


As far as I can see that case is impossible, why do you want to add a 
check for it?


Regards,
Christian.



Signed-off-by: Wen Zhiwei 
---
  drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index bb53016f3138..d3d342041adf 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -951,7 +951,7 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
  
  		if (mem->mem_type == TTM_PL_TT) {

bo_va->flags |= RADEON_VM_PAGE_SYSTEM;
-   if (!(bo_va->bo->flags & (RADEON_GEM_GTT_WC | 
RADEON_GEM_GTT_UC)))
+   if (bo_va->bo && !(bo_va->bo->flags & 
(RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC)))
bo_va->flags |= RADEON_VM_PAGE_SNOOPED;
  
  		} else {

Re: [PATCH 2/3] arm64: dts: renesas: r8a77961: Add lvds0 device node

2021-12-30 Thread Laurent Pinchart

Hi Nikita,

On Thu, Dec 30, 2021 at 08:30:43AM +0300, Nikita Yushchenko wrote:
> >> I'd prefer to make each DT fragment to use only either entities defined in 
> >> that fragment itself, or
> >> defined "interface entities" between this and "neighbor" DT fragment.
> >>
> >> Such as:
> >> - SoC's DT fragment defines a named port/endpoint to export video stream at
> >> - board's DT fragment defines a named panel node corresponding to panel 
> >> plugged into board's physical
> >> connector, and connects endpoints with SoC's video export,
> >> - panel's DT fragment extends the panel node from board with video mode 
> >> information for this particular
> >> panel.
> >> ...
>  >
> > I agree it's annoying, but we'll have a similar problem, just the other
> > way around, with an endpoint defined in the SoC dtsi. Many R-Car SoCs
> > have two LVDS encoders, and you can attach a panel to either of them.
> > Some boards use LVDS0, some boards use LVDS1, and some boards could even
> > use both.
> 
> The case of "some boards use LVDS0, some boards use LVDS1" is directly 
> addressed by what I'm trying to 
> suggest. The per-board DT fragment can completely hide board's connection 
> details, without a need for 
> any new concept.

We could do this by adding a label to the port instead of the endpoint
in the SoC .dtsi.

lvds0: lvds@ {
...

ports {
port@0 {
lvds0_in: endpoint {
remote-endpoint = <&du_out_lvds0>;
};
};

lvds_out_panel_port: port@1 {
};
};

It would however likely be better do add the label to port@1 in the
board .dts though, as usage of a particular LVDS output is a board
property, not an SoC property.

Then, in the overlay,

panel {
port {
panel_in: endpoint {
remote_endpoint <&lvds_out_panel>;
};
};
};

&lvds_out_panel_port {
lvds_out_panel: endpoint {
remote-endpoint = <&panel_in>;
};
};

There's one caveat though: The LVDS DT nodes are disabled in the SoC
.dtsi, so the overlay would need to have

&lvds0 {
status = "okay";
};

and that would need to reference the correct lvds node. Without
parameterized overlays, I don't think we can solve this issue neatly
(especially given that panels will often have control GPIOs, or
GPIO-controlled regulators, that could be wired to different SoC GPIOs
on different boards).

> The case of "some boards could even use both" indeed needs a some way to 
> parametrize panel's DT 
> fragment, and perhaps load two instances of it with different parameters. To 
> some extent this is doable 
> via preprocessor magic and multiple includes, although this approach has 
> obvious disadvantages.
> 
> > A real solution for this problem will require a new concept. The "DT
> > connector" proposal is related to this problem space. There's also a
> > proprietary implementation in the Rapsberry Pi boot loader of a
> > mechanism to support parametrized overlays ([2] and [3], or [4] for an
> > example of how a panel reset or backlight GPIO can be parametrized).
> 
> So the problem is already recognized for years...  what stops from
> wider adoption of this or similar solutions?

Someone to continue working on it I suppose :-)

> And - if/while that is not being done - can't we at least try to
> follow more portable DT coding pattern while staying within existing
> concepts?

We could use a label for the port node as shown above. It's not a
complete solution, but it may help. I'm not sure how to solve the
enabling of the lvds encoder DT node though.

-- 
Regards,

Laurent Pinchart

Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI

On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
>
---8<---
>   
> > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > tied to PCI specifically at all, right?
> > > > 
> > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > all?
> > > > 
> > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > just describe it as it is, "DIRECT_IO"?  
> > > 
> > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > name for it.
> > > 
> > > Thanks,
> > > Mauro  
> > 
> > Hmm, I might be missing something here but that sounds a lot like the
> > HAS_IOPORT option added in patch 02.
> > 
> > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > while LEGACY_PCI is for PCI drivers that require port I/O. 
> 
> I didn't look at the other patches on this series, but why it is needed
> to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough? 
> 
> I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> where LEGACY_PCI shall be "n"?

In the current patch set LEGACY_PCI is not currently selected by
architectures, though of course it could be if we know that an
architecture requires it. We should probably also set it in any
defconfig that has devices depending on it so as not to break these.

Other than that it would be set during kernel configuration if one
wants/needs support for legacy PCI devices. For testing I ran with
HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
based workstation and Raspberry Pi 4 (DT). I guess at the moment it
would make most sense for special configs such as those tailored for
vitualization guets but in the end that would be something for
distributions to decide.

Arnd described the options here:
https://lore.kernel.org/lkml/cak8p3a3hhep+gw_k2p7qtig0omerf0hn30g22+qhic_uzth...@mail.gmail.com/

> 
> > This
> > includes pre-PCIe devices as well as PCIe devices which require
> > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > compatibility with legacy devices which require their use. Future
> > revisions of this specification may deprecate the use of I/O Space."
> 
> I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> 
> I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> features that were/will be deprecated on PCI specs as time goes by.
> 
> So, I would, instead, use something like PCI_LEGACY_IO_SPACE or 
> HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> means.

Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
LEGACY_PCI is pretty clear since most devices are either pre-PCIe
devices or a compatibility feature allowing drivers for a pre-PCIe
device to work with a PCIe device.

> 
> > These two separate config options allow us to compile without support
> > for these legacy PCI devices even on a system where inb()/outb() and
> > friends are required for some PC style devices and for example ACPI.
> 
> Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI?
> 
> > @@ -172,6 +177,7 @@ config SND_AZT3328
> >  
> >  config SND_BT87X
> > tristate "Bt87x Audio Capture"
> > +   depends on LEGACY_PCI
> > select SND_PCM
> > help
> >   If you want to record audio from TV cards based on
> 
> I couldn't find any usage of inb/outb & friends on it:
> 
>   $ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c
> 
> It uses, instead, readl/writel:
> 
>   static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg)
>   {
>   return readl(chip->mmio + reg);
>   }
> 
>   static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, 
> u32 value)
>   {
>   writel(value, chip->mmio + reg);
>   }
> 
> I failed to see what makes it different from VIDEO_BT848 and
> DVB_BT8XX drivers. They all support exactly the same chipset:
> Brooktree/Conexant BT8xx. On those devices, depending on the exact
> model, up to three separate interfaces are provided, each one with
> its own Kconfig var:
> 
>   - audio I/O (SND_BT87X);
>   - video I/O (VIDEO_BT848);
>   - MPEG-TS I/O (DVB_BT8XX).
> 
> Thanks,
> Mauro

You're right, that makes no sense this doesn't seem to require
LEGACY_PCI. Maybe this was added by Arnd because it lacks a "depends on
PCI" which could have caused issues with HAVE_PCI=n rand configs.

[RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI

Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
PCI devices including those attached to a PCI-to-PCI Express bridge and
PCI Express devices using legacy I/O spaces. Note that this is different
from non PCI uses of I/O ports such as by ACPI.

Add dependencies on LEGACY_PCI for all PCI drivers which only target
legacy PCI devices and ifdef legacy PCI specific functions in ata
handling.

Co-developed-by: Arnd Bergmann 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Niklas Schnelle 
---
 drivers/ata/Kconfig  | 34 
 drivers/ata/ata_generic.c|  3 +-
 drivers/ata/libata-sff.c |  2 +
 drivers/comedi/Kconfig   | 42 +++
 drivers/gpio/Kconfig |  2 +-
 drivers/hwmon/Kconfig|  6 +--
 drivers/i2c/busses/Kconfig   | 24 +--
 drivers/input/gameport/Kconfig   |  4 +-
 drivers/isdn/hardware/mISDN/Kconfig  | 14 +++
 drivers/media/cec/platform/Kconfig   |  2 +-
 drivers/media/pci/dm1105/Kconfig |  2 +-
 drivers/media/radio/Kconfig  |  2 +-
 drivers/message/fusion/Kconfig   |  8 ++--
 drivers/net/arcnet/Kconfig   |  2 +-
 drivers/net/ethernet/8390/Kconfig|  2 +-
 drivers/net/ethernet/amd/Kconfig |  2 +-
 drivers/net/ethernet/intel/Kconfig   |  4 +-
 drivers/net/ethernet/sis/Kconfig |  6 +--
 drivers/net/ethernet/ti/Kconfig  |  4 +-
 drivers/net/ethernet/via/Kconfig |  4 +-
 drivers/net/fddi/Kconfig |  4 +-
 drivers/net/wan/Kconfig  |  2 +-
 drivers/net/wireless/atmel/Kconfig   |  4 +-
 drivers/net/wireless/intersil/hostap/Kconfig |  4 +-
 drivers/pci/Kconfig  | 11 +
 drivers/scsi/Kconfig | 20 -
 drivers/scsi/aic7xxx/Kconfig.aic79xx |  2 +-
 drivers/scsi/aic7xxx/Kconfig.aic7xxx |  2 +-
 drivers/scsi/aic94xx/Kconfig |  2 +-
 drivers/scsi/megaraid/Kconfig.megaraid   |  2 +-
 drivers/scsi/mvsas/Kconfig   |  2 +-
 drivers/scsi/qla2xxx/Kconfig |  2 +-
 drivers/spi/Kconfig  |  1 +
 drivers/staging/sm750fb/Kconfig  |  2 +-
 drivers/staging/vt6655/Kconfig   |  2 +-
 drivers/tty/Kconfig  |  2 +-
 drivers/tty/serial/Kconfig   |  2 +-
 drivers/video/fbdev/Kconfig  | 22 +-
 drivers/watchdog/Kconfig |  4 +-
 sound/pci/Kconfig| 43 
 40 files changed, 194 insertions(+), 110 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a7da8ea7b3ed..32e0489bd01c 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -556,7 +556,7 @@ comment "PATA SFF controllers with BMDMA"
 
 config PATA_ALI
tristate "ALi PATA support"
-   depends on PCI
+   depends on LEGACY_PCI
select PATA_TIMINGS
help
  This option enables support for the ALi ATA interfaces
@@ -566,7 +566,7 @@ config PATA_ALI
 
 config PATA_AMD
tristate "AMD/NVidia PATA support"
-   depends on PCI
+   depends on LEGACY_PCI
select PATA_TIMINGS
help
  This option enables support for the AMD and NVidia PATA
@@ -584,7 +584,7 @@ config PATA_ARASAN_CF
 
 config PATA_ARTOP
tristate "ARTOP 6210/6260 PATA support"
-   depends on PCI
+   depends on LEGACY_PCI
help
  This option enables support for ARTOP PATA controllers.
 
@@ -621,7 +621,7 @@ config PATA_BK3710
 
 config PATA_CMD64X
tristate "CMD64x PATA support"
-   depends on PCI
+   depends on LEGACY_PCI
select PATA_TIMINGS
help
  This option enables support for the CMD64x series chips
@@ -667,7 +667,7 @@ config PATA_CS5536
 
 config PATA_CYPRESS
tristate "Cypress CY82C693 PATA support (Very Experimental)"
-   depends on PCI
+   depends on LEGACY_PCI
select PATA_TIMINGS
help
  This option enables support for the Cypress/Contaq CY82C693
@@ -707,7 +707,7 @@ config PATA_FTIDE010
 
 config PATA_HPT366
tristate "HPT 366/368 PATA support"
-   depends on PCI
+   depends on LEGACY_PCI
help
  This option enables support for the HPT 366 and 368
  PATA controllers via the new ATA layer.
@@ -716,7 +716,7 @@ config PATA_HPT366
 
 config PATA_HPT37X
tristate "HPT 370/370A/371/372/374/302 PATA support"
-   depends on PCI
+   depends on LEGACY_PCI
help
  This option enables support for the majority of the later HPT
  PATA controllers via the new ATA layer.
@@ -725,7 +725,7 @@ config PATA_HPT37X
 
 config PATA_HPT3X2N
tristate "HPT 371N/372N/302N PATA support"

Re: [syzbot] general protection fault in sg_alloc_append_table_from_pages

2021-12-30 Thread syzbot

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any 
issue:

Reported-and-tested-by: syzbot+2c56b725ec547fa9c...@syzkaller.appspotmail.com

Tested on:

commit: eec4df26 Merge tag 's390-5.16-6' of git://git.kernel.o..
git tree:   upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=1bce7595e2f1eaf8
dashboard link: https://syzkaller.appspot.com/bug?extid=2c56b725ec547fa9cb29
compiler:   gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for 
Debian) 2.35.2
patch:  https://syzkaller.appspot.com/x/patch.diff?x=14fe2f47b0

Note: testing is done by a robot and is best-effort only.

Renesas rcar-du and DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE

2021-12-30 Thread Charles Stevens

Hi All,     I am working on a platform based on the Renesas RZ/G2 SoC family. 
This chip uses the rcar-du driver for the display. I would like to submit a 
patch to address the fact that the driver does not check/honor the flag 
DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE. My issue is that I would like to make as 
small a change to the driver as possible, but the panel bus_flags don't seem to 
even make it to the crtc driver. The crtc driver seems to use adjusted_mode to 
set the HSYNC and VSYNC polarity and as I said ignores the pixel clock polarity 
leaving it at the default of driving on the falling edge. In my investigations 
so far I have not figured out how to chase the pointers from the CRTC to the 
bridge to the panel in order to be able to look at bus_flags. My current 
approach also modifies the encoder initialization to cache the needed panel and 
then find the attached encoder during CRTC initialization to find the bus 
flags. This seems like a lot of work and not something that would be accepted 
as a patch. The OMAP DSS seems to have problems accessing this flag as well. 
The TI driver goes so far as to document the current approach as a HACK and 
suggest a fairly large change to the driver to address the problem. Am I 
missing something? Is there an easy way to get from a drm_crtc to a drm_panel 
that is in the same pipeline? 
    Any pointers would be greatly appreciated!
Thanks!
-charles

Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI

On Tue, 2021-12-28 at 18:12 +0100, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Dec 2021 16:06:44 +0100
> Niklas Schnelle  escreveu:
> 
> (on a side note: the c/c list of this patch is too long. I would try to
> avoid using a too long list, as otherwise this e-mail may end being rejected
> by mail servers)
> 
> > On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> > >  
> > ---8<---
> > > 
> > > > > > All you really care about is the "legacy" I/O spaces here, this 
> > > > > > isn't
> > > > > > tied to PCI specifically at all, right?
> > > > > > 
> > > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > > that, to show that it's the i/o functions we care about here, not 
> > > > > > PCI at
> > > > > > all?
> > > > > > 
> > > > > > And maybe not call it "old" or "legacy" as time constantly goes 
> > > > > > forward,
> > > > > > just describe it as it is, "DIRECT_IO"?
> > > > > 
> > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more 
> > > > > appropriate
> > > > > name for it.
> > > > > 
> > > > > Thanks,
> > > > > Mauro
> > > > 
> > > > Hmm, I might be missing something here but that sounds a lot like the
> > > > HAS_IOPORT option added in patch 02.
> > > > 
> > > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > > while LEGACY_PCI is for PCI drivers that require port I/O.   
> > > 
> > > I didn't look at the other patches on this series, but why it is needed
> > > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be 
> > > enough? 
> > > 
> > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > > where LEGACY_PCI shall be "n"?  
> > 
> > In the current patch set LEGACY_PCI is not currently selected by
> > architectures, though of course it could be if we know that an
> > architecture requires it. We should probably also set it in any
> > defconfig that has devices depending on it so as not to break these.
> > 
> > Other than that it would be set during kernel configuration if one
> > wants/needs support for legacy PCI devices. For testing I ran with
> > HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> > based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> > would make most sense for special configs such as those tailored for
> > vitualization guets but in the end that would be something for
> > distributions to decide.
> 
> IMO, it makes sense to have a "default y" there, as on systems that
> support I/O space, disabling it will just randomly disable some drivers
> that could be required by some hardware. I won't doubt that some of 
> those could be ported from using inb/outb to use, instead, readb/writeb.

Makes sense, if these get more legacy over time we can always change
the default. This would also mean we don't need to change defconfigs
that include legacy PCI devices.

> 
> > Arnd described the options here:
> > https://lore.kernel.org/lkml/cak8p3a3hhep+gw_k2p7qtig0omerf0hn30g22+qhic_uzth...@mail.gmail.com/
> 
> Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
> This is missing on patch 1. You should probably reorder your patch
> series to first create HAS_IOPORT and then add LEGACY_PCI with
> depends on, as otherwise it may cause randconfig build issues
> at robots and/or git bisect.
> 
> I would also suggest to first introduce such change and then send
> a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
> maintainers to review.

Playing around with the reordering I think it might make sense to
introduce HAS_IOPORT in patch 01, then LEGACY_PCI in patch 02 and then
add dependencies for both on a per subsystem basis. I think it would be
overkill to have two series of per subsystem patches.

> 
> > >   
> > > > This
> > > > includes pre-PCIe devices as well as PCIe devices which require
> > > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > > compatibility with legacy devices which require their use. Future
> > > > revisions of this specification may deprecate the use of I/O Space."  
> > > 
> > > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> > > 
> > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > > features that were/will be deprecated on PCI specs as time goes by.
> > > 
> > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or 
> > > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > > means.  
> > 
> > Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> > LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> > devices or a compatibility feature allowing drivers for a pre-PCIe
> > device to work with a PCIe device.
> 
> That's the main point: it is *not* disabling pre-PCIe devices or
> even l

[PATCH] drm/mediatek: Fix unused-but-set variable warning

2021-12-30 Thread Miles Chen

Fix unused-but-set variable warning:
drivers/gpu/drm/mediatek/mtk_cec.c:85:6: warning: variable 'tmp' set but not 
used [-Wunused-but-set-variable]

Signed-off-by: Miles Chen 
---
 drivers/gpu/drm/mediatek/mtk_cec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c 
b/drivers/gpu/drm/mediatek/mtk_cec.c
index e9cef5c0c8f7..cdfa648910b2 100644
--- a/drivers/gpu/drm/mediatek/mtk_cec.c
+++ b/drivers/gpu/drm/mediatek/mtk_cec.c
@@ -85,7 +85,7 @@ static void mtk_cec_mask(struct mtk_cec *cec, unsigned int 
offset,
u32 tmp = readl(cec->regs + offset) & ~mask;
 
tmp |= val & mask;
-   writel(val, cec->regs + offset);
+   writel(tmp, cec->regs + offset);
 }
 
 void mtk_cec_set_hpd_event(struct device *dev,
-- 
2.18.0

[v1 1/2] dt-bindings: msm/dsi: Add 10nm dsi phy tuning properties

2021-12-30 Thread Rajeev Nandan

Add 10nm dsi phy tuning properties for phy drive strength and
phy drive level adjustemnt.

Signed-off-by: Rajeev Nandan 
---
 .../devicetree/bindings/display/msm/dsi-phy-10nm.yaml | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml 
b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
index 4399715..9406982 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
@@ -35,6 +35,18 @@ properties:
   Connected to DSI0_MIPI_DSI_PLL_VDDA0P9 pin for sc7180 target and
   connected to VDDA_MIPI_DSI_0_PLL_0P9 pin for sdm845 target
 
+  phy-drive-strength-cfg:
+type: array
+description:
+  Register values of DSIPHY_RESCODE_OFFSET_TOP and 
DSIPHY_RESCODE_OFFSET_BOT
+  for all five lanes to adjust the phy drive strength.
+
+  phy-drive-level-cfg:
+type: array
+description:
+  Register values of DSIPHY_RESCODE_OFFSET_TOP for all five lanes to adjust
+  phy drive level/amplitude.
+
 required:
   - compatible
   - reg
@@ -64,5 +76,12 @@ examples:
  clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
   <&rpmhcc RPMH_CXO_CLK>;
  clock-names = "iface", "ref";
+
+ phy-drive-strength-cfg = [00 00
+   00 00
+   00 00
+   00 00
+   00 00];
+ phy-drive-level-cfg = [59 59 59 59 59];
  };
 ...
-- 
2.7.4

[PATCH] gpu/drm/radeon:Fix null pointer risk

2021-12-30 Thread Wen Zhiwei

If the null pointer is not judged in advance,
there is a risk that the pointer will cross
the boundary

Signed-off-by: Wen Zhiwei 
---
 drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index bb53016f3138..d3d342041adf 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -951,7 +951,7 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
 
if (mem->mem_type == TTM_PL_TT) {
bo_va->flags |= RADEON_VM_PAGE_SYSTEM;
-   if (!(bo_va->bo->flags & (RADEON_GEM_GTT_WC | 
RADEON_GEM_GTT_UC)))
+   if (bo_va->bo && !(bo_va->bo->flags & 
(RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC)))
bo_va->flags |= RADEON_VM_PAGE_SNOOPED;
 
} else {
-- 
2.30.0

[RFC 26/32] drm: handle HAS_IOPORT dependencies

In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them. There is also a direct and hard coded use in
cirrus.c which according to the comment is only necessary during resume.
Let's just skip this as for example s390 which doesn't have I/O port
support also doesen't support suspend/resume.

Co-developed-by: Arnd Bergmann 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Niklas Schnelle 
---
 drivers/gpu/drm/qxl/Kconfig   | 1 +
 drivers/gpu/drm/tiny/Kconfig  | 1 +
 drivers/gpu/drm/tiny/cirrus.c | 2 ++
 3 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/qxl/Kconfig b/drivers/gpu/drm/qxl/Kconfig
index ca3f51c2a8fe..d0e0d440c8d9 100644
--- a/drivers/gpu/drm/qxl/Kconfig
+++ b/drivers/gpu/drm/qxl/Kconfig
@@ -2,6 +2,7 @@
 config DRM_QXL
tristate "QXL virtual GPU"
depends on DRM && PCI && MMU
+   depends on HAS_IOPORT
select DRM_KMS_HELPER
select DRM_TTM
select DRM_TTM_HELPER
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 1ceb93fbdc50..81749943af13 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -13,6 +13,7 @@ config DRM_ARCPGU
 config DRM_BOCHS
tristate "DRM Support for bochs dispi vga interface (qemu stdvga)"
depends on DRM && PCI && MMU
+   depends on HAS_IOPORT
select DRM_KMS_HELPER
select DRM_VRAM_HELPER
select DRM_TTM
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index 4611ec408506..c9b6e9779d18 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -306,8 +306,10 @@ static int cirrus_mode_set(struct cirrus_device *cirrus,
 
cirrus_set_start_address(cirrus, 0);
 
+#ifdef CONFIG_HAS_IOPORT
/* Unblank (needed on S3 resume, vgabios doesn't do it then) */
outb(0x20, 0x3c0);
+#endif
 
drm_dev_exit(idx);
return 0;
-- 
2.32.0

Re: [PATCH] drm/mediatek: Fix unused-but-set variable warning

2021-12-30 Thread miles.chen

>You are right, in both cases the bit is set, but the funciton does not do what 
>it is supposed to do.
>Will just clear all bits of the mask.
>
>Without your patch, we will just write the val to the register and don't care 
>what the register value was before that.
>
>We should somehow mention that in the commit message, as it's not only about a 
>not used variable, it actually has an influence on the value we write(-back) 
>to 
>the register.

thanks for the comment. I understand that it's not only about a not used
variable. I talked to our hdmi experts and they think mtk_cec_mask() should
write tmp instead of write val to the register.

I will mention this in the commit message and submit next patch.

Happy new year!

Miles

[PATCH v2] drm/mediatek: Fix unused-but-set variable warning

2021-12-30 Thread Miles Chen

Fix unused-but-set variable warning:
drivers/gpu/drm/mediatek/mtk_cec.c:85:6: warning: variable 'tmp' set but not 
used [-Wunused-but-set-variable]

Cc: CK Hu 
Cc: Matthias Brugger 
Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
Signed-off-by: Miles Chen 

---

Change since v1:
add Fixes tag

---
 drivers/gpu/drm/mediatek/mtk_cec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c 
b/drivers/gpu/drm/mediatek/mtk_cec.c
index e9cef5c0c8f7..cdfa648910b2 100644
--- a/drivers/gpu/drm/mediatek/mtk_cec.c
+++ b/drivers/gpu/drm/mediatek/mtk_cec.c
@@ -85,7 +85,7 @@ static void mtk_cec_mask(struct mtk_cec *cec, unsigned int 
offset,
u32 tmp = readl(cec->regs + offset) & ~mask;
 
tmp |= val & mask;
-   writel(val, cec->regs + offset);
+   writel(tmp, cec->regs + offset);
 }
 
 void mtk_cec_set_hpd_event(struct device *dev,
-- 
2.18.0

Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI

On Tue, 2021-12-28 at 10:15 +0100, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Dec 2021 09:21:23 +0100
> Greg Kroah-Hartman  escreveu:
> 
> > On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > > --- a/drivers/pci/Kconfig
> > > +++ b/drivers/pci/Kconfig
> > > @@ -23,6 +23,17 @@ menuconfig PCI
> > >  
> > >  if PCI
> > >  
> > > +config LEGACY_PCI
> > > + bool "Enable support for legacy PCI devices"
> > > + depends on HAVE_PCI
> > > + help
> > > +This option enables support for legacy PCI devices. This includes
> > > +PCI devices attached directly or via a bridge on a PCI Express bus.
> > > +It also includes compatibility features on PCI Express devices which
> > > +make use of legacy I/O spaces.  
> 
> This Kconfig doesn't seem what it is needed there, as this should be an 
> arch-dependent feature, and not something that the poor user should be
> aware if a given architecture supports it or not. Also, the above will keep
> causing warnings or errors with randconfigs.
> 
> Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on 
> HAVE_PCI:

Ah yes you're right.

> 
>   menuconfig PCI
>   bool "PCI support"
>   depends on HAVE_PCI
>   help
> This option enables support for the PCI local bus, including
> support for PCI-X and the foundations for PCI Express support.
> Say 'Y' here unless you know what you are doing.
> 
> So, instead, I would expect that a new HAVE_xxx option would be
> added at arch/*/Kconfig, like:
> 
>   config X86
>   ...
>   select HAVE_PCI_DIRECT_IO
> 
> It would also make sense to document it at Documentation/features/.

I'll look into that, thanks.

> 
> > All you really care about is the "legacy" I/O spaces here, this isn't
> > tied to PCI specifically at all, right?
> > 
> > So why not just have a OLD_STYLE_IO config option or something like
> > that, to show that it's the i/o functions we care about here, not PCI at
> > all?
> > 
> > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > just describe it as it is, "DIRECT_IO"?
> 
> Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> name for it.
> 
> Thanks,
> Mauro

Hmm, I might be missing something here but that sounds a lot like the
HAS_IOPORT option added in patch 02.

We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
while LEGACY_PCI is for PCI drivers that require port I/O. This
includes pre-PCIe devices as well as PCIe devices which require
features like I/O spaces. The "legacy" naming is comes from the PCIe
spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
compatibility with legacy devices which require their use. Future
revisions of this specification may deprecate the use of I/O Space."

These two separate config options allow us to compile without support
for these legacy PCI devices even on a system where inb()/outb() and
friends are required for some PC style devices and for example ACPI.

Re: [PATCH] drm/mediatek: Fix unused-but-set variable warning

2021-12-30 Thread miles.chen

Hi,

On 28/12/2021 10:25, Miles Chen wrote:
> Fix unused-but-set variable warning:
>> drivers/gpu/drm/mediatek/mtk_cec.c:85:6: warning: variable 'tmp' set but not 
>> used [-Wunused-but-set-variable]
>> 
>
>Actually we ignore the value passed to mtk_cec_mask. In case of
>mtk_cec_mask(cec, CEC_CKGEN, 0 | CEC_32K_PDN, PDN | CEC_32K_PDN);
>
>
>We are not setting CEC_32K_PDN. I wonder which side effect will it have to set 
>that bit.

I am confused about "not setting CEC_32K_PDN" part,
in case mtk_cec_mask(cec, CEC_CKGEN, 0 | CEC_32K_PDN, PDN | CEC_32K_PDN);
CEC_32K_PDN (BIT(19)) is set.

for exmaple:
CEC_32K_PDN is BIT(19)
PDN is BIT(16)
say tmp = 0x;

mask = PDN | CEC_32K_PDN;
val = 0 | CEC_32K_PDN;

tmp = fff6, mask = 9
val = 8, tmp = fffe

u32 tmp = readl(cec->regs + offset) & ~mask; // tmp = fff6
tmp |= val & mask; // tmp = fffe
writel(val, cec->regs + offset); // val = 8, tmp = fffe

in both val and tmp case, CEC_32K_PDN is set.

>Anyway, if it's the right thing to do, we should add:
>
>Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")

I will add the Fixes tag, thanks.

[v1 2/2] drm/msm/dsi: Add 10nm dsi phy tuning configuration support

2021-12-30 Thread Rajeev Nandan

In most cases the default values of DSI PHY tuning registers
should be sufficient as they are fully optimized. However, in
some cases (for example, where extreme board parasitics cause
the eye shape to degrade), the override bits can be used to
improve the signal quality.

As per the MSM DSI PHY (10nm) tuning guideline, the drive strength
can be adjusted using DSIPHY_RESCODE_OFFSET_TOP & DSIPHY_RESCODE_OFFSET_BOT
registers, and the drive level can be adjusted using DSIPHY_CMN_VREG_CTRL
register.

Add DSI PHY tuning support for 10nm PHY. This can be extended to other
DSI PHY versions if needed.

Signed-off-by: Rajeev Nandan 
---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  | 55 ++
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  | 23 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 31 +
 3 files changed, 103 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 8c65ef6..bf630b7 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -669,10 +669,42 @@ static int dsi_phy_get_id(struct msm_dsi_phy *phy)
return -EINVAL;
 }
 
+static int dsi_phy_parse_dt_per_lane_cfgs(struct platform_device *pdev,
+ struct dsi_phy_per_lane_cfgs *cfg,
+ char *property)
+{
+   int i = 0, j = 0;
+   const u8 *data;
+   u32 len = 0;
+
+   data = of_get_property(pdev->dev.of_node, property, &len);
+   if (!data) {
+   DRM_DEV_ERROR(&pdev->dev, "couldn't find %s property\n", 
property);
+   return -EINVAL;
+   }
+
+   if (len != DSI_LANE_MAX * cfg->count_per_lane) {
+   DRM_DEV_ERROR(&pdev->dev, "incorrect phy %s settings, exp=%d, 
act=%d\n",
+  property, (DSI_LANE_MAX * cfg->count_per_lane), len);
+   return -EINVAL;
+   }
+
+   for (i = 0; i < DSI_LANE_MAX; i++) {
+   for (j = 0; j < cfg->count_per_lane; j++) {
+   cfg->val[i][j] = *data;
+   data++;
+   }
+   }
+
+   return 0;
+}
+
 static int dsi_phy_driver_probe(struct platform_device *pdev)
 {
struct msm_dsi_phy *phy;
struct device *dev = &pdev->dev;
+   struct dsi_phy_per_lane_cfgs *strength;
+   struct dsi_phy_per_lane_cfgs *level;
u32 phy_type;
int ret;
 
@@ -707,6 +739,29 @@ static int dsi_phy_driver_probe(struct platform_device 
*pdev)
if (!of_property_read_u32(dev->of_node, "phy-type", &phy_type))
phy->cphy_mode = (phy_type == PHY_TYPE_CPHY);
 
+   /* dsi phy tuning configurations */
+   if (phy->cfg->drive_strength_cfg_count) {
+   strength = &phy->tuning_cfg.drive_strength;
+   strength->count_per_lane = phy->cfg->drive_strength_cfg_count;
+   ret = dsi_phy_parse_dt_per_lane_cfgs(pdev, strength,
+   "phy-drive-strength-cfg");
+   if (ret) {
+   DRM_DEV_ERROR(dev, "failed to parse PHY drive strength 
cfg, %d\n", ret);
+   goto fail;
+   }
+   }
+
+   if (phy->cfg->drive_level_cfg_count) {
+   level = &phy->tuning_cfg.drive_level;
+   level->count_per_lane = phy->cfg->drive_level_cfg_count;
+   ret = dsi_phy_parse_dt_per_lane_cfgs(pdev, level,
+   "phy-drive-level-cfg");
+   if (ret) {
+   DRM_DEV_ERROR(dev, "failed to parse PHY drive level 
cfg, %d\n", ret);
+   goto fail;
+   }
+   }
+
phy->base = msm_ioremap_size(pdev, "dsi_phy", "DSI_PHY", 
&phy->base_size);
if (IS_ERR(phy->base)) {
DRM_DEV_ERROR(dev, "%s: failed to map phy base\n", __func__);
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index b91303a..9ff733a 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -39,6 +39,10 @@ struct msm_dsi_phy_cfg {
const int quirks;
bool has_phy_regulator;
bool has_phy_lane;
+
+   /* phy tuning config counts per lane */
+   u32 drive_strength_cfg_count;
+   u32 drive_level_cfg_count;
 };
 
 extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs;
@@ -81,6 +85,24 @@ struct msm_dsi_dphy_timing {
 #define DSI_PIXEL_PLL_CLK  1
 #define NUM_PROVIDED_CLKS  2
 
+#define DSI_LANE_MAX   5
+#define DSI_MAX_SETTINGS   8
+
+/**
+ * struct dsi_phy_per_lane_cfgs - Holds register values for PHY parameters
+ * @val: Register values for all lanes
+ * @count_per_lane: Number of values per lane.
+ */
+struct dsi_phy_per_lane_cfgs {
+   u8 val[DSI_LANE_MAX][DSI_MAX_SETTINGS];
+   u32 count_per_la

[PATCH] dma-buf: heaps: Fix mutex lock area and generalize struct dma_heap_attachment

2021-12-30 Thread Weizhao Ouyang

Fix cma_heap_buffer mutex lock area to protect vmap_cnt and vaddr. And
move struct dma_heap_attachment to dma-heap.h so that vendor dma heaps
can use it, the same behaviour as struct dma_buf_attachment.

Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the cma_heap 
implementation")
Signed-off-by: Weizhao Ouyang 
---
 drivers/dma-buf/heaps/cma_heap.c| 25 ++---
 drivers/dma-buf/heaps/system_heap.c | 12 ++--
 include/linux/dma-heap.h| 15 +++
 3 files changed, 27 insertions(+), 25 deletions(-)

diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 0c05b79870f9..23dad5b6421e 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -40,13 +40,6 @@ struct cma_heap_buffer {
void *vaddr;
 };
 
-struct dma_heap_attachment {
-   struct device *dev;
-   struct sg_table table;
-   struct list_head list;
-   bool mapped;
-};
-
 static int cma_heap_attach(struct dma_buf *dmabuf,
   struct dma_buf_attachment *attachment)
 {
@@ -58,7 +51,7 @@ static int cma_heap_attach(struct dma_buf *dmabuf,
if (!a)
return -ENOMEM;
 
-   ret = sg_alloc_table_from_pages(&a->table, buffer->pages,
+   ret = sg_alloc_table_from_pages(a->table, buffer->pages,
buffer->pagecount, 0,
buffer->pagecount << PAGE_SHIFT,
GFP_KERNEL);
@@ -90,7 +83,7 @@ static void cma_heap_detach(struct dma_buf *dmabuf,
list_del(&a->list);
mutex_unlock(&buffer->lock);
 
-   sg_free_table(&a->table);
+   sg_free_table(a->table);
kfree(a);
 }
 
@@ -98,12 +91,12 @@ static struct sg_table *cma_heap_map_dma_buf(struct 
dma_buf_attachment *attachme
 enum dma_data_direction direction)
 {
struct dma_heap_attachment *a = attachment->priv;
-   struct sg_table *table = &a->table;
+   struct sg_table *table = a->table;
int ret;
 
ret = dma_map_sgtable(attachment->dev, table, direction, 0);
if (ret)
-   return ERR_PTR(-ENOMEM);
+   return ERR_PTR(ret);
a->mapped = true;
return table;
 }
@@ -124,14 +117,15 @@ static int cma_heap_dma_buf_begin_cpu_access(struct 
dma_buf *dmabuf,
struct cma_heap_buffer *buffer = dmabuf->priv;
struct dma_heap_attachment *a;
 
+   mutex_lock(&buffer->lock);
+
if (buffer->vmap_cnt)
invalidate_kernel_vmap_range(buffer->vaddr, buffer->len);
 
-   mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
if (!a->mapped)
continue;
-   dma_sync_sgtable_for_cpu(a->dev, &a->table, direction);
+   dma_sync_sgtable_for_cpu(a->dev, a->table, direction);
}
mutex_unlock(&buffer->lock);
 
@@ -144,14 +138,15 @@ static int cma_heap_dma_buf_end_cpu_access(struct dma_buf 
*dmabuf,
struct cma_heap_buffer *buffer = dmabuf->priv;
struct dma_heap_attachment *a;
 
+   mutex_lock(&buffer->lock);
+
if (buffer->vmap_cnt)
flush_kernel_vmap_range(buffer->vaddr, buffer->len);
 
-   mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
if (!a->mapped)
continue;
-   dma_sync_sgtable_for_device(a->dev, &a->table, direction);
+   dma_sync_sgtable_for_device(a->dev, a->table, direction);
}
mutex_unlock(&buffer->lock);
 
diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
index ab7fd896d2c4..aac8fc660ea6 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -33,13 +32,6 @@ struct system_heap_buffer {
void *vaddr;
 };
 
-struct dma_heap_attachment {
-   struct device *dev;
-   struct sg_table *table;
-   struct list_head list;
-   bool mapped;
-};
-
 #define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP)
 #define MID_ORDER_GFP (LOW_ORDER_GFP | __GFP_NOWARN)
 #define HIGH_ORDER_GFP  (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
@@ -68,7 +60,7 @@ static struct sg_table *dup_sg_table(struct sg_table *table)
ret = sg_alloc_table(new_table, table->orig_nents, GFP_KERNEL);
if (ret) {
kfree(new_table);
-   return ERR_PTR(-ENOMEM);
+   return ERR_PTR(ret);
}
 
new_sg = new_table->sgl;
@@ -94,7 +86,7 @@ static int system_heap_attach(struct dma_buf *dmabuf,
table = dup_sg_table(&buffer->sg_table);
if (IS_ERR(table)) {
kfree(a);
-   return -ENOMEM;
+   return PTR_ERR(table);
}

[PATCH] video: fbdev: s3c-fb: remove redundant initialization of pointer bufs

2021-12-30 Thread Colin Ian King

Pointer bufs is being initialized with a value that is never read, it
is being re-assigned with a different value later on. The assignment
is redundant and can be removed. Cleans up clang-scan warning:

drivers/video/fbdev/s3c-fb.c:492:16: warning: Value stored to 'buf'
during its initialization is never read [deadcode.DeadStores]
void __iomem *buf = regs;

Signed-off-by: Colin Ian King 
---
 drivers/video/fbdev/s3c-fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
index 3b134e1bbc38..68408c499627 100644
--- a/drivers/video/fbdev/s3c-fb.c
+++ b/drivers/video/fbdev/s3c-fb.c
@@ -489,7 +489,7 @@ static int s3c_fb_set_par(struct fb_info *info)
struct s3c_fb_win *win = info->par;
struct s3c_fb *sfb = win->parent;
void __iomem *regs = sfb->regs;
-   void __iomem *buf = regs;
+   void __iomem *buf;
int win_no = win->index;
u32 alpha = 0;
u32 data;
-- 
2.33.1

Re: Regression report on laptop suspend

2021-12-30 Thread Christian Casteyde

Le lundi 27 décembre 2021 17:40:28 Rafael J. Wysocki a écrit :
> CC Daniel, Thomas and dri-devel.
> 
> On Mon, Dec 27, 2021 at 5:32 PM  wrote:
> > Hello
> > 
> > I've noticed my laptop totally freeze when going to hibernation.
> > The git bisect log is appended below.
> > Please note however that even the previous good commit was "good" (ie :
> > laptop managed to suspend and resume), the system was unstable and froze
> > few minutes later.
> So the breakage need not be related to the first bad commit.
> 
> Have you tried to revert that commit?  If so, has it helped?
Reverting the last bad commit on 5.16-rc7, the problem is still there.
I'm still convinced from bisection that it is related to graphic.

> 
> > Hardware specs: AMD Ryzen 5 4600H with Vega graphics + Nvidia 1650Ti
> > (unused) Software: Slackware 14.2 / X.org.
> > 
> > Seems to be related to drm stuff.
> > I've issued bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=215427
> > 
> > Thanks
> > 
> > git bisect start
> > # good: [8bb7eca972ad531c9b149c0a51ab43a417385813] Linux 5.15
> > git bisect good 8bb7eca972ad531c9b149c0a51ab43a417385813
> > # bad: [a7904a538933c525096ca2ccde1e60d0ee62c08e] Linux 5.16-rc6
> > git bisect bad a7904a538933c525096ca2ccde1e60d0ee62c08e
> > # bad: [43e1b12927276cde8052122a24ff796649f09d60] Merge tag 'for_linus' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost git bisect bad
> > 43e1b12927276cde8052122a24ff796649f09d60
> > # good: [fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4] Merge tag
> > 'net-next-for-5.16' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next git bisect
> > good fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4
> > # bad: [d9bd054177fbd2c4762546aec40fc3071bfe4cc0] Merge tag
> > 'amd-drm-next-5.16-2021-10-29' of
> > https://gitlab.freedesktop.org/agd5f/linux into drm-next git bisect bad
> > d9bd054177fbd2c4762546aec40fc3071bfe4cc0
> > # skip: [797d72ce8e0f8fa8a808cb189b5411046432cfd3] Merge tag
> > 'drm-misc-next-2021-10-06' of git://anongit.freedesktop.org/drm/drm-misc
> > into drm-next git bisect skip 797d72ce8e0f8fa8a808cb189b5411046432cfd3
> > # skip: [bf72ca73aaa6629568cb9b0761be6efdd02a2591] drm/amd/display: [FW
> > Promotion] Release 0.0.85 git bisect skip
> > bf72ca73aaa6629568cb9b0761be6efdd02a2591
> > # good: [bc41f059a080e487c235b539f1e5cdbf605aba9f] drm/i915/dp: fix DG1
> > and RKL max source rates git bisect good
> > bc41f059a080e487c235b539f1e5cdbf605aba9f
> > # skip: [58144d283712c9e80e528e001af6ac5aeee71af2] drm/amdgpu: unify BO
> > evicting method in amdgpu_ttm git bisect skip
> > 58144d283712c9e80e528e001af6ac5aeee71af2
> > # skip: [a5b51a9f8523a0b88ce7e8e8059f75a43c34c57f] drm/i915/gt: add
> > asm/cacheflush.h for use of clflush() git bisect skip
> > a5b51a9f8523a0b88ce7e8e8059f75a43c34c57f
> > # skip: [40348baedfbc6500e7a090c7da1d55b6c94c334f] drm/amd/display: fix
> > duplicated inclusion git bisect skip
> > 40348baedfbc6500e7a090c7da1d55b6c94c334f
> > # skip: [7547675b84bf452542463db29adb113cadb7dd6d] drm/virtio: implement
> > context init: track {ring_idx, emit_fence_info} in virtio_gpu_fence git
> > bisect skip 7547675b84bf452542463db29adb113cadb7dd6d
> > # good: [f01ee019586220c86f238263a4fbde6e72085e11] drm/amd/display: Add DP
> > 2.0 SST DC Support git bisect good
> > f01ee019586220c86f238263a4fbde6e72085e11
> > # good: [f3ede209d44d71636890a78fa89c5b1c83340320] drm/i915/pci: rename
> > functions to have i915_pci prefix git bisect good
> > f3ede209d44d71636890a78fa89c5b1c83340320
> > # skip: [4fb530e5caf7cb666948db65f245b350ce520436] drm/virtio: implement
> > context init: support init ioctl git bisect skip
> > 4fb530e5caf7cb666948db65f245b350ce520436
> > # good: [c7c4dfb6fe704ae3cce1a8f438db75b1a0a9061f] drm/i915/display: Some
> > code improvements and code style fixes for DRRS git bisect good
> > c7c4dfb6fe704ae3cce1a8f438db75b1a0a9061f
> > # skip: [7a28bee067d524c1b8770aa72a82263eb9fc53f0] drm/amd/display:
> > Disable dpp root clock when not being used git bisect skip
> > 7a28bee067d524c1b8770aa72a82263eb9fc53f0
> > # good: [5b116c17e6babc6de2e26714bc66228c74038b71] drm/i915/guc: Drop pin
> > count check trick between sched_disable and re-pin git bisect good
> > 5b116c17e6babc6de2e26714bc66228c74038b71
> > # skip: [9878844094703fbae1c3b301c9bb71253a30efe7] drm/amdgpu: drive all
> > vega asics from the IP discovery table git bisect skip
> > 9878844094703fbae1c3b301c9bb71253a30efe7
> > # skip: [7194dc998dfffca096c30b3cd39625158608992d] drm/i915/tc: Fix TypeC
> > port init/resume time sanitization git bisect skip
> > 7194dc998dfffca096c30b3cd39625158608992d
> > # skip: [5c3720be7d46581181782f5cf9585b532feed947] drm/amdgpu: get VCN and
> > SDMA instances from IP discovery table git bisect skip
> > 5c3720be7d46581181782f5cf9585b532feed947
> > # skip: [a53f2c035e9832d20775d2c66c71495f2dc27699] drm/panfrost: Calculate
> > lock region size correctly git bisect skip
> > a53f2c035e9832d20775d2c66c71495f2dc27699
> > # skip: [d04287d062a4198ec0bf0112db03618f65

[PATCH RESEND] dma-buf: heaps: Fix mutex lock area and generalize struct dma_heap_attachment

2021-12-30 Thread Weizhao Ouyang

Fix cma_heap_buffer mutex lock area to protect vmap_cnt and vaddr. And
move struct dma_heap_attachment to dma-heap.h so that vendor dma heaps
can use it, the same behaviour as struct dma_buf_attachment.

Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the cma_heap 
implementation")
Signed-off-by: Weizhao Ouyang 
---
Resend to correct email addresses.

 drivers/dma-buf/heaps/cma_heap.c| 25 ++---
 drivers/dma-buf/heaps/system_heap.c | 12 ++--
 include/linux/dma-heap.h| 15 +++
 3 files changed, 27 insertions(+), 25 deletions(-)

diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 0c05b79870f9..23dad5b6421e 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -40,13 +40,6 @@ struct cma_heap_buffer {
void *vaddr;
 };
 
-struct dma_heap_attachment {
-   struct device *dev;
-   struct sg_table table;
-   struct list_head list;
-   bool mapped;
-};
-
 static int cma_heap_attach(struct dma_buf *dmabuf,
   struct dma_buf_attachment *attachment)
 {
@@ -58,7 +51,7 @@ static int cma_heap_attach(struct dma_buf *dmabuf,
if (!a)
return -ENOMEM;
 
-   ret = sg_alloc_table_from_pages(&a->table, buffer->pages,
+   ret = sg_alloc_table_from_pages(a->table, buffer->pages,
buffer->pagecount, 0,
buffer->pagecount << PAGE_SHIFT,
GFP_KERNEL);
@@ -90,7 +83,7 @@ static void cma_heap_detach(struct dma_buf *dmabuf,
list_del(&a->list);
mutex_unlock(&buffer->lock);
 
-   sg_free_table(&a->table);
+   sg_free_table(a->table);
kfree(a);
 }
 
@@ -98,12 +91,12 @@ static struct sg_table *cma_heap_map_dma_buf(struct 
dma_buf_attachment *attachme
 enum dma_data_direction direction)
 {
struct dma_heap_attachment *a = attachment->priv;
-   struct sg_table *table = &a->table;
+   struct sg_table *table = a->table;
int ret;
 
ret = dma_map_sgtable(attachment->dev, table, direction, 0);
if (ret)
-   return ERR_PTR(-ENOMEM);
+   return ERR_PTR(ret);
a->mapped = true;
return table;
 }
@@ -124,14 +117,15 @@ static int cma_heap_dma_buf_begin_cpu_access(struct 
dma_buf *dmabuf,
struct cma_heap_buffer *buffer = dmabuf->priv;
struct dma_heap_attachment *a;
 
+   mutex_lock(&buffer->lock);
+
if (buffer->vmap_cnt)
invalidate_kernel_vmap_range(buffer->vaddr, buffer->len);
 
-   mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
if (!a->mapped)
continue;
-   dma_sync_sgtable_for_cpu(a->dev, &a->table, direction);
+   dma_sync_sgtable_for_cpu(a->dev, a->table, direction);
}
mutex_unlock(&buffer->lock);
 
@@ -144,14 +138,15 @@ static int cma_heap_dma_buf_end_cpu_access(struct dma_buf 
*dmabuf,
struct cma_heap_buffer *buffer = dmabuf->priv;
struct dma_heap_attachment *a;
 
+   mutex_lock(&buffer->lock);
+
if (buffer->vmap_cnt)
flush_kernel_vmap_range(buffer->vaddr, buffer->len);
 
-   mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
if (!a->mapped)
continue;
-   dma_sync_sgtable_for_device(a->dev, &a->table, direction);
+   dma_sync_sgtable_for_device(a->dev, a->table, direction);
}
mutex_unlock(&buffer->lock);
 
diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
index ab7fd896d2c4..aac8fc660ea6 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -33,13 +32,6 @@ struct system_heap_buffer {
void *vaddr;
 };
 
-struct dma_heap_attachment {
-   struct device *dev;
-   struct sg_table *table;
-   struct list_head list;
-   bool mapped;
-};
-
 #define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP)
 #define MID_ORDER_GFP (LOW_ORDER_GFP | __GFP_NOWARN)
 #define HIGH_ORDER_GFP  (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
@@ -68,7 +60,7 @@ static struct sg_table *dup_sg_table(struct sg_table *table)
ret = sg_alloc_table(new_table, table->orig_nents, GFP_KERNEL);
if (ret) {
kfree(new_table);
-   return ERR_PTR(-ENOMEM);
+   return ERR_PTR(ret);
}
 
new_sg = new_table->sgl;
@@ -94,7 +86,7 @@ static int system_heap_attach(struct dma_buf *dmabuf,
table = dup_sg_table(&buffer->sg_table);
if (IS_ERR(table)) {
kfree(a);
-   return -ENOMEM;
+

[RFC 22/32] video: handle HAS_IOPORT dependencies

In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them and guard inline code in headers.

Co-developed-by: Arnd Bergmann 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Niklas Schnelle 
---
 drivers/video/fbdev/Kconfig | 1 +
 include/video/vga.h | 8 
 2 files changed, 9 insertions(+)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index a3446d44c118..d95f638f4deb 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -436,6 +436,7 @@ config FB_FM2
 config FB_ARC
tristate "Arc Monochrome LCD board support"
depends on FB && (X86 || COMPILE_TEST)
+   depends on HAS_IOPORT
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
diff --git a/include/video/vga.h b/include/video/vga.h
index d334e64c1c19..53cb52c0fddb 100644
--- a/include/video/vga.h
+++ b/include/video/vga.h
@@ -201,18 +201,26 @@ extern int restore_vga(struct vgastate *state);
  
 static inline unsigned char vga_io_r (unsigned short port)
 {
+#ifdef CONFIG_HAS_IOPORT
return inb_p(port);
+#else
+   return 0xff;
+#endif
 }
 
 static inline void vga_io_w (unsigned short port, unsigned char val)
 {
+#ifdef CONFIG_HAS_IOPORT
outb_p(val, port);
+#endif
 }
 
 static inline void vga_io_w_fast (unsigned short port, unsigned char reg,
  unsigned char val)
 {
+#ifdef CONFIG_HAS_IOPORT
outw(VGA_OUT16VAL (val, reg), port);
+#endif
 }
 
 static inline unsigned char vga_mm_r (void __iomem *regbase, unsigned short 
port)
-- 
2.32.0

Re: [PATCH 2/3] arm64: dts: renesas: r8a77961: Add lvds0 device node

Endpoints are meant to model a link between two ports, so an endpoint

shouldn't exist in isolation. The issue with creating named endpoints in
SoC files is that you can't tell there what remote devices may exist, so
the endpoint may or may not match the actual hardware design of a board.
I think it's better to create endpoints on both sides together in
overlays.

https://lore.kernel.org/linux-renesas-soc/20211229193135.28767-2-laurent.pinchart+rene...@ideasonboard.com/T/#t

What I don't like here is: details of particular SoC (such as "panel gets video from port@1 of &lvds1)
leak into per-panel DT fragment.

This limits possibilities to share DT fragments between different use cases. In the patch pointed by the
above URL, you have to reference both board and panel in the dts file name.

I'd prefer to make each DT fragment to use only either entities defined in that fragment itself, or
defined "interface entities" between this and "neighbor" DT fragment.

Such as:
- SoC's DT fragment defines a named port/endpoint to export video stream at
- board's DT fragment defines a named panel node corresponding to panel plugged into board's physical
connector, and connects endpoints with SoC's video export,
- panel's DT fragment extends the panel node from board with video mode information for this particular
panel.

And similar for backlight, power, and whatever else exposed on the physical
panel connector.

So for the board's physical connector there is a set of board-DT-provided entities for use by DT
fragment of whatever component plugged to the connector, without direct references to final SoC
interfaces. And possibility to reuse DT fragments between boards, and probably have a library of DT
fragments for hardware currently available in the market, usable with different boards where that
hardware can be connected.

Nikita

Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI

On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > Em Wed, 29 Dec 2021 12:45:38 +0100
> > Niklas Schnelle  escreveu:
> > > ...
> > > I do think we agree that once done correctly there is value in
> > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> 
> I'm not sure I'm convinced about this.  For s390, you could do this
> patch series, where you don't define inb() at all, and you add new
> dependencies to prevent compile errors.  Or you could define inb() to
> return ~0, which is what happens on other platforms when the device is
> not present.
> 
> > Personally, I don't see much value on a Kconfig var for legacy PCI I/O 
> > space. From maintenance PoV, bots won't be triggered if someone use
> > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > could end having a mix of both at the wrong places, in long term.
> > 
> > Also, assuming that PCIe hardware will some day abandon support for 
> > "legacy" PCI I/O space, I guess some runtime logic would be needed, 
> > in order to work with both kinds of PCIe controllers. So, having a
> > Kconfig option won't help much, IMO.
> > 
> > So, my personal preference would be to have just one Kconfig var, but
> > I'm ok if the PCI maintainers decide otherwise.
> 
> I don't really like the "LEGACY_PCI" Kconfig option.  "Legacy" just
> means something old and out of favor; it doesn't say *what* that
> something is.
> 
> I think you're specifically interested in I/O port space usage, and it
> seems that you want all PCI drivers that *only* use I/O port space to
> depend on LEGACY_PCI?  Drivers that can use either I/O or memory
> space or both would not depend on LEGACY_PCI?  This seems a little
> murky and error-prone.

I'd like to hear Arnd's opinion on this but you're the PCI maintainer
so of course your buy-in would be quite important for such an option.

> 
> What if you used the approach from [1] but just dropped the warning?
> The inb() would return ~0 if the platform doesn't support I/O port
> space.  Drivers should be prepared to handle that because that's what
> happens if the device doesn't exist.

Hmm, in that mail Linus very clearly and specifically asked for this to
be a compile-time thing. So, if we do want to make it compile-time but
keep the potential errors to a minimum I guess just having HAS_IOPORT
might be valid compromise. It gets caught by bots through allyesconfig
or randconfig on HAS_IOPORT=n architectures. Also it has a nice
symmetry with the existing HAS_IOMEM. 

>  
> 
> HAS_IOPORT and LEGACY_PCI is a lot of Kconfiggery that basically just
> avoids building drivers that aren't useful on s390.  I'm not sure the
> benefit outweighs the complication.
> 
> Bjorn
> 
> [1] 
> https://lore.kernel.org/lkml/CAHk-=wg80je=k7madf4e7wrrnp37e3qh6y10svhdc7o8sz_...@mail.gmail.com/
> 

Despite s390 I believe it would also affect nds32, um, h8300, nios2,
openrisc, hexagon, csky, and xtensa. But yes none of these is any less
niche than us. I do wonder if we will see a new drivers using I/O
ports?

[v1 0/2] drm/msm/dsi: Add 10nm dsi phy tuning configuration support

2021-12-30 Thread Rajeev Nandan

This series is to add DSI PHY tuning support in Qualcomm Snapdragon
SoCs with 10nm DSI PHY e.g. SC7180

In most cases the default values of DSI PHY tuning registers
should be sufficient as they are fully optimized. However, in
some cases (for example, where extreme board parasitics cause
the eye shape to degrade), the override bits can be used to
improve the signal quality.

As per the MSM DSI PHY (10nm) tuning guideline, the drive strength
can be adjusted using DSIPHY_RESCODE_OFFSET_TOP & DSIPHY_RESCODE_OFFSET_BOT
registers, and the drive level can be adjusted using DSIPHY_CMN_VREG_CTRL
register.

Add DSI PHY tuning support for 10nm PHY. This can be extended to other
DSI PHY versions if needed. Number of registers to configure the PHY
tuning per lane can be different for different versions of the DSI PHY.
I tried to make it generic so that it can be extended to other versions.

Rajeev Nandan (2):
  dt-bindings: msm/dsi: Add 10nm dsi phy tuning properties
  drm/msm/dsi: Add 10nm dsi phy tuning configuration support

 .../bindings/display/msm/dsi-phy-10nm.yaml | 19 
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  | 55 ++
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  | 23 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 31 +---
 4 files changed, 122 insertions(+), 6 deletions(-)

-- 
2.7.4

Re: [PATCH 2/3] arm64: dts: renesas: r8a77961: Add lvds0 device node


Hi.

Thank you for looking at this.


+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
};


Endpoints must have a remote-endpoint property. Let's drop the endpoint
here and keep the port only, the endpoint can be declared in board
files.

If you're fine with this change I can make it when applying the patch.


This empty endpoint is currently defined in dtsi files for other r-car gen3 SoCs.  Goal here is to 
define lvds0_out label that is then used in extension board dtsi files to link to the port.


In this patch I just used the same approach as in files laying nearby.

If this approach is not appropriate, then perhaps need to fix it in files for all SoCs, to make it 
possible for extension board dtsi to be compatible with all of them.


Nikita

[PATCH] video: fbdev: asiliantfb: remove redundant assignment to variable Ftarget

2021-12-30 Thread Colin Ian King

Variable Ftarget is being initialized with a value that is never read,
it is being re-assigned a different value a little later on. The
assignment is redundant and can be removed.

Signed-off-by: Colin Ian King 
---
 drivers/video/fbdev/asiliantfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/asiliantfb.c b/drivers/video/fbdev/asiliantfb.c
index 84c56f525889..f8ef62542f7f 100644
--- a/drivers/video/fbdev/asiliantfb.c
+++ b/drivers/video/fbdev/asiliantfb.c
@@ -110,7 +110,7 @@ static const struct fb_ops asiliantfb_ops = {
 static void asiliant_calc_dclk2(u32 *ppixclock, u8 *dclk2_m, u8 *dclk2_n, u8 
*dclk2_div)
 {
unsigned pixclock = *ppixclock;
-   unsigned Ftarget = 100 * (100 / pixclock);
+   unsigned Ftarget;
unsigned n;
unsigned best_error = 0x;
unsigned best_m = 0x,
-- 
2.33.1

[PATCH v3] drm/mediatek: Fix unused-but-set variable warning

2021-12-30 Thread Miles Chen

clang reports a unused-but-set variable warning:
drivers/gpu/drm/mediatek/mtk_cec.c:85:6: warning: variable 'tmp' set but not 
used [-Wunused-but-set-variable]

In current implementation, mtk_cec_mask() writes val into target register
and ignores the mask. After talking to our hdmi experts, mtk_cec_mask()
should read a register, clean only mask bits, and update (val | mask) bits
to the register.

Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")

Cc: Zhiqiang Lin 
Cc: CK Hu 
Cc: Matthias Brugger 

Signed-off-by: Miles Chen 

---

Change since v1:
add Fixes tag

Change since v2:
add explanation of mtk_cec_mask()

Change-Id: Iec6402b0532942f4d0e8bc56817eb87b95c03fad
---
 drivers/gpu/drm/mediatek/mtk_cec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c 
b/drivers/gpu/drm/mediatek/mtk_cec.c
index e9cef5c0c8f7..cdfa648910b2 100644
--- a/drivers/gpu/drm/mediatek/mtk_cec.c
+++ b/drivers/gpu/drm/mediatek/mtk_cec.c
@@ -85,7 +85,7 @@ static void mtk_cec_mask(struct mtk_cec *cec, unsigned int 
offset,
u32 tmp = readl(cec->regs + offset) & ~mask;
 
tmp |= val & mask;
-   writel(val, cec->regs + offset);
+   writel(tmp, cec->regs + offset);
 }
 
 void mtk_cec_set_hpd_event(struct device *dev,
-- 
2.18.0

Re: [PATCH 2/3] arm64: dts: renesas: r8a77961: Add lvds0 device node

I'd prefer to make each DT fragment to use only either entities defined in that
fragment itself, or
defined "interface entities" between this and "neighbor" DT fragment.

Such as:
- SoC's DT fragment defines a named port/endpoint to export video stream at
- board's DT fragment defines a named panel node corresponding to panel plugged
into board's physical
connector, and connects endpoints with SoC's video export,
- panel's DT fragment extends the panel node from board with video mode
information for this particular
panel.
...

I agree it's annoying, but we'll have a similar problem, just the other
way around, with an endpoint defined in the SoC dtsi. Many R-Car SoCs
have two LVDS encoders, and you can attach a panel to either of them.
Some boards use LVDS0, some boards use LVDS1, and some boards could even
use both.

The case of "some boards use LVDS0, some boards use LVDS1" is directly addressed by what I'm trying to
suggest. The per-board DT fragment can completely hide board's connection details, without a need for
any new concept.

The case of "some boards could even use both" indeed needs a some way to parametrize panel's DT
fragment, and perhaps load two instances of it with different parameters. To some extent this is doable
via preprocessor magic and multiple includes, although this approach has obvious disadvantages.

A real solution for this problem will require a new concept. The "DT
connector" proposal is related to this problem space. There's also a
proprietary implementation in the Rapsberry Pi boot loader of a
mechanism to support parametrized overlays ([2] and [3], or [4] for an
example of how a panel reset or backlight GPIO can be parametrized).

So the problem is already recognized for years... what stops from wider adoption of this or similar
solutions?

And - if/while that is not being done - can't we at least try to follow more portable DT coding pattern
while staying within existing concepts?

Nikita

Re: [PATCH 2/3] arm64: dts: renesas: r8a77961: Add lvds0 device node


If this approach is not appropriate, then perhaps need to fix it in
files for all SoCs, to make it possible for extension board dtsi to be
compatible with all of them.


I'm writing a patch to drop those right now :-) I'll CC you.


Ok.

But, are you sure that empty nodes like these are that bad?

I was going to suggest a movement in opposite direction - adding more such nodes, so they could form a 
sort of API for dts plugins describing e.g. displays connectable to boards based on different SoCs.


Nikita

Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection for SRIOV

2021-12-30 Thread Andrey Grodzovsky


Thanks a lot, please let me know.

Andrey

On 2021-12-24 3:58 a.m., Deng, Emily wrote:

These patches look good to me. JingWen will pull these patches and do some 
basic TDR test on sriov environment, and give feedback.

Best wishes
Emily Deng




-Original Message-
From: Liu, Monk 
Sent: Thursday, December 23, 2021 6:14 PM
To: Koenig, Christian ; Grodzovsky, Andrey
; dri-devel@lists.freedesktop.org; amd-
g...@lists.freedesktop.org; Chen, Horace ; Chen,
JingWen ; Deng, Emily 
Cc: dan...@ffwll.ch
Subject: RE: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection
for SRIOV

[AMD Official Use Only]

@Chen, Horace @Chen, JingWen @Deng, Emily

Please take a review on Andrey's patch

Thanks
---
Monk Liu | Cloud GPU & Virtualization Solution | AMD
---
we are hiring software manager for CVS core team
---

-Original Message-
From: Koenig, Christian 
Sent: Thursday, December 23, 2021 4:42 PM
To: Grodzovsky, Andrey ; dri-
de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: dan...@ffwll.ch; Liu, Monk ; Chen, Horace

Subject: Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection
for SRIOV

Am 22.12.21 um 23:14 schrieb Andrey Grodzovsky:

Since now flr work is serialized against  GPU resets there is no need
for this.

Signed-off-by: Andrey Grodzovsky 

Acked-by: Christian König 


---
   drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 11 ---
   drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 11 ---
   2 files changed, 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
index 487cd654b69e..7d59a66e3988 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
@@ -248,15 +248,7 @@ static void xgpu_ai_mailbox_flr_work(struct

work_struct *work)

struct amdgpu_device *adev = container_of(virt, struct

amdgpu_device, virt);

int timeout = AI_MAILBOX_POLL_FLR_TIMEDOUT;

-   /* block amdgpu_gpu_recover till msg FLR COMPLETE received,
-* otherwise the mailbox msg will be ruined/reseted by
-* the VF FLR.
-*/
-   if (!down_write_trylock(&adev->reset_sem))
-   return;
-
amdgpu_virt_fini_data_exchange(adev);
-   atomic_set(&adev->in_gpu_reset, 1);

xgpu_ai_mailbox_trans_msg(adev, IDH_READY_TO_RESET, 0, 0, 0);

@@ -269,9 +261,6 @@ static void xgpu_ai_mailbox_flr_work(struct

work_struct *work)

} while (timeout > 1);

   flr_done:
-   atomic_set(&adev->in_gpu_reset, 0);
-   up_write(&adev->reset_sem);
-
/* Trigger recovery for world switch failure if no TDR */
if (amdgpu_device_should_recover_gpu(adev)
&& (!amdgpu_device_has_job_running(adev) || diff --git
a/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
b/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
index e3869067a31d..f82c066c8e8d 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
@@ -277,15 +277,7 @@ static void xgpu_nv_mailbox_flr_work(struct

work_struct *work)

struct amdgpu_device *adev = container_of(virt, struct

amdgpu_device, virt);

int timeout = NV_MAILBOX_POLL_FLR_TIMEDOUT;

-   /* block amdgpu_gpu_recover till msg FLR COMPLETE received,
-* otherwise the mailbox msg will be ruined/reseted by
-* the VF FLR.
-*/
-   if (!down_write_trylock(&adev->reset_sem))
-   return;
-
amdgpu_virt_fini_data_exchange(adev);
-   atomic_set(&adev->in_gpu_reset, 1);

xgpu_nv_mailbox_trans_msg(adev, IDH_READY_TO_RESET, 0, 0, 0);

@@ -298,9 +290,6 @@ static void xgpu_nv_mailbox_flr_work(struct

work_struct *work)

} while (timeout > 1);

   flr_done:
-   atomic_set(&adev->in_gpu_reset, 0);
-   up_write(&adev->reset_sem);
-
/* Trigger recovery for world switch failure if no TDR */
if (amdgpu_device_should_recover_gpu(adev)
&& (!amdgpu_device_has_job_running(adev) ||

Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection for SRIOV

2021-12-30 Thread Andrey Grodzovsky


Sure, I guess i can drop this patch then.

Andrey

On 2021-12-24 4:57 a.m., JingWen Chen wrote:

I do agree with shaoyun, if the host find the gpu engine hangs first, and do 
the flr, guest side thread may not know this and still try to access HW(e.g. 
kfd is using a lot of amdgpu_in_reset and reset_sem to identify the reset 
status). And this may lead to very bad result.

On 2021/12/24 下午4:58, Deng, Emily wrote:

These patches look good to me. JingWen will pull these patches and do some 
basic TDR test on sriov environment, and give feedback.

Best wishes
Emily Deng




-Original Message-
From: Liu, Monk 
Sent: Thursday, December 23, 2021 6:14 PM
To: Koenig, Christian ; Grodzovsky, Andrey
; dri-devel@lists.freedesktop.org; amd-
g...@lists.freedesktop.org; Chen, Horace ; Chen,
JingWen ; Deng, Emily 
Cc: dan...@ffwll.ch
Subject: RE: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection
for SRIOV

[AMD Official Use Only]

@Chen, Horace @Chen, JingWen @Deng, Emily

Please take a review on Andrey's patch

Thanks
---
Monk Liu | Cloud GPU & Virtualization Solution | AMD
---
we are hiring software manager for CVS core team
---

-Original Message-
From: Koenig, Christian 
Sent: Thursday, December 23, 2021 4:42 PM
To: Grodzovsky, Andrey ; dri-
de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: dan...@ffwll.ch; Liu, Monk ; Chen, Horace

Subject: Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection
for SRIOV

Am 22.12.21 um 23:14 schrieb Andrey Grodzovsky:

Since now flr work is serialized against  GPU resets there is no need
for this.

Signed-off-by: Andrey Grodzovsky 

Acked-by: Christian König 


---
   drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 11 ---
   drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 11 ---
   2 files changed, 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
index 487cd654b69e..7d59a66e3988 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
@@ -248,15 +248,7 @@ static void xgpu_ai_mailbox_flr_work(struct

work_struct *work)

struct amdgpu_device *adev = container_of(virt, struct

amdgpu_device, virt);

int timeout = AI_MAILBOX_POLL_FLR_TIMEDOUT;

-   /* block amdgpu_gpu_recover till msg FLR COMPLETE received,
-* otherwise the mailbox msg will be ruined/reseted by
-* the VF FLR.
-*/
-   if (!down_write_trylock(&adev->reset_sem))
-   return;
-
amdgpu_virt_fini_data_exchange(adev);
-   atomic_set(&adev->in_gpu_reset, 1);

xgpu_ai_mailbox_trans_msg(adev, IDH_READY_TO_RESET, 0, 0, 0);

@@ -269,9 +261,6 @@ static void xgpu_ai_mailbox_flr_work(struct

work_struct *work)

} while (timeout > 1);

   flr_done:
-   atomic_set(&adev->in_gpu_reset, 0);
-   up_write(&adev->reset_sem);
-
/* Trigger recovery for world switch failure if no TDR */
if (amdgpu_device_should_recover_gpu(adev)
&& (!amdgpu_device_has_job_running(adev) || diff --git
a/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
b/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
index e3869067a31d..f82c066c8e8d 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
@@ -277,15 +277,7 @@ static void xgpu_nv_mailbox_flr_work(struct

work_struct *work)

struct amdgpu_device *adev = container_of(virt, struct

amdgpu_device, virt);

int timeout = NV_MAILBOX_POLL_FLR_TIMEDOUT;

-   /* block amdgpu_gpu_recover till msg FLR COMPLETE received,
-* otherwise the mailbox msg will be ruined/reseted by
-* the VF FLR.
-*/
-   if (!down_write_trylock(&adev->reset_sem))
-   return;
-
amdgpu_virt_fini_data_exchange(adev);
-   atomic_set(&adev->in_gpu_reset, 1);

xgpu_nv_mailbox_trans_msg(adev, IDH_READY_TO_RESET, 0, 0, 0);

@@ -298,9 +290,6 @@ static void xgpu_nv_mailbox_flr_work(struct

work_struct *work)

} while (timeout > 1);

   flr_done:
-   atomic_set(&adev->in_gpu_reset, 0);
-   up_write(&adev->reset_sem);
-
/* Trigger recovery for world switch failure if no TDR */
if (amdgpu_device_should_recover_gpu(adev)
&& (!amdgpu_device_has_job_running(adev) ||

Re: [PATCH] drm: get rid of DRM_DEBUG_* log calls in drm core, files drm_{b,c}*.c

2021-12-30 Thread Claudio Suarez



Hi,

Please, don't apply this patch. I have to review it,.

BR



On Thu, Dec 30, 2021 at 10:31:45PM +0800, kernel test robot wrote:
> Hi Claudio,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on drm/drm-next]
> [also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip 
> v5.16-rc7 next-20211224]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:
> https://github.com/0day-ci/linux/commits/Claudio-Suarez/drm-get-rid-of-DRM_DEBUG_-log-calls-in-drm-core-files-drm_-b-c-c/20211230-185446
> base:   git://anongit.freedesktop.org/drm/drm drm-next
> config: hexagon-randconfig-r041-20211230 
> (https://download.01.org/0day-ci/archive/20211230/202112302236.ikd2et5w-...@intel.com/config)
> compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 
> cd284b7ac0615afc6e0f1a30da2777e361de27a3)
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # 
> https://github.com/0day-ci/linux/commit/9cfa12f89e858cd6d2eb5eb17c6db7ab689343e3
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review 
> Claudio-Suarez/drm-get-rid-of-DRM_DEBUG_-log-calls-in-drm-core-files-drm_-b-c-c/20211230-185446
> git checkout 9cfa12f89e858cd6d2eb5eb17c6db7ab689343e3
> # save the config file to linux build tree
> mkdir build_dir
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
> O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/gpu/drm/
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> All warnings (new ones prefixed by >>):
> 
>drivers/gpu/drm/drm_bufs.c:174:14: error: incompatible pointer types 
> passing 'struct drm_device *' to parameter of type 'const struct device *' 
> [-Werror,-Wincompatible-pointer-types]
>drm_dev_dbg(dev, "offset = 0x%08llx, size = 0x%08lx, type = %d\n",
>^~~
>include/drm/drm_print.h:337:39: note: passing argument to parameter 'dev' 
> here
>void drm_dev_dbg(const struct device *dev, enum drm_debug_category 
> category,
>  ^
> >> drivers/gpu/drm/drm_bufs.c:174:19: warning: incompatible pointer to 
> >> integer conversion passing 'char[46]' to parameter of type 'enum 
> >> drm_debug_category' [-Wint-conversion]
>drm_dev_dbg(dev, "offset = 0x%08llx, size = 0x%08lx, type = %d\n",
> ^~~~
>include/drm/drm_print.h:337:68: note: passing argument to parameter 
> 'category' here
>void drm_dev_dbg(const struct device *dev, enum drm_debug_category 
> category,
>   ^
> >> drivers/gpu/drm/drm_bufs.c:175:7: warning: incompatible integer to pointer 
> >> conversion passing 'unsigned long long' to parameter of type 'const char 
> >> *' [-Wint-conversion]
>(unsigned long long)map->offset, map->size, map->type);
>^~~
>include/drm/drm_print.h:338:16: note: passing argument to parameter 
> 'format' here
> const char *format, ...);
> ^
>drivers/gpu/drm/drm_bufs.c:208:17: error: incompatible pointer types 
> passing 'struct drm_device *' to parameter of type 'const struct device *' 
> [-Werror,-Wincompatible-pointer-types]
>drm_dev_dbg(dev,
>^~~
>include/drm/drm_print.h:337:39: note: passing argument to parameter 'dev' 
> here
>void drm_dev_dbg(const struct device *dev, enum drm_debug_category 
> category,
>  ^
>drivers/gpu/drm/drm_bufs.c:209:10: warning: incompatible pointer to 
> integer conversion passing 'char[62]' to parameter of type 'enum 
> drm_debug_category' [-Wint-conversion]
>"Matching maps of type %d with 
> mismatched sizes, (%ld vs %ld)\n",
>
> ^~~~
>include/

[PATCH 0/2] drm/meson: Error handling fix when AFBCD is used

2021-12-30 Thread Martin Blumenstingl

Hi Neil,

this series consists of a small cleanup patch and a fix for the error
handling in meson_drv_bind_master() when AFBCD is used.
The patches are based on drm-misc to not conflict with your previous
driver rework. Since the problem has not been observed in the wild I
decided not to Cc linux-stable.


Best regards,
Martin


Martin Blumenstingl (2):
  drm/meson: osd_afbcd: Add an exit callback to struct meson_afbcd_ops
  drm/meson: Fix error handling when afbcd.ops->init fails

 drivers/gpu/drm/meson/meson_drv.c   | 25 +++
 drivers/gpu/drm/meson/meson_osd_afbcd.c | 41 -
 drivers/gpu/drm/meson/meson_osd_afbcd.h |  1 +
 3 files changed, 41 insertions(+), 26 deletions(-)

-- 
2.34.1

[PATCH 1/2] drm/meson: osd_afbcd: Add an exit callback to struct meson_afbcd_ops

2021-12-30 Thread Martin Blumenstingl

Use this to simplify the driver shutdown. It will also come handy when
fixing the error handling in meson_drv_bind_master().

Signed-off-by: Martin Blumenstingl 
---
 drivers/gpu/drm/meson/meson_drv.c   |  6 ++--
 drivers/gpu/drm/meson/meson_osd_afbcd.c | 41 -
 drivers/gpu/drm/meson/meson_osd_afbcd.h |  1 +
 3 files changed, 30 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index 80f1d439841a..b919271a6e50 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -385,10 +385,8 @@ static void meson_drv_unbind(struct device *dev)
free_irq(priv->vsync_irq, drm);
drm_dev_put(drm);
 
-   if (priv->afbcd.ops) {
-   priv->afbcd.ops->reset(priv);
-   meson_rdma_free(priv);
-   }
+   if (priv->afbcd.ops)
+   priv->afbcd.ops->exit(priv);
 }
 
 static const struct component_master_ops meson_drv_master_ops = {
diff --git a/drivers/gpu/drm/meson/meson_osd_afbcd.c 
b/drivers/gpu/drm/meson/meson_osd_afbcd.c
index ffc6b584dbf8..0cdbe899402f 100644
--- a/drivers/gpu/drm/meson/meson_osd_afbcd.c
+++ b/drivers/gpu/drm/meson/meson_osd_afbcd.c
@@ -79,11 +79,6 @@ static bool meson_gxm_afbcd_supported_fmt(u64 modifier, 
uint32_t format)
return meson_gxm_afbcd_pixel_fmt(modifier, format) >= 0;
 }
 
-static int meson_gxm_afbcd_init(struct meson_drm *priv)
-{
-   return 0;
-}
-
 static int meson_gxm_afbcd_reset(struct meson_drm *priv)
 {
writel_relaxed(VIU_SW_RESET_OSD1_AFBCD,
@@ -93,6 +88,16 @@ static int meson_gxm_afbcd_reset(struct meson_drm *priv)
return 0;
 }
 
+static int meson_gxm_afbcd_init(struct meson_drm *priv)
+{
+   return 0;
+}
+
+static void meson_gxm_afbcd_exit(struct meson_drm *priv)
+{
+   meson_gxm_afbcd_reset(priv);
+}
+
 static int meson_gxm_afbcd_enable(struct meson_drm *priv)
 {
writel_relaxed(FIELD_PREP(OSD1_AFBCD_ID_FIFO_THRD, 0x40) |
@@ -172,6 +177,7 @@ static int meson_gxm_afbcd_setup(struct meson_drm *priv)
 
 struct meson_afbcd_ops meson_afbcd_gxm_ops = {
.init = meson_gxm_afbcd_init,
+   .exit = meson_gxm_afbcd_exit,
.reset = meson_gxm_afbcd_reset,
.enable = meson_gxm_afbcd_enable,
.disable = meson_gxm_afbcd_disable,
@@ -269,6 +275,18 @@ static bool meson_g12a_afbcd_supported_fmt(u64 modifier, 
uint32_t format)
return meson_g12a_afbcd_pixel_fmt(modifier, format) >= 0;
 }
 
+static int meson_g12a_afbcd_reset(struct meson_drm *priv)
+{
+   meson_rdma_reset(priv);
+
+   meson_rdma_writel_sync(priv, VIU_SW_RESET_G12A_AFBC_ARB |
+  VIU_SW_RESET_G12A_OSD1_AFBCD,
+  VIU_SW_RESET);
+   meson_rdma_writel_sync(priv, 0, VIU_SW_RESET);
+
+   return 0;
+}
+
 static int meson_g12a_afbcd_init(struct meson_drm *priv)
 {
int ret;
@@ -286,16 +304,10 @@ static int meson_g12a_afbcd_init(struct meson_drm *priv)
return 0;
 }
 
-static int meson_g12a_afbcd_reset(struct meson_drm *priv)
+static void meson_g12a_afbcd_exit(struct meson_drm *priv)
 {
-   meson_rdma_reset(priv);
-
-   meson_rdma_writel_sync(priv, VIU_SW_RESET_G12A_AFBC_ARB |
-  VIU_SW_RESET_G12A_OSD1_AFBCD,
-  VIU_SW_RESET);
-   meson_rdma_writel_sync(priv, 0, VIU_SW_RESET);
-
-   return 0;
+   meson_g12a_afbcd_reset(priv);
+   meson_rdma_free(priv);
 }
 
 static int meson_g12a_afbcd_enable(struct meson_drm *priv)
@@ -380,6 +392,7 @@ static int meson_g12a_afbcd_setup(struct meson_drm *priv)
 
 struct meson_afbcd_ops meson_afbcd_g12a_ops = {
.init = meson_g12a_afbcd_init,
+   .exit = meson_g12a_afbcd_exit,
.reset = meson_g12a_afbcd_reset,
.enable = meson_g12a_afbcd_enable,
.disable = meson_g12a_afbcd_disable,
diff --git a/drivers/gpu/drm/meson/meson_osd_afbcd.h 
b/drivers/gpu/drm/meson/meson_osd_afbcd.h
index 5e5523304f42..e77ddeb6416f 100644
--- a/drivers/gpu/drm/meson/meson_osd_afbcd.h
+++ b/drivers/gpu/drm/meson/meson_osd_afbcd.h
@@ -14,6 +14,7 @@
 
 struct meson_afbcd_ops {
int (*init)(struct meson_drm *priv);
+   void (*exit)(struct meson_drm *priv);
int (*reset)(struct meson_drm *priv);
int (*enable)(struct meson_drm *priv);
int (*disable)(struct meson_drm *priv);
-- 
2.34.1

[PATCH 2/2] drm/meson: Fix error handling when afbcd.ops->init fails

2021-12-30 Thread Martin Blumenstingl

When afbcd.ops->init fails we need to free the struct drm_device. Also
all errors which come after afbcd.ops->init was successful need to exit
the AFBCD, just like meson_drv_unbind() does.

Fixes: d1b5e41e13a7e9 ("drm/meson: Add AFBCD module driver")
Signed-off-by: Martin Blumenstingl 
---
 drivers/gpu/drm/meson/meson_drv.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index b919271a6e50..26aeaf0ab86e 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -302,42 +302,42 @@ static int meson_drv_bind_master(struct device *dev, bool 
has_components)
if (priv->afbcd.ops) {
ret = priv->afbcd.ops->init(priv);
if (ret)
-   return ret;
+   goto free_drm;
}
 
/* Encoder Initialization */
 
ret = meson_encoder_cvbs_init(priv);
if (ret)
-   goto free_drm;
+   goto exit_afbcd;
 
if (has_components) {
ret = component_bind_all(drm->dev, drm);
if (ret) {
dev_err(drm->dev, "Couldn't bind all components\n");
-   goto free_drm;
+   goto exit_afbcd;
}
}
 
ret = meson_encoder_hdmi_init(priv);
if (ret)
-   goto free_drm;
+   goto exit_afbcd;
 
ret = meson_plane_create(priv);
if (ret)
-   goto free_drm;
+   goto exit_afbcd;
 
ret = meson_overlay_create(priv);
if (ret)
-   goto free_drm;
+   goto exit_afbcd;
 
ret = meson_crtc_create(priv);
if (ret)
-   goto free_drm;
+   goto exit_afbcd;
 
ret = request_irq(priv->vsync_irq, meson_irq, 0, drm->driver->name, 
drm);
if (ret)
-   goto free_drm;
+   goto exit_afbcd;
 
drm_mode_config_reset(drm);
 
@@ -355,6 +355,9 @@ static int meson_drv_bind_master(struct device *dev, bool 
has_components)
 
 uninstall_irq:
free_irq(priv->vsync_irq, drm);
+exit_afbcd:
+   if (priv->afbcd.ops)
+   priv->afbcd.ops->exit(priv);
 free_drm:
drm_dev_put(drm);
 
-- 
2.34.1

[Bug 215436] admgpu: suspend and resuming from suspend don't work

https://bugzilla.kernel.org/show_bug.cgi?id=215436

--- Comment #6 from spassw...@web.de ---
After sorting out some .config troubles I've reverted commit
2a50edbf10c8c56e930bfb53d8f9f00a33fd837e in linux-5.16-rc7 and this seems to
cure both the not properly suspending issue (fan and keyboard lights stayed on)
and the hang on resuming from suspend issue.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215436] admgpu: suspend and resuming from suspend don't work

https://bugzilla.kernel.org/show_bug.cgi?id=215436

--- Comment #7 from spassw...@web.de ---
The
 [drm] Register(0) [mmUVD_POWER_STATUS] failed to reach value 0x0001 !=
0x0002
are still there, but they don't seem to be harmful, in fact they were there
even
 in linux.5.15.11 where suspend and resume seemed to work.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 1/2] drm/i2c/tda998x: Switch to atomic operations

2021-12-30 Thread Fabio Estevam

Use the atomic version of the enable/disable operations to continue the
transition to the atomic API, started with the introduction of
.atomic_get_input_bus_fmts(). This will be needed to access the mode
from the atomic state.

Based on Laurent's commit a6ea7d268a63("drm: bridge: ti-sn65dsi83:
Switch to atomic operations").

Tested on a imx6sx-udoo-neo board.

Suggested-by: Marek Vasut 
Signed-off-by: Fabio Estevam 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index b7ec6c374fbd..adaa985af87e 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1395,7 +1395,8 @@ static enum drm_mode_status 
tda998x_bridge_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
 }
 
-static void tda998x_bridge_enable(struct drm_bridge *bridge)
+static void tda998x_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state 
*old_bridge_state)
 {
struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
 
@@ -1413,7 +1414,8 @@ static void tda998x_bridge_enable(struct drm_bridge 
*bridge)
}
 }
 
-static void tda998x_bridge_disable(struct drm_bridge *bridge)
+static void tda998x_bridge_atomic_disable(struct drm_bridge *bridge,
+  struct drm_bridge_state 
*old_bridge_state)
 {
struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
 
@@ -1680,9 +1682,9 @@ static const struct drm_bridge_funcs tda998x_bridge_funcs 
= {
.attach = tda998x_bridge_attach,
.detach = tda998x_bridge_detach,
.mode_valid = tda998x_bridge_mode_valid,
-   .disable = tda998x_bridge_disable,
+   .atomic_disable = tda998x_bridge_atomic_disable,
.mode_set = tda998x_bridge_mode_set,
-   .enable = tda998x_bridge_enable,
+   .atomic_enable = tda998x_bridge_atomic_enable,
 };
 
 /* I2C driver functions */
-- 
2.25.1

[PATCH 2/2] drm/i2c/tda998x: Implement atomic_get_input_bus_fmts

2021-12-30 Thread Fabio Estevam

Implement the .atomic_get_input_bus_fmts callback to let the bridge
indicate the pixel format it requires on the parallel bus to the LCDIF.

Based on Marek's commit db8b7ca5b232 ("drm/bridge: ti-sn65dsi83: Replace
connector format patching with atomic_get_input_bus_fmts").

Tested on a imx6sx-udoo-neo board.

Suggested-by: Marek Vasut 
Signed-off-by: Fabio Estevam 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index adaa985af87e..d987481e97c1 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1678,6 +1678,31 @@ static void tda998x_bridge_mode_set(struct drm_bridge 
*bridge,
mutex_unlock(&priv->audio_mutex);
 }
 
+#define MAX_INPUT_SEL_FORMATS  1
+
+static u32 *
+tda998x_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+  struct drm_bridge_state *bridge_state,
+  struct drm_crtc_state *crtc_state,
+  struct drm_connector_state *conn_state,
+  u32 output_fmt,
+  unsigned int *num_input_fmts)
+{
+   u32 *input_fmts;
+
+   *num_input_fmts = 0;
+
+   input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+GFP_KERNEL);
+   if (!input_fmts)
+   return NULL;
+
+   input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+   *num_input_fmts = 1;
+
+   return input_fmts;
+}
+
 static const struct drm_bridge_funcs tda998x_bridge_funcs = {
.attach = tda998x_bridge_attach,
.detach = tda998x_bridge_detach,
@@ -1685,6 +1710,10 @@ static const struct drm_bridge_funcs 
tda998x_bridge_funcs = {
.atomic_disable = tda998x_bridge_atomic_disable,
.mode_set = tda998x_bridge_mode_set,
.atomic_enable = tda998x_bridge_atomic_enable,
+   .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+   .atomic_reset = drm_atomic_helper_bridge_reset,
+   .atomic_get_input_bus_fmts = tda998x_atomic_get_input_bus_fmts,
 };
 
 /* I2C driver functions */
-- 
2.25.1

[git pull] drm fixes for 5.16-rc8

2021-12-30 Thread Dave Airlie

Hi Linus (and misc maintainers),

This is a bit bigger than I'd like, however it has two weeks of amdgpu
fixes in it, since they missed last week, which was very small.

The nouveau regression is probably the biggest fix in here, and it
needs to go into 5.15 as well, two i915 fixes, and then a scattering
of amdgpu fixes. The biggest fix in there is for a fencing NULL
pointer dereference, the rest are pretty minor.

For the misc team, I've pulled the two misc fixes manually since I'm
not sure what is happening at this time of year!

The amdgpu maintainers have the outstanding runpm regression to fix
still, they are just working through the last bits of it now.

Happy New Year in advance!
Dave.

drm-fixes-2021-12-31:
drm fixes for 5.16-rc8

nouveau:
- fencing regression fix

i915:
- Fix possible uninitialized variable
- Fix composite fence seqno increment on each fence creation

amdgpu:
- Fencing fix
- XGMI fix
- VCN regression fix
- IP discovery regression fixes
- Fix runpm documentation
- Suspend/resume fixes
- Yellow Carp display fixes
- MCLK power management fix
- dma-buf fix
The following changes since commit fc74e0a40e4f9fd0468e34045b0c45bba11dcbb2:

  Linux 5.16-rc7 (2021-12-26 13:17:17 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-12-31

for you to fetch changes up to ce9b333c73a5a8707f2f446a837a6ca743ddcffd:

  Merge branch 'drm-misc-fixes' of
ssh://git.freedesktop.org/git/drm/drm-misc into drm-fixes (2021-12-31
11:40:29 +1000)


drm fixes for 5.16-rc8

nouveau:
- fencing regression fix

i915:
- Fix possible uninitialized variable
- Fix composite fence seqno icrement on each fence creation

amdgpu:
- Fencing fix
- XGMI fix
- VCN regression fix
- IP discovery regression fixes
- Fix runpm documentation
- Suspend/resume fixes
- Yellow Carp display fixes
- MCLK power management fix
- dma-buf fix


Alex Deucher (4):
  drm/amdgpu: add support for IP discovery gc_info table v2
  drm/amdgpu: fix runpm documentation
  drm/amdgpu: always reset the asic in suspend (v2)
  drm/amdgpu: no DC support for headless chips

Angus Wang (1):
  drm/amd/display: Changed pipe split policy to allow for
multi-display pipe split

Charlene Liu (1):
  drm/amd/display: fix B0 TMDS deepcolor no dislay issue

Christian König (2):
  drm/amdgpu: fix dropped backing store handling in
amdgpu_dma_buf_move_notify
  drm/nouveau: wait for the exclusive fence after the shared ones v2

Dave Airlie (3):
  Merge tag 'drm-intel-fixes-2021-12-29' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'amd-drm-fixes-5.16-2021-12-29' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
  Merge branch 'drm-misc-fixes' of
ssh://git.freedesktop.org/git/drm/drm-misc into drm-fixes

Evan Quan (1):
  drm/amdgpu: put SMU into proper state on runpm suspending for
BOCO capable platform

Huang Rui (1):
  drm/amdgpu: introduce new amdgpu_fence object to indicate the
job embedded fence

Lai, Derek (1):
  drm/amd/display: Added power down for DCN10

Lijo Lazar (1):
  drm/amd/pm: Fix xgmi link control on aldebaran

Matthew Brost (2):
  drm/i915: Fix possible uninitialized variable in parallel extension
  drm/i915: Increment composite fence seqno

Nicholas Kazlauskas (3):
  drm/amd/display: Send s0i2_rdy in stream_count == 0 optimization
  drm/amd/display: Set optimize_pwr_state for DCN31
  drm/amd/display: Fix USB4 null pointer dereference in
update_psp_stream_config

Prike Liang (1):
  drm/amd/pm: skip setting gfx cgpg in the s0ix suspend-resume

chen gong (1):
  drm/amdgpu: When the VCN(1.0) block is suspended, powergating is
explicitly enabled

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  17 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c  |  76 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  27 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  | 126 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |   4 +-
 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c  |   7 ++
 .../amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c   |   1 +
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |   5 +-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c  |   1 +
 .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c  |   2 +-
 .../drm/amd/display/dc/dcn201/dcn201_resource.c|   2 +-
 .../gpu/drm/amd/display/dc/dcn21/dcn21_resource.c  |   2 +-
 .../gpu/drm/amd/display/dc/dcn30/dcn30_resource.c  |   2 +-
 .../drm/amd/display/dc/dcn301/dcn301_resource.c|   2 +-
 .../drm/amd/display/dc/dcn302/dcn302_resource.c|   2 +-
 .../drm/amd/display/dc/dcn303/dcn303_resource.c|   2 +-
 drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c  |   1 +
 .../

Re: [git pull] drm fixes for 5.16-rc8

2021-12-30 Thread pr-tracker-bot

The pull request you sent on Fri, 31 Dec 2021 12:20:04 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-12-31

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4f3d93c6eaff6b84e43b63e0d7a119c5920e1020

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [PATCH v2 2/2] drm/msm/dp: rewrite dss_module_power to use bulk clock functions

HI,

On Wed, 29 Dec 2021 at 07:12, Bjorn Andersson
 wrote:
>
> On Thu 25 Nov 20:35 CST 2021, Dmitry Baryshkov wrote:
>
> > In order to simplify DP code, drop hand-coded loops over clock arrays,
> > replacing them with clk_bulk_* functions.
> >
>
> I've yet to debug this, but applying the two patches and attaching an
> HDMI cable to my USB dongle results in the follwing splat on the 8350
> HDK.

Intersesting. The only major difference between original code and the
patches code in this function is the removal of `if (clk_arry[i].clk)`
condition in that function. Could yyou please check whether clocks are
properly parsed at the time you receive the hpd event?

If  we can not debug this issue,  I'd then propose to merge first
patch and let somebody else rewrite dp_clk_util to use clk_bulk_data.

>
> [   39.658840] Unable to handle kernel NULL pointer dereference at virtual 
> address 
> [   39.667883] Mem abort info:
> [   39.670774]   ESR = 0x9606
> [   39.673940]   EC = 0x25: DABT (current EL), IL = 32 bits
> [   39.679417]   SET = 0, FnV = 0
> [   39.682582]   EA = 0, S1PTW = 0
> [   39.685825]   FSC = 0x06: level 2 translation fault
> [   39.690851] Data abort info:
> [   39.693838]   ISV = 0, ISS = 0x0006
> [   39.697797]   CM = 0, WnR = 0
> [   39.700864] user pgtable: 4k pages, 48-bit VAs, pgdp=00010eb8d000
> [   39.707501] [] pgd=08010f097003, p4d=08010f097003, 
> pud=08010ba58003, pmd=
> [   39.718425] Internal error: Oops: 9606 [#1] PREEMPT SMP
> [   39.724169] Modules linked in: pmic_glink_altmode qcom_pmic_glink_power 
> cfg80211 rfkill 8021q garp mrp stp llc microchip lan78xx snd_soc_hdmi_codec 
> pmic_glink pdr_interface rpmsg_char qrtr_smd qrtr fsa4480 qcom_q6v5_pas 
> qcom_pil_info i2c_qcom_geni qcom_q6v5 msm qcom_sysmon qcom_stats gpu_sched 
> crct10dif_ce drm_kms_helper qcom_common qcom_glink_smem gpucc_sm8350 
> phy_qcom_qmp mdt_loader typec ufs_qcom qmi_helpers qcom_rng socinfo 
> qnoc_sm8350 rmtfs_mem fuse drm ipv6
> [   39.766330] CPU: 0 PID: 85 Comm: kworker/0:3 Not tainted 
> 5.16.0-rc5-next-20211215-00046-g2f90133452d9 #280
> [   39.776256] Hardware name: Qualcomm Technologies, Inc. SM8350 HDK (DT)
> [   39.782969] Workqueue: events pmic_glink_altmode_worker 
> [pmic_glink_altmode]
> [   39.790235] pstate: 4045 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [   39.797393] pc : __pi_strcmp+0x1c/0xf0
> [   39.801271] lr : dp_ctrl_set_clock_rate+0x8c/0xf0 [msm]
> [   39.806737] sp : 88adbbc0
> [   39.810153] x29: 88adbbc0 x28:  x27: 
> 
> [   39.817501] x26: b60107f74270 x25: 297a49b33c80 x24: 
> 202fbf00
> [   39.824846] x23: 0001 x22: 297a4b400580 x21: 
> 0020
> [   39.832188] x20: b600e3d78068 x19:  x18: 
> 
> [   39.839541] x17: 6b6c63206e6f2030 x16: b601063476c0 x15: 
> 0720072007200720
> [   39.846893] x14: 0720072007200720 x13: b60107c622c8 x12: 
> 0765
> [   39.854229] x11: 0277 x10: 0101010101010101 x9 : 
> b60107c622c8
> [   39.861565] x8 : efff x7 :  x6 : 
> b60107cba2c8
> [   39.868902] x5 :  x4 : 297cbe8619d8 x3 : 
> 
> [   39.876240] x2 :  x1 : b600e3d78068 x0 : 
> 
> [   39.883594] Call trace:
> [   39.886124]  __pi_strcmp+0x1c/0xf0
> [   39.889638]  dp_ctrl_enable_mainlink_clocks+0x98/0x110 [msm]
> [   39.895537]  dp_ctrl_on_link+0x98/0x3f0 [msm]
> [   39.900096]  dp_display_process_hpd_high+0xa8/0x100 [msm]
> [   39.905731]  dp_display_usbpd_attention_cb+0x164/0x1a4 [msm]
> [   39.911629]  dp_hpd_oob_event+0x74/0xa4 [msm]
> [   39.916195]  dp_display_oob_hotplug_event+0x1c/0x2c [msm]
> [   39.921831]  dp_oob_hotplug_event+0x18/0x24 [msm]
> [   39.926756]  drm_connector_oob_hotplug_event+0x40/0x60 [drm]
> [   39.932686]  pmic_glink_altmode_worker+0x7c/0x194 [pmic_glink_altmode]
> [   39.939398]  process_one_work+0x1d0/0x350
> [   39.943526]  worker_thread+0x13c/0x460
> [   39.947390]  kthread+0x17c/0x190
> [   39.950722]  ret_from_fork+0x10/0x20
> [   39.954416] Code: f24008ff 540003e1 f2400807 54000241 (f8408402)
> [   39.960684] ---[ end trace  ]---
>
> Regards,
> Bjorn



-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] drm/msm/dp: rewrite dss_module_power to use bulk clock functions