Re: [RFC 09/11] drm/mediatek: add fbdev support

[CK Hu]

Hi, Ulrich:

On Fri, 2017-09-29 at 15:09 +0200, Ulrich Hecht wrote:
> Forward-ported from chromeos-3.18 vendor kernel.
> 
> Signed-off-by: Ulrich Hecht 

I think this patch originate from [1]. And you should keep the
signed-off-by info so that we could know who contribute to this patch.

[1]
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/330532

Regards,
CK

> ---
>  drivers/gpu/drm/mediatek/Makefile|   2 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   |   9 ++
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h   |   4 +-
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c|  13 +++
>  drivers/gpu/drm/mediatek/mtk_drm_fb.h|   3 +
>  drivers/gpu/drm/mediatek/mtk_drm_fbdev.c | 184 
> +++
>  drivers/gpu/drm/mediatek/mtk_drm_fbdev.h |  32 ++
>  7 files changed, 246 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fbdev.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fbdev.h
> 
> diff --git a/drivers/gpu/drm/mediatek/Makefile 
> b/drivers/gpu/drm/mediatek/Makefile
> index e37b55a..8306fb5 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -12,6 +12,8 @@ mediatek-drm-y := mtk_disp_color.o \
> mtk_mipi_tx.o \
> mtk_dpi.o
>  
> +mediatek-drm-$(CONFIG_DRM_FBDEV_EMULATION) += mtk_drm_fbdev.o
> +
>  obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
>  
>  mediatek-drm-hdmi-objs := mtk_cec.o \
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 8c92630..a69aa2f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -30,6 +30,7 @@
>  #include "mtk_drm_ddp_comp.h"
>  #include "mtk_drm_drv.h"
>  #include "mtk_drm_fb.h"
> +#include "mtk_drm_fbdev.h"
>  #include "mtk_drm_gem.h"
>  
>  #define DRIVER_NAME "mediatek"
> @@ -257,8 +258,15 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>   drm_kms_helper_poll_init(drm);
>   drm_mode_config_reset(drm);
>  
> + ret = mtk_fbdev_init(drm);
> + if (ret)
> + goto err_kms_helper_poll_fini;
> +
>   return 0;
>  
> +err_kms_helper_poll_fini:
> + drm_kms_helper_poll_fini(drm);
> +//   drm_vblank_cleanup(drm);
>  err_component_unbind:
>   component_unbind_all(drm->dev, drm);
>  err_config_cleanup:
> @@ -269,6 +277,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>  
>  static void mtk_drm_kms_deinit(struct drm_device *drm)
>  {
> + mtk_fbdev_fini(drm);
>   drm_kms_helper_poll_fini(drm);
>  
>   component_unbind_all(drm->dev, drm);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index c3378c4..4edc002 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -14,6 +14,7 @@
>  #ifndef MTK_DRM_DRV_H
>  #define MTK_DRM_DRV_H
>  
> +#include 
>  #include 
>  #include "mtk_drm_ddp_comp.h"
>  
> @@ -24,7 +25,6 @@ struct device;
>  struct device_node;
>  struct drm_crtc;
>  struct drm_device;
> -struct drm_fb_helper;
>  struct drm_property;
>  struct regmap;
>  
> @@ -56,6 +56,8 @@ struct mtk_drm_private {
>   } commit;
>  
>   struct drm_atomic_state *suspend_state;
> + struct drm_fb_helper fb_helper;
> + struct drm_gem_object *fbdev_bo;
>  };
>  
>  extern struct platform_driver mtk_ddp_driver;
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> index 0d8d506..ac8561d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> @@ -96,6 +96,19 @@ static struct mtk_drm_fb *mtk_drm_framebuffer_init(struct 
> drm_device *dev,
>   return mtk_fb;
>  }
>  
> +struct drm_framebuffer *mtk_drm_framebuffer_create(struct drm_device *dev,
> + const struct drm_mode_fb_cmd2 *mode,
> + struct drm_gem_object *obj)
> +{
> + struct mtk_drm_fb *mtk_fb;
> +
> + mtk_fb = mtk_drm_framebuffer_init(dev, mode, obj);
> + if (IS_ERR(mtk_fb))
> + return ERR_CAST(mtk_fb);
> +
> + return _fb->base;
> +}
> +
>  /*
>   * Wait for any exclusive fence in fb's gem object's reservation object.
>   *
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_fb.h
> index 9b2ae34..9ee1ac2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_fb.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.h
> @@ -19,5 +19,8 @@ int mtk_fb_wait(struct drm_framebuffer *fb);
>  struct drm_framebuffer *mtk_drm_mode_fb_create(struct drm_device *dev,
>  struct drm_file *file,
>  const struct drm_mode_fb_cmd2 
> *cmd);
> +struct drm_framebuffer *mtk_drm_framebuffer_create(struct drm_device *dev,
> + const struct drm_mode_fb_cmd2 *mode,
> + struct drm_gem_object *obj);
>  
>  #endif /* MTK_DRM_FB_H 

Re: [PATCH v5 4/4] drm/tinydrm: select BACKLIGHT_LCD_SUPPORT, BACKLIGHT_CLASS_DEVICE

[kbuild test robot]

Hi Meghana,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Meghana-Madhyastha/drm-tinydrm-drm_of_find_backlight-helper/20171003-030102
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-x078-201740 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

warning: (DRM && DRM_RADEON && DRM_AMDGPU && DRM_NOUVEAU && DRM_I915 && 
DRM_GMA500 && DRM_SHMOBILE && DRM_TILCDC && DRM_FSL_DCU && DRM_TINYDRM && 
DRM_PARADE_PS8622 && FB_BACKLIGHT && FB_ARMCLCD && FB_MX3 && USB_APPLEDISPLAY 
&& FB_OLPC_DCON && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE 
which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


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

[Bug 93199] IGT: Couldn't map MMIO region

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93199

--- Comment #25 from os...@cetex.se ---
Forgot to mention this is ubuntu 17.04 and i intel-gpu-tools are version 1.17-1

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

[Bug 93199] IGT: Couldn't map MMIO region

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93199

--- Comment #24 from os...@cetex.se ---
(In reply to Jari Tahvanainen from comment #23)
> Moving this from DRM/Intel to IGT, since it seems to be problem with that.
> Sean, Jonathan, Dimitry and Rami - please check if this problem is still
> valid with the latest igt.

I've found i have the same issue, running as root:

root@oskar-ThinkPad-X270:/sys/bus/pci/devices/:00:02.0# intel_gpu_top 
(intel_gpu_top:6971) intel-mmio-CRITICAL: Test assertion failure function
intel_mmio_use_pci_bar, file ../../lib/intel_mmio.c:145:
(intel_gpu_top:6971) intel-mmio-CRITICAL: Failed assertion: !(error != 0)
(intel_gpu_top:6971) intel-mmio-CRITICAL: Last errno: 1, Operation not
permitted
(intel_gpu_top:6971) intel-mmio-CRITICAL: Couldn't map MMIO region
Stack trace:
  #0 [_init+0x7369]
  #1 [_init+0x4fd0]
  #2 [_init+0x98e]
  #3 [__libc_start_main+0xf1]
  #4 [_init+0x1752]
  #5 [+0x1752]
Test (null) failed.
 DEBUG 
(intel_gpu_top:6971) intel-chipset-DEBUG: Test requirement passed: pci_dev
(intel_gpu_top:6971) intel-mmio-CRITICAL: Test assertion failure function
intel_mmio_use_pci_bar, file ../../lib/intel_mmio.c:145:
(intel_gpu_top:6971) intel-mmio-CRITICAL: Failed assertion: !(error != 0)
(intel_gpu_top:6971) intel-mmio-CRITICAL: Last errno: 1, Operation not
permitted
(intel_gpu_top:6971) intel-mmio-CRITICAL: Couldn't map MMIO region
  END  
FAIL (-1.000s)


strace shows failure on opening resource0:
open("/sys/bus/pci/devices/:00:02.0/resource", O_RDONLY|O_CLOEXEC) = 4
read(4, "0xe000 0xe0f"..., 512) = 512
close(4)= 0
open("/sys/bus/pci/devices/:00:02.0/resource0", O_RDWR|O_CLOEXEC) = 4
mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = -1 EPERM
(Operation not permitted)
close(4)= 0
write(2, "(intel_gpu_top:7094) intel-mmio-"..., 131(intel_gpu_top:7094)
intel-mmio-CRITICAL: Test assertion failure function intel_mmio_use_pci_bar,
file ../../lib/intel_mmio.c:145:
) = 131
write(2, "(intel_gpu_top:7094) intel-mmio-"..., 74(intel_gpu_top:7094)
intel-mmio-CRITICAL: Failed assertion: !(error != 0)
) = 74
write(2, "(intel_gpu_top:7094) intel-mmio-"..., 81(intel_gpu_top:7094)
intel-mmio-CRITICAL: Last errno: 1, Operation not permitted
) = 81
write(2, "(intel_gpu_top:7094) intel-mmio-"..., 67(intel_gpu_top:7094)
intel-mmio-CRITICAL: Couldn't map MMIO region
) = 67

checking if readable with cat:
root@oskar-ThinkPad-X270:/sys/bus/pci/devices/:00:02.0# cat resource
0xe000 0xe0ff 0x00140204
0x 0x 0x
0xc000 0xdfff 0x0014220c
0x 0x 0x
0xe000 0xe03f 0x00040101
0x 0x 0x
0x000c 0x000d 0x0212
0x 0x 0x
0x 0x 0x
0x 0x 0x
0x 0x 0x
0x 0x 0x
0x 0x 0x
root@oskar-ThinkPad-X270:/sys/bus/pci/devices/:00:02.0# cat resource0
cat: resource0: Input/output error
root@oskar-ThinkPad-X270:/sys/bus/pci/devices/:00:02.0# cat resource2
cat: resource2: Input/output error
root@oskar-ThinkPad-X270:/sys/bus/pci/devices/:00:02.0# cat resource2_wc
cat: resource2_wc: Input/output error
root@oskar-ThinkPad-X270:/sys/bus/pci/devices/:00:02.0# cat resource4
cat: resource4: Invalid argument

root@oskar-ThinkPad-X270:/sys/bus/pci/devices/:00:02.0# ls -la resource*
-r--r--r-- 1 root root  4096 okt  2 22:38 resource
-rw--- 1 root root  16777216 okt  2 22:30 resource0
-rw--- 1 root root 536870912 okt  2 22:38 resource2
-rw--- 1 root root 536870912 okt  2 22:38 resource2_wc
-rw--- 1 root root64 okt  2 22:38 resource4

root@oskar-ThinkPad-X270:/sys/bus/pci/devices/:00:02.0# uname -a
Linux oskar-ThinkPad-X270 4.10.0-35-generic #39-Ubuntu SMP Wed Sep 13 07:46:59
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux


I wonder if it could be related to secure_boot?

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

[Bug 103066] Empire boundaries do not show up in Stellaris.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103066

Bug ID: 103066
   Summary: Empire boundaries do not show up in Stellaris.
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: dstephanoshach...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

When I play Stellaris, I can not see the empire boundaries. The whole galaxy
just looks like a grey blob. It looks just like Bug 95530.

I am using an AMD Radeon HD 6970, mesa 17.2.1, and fedora 26.

I'm not sure what kind of debug info is useful, but the bug is completely
reproducible so I can get any info needed.

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

[PATCH v2] amdgpu: Add deadlock detection test suit.

[Andrey Grodzovsky]

From: Andrey Grodzovsky 

Adding initial tests for locks detection when SW
scheduler FIFO is full.

The test works by submitting a batch of identical commands which make the CP
stall waiting for condition to become true. The condition is later satisfied
form a helper thread. Other events that happen during this time
might create deadlock situations. One such example is GPU reset
triggered by this stall when  amdgpu_lockup_timeout != 0.

v2:
Increase the delay from 2 to 100 ms.
Comment out the compute test until it's working.
Typos fix.

Signed-off-by: Andrey Grodzovsky 
Reviewed-by: Christian König 
---
 tests/amdgpu/Makefile.am  |   6 +-
 tests/amdgpu/amdgpu_test.c|   6 ++
 tests/amdgpu/amdgpu_test.h|  15 +++
 tests/amdgpu/deadlock_tests.c | 245 ++
 4 files changed, 270 insertions(+), 2 deletions(-)
 create mode 100644 tests/amdgpu/deadlock_tests.c

diff --git a/tests/amdgpu/Makefile.am b/tests/amdgpu/Makefile.am
index 9c02fd6..8700c4d 100644
--- a/tests/amdgpu/Makefile.am
+++ b/tests/amdgpu/Makefile.am
@@ -1,7 +1,8 @@
 AM_CFLAGS = \
-I $(top_srcdir)/include/drm \
-I $(top_srcdir)/amdgpu \
-   -I $(top_srcdir)
+   -I $(top_srcdir) \
+   -pthread
 
 LDADD = $(top_builddir)/libdrm.la \
$(top_builddir)/amdgpu/libdrm_amdgpu.la \
@@ -29,4 +30,5 @@ amdgpu_test_SOURCES = \
frame.h \
uvd_enc_tests.c \
vcn_tests.c \
-   uve_ib.h
+   uve_ib.h \
+   deadlock_tests.c
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index cd6b826..9925503 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -97,6 +97,12 @@ static CU_SuiteInfo suites[] = {
.pCleanupFunc = suite_uvd_enc_tests_clean,
.pTests = uvd_enc_tests,
},
+   {
+   .pName = "Deadlock Tests",
+   .pInitFunc = suite_deadlock_tests_init,
+   .pCleanupFunc = suite_deadlock_tests_clean,
+   .pTests = deadlock_tests,
+   },
CU_SUITE_INFO_NULL,
 };
 
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index d0b61ba..ece93f4 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -135,6 +135,21 @@ int suite_uvd_enc_tests_clean();
 extern CU_TestInfo uvd_enc_tests[];
 
 /**
+ * Initialize deadlock test suite
+ */
+int suite_deadlock_tests_init();
+
+/**
+ * Deinitialize deadlock test suite
+ */
+int suite_deadlock_tests_clean();
+
+/**
+ * Tests in uvd enc test suite
+ */
+extern CU_TestInfo deadlock_tests[];
+
+/**
  * Helper functions
  */
 static inline amdgpu_bo_handle gpu_mem_alloc(
diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
new file mode 100644
index 000..e23d903
--- /dev/null
+++ b/tests/amdgpu/deadlock_tests.c
@@ -0,0 +1,245 @@
+/*
+ * Copyright 2017 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.
+ *
+*/
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#ifdef HAVE_ALLOCA_H
+# include 
+#endif
+
+#include "CUnit/Basic.h"
+
+#include "amdgpu_test.h"
+#include "amdgpu_drm.h"
+
+#include 
+
+
+/*
+ * This defines the delay in MS after which memory location designated for
+ * compression against reference value is written to, unblocking command
+ * processor
+ */
+#define WRITE_MEM_ADDRESS_DELAY_MS 100
+
+#definePACKET_TYPE33
+
+#define PACKET3(op, n) ((PACKET_TYPE3 << 30) | \
+(((op) & 0xFF) << 8) | \
+((n) & 0x3FFF) << 16)
+
+#definePACKET3_WAIT_REG_MEM0x3C
+#defineWAIT_REG_MEM_FUNCTION(x)((x) << 0)
+   /* 0 - always
+* 1 - <
+* 2 - <=
+  

Re: [PATCH v6 2/2] drm/tinydrm: Add devres versions of drm_of_find_backlight

[kbuild test robot]

Hi Meghana,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Meghana-Madhyastha/drm-tinydrm-drm_of_find_backlight-helper/20171003-011920
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
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
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/drm_of.c:283:26: error: redefinition of 
'drm_of_find_backlight'
struct backlight_device *drm_of_find_backlight(struct device *dev)
 ^
   In file included from drivers/gpu/drm/drm_of.c:4:0:
   include/linux/backlight.h:181:1: note: previous definition of 
'drm_of_find_backlight' was here
drm_of_find_backlight(struct device *dev)
^
>> drivers/gpu/drm/drm_of.c:328:26: error: redefinition of 
>> 'devm_drm_of_find_backlight'
struct backlight_device *devm_drm_of_find_backlight(struct device *dev)
 ^~
   In file included from drivers/gpu/drm/drm_of.c:4:0:
   include/linux/backlight.h:187:1: note: previous definition of 
'devm_drm_of_find_backlight' was here
devm_drm_of_find_backlight(struct device *dev)
^~

vim +/devm_drm_of_find_backlight +328 drivers/gpu/drm/drm_of.c

   264  
   265  /**
   266   * drm_of_find_backlight - Find backlight device in device-tree
   267   * @dev: Device
   268   *
   269   * This function looks for a DT node pointed to by a property named 
'backlight'
   270   * and uses of_find_backlight_by_node() to get the backlight device.
   271   * Additionally if the brightness property is zero, it is set to
   272   * max_brightness.
   273   *
   274   * Note: It is the responsibility of the caller to call put_device() 
when
   275   * releasing the resource.
   276   *
   277   * Returns:
   278   * NULL if there's no backlight property.
   279   * Error pointer -EPROBE_DEFER if the DT node is found, but no 
backlight device
   280   * is found.
   281   * If the backlight device is found, a pointer to the structure is 
returned.
   282   */
 > 283  struct backlight_device *drm_of_find_backlight(struct device *dev)
   284  {
   285  struct backlight_device *backlight;
   286  struct device_node *np;
   287  
   288  np = of_parse_phandle(dev->of_node, "backlight", 0);
   289  if (!np)
   290  return NULL;
   291  
   292  backlight = of_find_backlight_by_node(np);
   293  of_node_put(np);
   294  
   295  if (!backlight)
   296  return ERR_PTR(-EPROBE_DEFER);
   297  
   298  if (!backlight->props.brightness) {
   299  backlight->props.brightness = 
backlight->props.max_brightness;
   300  DRM_DEBUG_KMS("Backlight brightness set to %d\n",
   301backlight->props.brightness);
   302  }
   303  
   304  return backlight;
   305  }
   306  EXPORT_SYMBOL(drm_of_find_backlight);
   307  
   308  static void devm_drm_of_find_backlight_release(void *data)
   309  {
   310  put_device(data);
   311  }
   312  
   313  /**
   314   * devm_drm_of_find_backlight - Find backlight device in device-tree
   315   * devres version of the function
   316   * @dev: Device
   317   *
   318   * This is the devres version of the function drm_of_find_backlight.
   319   * Some drivers use devres versions of functions for
   320   * requiring device resources.
   321   *
   322   * Returns:
   323   * NULL if there's no backlight property.
   324   * Error pointer -EPROBE_DEFER if the DT node is found, but no 
backlight device
   325   * is found.
   326   * If the backlight device is found, a pointer to the structure is 
returned.
   327   */
 > 328  struct backlight_device *devm_drm_of_find_backlight(struct device *dev)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


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

Re: [PATCH v3 05/14] drm/sun4i: hdmi: Disable clks in bind function error path and unbind function

[Maxime Ripard]

On Fri, Sep 29, 2017 at 08:22:57AM +, Chen-Yu Tsai wrote:
> The HDMI driver enables the bus and mod clocks in the bind function, but
> does not disable them if it then bails our due to any errors. Neither
> does it disable the clocks in the unbind function.
> 
> Fix this by adding a proper error path to the bind function, and
> clk_disable_unprepare calls to the unbind function.
> 
> Also rename the err_cleanup_connector label to err_cleanup_encoder,
> since it is the encoder that gets cleaned up.
> 
> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> Signed-off-by: Chen-Yu Tsai 
> Acked-by: Maxime Ripard 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH v6 1/2] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

[kbuild test robot]

Hi Meghana,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Meghana-Madhyastha/drm-tinydrm-drm_of_find_backlight-helper/20171003-011920
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
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
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/drm_of.c:283:26: error: redefinition of 
>> 'drm_of_find_backlight'
struct backlight_device *drm_of_find_backlight(struct device *dev)
 ^
   In file included from drivers/gpu/drm/drm_of.c:4:0:
   include/linux/backlight.h:180:1: note: previous definition of 
'drm_of_find_backlight' was here
drm_of_find_backlight(struct device *dev)
^

vim +/drm_of_find_backlight +283 drivers/gpu/drm/drm_of.c

   264  
   265  /**
   266   * drm_of_find_backlight - Find backlight device in device-tree
   267   * @dev: Device
   268   *
   269   * This function looks for a DT node pointed to by a property named 
'backlight'
   270   * and uses of_find_backlight_by_node() to get the backlight device.
   271   * Additionally if the brightness property is zero, it is set to
   272   * max_brightness.
   273   *
   274   * Note: It is the responsibility of the caller to call put_device() 
when
   275   * releasing the resource.
   276   *
   277   * Returns:
   278   * NULL if there's no backlight property.
   279   * Error pointer -EPROBE_DEFER if the DT node is found, but no 
backlight device
   280   * is found.
   281   * If the backlight device is found, a pointer to the structure is 
returned.
   282   */
 > 283  struct backlight_device *drm_of_find_backlight(struct device *dev)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


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

[PATCH hwc] drm_hwcomposer: make sure primary plane is allocated for squash

[Adrian Salido]

There are instances where the primary plane may have been disabled, look
through disabled planes as well to find primary plane to use for squash.

Signed-off-by: Adrian Salido 
---
 drmdisplaycompositor.cpp | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index a07d3588d1f5..80e3eba60ccf 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -933,10 +933,13 @@ int 
DrmDisplayCompositor::SquashFrame(DrmDisplayComposition *src,
   goto move_layers_back;
 }
 
-if (comp_plane.type() == DrmCompositionPlane::Type::kDisable) {
+if (comp_plane.plane()->type() == DRM_PLANE_TYPE_PRIMARY)
+  squashed_comp.set_plane(comp_plane.plane());
+else
   dst->AddPlaneDisable(comp_plane.plane());
+
+if (comp_plane.type() == DrmCompositionPlane::Type::kDisable)
   continue;
-}
 
 for (auto i : comp_plane.source_layers()) {
   DrmHwcLayer  = src_layers[i];
@@ -955,11 +958,12 @@ int 
DrmDisplayCompositor::SquashFrame(DrmDisplayComposition *src,
   squashed_comp.source_layers().push_back(
   squashed_comp.source_layers().size());
 }
+  }
 
-if (comp_plane.plane()->type() == DRM_PLANE_TYPE_PRIMARY)
-  squashed_comp.set_plane(comp_plane.plane());
-else
-  dst->AddPlaneDisable(comp_plane.plane());
+  if (squashed_comp.plane() == NULL) {
+ALOGE("Primary plane not found for squash");
+ret = -ENOTSUP;
+goto move_layers_back;
   }
 
   ret = dst->SetLayers(dst_layers.data(), dst_layers.size(), false);
-- 
2.14.2.822.g60be5d43e6-goog

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

Re: [PATCH v5 2/2] staging: ion: create one device entry per heap

[Laura Abbott]

On 09/27/2017 06:20 AM, Benjamin Gaignard wrote:
> Instead a getting only one common device "/dev/ion" for
> all the heaps this patch allow to create one device
> entry ("/dev/ionX") per heap.
> Getting an entry per heap could allow to set security rules
> per heap and global ones for all heaps.
> 
> Allocation requests will be only allowed if the mask_id
> match with device minor.
> Query request could be done on any of the devices.
>
Thinking about this a bit more, I'm not 100% sure if this
will allow the security rules we want. Heap ids are assigned
dynamically and therefore so will the /dev/ionX designation.
From my understanding, security rules like selinux need to
be fully specified at boot time so I'm not sure how you would
be able to write rules to differentiate between /dev/ionX and
/dev/ionY without knowing the values at boottime.

So I think we need a different way to match the heap ids to
get the security we want unless my understanding of security
policies is wrong and we can dynamically specify permissions.

Thanks,
Laura
> Signed-off-by: Benjamin Gaignard 
> ---
> version 5:
> - create a configuration flag to keep legacy Ion misc device
> 
> version 4:
> - add a configuration flag to switch between legacy Ion misc device
>   and one device per heap version.
> 
> version 3:
> - change ion_device_add_heap prototype to return a possible error.
> 
> version 2:
> - simplify ioctl check like propose by Dan
> - make sure that we don't register more than ION_DEV_MAX heaps.
> 
>  drivers/staging/android/TODO|  1 -
>  drivers/staging/android/ion/Kconfig |  7 +++
>  drivers/staging/android/ion/ion-ioctl.c | 18 --
>  drivers/staging/android/ion/ion.c   | 31 ++-
>  drivers/staging/android/ion/ion.h   | 15 +--
>  5 files changed, 66 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> index 5f14247..d770ffa 100644
> --- a/drivers/staging/android/TODO
> +++ b/drivers/staging/android/TODO
> @@ -9,7 +9,6 @@ TODO:
>  ion/
>   - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would
> involve putting appropriate bindings in a memory node for Ion to find.
> - - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
>   - Better test framework (integration with VGEM was suggested)
>  
>  Please send patches to Greg Kroah-Hartman  and Cc:
> diff --git a/drivers/staging/android/ion/Kconfig 
> b/drivers/staging/android/ion/Kconfig
> index a517b2d..cb4666e 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -10,6 +10,13 @@ menuconfig ION
> If you're not using Android its probably safe to
> say N here.
>  
> +config ION_LEGACY_DEVICE_API
> + bool "Keep using Ion legacy misc device API"
> + depends on ION
> + help
> +   Choose this option to keep using Ion legacy misc device API
> +   i.e. /dev/ion
> +
>  config ION_SYSTEM_HEAP
>   bool "Ion system heap"
>   depends on ION
> diff --git a/drivers/staging/android/ion/ion-ioctl.c 
> b/drivers/staging/android/ion/ion-ioctl.c
> index e26b786..bb5c77b 100644
> --- a/drivers/staging/android/ion/ion-ioctl.c
> +++ b/drivers/staging/android/ion/ion-ioctl.c
> @@ -25,7 +25,8 @@ union ion_ioctl_arg {
>   struct ion_heap_query query;
>  };
>  
> -static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
> +static int validate_ioctl_arg(struct file *filp,
> +   unsigned int cmd, union ion_ioctl_arg *arg)
>  {
>   switch (cmd) {
>   case ION_IOC_HEAP_QUERY:
> @@ -34,6 +35,19 @@ static int validate_ioctl_arg(unsigned int cmd, union 
> ion_ioctl_arg *arg)
>   arg->query.reserved2 )
>   return -EINVAL;
>   break;
> +
> + case ION_IOC_ALLOC:
> + {
> + int mask = 1 << iminor(filp->f_inode);
> +
> +#ifdef CONFIG_ION_LEGACY_DEVICE_API
> + if (imajor(filp->f_inode) == MISC_MAJOR)
> + return 0;
> +#endif
> + if (!(arg->allocation.heap_id_mask & mask))
> + return -EINVAL;
> + break;
> + }
>   default:
>   break;
>   }
> @@ -69,7 +83,7 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
> unsigned long arg)
>   if (copy_from_user(, (void __user *)arg, _IOC_SIZE(cmd)))
>   return -EFAULT;
>  
> - ret = validate_ioctl_arg(cmd, );
> + ret = validate_ioctl_arg(filp, cmd, );
>   if (WARN_ON_ONCE(ret))
>   return ret;
>  
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 93e2c90..092b24c 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -40,6 +40,8 @@
>  
>  #include "ion.h"
>  
> +#define ION_DEV_MAX 32
> +
>  static struct ion_device 

[Bug 196777] Virtual guest using video device QXL does not reach GDM

[bugzilla-daemon]

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

--- Comment #12 from Justin M. Forbes (jmfor...@linuxtx.org) ---
(In reply to Gerd Hoffmann from comment #11)
> (In reply to Justin M. Forbes from comment #10)
> > After going through these with a number of users:
> > 
> > qxl: fix primary surface handling - This patch is widely reported to cause
> > serious screen flickering that is not there without it, making the system
> > unusable.
> 
> Workaround #1: turn off wayland.

Possible as a short term fix, but with wayland being pretty much "the way
forward" it doesn't seem to be a workable long term solution.

> Workaround #2: use virtio-vga instead. wayland doesn't use qxl 2d accel
> anyway.
> 
> Fundamental problem here is that the qxl virtual hardware simply doesn't
> support pageflip, we have to destroy + re-create the primary surface
> instead.  This is where the flicker comes from.
> 
> Commit "058e9f5c82 drm/qxl: simple crtc page flipping emulated using buffer
> copy" handles the issue with a pretty gross hack, blitting one framebuffer
> over the other instead of a proper primary surface update.  With atomic
> modesetting that doesn't work any more.
> 
> We could possibly decouple the primary surface from the drm framebuffers, so
> the drm framebuffers effectively become shadow framebuffers, and every
> display update becomes a drm framebuffer -> primary surface blit.  Not sure
> whenever that scheme can work properly with xorg though.  Also has a high
> chance to cause xorg performance regressions.
>

So this brings up an interesting problem in how things are to move forward. It
came up as a blocker in Fedora 27 today. Let's say we find a way to force boxes
to revert to virtio-vga.  That wouldn't change any existing VMs, and it is
something we have no control over when the host is not Fedora as well.  It also
would be a problem for non wayland guests.

-- 
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

[Bug 102955] HyperZ related rendering issue in ARK: Survival Evolved

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102955

--- Comment #3 from Marek Olšák  ---
Workaround:

diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi/si_blit.c
index 67972a2..dc71742 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -903,6 +903,14 @@ static void si_clear(struct pipe_context *ctx, unsigned
buffers,
sctx->db_stencil_clear = true;
si_mark_atom_dirty(sctx, >db_render_state);
}
+
+   /* TODO: Find out what's wrong here. Fast depth clear with
+* a dirty DB cache causes corruption in ARK: Survival Evolved.
+* https://bugs.freedesktop.org/show_bug.cgi?id=102955
+*
+* This hack massively decreases back-to-back ClearDepth
performance.
+*/
+   sctx->b.flags |= SI_CONTEXT_FLUSH_AND_INV_DB;
}

si_blitter_begin(ctx, SI_CLEAR);

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

[PATCH] drm/msm: use proper memory barriers for updating tail/head

[Rob Clark]

Fixes intermittent corruption of cmdstream dump.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_rd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index 5c087a4228ff..918c65e19964 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -120,7 +120,7 @@ static void rd_write(struct msm_rd_state *rd, const void 
*buf, int sz)
n = min(sz, circ_space_to_end(>fifo));
memcpy(fptr, ptr, n);
 
-   fifo->head = (fifo->head + n) & (BUF_SZ - 1);
+   smp_store_release(>head, (fifo->head + n) & (BUF_SZ - 1));
sz  -= n;
ptr += n;
 
@@ -157,7 +157,7 @@ static ssize_t rd_read(struct file *file, char __user *buf,
goto out;
}
 
-   fifo->tail = (fifo->tail + n) & (BUF_SZ - 1);
+   smp_store_release(>tail, (fifo->tail + n) & (BUF_SZ - 1));
*ppos += n;
 
wake_up_all(>fifo_event);
-- 
2.13.5

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

Re: [PATCH v2] dt-bindings: fsl-imx-drm: Remove incorrect "@di0" usage

[Philipp Zabel]

Hi Marco,

On Mon, 2017-10-02 at 10:45 -0300, Marco Franchi wrote:
> Improve the binding example by removing the '@di0' notation, which
> fixes the following build warning:
> 
> Warning (unit_address_vs_reg): Node /display@di0 has a unit name, but 
> no reg property
> 
> Signed-off-by: Marco Franchi 

Thank you, I've applied this patch to the imx-drm/next branch.

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

[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102646

--- Comment #13 from Harry Wentland  ---
I'm curious if you only see this with Stardew Valley? I've seen reports of
people having the same issue with Stardew Valley independent of their graphics
adapter. Seems to be a combination of game and window manager.

https://steamcommunity.com/app/413150/discussions/1/405693392918042081/
https://steamcommunity.com/app/413150/discussions/1/333656722968187453/

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

Re: [PATCH v3 03/14] drm/sun4i: tcon: Add variant callback for TCON output muxing

[Chen-Yu Tsai]

On Fri, Sep 29, 2017 at 6:19 PM, Maxime Ripard
 wrote:
> On Fri, Sep 29, 2017 at 08:22:55AM +, Chen-Yu Tsai wrote:
>>  static const struct sun4i_tcon_quirks sun5i_a13_quirks = {
>> - .has_unknown_mux = true,
>> - .has_channel_1  = true,
>> + .has_unknown_mux= true,
>> + .has_channel_1  = true,
>> + .set_mux= sun5i_a13_tcon_set_mux,
>
> I guess we could even retire has_unknown_mux now, since it provides
> the same information than if set_mux is set or to NULL.

I'll drop them in the same patch in v4.

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

Re: [PATCH] dt-bindings: fsl-imx-drm: Remove incorrect "@di0" usage

[Philipp Zabel]

Hi Marco,

On Fri, 2017-09-22 at 15:05 -0300, Marco Franchi wrote:
> Improve the binding example by removing the '@di0' notation, which
> fixes the following build warning:
> 
> Warning (unit_address_vs_reg): Node /display@di0 has a unit name, but 
> no reg property
> 
> Signed-off-by: Marco Franchi 
> ---
>  Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-
> drm.txt b/Documentation/devicetree/bindings/display/imx/fsl-imx-
> drm.txt
> index f798547..44814f0 100644
> --- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> +++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> @@ -129,7 +129,7 @@ Optional properties:
>  
>  example:
>  
> -display@di0 {
> +display-di0 {
>   compatible = "fsl,imx-parallel-display";
>   edid = [edid-data];
>   interface-pix-fmt = "rgb24";

Thank you for the patch. We certainly should get rid of the @di0
notation. Since these nodes mostly describe the DISP0 and DISP1 pin
groups controlled by the IOMUXC, I'd prefer to rename this to

-display@di0 {
+disp0 {

instead, if that is fine with you.

I'd also like to move the disp0/disp1 nodes into the SoC dtsi files to
avoid having to duplicate port@0 all over the place.

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

Re: [RFC 01/11] soc: mediatek: MediaTek Command Queue (CMDQ) driver

[CK Hu]

Hi, Ulrich:

This patch looks old-fashioned. Please follow up with [1].

[1]
http://lists.infradead.org/pipermail/linux-mediatek/2017-January/007654.html

Regards,
CK

On Fri, 2017-09-29 at 15:09 +0200, Ulrich Hecht wrote:
> Ported from chromeos-3.18 kernel.
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  drivers/soc/mediatek/Kconfig|   10 +
>  drivers/soc/mediatek/Makefile   |1 +
>  drivers/soc/mediatek/mtk-cmdq.c | 2814 
> +++
>  include/soc/mediatek/cmdq.h |  211 +++
>  4 files changed, 3036 insertions(+)
>  create mode 100644 drivers/soc/mediatek/mtk-cmdq.c
>  create mode 100644 include/soc/mediatek/cmdq.h
> 
> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> index 609bb34..ef271e0 100644
> --- a/drivers/soc/mediatek/Kconfig
> +++ b/drivers/soc/mediatek/Kconfig
> @@ -1,6 +1,16 @@
>  #
>  # MediaTek SoC drivers
>  #
> +config MTK_CMDQ
> + bool "MediaTek CMDQ Support"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + select MTK_INFRACFG
> + help
> +   Say yes here to add support for the MediaTek Command Queue (CMDQ)
> +   driver. The CMDQ is used to help read/write registers with critical
> +   time limitation, such as updating display configuration during the
> +   vblank.
> +
>  config MTK_INFRACFG
>   bool "MediaTek INFRACFG Support"
>   depends on ARCH_MEDIATEK || COMPILE_TEST
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 12998b0..f7397ef 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -1,3 +1,4 @@
> +obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq.o
>  obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
>  obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
>  obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> diff --git a/drivers/soc/mediatek/mtk-cmdq.c b/drivers/soc/mediatek/mtk-cmdq.c
> new file mode 100644
> index 000..a8bfb5c
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-cmdq.c
> @@ -0,0 +1,2814 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Please calculate this value for each platform.
> + * task number = vblank time / ((task cmds * cmd ticks) / GCE freq)
> + */
> +#define CMDQ_MAX_TASK_IN_THREAD  70
> +
> +#define CMDQ_INITIAL_CMD_BLOCK_SIZE  PAGE_SIZE
> +#define CMDQ_CMD_BUF_POOL_BUF_SIZE   PAGE_SIZE
> +#define CMDQ_CMD_BUF_POOL_BUF_NUM140 /* 2 * 70 = 140 */
> +#define CMDQ_INST_SIZE   8 /* instruction is 64-bit */
> +
> +/*
> + * cmdq_thread cookie value is from 0 to CMDQ_MAX_COOKIE_VALUE.
> + * And, this value also be used as MASK.
> + */
> +#define CMDQ_MAX_COOKIE_VALUE0x
> +#define CMDQ_COOKIE_MASK CMDQ_MAX_COOKIE_VALUE
> +
> +#define CMDQ_DEFAULT_TIMEOUT_MS  1000
> +#define CMDQ_ACQUIRE_THREAD_TIMEOUT_MS   5000
> +#define CMDQ_PREALARM_TIMEOUT_NS 2
> +
> +#define CMDQ_INVALID_THREAD  -1
> +
> +#define CMDQ_DRIVER_DEVICE_NAME  "mtk_cmdq"
> +
> +#define CMDQ_CLK_NAME"gce"
> +
> +#define CMDQ_CURR_IRQ_STATUS_OFFSET  0x010
> +#define CMDQ_CURR_LOADED_THR_OFFSET  0x018
> +#define CMDQ_THR_SLOT_CYCLES_OFFSET  0x030
> +#define CMDQ_THR_EXEC_CYCLES_OFFSET  0x034
> +#define CMDQ_THR_TIMEOUT_TIMER_OFFSET0x038
> +#define CMDQ_BUS_CONTROL_TYPE_OFFSET 0x040
> +
> +#define CMDQ_SYNC_TOKEN_ID_OFFSET0x060
> +#define CMDQ_SYNC_TOKEN_VAL_OFFSET   0x064
> +#define CMDQ_SYNC_TOKEN_UPD_OFFSET   0x068
> +
> +#define CMDQ_GPR_SHIFT   0x004
> +#define CMDQ_GPR_OFFSET  0x080
> +
> +#define CMDQ_THR_SHIFT   0x080
> +#define CMDQ_THR_WARM_RESET_OFFSET   0x100
> +#define CMDQ_THR_ENABLE_TASK_OFFSET  0x104
> +#define CMDQ_THR_SUSPEND_TASK_OFFSET 0x108
> +#define CMDQ_THR_CURR_STATUS_OFFSET  0x10c
> +#define CMDQ_THR_IRQ_STATUS_OFFSET   0x110
> +#define CMDQ_THR_IRQ_ENABLE_OFFSET   0x114
> +#define CMDQ_THR_CURR_ADDR_OFFSET0x120
> +#define CMDQ_THR_END_ADDR_OFFSET 0x124
> +#define CMDQ_THR_EXEC_CNT_OFFSET 0x128
> +#define CMDQ_THR_WAIT_TOKEN_OFFSET   0x130
> +#define CMDQ_THR_CFG_OFFSET  0x140
> +#define CMDQ_THR_INST_CYCLES_OFFSET  0x150
> +#define CMDQ_THR_INST_THRESX_OFFSET  0x154
> +#define 

Re: [RFC 11/11] hack: Revert "iommu/io-pgtable: Sanitise map/unmap addresses"

[Robin Murphy]

Hi Ulrich,

On 29/09/17 14:09, Ulrich Hecht wrote:
> This check breaks DRM initialization on Acer Chromebook R13, paddr is above
> 4GB. Haven't looked into this yet.

I think you mean "DRM initialisation was happening to still work with
silently truncated addresses..." ;)

Anyway, the Mediatek-specific fix is in rc3 now - 1ff9b17cedb3
("iommu/mediatek: Limit the physical address in 32bit for v7s")

Robin.

> This reverts commit 76557391433c77d330cede1a531b358d2f90df66.
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  drivers/iommu/io-pgtable-arm-v7s.c | 6 --
>  drivers/iommu/io-pgtable-arm.c | 7 ---
>  2 files changed, 13 deletions(-)
> 
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c 
> b/drivers/iommu/io-pgtable-arm-v7s.c
> index d665d0d..af330f5 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -479,9 +479,6 @@ static int arm_v7s_map(struct io_pgtable_ops *ops, 
> unsigned long iova,
>   if (!(prot & (IOMMU_READ | IOMMU_WRITE)))
>   return 0;
>  
> - if (WARN_ON(upper_32_bits(iova) || upper_32_bits(paddr)))
> - return -ERANGE;
> -
>   ret = __arm_v7s_map(data, iova, paddr, size, prot, 1, data->pgd);
>   /*
>* Synchronise all PTE updates for the new mapping before there's
> @@ -662,9 +659,6 @@ static int arm_v7s_unmap(struct io_pgtable_ops *ops, 
> unsigned long iova,
>   struct arm_v7s_io_pgtable *data = io_pgtable_ops_to_data(ops);
>   size_t unmapped;
>  
> - if (WARN_ON(upper_32_bits(iova)))
> - return 0;
> -
>   unmapped = __arm_v7s_unmap(data, iova, size, 1, data->pgd);
>   if (unmapped)
>   io_pgtable_tlb_sync(>iop);
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index e8018a3..b182039 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -452,10 +452,6 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, 
> unsigned long iova,
>   if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
>   return 0;
>  
> - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias) ||
> - paddr >= (1ULL << data->iop.cfg.oas)))
> - return -ERANGE;
> -
>   prot = arm_lpae_prot_to_pte(data, iommu_prot);
>   ret = __arm_lpae_map(data, iova, paddr, size, prot, lvl, ptep);
>   /*
> @@ -614,9 +610,6 @@ static int arm_lpae_unmap(struct io_pgtable_ops *ops, 
> unsigned long iova,
>   arm_lpae_iopte *ptep = data->pgd;
>   int lvl = ARM_LPAE_START_LVL(data);
>  
> - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias)))
> - return 0;
> -
>   unmapped = __arm_lpae_unmap(data, iova, size, lvl, ptep);
>   if (unmapped)
>   io_pgtable_tlb_sync(>iop);
> 

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

Re: [PATCH v7 1/3] backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

[Jani Nikula]

On Mon, 02 Oct 2017, Daniel Thompson  wrote:
> On 02/10/17 09:49, Jani Nikula wrote:
>> On Mon, 02 Oct 2017, Daniel Thompson  wrote:
>>> On 01/10/17 18:26, Meghana Madhyastha wrote:
 -#ifdef CONFIG_OF
 +#if defined CONFIG_OF && IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
>>>
>>> The above comments are more important but why does this mix defined and
>>> IS_ENABLED? Couldn't they both use defined (and preferably with the
>>> optional brackets around the CONFIG_ symbol).
>> 
>> No, always use IS_ENABLED() for tristates when you want to match 'y' or
>> 'm'.
>
> Oops.
>
> Actually it was the mis-match in the original code that attracted my 
> attention (defined on one side, IS_ENABLED() on the other)... I'd be 
> happier if both used the same approach.

Agreed.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 1/3] backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

[Daniel Thompson]

On 02/10/17 09:49, Jani Nikula wrote:

On Mon, 02 Oct 2017, Daniel Thompson  wrote:

On 01/10/17 18:26, Meghana Madhyastha wrote:

-#ifdef CONFIG_OF
+#if defined CONFIG_OF && IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)


The above comments are more important but why does this mix defined and
IS_ENABLED? Couldn't they both use defined (and preferably with the
optional brackets around the CONFIG_ symbol).


No, always use IS_ENABLED() for tristates when you want to match 'y' or
'm'.


Oops.

Actually it was the mis-match in the original code that attracted my 
attention (defined on one side, IS_ENABLED() on the other)... I'd be 
happier if both used the same approach.



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

[PATCH v2 5/5] drm/bridge/synopsys: dsi :remove is_panel_bridge

[Benjamin Gaignard]

When using drm_of_panel_bridge_remove() we can simplify the
code and remove is_panel_bridge from dw_mipi_dsi structure.

Signed-off-by: Benjamin Gaignard 
Reviewed-by: Philippe Cornu 
Tested-by: Philippe Cornu 
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index f4f633a..d9cca4f 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -221,7 +221,6 @@ struct dw_mipi_dsi {
struct drm_bridge bridge;
struct mipi_dsi_host dsi_host;
struct drm_bridge *panel_bridge;
-   bool is_panel_bridge;
struct device *dev;
void __iomem *base;
 
@@ -297,7 +296,6 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host 
*host,
bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DSI);
if (IS_ERR(bridge))
return PTR_ERR(bridge);
-   dsi->is_panel_bridge = true;
}
 
dsi->panel_bridge = bridge;
@@ -312,8 +310,7 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host 
*host,
 {
struct dw_mipi_dsi *dsi = host_to_dsi(host);
 
-   if (dsi->is_panel_bridge)
-   drm_panel_bridge_remove(dsi->panel_bridge);
+   drm_of_panel_bridge_remove(host->dev->of_node, 1, 0);
 
drm_bridge_remove(>bridge);
 
-- 
2.7.4

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

[PATCH v2 2/5] drm/drm_of: add drm_of_panel_bridge_remove function

[Benjamin Gaignard]

This function is the pendant of drm_of_find_panel_or_bridge()
to remove a previously allocated panel_bridge.
Given a specific port and endpoint it remove the panel bridge.
Since drm_panel_bridge_remove() will check that bridge parameter
is not NULL and is a real drm_panel_bridge and no a simple bridge
it is safe to call it directly.

Signed-off-by: Benjamin Gaignard 
Reviewed-by: Philippe Cornu 
Tested-by: Philippe Cornu 
---
 drivers/gpu/drm/drm_of.c | 33 +
 include/drm/drm_of.h |  8 
 2 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 8dafbdf..6b54f17 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -260,3 +260,36 @@ int drm_of_find_panel_or_bridge(const struct device_node 
*np,
return ret;
 }
 EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
+
+#ifdef CONFIG_DRM_PANEL_BRIDGE
+/*
+ * drm_of_panel_bridge_remove - remove panel bridge
+ * @np: device tree node containing panel bridge output ports
+ *
+ * Remove the panel bridge of a given DT node's port and endpoint number
+ *
+ * Returns zero if successful, or one of the standard error codes if it fails.
+ */
+int drm_of_panel_bridge_remove(const struct device_node *np,
+  int port, int endpoint)
+{
+   struct drm_bridge *bridge;
+   struct device_node *remote;
+
+   remote = of_graph_get_remote_node(np, port, endpoint);
+   if (!remote)
+   return -ENODEV;
+
+   bridge = of_drm_find_bridge(remote);
+   drm_panel_bridge_remove(bridge);
+
+   return 0;
+}
+#else
+int drm_of_panel_bridge_remove(const struct device_node *np,
+  int port, int endpoint)
+{
+   return -EINVAL;
+}
+#endif
+EXPORT_SYMBOL_GPL(drm_of_panel_bridge_remove);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 104dd51..390966e 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -29,6 +29,8 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
int port, int endpoint,
struct drm_panel **panel,
struct drm_bridge **bridge);
+int drm_of_panel_bridge_remove(const struct device_node *np,
+  int port, int endpoint);
 #else
 static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
  struct device_node *port)
@@ -65,6 +67,12 @@ static inline int drm_of_find_panel_or_bridge(const struct 
device_node *np,
 {
return -EINVAL;
 }
+
+static inline int drm_of_panel_bridge_remove(const struct device_node *np,
+int port, int endpoint)
+{
+   return -EINVAL;
+}
 #endif
 
 static inline int drm_of_encoder_active_endpoint_id(struct device_node *node,
-- 
2.7.4

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

[PATCH v2 3/5] drm/stm: ltdc: remove bridge from driver internal structure

[Benjamin Gaignard]

With a call to drm_of_panel_bridge_remove() we could remove the bridge
without store it in ldtc internal driver structure.

Signed-off-by: Benjamin Gaignard 
Reviewed-by: Philippe Cornu 
Tested-by: Philippe Cornu 
---
 drivers/gpu/drm/stm/ltdc.c | 16 +---
 drivers/gpu/drm/stm/ltdc.h |  2 --
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index d394a03..735c908 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -791,9 +791,8 @@ static const struct drm_encoder_funcs ltdc_encoder_funcs = {
.destroy = drm_encoder_cleanup,
 };
 
-static int ltdc_encoder_init(struct drm_device *ddev)
+static int ltdc_encoder_init(struct drm_device *ddev, struct drm_bridge 
*bridge)
 {
-   struct ltdc_device *ldev = ddev->dev_private;
struct drm_encoder *encoder;
int ret;
 
@@ -807,7 +806,7 @@ static int ltdc_encoder_init(struct drm_device *ddev)
drm_encoder_init(ddev, encoder, _encoder_funcs,
 DRM_MODE_ENCODER_DPI, NULL);
 
-   ret = drm_bridge_attach(encoder, ldev->bridge, NULL);
+   ret = drm_bridge_attach(encoder, bridge, NULL);
if (ret) {
drm_encoder_cleanup(encoder);
return -EINVAL;
@@ -936,12 +935,9 @@ int ltdc_load(struct drm_device *ddev)
ret = PTR_ERR(bridge);
goto err;
}
-   ldev->is_panel_bridge = true;
}
 
-   ldev->bridge = bridge;
-
-   ret = ltdc_encoder_init(ddev);
+   ret = ltdc_encoder_init(ddev, bridge);
if (ret) {
DRM_ERROR("Failed to init encoder\n");
goto err;
@@ -972,8 +968,7 @@ int ltdc_load(struct drm_device *ddev)
return 0;
 
 err:
-   if (ldev->is_panel_bridge)
-   drm_panel_bridge_remove(bridge);
+   drm_panel_bridge_remove(bridge);
 
clk_disable_unprepare(ldev->pixel_clk);
 
@@ -986,8 +981,7 @@ void ltdc_unload(struct drm_device *ddev)
 
DRM_DEBUG_DRIVER("\n");
 
-   if (ldev->is_panel_bridge)
-   drm_panel_bridge_remove(ldev->bridge);
+   drm_of_panel_bridge_remove(ddev->dev->of_node, 0, 0);
 
clk_disable_unprepare(ldev->pixel_clk);
 }
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index bc6d6f6..ae43755 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -24,8 +24,6 @@ struct ltdc_device {
struct drm_fbdev_cma *fbdev;
void __iomem *regs;
struct clk *pixel_clk;  /* lcd pixel clock */
-   struct drm_bridge *bridge;
-   bool is_panel_bridge;
struct mutex err_lock;  /* protecting error_status */
struct ltdc_caps caps;
u32 error_status;
-- 
2.7.4

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

[PATCH v2 4/5] drm/vc4: remove bridge from driver internal structure

[Benjamin Gaignard]

With a call to drm_of_panel_bridge_remove() we could remove
the bridge without store it in vc4_dpi internal driver structure.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/vc4/vc4_dpi.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index 519cefe..72c9dbd 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -97,8 +97,6 @@ struct vc4_dpi {
 
struct drm_encoder *encoder;
struct drm_connector *connector;
-   struct drm_bridge *bridge;
-   bool is_panel_bridge;
 
void __iomem *regs;
 
@@ -251,10 +249,11 @@ static int vc4_dpi_init_bridge(struct vc4_dpi *dpi)
 {
struct device *dev = >pdev->dev;
struct drm_panel *panel;
+   struct drm_bridge *bridge;
int ret;
 
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- , >bridge);
+ , );
if (ret) {
/* If nothing was connected in the DT, that's not an
 * error.
@@ -265,13 +264,10 @@ static int vc4_dpi_init_bridge(struct vc4_dpi *dpi)
return ret;
}
 
-   if (panel) {
-   dpi->bridge = drm_panel_bridge_add(panel,
-  DRM_MODE_CONNECTOR_DPI);
-   dpi->is_panel_bridge = true;
-   }
+   if (panel)
+   bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DPI);
 
-   return drm_bridge_attach(dpi->encoder, dpi->bridge, NULL);
+   return drm_bridge_attach(dpi->encoder, bridge, NULL);
 }
 
 static int vc4_dpi_bind(struct device *dev, struct device *master, void *data)
@@ -352,8 +348,7 @@ static void vc4_dpi_unbind(struct device *dev, struct 
device *master,
struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_dpi *dpi = dev_get_drvdata(dev);
 
-   if (dpi->is_panel_bridge)
-   drm_panel_bridge_remove(dpi->bridge);
+   drm_of_panel_bridge_remove(dev->of_node, 0, 0);
 
drm_encoder_cleanup(dpi->encoder);
 
-- 
2.7.4

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

[PATCH v2 0/5] Simplify panel bridge cleanup

[Benjamin Gaignard]

The goal of this series is to simplify driver code when they need to clean up
a previously allocated panel bridge.
Few drivers have "is_panel_bridge" flag to be able to distinguish a
drm_panel_bridge from "simple" drm_bridge.
To remove this flag I propose to
- let drm_panel_bridge_remove() check if the bridge provided in parameter is
  really a drm_panel_bridge.
- add drm_of_panel_bridge_remove() to remove a bridge given DT port and
  endpoint
Finally that allow to remove drm_bridge structure and "is_panel_bridge" flag
from stm driver internal structure.

version 2:
- does the same for vc4 and dw-mipi-dsi

Benjamin Gaignard (5):
  drm/bridge: make drm_panel_bridge_remove more robust
  drm/drm_of: add drm_of_panel_bridge_remove function
  drm/stm: ltdc: remove bridge from driver internal structure
  drm/vc4: remove bridge from driver internal structure
  drm/bridge/synopsys: dsi :remove is_panel_bridge

 drivers/gpu/drm/bridge/panel.c| 10 +++-
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c |  5 +---
 drivers/gpu/drm/drm_of.c  | 33 +++
 drivers/gpu/drm/stm/ltdc.c| 16 -
 drivers/gpu/drm/stm/ltdc.h|  2 --
 drivers/gpu/drm/vc4/vc4_dpi.c | 17 +-
 include/drm/drm_of.h  |  8 +++
 7 files changed, 62 insertions(+), 29 deletions(-)

-- 
2.7.4

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

[PATCH v2 1/5] drm/bridge: make drm_panel_bridge_remove more robust

[Benjamin Gaignard]

Make sure that bridge parameter is not NULL and can be safely
cast into a panel_bridge structure.

Signed-off-by: Benjamin Gaignard 
Reviewed-by: Philippe Cornu 
Tested-by: Philippe Cornu 
---
 drivers/gpu/drm/bridge/panel.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index e0cca19..6d99d4a 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -188,7 +188,15 @@ EXPORT_SYMBOL(drm_panel_bridge_add);
  */
 void drm_panel_bridge_remove(struct drm_bridge *bridge)
 {
-   struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
+   struct panel_bridge *panel_bridge;
+
+   if (!bridge)
+   return;
+
+   if (bridge->funcs != _bridge_bridge_funcs)
+   return;
+
+   panel_bridge = drm_bridge_to_panel_bridge(bridge);
 
drm_bridge_remove(bridge);
devm_kfree(panel_bridge->panel->dev, bridge);
-- 
2.7.4

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

Re: [PATCH v7 1/3] backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

[Jani Nikula]

On Mon, 02 Oct 2017, Daniel Thompson  wrote:
> So I'm coming to this patchset cold but can you explain *why* something 
> wants to call of_find_backlight_by_node() when there is no backlight 
> support enabled. Why isn't the code that called is conditional on 
> BACKLIGHT_CLASS_DEVICE?
>
> The undefined symbol issue is a pain but to be honest I'd rather solve 
> the use of undefined symbols by avoiding declaring them; this making 
> them into compile errors rather than link errors.

Typically the kernel header files define static inline stubs of the
functions when the actual functions aren't configured/built. The code
using the functions looks the same regardless of the config option, and
handles the -ENODEV or NULL or whatever returns from the stubs
gracefully. With the inlines, the compiler can usually throw out much of
the code anyway.

In this regard, the backlight interface is an exception, forcing the
callers to wrap the code around IS_ENABLED(BACKLIGHT_CLASS_DEVICE), not
the rule.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 1/3] backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

[Jani Nikula]

On Mon, 02 Oct 2017, Daniel Thompson  wrote:
> On 01/10/17 18:26, Meghana Madhyastha wrote:
>> -#ifdef CONFIG_OF
>> +#if defined CONFIG_OF && IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
>
> The above comments are more important but why does this mix defined and 
> IS_ENABLED? Couldn't they both use defined (and preferably with the 
> optional brackets around the CONFIG_ symbol).

No, always use IS_ENABLED() for tristates when you want to match 'y' or
'm'.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH hwc v3 0/6] Implement fencing

[Robert Foss]

Series pushed.

On Thu, 2017-09-28 at 18:40 +0200, Robert Foss wrote:
> This series removes the old thread-based synchronization utilities
> and
> replaces them with fences.
> 
> It has been tested on various platforms, including
> etnaviv/freedreno/virgl.
> 
> Robert Foss (5):
>   drm_hwcomposer: Add support for IN_FENCE_FD property to DrmPlane
>   drm_hwcomposer: Submit in-fence to DRM
>   drm_hwcomposer: Add FENCE_OUT_PTR property to DrmCrtc
>   drm_hwcomposer: Add crtc() fetcher to DrmResources
>   drm_hwcomposer: Add out-fence support
> 
> Sean Paul (1):
>   drm_hwcomposer: Remove threading
> 
>  Android.mk|   3 -
>  drmcomposition.cpp| 166 
>  drmcomposition.h  |  79 ---
>  drmcompositor.cpp | 106 
>  drmcompositor.h   |  56 ---
>  drmcompositorworker.h |  41 
>  drmcrtc.cpp   |  10 ++
>  drmcrtc.h |   2 +
>  drmdisplaycomposition.cpp |   1 +
>  drmdisplaycomposition.h   |  19 
>  drmdisplaycompositor.cpp  | 239 +---
> --
>  drmdisplaycompositor.h|  36 +--
>  drmeventlistener.cpp  |   3 +
>  drmhwctwo.cpp |  15 +--
>  drmplane.cpp  |   8 ++
>  drmplane.h|   2 +
>  drmresources.cpp  |  58 +--
>  drmresources.h|   6 +-
>  glworker.cpp  |  52 +-
>  glworker.h|  10 ++
>  20 files changed, 162 insertions(+), 750 deletions(-)
>  delete mode 100644 drmcomposition.cpp
>  delete mode 100644 drmcomposition.h
>  delete mode 100644 drmcompositor.cpp
>  delete mode 100644 drmcompositor.h
>  delete mode 100644 drmcompositorworker.h
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] MAINTAINERS: Add dri-devel as a mailing list for anything fbdev

[Daniel Vetter]

On Fri, Sep 08, 2017 at 11:39:44AM -0400, Sean Paul wrote:
> On Fri, Sep 8, 2017 at 11:35 AM, Daniel Vetter  wrote:
> > fbdev is in maintenance only, except that it's still used by drm
> > through the drm fbdev emulation, to be able to use fbcon. And people
> > might want to sometimes extend fbcon to enable new features for drm
> > drivers, e.g. Hans' panel orientation work.
> >
> > The problem is that when those patches only touch fbdev code they'll
> > never show up on drm developer's radar, which means we end up with
> > designs that don't really fit whell into the full stack. That happened
> > a bit with the panel orientation work, where an fbcon patch made it
> > into 4.14, implementing a design that won't really work on the drm
> > side. Which means we now have to redo things, and on top coordinate 2
> > subsystem trees.
> >
> > Since fbdev is super low-volume we can prevent this in the future by
> > simply adding the dri-devel mailing list to the fbdev subsystem.
> >
> > Cc: Hans de Goede 
> > Cc: Bartlomiej Zolnierkiewicz 
> > Cc: linux-fb...@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Sean Paul 
> 
> Acked-by: Sean Paul 

Bartlomiej, ack from you too?

Thanks, Daniel
> 
> > Cc: David Airlie 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  MAINTAINERS | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index ba51d0906955..af9766a32949 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -5391,6 +5391,7 @@ F:drivers/net/wan/sdla.c
> >
> >  FRAMEBUFFER LAYER
> >  M: Bartlomiej Zolnierkiewicz 
> > +L: dri-devel@lists.freedesktop.org
> >  L: linux-fb...@vger.kernel.org
> >  T: git git://github.com/bzolnier/linux.git
> >  Q: http://patchwork.kernel.org/project/linux-fbdev/list/
> > --
> > 2.14.1
> >

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/18] drm: use ARRAY_SIZE

[Thierry Reding]

On Sun, Oct 01, 2017 at 03:30:44PM -0400, Jérémy Lefaure wrote:
> Using the ARRAY_SIZE macro improves the readability of the code. Also,
> it is not always useful to use a variable to store this constant
> calculated at compile time nor to re-invent the ARRAY_SIZE macro.
> 
> Found with Coccinelle with the following semantic patch:
> @r depends on (org || report)@
> type T;
> T[] E;
> position p;
> @@
> (
>  (sizeof(E)@p /sizeof(*E))
> |
>  (sizeof(E)@p /sizeof(E[...]))
> |
>  (sizeof(E)@p /sizeof(T))
> )
> 
> Signed-off-by: Jérémy Lefaure 
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  9 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   |  9 +
>  drivers/gpu/drm/gma500/psb_intel_sdvo.c |  9 -
>  drivers/gpu/drm/i915/gvt/vgpu.c |  3 ++-
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c |  7 ---
>  drivers/gpu/drm/via/via_verifier.c  | 10 --
>  6 files changed, 24 insertions(+), 23 deletions(-)

Reviewed-by: Thierry Reding 


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

Re: [PATCH v2 4/4] drm/fb-helper: Apply panel orientation connector prop to the primary plane

[Daniel Vetter]

On Sun, Oct 01, 2017 at 05:33:17PM +0200, Hans de Goede wrote:
> Apply the "panel orientation" drm connector prop to the primary plane,
> so that fbcon and fbdev using userspace programs display the right way
> up.
> 
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -New patch in v2 of this patch-set
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 53 
> +++--
>  1 file changed, 51 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 1b8f013ffa65..75c409430a26 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -41,6 +41,7 @@
>  #include 
>  #include 
>  
> +#include "drm_crtc_internal.h"
>  #include "drm_crtc_helper_internal.h"
>  
>  static bool drm_fbdev_emulation = true;
> @@ -347,6 +348,53 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
>  }
>  EXPORT_SYMBOL(drm_fb_helper_debug_leave);
>  
> +static int get_plane_rotation_from_panel_orientation(
> + struct drm_fb_helper *fb_helper, struct drm_plane *plane)
> +{
> + int i, rotation = DRM_MODE_ROTATE_0;
> + struct drm_connector *conn;
> + uint64_t valid_mask = 0;
> +
> + drm_fb_helper_for_each_connector(fb_helper, i) {
> + conn = fb_helper->connector_info[i]->connector;
> + if (conn->state->crtc && conn->state->crtc->primary == plane) {
> + switch (conn->display_info.panel_orientation) {
> + case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
> + rotation = DRM_MODE_ROTATE_180;
> + break;
> + case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
> + rotation = DRM_MODE_ROTATE_90;
> + break;
> + case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
> + rotation = DRM_MODE_ROTATE_270;
> + break;
> + }
> + break;
> + }
> + }
> +
> + /*
> +  * Check the necessary rotation to compensate for the panel orientation
> +  * is supported.
> +  * Note currently we simply leave things as is when not supported, maybe
> +  * we shouls set a hint in fb_info to tell fbcon to rotate in this case
> +  * so that atleast the console ends up the right way. Maybe, but this:
> +  * a) Is not necessary for any known models with a non upright panel
> +  * b) Is tricky because fbcon rotation applies to all outputs rather
> +  *then a single one
> +  */
> + if (!plane->rotation_property)
> + return DRM_MODE_ROTATE_0;
> +
> + for (i = 0; i < plane->rotation_property->num_values; i++)
> + valid_mask |= (1ULL << plane->rotation_property->values[i]);
> +
> + if (rotation & ~valid_mask)
> + return DRM_MODE_ROTATE_0;
> +
> + return rotation;
> +}
> +
>  static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool 
> active)
>  {
>   struct drm_device *dev = fb_helper->dev;
> @@ -376,8 +424,9 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
> *fb_helper, bool activ
>   goto out_state;
>   }
>  
> - plane_state->rotation = DRM_MODE_ROTATE_0;
> -
> + plane_state->rotation =
> + get_plane_rotation_from_panel_orientation(fb_helper,
> +   plane);

This is the loop to reset all the planes to default values, feels a bit
awkward to change the rotation value in there. Also gives you that
unpretty loop to check you're on the right plane.

I think a cleaner way to do this would be:
- add a rotation member to struct drm_fb_helper_crtc
- set that when setting up the configuration drm_setup_crtcs
- look up crtc->primary plane_state and set it int the loop below this one
  here (which is the one that actually sets the mode)

Cheers, Daniel
>   plane->old_fb = plane->fb;
>   plane_mask |= 1 << drm_plane_index(plane);
>  
> -- 
> 2.14.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/2] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

[Jani Nikula]

On Mon, 02 Oct 2017, Daniel Vetter  wrote:
> Also adding Jani, who looked at the backlight Kconfig mess in the past.

I've even sent patches to fix some of the dependency mess, but the
problem is social not technical. The problem is that people think
"select" is more convenient than "depends" because they can just enable
a config that way, while "depends" would require finding and enabling
all the dependencies before the menu option even shows up.

I don't deny, that's annoying. But it's also abuse of select, see
Documentation/kbuild/kconfig-language.txt:

  Note:
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.

The real fix would be making finding and enabling dependencies
recursively more convenient, but I don't see that happening anytime
soon.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/4] drm/i915: Add "panel orientation" property to the panel connector

[Daniel Vetter]

On Sun, Oct 01, 2017 at 05:33:16PM +0200, Hans de Goede wrote:
> Ideally we could use the VBT for this, that would be simple, in
> intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
> connector->display_info.panel_orientation accordingly and call
> drm_connector_init_panel_orientation_property(), done.
> 
> Unfortunately vbt.dsi.config->rotation is always 0 even on tablets
> with an upside down LCD and where the GOP is properly rotating the
> EFI fb in hardware.
> 
> So instead we end up reading the rotation from the primary plane,
> which is a bit more complicated.
> 
> The code to read back the rotation from the hardware is based on an
> earlier attempt to fix fdo#94894 by Ville Syrjala.
> 
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
> Cc: Ville Syrjala 
> Suggested-by: Ville Syrjala 
> Signed-off-by: Hans de Goede 

This patch looks a bit like it tries to maximize layering violations:

- store panel state in plane_state
- digg a hole from global code to set up panel information

Can't we do this in a better way? I'm thinking of something mimicking the
fixed mode readout, which is also not driven in a backwards way like this.
I.e. a small helper in intel_panel.c which reads out the rotation of the
primary panel and hopes for the best.

Plus ofc taking the quirk list into account.

Also, how exactly does the GOP figure out we need to rotate?
-Daniel

> ---
> Changes in v2:
> -Rebased on 4.14-rc1
> -Readback primary plane rotation from the hardware and use that to
>  set the panel orientation
> -This (readback) fixes fdo#94894, add Fixes: tag
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  3 +++
>  drivers/gpu/drm/i915/intel_display.c | 39 
> +++-
>  drivers/gpu/drm/i915/intel_drv.h |  5 +
>  drivers/gpu/drm/i915/intel_panel.c   | 33 ++
>  4 files changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 18d9da53282b..c4c8590972b4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2151,6 +2151,8 @@ struct intel_cdclk_state {
>   unsigned int cdclk, vco, ref;
>  };
>  
> +struct intel_panel;
> +
>  struct drm_i915_private {
>   struct drm_device drm;
>  
> @@ -2200,6 +2202,7 @@ struct drm_i915_private {
>   struct i915_gem_context *kernel_context;
>   struct intel_engine_cs *engine[I915_NUM_ENGINES];
>   struct i915_vma *semaphore;
> + struct intel_panel *panel;
>  
>   struct drm_dma_handle *status_page_dmah;
>   struct resource mch_res;
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 00cd17c76fdc..fbd61f92b60d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2891,6 +2891,9 @@ intel_find_initial_plane_obj(struct intel_crtc 
> *intel_crtc,
>   return;
>   }
>  
> + intel_panel_set_orientation_from_crtc(dev_priv->panel, intel_crtc,
> +   plane_config->panel_orientation);
> +
>   plane_state->src_x = 0;
>   plane_state->src_y = 0;
>   plane_state->src_w = fb->width << 16;
> @@ -7523,6 +7526,10 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
>   plane_config->tiling = I915_TILING_X;
>   fb->modifier = I915_FORMAT_MOD_X_TILED;
>   }
> +
> + if (val & DISPPLANE_ROTATE_180)
> + plane_config->panel_orientation =
> + DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
>   }
>  
>   pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
> @@ -8576,6 +8583,24 @@ skylake_get_initial_plane_config(struct intel_crtc 
> *crtc,
>   goto error;
>   }
>  
> + /* The rotation is used to *correct* for the panel orientation */
> + switch (val & PLANE_CTL_ROTATE_MASK) {
> + case PLANE_CTL_ROTATE_0:
> + break;
> + case PLANE_CTL_ROTATE_90:
> + plane_config->panel_orientation =
> + DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
> + break;
> + case PLANE_CTL_ROTATE_180:
> + plane_config->panel_orientation =
> + DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
> + break;
> + case PLANE_CTL_ROTATE_270:
> + plane_config->panel_orientation =
> + DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
> + break;
> + }
> +
>   base = I915_READ(PLANE_SURF(pipe, 0)) & 0xf000;
>   plane_config->base = base;
>  
> @@ -8661,6 +8686,10 @@ ironlake_get_initial_plane_config(struct intel_crtc 
> *crtc,
>   plane_config->tiling = I915_TILING_X;
>   fb->modifier = I915_FORMAT_MOD_X_TILED;
>   }
> +
> + if (val & 

Re: [PATCH v2 1/4] video: fb: Make fbcon dmi quirks usuable for drm drivers too

[Daniel Vetter]

On Sun, Oct 01, 2017 at 05:33:14PM +0200, Hans de Goede wrote:
> Some x86 clamshell design devices use portrait tablet LCD panels and a
> display engine which cannot (transparently) rotate in hardware, so we
> need to rotate things in software / let user space deal with this.
> 
> The fbcon code has a set of DMI based quirks to automatically detect
> such tablet LCD panels and rotate the fbcon to compensate.
> 
> The plan was for userspace (e.g. a Wayland compositor) to simply read
> /sys/class/graphics/fbcon/rotate and apply the rotation from there to
> the LCD panel to compensate.
> 
> However this will not work when an external monitor gets plugged in,
> since with fbcon rotation is not per output, so the fbcon quirk code
> disables the rotation when an external monitor is present.
> 
> Using /sys/class/graphics/fbcon/rotate will not help in that case
> since it will indicate no rotation is in use. So instead we are going
> to need a drm connecter property for this.
> 
> This commit is a preparation patch for adding the drm-connecter
> property, by making the fbcon quirk code generally usable so that
> the drm code can use it to check for rotation quirks.
> 
> Note this commit re-uses the FB_CMDLINE Kconfig option for selecting
> if the quirk code should be build, since that is already selected by
> both the drm and fbcon code.
> 
> Signed-off-by: Hans de Goede 

Can we pls just outright move this out of fbdev? fbdev is dead, I don't
want to add/maintain new stuff in there (except fbcon, but that should not
deal with stuff like this).

This probably means some serious patch series acrobatics, or just breaking
the current fbcon-only hack and rebuilding it in drm (in the same series).
-Daniel

> ---
> Changes in v2:
> -Rebased on 4.14-rc1
> ---
>  drivers/video/fbdev/core/Makefile  |  6 +++---
>  .../core/{fbcon_dmi_quirks.c => fb_dmi_quirks.c}   | 15 +--
>  drivers/video/fbdev/core/fbcon.c   | 22 
> ++
>  drivers/video/fbdev/core/fbcon.h   |  6 --
>  include/linux/fb.h |  6 ++
>  5 files changed, 32 insertions(+), 23 deletions(-)
>  rename drivers/video/fbdev/core/{fbcon_dmi_quirks.c => fb_dmi_quirks.c} (91%)
> 
> diff --git a/drivers/video/fbdev/core/Makefile 
> b/drivers/video/fbdev/core/Makefile
> index 73493bbd7a15..06caf037a822 100644
> --- a/drivers/video/fbdev/core/Makefile
> +++ b/drivers/video/fbdev/core/Makefile
> @@ -1,4 +1,7 @@
>  obj-$(CONFIG_FB_CMDLINE)  += fb_cmdline.o
> +ifeq ($(CONFIG_DMI),y)
> +obj-$(CONFIG_FB_CMDLINE)  += fb_dmi_quirks.o
> +endif
>  obj-$(CONFIG_FB_NOTIFY)   += fb_notify.o
>  obj-$(CONFIG_FB)  += fb.o
>  fb-y  := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
> @@ -14,9 +17,6 @@ ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE_ROTATION),y)
>  fb-y   += fbcon_rotate.o fbcon_cw.o fbcon_ud.o \
>fbcon_ccw.o
>  endif
> -ifeq ($(CONFIG_DMI),y)
> -fb-y   += fbcon_dmi_quirks.o
> -endif
>  endif
>  fb-objs   := $(fb-y)
>  
> diff --git a/drivers/video/fbdev/core/fbcon_dmi_quirks.c 
> b/drivers/video/fbdev/core/fb_dmi_quirks.c
> similarity index 91%
> rename from drivers/video/fbdev/core/fbcon_dmi_quirks.c
> rename to drivers/video/fbdev/core/fb_dmi_quirks.c
> index 6904e47d1e51..d5fdf3245f83 100644
> --- a/drivers/video/fbdev/core/fbcon_dmi_quirks.c
> +++ b/drivers/video/fbdev/core/fb_dmi_quirks.c
> @@ -1,5 +1,5 @@
>  /*
> - *  fbcon_dmi_quirks.c -- DMI based quirk detection for fbcon
> + *  fb_dmi_quirks.c -- DMI based LCD panel rotation quirk detection
>   *
>   *   Copyright (C) 2017 Hans de Goede 
>   *
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include "fbcon.h"
>  
>  /*
>   * Some x86 clamshell design devices use portrait tablet screens and a 
> display
> @@ -112,7 +111,11 @@ static const struct dmi_system_id rotate_data[] = {
>   {}
>  };
>  
> -int fbcon_platform_get_rotate(struct fb_info *info)
> +/*
> + * Note this function returns the rotation necessary to put the display
> + * the right way up, or -1 if there is no quirk.
> + */
> +int fb_get_panel_rotate_quirk(int width, int height)
>  {
>   const struct dmi_system_id *match;
>   const struct fbcon_dmi_rotate_data *data;
> @@ -124,8 +127,7 @@ int fbcon_platform_get_rotate(struct fb_info *info)
>match = dmi_first_match(match + 1)) {
>   data = match->driver_data;
>  
> - if (data->width != info->var.xres ||
> - data->height != info->var.yres)
> + if (data->width != width || data->height != height)
>   continue;
>  
>   if (!data->bios_dates)
> @@ -141,5 +143,6 @@ int fbcon_platform_get_rotate(struct fb_info *info)
>   }
>   }
>  
> - return FB_ROTATE_UR;
> +

Re: [PATCH v5 4/4] drm/tinydrm: select BACKLIGHT_LCD_SUPPORT, BACKLIGHT_CLASS_DEVICE

[Daniel Vetter]

On Sat, Sep 30, 2017 at 03:49:43PM +0200, Noralf Trønnes wrote:
> 
> Den 30.09.2017 11.10, skrev Meghana Madhyastha:
> > Add select BACKLIGHT_LCD_SUPPORT, BACKLIGHT_CLASS_DEVICE to
> > the Kconfig of drm. This is required for the successful build of
> > drm_of_find_backlight helpers.
> > 
> > Signed-off-by: Meghana Madhyastha 
> > ---
> > Changes in v5:
> > -This commit was not present in v4. Selecting BACKLIGHT_LCD_SUPPORT,
> > BACKLIGHT_CLASS_DEVICE in the Kconfig file under the symbol DRM seems
> > to fix the Kbuild error drm_of.c:(.text+0x3bc): undefined reference to
> > `of_find_backlight_by_node'.
> > 
> >   drivers/gpu/drm/Kconfig | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 83cb2a8..3ba5632 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -7,6 +7,8 @@
> >   menuconfig DRM
> > tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
> > support)"
> > depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
> > +   select BACKLIGHT_LCD_SUPPORT
> > +   select BACKLIGHT_CLASS_DEVICE
> > select HDMI
> > select FB_CMDLINE
> > select I2C
> 
> A night's sleep has made this more clear, we don't need 'depends on'
> or select as you have tried here, it's enough that we make a change in
> the backlight subsystem as I outlined earlier:
> 
> include/linux/backlight.h:
> 
> -#ifdef CONFIG_OF
> +#if defined(CONFIG_OF) && IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
>  struct backlight_device *of_find_backlight_by_node(struct device_node
> *node);
>  #else
>  static inline struct backlight_device *
>  of_find_backlight_by_node(struct device_node *node)
>  {
>  return NULL;
>  }
>  #endif
> 
> Now we don't have to care about backlight being built-in, module or
> disabled.
> 
> This patch has to be the first in the patchset. No single patch can break
> anything
> even if it's fixed later. This is so people can bisect.

Adding Jani to double-check this plan ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 3/3] drm/tinydrm: Add the dummy versions of drm_of_find_backlight functions

[Daniel Vetter]

On Sat, Sep 30, 2017 at 01:18:53PM +0800, kbuild test robot wrote:
> Hi Meghana,
> 
> [auto build test WARNING on drm/drm-next]
> [also build test WARNING on v4.14-rc2 next-20170929]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Meghana-Madhyastha/drm-tinydrm-drm_of_find_backlight-helper/20170930-122931
> base:   git://people.freedesktop.org/~airlied/linux.git drm-next
> config: x86_64-randconfig-x017-201739 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All warnings (new ones prefixed by >>):
> 
>In file included from drivers/gpu//drm/tinydrm/mi0283qt.c:15:0:
>include/drm/drm_of.h:74:1: error: expected identifier or '(' before '{' 
> token
> {
> ^
>include/drm/drm_of.h:80:1: error: expected identifier or '(' before '{' 
> token
> {
> ^
>include/drm/drm_of.h:72:40: warning: 'drm_of_find_backlight' declared 
> 'static' but never defined [-Wunused-function]
> static inline struct backlight_device *drm_of_find_backlight(
>^
> >> include/drm/drm_of.h:78:40: warning: 'devm_drm_of_find_backlight' used but 
> >> never defined
> static inline struct backlight_device *devm_drm_of_find_backlight(

You need to squash the dummy version into the patch that introduces the
first usage, otherwise compilation can fail and break bisecting. And looks
liek this doesn't compile. It takes a bit of playing around until you have
a Kconfig that hits this. Luckily 0day has constructed one for you
already.
-Daniel

>^~
> 
> vim +/devm_drm_of_find_backlight +78 include/drm/drm_of.h
> 
> 71
> 72static inline struct backlight_device *drm_of_find_backlight(
> 73struct device *dev);
>   > 74{
> 75return -EINVAL;
> 76}
> 77
>   > 78static inline struct backlight_device 
> *devm_drm_of_find_backlight(
> 79struct device 
> *dev);
> 80{
> 81return -EINVAL;
> 82}
> 83#endif
> 84
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] Simplify panel bridge cleanup

[Daniel Vetter]

On Fri, Sep 29, 2017 at 03:03:54PM +, Philippe CORNU wrote:
> Hi Benjamin,
> and many thanks for this cleanup patchset.
> 
> Reviewed-by: Philippe Cornu 
> Tested-by: Philippe Cornu 

Can you pls either convert vc4 and dw-mipi too, or add an entry to our
todo list in Documentation/gpu/todo.rst?

Thanks, Daniel

> 
> Philippe :-)
> 
> On 09/29/2017 02:59 PM, Benjamin Gaignard wrote:
> > The goal of this series is to simplify driver code when they need to clean 
> > up
> > a previously allocated panel bridge.
> > Few drivers have "is_panel_bridge" flag to be able to distinguish a
> > drm_panel_bridge from "simple" drm_bridge.
> > To remove this flag I propose to
> > - let drm_panel_bridge_remove() check if the bridge provided in parameter is
> >really a drm_panel_bridge.
> > - add drm_of_panel_bridge_remove() to remove a bridge given DT port and
> >endpoint
> > Finally that allow to remove drm_bridge structure and "is_panel_bridge" flag
> > from stm driver internal structure.
> > 
> > Benjamin Gaignard (3):
> >drm/bridge: make drm_panel_bridge_remove more robust
> >drm/drm_of: add drm_of_panel_bridge_remove function
> >drm/stm: ltdc: remove bridge from driver internal structure
> > 
> >   drivers/gpu/drm/bridge/panel.c | 10 +-
> >   drivers/gpu/drm/drm_of.c   | 33 +
> >   drivers/gpu/drm/stm/ltdc.c | 16 +---
> >   drivers/gpu/drm/stm/ltdc.h |  2 --
> >   include/drm/drm_of.h   |  8 
> >   5 files changed, 55 insertions(+), 14 deletions(-)
> > 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/virtio: Replace instances of reference/unreference with get/put

[Daniel Vetter]

On Fri, Sep 29, 2017 at 03:33:39PM +0530, Srishti Sharma wrote:
> Replace reference/unreference with get/put as it is consistent
> with the kernel coding style. Done using the following semantic
> patch by coccinelle.
> 
> @r@
> expression e;
> @@
> 
> -drm_gem_object_unreference_unlocked(e);
> +drm_gem_object_put_unlocked(e);
> 
> Signed-off-by: Srishti Sharma 

Applied to drm-misc-next, thanks.
-Daniel

> ---
>  drivers/gpu/drm/virtio/virtgpu_display.c |  4 ++--
>  drivers/gpu/drm/virtio/virtgpu_gem.c |  4 ++--
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c   | 12 ++--
>  3 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index b6d5205..41b0930 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -53,7 +53,7 @@ static void virtio_gpu_user_framebuffer_destroy(struct 
> drm_framebuffer *fb)
>   struct virtio_gpu_framebuffer *virtio_gpu_fb
>   = to_virtio_gpu_framebuffer(fb);
>  
> - drm_gem_object_unreference_unlocked(virtio_gpu_fb->obj);
> + drm_gem_object_put_unlocked(virtio_gpu_fb->obj);
>   drm_framebuffer_cleanup(fb);
>   kfree(virtio_gpu_fb);
>  }
> @@ -327,7 +327,7 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
>   ret = virtio_gpu_framebuffer_init(dev, virtio_gpu_fb, mode_cmd, obj);
>   if (ret) {
>   kfree(virtio_gpu_fb);
> - drm_gem_object_unreference_unlocked(obj);
> + drm_gem_object_put_unlocked(obj);
>   return NULL;
>   }
>  
> diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c 
> b/drivers/gpu/drm/virtio/virtgpu_gem.c
> index 72ad7b1..92fb277 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_gem.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
> @@ -72,7 +72,7 @@ int virtio_gpu_gem_create(struct drm_file *file,
>   *obj_p = >gem_base;
>  
>   /* drop reference from allocate - handle holds it now */
> - drm_gem_object_unreference_unlocked(>gem_base);
> + drm_gem_object_put_unlocked(>gem_base);
>  
>   *handle_p = handle;
>   return 0;
> @@ -130,7 +130,7 @@ int virtio_gpu_mode_dumb_mmap(struct drm_file *file_priv,
>   return -ENOENT;
>   obj = gem_to_virtio_gpu_obj(gobj);
>   *offset_p = virtio_gpu_object_mmap_offset(obj);
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index b94bd54..0528edb 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -86,7 +86,7 @@ static void virtio_gpu_unref_list(struct list_head *head)
>   bo = buf->bo;
>   qobj = container_of(bo, struct virtio_gpu_object, tbo);
>  
> - drm_gem_object_unreference_unlocked(>gem_base);
> + drm_gem_object_put_unlocked(>gem_base);
>   }
>  }
>  
> @@ -304,7 +304,7 @@ static int virtio_gpu_resource_create_ioctl(struct 
> drm_device *dev, void *data,
>   }
>   return ret;
>   }
> - drm_gem_object_unreference_unlocked(obj);
> + drm_gem_object_put_unlocked(obj);
>  
>   rc->res_handle = res_id; /* similiar to a VM address */
>   rc->bo_handle = handle;
> @@ -341,7 +341,7 @@ static int virtio_gpu_resource_info_ioctl(struct 
> drm_device *dev, void *data,
>  
>   ri->size = qobj->gem_base.size;
>   ri->res_handle = qobj->hw_res_handle;
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
>   return 0;
>  }
>  
> @@ -389,7 +389,7 @@ static int virtio_gpu_transfer_from_host_ioctl(struct 
> drm_device *dev,
>  out_unres:
>   virtio_gpu_object_unreserve(qobj);
>  out:
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
>   return ret;
>  }
>  
> @@ -439,7 +439,7 @@ static int virtio_gpu_transfer_to_host_ioctl(struct 
> drm_device *dev, void *data,
>  out_unres:
>   virtio_gpu_object_unreserve(qobj);
>  out:
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
>   return ret;
>  }
>  
> @@ -462,7 +462,7 @@ static int virtio_gpu_wait_ioctl(struct drm_device *dev, 
> void *data,
>   nowait = true;
>   ret = virtio_gpu_object_wait(qobj, nowait);
>  
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
>   return ret;
>  }
>  
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/2] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

[Daniel Vetter]

On Fri, Sep 29, 2017 at 05:41:04PM +0200, Noralf Trønnes wrote:
> 
> Den 29.09.2017 16.13, skrev Meghana Madhyastha:
> > On Fri, Sep 29, 2017 at 02:33:12PM +0200, Noralf Trønnes wrote:
> > > Den 29.09.2017 14.20, skrev Meghana Madhyastha:
> > > > On Fri, Sep 29, 2017 at 02:10:31PM +0200, Noralf Trønnes wrote:
> > > > > Den 29.09.2017 05.22, skrev Meghana Madhyastha:
> > > > > > On Thu, Sep 28, 2017 at 06:02:27PM +0200, Noralf Trønnes wrote:
> > > > > > > Den 28.09.2017 16.08, skrev Daniel Vetter:
> > > > > > > > On Thu, Sep 28, 2017 at 02:44:34PM +0530, Meghana Madhyastha 
> > > > > > > > wrote:
> > > > > > > > > Rename tinydrm_of_find_backlight to drm_of_find_backlight
> > > > > > > > > and move it into drm_of.c from tinydrm-helpers.c. This is
> > > > > > > > > because other drivers in the drm subsystem might need to call
> > > > > > > > > this function. In that case and otherwise, it is better from
> > > > > > > > > an organizational point of view to move it into drm_of.c along
> > > > > > > > > with the other _of.c functions.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Meghana Madhyastha 
> > > > > > > > > 
> > > > > > > > > ---
> > > > > > > > > Changes in v3:
> > > > > > > > > -Change it back to a single patch from two patches in v2
> > > > > > > > > 
> > > > > > > > >   drivers/gpu/drm/drm_of.c   | 44 
> > > > > > > > > ++
> > > > > > > > >   drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 
> > > > > > > > > ---
> > > > > > > > >   drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
> > > > > > > > >   include/drm/drm_of.h   |  1 +
> > > > > > > > >   include/drm/tinydrm/tinydrm-helpers.h  |  1 -
> > > > > > > > >   5 files changed, 47 insertions(+), 42 deletions(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/gpu/drm/drm_of.c 
> > > > > > > > > b/drivers/gpu/drm/drm_of.c
> > > > > > > > > index 8dafbdf..d878d3a 100644
> > > > > > > > > --- a/drivers/gpu/drm/drm_of.c
> > > > > > > > > +++ b/drivers/gpu/drm/drm_of.c
> > > > > > > > > @@ -1,6 +1,7 @@
> > > > > > > > >   #include 
> > > > > > > > >   #include 
> > > > > > > > >   #include 
> > > > > > > > > +#include 
> > > > > > > > >   #include 
> > > > > > > > >   #include 
> > > > > > > > >   #include 
> > > > > > > > > @@ -260,3 +261,46 @@ int drm_of_find_panel_or_bridge(const 
> > > > > > > > > struct device_node *np,
> > > > > > > > >   return ret;
> > > > > > > > >   }
> > > > > > > > >   EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
> > > > > > > > > +
> > > > > > > > > +/**
> > > > > > > > > + * drm_of_find_backlight - Find backlight device in 
> > > > > > > > > device-tree
> > > > > > > > > + * @dev: Device
> > > > > > > > > + *
> > > > > > > > > + * This function looks for a DT node pointed to by a 
> > > > > > > > > property named 'backlight'
> > > > > > > > > + * and uses of_find_backlight_by_node() to get the backlight 
> > > > > > > > > device.
> > > > > > > > > + * Additionally if the brightness property is zero, it is 
> > > > > > > > > set to
> > > > > > > > > + * max_brightness.
> > > > > > > > > + *
> > > > > > > > > + * Note: It is the responsibility of the caller to call 
> > > > > > > > > put_device() when
> > > > > > > > > + * releasing the resource.
> > > > > > > > > + *
> > > > > > > > > + * Returns:
> > > > > > > > > + * NULL if there's no backlight property.
> > > > > > > > > + * Error pointer -EPROBE_DEFER if the DT node is found, but 
> > > > > > > > > no backlight device
> > > > > > > > > + * is found.
> > > > > > > > > + * If the backlight device is found, a pointer to the 
> > > > > > > > > structure is returned.
> > > > > > > > > + */
> > > > > > > > > +struct backlight_device *drm_of_find_backlight(struct device 
> > > > > > > > > *dev)
> > > > > > > > > +{
> > > > > > > > > + struct backlight_device *backlight;
> > > > > > > > > + struct device_node *np;
> > > > > > > > > +
> > > > > > > > > + np = of_parse_phandle(dev->of_node, "backlight", 0);
> > > > > > > > > + if (!np)
> > > > > > > > > + return NULL;
> > > > > > > > > +
> > > > > > > > > + backlight = of_find_backlight_by_node(np);
> > > > > > > > > + of_node_put(np);
> > > > > > > > > +
> > > > > > > > > + if (!backlight)
> > > > > > > > > + return ERR_PTR(-EPROBE_DEFER);
> > > > > > > > > +
> > > > > > > > > + if (!backlight->props.brightness) {
> > > > > > > > > + backlight->props.brightness = 
> > > > > > > > > backlight->props.max_brightness;
> > > > > > > > > + DRM_DEBUG_KMS("Backlight brightness set to 
> > > > > > > > > %d\n",
> > > > > > > > > +   backlight->props.brightness);
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + return backlight;
> > > > > > > > > +}
> > > > > > > > > +EXPORT_SYMBOL(drm_of_find_backlight);
> 
> 
> 
> > > > > > > Another problem I discovered 

Re: [PATCH 06/18] drm: use ARRAY_SIZE

[Jani Nikula]

On Sun, 01 Oct 2017, Jérémy Lefaure  wrote:
> Using the ARRAY_SIZE macro improves the readability of the code. Also,
> it is not always useful to use a variable to store this constant
> calculated at compile time nor to re-invent the ARRAY_SIZE macro.
>
> Found with Coccinelle with the following semantic patch:
> @r depends on (org || report)@
> type T;
> T[] E;
> position p;
> @@
> (
>  (sizeof(E)@p /sizeof(*E))
> |
>  (sizeof(E)@p /sizeof(E[...]))
> |
>  (sizeof(E)@p /sizeof(T))
> )
>
> Signed-off-by: Jérémy Lefaure 

Please split this up.

Patch 1:
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  9 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   |  9 +

Patch 2:
>  drivers/gpu/drm/gma500/psb_intel_sdvo.c |  9 -

Patch 3:
>  drivers/gpu/drm/i915/gvt/vgpu.c |  3 ++-

Patch 4:
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c |  7 ---

Patch 5:
>  drivers/gpu/drm/via/via_verifier.c  | 10 --

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/armada: Remove unused #include

[Daniel Vetter]

On Sat, Sep 30, 2017 at 12:34:40PM -0600, Haneen Mohammed wrote:
> On Fri, Sep 29, 2017 at 02:29:31PM +0200, Noralf Trønnes wrote:
> > 
> > Den 29.09.2017 09.25, skrev Daniel Vetter:
> > >On Wed, Sep 27, 2017 at 01:38:46AM -0600, Haneen Mohammed wrote:
> > >>Remove drmP.h as it is not needed anymore since nothing it
> > >>defines is used in these files.
> > >>
> > >>Signed-off-by: Haneen Mohammed 
> > >Applied, thanks.
> > 
> > drivers/gpu/drm/armada/armada_fb.c uses DRM_ERROR() which is defined in
> > include/drm/drmP.h. Doesn't that warrant an inclusion?
> > 
> > Noralf.
> > 
> > >-Daniel
> 
> Actually most of them do use DRM_ERROR. It's my mistake, I did not check 
> every function,
> and just relied on not getting an error when compiled. 
> 
> But this would mean almost all the files would need to include the
> drmP.h then, since they are encouraged to use DRM_DEV_*, right?

We still need to split out the last few bits of drmP.h, then there'd
just be a drm_debug.h or similar helper for this stuff.
-Daniel

> 
> > >>---
> > >>  drivers/gpu/drm/armada/armada_510.c   | 1 -
> > >>  drivers/gpu/drm/armada/armada_drv.c   | 1 -
> > >>  drivers/gpu/drm/armada/armada_fb.c| 1 -
> > >>  drivers/gpu/drm/armada/armada_fbdev.c | 1 -
> > >>  drivers/gpu/drm/armada/armada_gem.c   | 1 -
> > >>  5 files changed, 5 deletions(-)
> > >>
> > >>diff --git a/drivers/gpu/drm/armada/armada_510.c 
> > >>b/drivers/gpu/drm/armada/armada_510.c
> > >>index ad3d2eb..41a784f 100644
> > >>--- a/drivers/gpu/drm/armada/armada_510.c
> > >>+++ b/drivers/gpu/drm/armada/armada_510.c
> > >>@@ -9,7 +9,6 @@
> > >>   */
> > >>  #include 
> > >>  #include 
> > >>-#include 
> > >>  #include 
> > >>  #include "armada_crtc.h"
> > >>  #include "armada_drm.h"
> > >>diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> > >>b/drivers/gpu/drm/armada/armada_drv.c
> > >>index c993bcc..17bb675 100644
> > >>--- a/drivers/gpu/drm/armada/armada_drv.c
> > >>+++ b/drivers/gpu/drm/armada/armada_drv.c
> > >>@@ -9,7 +9,6 @@
> > >>  #include 
> > >>  #include 
> > >>  #include 
> > >>-#include 
> > >>  #include 
> > >>  #include 
> > >>  #include "armada_crtc.h"
> > >>diff --git a/drivers/gpu/drm/armada/armada_fb.c 
> > >>b/drivers/gpu/drm/armada/armada_fb.c
> > >>index 51839c1..a38d5a0 100644
> > >>--- a/drivers/gpu/drm/armada/armada_fb.c
> > >>+++ b/drivers/gpu/drm/armada/armada_fb.c
> > >>@@ -5,7 +5,6 @@
> > >>   * it under the terms of the GNU General Public License version 2 as
> > >>   * published by the Free Software Foundation.
> > >>   */
> > >>-#include 
> > >>  #include 
> > >>  #include 
> > >>  #include "armada_drm.h"
> > >>diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
> > >>b/drivers/gpu/drm/armada/armada_fbdev.c
> > >>index cf6bad1..a2ce83f 100644
> > >>--- a/drivers/gpu/drm/armada/armada_fbdev.c
> > >>+++ b/drivers/gpu/drm/armada/armada_fbdev.c
> > >>@@ -10,7 +10,6 @@
> > >>  #include 
> > >>  #include 
> > >>-#include 
> > >>  #include 
> > >>  #include "armada_crtc.h"
> > >>  #include "armada_drm.h"
> > >>diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> > >>b/drivers/gpu/drm/armada/armada_gem.c
> > >>index 49d40aa..190280e 100644
> > >>--- a/drivers/gpu/drm/armada/armada_gem.c
> > >>+++ b/drivers/gpu/drm/armada/armada_gem.c
> > >>@@ -8,7 +8,6 @@
> > >>  #include 
> > >>  #include 
> > >>  #include 
> > >>-#include 
> > >>  #include "armada_drm.h"
> > >>  #include "armada_gem.h"
> > >>  #include 
> > >>-- 
> > >>2.7.4
> > >>
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 197103] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 / IP: nouveau_fbcon_set_suspend_work+0x45/0xf0 [nouveau]

[bugzilla-daemon]

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

Igor Gnatenko (i.gnatenko.br...@gmail.com) changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=102381

--- Comment #1 from Igor Gnatenko (i.gnatenko.br...@gmail.com) ---
Someone submitted same bug on FDO bugzilla, but I think this is more kernel
bug..

https://bugs.freedesktop.org/show_bug.cgi?id=102381

-- 
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

[Bug 197103] New: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 / IP: nouveau_fbcon_set_suspend_work+0x45/0xf0 [nouveau]

[bugzilla-daemon]

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

Bug ID: 197103
   Summary: BUG: unable to handle kernel NULL pointer dereference
at 0008 / IP:
nouveau_fbcon_set_suspend_work+0x45/0xf0 [nouveau]
   Product: Drivers
   Version: 2.5
Kernel Version: 4.14.0-0.rc2.git4.1.fc28.x86_64
  Hardware: All
OS: Linux
  Tree: Fedora
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: i.gnatenko.br...@gmail.com
Regression: Yes

Created attachment 258693
  --> https://bugzilla.kernel.org/attachment.cgi?id=258693=edit
journal

This is Lenovo ThinkPad W541 machine. 4.13.0 works fine, as far as I know, none
of 4.14 works..

BUG: unable to handle kernel NULL pointer dereference at 0008
IP: nouveau_fbcon_set_suspend_work+0x45/0xf0 [nouveau]
PGD 0 P4D 0
Oops:  [#1] SMP
Modules linked in: pcc_cpufreq(-) intel_cstate(+) intel_uncore intel_rapl_perf
iwlmvm(+) mac80211 joydev(+) wmi_bmof i2c_i801 iwlwifi btusb btrtl btbcm
btintel bluetooth lpc_ich uvcvideo cfg80211 videobuf2_vmalloc
snd_hda_codec_realtek videobuf2_memops videobuf2_v4l2 snd_hda_codec_hdmi(+)
videobuf2_core snd_hda_codec_generic videodev media snd_hda_intel snd_hda_codec
ecdh_generic snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm mei_me mei
snd_timer ie31200_edac shpchp thinkpad_acpi snd soundcore rfkill tpm_tis
fjes(-) tpm_tis_core tpm acpi_cpufreq(-) xfs libcrc32c dm_crypt nouveau i915
crct10dif_pclmul crc32_pclmul crc32c_intel mxm_wmi ghash_clmulni_intel ttm
e1000e i2c_algo_bit serio_raw drm_kms_helper sdhci_pci sdhci mmc_core drm ptp
pps_core wmi video
CPU: 4 PID: 35 Comm: kworker/4:0 Not tainted 4.14.0-0.rc2.git4.1.fc28.x86_64 #1
Hardware name: LENOVO 20EGS0R60R/20EGS0R60R, BIOS GNET81WW (2.29 ) 11/24/2016
Workqueue: events nouveau_fbcon_set_suspend_work [nouveau]
task: 9c8b6a50b4c0 task.stack: bb5a81a28000
RIP: 0010:nouveau_fbcon_set_suspend_work+0x45/0xf0 [nouveau]
RSP: 0018:bb5a81a2be28 EFLAGS: 00010286
RAX: 9c8b6212f000 RBX: 9c8b63a157f8 RCX: 
RDX: 9c8b63a14000 RSI: 0001 RDI: 
RBP: bb5a81a2be30 R08: bb5a81a2bf40 R09: 99e0b400
R10: 0001 R11:  R12: 9c8b6d5dafc0
R13: 9c8b6d5df800 R14: 9c8b63a157f8 R15: 
FS:  () GS:9c8b6d40() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0008 CR3: 000467f4e005 CR4: 001606e0
Call Trace:
 process_one_work+0x26b/0x6c0
 worker_thread+0x35/0x3b0
 kthread+0x171/0x190
 ? process_one_work+0x6c0/0x6c0
 ? kthread_create_on_node+0x70/0x70
 ret_from_fork+0x2a/0x40
Code: 8b bb f0 f9 ff ff be 01 00 00 00 e8 46 d6 c7 ff 48 8b 83 f0 e9 ff ff 48
8b 50 28 48 8b 82 e8 11 00 00 48 85 c0 74 1c 48 8b 48 38 <8b> 49 08 89 88 58 02
00 00 48 8b 82 e8 11 00 00 48 8b 40 38 83
RIP: nouveau_fbcon_set_suspend_work+0x45/0xf0 [nouveau] RSP: bb5a81a2be28
CR2: 0008
---[ end trace 01aa0aae272659a2 ]---
BUG: sleeping function called from invalid context at
./include/linux/percpu-rwsem.h:33
in_atomic(): 0, irqs_disabled(): 1, pid: 35, name: kworker/4:0
INFO: lockdep is turned off.
irq event stamp: 9496
hardirqs last  enabled at (9495): []
_raw_spin_unlock_irqrestore+0x36/0x60
hardirqs last disabled at (9496): [] error_entry+0x7c/0xd0
softirqs last  enabled at (9428): []
srcu_invoke_callbacks+0xbc/0x190
softirqs last disabled at (9424): []
srcu_invoke_callbacks+0xbc/0x190
CPU: 4 PID: 35 Comm: kworker/4:0 Tainted: G  D
4.14.0-0.rc2.git4.1.fc28.x86_64 #1
Hardware name: LENOVO 20EGS0R60R/20EGS0R60R, BIOS GNET81WW (2.29 ) 11/24/2016
Workqueue: events nouveau_fbcon_set_suspend_work [nouveau]
Call Trace:
 dump_stack+0x8e/0xd6
 ___might_sleep+0x164/0x250
 __might_sleep+0x4a/0x80
 exit_signals+0x33/0x240
 do_exit+0xb9/0xda0
 ? kthread+0x171/0x190
 rewind_stack_do_exit+0x17/0x20

-- 
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

Re: [PATCH 00/18] use ARRAY_SIZE macro

[Jérémy Lefaure]

On Mon, 2 Oct 2017 09:01:31 +1100
"Tobin C. Harding"  wrote:

> > In order to reduce the size of the To: and Cc: lines, each patch of the
> > series is sent only to the maintainers and lists concerned by the patch.
> > This cover letter is sent to every list concerned by this series.  
> 
> Why don't you just send individual patches for each subsystem? I'm not a 
> maintainer but I don't see
> how any one person is going to be able to apply this whole series, it is 
> making it hard for
> maintainers if they have to pick patches out from among the series (if indeed 
> any will bother
> doing that).
Yeah, maybe it would have been better to send individual patches.

From my point of view it's a series because the patches are related (I
did a git format-patch from my local branch). But for the maintainers
point of view, they are individual patches.

As each patch in this series is standalone, the maintainers can pick
the patches they want and apply them individually. So yeah, maybe I
should have sent individual patches. But I also wanted to tie all
patches together as it's the same change.

Anyway, I can tell to each maintainer that they can apply the patches
they're concerned about and next time I may send individual patches.

Thank you for your answer,
Jérémy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/18] use ARRAY_SIZE macro

[Jérémy Lefaure]

Hi everyone,
Using ARRAY_SIZE improves the code readability. I used coccinelle (I
made a change to the array_size.cocci file [1]) to find several places
where ARRAY_SIZE could be used instead of other macros or sizeof
division.

I tried to divide the changes into a patch per subsystem (excepted for
staging). If one of the patch should be split into several patches, let
me know.

In order to reduce the size of the To: and Cc: lines, each patch of the
series is sent only to the maintainers and lists concerned by the patch.
This cover letter is sent to every list concerned by this series.

This series is based on linux-next next-20170929. Each patch has been
tested by building the relevant files with W=1.

This series contains the following patches:
[PATCH 01/18] sound: use ARRAY_SIZE
[PATCH 02/18] tracing/filter: use ARRAY_SIZE
[PATCH 03/18] media: use ARRAY_SIZE
[PATCH 04/18] IB/mlx5: Use ARRAY_SIZE
[PATCH 05/18] net: use ARRAY_SIZE
[PATCH 06/18] drm: use ARRAY_SIZE
[PATCH 07/18] scsi: bfa: use ARRAY_SIZE
[PATCH 08/18] ecryptfs: use ARRAY_SIZE
[PATCH 09/18] nfsd: use ARRAY_SIZE
[PATCH 10/18] orangefs: use ARRAY_SIZE
[PATCH 11/18] dm space map metadata: use ARRAY_SIZE
[PATCH 12/18] x86: use ARRAY_SIZE
[PATCH 13/18] tpm: use ARRAY_SIZE
[PATCH 14/18] ipmi: use ARRAY_SIZE
[PATCH 15/18] acpi: use ARRAY_SIZE
[PATCH 16/18] media: staging: atomisp: use ARRAY_SIZE
[PATCH 17/18] staging: rtl8723bs: use ARRAY_SIZE
[PATCH 18/18] staging: rtlwifi: use ARRAY_SIZE


[1]: https://lkml.org/lkml/2017/9/13/689
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/18] use ARRAY_SIZE macro

[Tobin C. Harding]

On Sun, Oct 01, 2017 at 03:30:38PM -0400, Jérémy Lefaure wrote:
> Hi everyone,
> Using ARRAY_SIZE improves the code readability. I used coccinelle (I
> made a change to the array_size.cocci file [1]) to find several places
> where ARRAY_SIZE could be used instead of other macros or sizeof
> division.
> 
> I tried to divide the changes into a patch per subsystem (excepted for
> staging). If one of the patch should be split into several patches, let
> me know.
> 
> In order to reduce the size of the To: and Cc: lines, each patch of the
> series is sent only to the maintainers and lists concerned by the patch.
> This cover letter is sent to every list concerned by this series.

Why don't you just send individual patches for each subsystem? I'm not a 
maintainer but I don't see
how any one person is going to be able to apply this whole series, it is making 
it hard for
maintainers if they have to pick patches out from among the series (if indeed 
any will bother
doing that).

I get that this will be more work for you but AFAIK we are optimizing for 
maintainers.

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

[PATCH 06/18] drm: use ARRAY_SIZE

[Jérémy Lefaure]

Using the ARRAY_SIZE macro improves the readability of the code. Also,
it is not always useful to use a variable to store this constant
calculated at compile time nor to re-invent the ARRAY_SIZE macro.

Found with Coccinelle with the following semantic patch:
@r depends on (org || report)@
type T;
T[] E;
position p;
@@
(
 (sizeof(E)@p /sizeof(*E))
|
 (sizeof(E)@p /sizeof(E[...]))
|
 (sizeof(E)@p /sizeof(T))
)

Signed-off-by: Jérémy Lefaure 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  9 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   |  9 +
 drivers/gpu/drm/gma500/psb_intel_sdvo.c |  9 -
 drivers/gpu/drm/i915/gvt/vgpu.c |  3 ++-
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c |  7 ---
 drivers/gpu/drm/via/via_verifier.c  | 10 --
 6 files changed, 24 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index dfc10b1baea0..304862e2a8a6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -20,6 +20,7 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
  */
+#include 
 #include 
 #include 
 #include "amdgpu.h"
@@ -3952,10 +3953,10 @@ static int gfx_v8_0_init_save_restore_list(struct 
amdgpu_device *adev)
adev->gfx.rlc.reg_list_format_size_bytes >> 2,
unique_indices,
_count,
-   sizeof(unique_indices) / sizeof(int),
+   ARRAY_SIZE(unique_indices),
indirect_start_offsets,
_count,
-   sizeof(indirect_start_offsets)/sizeof(int));
+   ARRAY_SIZE(indirect_start_offsets));
 
/* save and restore list */
WREG32_FIELD(RLC_SRM_CNTL, AUTO_INCR_ADDR, 1);
@@ -3977,14 +3978,14 @@ static int gfx_v8_0_init_save_restore_list(struct 
amdgpu_device *adev)
/* starting offsets starts */
WREG32(mmRLC_GPM_SCRATCH_ADDR,
adev->gfx.rlc.starting_offsets_start);
-   for (i = 0; i < sizeof(indirect_start_offsets)/sizeof(int); i++)
+   for (i = 0; i < ARRAY_SIZE(indirect_start_offsets); i++)
WREG32(mmRLC_GPM_SCRATCH_DATA,
indirect_start_offsets[i]);
 
/* unique indices */
temp = mmRLC_SRM_INDEX_CNTL_ADDR_0;
data = mmRLC_SRM_INDEX_CNTL_DATA_0;
-   for (i = 0; i < sizeof(unique_indices) / sizeof(int); i++) {
+   for (i = 0; i < ARRAY_SIZE(unique_indices); i++) {
if (unique_indices[i] != 0) {
WREG32(temp + i, unique_indices[i] & 0x3);
WREG32(data + i, unique_indices[i] >> 20);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index deeaee1457ef..180726f4f34e 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -20,6 +20,7 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
  */
+#include 
 #include 
 #include 
 #include "amdgpu.h"
@@ -1730,10 +1731,10 @@ static int gfx_v9_0_init_rlc_save_restore_list(struct 
amdgpu_device *adev)
adev->gfx.rlc.reg_list_format_size_bytes >> 2,
unique_indirect_regs,
_indirect_reg_count,
-   sizeof(unique_indirect_regs)/sizeof(int),
+   ARRAY_SIZE(unique_indirect_regs),
indirect_start_offsets,
_start_offsets_count,
-   sizeof(indirect_start_offsets)/sizeof(int));
+   ARRAY_SIZE(indirect_start_offsets));
 
/* enable auto inc in case it is disabled */
tmp = RREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_SRM_CNTL));
@@ -1770,12 +1771,12 @@ static int gfx_v9_0_init_rlc_save_restore_list(struct 
amdgpu_device *adev)
/* write the starting offsets to RLC scratch ram */
WREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_GPM_SCRATCH_ADDR),
adev->gfx.rlc.starting_offsets_start);
-   for (i = 0; i < sizeof(indirect_start_offsets)/sizeof(int); i++)
+   for (i = 0; i < ARRAY_SIZE(indirect_start_offsets); i++)
WREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_GPM_SCRATCH_DATA),
indirect_start_offsets[i]);
 
/* load unique indirect regs*/
-   for (i = 0; i < sizeof(unique_indirect_regs)/sizeof(int); i++) {
+   for (i = 0; i < ARRAY_SIZE(unique_indirect_regs); i++) {
WREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_SRM_INDEX_CNTL_ADDR_0) + i,
unique_indirect_regs[i] & 0x3);
WREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_SRM_INDEX_CNTL_DATA_0) + i,
diff --git 

Re: [linux-sunxi] Re: [PATCH v3 04/14] drm/sun4i: tcon: Add support for demuxing TCON output on A31

[Chen-Yu Tsai]

On Sat, Sep 30, 2017 at 2:26 PM, Julian Calaby  wrote:
> Hi Chen-Yu,
>
> On Sat, Sep 30, 2017 at 3:58 PM, Chen-Yu Tsai  wrote:
>> On Sat, Sep 30, 2017 at 1:35 PM, Julian Calaby  
>> wrote:
>>> Hi Chen-Yu,
>>>
>>> On Fri, Sep 29, 2017 at 8:22 PM, Chen-Yu Tsai  wrote:
 On Fri, Sep 29, 2017 at 6:20 PM, Maxime Ripard
  wrote:
> On Fri, Sep 29, 2017 at 08:22:56AM +, Chen-Yu Tsai wrote:
>> On systems with 2 TCONs such as the A31, it is possible to demux the
>> output of the TCONs to one encoder.
>>
>> Add support for this for the A31.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 38 
>> ++
>>  1 file changed, 38 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
>> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index 7bf51abaee97..c949309d4285 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -112,6 +112,21 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon 
>> *tcon, bool enable)
>>  }
>>  EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
>>
>> +static struct sun4i_tcon *sun4i_get_first_tcon(struct drm_device *drm)
>
> Would that make sense to make it a bit more generic, and pass the id
> to look for as an argument?

 The reason to look for TCON0 explicitly is to access the muxing registers, 
 which
 are only available in TCON0. Other than that, there's nothing else
 shared between
 the two TCONs. So there's no particular reason to look for TCON1 
 explicitly.
>>>
>>> In that case: in the bizarre case where we're trying to use this mux
>>> type and there is no TCON0, shouldn't we fail?
>>
>> It gives out a big warning, indicating something is wrong. If TCON0 is not 
>> found
>> it is most likely your device tree is broken. There's nothing more the
>> driver can do.
>> Are you suggesting to return NULL in this case, and also do error
>> handling in the
>> callers?
>
> You're already returning -EINVAL for other failure cases, so a lack of
> TCON0 might as well do the same.
>
>>> (Also, the code doesn't make sense if we have some TCON1 and TCON2 in
>>> that order as it'll return TCON2)
>>
>> I'm guessing you want it to return NULL.
>
> I'm just pointing out the mismatch between getting the "first" TCON
> and the actual behaviour.

Makes sense. I've renamed it to "_get_tcon0" and added more comments
on it's behavior. Also made it return NULL when tcon0 is not found.

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

[Bug 196615] amdgpu - resume from suspend is no longer working on rx480

[bugzilla-daemon]

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

--- Comment #18 from klavkala...@gmail.com ---
Looks like it when browsing the source. It's in both 4.13 and 4.14-rc3. I hope
it can be removed again in time for the LTS release. For now I'm holding off
the upgrade to 4.13. I don't know if I'm getting this right, but it sounds like
there is a choice between suspend/resume and screen flickering...

-- 
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

Re: [PATCH v2 0/9] Exynos DRM: rewrite IPP subsystem and userspace API

[Marek Szyprowski]

Hi Tobias,

On 2017-09-29 15:24, Tobias Jakobi wrote:

Hello Marek,

I just tested this series, and I noticed a lot of these lines:

exynos-sysmmu 11a4.sysmmu: restoring state
exynos-sysmmu 11a4.sysmmu: saving state

I guess it would make sense to enable autosuspend for runtime PM in each of the
hw drivers.

I've just send a patch that does it for the FIMC (the only hw I can test this
on). This improves frame time stability for me.


Right, autosuspend definitely makes sense in case of IPP drivers. I will 
update all

to use it. Thanks for testing this stuff and pointing this issue!

> ...

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

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