[GIT PULL FOR v5.8] R-Car DU fixes

2020-06-20 Thread Laurent Pinchart
Hi Dave and Daniel,

Just one small fix for the R-Car DU driver.

The following changes since commit 8a7a3d1d0dcf2bb63dafe7275020420005e13e54:

  Merge tag 'amd-drm-fixes-5.8-2020-06-17' of 
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-06-19 10:02:30 
+1000)

are available in the Git repository at:

  git://linuxtv.org/pinchartl/media.git tags/du-fixes-20200621

for you to fetch changes up to 5f9af404eec82981c4345c9943be48422234e7ab:

  drm: rcar-du: Fix build error (2020-06-21 05:12:57 +0300)


Build fix for the R-Car DU DRM driver


Daniel Gomez (1):
  drm: rcar-du: Fix build error

 drivers/gpu/drm/rcar-du/Kconfig | 1 +
 1 file changed, 1 insertion(+)

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers

2020-06-20 Thread Laurent Pinchart
Most of the DRM drivers uAPI headers are licensed under the MIT license,
and carry copies of the license with slight variations. Replace them
with SPDX headers.

Signed-off-by: Laurent Pinchart 
---
 include/uapi/drm/amdgpu_drm.h  | 19 +--
 include/uapi/drm/i915_drm.h| 22 +-
 include/uapi/drm/mga_drm.h | 20 +---
 include/uapi/drm/msm_drm.h | 20 +---
 include/uapi/drm/nouveau_drm.h | 20 +---
 include/uapi/drm/qxl_drm.h | 20 +---
 include/uapi/drm/r128_drm.h| 20 +---
 include/uapi/drm/radeon_drm.h  | 20 +---
 include/uapi/drm/savage_drm.h  | 20 +---
 include/uapi/drm/sis_drm.h | 21 +
 include/uapi/drm/tegra_drm.h   | 19 +--
 include/uapi/drm/v3d_drm.h | 20 +---
 include/uapi/drm/vc4_drm.h | 20 +---
 include/uapi/drm/vgem_drm.h| 22 +-
 include/uapi/drm/via_drm.h | 20 +---
 include/uapi/drm/virtgpu_drm.h | 20 +---
 include/uapi/drm/vmwgfx_drm.h  | 21 +
 17 files changed, 17 insertions(+), 327 deletions(-)

diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index 4e873dcbe68f..c6adda72bec7 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: MIT */
 /* amdgpu_drm.h -- Public header for the amdgpu driver -*- linux-c -*-
  *
  * Copyright 2000 Precision Insight, Inc., Cedar Park, Texas.
@@ -5,24 +6,6 @@
  * Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas.
  * Copyright 2014 Advanced Micro Devices, Inc.
  *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
  * Authors:
  *Kevin E. Martin 
  *Gareth Hughes 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 14b67cd6b54b..c29e3acb3026 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1,27 +1,7 @@
+/* SPDX-License-Identifier: MIT */
 /*
  * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
  * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
- * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
- * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
- * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
- * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
- * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
  */
 
 #ifndef _UAPI_I915_DRM_H_
diff --git a/include/uapi/drm/mga_drm.h b/include/uapi/drm/mga_drm.h
index 8c4337548ab5..4415efefe0cf 100644
--- a/include/uapi/drm/mga_drm.h
+++ b/include/uapi/drm/mga_drm.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: MIT */
 /* mga_drm.h -- Public header for the Matrox g200/g400 driver -*- linux-c -*-
  * Created: Tue Jan 25 01:50:01 1999 by jhartm...@precisioninsight.com
  *
@@ -5,25 +6,6 @@
  * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
  * All rights reserved.
  *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of 

[PATCH 1/3] drm: uapi: Use SPDX in DRM core uAPI headers

2020-06-20 Thread Laurent Pinchart
The DRM core uAPI headers are licensed under the MIT license, and carry
copies of the license with slight variations. Replace them with SPDX
headers.

Following a discussion with Daniel Vetter on this topic, add a
clarification in the drm-uapi.rst file that independent closed-source
userspace implementations of software using the DRM uAPI are accepted,
as allowed by the MIT license.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Thomas Gleixner 
---
 Documentation/gpu/drm-uapi.rst |  4 
 include/uapi/drm/drm.h | 20 +---
 include/uapi/drm/drm_fourcc.h  | 20 +---
 include/uapi/drm/drm_mode.h| 19 +--
 include/uapi/drm/drm_sarea.h   | 20 +---
 5 files changed, 8 insertions(+), 75 deletions(-)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 56fec6ed1ad8..de2ecc76dd6c 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -107,6 +107,10 @@ is already rather painful for the DRM subsystem, with 
multiple different uAPIs
 for the same thing co-existing. If we add a few more complete mistakes into the
 mix every year it would be entirely unmanageable.
 
+The DRM subsystem has however no concern with independent closed-source
+userspace implementations. To officialize that position, the DRM uAPI headers
+are covered by the MIT license.
+
 .. _drm_render_node:
 
 Render nodes
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 808b48a93330..14d57361e580 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: MIT */
 /**
  * \file drm.h
  * Header for the Direct Rendering Manager
@@ -12,25 +13,6 @@
  * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
  * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
  * All rights reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 #ifndef _DRM_H_
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 490143500a50..d2c4a597620f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -1,24 +1,6 @@
+/* SPDX-License-Identifier: MIT */
 /*
  * Copyright 2011 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 #ifndef DRM_FOURCC_H
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 735c8cfdaaa1..c34a544fdf29 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -1,27 +1,10 @@
+/* SPDX-License-Identifier: MIT */
 /*
  * Copyright (c) 2007 Dave Airlie 
  * Copyright (c) 2007 Jakob Bornecrantz 
  * Copyright (c) 2008 Red Hat Inc.
  * Copyright (c) 2007-2008 Tungsten Graphics, Inc., Cedar Park, TX., USA
  * Copyright (c) 2007-2008 Intel Corporation
- *
- * 

[PATCH 3/3] drm: uapi: Remove copies of GPL license text from headers

2020-06-20 Thread Laurent Pinchart
Several DRM drivers uAPI headers that are licensed under the GPL carry
both an SPDX header and a copy of the license text. Drop the latter.

Signed-off-by: Laurent Pinchart 
---
 include/uapi/drm/armada_drm.h  |  4 
 include/uapi/drm/etnaviv_drm.h | 12 
 include/uapi/drm/exynos_drm.h  |  5 -
 include/uapi/drm/omap_drm.h| 12 
 4 files changed, 33 deletions(-)

diff --git a/include/uapi/drm/armada_drm.h b/include/uapi/drm/armada_drm.h
index af1c14c837c5..f711e63a9758 100644
--- a/include/uapi/drm/armada_drm.h
+++ b/include/uapi/drm/armada_drm.h
@@ -2,10 +2,6 @@
 /*
  * Copyright (C) 2012 Russell King
  *  With inspiration from the i915 driver
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 #ifndef DRM_ARMADA_IOCTL_H
 #define DRM_ARMADA_IOCTL_H
diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
index 09d0df8b71c5..e23e0f885655 100644
--- a/include/uapi/drm/etnaviv_drm.h
+++ b/include/uapi/drm/etnaviv_drm.h
@@ -1,18 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
 /*
  * Copyright (C) 2015 Etnaviv Project
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
  */
 
 #ifndef __ETNAVIV_DRM_H__
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index a51aa1c618c1..a96fa566433c 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -6,11 +6,6 @@
  * Inki Dae 
  * Joonyoung Shim 
  * Seung-Woo Kim 
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
  */
 
 #ifndef _UAPI_EXYNOS_DRM_H_
diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
index 5a142fad473c..b51dad32122d 100644
--- a/include/uapi/drm/omap_drm.h
+++ b/include/uapi/drm/omap_drm.h
@@ -4,18 +4,6 @@
  *
  * Copyright (C) 2011 Texas Instruments
  * Author: Rob Clark 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
  */
 
 #ifndef __OMAP_DRM_H__
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v7 33/36] rapidio: fix common struct sg_table related issues

2020-06-20 Thread kernel test robot
Hi Marek,

I love your patch! Perhaps something to improve:

[auto build test WARNING on next-20200618]
[also build test WARNING on v5.8-rc1]
[cannot apply to linuxtv-media/master staging/staging-testing 
drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7 
v5.7-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Marek-Szyprowski/DRM-fix-struct-sg_table-nents-vs-orig_nents-misuse/20200619-184302
base:ce2cc8efd7a40cbd17841add878cb691d0ce0bba
config: x86_64-randconfig-r005-20200621 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
ef455a55bcf2cfea04a99c361b182ad18b7f03f1)
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
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> drivers/rapidio/devices/rio_mport_cdev.c:939:40: warning: variable 'nents' 
>> is uninitialized when used here [-Wuninitialized]
ret = do_dma_request(req, xfer, sync, nents);
^
drivers/rapidio/devices/rio_mport_cdev.c:816:11: note: initialize the variable 
'nents' to silence this warning
int nents;
^
= 0
1 warning generated.

vim +/nents +939 drivers/rapidio/devices/rio_mport_cdev.c

e8de370188d098 Alexandre Bounine  2016-03-22  793  
e8de370188d098 Alexandre Bounine  2016-03-22  794  /*
e8de370188d098 Alexandre Bounine  2016-03-22  795   * rio_dma_transfer() - 
Perform RapidIO DMA data transfer to/from
e8de370188d098 Alexandre Bounine  2016-03-22  796   *  the 
remote RapidIO device
e8de370188d098 Alexandre Bounine  2016-03-22  797   * @filp: file pointer 
associated with the call
e8de370188d098 Alexandre Bounine  2016-03-22  798   * @transfer_mode: DMA 
transfer mode
e8de370188d098 Alexandre Bounine  2016-03-22  799   * @sync: synchronization 
mode
e8de370188d098 Alexandre Bounine  2016-03-22  800   * @dir: DMA transfer 
direction (DMA_MEM_TO_DEV = write OR
e8de370188d098 Alexandre Bounine  2016-03-22  801   *   
DMA_DEV_TO_MEM = read)
e8de370188d098 Alexandre Bounine  2016-03-22  802   * @xfer: data transfer 
descriptor structure
e8de370188d098 Alexandre Bounine  2016-03-22  803   */
e8de370188d098 Alexandre Bounine  2016-03-22  804  static int
4e1016dac1ccce Alexandre Bounine  2016-05-05  805  rio_dma_transfer(struct file 
*filp, u32 transfer_mode,
e8de370188d098 Alexandre Bounine  2016-03-22  806enum 
rio_transfer_sync sync, enum dma_data_direction dir,
e8de370188d098 Alexandre Bounine  2016-03-22  807struct 
rio_transfer_io *xfer)
e8de370188d098 Alexandre Bounine  2016-03-22  808  {
e8de370188d098 Alexandre Bounine  2016-03-22  809   struct mport_cdev_priv 
*priv = filp->private_data;
e8de370188d098 Alexandre Bounine  2016-03-22  810   unsigned long nr_pages 
= 0;
e8de370188d098 Alexandre Bounine  2016-03-22  811   struct page **page_list 
= NULL;
e8de370188d098 Alexandre Bounine  2016-03-22  812   struct mport_dma_req 
*req;
e8de370188d098 Alexandre Bounine  2016-03-22  813   struct mport_dev *md = 
priv->md;
e8de370188d098 Alexandre Bounine  2016-03-22  814   struct dma_chan *chan;
67446283d89467 John Hubbard   2020-06-04  815   int ret;
e8de370188d098 Alexandre Bounine  2016-03-22  816   int nents;
e8de370188d098 Alexandre Bounine  2016-03-22  817  
e8de370188d098 Alexandre Bounine  2016-03-22  818   if (xfer->length == 0)
e8de370188d098 Alexandre Bounine  2016-03-22  819   return -EINVAL;
e8de370188d098 Alexandre Bounine  2016-03-22  820   req = 
kzalloc(sizeof(*req), GFP_KERNEL);
e8de370188d098 Alexandre Bounine  2016-03-22  821   if (!req)
e8de370188d098 Alexandre Bounine  2016-03-22  822   return -ENOMEM;
e8de370188d098 Alexandre Bounine  2016-03-22  823  
e8de370188d098 Alexandre Bounine  2016-03-22  824   ret = 
get_dma_channel(priv);
e8de370188d098 Alexandre Bounine  2016-03-22  825   if (ret) {
e8de370188d098 Alexandre Bounine  2016-03-22  826   kfree(req);
e8de370188d098 Alexandre Bounine  2016-03-22  827   return ret;
e8de370188d098 Alexandre Bounine  2016-03-22  828   }
c5157b76869ba9 Ioan Nicu  2018-04-20  829   chan = priv->dmach;
c5157b76869ba9 Ioan Nicu  2018-04-20  830  
c5157b76869ba9 Ioan Nicu  2018-04-20  831   
kref_init(>refcount);
c5157b76869ba9 Ioan Nicu   

[PATCH v2 3/8] dt-bindings: media: renesas, fcp: Add resets and iommus properties

2020-06-20 Thread Laurent Pinchart
The resets and iommus properties are used in DT sources in the kernel
tree. Document them, and make resets mandatory. The iommus property is
optional as not all platforms wire the FCP to a functional IOMMU.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/media/renesas,fcp.yaml | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml 
b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
index eeca7e255420..b6cf2958e6c9 100644
--- a/Documentation/devicetree/bindings/media/renesas,fcp.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
@@ -31,14 +31,21 @@ properties:
   clocks:
 maxItems: 1
 
+  iommus:
+maxItems: 1
+
   power-domains:
 maxItems: 1
 
+  resets:
+maxItems: 1
+
 required:
   - compatible
   - reg
   - clocks
   - power-domains
+  - resets
 
 additionalProperties: false
 
@@ -53,5 +60,7 @@ examples:
 reg = <0xfea2f000 0x200>;
 clocks = < CPG_MOD 602>;
 power-domains = < R8A7795_PD_ALWAYS_ON>;
+resets = < 602>;
+iommus = <_vi0 9>;
 };
 ...
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 1/8] dt-bindings: media: renesas, fcp: Convert binding to YAML

2020-06-20 Thread Laurent Pinchart
Convert the Renesas R-Car FCP text binding to YAML.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
---
Changes since v1:

- Simplify comments on compatible strings
- Update MAINTAINERS
---
 .../devicetree/bindings/media/renesas,fcp.txt | 34 ---
 .../bindings/media/renesas,fcp.yaml   | 56 +++
 MAINTAINERS   |  2 +-
 3 files changed, 57 insertions(+), 35 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/media/renesas,fcp.txt
 create mode 100644 Documentation/devicetree/bindings/media/renesas,fcp.yaml

diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.txt 
b/Documentation/devicetree/bindings/media/renesas,fcp.txt
deleted file mode 100644
index 79c37395b396..
--- a/Documentation/devicetree/bindings/media/renesas,fcp.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Renesas R-Car Frame Compression Processor (FCP)

-
-The FCP is a companion module of video processing modules in the Renesas R-Car
-Gen3 and RZ/G2 SoCs. It provides data compression and decompression, data
-caching, and conversion of AXI transactions in order to reduce the memory
-bandwidth.
-
-There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and FCP
-for FDP (FCPF). Their configuration and behaviour depend on the module they
-are paired with. These DT bindings currently support the FCPV and FCPF.
-
- - compatible: Must be one or more of the following
-
-   - "renesas,fcpv" for generic compatible 'FCP for VSP'
-   - "renesas,fcpf" for generic compatible 'FCP for FDP'
-
- - reg: the register base and size for the device registers
- - clocks: Reference to the functional clock
-
-Optional properties:
- - power-domains : power-domain property defined with a power domain specifier
-  to respective power domain.
-
-
-Device node example

-
-   fcpvd1: fcp@fea2f000 {
-   compatible = "renesas,fcpv";
-   reg = <0 0xfea2f000 0 0x200>;
-   clocks = < CPG_MOD 602>;
-   power-domains = < R8A7795_PD_A3VP>;
-   };
diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml 
b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
new file mode 100644
index ..9241bf3c5efc
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/renesas,fcp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Frame Compression Processor (FCP)
+
+maintainers:
+  - Laurent Pinchart 
+
+description: |
+  The FCP is a companion module of video processing modules in the Renesas
+  R-Car Gen3 and RZ/G2 SoCs. It provides data compression and decompression,
+  data caching, and conversion of AXI transactions in order to reduce the
+  memory bandwidth.
+
+  There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and
+  FCP for FDP (FCPF). Their configuration and behaviour depend on the module
+  they are paired with. These DT bindings currently support the FCPV and FCPF.
+
+properties:
+  compatible:
+enum:
+  - renesas,fcpv # FCP for VSP
+  - renesas,fcpf # FCP for FDP
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  power-domains:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+
+additionalProperties: false
+
+examples:
+  # R8A7790 (R-Car H2) VSP1-S
+  - |
+#include 
+#include 
+
+fcp@fea2f000 {
+compatible = "renesas,fcpv";
+reg = <0xfea2f000 0x200>;
+clocks = < CPG_MOD 602>;
+power-domains = < R8A7795_PD_ALWAYS_ON>;
+};
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 68f21d46614c..660ed6606de2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10700,7 +10700,7 @@ L:  linux-me...@vger.kernel.org
 L: linux-renesas-...@vger.kernel.org
 S: Supported
 T: git git://linuxtv.org/media_tree.git
-F: Documentation/devicetree/bindings/media/renesas,fcp.txt
+F: Documentation/devicetree/bindings/media/renesas,fcp.yaml
 F: drivers/media/platform/rcar-fcp.c
 F: include/media/rcar-fcp.h
 
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 5/8] dt-bindings: media: renesas, fdp1: Make power-domains mandatory

2020-06-20 Thread Laurent Pinchart
All DT source files in the kernel tree specify the power-domains
property. Make it mandatory.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
---
Changes since v1:

- Fix typo in comment message
---
 Documentation/devicetree/bindings/media/renesas,fdp1.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/renesas,fdp1.yaml 
b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml
index f4db96a1f53c..39184bd21a27 100644
--- a/Documentation/devicetree/bindings/media/renesas,fdp1.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml
@@ -43,6 +43,7 @@ required:
   - reg
   - interrupts
   - clocks
+  - power-domains
 
 additionalProperties: false
 
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 4/8] dt-bindings: media: renesas, fdp1: Convert binding to YAML

2020-06-20 Thread Laurent Pinchart
Convert the Renesas R-Car FDP1 text binding to YAML.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
---
Changes since v1:

- Update MAINTAINERS
---
 .../bindings/media/renesas,fdp1.txt   | 37 ---
 .../bindings/media/renesas,fdp1.yaml  | 63 +++
 MAINTAINERS   |  2 +-
 3 files changed, 64 insertions(+), 38 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/media/renesas,fdp1.txt
 create mode 100644 Documentation/devicetree/bindings/media/renesas,fdp1.yaml

diff --git a/Documentation/devicetree/bindings/media/renesas,fdp1.txt 
b/Documentation/devicetree/bindings/media/renesas,fdp1.txt
deleted file mode 100644
index 8dd1007bb573..
--- a/Documentation/devicetree/bindings/media/renesas,fdp1.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-Renesas R-Car Fine Display Processor (FDP1)

-
-The FDP1 is a de-interlacing module which converts interlaced video to
-progressive video. It is capable of performing pixel format conversion between
-YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are supported as
-an input to the module.
-
-Required properties:
-
- - compatible: must be "renesas,fdp1"
- - reg: the register base and size for the device registers
- - interrupts : interrupt specifier for the FDP1 instance
- - clocks: reference to the functional clock
-
-Optional properties:
-
- - power-domains: reference to the power domain that the FDP1 belongs to, if
-  any.
- - renesas,fcp: a phandle referencing the FCP that handles memory accesses
-for the FDP1. Not needed on Gen2, mandatory on Gen3.
-
-Please refer to the binding documentation for the clock and/or power domain
-providers for more details.
-
-
-Device node example

-
-   fdp1@fe94 {
-   compatible = "renesas,fdp1";
-   reg = <0 0xfe94 0 0x2400>;
-   interrupts = ;
-   clocks = < CPG_MOD 119>;
-   power-domains = < R8A7795_PD_A3VP>;
-   renesas,fcp = <>;
-   };
diff --git a/Documentation/devicetree/bindings/media/renesas,fdp1.yaml 
b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml
new file mode 100644
index ..f4db96a1f53c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/renesas,fdp1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Fine Display Processor (FDP1)
+
+maintainers:
+  - Laurent Pinchart 
+
+description:
+  The FDP1 is a de-interlacing module which converts interlaced video to
+  progressive video. It is capable of performing pixel format conversion
+  between YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are
+  supported as an input to the module.
+
+properties:
+  compatible:
+enum:
+  - renesas,fdp1
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  power-domains:
+maxItems: 1
+
+  renesas,fcp:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+  A phandle referencing the FCP that handles memory accesses for the FDP1.
+  Not allowed on R-Car Gen2, mandatory on R-Car Gen3.
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+fdp1@fe94 {
+compatible = "renesas,fdp1";
+reg = <0xfe94 0x2400>;
+interrupts = ;
+clocks = < CPG_MOD 119>;
+power-domains = < R8A7795_PD_A3VP>;
+renesas,fcp = <>;
+};
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 660ed6606de2..7383dfa510a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10710,7 +10710,7 @@ L:  linux-me...@vger.kernel.org
 L: linux-renesas-...@vger.kernel.org
 S: Supported
 T: git git://linuxtv.org/media_tree.git
-F: Documentation/devicetree/bindings/media/renesas,fdp1.txt
+F: Documentation/devicetree/bindings/media/renesas,fdp1.yaml
 F: drivers/media/platform/rcar_fdp1.c
 
 MEDIA DRIVERS FOR RENESAS - VIN
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 7/8] dt-bindings: media: renesas, vsp1: Convert binding to YAML

2020-06-20 Thread Laurent Pinchart
Convert the Renesas R-Car VSP1 text binding to YAML.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
---
Changes since v1:

- Simplify comments on compatible strings
- Update MAINTAINERS
---
 .../bindings/media/renesas,vsp1.txt   | 30 ---
 .../bindings/media/renesas,vsp1.yaml  | 83 +++
 MAINTAINERS   |  2 +-
 3 files changed, 84 insertions(+), 31 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/media/renesas,vsp1.txt
 create mode 100644 Documentation/devicetree/bindings/media/renesas,vsp1.yaml

diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt 
b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
deleted file mode 100644
index cd5a955b2ea0..
--- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* Renesas VSP Video Processing Engine
-
-The VSP is a video processing engine that supports up-/down-scaling, alpha
-blending, color space conversion and various other image processing features.
-It can be found in the Renesas R-Car Gen2, R-Car Gen3, RZ/G1, and RZ/G2 SoCs.
-
-Required properties:
-
-  - compatible: Must contain one of the following values
-- "renesas,vsp1" for the R-Car Gen2 and RZ/G1 VSP1
-- "renesas,vsp2" for the R-Car Gen3 and RZ/G2 VSP2
-
-  - reg: Base address and length of the registers block for the VSP.
-  - interrupts: VSP interrupt specifier.
-  - clocks: A phandle + clock-specifier pair for the VSP functional clock.
-
-Optional properties:
-
-  - renesas,fcp: A phandle referencing the FCP that handles memory accesses
- for the VSP. Not needed on Gen2, mandatory on Gen3.
-
-
-Example: R8A7790 (R-Car H2) VSP1-S node
-
-   vsp@fe928000 {
-   compatible = "renesas,vsp1";
-   reg = <0 0xfe928000 0 0x8000>;
-   interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
-   clocks = <_clks R8A7790_CLK_VSP1_S>;
-   };
diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml 
b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
new file mode 100644
index ..65e8ee61ce90
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/renesas,vsp1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas VSP Video Processing Engine
+
+maintainers:
+  - Laurent Pinchart 
+
+description:
+  The VSP is a video processing engine that supports up-/down-scaling, alpha
+  blending, color space conversion and various other image processing features.
+  It can be found in the Renesas R-Car Gen2, R-Car Gen3, RZ/G1, and RZ/G2 SoCs.
+
+properties:
+  compatible:
+enum:
+  - renesas,vsp1 # R-Car Gen2 and RZ/G1
+  - renesas,vsp2 # R-Car Gen3 and RZ/G2
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  renesas,fcp:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+  A phandle referencing the FCP that handles memory accesses for the VSP.
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+additionalProperties: false
+
+if:
+  properties:
+compatible:
+  items:
+- const: renesas,vsp1
+then:
+  properties:
+renesas,fcp: false
+else:
+  required:
+- renesas,fcp
+
+examples:
+  # R8A7790 (R-Car H2) VSP1-S
+  - |
+#include 
+#include 
+
+vsp@fe928000 {
+compatible = "renesas,vsp1";
+reg = <0xfe928000 0x8000>;
+interrupts = ;
+clocks = < CPG_MOD 131>;
+};
+
+  # R8A77951 (R-Car H3) VSP2-BC
+  - |
+#include 
+#include 
+
+vsp@fe92 {
+compatible = "renesas,vsp2";
+reg = <0xfe92 0x8000>;
+interrupts = ;
+clocks = < CPG_MOD 624>;
+
+renesas,fcp = <>;
+};
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 7383dfa510a3..22e079cc3e3f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10730,7 +10730,7 @@ L:  linux-me...@vger.kernel.org
 L: linux-renesas-...@vger.kernel.org
 S: Supported
 T: git git://linuxtv.org/media_tree.git
-F: Documentation/devicetree/bindings/media/renesas,vsp1.txt
+F: Documentation/devicetree/bindings/media/renesas,vsp1.yaml
 F: drivers/media/platform/vsp1/
 
 MEDIA DRIVERS FOR ST STV0910 DEMODULATOR ICs
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 6/8] dt-bindings: media: renesas,fdp1: Add resets property

2020-06-20 Thread Laurent Pinchart
The resets property is used in DT sources in the kernel tree. Document
it and make it mandatory.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
---
Changes since v1:

- Fix typo in commit message
---
 Documentation/devicetree/bindings/media/renesas,fdp1.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/renesas,fdp1.yaml 
b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml
index 39184bd21a27..2a27a7296fea 100644
--- a/Documentation/devicetree/bindings/media/renesas,fdp1.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml
@@ -32,6 +32,9 @@ properties:
   power-domains:
 maxItems: 1
 
+  resets:
+maxItems: 1
+
   renesas,fcp:
 $ref: /schemas/types.yaml#/definitions/phandle
 description:
@@ -44,6 +47,7 @@ required:
   - interrupts
   - clocks
   - power-domains
+  - resets
 
 additionalProperties: false
 
@@ -59,6 +63,7 @@ examples:
 interrupts = ;
 clocks = < CPG_MOD 119>;
 power-domains = < R8A7795_PD_A3VP>;
+resets = < 119>;
 renesas,fcp = <>;
 };
 ...
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/8] dt-bindings: media: Conversion of Renesas bindings to YAML

2020-06-20 Thread Laurent Pinchart
This patch series converts the DT bindings for the Renesas R-Car FCP,
FDP1 and VSP1 to YAML. It also updates the bindings based on the
properties that have been added to the DT sources over time but never
documented.

Compared to v1, review comments have been incorporated to fix small
typos and simplify a few comments in the bindings, and MAINTAINERS has
been updated.

Rob, this series has been reviewed by Geert, could you merge it ?
Alternatively you can provide acks and I can send a pull request to get
it merged through the linux-media tree.

Laurent Pinchart (8):
  dt-bindings: media: renesas,fcp: Convert binding to YAML
  dt-bindings: media: renesas,fcp: Make power-domains mandatory
  dt-bindings: media: renesas,fcp: Add resets and iommus properties
  dt-bindings: media: renesas,fdp1: Convert binding to YAML
  dt-bindings: media: renesas,fdp1: Make power-domains mandatory
  dt-bindings: media: renesas,fdp1: Add resets property
  dt-bindings: media: renesas,vsp1: Convert binding to YAML
  dt-bindings: media: renesas,vsp1: Add power-domains and resets

 .../devicetree/bindings/media/renesas,fcp.txt | 34 ---
 .../bindings/media/renesas,fcp.yaml   | 66 +
 .../bindings/media/renesas,fdp1.txt   | 37 ---
 .../bindings/media/renesas,fdp1.yaml  | 69 +
 .../bindings/media/renesas,vsp1.txt   | 30 --
 .../bindings/media/renesas,vsp1.yaml  | 97 +++
 MAINTAINERS   |  6 +-
 7 files changed, 235 insertions(+), 104 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/media/renesas,fcp.txt
 create mode 100644 Documentation/devicetree/bindings/media/renesas,fcp.yaml
 delete mode 100644 Documentation/devicetree/bindings/media/renesas,fdp1.txt
 create mode 100644 Documentation/devicetree/bindings/media/renesas,fdp1.yaml
 delete mode 100644 Documentation/devicetree/bindings/media/renesas,vsp1.txt
 create mode 100644 Documentation/devicetree/bindings/media/renesas,vsp1.yaml

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 8/8] dt-bindings: media: renesas, vsp1: Add power-domains and resets

2020-06-20 Thread Laurent Pinchart
The power-domains and resets properties are used in all DT sources in
the kernel but are absent from the bindings. Document them and make them
mandatory.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
---
 .../devicetree/bindings/media/renesas,vsp1.yaml| 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml 
b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
index 65e8ee61ce90..990e9c1dbc43 100644
--- a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
@@ -29,6 +29,12 @@ properties:
   clocks:
 maxItems: 1
 
+  power-domains:
+maxItems: 1
+
+  resets:
+maxItems: 1
+
   renesas,fcp:
 $ref: /schemas/types.yaml#/definitions/phandle
 description:
@@ -39,6 +45,8 @@ required:
   - reg
   - interrupts
   - clocks
+  - power-domains
+  - resets
 
 additionalProperties: false
 
@@ -59,24 +67,30 @@ examples:
   - |
 #include 
 #include 
+#include 
 
 vsp@fe928000 {
 compatible = "renesas,vsp1";
 reg = <0xfe928000 0x8000>;
 interrupts = ;
 clocks = < CPG_MOD 131>;
+power-domains = < R8A7790_PD_ALWAYS_ON>;
+resets = < 131>;
 };
 
   # R8A77951 (R-Car H3) VSP2-BC
   - |
 #include 
 #include 
+#include 
 
 vsp@fe92 {
 compatible = "renesas,vsp2";
 reg = <0xfe92 0x8000>;
 interrupts = ;
 clocks = < CPG_MOD 624>;
+power-domains = < R8A7795_PD_A3VP>;
+resets = < 624>;
 
 renesas,fcp = <>;
 };
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/8] dt-bindings: media: renesas, fcp: Make power-domains mandatory

2020-06-20 Thread Laurent Pinchart
All DT source files in the kernel tree specify the power-domains
property. Make it mandatory.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
---
Changes since v1:

- Fix typo in commit message
---
 Documentation/devicetree/bindings/media/renesas,fcp.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml 
b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
index 9241bf3c5efc..eeca7e255420 100644
--- a/Documentation/devicetree/bindings/media/renesas,fcp.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
@@ -38,6 +38,7 @@ required:
   - compatible
   - reg
   - clocks
+  - power-domains
 
 additionalProperties: false
 
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 3/3] drm/bridge: ps8640: Rework power state handling

2020-06-20 Thread Sam Ravnborg
Hi Enric.

On Mon, Jun 15, 2020 at 10:53:20PM +0200, Enric Balletbo i Serra wrote:
> The get_edid() callback can be triggered anytime by an ioctl, i.e
> 
>   drm_mode_getconnector (ioctl)
> -> drm_helper_probe_single_connector_modes
>-> drm_bridge_connector_get_modes
>   -> ps8640_bridge_get_edid
> 
> Actually if the bridge pre_enable() function was not called before
> get_edid(), the driver will not be able to get the EDID properly and
> display will not work until a second get_edid() call is issued and if
> pre_enable() is called before.
Is it correct to fix this in the driver?
Why not just fail and tell user-sapce to try again later?
(Dunno what error-code to use - there must be one).

Then we avoid complicating drivers fro somethign we really should
fix in user-space.

> The side effect of this, for example, is
> that you see anything when `Frecon` starts, neither the splash screen,
that you do not see ...

(Otherwise I do not parse the above).

> until the graphical session manager starts.
> 
> To fix this we need to make sure that all we need is enabled before
> reading the EDID. This means the following:
> 
> 1. If get_edid() is called before having the device powered we need to
>power on the device. In such case, the driver will power off again the
>device.
> 
> 2. If get_edid() is called after having the device powered, all should
>just work. We added a powered flag in order to avoid recurrent calls
>to ps8640_bridge_poweron() and unneeded delays.
> 
> 3. This seems to be specific for this device, but we need to make sure
>the panel is powered on before do a power on cycle on this device.
>Otherwise the device fails to retrieve the EDID.
Step 3. looks like an ugly hack too

> 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> 
>  drivers/gpu/drm/bridge/parade-ps8640.c | 79 --
>  1 file changed, 73 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> index 9f7b7a9c53c52..ca651480891df 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -65,6 +65,7 @@ struct ps8640 {
>   struct regulator_bulk_data supplies[2];
>   struct gpio_desc *gpio_reset;
>   struct gpio_desc *gpio_powerdown;
> + bool powered;
>  };
>  
>  static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
> @@ -91,13 +92,25 @@ static int ps8640_bridge_vdo_control(struct ps8640 
> *ps_bridge,
>   return 0;
>  }
>  
> -static void ps8640_pre_enable(struct drm_bridge *bridge)
> +static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
>  {
> - struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>   struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
> + struct drm_bridge *panel;
>   unsigned long timeout;
>   int ret, status;
>  
> + if (ps_bridge->powered)
> + return;
> +
> + /*
> +  * That seems to be specific to this chip, and a weird behaviour, but
> +  * we need to call drm_panel_prepare before issuing a poweron cycle. If
> +  * we don't do this, the chip is not able to read properly the EDID.
> +  */
> + panel = ps_bridge->panel_bridge;
> + if (panel->funcs && panel->funcs->pre_enable)
> + panel->funcs->pre_enable(panel);
> +
>   ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
>   ps_bridge->supplies);
>   if (ret < 0) {
> @@ -164,6 +177,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
>   goto err_regulators_disable;
>   }
>  
> + ps_bridge->powered = true;
> +
>   return;
>  
>  err_regulators_disable:
> @@ -171,12 +186,13 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
>  ps_bridge->supplies);
>  }
>  
> -static void ps8640_post_disable(struct drm_bridge *bridge)
> +static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
>  {
> - struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> + struct drm_bridge *panel;
>   int ret;
>  
> - ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> + if (!ps_bridge->powered)
> + return;
>  
>   gpiod_set_value(ps_bridge->gpio_reset, 1);
>   gpiod_set_value(ps_bridge->gpio_powerdown, 1);
> @@ -184,6 +200,32 @@ static void ps8640_post_disable(struct drm_bridge 
> *bridge)
>ps_bridge->supplies);
>   if (ret < 0)
>   DRM_ERROR("cannot disable regulators %d\n", ret);
> +
> + panel = ps_bridge->panel_bridge;
> + if (panel->funcs && panel->funcs->post_disable)
> + panel->funcs->post_disable(panel);
> +
> + ps_bridge->powered = false;
> +}
> +
> +static void ps8640_pre_enable(struct drm_bridge *bridge)
> +{
> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> + int ret;
> +
> + ps8640_bridge_poweron(ps_bridge);
> +
> + 

Re: [RESEND PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge

2020-06-20 Thread Sam Ravnborg
Hi Enric

On Mon, Jun 15, 2020 at 10:31:01PM +0200, Enric Balletbo i Serra wrote:
> (This resend is to fix some trivial conflicts due the merge window)
> 
> The PS8640 dsi-to-eDP bridge driver is using the panel bridge API,
> however, not all the components in the chain have been ported to the
> drm_bridge API. Actually, when a panel is attached the default panel's mode
> is used, but in some cases we can't get display up if mode getting from
> eDP control EDID is not chosen.
> 
> This series address that problem, first implements the .get_edid()
> callback in the PS8640 driver (which is not used until the conversion is
> done) and then, converts the Mediatek DSI driver to use the drm_bridge
> API.
> 
> As far as I know, we're the only users of the mediatek dsi driver in
> mainline, so should be safe to switch to the new chain of drm_bridge API
> unconditionally.
> 
> The patches has been tested on a Acer Chromebook R13 (Elm) running a
> Chrome OS userspace and checking that the valid EDID mode reported by
> the bridge is selected.
> 
> Changes in v4:
> - Remove double call to drm_encoder_init(). (Chun-Kuang Hu)
> - Cleanup the encoder in mtk_dsi_unbind(). (Chun-Kuang Hu)
> 
> Changes in v3:
> - Replace s/bridge/next bridge/ for comment. (Laurent Pinchart)
> - Add the bridge.type. (Laurent Pinchart)
> - Use next_bridge field to store the panel bridge. (Laurent Pinchart)
> - Add the bridge.type field. (Laurent Pinchart)
> - This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
>   properly.
> - Move the bridge.type line to the patch that adds drm_bridge support. 
> (Laurent Pinchart)
> 
> Changes in v2:
> - Do not set connector_type for panel here. (Sam Ravnborg)
> 
> Enric Balletbo i Serra (7):
>   drm/bridge: ps8640: Get the EDID from eDP control
>   drm/bridge_connector: Set default status connected for eDP connectors
>   drm/mediatek: mtk_dsi: Rename bridge to next_bridge
>   drm/mediatek: mtk_dsi: Convert to bridge driver
>   drm/mediatek: mtk_dsi: Use simple encoder
>   drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
>   drm/mediatek: mtk_dsi: Create connector for bridges

Patch seems ready to apply. Will they be applied to a mediatek tree
or to drm-misc-next?
Or shall we take the first two patches via drm-misc-next, and the
remaning via a mediatek tree? (I hope not)

Sam


> 
>  drivers/gpu/drm/bridge/parade-ps8640.c |  12 ++
>  drivers/gpu/drm/drm_bridge_connector.c |   1 +
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 269 -
>  3 files changed, 97 insertions(+), 185 deletions(-)
> 
> -- 
> 2.27.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 3/5] drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)

2020-06-20 Thread Sam Ravnborg
Hi Ondrej et al.

On Wed, Jun 17, 2020 at 02:32:07AM +0200, Ondrej Jirman wrote:
> From: Icenowy Zheng 
> 
> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
> Xingbangda, which is used on PinePhone final assembled phones.
> 
> It is based on Sitronix ST7703 LCD controller.

I am a little late to the game here - so sorry if this has been
discussed before.
We already have panel-rocktech-jh057n00900.c which is a panle driver
based on st7703.
Why is it we need a new driver?
Would it not be better to have one st7703 driver that suipports both
panels?

The driver would need dedicated init functions depending on the panel.
But a lot could also be shared.

Sam

> 
> Add support for it.
> 
> Signed-off-by: Icenowy Zheng 
> Signed-off-by: Ondrej Jirman 
> ---
>  drivers/gpu/drm/panel/Kconfig |  10 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 535 ++
>  3 files changed, 546 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7703.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 39055c1f0e2f..b7bc157b0612 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -395,6 +395,16 @@ config DRM_PANEL_SITRONIX_ST7701
> ST7701 controller for 480X864 LCD panels with MIPI/RGB/SPI
> system interfaces.
>  
> +config DRM_PANEL_SITRONIX_ST7703
> + tristate "Sitronix ST7703 panel driver"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y here if you want to enable support for the Sitronix
> +   ST7703 controller for 720X1440 LCD panels with MIPI/RGB/SPI
> +   system interfaces.
> +
>  config DRM_PANEL_SITRONIX_ST7789V
>   tristate "Sitronix ST7789V panel"
>   depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index de74f282c433..47f4789a8685 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += 
> panel-sharp-lq101r1sx01.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
>  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
> +obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
>  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
>  obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
>  obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c 
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> new file mode 100644
> index ..dbd46b6c0b46
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -0,0 +1,535 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DRM driver for Sitronix ST7703 MIPI DSI panel
> + *
> + * Copyright (C) 2020 Ondrej Jirman 
> + * Copyright (C) 2019-2020 Icenowy Zheng 
> + *
> + * Based on panel-rocktech-jh057n00900.c, which is:
> + *   Copyright (C) Purism SPC 2019
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Manufacturer specific DCS commands */
> +#define ST7703_CMD_SETDISP   0xB2
> +#define ST7703_CMD_SETRGBIF  0xB3
> +#define ST7703_CMD_SETCYC0xB4
> +#define ST7703_CMD_SETBGP0xB5
> +#define ST7703_CMD_SETVCOM   0xB6
> +#define ST7703_CMD_SETOTP0xB7
> +#define ST7703_CMD_SETPOWER_EXT  0xB8
> +#define ST7703_CMD_SETEXTC   0xB9
> +#define ST7703_CMD_SETMIPI   0xBA
> +#define ST7703_CMD_SETVDC0xBC
> +#define ST7703_CMD_UNK_BF0xBF
> +#define ST7703_CMD_SETSCR0xC0
> +#define ST7703_CMD_SETPOWER  0xC1
> +#define ST7703_CMD_UNK_C60xC6
> +#define ST7703_CMD_SETPANEL  0xCC
> +#define ST7703_CMD_RDID1 0xDA
> +#define ST7703_CMD_RDID2 0xDB
> +#define ST7703_CMD_RDID3 0xDC
> +#define ST7703_CMD_SETGAMMA  0xE0
> +#define ST7703_CMD_SETEQ 0xE3
> +#define ST7703_CMD_SETGIP1   0xE9
> +#define ST7703_CMD_SETGIP2   0xEA
> +
> +struct st7703_panel_desc {
> + const struct drm_display_mode *mode;
> + unsigned int lanes;
> + unsigned long flags;
> + enum mipi_dsi_pixel_format format;
> + const char *const *supply_names;
> + unsigned int num_supplies;
> +};
> +
> +struct st7703 {
> + struct device *dev;
> + struct drm_panel panel;
> + struct gpio_desc *reset_gpio;
> + struct regulator_bulk_data *supplies;
> + const struct st7703_panel_desc *desc;
> + bool prepared;
> +};
> +
> +static inline struct st7703 *panel_to_st7703(struct drm_panel *panel)
> +{
> + return container_of(panel, struct st7703, panel);
> +}
> +
> +#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
> +

Re: [PATCH v2 2/4] drm/ast: Remove test for device from ast_pm_freeze()

2020-06-20 Thread Sam Ravnborg
On Wed, Jun 17, 2020 at 10:03:38AM +0200, Thomas Zimmermann wrote:
> The driver cannot suspend before it has loaded completely. So the test
> for device pointers is not required. Remove them.
> 
> Signed-off-by: Thomas Zimmermann 
Sounds resonable.
Acked-by: Sam Ravnborg 

> ---
>  drivers/gpu/drm/ast/ast_drv.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> index f7a14e4e1df0..0b58f7aee6b0 100644
> --- a/drivers/gpu/drm/ast/ast_drv.c
> +++ b/drivers/gpu/drm/ast/ast_drv.c
> @@ -188,9 +188,6 @@ static int ast_pm_freeze(struct device *dev)
>  {
>   struct pci_dev *pdev = to_pci_dev(dev);
>   struct drm_device *ddev = pci_get_drvdata(pdev);
> -
> - if (!ddev || !ddev->dev_private)
> - return -ENODEV;
>   return ast_drm_freeze(ddev);
>  }
>  
> -- 
> 2.27.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v7 31/36] staging: tegra-vde: fix common struct sg_table related issues

2020-06-20 Thread kernel test robot
Hi Marek,

I love your patch! Yet something to improve:

[auto build test ERROR on next-20200618]
[also build test ERROR on v5.8-rc1]
[cannot apply to linuxtv-media/master staging/staging-testing 
drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7 
v5.7-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Marek-Szyprowski/DRM-fix-struct-sg_table-nents-vs-orig_nents-misuse/20200619-184302
base:ce2cc8efd7a40cbd17841add878cb691d0ce0bba
config: c6x-allyesconfig (attached as .config)
compiler: c6x-elf-gcc (GCC) 9.3.0
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
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=c6x 

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

All errors (new ones prefixed by >>):

   drivers/staging/media/tegra-vde/iommu.c: In function 'tegra_vde_iommu_map':
>> drivers/staging/media/tegra-vde/iommu.c:39:9: error: implicit declaration of 
>> function 'iommu_map_sgtable'; did you mean 'dma_map_sgtable'? 
>> [-Werror=implicit-function-declaration]
  39 |  size = iommu_map_sgtable(vde->domain, addr, sgt,
 | ^
 | dma_map_sgtable
   cc1: some warnings being treated as errors

vim +39 drivers/staging/media/tegra-vde/iommu.c

18  
19  int tegra_vde_iommu_map(struct tegra_vde *vde,
20  struct sg_table *sgt,
21  struct iova **iovap,
22  size_t size)
23  {
24  struct iova *iova;
25  unsigned long shift;
26  unsigned long end;
27  dma_addr_t addr;
28  
29  end = vde->domain->geometry.aperture_end;
30  size = iova_align(>iova, size);
31  shift = iova_shift(>iova);
32  
33  iova = alloc_iova(>iova, size >> shift, end >> shift, 
true);
34  if (!iova)
35  return -ENOMEM;
36  
37  addr = iova_dma_addr(>iova, iova);
38  
  > 39  size = iommu_map_sgtable(vde->domain, addr, sgt,
40   IOMMU_READ | IOMMU_WRITE);
41  if (!size) {
42  __free_iova(>iova, iova);
43  return -ENXIO;
44  }
45  
46  *iovap = iova;
47  
48  return 0;
49  }
50  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/4] drm/bridge: ti-sn65dsi86: Don't compile GPIO bits if not CONFIG_OF_GPIO

2020-06-20 Thread Linus Walleij
On Mon, Jun 8, 2020 at 7:48 PM Douglas Anderson  wrote:

> The kernel test robot noted that if "OF" is defined (which is needed
> to select DRM_TI_SN65DSI86 at all) but not OF_GPIO that we'd get
> compile failures because some of the members that we access in "struct
> gpio_chip" are only defined "#if defined(CONFIG_OF_GPIO)".
>
> All the GPIO bits in the driver are all nicely separated out.  We'll
> guard them with the same "#if defined" that the header has and add a
> little stub function if OF_GPIO is not defined.
>
> Fixes: 27ed2b3f22ed ("drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux")
> Reported-by: kernel test robot 
> Signed-off-by: Douglas Anderson 

Fair enough,
Reviewed-by: Linus Walleij 

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 0/4] dt-bindings: display: ti,tfp410.txt: convert to yaml

2020-06-20 Thread Sam Ravnborg
Hi Ricardo.

On Wed, Jun 17, 2020 at 11:46:29AM +0200, Ricardo Cañuelo wrote:
> This series converts the DT binding for the TI TFP410 DPI-to-DVI encoder
> to json-schema.
> 
> It also fixes a minor bug in the ti-tfp410 driver that causes a
> wrong calculation of the setup and hold times when the de-skew feature
> is enabled. The retrieval of the de-skew value from the DT has also been
> updated to reflect the binding changes.
> 
> Changes in v4:
> 
>   - ti,tfp410.yaml:
> - "ports" node set back as required (Laurent Pinchart). This means
>   that dove-sbc-a510.dts will not comply with the binding and will
>   have to be fixed at some point.
> 
> The bindings have been tested with:
> 
>   make dt_binding_check ARCH= DT_SCHEMA_FILES=<...ti,tfp410.yaml>
>   make dtbs_check ARCH= DT_SCHEMA_FILES=<...ti,tfp410.yaml>
> 
> for  = arm and arm64.
> This uncovered a number of dts files that use the TFP410 but not through
> I2C and don't define the ti,deskew property. These should also be fixed.
> 
> Ricardo Cañuelo (4):
>   dt-bindings: display: ti,tfp410.txt: convert to yaml
>   dt-bindings: display: ti,tfp410.yaml: Redefine ti,deskew property
>   drm/bridge: tfp410: fix de-skew value retrieval from DT
>   drm/bridge: tfp410: Fix setup and hold time calculation

Thanks for following up and this.
Applied to drm-misc-next.

Sam

> 
>  .../bindings/display/bridge/ti,tfp410.txt |  66 -
>  .../bindings/display/bridge/ti,tfp410.yaml| 131 ++
>  drivers/gpu/drm/bridge/ti-tfp410.c|  10 +-
>  3 files changed, 136 insertions(+), 71 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
> 
> -- 
> 2.18.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 208179] [amdgpu] black screen after exiting X

2020-06-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208179

Shlomo (shl...@fastmail.com) changed:

   What|Removed |Added

 Kernel Version|5.7.2   |5.7.2,5.7.4,5.8-rc1

--- Comment #1 from Shlomo (shl...@fastmail.com) ---
Arch Linux 5.7.4-arch1-1 is still bad.
Linux v5.8-rc1 is still bad.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 3/3] drm/bridge: Introduce LT9611 DSI to HDMI bridge

2020-06-20 Thread Sam Ravnborg
Hi Vinod.

Looks good but some some of small nits.
And a few larger things in the following.
The larger things is releated to prepare the bridge driver to live in a
world with chained bridges.

Sam

On Wed, Jun 17, 2020 at 04:29:50PM +0530, Vinod Koul wrote:
> Lontium Lt9611 is a DSI to HDMI bridge which supports two DSI ports and
> I2S port as an input and HDMI port as output
> 
> Co-developed-by: Bjorn Andersson 
> Signed-off-by: Bjorn Andersson 
> Co-developed-by: Srinivas Kandagatla 
> Signed-off-by: Srinivas Kandagatla 
> Signed-off-by: Vinod Koul 
> ---
>  drivers/gpu/drm/bridge/Kconfig  |   13 +
>  drivers/gpu/drm/bridge/Makefile |1 +
>  drivers/gpu/drm/bridge/lontium-lt9611.c | 1219 +++
>  3 files changed, 1233 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 43271c21d3fc..c7f0dacfb57a 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
> on ARM-based platforms. Saying Y here when this driver is not needed
> will not cause any issue.
>  
> +config DRM_LONTIUM_LT9611
> + tristate "Lontium LT9611 DSI/HDMI bridge"
> + select SND_SOC_HDMI_CODEC if SND_SOC
> + depends on OF
> + select DRM_PANEL_BRIDGE
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + help
> +   Driver for Lontium LT9611 DSI to HDMI bridge
> +   chip driver that converts dual DSI and I2S to
> +   HDMI signals
> +   Please say Y if you have such hardware.
> +
>  config DRM_LVDS_CODEC
>   tristate "Transparent LVDS encoders and decoders support"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index d63d4b7e4347..7d7c123a95e4 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -2,6 +2,7 @@
>  obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
>  obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
>  obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
> +obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
>  obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
>  obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
> megachips-stdp-ge-b850v3-fw.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c 
> b/drivers/gpu/drm/bridge/lontium-lt9611.c
> new file mode 100644
> index ..c38f89f28651
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
> @@ -0,0 +1,1219 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2019-2020. Linaro Limited.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
Please add empty lines between each group of includes.
They are already sorted within each group and in preferred order - good.

> +
> +#define EDID_SEG_SIZE256
> +#define EDID_LEN 32
> +#define EDID_LOOP8
> +#define KEY_DDC_ACCS_DONE 0x02
> +#define DDC_NO_ACK   0x50
> +
> +#define LT9611_4LANES0
> +
> +struct lt9611 {
> + struct device *dev;
> + struct drm_bridge bridge;
> + struct drm_connector connector;
> +
> + struct regmap *regmap;
> +
> + struct device_node *dsi0_node;
> + struct device_node *dsi1_node;
> + struct mipi_dsi_device *dsi0;
> + struct mipi_dsi_device *dsi1;
> + struct platform_device *audio_pdev;
> +
> + bool ac_mode;
> +
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *enable_gpio;
> +
> + bool power_on;
> + bool sleep;
> +
> + struct regulator_bulk_data supplies[2];
> +
> + struct i2c_client *client;
> +
> + enum drm_connector_status status;
> +
> + u8 edid_buf[EDID_SEG_SIZE];
> + u32 vic;
> +};
> +
> +#define LT9611_PAGE_CONTROL  0xff
> +
> +static const struct regmap_range_cfg lt9611_ranges[] = {
> + {
> + .name = "register_range",
> + .range_min =  0,
> + .range_max = 0x85ff,
> + .selector_reg = LT9611_PAGE_CONTROL,
> + .selector_mask = 0xff,
> + .selector_shift = 0,
> + .window_start = 0,
> + .window_len = 0x100,
> + },
> +};
> +
> +static const struct regmap_config lt9611_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = 0x,
> + .ranges = lt9611_ranges,
> + .num_ranges = ARRAY_SIZE(lt9611_ranges),
> +};
> +
> +struct lt9611_mode {
> + u16 hdisplay;
> + u16 vdisplay;
> + u8 vrefresh;
> + u8 lanes;
> + u8 intfs;
> +};
> +
> +static struct lt9611_mode lt9611_modes[] = {
> + { 3840, 2160, 30, 4, 2 }, /* 3840x2160 24bit 30Hz 4Lane 2ports */
> + { 1920, 1080, 60, 4, 1 }, 

Re: [PATCH] drm/msm/dpu: Fix usage of ERR_PTR()

2020-06-20 Thread Rob Clark
On Sat, Jun 20, 2020 at 3:26 AM Zenghui Yu  wrote:
>
> ping for this obvious fix...

Hi, thanks, but there is already a similar fix in msm-next:

commit aa472721c8dbe1713cf510f56ffbc56ae9e14247
Refs: v5.7-rc5-33-gaa472721c8db
Author: Chen Tao 
AuthorDate: Mon Jun 8 09:48:59 2020 +0800
Commit: Rob Clark 
CommitDate: Thu Jun 11 20:07:21 2020 -0700

drm/msm/dpu: fix error return code in dpu_encoder_init

Fix to return negative error code -ENOMEM with the use of
ERR_PTR from dpu_encoder_init.

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Chen Tao 
Signed-off-by: Rob Clark 


BR,
-R

>
> On 2020/5/28 21:08, Zenghui Yu wrote:
> > ERR_PTR() is used in the kernel to encode an usual *negative* errno code
> > into a pointer.  Passing a positive value (ENOMEM) to it will break the
> > following IS_ERR() check.
> >
> > Though memory allocation is unlikely to fail, it's still worth fixing.
> > And grepping shows that this is the only misuse of ERR_PTR() in kernel.
> >
> > Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
> > Signed-off-by: Zenghui Yu 
> > ---
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > index a1b79ee2bd9d..a2f6b688a976 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > @@ -2173,7 +2173,7 @@ struct drm_encoder *dpu_encoder_init(struct 
> > drm_device *dev,
> >
> >   dpu_enc = devm_kzalloc(dev->dev, sizeof(*dpu_enc), GFP_KERNEL);
> >   if (!dpu_enc)
> > - return ERR_PTR(ENOMEM);
> > + return ERR_PTR(-ENOMEM);
> >
> >   rc = drm_encoder_init(dev, _enc->base, _encoder_funcs,
> >   drm_enc_mode, NULL);
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v8 7/7] drm/panel-simple: Add missing connector type for some panels

2020-06-20 Thread Sam Ravnborg
Hi Dmitry
On Sat, Jun 20, 2020 at 06:05:37PM +0300, Dmitry Osipenko wrote:
> 20.06.2020 17:31, Sam Ravnborg пишет:
> > Hi Dmitry
> > 
> >>
> >> Oops! Good catch!
> > Yep, thanks Laurent. Should have taken a better look before applying.
> > 
> >> Indeed, I blindly set the LVDS type to all these
> >> panels. Please revert this patch, I'll double check each panel and
> >> prepare an updated version of this patch. Thank you very much for the
> >> review!
> > 
> > If you can prepare a fix within a few days then lets wait for that.
> > I will do a better review next time.
> 
> Hello Sam,
> 
> I should be able to make it later today or tomorrow. Could you please
> clarify what do you mean by the fix, do you what it to be as an
> additional patch on top of the applied one or a new version of the patch?
An additional patch on top of the one applied.
It shall carry a proper fixes: tag like this:

Fixes: 94f07917ebe8 ("drm/panel-simple: Add missing connector type for some 
panels")
Cc: Dmitry Osipenko 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Cc: dri-devel@lists.freedesktop.org

Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3] drm/amd: Fix memory leak according to error branch

2020-06-20 Thread Felix Kuehling

Am 2020-06-20 um 9:21 a.m. schrieb Julia Lawall:
>
> On Sat, 20 Jun 2020, Markus Elfring wrote:
>
>>> The function kobject_init_and_add alloc memory like:
>>> kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
>>> ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
>>> ->kmalloc_slab, in err branch this memory not free. If use
>>> kmemleak, this path maybe catched.
>>> These changes are to add kobject_put in kobject_init_and_add
>>> failed branch, fix potential memleak.
>> …
>>> Changes since V2:
>>> *remove duplicate kobject_put in kfd_procfs_init.
>> Under which circumstances are going to improve this change description 
>> accordingly?
> Bernard, please update the log message as well.  The mail you sent was
> much more clear, but mail just gets lost over time.  The log message
> itself should be improved.

Hi all,

The behaviour of kobject_init_and_add is documented in the kernel
source: https://elixir.bootlin.com/linux/v5.7.2/source/lib/kobject.c#L459:

* If this function returns an error, kobject_put() must be called to
* properly clean up the memory associated with the object. This is the
* same type of error handling after a call to kobject_add() and kobject
* lifetime rules are the same here.

No need to have a complicated explanation with a call stack in the
change description. Just point to the kernel documentation.

Regards,
  Felix


>
> julia
>
>> Would you like to add the tag “Fixes” to the commit message?
>>
>> Regards,
>> Markus
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v8 7/7] drm/panel-simple: Add missing connector type for some panels

2020-06-20 Thread Sam Ravnborg
Hi Dmitry

> 
> Oops! Good catch!
Yep, thanks Laurent. Should have taken a better look before applying.

> Indeed, I blindly set the LVDS type to all these
> panels. Please revert this patch, I'll double check each panel and
> prepare an updated version of this patch. Thank you very much for the
> review!

If you can prepare a fix within a few days then lets wait for that.
I will do a better review next time.

Sam

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 199475] AMDGPU Failed to blank

2020-06-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=199475

DCWizard (andrea...@protonmail.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume

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

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

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

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

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

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

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

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 80d0f9c64f9d..4f3d60ce9929 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -123,25 +123,31 @@ static inline void pwm_lpss_cond_enable(struct pwm_device 
*pwm, bool cond)
pwm_lpss_write(pwm, pwm_lpss_read(pwm) | PWM_ENABLE);
 }
 
-static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
- const struct pwm_state *state)
+static int __pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+   const struct pwm_state *state, bool from_resume)
 {
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
int ret;
 
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
-   pm_runtime_get_sync(chip->dev);
+   if (!from_resume)
+   pm_runtime_get_sync(chip->dev);
+
ret = pwm_lpss_is_updating(pwm);
if (ret) {
-   pm_runtime_put(chip->dev);
+   if (!from_resume)
+   pm_runtime_put(chip->dev);
+
return ret;
}
pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, 
state->period);
pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
ret = pwm_lpss_wait_for_update(pwm);
if (ret) {
-   pm_runtime_put(chip->dev);
+   if (!from_resume)
+   pm_runtime_put(chip->dev);
+
return ret;
}
pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
@@ -154,12 +160,20 @@ static int pwm_lpss_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
-   pm_runtime_put(chip->dev);
+
+   if (!from_resume)
+   pm_runtime_put(chip->dev);
}
 
return 0;
 }
 
+static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+   return __pwm_lpss_apply(chip, pwm, state, false);
+}
+
 static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
   struct pwm_state 

[PATCH v3 06/15] pwm: crc: Fix period / duty_cycle times being off by a factor of 256

2020-06-20 Thread Hans de Goede
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.

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

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

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

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

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

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

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

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 01/15] ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase

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

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

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

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

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

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

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

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 03/15] pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()

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

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

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

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

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

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 10/15] pwm: crc: Implement apply() method to support the new atomic PWM API

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

Signed-off-by: Hans de Goede 
---
Changes in v3:
- Keep crc_pwm_calc_clk_div() helper to avoid needless churn
---
 drivers/pwm/pwm-crc.c | 89 ++-
 1 file changed, 53 insertions(+), 36 deletions(-)

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 08/15] pwm: crc: Fix period changes not having any effect

2020-06-20 Thread Hans de Goede
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register

I strongly suspect that the BACKLIGHT_EN register at address 0x51 really
controls a separate output-only GPIO which is connected to the LCD panels
backlight-enable input. Like how the PANEL_EN register at address 0x52
controls an output-only GPIO which is earmarked for the LCD panel's
enable pin. If this is correct then this GPIO should really be added to
the gpio-crystalcove.c driver and the PWM driver should stop poking it.
But I've been unable to come up with a definitive answer here, so I'm
keeping this as is for now.

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

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

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

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

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 14/15] drm/i915: panel: Honor the VBT PWM min setting for devs with an external PWM controller

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

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

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

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 07/15] pwm: crc: Fix off-by-one error in the clock-divider calculations

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

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

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

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

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 09/15] pwm: crc: Enable/disable PWM output on enable/disable

2020-06-20 Thread Hans de Goede
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register

So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set it again on re-enable.

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

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 15/15] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller

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

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

Signed-off-by: Hans de Goede 
---
 .../drm/i915/display/intel_display_types.h|  3 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 73 +--
 2 files changed, 37 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index de32f9efb120..4bd9981e70a1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -223,7 +224,7 @@ struct intel_panel {
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
-   int pwm_period_ns;
+   struct pwm_state pwm_state;
 
/* DPCD backlight */
u8 pwmgen_bit_count;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index cb28b9908ca4..a0f76343f381 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -592,10 +592,11 @@ static u32 bxt_get_backlight(struct intel_connector 
*connector)
 static u32 pwm_get_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = >panel;
-   int duty_ns;
+   int duty_ns, period_ns;
 
duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
-   return DIV_ROUND_UP(duty_ns * 100, panel->backlight.pwm_period_ns);
+   period_ns = pwm_get_period(panel->backlight.pwm);
+   return DIV_ROUND_UP(duty_ns * 100, period_ns);
 }
 
 static void lpt_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
@@ -669,10 +670,10 @@ static void bxt_set_backlight(const struct 
drm_connector_state *conn_state, u32
 static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
 {
struct intel_panel *panel = 
_intel_connector(conn_state->connector)->panel;
-   int duty_ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
 
-   pwm_config(panel->backlight.pwm, duty_ns,
-  panel->backlight.pwm_period_ns);
+   panel->backlight.pwm_state.duty_cycle =
+   DIV_ROUND_UP(level * panel->backlight.pwm_state.period, 100);
+   pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
 }
 
 static void
@@ -841,10 +842,8 @@ static void pwm_disable_backlight(const struct 
drm_connector_state *old_conn_sta
struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
struct intel_panel *panel = >panel;
 
-   /* Disable the backlight */
-   intel_panel_actually_set_backlight(old_conn_state, 0);
-   usleep_range(2000, 3000);
-   pwm_disable(panel->backlight.pwm);
+   panel->backlight.pwm_state.enabled = false;
+   pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
 }
 
 void intel_panel_disable_backlight(const struct drm_connector_state 
*old_conn_state)
@@ -1176,9 +1175,14 @@ static void pwm_enable_backlight(const struct 
intel_crtc_state *crtc_state,
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_panel *panel = >panel;
+   int level = panel->backlight.level;
 
-   pwm_enable(panel->backlight.pwm);
-   intel_panel_actually_set_backlight(conn_state, panel->backlight.level);
+   level = intel_panel_compute_brightness(connector, level);
+
+   panel->backlight.pwm_state.duty_cycle =
+   DIV_ROUND_UP(level * panel->backlight.pwm_state.period, 100);
+   panel->backlight.pwm_state.enabled = true;
+   pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
 }
 
 static void __intel_panel_enable_backlight(const struct intel_crtc_state 
*crtc_state,
@@ -1897,8 +1901,7 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_panel *panel = >panel;
const char *desc;
-   u32 level, ns;
-   int retval;
+   u32 level;
 
/* Get the right PWM chip for DSI backlight according to VBT */
if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {
@@ -1916,36 +1919,30 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
return -ENODEV;
}
 
-   panel->backlight.pwm_period_ns = NSEC_PER_SEC /
-get_vbt_pwm_freq(dev_priv);
-
-   /*
-* FIXME: pwm_apply_args() should be removed when switching to
-* the atomic PWM API.
-*/
-   

[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value

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

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

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

base_unit &= (base_unit_range - 1);

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

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

Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Signed-off-by: Hans de Goede 
---
Changes in v3:
- Change upper limit of clamp to (base_unit_range - 1)
- Add Fixes tag
---
 drivers/pwm/pwm-lpss.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 13/15] drm/i915: panel: Honor the VBT PWM frequency for devs with an external PWM controller

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

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

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

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

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

This is important because:

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

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

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

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

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

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

[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation)

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

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

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

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

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

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

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

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

There are a number of possible solutions to this problem:

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

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

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

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

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

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

[PATCH v3 11/15] pwm: crc: Implement get_state() method

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

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

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 12/15] drm/i915: panel: Add get_vbt_pwm_freq() helper

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

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

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

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 00/15] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

2020-06-20 Thread Hans de Goede
Hi All,

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

Initially the plan was for this series to consist of 2 parts:
1. convert the pwm-crc driver to support the atomic PWM API and
2. convert the i915 driver's PWM code to use the atomic PWM API.

But during testing I've found a number of bugs in the pwm-lpss and I
found that the acpi_lpss code needs some special handling because of
some ugliness found in most Cherry Trail DSDTs.

So now this series has grown somewhat large and consists of 4 parts:

1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness
2. various fixes to the pwm-lpss driver
3. convert the pwm-crc driver to support the atomic PWM API and
4. convert the i915 driver's PWM code to use the atomic PWM API

So we need to discuss how to merge this (once it passes review).
Although the inter-dependencies are only runtime I still think we should
make sure that 1-3 are in the drm-intel-next-queued (dinq) tree before
merging the i915 changes. Both to make sure that the intel-gfx CI system
does not become unhappy and for bisecting reasons.

The involved acpi_lpss and pwm drivers do not see a whole lot of churn, so
it likely is the easiest to just merge everything through dinq.

Rafael and Thierry, can I get your Acked-by for directly merging this into
dinq?

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

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

Changelog:

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

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

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v8 7/7] drm/panel-simple: Add missing connector type for some panels

2020-06-20 Thread Laurent Pinchart
Hi Sam and Dmitry,

On Sat, Jun 20, 2020 at 01:21:32PM +0200, Sam Ravnborg wrote:
> On Thu, Jun 18, 2020 at 01:27:03AM +0300, Dmitry Osipenko wrote:
> > The DRM panel bridge core requires connector type to be set up properly,
> > otherwise it rejects the panel. The missing connector type problem popped
> > up while I was trying to wrap CLAA070WP03XG panel into a DRM bridge in
> > order to test whether panel's rotation property work properly using
> > panel-simple driver on NVIDIA Tegra30 Nexus 7 tablet device, which uses
> > CLAA070WP03XG display panel.
> > 
> > The NVIDIA Tegra DRM driver recently gained DRM bridges support for the
> > RGB output and now driver wraps directly-connected panels into DRM bridge.
> > Hence all panels should have connector type set properly now, otherwise
> > the panel's wrapping fails.
> > 
> > This patch adds missing connector types for the LVDS panels that are found
> > on NVIDIA Tegra devices:
> > 
> >   1. AUO B101AW03
> >   2. Chunghwa CLAA070WP03XG
> >   3. Chunghwa CLAA101WA01A
> >   4. Chunghwa CLAA101WB01
> >   5. EDT ET057090DHU
> >   6. Innolux N156BGE L21
> >   7. Samsung LTN101NT05
> > 
> > Signed-off-by: Dmitry Osipenko 
> 
> Very good to have this fixed.
> I went ahead and pushed this commit to drm-misc-next as it is really
> independent from the rest of the series.
> 
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 6764ac630e22..9eb2dbb7bfa6 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -687,6 +687,7 @@ static const struct panel_desc auo_b101aw03 = {
> > .width = 223,
> > .height = 125,
> > },
> > +   .connector_type = DRM_MODE_CONNECTOR_LVDS,

Note that, for LVDS panels, the bus_format field is mandatory. This
panel, for instance, according to
http://www.vslcd.com/Specification/B101AW03%20V.0.pdf, uses
MEDIA_BUS_FMT_RGB666_1X7X3_SPWG (see
https://linuxtv.org/downloads/v4l-dvb-apis/userspace-api/v4l/subdev-formats.html#v4l2-mbus-pixelcode).
The panels below need to be investigated similarly.

> >  };
> >  
> >  static const struct display_timing auo_b101ean01_timing = {
> > @@ -1340,6 +1341,7 @@ static const struct panel_desc chunghwa_claa070wp03xg 
> > = {
> > .width = 94,
> > .height = 150,
> > },
> > +   .connector_type = DRM_MODE_CONNECTOR_LVDS,
> >  };
> >  
> >  static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
> > @@ -1362,6 +1364,7 @@ static const struct panel_desc chunghwa_claa101wa01a 
> > = {
> > .width = 220,
> > .height = 120,
> > },
> > +   .connector_type = DRM_MODE_CONNECTOR_LVDS,
> >  };
> >  
> >  static const struct drm_display_mode chunghwa_claa101wb01_mode = {
> > @@ -1384,6 +1387,7 @@ static const struct panel_desc chunghwa_claa101wb01 = 
> > {
> > .width = 223,
> > .height = 125,
> > },
> > +   .connector_type = DRM_MODE_CONNECTOR_LVDS,
> >  };
> >  
> >  static const struct drm_display_mode dataimage_scf0700c48ggu18_mode = {
> > @@ -1573,6 +1577,7 @@ static const struct panel_desc edt_et057090dhu = {
> > },
> > .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
> > +   .connector_type = DRM_MODE_CONNECTOR_LVDS,

This contradicts .bus_format and .bus_flags that hint that the panel is
a DPI panel, not an LVDS panel. According to
https://www.lcdtek.co.uk/dwpdf/ET057090DHU-RoHS.pdf, this isn't an LVDS
panel.

I'm worried enough research hasn't gone into this patch, and I'd prefer
reverting it until we check each panel individually.

> >  };
> >  
> >  static const struct drm_display_mode edt_etm0700g0dh6_mode = {
> > @@ -2055,6 +2060,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
> > .width = 344,
> > .height = 193,
> > },
> > +   .connector_type = DRM_MODE_CONNECTOR_LVDS,
> >  };
> >  
> >  static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
> > @@ -3001,6 +3007,7 @@ static const struct panel_desc samsung_ltn101nt05 = {
> > .width = 223,
> > .height = 125,
> > },
> > +   .connector_type = DRM_MODE_CONNECTOR_LVDS,
> >  };
> >  
> >  static const struct drm_display_mode samsung_ltn140at29_301_mode = {

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH][next] fbdev/fb.h: Use struct_size() helper in kzalloc()

2020-06-20 Thread Sam Ravnborg
Hi Gustavo.

On Wed, Jun 17, 2020 at 12:56:47PM -0500, Gustavo A. R. Silva wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
> 
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
> 
> Signed-off-by: Gustavo A. R. Silva 

struct_size is defined in overflow.h - which is not included by fs.h.
So we rely on overflow.h being pulled in by some other header - maybe
slab.h in this case.
Seems fragile, should this patch add an include of overflow.h?

Sam

> ---
>  include/linux/fb.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 3b4b2f0c6994..2b530e6d86e4 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -506,8 +506,9 @@ struct fb_info {
>  };
>  
>  static inline struct apertures_struct *alloc_apertures(unsigned int max_num) 
> {
> - struct apertures_struct *a = kzalloc(sizeof(struct apertures_struct)
> - + max_num * sizeof(struct aperture), GFP_KERNEL);
> + struct apertures_struct *a;
> +
> + a = kzalloc(struct_size(a, ranges, max_num), GFP_KERNEL);
>   if (!a)
>   return NULL;
>   a->count = max_num;
> -- 
> 2.27.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v8 7/7] drm/panel-simple: Add missing connector type for some panels

2020-06-20 Thread Sam Ravnborg
Hi Dmitry

On Thu, Jun 18, 2020 at 01:27:03AM +0300, Dmitry Osipenko wrote:
> The DRM panel bridge core requires connector type to be set up properly,
> otherwise it rejects the panel. The missing connector type problem popped
> up while I was trying to wrap CLAA070WP03XG panel into a DRM bridge in
> order to test whether panel's rotation property work properly using
> panel-simple driver on NVIDIA Tegra30 Nexus 7 tablet device, which uses
> CLAA070WP03XG display panel.
> 
> The NVIDIA Tegra DRM driver recently gained DRM bridges support for the
> RGB output and now driver wraps directly-connected panels into DRM bridge.
> Hence all panels should have connector type set properly now, otherwise
> the panel's wrapping fails.
> 
> This patch adds missing connector types for the LVDS panels that are found
> on NVIDIA Tegra devices:
> 
>   1. AUO B101AW03
>   2. Chunghwa CLAA070WP03XG
>   3. Chunghwa CLAA101WA01A
>   4. Chunghwa CLAA101WB01
>   5. EDT ET057090DHU
>   6. Innolux N156BGE L21
>   7. Samsung LTN101NT05
> 
> Signed-off-by: Dmitry Osipenko 

Very good to have this fixed.
I went ahead and pushed this commit to drm-misc-next as it is really
independent from the rest of the series.

Sam

> ---
>  drivers/gpu/drm/panel/panel-simple.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 6764ac630e22..9eb2dbb7bfa6 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -687,6 +687,7 @@ static const struct panel_desc auo_b101aw03 = {
>   .width = 223,
>   .height = 125,
>   },
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct display_timing auo_b101ean01_timing = {
> @@ -1340,6 +1341,7 @@ static const struct panel_desc chunghwa_claa070wp03xg = 
> {
>   .width = 94,
>   .height = 150,
>   },
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
> @@ -1362,6 +1364,7 @@ static const struct panel_desc chunghwa_claa101wa01a = {
>   .width = 220,
>   .height = 120,
>   },
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct drm_display_mode chunghwa_claa101wb01_mode = {
> @@ -1384,6 +1387,7 @@ static const struct panel_desc chunghwa_claa101wb01 = {
>   .width = 223,
>   .height = 125,
>   },
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct drm_display_mode dataimage_scf0700c48ggu18_mode = {
> @@ -1573,6 +1577,7 @@ static const struct panel_desc edt_et057090dhu = {
>   },
>   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
>   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct drm_display_mode edt_etm0700g0dh6_mode = {
> @@ -2055,6 +2060,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
>   .width = 344,
>   .height = 193,
>   },
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
> @@ -3001,6 +3007,7 @@ static const struct panel_desc samsung_ltn101nt05 = {
>   .width = 223,
>   .height = 125,
>   },
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
>  static const struct drm_display_mode samsung_ltn140at29_301_mode = {
> -- 
> 2.26.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/panel: otm8009a: Drop unnessary backlight_device_unregister()

2020-06-20 Thread Sam Ravnborg
Hi Wei.

On Thu, Jun 18, 2020 at 01:46:50PM +, Wei Yongjun wrote:
> It's not necessary to unregister backlight device which
> registered with devm_backlight_device_register().
> 
> Fixes: 12a6cbd4f3f1 ("drm/panel: otm8009a: Use new backlight API")
> Reported-by: Hulk Robot 
> Signed-off-by: Wei Yongjun 

Thanks, pushed to drm-misc-next.

Sam

> ---
>  drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
> b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> index 895ee3d1371e..d956522f32ee 100644
> --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> @@ -479,7 +479,6 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
>   if (ret < 0) {
>   dev_err(dev, "mipi_dsi_attach failed. Is host ready?\n");
>   drm_panel_remove(>panel);
> - backlight_device_unregister(ctx->bl_dev);
>   return ret;
>   }
> 
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 2/2] display/drm/bridge: TC358775 DSI/LVDS driver

2020-06-20 Thread Sam Ravnborg
Hi Vinay.

> +
> +static int tc_probe(struct i2c_client *client, const struct i2c_device_id 
> *id)
> +{
> + struct device *dev = >dev;
> + struct drm_panel *panel;
> + struct tc_data *tc;
> + int ret;
> +
> + tc = devm_kzalloc(dev, sizeof(*tc), GFP_KERNEL);
> + if (!tc)
> + return -ENOMEM;
> +
> + tc->dev = dev;
> + tc->i2c = client;
> +
> + ret = drm_of_find_panel_or_bridge(dev->of_node, TC358775_LVDS_OUT0,
> +   0, , NULL);
> + if (ret < 0)
> + return ret;
> + if (!panel)
> + return -ENODEV;
> +
> + panel->connector_type = DRM_MODE_CONNECTOR_LVDS;

The panel is responsible for specifying the connector_type.
It is wrong to let users of panel set it.

Fix the panel and not the bridge driver.


> +
> + tc->panel_bridge = devm_drm_panel_bridge_add(dev, panel);
> + if (IS_ERR(tc->panel_bridge))
> + return PTR_ERR(tc->panel_bridge);
> +
> + ret = tc358775_parse_dt(dev->of_node, tc);
> + if (ret)
> + return ret;
> +
> + tc->vddio = devm_regulator_get(dev, "vddio-supply");
> + if (IS_ERR(tc->vddio)) {
> + ret = PTR_ERR(tc->vddio);
> + dev_err(dev, "vddio-supply not found\n");
> + return ret;
> + }
> +
> + tc->vdd = devm_regulator_get(dev, "vdd-supply");
> + if (IS_ERR(tc->vdd)) {
> + ret = PTR_ERR(tc->vddio);
> + dev_err(dev, "vdd-supply not found\n");
> + return ret;
> + }
> +
> + tc->stby_gpio = devm_gpiod_get(dev, "stby", GPIOD_OUT_HIGH);
> + if (IS_ERR(tc->stby_gpio)) {
> + ret = PTR_ERR(tc->stby_gpio);
> + dev_err(dev, "cannot get stby-gpio %d\n", ret);
> + return ret;
> + }
> +
> + tc->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(tc->reset_gpio)) {
> + ret = PTR_ERR(tc->reset_gpio);
> + dev_err(dev, "cannot get reset-gpios %d\n", ret);
> + return ret;
> + }
> +
> + tc->bridge.funcs = _bridge_funcs;
> + tc->bridge.of_node = dev->of_node;
> + drm_bridge_add(>bridge);
> +
> + i2c_set_clientdata(client, tc);
> +
> + return 0;
> +}
> +

Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel