[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon]

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

Stratos Zolotas (str...@gmail.com) changed:

   What|Removed |Added

 CC||str...@gmail.com

--- Comment #53 from Stratos Zolotas (str...@gmail.com) ---
Hi everyone.

Don't know if it helps. I'm getting a similar issue on Opensuse Tumbleweed with
kernel 5.7.7. Reverting to kernel 5.7.5 makes things stable for me. My GPU is
RX580.

Ιουλ 09 21:17:39.718030 teras.baskin.cywn kernel: general protection fault,
probably for non-canonical address 0x3e9478a9ecb3abc8:  [#1] SMP NOPTI
Ιουλ 09 21:17:39.718200 teras.baskin.cywn kernel: CPU: 1 PID: 141 Comm:
kworker/u16:3 Tainted: G   O  5.7.7-1-default #1 openSUSE
Tumbleweed (unreleased)
Ιουλ 09 21:17:39.718239 teras.baskin.cywn kernel: Hardware name: Gigabyte
Technology Co., Ltd. To be filled by O.E.M./970A-DS3P, BIOS FD 02/26/2016
Ιουλ 09 21:17:39.718273 teras.baskin.cywn kernel: Workqueue: events_unbound
commit_work [drm_kms_helper]
Ιουλ 09 21:17:39.718306 teras.baskin.cywn kernel: RIP:
0010:amdgpu_dm_atomic_commit_tail+0x273/0x10f0 [amdgpu]
Ιουλ 09 21:17:39.718339 teras.baskin.cywn kernel: Code: 43 08 8b 90 e0 02
00 00 41 83 c6 01 44 39 f2 0f 87 3a ff ff ff 48 83 bd a0 fd ff ff 00 0f 84 03
01 00 00 48 8b bd a0 fd ff ff <80> bf b0 01 00 00 01 0f 86 ac 00 00 00 48 b9 00
00 00 00 01 00 00
Ιουλ 09 21:17:39.718368 teras.baskin.cywn kernel: RSP:
0018:b7cf4037bbe0 EFLAGS: 00010202
Ιουλ 09 21:17:39.718400 teras.baskin.cywn kernel: RAX: 8fb2a5e11800
RBX: 8fb28f2c2880 RCX: 8fb10ff8ec00
Ιουλ 09 21:17:39.718442 teras.baskin.cywn kernel: RDX: 0006
RSI: c0b7f530 RDI: 3e9478a9ecb3abc8
Ιουλ 09 21:17:39.718482 teras.baskin.cywn kernel: RBP: b7cf4037be68
R08: 0001 R09: 0001
Ιουλ 09 21:17:39.718519 teras.baskin.cywn kernel: R10: 014d
R11: 0018 R12: 8fb2a35e7400
Ιουλ 09 21:17:39.718547 teras.baskin.cywn kernel: R13: 
R14: 0006 R15: 8fb112001000
Ιουλ 09 21:17:39.718584 teras.baskin.cywn kernel: FS: 
() GS:8fb2aec4() knlGS:
Ιουλ 09 21:17:39.718620 teras.baskin.cywn kernel: CS:  0010 DS:  ES:
 CR0: 80050033
Ιουλ 09 21:17:39.718652 teras.baskin.cywn kernel: CR2: 7f364b9bc000
CR3: 00042a2ae000 CR4: 000406e0
Ιουλ 09 21:17:39.718683 teras.baskin.cywn kernel: Call Trace:
Ιουλ 09 21:17:39.718715 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.718750 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.718784 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.718810 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.718840 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.718868 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.718894 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.718921 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.718946 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.718972 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.718999 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.719026 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.719062 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.719088 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.719122 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.719149 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.719177 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.719203 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.719229 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.719254 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.719280 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.719306 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.719333 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.719359 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.719383 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.719408 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.719433 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x40/0x70
Ιουλ 09 21:17:39.719465 teras.baskin.cywn kernel:  ?
__switch_to_asm+0x34/0x70
Ιουλ 09 21:17:39.719490 teras.baskin.cywn kernel:  ?
__switch

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon]

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

--- Comment #54 from Paul Menzel (pmenzel+bugzilla.kernel@molgen.mpg.de) ---
(In reply to Stratos Zolotas from comment #53)

> Don't know if it helps. I'm getting a similar issue on Opensuse Tumbleweed
> with kernel 5.7.7. Reverting to kernel 5.7.5 makes things stable for me. My
> GPU is RX580.

[…]

Thank you for your report. How quickly can you reproduce it? If you could
bisect the issue to pinpoint the culprit commit between 5.7.5 and 5.7.7, that’d
be great. Maybe open even a separate bug report, in case they are unrelated.
They can always be marked as duplicates later.

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

[PATCH 2/4] drm/etnaviv: add loadavg accounting

[Christian Gmeiner]

The GPU has an idle state register where each bit represents the idle
state of a sub-GPU component like FE or TX. Sample this register
every 10ms and calculate a simple moving average over the sub-GPU
component idle states with a total observation time frame of 1s.

This provides us with a percentage based load of each sub-GPU
component.

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 14 
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 32 +++
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 29 
 3 files changed, 75 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index f9afe11c50f0..b31920241c86 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -46,6 +46,19 @@ static void load_gpu(struct drm_device *dev)
}
 }
 
+static void unload_gpu(struct drm_device *dev)
+{
+   struct etnaviv_drm_private *priv = dev->dev_private;
+   unsigned int i;
+
+   for (i = 0; i < ETNA_MAX_PIPES; i++) {
+   struct etnaviv_gpu *g = priv->gpu[i];
+
+   if (g)
+   etnaviv_gpu_shutdown(g);
+   }
+}
+
 static int etnaviv_open(struct drm_device *dev, struct drm_file *file)
 {
struct etnaviv_drm_private *priv = dev->dev_private;
@@ -581,6 +594,7 @@ static void etnaviv_unbind(struct device *dev)
struct drm_device *drm = dev_get_drvdata(dev);
struct etnaviv_drm_private *priv = drm->dev_private;
 
+   unload_gpu(drm);
drm_dev_unregister(drm);
 
component_unbind_all(dev, drm);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index a31eeff2b297..1f0eb7e00657 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -714,6 +714,28 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
gpu_write(gpu, VIVS_HI_INTR_ENBL, ~0U);
 }
 
+static void etnaviv_loadavg_function(struct timer_list *t)
+{
+   struct etnaviv_gpu *gpu = from_timer(gpu, t, loadavg_timer);
+   const u32 idle = gpu_read(gpu, VIVS_HI_IDLE_STATE);
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(etna_idle_module_names); i++)
+   if ((idle & etna_idle_module_names[i].bit))
+   sma_loadavg_add(&gpu->loadavg_value[i], 0);
+   else
+   sma_loadavg_add(&gpu->loadavg_value[i], 100);
+
+   spin_lock_bh(&gpu->loadavg_spinlock);
+
+   for (i = 0; i < ARRAY_SIZE(etna_idle_module_names); i++)
+   gpu->loadavg_percentage[i] = 
sma_loadavg_read(&gpu->loadavg_value[i]);
+
+   spin_unlock_bh(&gpu->loadavg_spinlock);
+
+   mod_timer(t, jiffies + msecs_to_jiffies(10));
+}
+
 int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
 {
struct etnaviv_drm_private *priv = gpu->drm->dev_private;
@@ -804,6 +826,10 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
for (i = 0; i < ARRAY_SIZE(gpu->event); i++)
complete(&gpu->event_free);
 
+   /* Setup loadavg timer */
+   timer_setup(&gpu->loadavg_timer, etnaviv_loadavg_function, 0);
+   mod_timer(&gpu->loadavg_timer, jiffies + msecs_to_jiffies(10));
+
/* Now program the hardware */
mutex_lock(&gpu->lock);
etnaviv_gpu_hw_init(gpu);
@@ -824,6 +850,11 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
return ret;
 }
 
+void etnaviv_gpu_shutdown(struct etnaviv_gpu *gpu)
+{
+   del_timer(&gpu->loadavg_timer);
+}
+
 #ifdef CONFIG_DEBUG_FS
 struct dma_debug {
u32 address[2];
@@ -1762,6 +1793,7 @@ static int etnaviv_gpu_platform_probe(struct 
platform_device *pdev)
gpu->dev = &pdev->dev;
mutex_init(&gpu->lock);
mutex_init(&gpu->fence_lock);
+   spin_lock_init(&gpu->loadavg_spinlock);
 
/* Map registers: */
gpu->mmio = devm_platform_ioremap_resource(pdev, 0);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 8ea48697d132..a5b9c89c6744 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -10,6 +10,8 @@
 #include "etnaviv_gem.h"
 #include "etnaviv_mmu.h"
 #include "etnaviv_drv.h"
+#include "etnaviv_sma.h"
+#include "state_hi.xml.h"
 
 struct etnaviv_gem_submit;
 struct etnaviv_vram_mapping;
@@ -91,6 +93,26 @@ struct clk;
 
 #define ETNA_NR_EVENTS 30
 
+DECLARE_SMA(loadavg, 100)
+
+static const struct {
+const char *name;
+u32 bit;
+} etna_idle_module_names[] = {
+{ "FE", VIVS_HI_IDLE_STATE_FE },
+{ "DE", VIVS_HI_IDLE_STATE_DE },
+{ "PE", VIVS_HI_IDLE_STATE_PE },
+{ "SH", VIVS_HI_IDLE_STATE_SH },
+{ "PA", VIVS_HI_IDLE_STATE_PA },
+{ "SE", VIVS_HI_IDLE_STATE_SE },
+{ "RA", VIVS_HI_IDLE_STATE_RA },
+{ "TX", VIVS_HI_IDLE_STATE_TX },
+{ "VG", VIVS_HI_IDLE_STATE_VG },
+{ "IM", VIVS_HI_IDLE_STATE_IM },
+{ "FP", VIVS_HI_IDLE_STAT

[PATCH 0/4] Add support for GPU load values

[Christian Gmeiner]

This patch series add support for loadavg values for GPU
sub-components. I am adding a SMA algorithm as I was not
really sure if EWMA would be a good fit for this use case.

Christian Gmeiner (4):
  drm/etnaviv: add simple moving average (SMA)
  drm/etnaviv: add loadavg accounting
  drm/etnaviv: show loadavg in debugfs
  drm/etnaviv: export loadavg via perfmon

 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 14 
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 44 -
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 29 +
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 79 +++
 drivers/gpu/drm/etnaviv/etnaviv_sma.h | 53 +++
 5 files changed, 218 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_sma.h

-- 
2.26.2

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

[PATCH 4/4] drm/etnaviv: export loadavg via perfmon

[Christian Gmeiner]

Make it possible to access the sub-GPU component load value from
user space with the perfmon infrastructure.

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 79 +++
 1 file changed, 79 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 75f9db8f7bec..614d86e2802d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -98,6 +98,19 @@ static u32 hi_total_idle_cycle_read(struct etnaviv_gpu *gpu,
return gpu_read(gpu, reg);
 }
 
+static u32 load_read(struct etnaviv_gpu *gpu,
+   const struct etnaviv_pm_domain *domain,
+   const struct etnaviv_pm_signal *signal)
+{
+   u32 load;
+
+   spin_lock_bh(&gpu->loadavg_spinlock);
+   load = gpu->loadavg_percentage[signal->data];
+   spin_unlock_bh(&gpu->loadavg_spinlock);
+
+   return load;
+}
+
 static const struct etnaviv_pm_domain doms_3d[] = {
{
.name = "HI",
@@ -387,6 +400,72 @@ static const struct etnaviv_pm_domain doms_3d[] = {
&perf_reg_read
}
}
+   },
+   {
+   .name = "LOAD",
+   .nr_signals = 12,
+   .signal = (const struct etnaviv_pm_signal[]) {
+   {
+   "FE",
+   0,
+   &load_read
+   },
+   {
+   "DE",
+   1,
+   &load_read
+   },
+   {
+   "PE",
+   2,
+   &load_read
+   },
+   {
+   "SH",
+   3,
+   &load_read
+   },
+   {
+   "PA",
+   4,
+   &load_read
+   },
+   {
+   "SE",
+   5,
+   &load_read
+   },
+   {
+   "RA",
+   6,
+   &load_read
+   },
+   {
+   "TX",
+   7,
+   &load_read
+   },
+   {
+   "VG",
+   8,
+   &load_read
+   },
+   {
+   "IM",
+   9,
+   &load_read
+   },
+   {
+   "FP",
+   10,
+   &load_read
+   },
+   {
+   "TS",
+   11,
+   &load_read
+   }
+   }
}
 };
 
-- 
2.26.2

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

[PATCH 1/4] drm/etnaviv: add simple moving average (SMA)

[Christian Gmeiner]

This adds a SMA algorithm inspired by Exponentially weighted moving
average (EWMA) algorithm found in the kernel.

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_sma.h | 53 +++
 1 file changed, 53 insertions(+)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_sma.h

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sma.h 
b/drivers/gpu/drm/etnaviv/etnaviv_sma.h
new file mode 100644
index ..81564d5cbdc3
--- /dev/null
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sma.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Etnaviv Project
+ */
+
+#ifndef __ETNAVIV_SMA_H__
+#define __ETNAVIV_SMA_H__
+
+#include 
+#include 
+
+/*
+ * Simple moving average (SMA)
+ *
+ * This implements a fixed-size SMA algorithm.
+ *
+ * The first argument to the macro is the name that will be used
+ * for the struct and helper functions.
+ *
+ * The second argument, the samples, expresses how many samples are
+ * used for the SMA algorithm.
+ */
+
+#define DECLARE_SMA(name, _samples) \
+struct sma_##name { \
+unsigned long pos; \
+unsigned long sum; \
+unsigned long samples[_samples]; \
+}; \
+static inline void sma_##name##_init(struct sma_##name *s) \
+{ \
+BUILD_BUG_ON(!__builtin_constant_p(_samples)); \
+memset(s, 0, sizeof(struct sma_##name)); \
+} \
+static inline unsigned long sma_##name##_read(struct sma_##name *s) \
+{ \
+BUILD_BUG_ON(!__builtin_constant_p(_samples)); \
+return s->sum / _samples; \
+} \
+static inline void sma_##name##_add(struct sma_##name *s, unsigned long 
val) \
+{ \
+unsigned long pos = READ_ONCE(s->pos); \
+unsigned long sum = READ_ONCE(s->sum); \
+unsigned long sample = READ_ONCE(s->samples[pos]); \
+  \
+BUILD_BUG_ON(!__builtin_constant_p(_samples)); \
+  \
+   WRITE_ONCE(s->sum, sum - sample + val); \
+   WRITE_ONCE(s->samples[pos], val); \
+   WRITE_ONCE(s->pos, pos + 1 == _samples ? 0 : pos + 1); \
+}
+
+#endif /* __ETNAVIV_SMA_H__ */
-- 
2.26.2

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

[PATCH 3/4] drm/etnaviv: show loadavg in debugfs

[Christian Gmeiner]

Might be helpful to see the loadavg in debugfs.

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 1f0eb7e00657..82fe4aafed57 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -884,7 +884,7 @@ int etnaviv_gpu_debugfs(struct etnaviv_gpu *gpu, struct 
seq_file *m)
 {
struct dma_debug debug;
u32 dma_lo, dma_hi, axi, idle;
-   int ret;
+   int ret, i;
 
seq_printf(m, "%s Status:\n", dev_name(gpu->dev));
 
@@ -1002,6 +1002,16 @@ int etnaviv_gpu_debugfs(struct etnaviv_gpu *gpu, struct 
seq_file *m)
if (idle & VIVS_HI_IDLE_STATE_AXI_LP)
seq_puts(m, "\t AXI low power mode\n");
 
+   seq_printf(m, "\tload:\n");
+   spin_lock_bh(&gpu->loadavg_spinlock);
+
+   for (i = 0; i < ARRAY_SIZE(etna_idle_module_names); i++)
+   seq_printf(m, "\t %s: %u%%\n",
+ etna_idle_module_names[i].name,
+ gpu->loadavg_percentage[i]);
+
+   spin_unlock_bh(&gpu->loadavg_spinlock);
+
if (gpu->identity.features & chipFeatures_DEBUG_MODE) {
u32 read0 = gpu_read(gpu, VIVS_MC_DEBUG_READ0);
u32 read1 = gpu_read(gpu, VIVS_MC_DEBUG_READ1);
-- 
2.26.2

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

Re: [PATCH v6 2/4] driver core: add deferring probe reason to devices_deferred property

[Andrzej Hajda]

On 07.07.2020 06:14, Dmitry Torokhov wrote:
> On Thu, Jul 02, 2020 at 08:57:55AM +0200, Andrzej Hajda wrote:
>> On 30.06.2020 20:00, Dmitry Torokhov wrote:
>>> On Tue, Jun 30, 2020 at 8:42 AM Andrzej Hajda  wrote:
 On 30.06.2020 10:59, Grygorii Strashko wrote:
> Hi
>
> On 29/06/2020 14:28, Andrzej Hajda wrote:
>> Hi Grygorii,
>>
>> (...)
>>
  /*
   * deferred_devs_show() - Show the devices in the deferred probe
 pending list.
   */
 @@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s,
 void *data)
  mutex_lock(&deferred_probe_mutex);
list_for_each_entry(curr, &deferred_probe_pending_list,
 deferred_probe)
 -seq_printf(s, "%s\n", dev_name(curr->device));
 +seq_printf(s, "%s\t%s", dev_name(curr->device),
 + curr->device->p->deferred_probe_reason ?: "\n");
mutex_unlock(&deferred_probe_mutex);

>>> Sry, may be i missing smth, but shouldn't it be optional
>>> (CONFIG_DEBUG_FS is probably too generic).
>>>
>> I am not sure what exactly are you referring to, but this patch does not
>> add new property, it just extends functionality of existing one.
> Sry, needed to be more specific.
>
> You've added  device_set_deferred_probe_reson(dev, &vaf);
> which expected to be used on every EPROBE_DEFER in dev_err_probe() in
> combination with
>
> +   } else {
> +   device_set_deferred_probe_reson(dev, &vaf);
>   dev_dbg(dev, "error %d: %pV", err, &vaf);
>
> ^^ dev_dbg() does not add any runtime overhead during boot unless enabled
> +   }
>
> But:
>
> +void device_set_deferred_probe_reson(const struct device *dev, struct
> va_format *vaf)
> +{
> +   const char *drv = dev_driver_string(dev);
> +
> +   mutex_lock(&deferred_probe_mutex);
> +
> +   kfree(dev->p->deferred_probe_reason);
> +   dev->p->deferred_probe_reason = kasprintf(GFP_KERNEL, "%s:
> %pV", drv, vaf);
> +
> +   mutex_unlock(&deferred_probe_mutex);
> +}
>
> ^^ Adds locking, kfree() and kasprintf() for every deferred probe
> during boot and can't be disabled.
>
> Right?
 Right, but usually the burden should be insignificant in comparison to
 probe time, so I do not think it is worth optimizing.
>>> I do not think this is going to take. You are suggesting that we
>>> modify pretty much every driver to supply this deferral reason, and I
>>> doubt it will happen. Can we put this burden on providers that raise
>>> the deferral?
>>
>> I wouldn't say they raise the deferral, they just inform resource is not
>> yet available. Only device driver, and only in its probe function can
>> "raise the deferral".
> Well, this is a matter of perspective. If devm_gpiod_get() returns
> -EBUSY and this is returned to driver core, is it GPIO line signals that
> line is busy, or is it the driver applies its knowledge. I say that in
> majority of cases driver does not really get a say in this and simply
> has to pass whatever error condition that is signalled by providers up
> the stack.
>
> I would consider whenever a driver does not propagate -EPROBE_DEFER to
> the driver code a bug that needs fixing, because it should not degrade
> functionality and/or performance just because we have not figured out
> how to order probing properly and have to rely on deferrals.
>
>>
>>>I.e. majority of code are using devm API now, so we most
>>> likely know the device for which deferral is being raised. We can have
>>> a list of deferral reasons and their devices and when in device code
>>> once probe is done we could try reconciling it with the deferred
>>> devicelist, and this would mean you only need to implement this in
>>> gpiolib, regulator core, clocks core, etc.
>>
>> This patchset tries to solve simple issue - replace multiple lines of
>> code present in multiple probe functions (additionally fixing lot of
>> them) with single call and then enhance it little bit, nothing more.
>>
>> What you are proposing is blurry at the moment for me, provider does not
>> know if consumer want to defer,
> This is my point - the consumer does not get to decide. If deferral is
> raised, it must be honored.
>
>> or will continue working without missing resource,
> Deferral does not mean resource does not exist and the driver has to get
> by if it can. It means the resource is not ready, and even if the system
> can work without it, it will not be working optimally.
>
>> moreover some consumers can acquire resources after probe - again no
>> probe deferral.
> In this case we should not signal deferral either.


But the provider does not know if *get is called in probe context or 
not, so it is not able to differentiate it.

So the whole idea is for me suspicious/wrong. Kind 

Re: [PATCH v4 04/16] pwm: lpss: Add range limit check for the base_unit register value

[Andy Shevchenko]

On Thu, Jul 09, 2020 at 03:23:13PM +0200, Hans de Goede wrote:
> On 7/9/20 2:53 PM, Andy Shevchenko wrote:
> > On Wed, Jul 08, 2020 at 11:14:20PM +0200, Hans de Goede wrote:
> > > When the user requests a high enough period ns value, then the
> > > calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
> > > 
> > > But according to the data-sheet the way the PWM controller works is that
> > > each input clock-cycle the base_unit gets added to a N bit counter and
> > > that counter overflowing determines the PWM output frequency. Adding 0
> > > to the counter is a no-op. The data-sheet even explicitly states that
> > > writing 0 to the base_unit bits will result in the PWM outputting a
> > > continuous 0 signal.
> > 
> > And I don't see how you can get duty 100% / 0% (I don't remember which one 
> > is
> > equivalent to 0 in base unit) after this change. IIRC the problem here that
> > base unit when non-zero is always being added to the counter and it will
> > trigger the change of output at some point which is not what we want for 
> > 100% /
> > 0% cases.
> 
> The base_unit controls the output frequency, not the duty-cycle. So clamping
> the base_unit, as calculated from the period here, which also only configures
> output-frequency does not impact the duty-cycle at all.
> 
> note that AFAICT currently no (in kernel) users actually try to set a period 
> value
> which would hit the clamp, so for existing users the clamp is a no-op. I just
> added it to this patch-set for correctness sake and because userspace
> (sysfs interface) users could in theory set out of range values.
> 
> As for the duty-cycle thing, first of all let me say that that is a
> question / issue which is completely orthogonal to this patch, this
> patch only impacts the period/output frequency NOT the duty-cycle,

Unfortunately the base unit settings affects duty cycle.

Documentation says about integer part and fractional, where integer is
8 bit and this what's being compared to on time divisor. Thus, if on time
divisor is 255 and base unit is 1 (in integer part) or 0.25, we can't get 0%.
(It looks like if 'on time divisor MOD base unit == 0' we won't get 0%)

> With that said, the documentation is not really helpful here,
> we need to set the on_time_div to 255 to get a duty-cycle close to 0
> (and to 0 to get a duty cycle of 100%) but if setting this to 255 gives
> us a duty-cycle of really really 0%, or just close to 0% is uncleaer.

It depends on base unit value.

> We could do a separate patch add ing a hack where if the user asks for
> 0% duty-cycle we program the base_unit to 0, but that seems like a bad
> idea for 2 reasons:

> 1. If the user really wants the output to be constantly 0 the user should
> just disable the pwm

I can't take this as an argument. Disabling PWM is orthogonal to what duty 
cycle is.

> 2. New base_unit values are latched and not applied until the counter
> overflows, with a base_unit of 0 the counter never overflows. I have
> not tested this but I would not be surprised if after programming a
> base_unit value of 0, we are unable to ever change the value again
> through any other means then power-cycling the PWM controller.
> Even if I could test this on some revisions, we already know that
> not all revisions work the same wrt the latching. So it is best to
> just never set base_unit to 0, that is just a recipe asking for trouble.

This what doc says about zeros:
• Programming either the PWM_base_unit value or the PWM_on_time_divisor to ‘0’
will generate an always zero output.

So, what I'm talking seems about correlation between base unit and on time
divisor rather than zeros.

I agree with this patch.
Reviewed-by: Andy Shevchenko 

> > > When the user requestes a low enough period ns value, then the
> > > calculations in pwm_lpss_prepare() might result in a base_unit value
> > > which is bigger then base_unit_range - 1. Currently the codes for this
> > > deals with this by applying a mask:
> > > 
> > >   base_unit &= (base_unit_range - 1);
> > > 
> > > But this means that we let the value overflow the range, we throw away the
> > > higher bits and store whatever value is left in the lower bits into the
> > > register leading to a random output frequency, rather then clamping the
> > > output frequency to the highest frequency which the hardware can do.
> > 
> > It would be nice to have an example of calculus here.
> > 
> > > This commit fixes both issues by clamping the base_unit value to be
> > > between 1 and (base_unit_range - 1).
> > 
> > Eventually I sat and wrote all this on paper. I see now that the problem
> > is in out of range of the period. And strongly we should clamp rather period
> > to the supported range, but your solution is an equivalent.
> 
> Right, the advantage of doing the clamping on the register value is that we
> avoid some tricky math with possible rounding errors and which is different
> per controller revision because the number of bits in the base un

[PATCH v3 02/14] drm/panfrost: clean headers in devfreq

[Clément Péron]

Don't include not required headers and sort them.

Reviewed-by: Steven Price 
Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 
---
 drivers/gpu/drm/panfrost/panfrost_devfreq.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 1b560b903ea6..df7b71da9a84 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -1,18 +1,14 @@
 // SPDX-License-Identifier: GPL-2.0
 /* Copyright 2019 Collabora ltd. */
+
+#include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
 
 #include "panfrost_device.h"
 #include "panfrost_devfreq.h"
-#include "panfrost_features.h"
-#include "panfrost_issues.h"
-#include "panfrost_gpu.h"
-#include "panfrost_regs.h"
 
 static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev)
 {
-- 
2.25.1

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

[PATCH v2 0/2] Convert mtk-dpi to drm_bridge API

[Enric Balletbo i Serra]

The mtk-dpi driver still uses the drm_encoder API which is now somewhat
deprecated. We started to move all the Mediatek drivers to the drm_bridge API,
like we did for the mtk-dsi driver [1], this is another small step to be able to
fully convert the DRM Mediatek drivers to the drm_bridge API. A dummy
drm_encoder is maintained in the mtk-dpi driver but the end goal is move all the
dummy drm_encoder (mtk-dsi, mtk-dpi, etc) to the main mtk_drm_drv driver.

[1] https://lore.kernel.org/patchwork/project/lkml/list/?series=441559

Changes in v2:
- Maintain error message when attach to bridge fails. (Boris)
- Drop the third patch.

Enric Balletbo i Serra (2):
  drm/mediatek: mtk_dpi: Rename bridge to next_bridge
  drm/mediatek: mtk_dpi: Convert to bridge driver

 drivers/gpu/drm/mediatek/mtk_dpi.c | 77 +-
 1 file changed, 45 insertions(+), 32 deletions(-)

-- 
2.27.0

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

[PATCH v3 03/14] drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle

[Clément Péron]

This use devfreq variable that will be lock with spinlock in future
patches. We should either introduce a function to access this one
but as devfreq is optional let's just remove it.

Reviewed-by: Steven Price 
Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 
---
 drivers/gpu/drm/panfrost/panfrost_job.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 7914b1570841..63e32a9f2749 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -581,10 +581,6 @@ int panfrost_job_is_idle(struct panfrost_device *pfdev)
struct panfrost_job_slot *js = pfdev->js;
int i;
 
-   /* Check whether the hardware is idle */
-   if (atomic_read(&pfdev->devfreq.busy_count))
-   return false;
-
for (i = 0; i < NUM_JOB_SLOTS; i++) {
/* If there are any jobs in the HW queue, we're not idle */
if (atomic_read(&js->queue[i].sched.hw_rq_count))
-- 
2.25.1

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

Re: [RESEND PATCH 3/3] drm/mediatek: mtk_dpi: Use simple encoder

[Enric Balletbo i Serra]

Hi again,

On 8/7/20 17:12, Enric Balletbo i Serra wrote:
> Hi Boris,
> 
> Thank you to spend some time to review the patches.
> 
> On 1/7/20 13:41, Boris Brezillon wrote:
>> On Mon, 18 May 2020 19:39:09 +0200
>> Enric Balletbo i Serra  wrote:
>>
>>> The mtk_dpi driver uses an empty implementation for its encoder. Replace
>>> the code with the generic simple encoder.
>>>
>>> Signed-off-by: Enric Balletbo i Serra 
>>> Reviewed-by: Chun-Kuang Hu 
>>> ---
>>>
>>>  drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
>>>  1 file changed, 3 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
>>> b/drivers/gpu/drm/mediatek/mtk_dpi.c
>>> index baad198c69eb..80778b2aac2a 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
>>> @@ -20,6 +20,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  
>>>  #include "mtk_dpi_regs.h"
>>>  #include "mtk_drm_ddp_comp.h"
>>> @@ -510,15 +511,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi 
>>> *dpi,
>>> return 0;
>>>  }
>>>  
>>> -static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
>>> -{
>>> -   drm_encoder_cleanup(encoder);
>>> -}
>>> -
>>> -static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
>>> -   .destroy = mtk_dpi_encoder_destroy,
>>> -};
>>> -
>>>  static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
>>>  enum drm_bridge_attach_flags flags)
>>>  {
>>> @@ -591,8 +583,8 @@ static int mtk_dpi_bind(struct device *dev, struct 
>>> device *master, void *data)
>>> return ret;
>>> }
>>>  
>>> -   ret = drm_encoder_init(drm_dev, &dpi->encoder, &mtk_dpi_encoder_funcs,
>>> -  DRM_MODE_ENCODER_TMDS, NULL);
>>> +   ret = drm_simple_encoder_init(drm_dev, &dpi->encoder,
>>> + DRM_MODE_ENCODER_TMDS);
>>
>> Not related to this change, but shouldn't we have DRM_MODE_ENCODER_DPI
>> here?
>>
> 

Thinking a bit more about this and this patchset in general, I think I'll drop
this patch from the series, at the end, all the encoder creation stuff should be
moved to mtk_drm_drv.


> Right, I'll add a patch to fix this.
> 
>>> if (ret) {
>>> dev_err(dev, "Failed to initialize decoder: %d\n", ret);
>>> goto err_unregister;
>>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v2] drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfs

[Angelo Ribeiro]

Hi Philippe,

From: Philippe CORNU 
Date: Thu, Jul 09, 2020 at 08:56:10

> 
> On 7/8/20 7:08 PM, Angelo Ribeiro wrote:
> > Hi,
> > 
> > Is this patch good to go?
> > @dan...@ffwll.ch, @Philippe CORNU
> > 
> > Was already tested by @Yannick FERTRE
> > and @Adrian Pop
> > on 
> > https://urldefense.com/v3/__https://lkml.org/lkml/2020/4/6/691__;!!A4F2R9G_pg!Kt4QZq004dTCJ3GJ6t6RIaJMBrP5tWWgTlboJo1ZICktSxRegGKtp1VxYM1i2PiM$
> >   .
> > 
> > Thanks,
> > Angelo
> > 
> > From: Yannick
> > FERTRE 
> > Date: Wed, Jun 24, 2020 at 16:35:04
> > 
> >> Hello Angelo,
> >> thanks for the patch.
> >> Tested-by: Yannick Fertre 
> >> Tested OK on STM32MP1-DISCO, DSI v1.31
> >>
> >> Best regards
> >>
> >>
> >> On 4/6/20 3:49 PM, Angelo Ribeiro wrote:
> >>> Add support for the video pattern generator (VPG) BER pattern mode and
> >>> configuration in runtime.
> >>>
> >>> This enables using the debugfs interface to manipulate the VPG after
> >>> the pipeline is set.
> >>> Also, enables the usage of the VPG BER pattern.
> >>>
> >>> Changes in v2:
> >>> - Added VID_MODE_VPG_MODE
> >>> - Solved incompatible return type on __get and __set
> >>>
> >>> Reported-by: kbuild test robot 
> >>> Reported-by: Adrian Pop 
> >>> Cc: Gustavo Pimentel 
> >>> Cc: Joao Pinto 
> >>> Cc: Jose Abreu 
> >>> Signed-off-by: Angelo Ribeiro 
> >>> ---
> >>>drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 98 
> >>> ---
> >>>1 file changed, 90 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> >>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >>> index b18351b..9de3645 100644
> >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >>> @@ -91,6 +91,7 @@
> >>>#define VID_MODE_TYPE_BURST0x2
> >>>#define VID_MODE_TYPE_MASK 0x3
> >>>#define VID_MODE_VPG_ENABLEBIT(16)
> >>> +#define VID_MODE_VPG_MODEBIT(20)
> >>>#define VID_MODE_VPG_HORIZONTALBIT(24)
> >>>
> >>>#define DSI_VID_PKT_SIZE   0x3c
> >>> @@ -221,6 +222,21 @@
> >>>#define PHY_STATUS_TIMEOUT_US  1
> >>>#define CMD_PKT_STATUS_TIMEOUT_US  2
> >>>
> >>> +#ifdef CONFIG_DEBUG_FS
> >>> +#define VPG_DEFS(name, dsi) \
> >>> + ((void __force *)&((*dsi).vpg_defs.name))
> >>> +
> >>> +#define REGISTER(name, mask, dsi) \
> >>> + { #name, VPG_DEFS(name, dsi), mask, dsi }
> >>> +
> >>> +struct debugfs_entries {
> >>> + const char  *name;
> >>> + bool*reg;
> >>> + u32 mask;
> >>> + struct dw_mipi_dsi  *dsi;
> >>> +};
> >>> +#endif /* CONFIG_DEBUG_FS */
> >>> +
> >>>struct dw_mipi_dsi {
> >>>   struct drm_bridge bridge;
> >>>   struct mipi_dsi_host dsi_host;
> >>> @@ -238,9 +254,12 @@ struct dw_mipi_dsi {
> >>>
> >>>#ifdef CONFIG_DEBUG_FS
> >>>   struct dentry *debugfs;
> >>> -
> >>> - bool vpg;
> >>> - bool vpg_horizontal;
> >>> + struct debugfs_entries *debugfs_vpg;
> >>> + struct {
> >>> + bool vpg;
> >>> + bool vpg_horizontal;
> >>> + bool vpg_ber_pattern;
> >>> + } vpg_defs;
> >>>#endif /* CONFIG_DEBUG_FS */
> >>>
> >>>   struct dw_mipi_dsi *master; /* dual-dsi master ptr */
> >>> @@ -530,9 +549,11 @@ static void dw_mipi_dsi_video_mode_config(struct 
> >>> dw_mipi_dsi *dsi)
> >>>   val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;
> >>>
> >>>#ifdef CONFIG_DEBUG_FS
> >>> - if (dsi->vpg) {
> >>> + if (dsi->vpg_defs.vpg) {
> >>>   val |= VID_MODE_VPG_ENABLE;
> >>> - val |= dsi->vpg_horizontal ? VID_MODE_VPG_HORIZONTAL : 0;
> >>> + val |= dsi->vpg_defs.vpg_horizontal ?
> >>> +VID_MODE_VPG_HORIZONTAL : 0;
> >>> + val |= dsi->vpg_defs.vpg_ber_pattern ? VID_MODE_VPG_MODE : 0;
> >>>   }
> >>>#endif /* CONFIG_DEBUG_FS */
> >>>
> >>> @@ -961,6 +982,68 @@ static const struct drm_bridge_funcs 
> >>> dw_mipi_dsi_bridge_funcs = {
> >>>
> >>>#ifdef CONFIG_DEBUG_FS
> >>>
> >>> +int dw_mipi_dsi_debugfs_write(void *data, u64 val)
> >>> +{
> >>> + struct debugfs_entries *vpg = data;
> >>> + struct dw_mipi_dsi *dsi;
> >>> + u32 mode_cfg;
> >>> +
> >>> + if (!vpg)
> >>> + return -ENODEV;
> >>> +
> >>> + dsi = vpg->dsi;
> >>> +
> >>> + *vpg->reg = (bool)val;
> >>> +
> >>> + mode_cfg = dsi_read(dsi, DSI_VID_MODE_CFG);
> >>> +
> >>> + if (*vpg->reg)
> >>> + mode_cfg |= vpg->mask;
> >>> + else
> >>> + mode_cfg &= ~vpg->mask;
> >>> +
> >>> + dsi_write(dsi, DSI_VID_MODE_CFG, mode_cfg);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +int dw_mipi_dsi_debugfs_show(void *data, u64 *val)
> >>> +{
> >>> + struct debugfs_entries *vpg = data;
> >>> +
> >>> + if (!vpg)
> >>> + return -ENODEV;
> >>> +
> >>> + *val = *vpg->

[PATCH v3 07/14] drm/panfrost: rename error labels in device_init

[Clément Péron]

Rename goto labels in device_init it will be easier to maintain.

Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 
---
 drivers/gpu/drm/panfrost/panfrost_device.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 8136babd3ba9..cc16d102b275 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -215,57 +215,57 @@ int panfrost_device_init(struct panfrost_device *pfdev)
err = panfrost_regulator_init(pfdev);
if (err) {
dev_err(pfdev->dev, "regulator init failed %d\n", err);
-   goto err_out0;
+   goto out_clk;
}
 
err = panfrost_reset_init(pfdev);
if (err) {
dev_err(pfdev->dev, "reset init failed %d\n", err);
-   goto err_out1;
+   goto out_regulator;
}
 
err = panfrost_pm_domain_init(pfdev);
if (err)
-   goto err_out2;
+   goto out_reset;
 
res = platform_get_resource(pfdev->pdev, IORESOURCE_MEM, 0);
pfdev->iomem = devm_ioremap_resource(pfdev->dev, res);
if (IS_ERR(pfdev->iomem)) {
dev_err(pfdev->dev, "failed to ioremap iomem\n");
err = PTR_ERR(pfdev->iomem);
-   goto err_out3;
+   goto out_pm_domain;
}
 
err = panfrost_gpu_init(pfdev);
if (err)
-   goto err_out3;
+   goto out_pm_domain;
 
err = panfrost_mmu_init(pfdev);
if (err)
-   goto err_out4;
+   goto out_gpu;
 
err = panfrost_job_init(pfdev);
if (err)
-   goto err_out5;
+   goto out_mmu;
 
err = panfrost_perfcnt_init(pfdev);
if (err)
-   goto err_out6;
+   goto out_job;
 
return 0;
-err_out6:
+out_job:
panfrost_job_fini(pfdev);
-err_out5:
+out_mmu:
panfrost_mmu_fini(pfdev);
-err_out4:
+out_gpu:
panfrost_gpu_fini(pfdev);
-err_out3:
+out_pm_domain:
panfrost_pm_domain_fini(pfdev);
-err_out2:
+out_reset:
panfrost_reset_fini(pfdev);
-err_out1:
+out_regulator:
panfrost_regulator_fini(pfdev);
-err_out0:
+out_clk:
panfrost_clk_fini(pfdev);
return err;
 }
-- 
2.25.1

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

[PATCH v3 00/14] Add regulator devfreq support to Panfrost

[Clément Péron]

Hi,

This serie cleans and adds regulator support to Panfrost devfreq.
This is mostly based on comment for the freshly introduced lima
devfreq.

We need to add regulator support because on Allwinner the GPU OPP
table defines both frequencies and voltages.

First patches [01-07] should not change the actual behavior
and introduce a proper panfrost_devfreq struct.

Regards,
Clément

Changes since v2:
 - Collect Alyssa Rosenzweig reviewed-by tags
 - Fix opp_set_regulator before adding opp_table (introduce in v2)
 - Call err_fini in case opp_add_table failed

Changes since v1:
 - Collect Steven Price reviewed-by tags
 - Fix spinlock comment
 - Drop OPP clock-name path
 - Drop device_property_test patch
 - Add rename error labels patch


Clément Péron (14):
  drm/panfrost: avoid static declaration
  drm/panfrost: clean headers in devfreq
  drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle
  drm/panfrost: introduce panfrost_devfreq struct
  drm/panfrost: use spinlock instead of atomic
  drm/panfrost: properly handle error in probe
  drm/panfrost: rename error labels in device_init
  drm/panfrost: move devfreq_init()/fini() in device
  drm/panfrost: dynamically alloc regulators
  drm/panfrost: add regulators to devfreq
  arm64: defconfig: Enable devfreq cooling device
  arm64: dts: allwinner: h6: Add cooling map for GPU
  [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
  [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be always

 .../dts/allwinner/sun50i-h6-beelink-gs1.dts   |   1 +
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 102 ++
 arch/arm64/configs/defconfig  |   1 +
 drivers/gpu/drm/panfrost/panfrost_devfreq.c   | 175 --
 drivers/gpu/drm/panfrost/panfrost_devfreq.h   |  30 ++-
 drivers/gpu/drm/panfrost/panfrost_device.c|  61 +++---
 drivers/gpu/drm/panfrost/panfrost_device.h|  14 +-
 drivers/gpu/drm/panfrost/panfrost_drv.c   |  15 +-
 drivers/gpu/drm/panfrost/panfrost_job.c   |  10 +-
 9 files changed, 296 insertions(+), 113 deletions(-)

-- 
2.25.1

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

RE: [PATCH 14/20] Documentation: misc/xilinx_sdfec: eliminate duplicated word

[Dragan Cvetic]

> -Original Message-
> From: Randy Dunlap 
> Sent: Tuesday 7 July 2020 19:04
> To: linux-ker...@vger.kernel.org
> Cc: Randy Dunlap ; Jonathan Corbet ; 
> linux-...@vger.kernel.org; linux-
> m...@vger.kernel.org; Mike Rapoport ; Jens Axboe 
> ; linux-bl...@vger.kernel.org; Jason
> Wessel ; Daniel Thompson 
> ; Douglas Anderson
> ; kgdb-bugrep...@lists.sourceforge.net; Wu Hao 
> ; linux-f...@vger.kernel.org;
> James Wang ; Liviu Dudau ; 
> Mihail Atanassov ;
> Mali DP Maintainers ; David Airlie ; 
> Daniel Vetter ; dri-
> de...@lists.freedesktop.org; Srinivas Pandruvada 
> ; Jiri Kosina ; linux-
> in...@vger.kernel.org; Wolfram Sang ; 
> linux-...@vger.kernel.org; Masahiro Yamada ;
> Michal Marek ; linux-kbu...@vger.kernel.org; Jacek 
> Anaszewski ; Pavel
> Machek ; Dan Murphy ; 
> linux-l...@vger.kernel.org; Dan Williams ;
> Paul Cercueil ; Thomas Bogendoerfer 
> ; linux-m...@vger.kernel.org; Derek
> Kiernan ; Dragan Cvetic ; Michael 
> Ellerman ; Benjamin
> Herrenschmidt ; Paul Mackerras ; 
> linuxppc-...@lists.ozlabs.org; Tony Krowiak
> ; Pierre Morel ; Halil Pasic 
> ; linux-s...@vger.kernel.org;
> Matthew Wilcox ; Hannes Reinecke ; 
> linux-s...@vger.kernel.org; James E.J. Bottomley
> ; Martin K. Petersen ; Jarkko 
> Sakkinen ;
> Mimi Zohar ; linux-integr...@vger.kernel.org; 
> keyri...@vger.kernel.org; Paolo Bonzini
> ; k...@vger.kernel.org; Andrew Morton 
> 
> Subject: [PATCH 14/20] Documentation: misc/xilinx_sdfec: eliminate duplicated 
> word
> 
> Drop the doubled word "the".
> 
> Signed-off-by: Randy Dunlap 
> Cc: Jonathan Corbet 
> Cc: linux-...@vger.kernel.org
> Cc: Derek Kiernan 
> Cc: Dragan Cvetic 
> ---
>  Documentation/misc-devices/xilinx_sdfec.rst |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-next-20200701.orig/Documentation/misc-devices/xilinx_sdfec.rst
> +++ linux-next-20200701/Documentation/misc-devices/xilinx_sdfec.rst
> @@ -78,7 +78,7 @@ application interfaces:
>- open: Implements restriction that only a single file descriptor can be 
> open per SD-FEC instance at any time
>- release: Allows another file descriptor to be open, that is after 
> current file descriptor is closed
>- poll: Provides a method to monitor for SD-FEC Error events
> -  - unlocked_ioctl: Provides the the following ioctl commands that allows 
> the application configure the SD-FEC core:
> +  - unlocked_ioctl: Provides the following ioctl commands that allows the 
> application configure the SD-FEC core:
> 
>   - :c:macro:`XSDFEC_START_DEV`
>   - :c:macro:`XSDFEC_STOP_DEV`

Acked-by: Dragan Cvetic 
Thanks Randy

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

[PATCH v3 05/14] drm/panfrost: use spinlock instead of atomic

[Clément Péron]

Convert busy_count to a simple int protected by spinlock.

Reviewed-by: Steven Price 
Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 
---
 drivers/gpu/drm/panfrost/panfrost_devfreq.c | 43 +++--
 drivers/gpu/drm/panfrost/panfrost_devfreq.h |  9 -
 2 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 962550363391..78753cfb59fb 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -12,16 +12,12 @@
 
 static void panfrost_devfreq_update_utilization(struct panfrost_devfreq 
*pfdevfreq)
 {
-   ktime_t now;
-   ktime_t last;
-
-   if (!pfdevfreq->devfreq)
-   return;
+   ktime_t now, last;
 
now = ktime_get();
last = pfdevfreq->time_last_update;
 
-   if (atomic_read(&pfdevfreq->busy_count) > 0)
+   if (pfdevfreq->busy_count > 0)
pfdevfreq->busy_time += ktime_sub(now, last);
else
pfdevfreq->idle_time += ktime_sub(now, last);
@@ -59,10 +55,14 @@ static int panfrost_devfreq_get_dev_status(struct device 
*dev,
 {
struct panfrost_device *pfdev = dev_get_drvdata(dev);
struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
+   unsigned long irqflags;
+
+   status->current_frequency = clk_get_rate(pfdev->clock);
+
+   spin_lock_irqsave(&pfdevfreq->lock, irqflags);
 
panfrost_devfreq_update_utilization(pfdevfreq);
 
-   status->current_frequency = clk_get_rate(pfdev->clock);
status->total_time = ktime_to_ns(ktime_add(pfdevfreq->busy_time,
   pfdevfreq->idle_time));
 
@@ -70,6 +70,8 @@ static int panfrost_devfreq_get_dev_status(struct device *dev,
 
panfrost_devfreq_reset(pfdevfreq);
 
+   spin_unlock_irqrestore(&pfdevfreq->lock, irqflags);
+
dev_dbg(pfdev->dev, "busy %lu total %lu %lu %% freq %lu MHz\n",
status->busy_time, status->total_time,
status->busy_time / (status->total_time / 100),
@@ -100,6 +102,8 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
else if (ret)
return ret;
 
+   spin_lock_init(&pfdevfreq->lock);
+
panfrost_devfreq_reset(pfdevfreq);
 
cur_freq = clk_get_rate(pfdev->clock);
@@ -162,15 +166,32 @@ void panfrost_devfreq_suspend(struct panfrost_device 
*pfdev)
 
 void panfrost_devfreq_record_busy(struct panfrost_devfreq *pfdevfreq)
 {
+   unsigned long irqflags;
+
+   if (!pfdevfreq->devfreq)
+   return;
+
+   spin_lock_irqsave(&pfdevfreq->lock, irqflags);
+
panfrost_devfreq_update_utilization(pfdevfreq);
-   atomic_inc(&pfdevfreq->busy_count);
+
+   pfdevfreq->busy_count++;
+
+   spin_unlock_irqrestore(&pfdevfreq->lock, irqflags);
 }
 
 void panfrost_devfreq_record_idle(struct panfrost_devfreq *pfdevfreq)
 {
-   int count;
+   unsigned long irqflags;
+
+   if (!pfdevfreq->devfreq)
+   return;
+
+   spin_lock_irqsave(&pfdevfreq->lock, irqflags);
 
panfrost_devfreq_update_utilization(pfdevfreq);
-   count = atomic_dec_if_positive(&pfdevfreq->busy_count);
-   WARN_ON(count < 0);
+
+   WARN_ON(--pfdevfreq->busy_count < 0);
+
+   spin_unlock_irqrestore(&pfdevfreq->lock, irqflags);
 }
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index 0697f8d5aa34..3392df1020be 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -4,6 +4,7 @@
 #ifndef __PANFROST_DEVFREQ_H__
 #define __PANFROST_DEVFREQ_H__
 
+#include 
 #include 
 
 struct devfreq;
@@ -14,10 +15,16 @@ struct panfrost_device;
 struct panfrost_devfreq {
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+
ktime_t busy_time;
ktime_t idle_time;
ktime_t time_last_update;
-   atomic_t busy_count;
+   int busy_count;
+   /*
+* Protect busy_time, idle_time, time_last_update and busy_count
+* because these can be updated concurrently between multiple jobs.
+*/
+   spinlock_t lock;
 };
 
 int panfrost_devfreq_init(struct panfrost_device *pfdev);
-- 
2.25.1

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

Re: [PATCH v4 04/16] pwm: lpss: Add range limit check for the base_unit register value

[Andy Shevchenko]

On Wed, Jul 08, 2020 at 11:14:20PM +0200, Hans de Goede wrote:
> When the user requests a high enough period ns value, then the
> calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
> 
> But according to the data-sheet the way the PWM controller works is that
> each input clock-cycle the base_unit gets added to a N bit counter and
> that counter overflowing determines the PWM output frequency. Adding 0
> to the counter is a no-op. The data-sheet even explicitly states that
> writing 0 to the base_unit bits will result in the PWM outputting a
> continuous 0 signal.

And I don't see how you can get duty 100% / 0% (I don't remember which one is
equivalent to 0 in base unit) after this change. IIRC the problem here that
base unit when non-zero is always being added to the counter and it will
trigger the change of output at some point which is not what we want for 100% /
0% cases.

> When the user requestes a low enough period ns value, then the
> calculations in pwm_lpss_prepare() might result in a base_unit value
> which is bigger then base_unit_range - 1. Currently the codes for this
> deals with this by applying a mask:
> 
>   base_unit &= (base_unit_range - 1);
> 
> But this means that we let the value overflow the range, we throw away the
> higher bits and store whatever value is left in the lower bits into the
> register leading to a random output frequency, rather then clamping the
> output frequency to the highest frequency which the hardware can do.

It would be nice to have an example of calculus here.

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

Eventually I sat and wrote all this on paper. I see now that the problem
is in out of range of the period. And strongly we should clamp rather period
to the supported range, but your solution is an equivalent.

Only question is about the 100% / 0% duty cycle.

> Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
> Signed-off-by: Hans de Goede 
> ---
> Changes in v3:
> - Change upper limit of clamp to (base_unit_range - 1)
> - Add Fixes tag
> ---
>  drivers/pwm/pwm-lpss.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> index 43b1fc634af1..80d0f9c64f9d 100644
> --- a/drivers/pwm/pwm-lpss.c
> +++ b/drivers/pwm/pwm-lpss.c
> @@ -97,6 +97,9 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
> struct pwm_device *pwm,
>   freq *= base_unit_range;
>  
>   base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);
> + /* base_unit must not be 0 and we also want to avoid overflowing it */

> + base_unit = clamp_t(unsigned long long, base_unit, 1,
> + base_unit_range - 1);

A nit: one line.

>   on_time_div = 255ULL * duty_ns;
>   do_div(on_time_div, period_ns);
> @@ -105,7 +108,6 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
> struct pwm_device *pwm,
>   orig_ctrl = ctrl = pwm_lpss_read(pwm);
>   ctrl &= ~PWM_ON_TIME_DIV_MASK;
>   ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
> - base_unit &= (base_unit_range - 1);
>   ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
>   ctrl |= on_time_div;
>  
> -- 
> 2.26.2
> 

-- 
With Best Regards,
Andy Shevchenko


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

[PATCH v3 09/14] drm/panfrost: dynamically alloc regulators

[Clément Péron]

We will later introduce regulators managed by OPP.

Only alloc regulators when it's needed. This also help use
to release the regulators only when they are allocated.

Reviewed-by: Steven Price 
Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 
---
 drivers/gpu/drm/panfrost/panfrost_device.c | 14 +-
 drivers/gpu/drm/panfrost/panfrost_device.h |  3 +--
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 464da1646398..0b0fb45aee82 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -90,9 +90,11 @@ static int panfrost_regulator_init(struct panfrost_device 
*pfdev)
 {
int ret, i;
 
-   if (WARN(pfdev->comp->num_supplies > ARRAY_SIZE(pfdev->regulators),
-   "Too many supplies in compatible structure.\n"))
-   return -EINVAL;
+   pfdev->regulators = devm_kcalloc(pfdev->dev, pfdev->comp->num_supplies,
+sizeof(*pfdev->regulators),
+GFP_KERNEL);
+   if (!pfdev->regulators)
+   return -ENOMEM;
 
for (i = 0; i < pfdev->comp->num_supplies; i++)
pfdev->regulators[i].supply = pfdev->comp->supply_names[i];
@@ -117,8 +119,10 @@ static int panfrost_regulator_init(struct panfrost_device 
*pfdev)
 
 static void panfrost_regulator_fini(struct panfrost_device *pfdev)
 {
-   regulator_bulk_disable(pfdev->comp->num_supplies,
-   pfdev->regulators);
+   if (!pfdev->regulators)
+   return;
+
+   regulator_bulk_disable(pfdev->comp->num_supplies, pfdev->regulators);
 }
 
 static void panfrost_pm_domain_fini(struct panfrost_device *pfdev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h 
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 2efa59c9d1c5..953f7536a773 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -22,7 +22,6 @@ struct panfrost_job;
 struct panfrost_perfcnt;
 
 #define NUM_JOB_SLOTS 3
-#define MAX_REGULATORS 2
 #define MAX_PM_DOMAINS 3
 
 struct panfrost_features {
@@ -81,7 +80,7 @@ struct panfrost_device {
void __iomem *iomem;
struct clk *clock;
struct clk *bus_clock;
-   struct regulator_bulk_data regulators[MAX_REGULATORS];
+   struct regulator_bulk_data *regulators;
struct reset_control *rstc;
/* pm_domains for devices with more than one. */
struct device *pm_domain_devs[MAX_PM_DOMAINS];
-- 
2.25.1

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

Re: [PATCH] drm/vc4: dsi: Only register our component once a DSI device is attached

[Maxime Ripard]

Hi Eric,

On Tue, Jul 07, 2020 at 09:48:45AM -0700, Eric Anholt wrote:
> On Tue, Jul 7, 2020 at 3:26 AM Maxime Ripard  wrote:
> >
> > If the DSI driver is the last to probe, component_add will try to run all
> > the bind callbacks straight away and return the error code.
> >
> > However, since we depend on a power domain, we're pretty much guaranteed to
> > be in that case on the BCM2711, and are just lucky on the previous SoCs
> > since the v3d also depends on that power domain and is further in the probe
> > order.
> >
> > In that case, the DSI host will not stick around in the system: the DSI
> > bind callback will be executed, will not find any DSI device attached and
> > will return EPROBE_DEFER, and we will then remove the DSI host and ask to
> > be probed later on.
> >
> > But since that host doesn't stick around, DSI devices like the RaspberryPi
> > touchscreen whose probe is not linked to the DSI host (unlike the usual DSI
> > devices that will be probed through the call to mipi_dsi_host_register)
> > cannot attach to the DSI host, and we thus end up in a situation where the
> > DSI host cannot probe because the panel hasn't probed yet, and the panel
> > cannot probe because the DSI host hasn't yet.
> >
> > In order to break this cycle, let's wait until there's a DSI device that
> > attaches to the DSI host to register the component and allow to progress
> > further.
> >
> > Suggested-by: Andrzej Hajda 
> > Signed-off-by: Maxime Ripard 
> 
> I feel like I've written this patch before, but I've thankfully
> forgotten most of my battle with DSI probing.  As long as this still
> lets vc4 probe in the absence of a DSI panel in the DT as well, then
> this is enthusiastically acked.

I'm not really sure what you mean by that, did you mean vc4 has to probe
when the DSI controller is enabled but there's no panel described, or it
has to probe when the DSI controller is disabled?

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

[PATCH v3 01/14] drm/panfrost: avoid static declaration

[Clément Péron]

This declaration can be avoided so change it.

Reviewed-by: Steven Price 
Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 
---
 drivers/gpu/drm/panfrost/panfrost_devfreq.c | 38 ++---
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 413987038fbf..1b560b903ea6 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -14,7 +14,24 @@
 #include "panfrost_gpu.h"
 #include "panfrost_regs.h"
 
-static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev);
+static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev)
+{
+   ktime_t now;
+   ktime_t last;
+
+   if (!pfdev->devfreq.devfreq)
+   return;
+
+   now = ktime_get();
+   last = pfdev->devfreq.time_last_update;
+
+   if (atomic_read(&pfdev->devfreq.busy_count) > 0)
+   pfdev->devfreq.busy_time += ktime_sub(now, last);
+   else
+   pfdev->devfreq.idle_time += ktime_sub(now, last);
+
+   pfdev->devfreq.time_last_update = now;
+}
 
 static int panfrost_devfreq_target(struct device *dev, unsigned long *freq,
   u32 flags)
@@ -139,25 +156,6 @@ void panfrost_devfreq_suspend(struct panfrost_device 
*pfdev)
devfreq_suspend_device(pfdev->devfreq.devfreq);
 }
 
-static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev)
-{
-   ktime_t now;
-   ktime_t last;
-
-   if (!pfdev->devfreq.devfreq)
-   return;
-
-   now = ktime_get();
-   last = pfdev->devfreq.time_last_update;
-
-   if (atomic_read(&pfdev->devfreq.busy_count) > 0)
-   pfdev->devfreq.busy_time += ktime_sub(now, last);
-   else
-   pfdev->devfreq.idle_time += ktime_sub(now, last);
-
-   pfdev->devfreq.time_last_update = now;
-}
-
 void panfrost_devfreq_record_busy(struct panfrost_device *pfdev)
 {
panfrost_devfreq_update_utilization(pfdev);
-- 
2.25.1

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

[PATCH v14 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP

[Xin Ji]

The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.

Signed-off-by: Xin Ji 
---
 drivers/gpu/drm/bridge/analogix/Kconfig   |9 +
 drivers/gpu/drm/bridge/analogix/Makefile  |1 +
 drivers/gpu/drm/bridge/analogix/anx7625.c | 1939 +
 drivers/gpu/drm/bridge/analogix/anx7625.h |  391 ++
 4 files changed, 2340 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h

diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
b/drivers/gpu/drm/bridge/analogix/Kconfig
index e1fa7d8..024ea2a 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -25,3 +25,12 @@ config DRM_ANALOGIX_ANX78XX
 config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config DRM_ANALOGIX_ANX7625
+   tristate "Analogix Anx7625 MIPI to DP interface support"
+   depends on DRM
+   depends on OF
+   help
+ ANX7625 is an ultra-low power 4K mobile HD transmitter
+ designed for portable devices. It converts MIPI/DPI to
+ DisplayPort1.3 4K.
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
b/drivers/gpu/drm/bridge/analogix/Makefile
index 97669b3..44da392 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
 analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
 obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
new file mode 100644
index 000..0d6be64
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -0,0 +1,1939 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2020, Analogix Semiconductor. All rights reserved.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "anx7625.h"
+
+/*
+ * There is a sync issue while access I2C register between AP(CPU) and
+ * internal firmware(OCM), to avoid the race condition, AP should access
+ * the reserved slave address before slave address occurs changes.
+ */
+static int i2c_access_workaround(struct anx7625_data *ctx,
+struct i2c_client *client)
+{
+   u8 offset;
+   struct device *dev = &client->dev;
+   int ret;
+
+   if (client == ctx->last_client)
+   return 0;
+
+   ctx->last_client = client;
+
+   if (client == ctx->i2c.tcpc_client)
+   offset = RSVD_00_ADDR;
+   else if (client == ctx->i2c.tx_p0_client)
+   offset = RSVD_D1_ADDR;
+   else if (client == ctx->i2c.tx_p1_client)
+   offset = RSVD_60_ADDR;
+   else if (client == ctx->i2c.rx_p0_client)
+   offset = RSVD_39_ADDR;
+   else if (client == ctx->i2c.rx_p1_client)
+   offset = RSVD_7F_ADDR;
+   else
+   offset = RSVD_00_ADDR;
+
+   ret = i2c_smbus_write_byte_data(client, offset, 0x00);
+   if (ret < 0)
+   DRM_DEV_ERROR(dev,
+ "fail to access i2c id=%x\n:%x",
+ client->addr, offset);
+
+   return ret;
+}
+
+static int anx7625_reg_read(struct anx7625_data *ctx,
+   struct i2c_client *client, u8 reg_addr)
+{
+   int ret;
+   struct device *dev = &client->dev;
+
+   i2c_access_workaround(ctx, client);
+
+   ret = i2c_smbus_read_byte_data(client, reg_addr);
+   if (ret < 0)
+   DRM_DEV_ERROR(dev, "read i2c fail id=%x:%x\n",
+ client->addr, reg_addr);
+
+   return ret;
+}
+
+static int anx7625_reg_block_read(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 reg_addr, u8 len, u8 *buf)
+{
+   int ret;
+   struct device *dev = &client->dev;
+
+   i2c_access_workaround(ctx, client);
+
+   ret = i2c_smbus_read_i2c_block_data(client, reg_addr, len, buf);
+   if (ret < 0)
+   DRM_DEV_ERROR(dev, "read i2c block fail id=%x:%x\n",
+ client->addr, reg_addr);
+
+   return ret;
+}
+
+static int anx7625_reg_write(struct anx7625_data *ctx,
+struct i2c_client *client,
+u8 reg_addr, u8 reg_val)
+{
+   int ret;
+   struct device *dev = &client->dev;
+
+   i2c_access_workaround(ctx, client);
+

Re: [PATCH v4 05/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume

[Andy Shevchenko]

On Wed, Jul 08, 2020 at 11:14:21PM +0200, Hans de Goede wrote:
> Before this commit a suspend + resume of the LPSS PWM controller
> would result in the controller being reset to its defaults of
> output-freq = clock/256, duty-cycle=100%, until someone changes
> to the output-freq and/or duty-cycle are made.
> 
> This problem has been masked so far because the main consumer
> (the i915 driver) was always making duty-cycle changes on resume.
> With the conversion of the i915 driver to the atomic PWM API the
> driver now only disables/enables the PWM on suspend/resume leaving
> the output-freq and duty as is, triggering this problem.
> 
> The LPSS PWM controller has a mechanism where the ctrl register value
> and the actual base-unit and on-time-div values used are latched. When
> software sets the SW_UPDATE bit then at the end of the current PWM cycle,
> the new values from the ctrl-register will be latched into the actual
> registers, and the SW_UPDATE bit will be cleared.
> 
> The problem is that before this commit our suspend/resume handling
> consisted of simply saving the PWM ctrl register on suspend and
> restoring it on resume, without setting the PWM_SW_UPDATE bit.
> When the controller has lost its state over a suspend/resume and thus
> has been reset to the defaults, just restoring the register is not
> enough. We must also set the SW_UPDATE bit to tell the controller to
> latch the restored values into the actual registers.
> 
> Fixing this problem is not as simple as just or-ing in the value which
> is being restored with SW_UPDATE. If the PWM was enabled before we must
> write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE.
> We must also wait for PWM_SW_UPDATE to become 0 again and depending on the
> model we must do this either before or after the setting of PWM_ENABLE.
> 
> All the necessary logic for doing this is already present inside
> pwm_lpss_apply(), so instead of duplicating this inside the resume
> handler, this commit makes the resume handler use pwm_lpss_apply() to
> restore the settings when necessary. This fixes the output-freq and
> duty-cycle being reset to their defaults on resume.

...

> +static int __pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state, bool from_resume)
>  {
>   struct pwm_lpss_chip *lpwm = to_lpwm(chip);
>   int ret;
>  
>   if (state->enabled) {
>   if (!pwm_is_enabled(pwm)) {
> - pm_runtime_get_sync(chip->dev);
> + if (!from_resume)
> + pm_runtime_get_sync(chip->dev);
> +
>   ret = pwm_lpss_is_updating(pwm);
>   if (ret) {
> - pm_runtime_put(chip->dev);
> + if (!from_resume)
> + pm_runtime_put(chip->dev);
> +
>   return ret;
>   }
>   pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, 
> state->period);
>   pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
>   ret = pwm_lpss_wait_for_update(pwm);
>   if (ret) {
> - pm_runtime_put(chip->dev);
> + if (!from_resume)
> + pm_runtime_put(chip->dev);
> +
>   return ret;
>   }
>   pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);

>   }
>   } else if (pwm_is_enabled(pwm)) {
>   pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
> - pm_runtime_put(chip->dev);
> +
> + if (!from_resume)
> + pm_runtime_put(chip->dev);
>   }

I'm wondering if splitting more will make this look better, like:

...
if (from_resume) {
ret = pwm_lpss_prepare_enable(...); // whatever name you think 
suits better
} else {
pm_runtime_get_sync(...);
ret = pwm_lpss_prepare_enable(...);
if (ret)
pm_runtime_put(...);
}
...

-- 
With Best Regards,
Andy Shevchenko


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

[PATCH v3 08/14] drm/panfrost: move devfreq_init()/fini() in device

[Clément Péron]

Later we will introduce devfreq probing regulator if they
are present. As regulator should be probe only one time we
need to get this logic in the device_init().

panfrost_device is already taking care of devfreq_resume()
and devfreq_suspend(), so it's not totally illogic to move
the devfreq_init() and devfreq_fini() here.

Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 
---
 drivers/gpu/drm/panfrost/panfrost_device.c | 12 +++-
 drivers/gpu/drm/panfrost/panfrost_drv.c| 15 ++-
 2 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
b/drivers/gpu/drm/panfrost/panfrost_device.c
index cc16d102b275..464da1646398 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -212,10 +212,17 @@ int panfrost_device_init(struct panfrost_device *pfdev)
return err;
}
 
+   err = panfrost_devfreq_init(pfdev);
+   if (err) {
+   if (err != -EPROBE_DEFER)
+   dev_err(pfdev->dev, "devfreq init failed %d\n", err);
+   goto out_clk;
+   }
+
err = panfrost_regulator_init(pfdev);
if (err) {
dev_err(pfdev->dev, "regulator init failed %d\n", err);
-   goto out_clk;
+   goto out_devfreq;
}
 
err = panfrost_reset_init(pfdev);
@@ -265,6 +272,8 @@ int panfrost_device_init(struct panfrost_device *pfdev)
panfrost_reset_fini(pfdev);
 out_regulator:
panfrost_regulator_fini(pfdev);
+out_devfreq:
+   panfrost_devfreq_fini(pfdev);
 out_clk:
panfrost_clk_fini(pfdev);
return err;
@@ -278,6 +287,7 @@ void panfrost_device_fini(struct panfrost_device *pfdev)
panfrost_gpu_fini(pfdev);
panfrost_pm_domain_fini(pfdev);
panfrost_reset_fini(pfdev);
+   panfrost_devfreq_fini(pfdev);
panfrost_regulator_fini(pfdev);
panfrost_clk_fini(pfdev);
 }
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 882fecc33fdb..4dda68689015 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -14,7 +14,6 @@
 #include 
 
 #include "panfrost_device.h"
-#include "panfrost_devfreq.h"
 #include "panfrost_gem.h"
 #include "panfrost_mmu.h"
 #include "panfrost_job.h"
@@ -606,13 +605,6 @@ static int panfrost_probe(struct platform_device *pdev)
goto err_out0;
}
 
-   err = panfrost_devfreq_init(pfdev);
-   if (err) {
-   if (err != -EPROBE_DEFER)
-   dev_err(&pdev->dev, "Fatal error during devfreq 
init\n");
-   goto err_out1;
-   }
-
pm_runtime_set_active(pfdev->dev);
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_enable(pfdev->dev);
@@ -625,16 +617,14 @@ static int panfrost_probe(struct platform_device *pdev)
 */
err = drm_dev_register(ddev, 0);
if (err < 0)
-   goto err_out2;
+   goto err_out1;
 
panfrost_gem_shrinker_init(ddev);
 
return 0;
 
-err_out2:
-   pm_runtime_disable(pfdev->dev);
-   panfrost_devfreq_fini(pfdev);
 err_out1:
+   pm_runtime_disable(pfdev->dev);
panfrost_device_fini(pfdev);
 err_out0:
drm_dev_put(ddev);
@@ -650,7 +640,6 @@ static int panfrost_remove(struct platform_device *pdev)
panfrost_gem_shrinker_cleanup(ddev);
 
pm_runtime_get_sync(pfdev->dev);
-   panfrost_devfreq_fini(pfdev);
panfrost_device_fini(pfdev);
pm_runtime_put_sync_suspend(pfdev->dev);
pm_runtime_disable(pfdev->dev);
-- 
2.25.1

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

[PATCH v3 11/14] arm64: defconfig: Enable devfreq cooling device

[Clément Péron]

Devfreq cooling device framework is used in Panfrost
to throttle GPU in order to regulate its temperature.

Enable this driver for ARM64 SoC.

Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 883e8bace3ed..1b7f9ffdc314 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -501,6 +501,7 @@ CONFIG_SENSORS_INA2XX=m
 CONFIG_SENSORS_INA3221=m
 CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
 CONFIG_CPU_THERMAL=y
+CONFIG_DEVFREQ_THERMAL=y
 CONFIG_THERMAL_EMULATION=y
 CONFIG_QORIQ_THERMAL=m
 CONFIG_SUN8I_THERMAL=y
-- 
2.25.1

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

[PATCH v14 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema

[Xin Ji]

anx7625: MIPI to DP transmitter DT schema

Signed-off-by: Xin Ji 
Reviewed-by: Rob Herring 
---
 .../bindings/display/bridge/analogix,anx7625.yaml  | 95 ++
 1 file changed, 95 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
new file mode 100644
index 000..60585a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analogix Semiconductor, Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+
+maintainers:
+  - Xin Ji 
+
+description: |
+  The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+  designed for portable devices.
+
+properties:
+  compatible:
+items:
+  - const: analogix,anx7625
+
+  reg:
+maxItems: 1
+
+  interrupts:
+description: used for interrupt pin B8.
+maxItems: 1
+
+  enable-gpios:
+description: used for power on chip control, POWER_EN pin D2.
+maxItems: 1
+
+  reset-gpios:
+description: used for reset chip control, RESET_N pin B7.
+maxItems: 1
+
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description:
+  Video port for MIPI DSI input.
+
+  port@1:
+type: object
+description:
+  Video port for panel or connector.
+
+required:
+- port@0
+- port@1
+
+required:
+  - compatible
+  - reg
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+encoder@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
+reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi2dp_bridge_in: port@0 {
+reg = <0>;
+anx7625_in: endpoint {
+remote-endpoint = <&mipi_dsi>;
+};
+};
+
+mipi2dp_bridge_out: port@1 {
+reg = <1>;
+anx7625_out: endpoint {
+remote-endpoint = <&panel_in>;
+};
+};
+};
+};
+};
-- 
2.7.4

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

Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can

[Steev Klimaszewski]

Hi,

On 7/9/20 11:12 PM, Doug Anderson wrote:

root@c630:~# bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
root@c630:~# i2cdump ${bus} 0x50 i > edid
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-16, address 0x50, mode i2c block
Continue? [Y/n]
root@c630:~# edid-decode edid
edid-decode (hex):

00 ff ff ff ff ff ff 00 09 e5 d1 07 00 00 00 00
01 1c 01 04 a5 1d 11 78 0a 1d b0 a6 58 54 9e 26
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 c0 39 80 18 71 38 28 40 30 20
36 00 26 a5 10 00 00 1a 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 1a 00 00 00 fe 00 42
4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe
00 4e 56 31 33 33 46 48 4d 2d 4e 36 31 0a 00 9a

03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb
fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73
44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61
92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2
66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70
43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc
45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3
30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29



EDID version: 1.4
Manufacturer: BOE Model 2001 Serial Number 0
Made in week 1 of 2018
Digital display
8 bits per primary color channel
DisplayPort interface
Maximum image size: 29 cm x 17 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:4:4
First detailed timing includes the native pixel format and preferred
refresh rate
Color Characteristics
Red:   0.6484, 0.3447
Green: 0.3310, 0.6181
Blue:  0.1503, 0.0615
White: 0.3125, 0.3281
Established Timings I & II: none
Standard Timings: none
Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm
 1920 1968 2000 2200 ( 48  32 200)
 1080 1083 1089 1120 (  3   6  31)
 +hsync -vsync
 VertFreq: 60.000 Hz, HorFreq: 67.200 kHz
Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 1a  
Alphanumeric Data String: BOE CQ
Alphanumeric Data String: NV133FHM-N61
Checksum: 0x9a



Unknown EDID Extension Block 0x03
03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb .&.w...qo...C.j.
fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73  ... 9."nehwp..4s
44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61 D!...m.b.*|...ja
92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2 ...SL9...#.H.9..
66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70 f.p..w.J..Lrn]Gp
43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc C..x..A..j(.
45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3 E*..5.4.>.^.
30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29 0^.).H.1..;)
Checksum: 0x29 (should be 0x82)


- My edid does in fact say it's 8bit

Crazy!  Mine:

Extracted contents:
header:  00 ff ff ff ff ff ff 00
serial number:   09 e5 2d 08 00 00 00 00 23 1c
version: 01 04
basic params:95 1d 11 78 02
chroma info: d5 00 a6 58 54 9f 27 0f 4f 57
established: 00 00 00
standard:01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:c0 39 80 18 71 38 28 40 30 20 36 00 26 a5 10 00 00 1a
descriptor 2:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 3:00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20
descriptor 4:00 00 00 fe 00 4e 56 31 33 33 46 48 4d 2d 4e 36 32 0a
extensions:  00
checksum:40

Manufacturer: BOE Model 82d Serial Number 0
Made week 35 of 2018
EDID version: 1.4
Digital display
6 bits per primary color channel
DisplayPort interface
Maximum image size: 29 cm x 17 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm
1920 1968 2000 2200 hborder 0
1080 1083 1089 1120 vborder 0
+hsync -vsync
Manufacturer-specified data, tag 0
ASCII string: BOE
ASCII string: NV133FHM-N62
Checksum: 0x40 (valid)

Unknown extension block

EDID block does NOT conform to EDID 1.3!
 Missing name descriptor
 Missing monitor ranges
 Detailed block string not properly terminated
EDID block does not conform at all!
 Has 128 nonconformant extension block(s)


I did attempt to modify the patch, and I don't think I did it correctly

Around line 232, I changed

IS_SC7180_TARGET(c->hw.hwversion))

to

IS_SC7180_TARGET(c->hw.hwversion) ||

IS_SDM845_TARGET(c->hw.hwversion))


But it would seem that only gets us 1/2 way there...

https://dev.gentoo.org/~steev/files/image2.jpg


But should I continue on this path, or should we be finding others who 
have an N61 and see what their EDID reports?


I have another c630, but unfortunately, it appears to have the IVO 
screen in it, instead of another N61.  I asked another user and he also 
had the IVO.


-- steev

___
dri-devel mailing list
dri-

Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can

[Steev Klimaszewski]

On 7/9/20 10:12 PM, Steev Klimaszewski wrote:


On 7/9/20 9:14 PM, Doug Anderson wrote:

Hi,

On Thu, Jul 9, 2020 at 6:38 PM Doug Anderson  
wrote:

Hi,

On Thu, Jul 9, 2020 at 6:19 PM Steev Klimaszewski  
wrote:

Hi Doug,

I've been testing 5.8 and linux-next on the Lenovo Yoga C630, and 
with this patch applied, there is really bad banding on the display.


I'm really bad at explaining it, but you can see the differences in 
the following:


24bit (pre-5.8) - https://dev.gentoo.org/~steev/files/image0.jpg

18bit (5.8/linux-next) - 
https://dev.gentoo.org/~steev/files/image1.jpg

Presumably this means that your panel is defined improperly? If the
panel reports that it's a 6 bits per pixel panel but it's actually an
8 bits per pixel panel then you'll run into this problem.

I would have to assume you have a bunch of out of tree patches to
support your hardware since I don't see any device trees in linuxnext
(other than cheza) that use this bridge chip.  Otherwise I could try
to check and confirm that was the problem.

Ah, interesting.  Maybe you have the panel:

boe,nv133fhm-n61

As far as I can tell from the datasheet (I have the similar
boe,nv133fhm-n62) this is a 6bpp panel.  ...but if you feed it 8bpp
the banding goes away!  Maybe the panel itself knows how to dither???
...or maybe the datasheet / edid are wrong and this is actually an
8bpp panel.  Seems unlikely...

In any case, one fix is to pick
, 


though right now that patch is only enabled for sc7180.  Maybe you
could figure out how to apply it to your hardware?

...another fix would be to pretend that your panel is 8bpp even though
it's actually 6bpp.  Ironically if anyone ever tried to configure BPP
from the EDID they'd go back to 6bpp.  You can read the EDID of your
panel with this:

bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
i2cdump ${bus} 0x50 i

When I do that and then decode it on the "boe,nv133fhm-n62" panel, I 
find:


6 bits per primary color channel

-Doug



Hi Doug,

Decoding it does show be to boe,nv133fhm-n61 - and yeah it does say 
it's 6-bit according to panelook's specs for it.



I'll take a look at the patch and see what I can come up with... at 
the moment, I'm forcing it to be 8bit and that does "work fine" but 
I'd like it to be fixed properly instead of my hack.


Thanks for your time and work!

-- Steev

For what it's worth - the 5.8 that I'm testing is at 
https://github.com/steev/linux/commits/c630-5.8-rc4-inline-encryption

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

Re: [PATCH v3 0/6] Generic USB Display driver

[Lubomir Rintel]

Hello,

On 29 May 2020 Noralf Trønnes wrote:
...
> This series adds a USB host driver and a device/gadget driver to achieve
> that.
> 
> The reason for calling it 'Generic' is so anyone can make a USB
> display/adapter against this driver, all that's needed is to add a USB
> vid:pid. I have done a microcontroller implementation hack just to see
> how that would work out[1] (which unconvered a couple of bugs in the
> host driver).
...

This is actually very cool; finally a good way to drive the cheapo
SPI/I2C displays from computers whose only means of expansion is USB
with a little help from a microcontroller. I've actually had some
success doing just that [1].

[1] 
https://assets.octodon.social/media_attachments/files/009/983/960/original/64ad8ea46c1b06c5.jpg

I suppose you can add:

Tested-by: Lubomir Rintel 

I've had to jump through some hoops though.

My OLED display is a 128x64 SSD1306 [1] driven from the SPI bus. The frame
buffer SRAM is normally scanned out in stripes of 8 vertical pixels called
"pages". When the display is turned on its side, with "vertical
addressing mode" and "segment remapping" enabled and bytes being sent LSB
first, it appears linear -- it's easy to repaint the whole display from
what is now the top left corner to the bottom right. This is very
convenient for painting pixels as they come, without bufferring them or
doing any conversions (assuming that memory and cpu cycles are at
premium on MCUs).

[1] https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf

There doesn't seem a comfortable way to do partial redraws though. Would
you find it objectionable if the device could indicate that needs full
frames instead of just the damaged areas? Perhaps then the driver
wouldn't even need to bother issuing GUD_DRM_USB_REQ_SET_BUFFER to
displays dumb enough to be incapable of partial redraws and decompression.

My work-in-progress code that works on STM32F103 (e.g. "Blue Pill"
boards), or GD32VF103 (RISC-V "Polos Alef") is at [2]. The partial redraws
that don't start from column zero or are not "page aligned" don't work
correctly for the time being; X11 doesn't seem to care.

[2] 
https://github.com/hackerspace/libopencm3-gf32v-examples/tree/lr/gd32v/examples/gd32v/f103/polos-alef/usb-display

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

Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can

[Steev Klimaszewski]

On 7/9/20 9:14 PM, Doug Anderson wrote:

Hi,

On Thu, Jul 9, 2020 at 6:38 PM Doug Anderson  wrote:

Hi,

On Thu, Jul 9, 2020 at 6:19 PM Steev Klimaszewski  wrote:

Hi Doug,

I've been testing 5.8 and linux-next on the Lenovo Yoga C630, and with this 
patch applied, there is really bad banding on the display.

I'm really bad at explaining it, but you can see the differences in the 
following:

24bit (pre-5.8) - https://dev.gentoo.org/~steev/files/image0.jpg

18bit (5.8/linux-next) - https://dev.gentoo.org/~steev/files/image1.jpg

Presumably this means that your panel is defined improperly?  If the
panel reports that it's a 6 bits per pixel panel but it's actually an
8 bits per pixel panel then you'll run into this problem.

I would have to assume you have a bunch of out of tree patches to
support your hardware since I don't see any device trees in linuxnext
(other than cheza) that use this bridge chip.  Otherwise I could try
to check and confirm that was the problem.

Ah, interesting.  Maybe you have the panel:

boe,nv133fhm-n61

As far as I can tell from the datasheet (I have the similar
boe,nv133fhm-n62) this is a 6bpp panel.  ...but if you feed it 8bpp
the banding goes away!  Maybe the panel itself knows how to dither???
...or maybe the datasheet / edid are wrong and this is actually an
8bpp panel.  Seems unlikely...

In any case, one fix is to pick
,
though right now that patch is only enabled for sc7180.  Maybe you
could figure out how to apply it to your hardware?

...another fix would be to pretend that your panel is 8bpp even though
it's actually 6bpp.  Ironically if anyone ever tried to configure BPP
from the EDID they'd go back to 6bpp.  You can read the EDID of your
panel with this:

bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
i2cdump ${bus} 0x50 i

When I do that and then decode it on the "boe,nv133fhm-n62" panel, I find:

6 bits per primary color channel

-Doug



Hi Doug,

Decoding it does show be to boe,nv133fhm-n61 - and yeah it does say it's 
6-bit according to panelook's specs for it.



I'll take a look at the patch and see what I can come up with... at the 
moment, I'm forcing it to be 8bit and that does "work fine" but I'd like 
it to be fixed properly instead of my hack.


Thanks for your time and work!

-- Steev

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

[PATCH v3 04/14] drm/panfrost: introduce panfrost_devfreq struct

[Clément Péron]

Introduce a proper panfrost_devfreq to deal with devfreq variables.

Reviewed-by: Steven Price 
Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 
---
 drivers/gpu/drm/panfrost/panfrost_devfreq.c | 76 -
 drivers/gpu/drm/panfrost/panfrost_devfreq.h | 20 +-
 drivers/gpu/drm/panfrost/panfrost_device.h  | 11 +--
 drivers/gpu/drm/panfrost/panfrost_job.c |  6 +-
 4 files changed, 66 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index df7b71da9a84..962550363391 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -10,23 +10,23 @@
 #include "panfrost_device.h"
 #include "panfrost_devfreq.h"
 
-static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev)
+static void panfrost_devfreq_update_utilization(struct panfrost_devfreq 
*pfdevfreq)
 {
ktime_t now;
ktime_t last;
 
-   if (!pfdev->devfreq.devfreq)
+   if (!pfdevfreq->devfreq)
return;
 
now = ktime_get();
-   last = pfdev->devfreq.time_last_update;
+   last = pfdevfreq->time_last_update;
 
-   if (atomic_read(&pfdev->devfreq.busy_count) > 0)
-   pfdev->devfreq.busy_time += ktime_sub(now, last);
+   if (atomic_read(&pfdevfreq->busy_count) > 0)
+   pfdevfreq->busy_time += ktime_sub(now, last);
else
-   pfdev->devfreq.idle_time += ktime_sub(now, last);
+   pfdevfreq->idle_time += ktime_sub(now, last);
 
-   pfdev->devfreq.time_last_update = now;
+   pfdevfreq->time_last_update = now;
 }
 
 static int panfrost_devfreq_target(struct device *dev, unsigned long *freq,
@@ -47,30 +47,31 @@ static int panfrost_devfreq_target(struct device *dev, 
unsigned long *freq,
return 0;
 }
 
-static void panfrost_devfreq_reset(struct panfrost_device *pfdev)
+static void panfrost_devfreq_reset(struct panfrost_devfreq *pfdevfreq)
 {
-   pfdev->devfreq.busy_time = 0;
-   pfdev->devfreq.idle_time = 0;
-   pfdev->devfreq.time_last_update = ktime_get();
+   pfdevfreq->busy_time = 0;
+   pfdevfreq->idle_time = 0;
+   pfdevfreq->time_last_update = ktime_get();
 }
 
 static int panfrost_devfreq_get_dev_status(struct device *dev,
   struct devfreq_dev_status *status)
 {
struct panfrost_device *pfdev = dev_get_drvdata(dev);
+   struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
 
-   panfrost_devfreq_update_utilization(pfdev);
+   panfrost_devfreq_update_utilization(pfdevfreq);
 
status->current_frequency = clk_get_rate(pfdev->clock);
-   status->total_time = ktime_to_ns(ktime_add(pfdev->devfreq.busy_time,
-  pfdev->devfreq.idle_time));
+   status->total_time = ktime_to_ns(ktime_add(pfdevfreq->busy_time,
+  pfdevfreq->idle_time));
 
-   status->busy_time = ktime_to_ns(pfdev->devfreq.busy_time);
+   status->busy_time = ktime_to_ns(pfdevfreq->busy_time);
 
-   panfrost_devfreq_reset(pfdev);
+   panfrost_devfreq_reset(pfdevfreq);
 
-   dev_dbg(pfdev->dev, "busy %lu total %lu %lu %% freq %lu MHz\n", 
status->busy_time,
-   status->total_time,
+   dev_dbg(pfdev->dev, "busy %lu total %lu %lu %% freq %lu MHz\n",
+   status->busy_time, status->total_time,
status->busy_time / (status->total_time / 100),
status->current_frequency / 1000 / 1000);
 
@@ -91,6 +92,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct device *dev = &pfdev->pdev->dev;
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+   struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
 
ret = dev_pm_opp_of_add_table(dev);
if (ret == -ENODEV) /* Optional, continue without devfreq */
@@ -98,7 +100,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
else if (ret)
return ret;
 
-   panfrost_devfreq_reset(pfdev);
+   panfrost_devfreq_reset(pfdevfreq);
 
cur_freq = clk_get_rate(pfdev->clock);
 
@@ -116,53 +118,59 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
dev_pm_opp_of_remove_table(dev);
return PTR_ERR(devfreq);
}
-   pfdev->devfreq.devfreq = devfreq;
+   pfdevfreq->devfreq = devfreq;
 
cooling = of_devfreq_cooling_register(dev->of_node, devfreq);
if (IS_ERR(cooling))
DRM_DEV_INFO(dev, "Failed to register cooling device\n");
else
-   pfdev->devfreq.cooling = cooling;
+   pfdevfreq->cooling = cooling;
 
return 0;
 }
 
 void panfrost_devfreq_fini(struct panfrost_device *pfdev)
 {
-   if (pfdev->devfreq.cooling)
-   devfreq_cooling_unregister(pfdev->devfreq.cool

[PATCH v3 14/14] [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be always

[Clément Péron]

Signed-off-by: Clément Péron 
---
 arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index 3f7ceeb1a767..14257f7476b8 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
@@ -245,6 +245,7 @@ reg_dcdca: dcdca {
};
 
reg_dcdcc: dcdcc {
+   regulator-always-on;
regulator-enable-ramp-delay = <32000>;
regulator-min-microvolt = <81>;
regulator-max-microvolt = <108>;
-- 
2.25.1

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

[PATCH v3 13/14] [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table

[Clément Péron]

Add an Operating Performance Points table for the GPU to
enable Dynamic Voltage & Frequency Scaling on the H6.

The voltage range is set with minival voltage set to the target
and the maximal voltage set to 1.2V. This allow DVFS framework to
work properly on board with fixed regulator.

Signed-off-by: Clément Péron 
---
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 80 
 1 file changed, 80 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 8f514a2169aa..a69f9e09a829 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -174,6 +174,7 @@ gpu: gpu@180 {
clocks = <&ccu CLK_GPU>, <&ccu CLK_BUS_GPU>;
clock-names = "core", "bus";
resets = <&ccu RST_BUS_GPU>;
+   operating-points-v2 = <&gpu_opp_table>;
#cooling-cells = <2>;
status = "disabled";
};
@@ -1036,4 +1037,83 @@ map0 {
};
};
};
+
+   gpu_opp_table: gpu-opp-table {
+   compatible = "operating-points-v2";
+
+   opp@21600 {
+   opp-hz = /bits/ 64 <21600>;
+   opp-microvolt = <81 81 120>;
+   };
+
+   opp@26400 {
+   opp-hz = /bits/ 64 <26400>;
+   opp-microvolt = <81 81 120>;
+   };
+
+   opp@31200 {
+   opp-hz = /bits/ 64 <31200>;
+   opp-microvolt = <81 81 120>;
+   };
+
+   opp@33600 {
+   opp-hz = /bits/ 64 <33600>;
+   opp-microvolt = <81 81 120>;
+   };
+
+   opp@36000 {
+   opp-hz = /bits/ 64 <36000>;
+   opp-microvolt = <82 82 120>;
+   };
+
+   opp@38400 {
+   opp-hz = /bits/ 64 <38400>;
+   opp-microvolt = <83 83 120>;
+   };
+
+   opp@40800 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <84 84 120>;
+   };
+
+   opp@42000 {
+   opp-hz = /bits/ 64 <42000>;
+   opp-microvolt = <85 85 120>;
+   };
+
+   opp@43200 {
+   opp-hz = /bits/ 64 <43200>;
+   opp-microvolt = <86 86 120>;
+   };
+
+   opp@45600 {
+   opp-hz = /bits/ 64 <45600>;
+   opp-microvolt = <87 87 120>;
+   };
+
+   opp@50400 {
+   opp-hz = /bits/ 64 <50400>;
+   opp-microvolt = <89 89 120>;
+   };
+
+   opp@54000 {
+   opp-hz = /bits/ 64 <54000>;
+   opp-microvolt = <91 91 120>;
+   };
+
+   opp@57600 {
+   opp-hz = /bits/ 64 <57600>;
+   opp-microvolt = <93 93 120>;
+   };
+
+   opp@62400 {
+   opp-hz = /bits/ 64 <62400>;
+   opp-microvolt = <95 95 120>;
+   };
+
+   opp@75600 {
+   opp-hz = /bits/ 64 <75600>;
+   opp-microvolt = <104 104 120>;
+   };
+   };
 };
-- 
2.25.1

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

Re: [PATCH v4 04/16] pwm: lpss: Add range limit check for the base_unit register value

[Andy Shevchenko]

On Thu, Jul 09, 2020 at 04:33:50PM +0200, Hans de Goede wrote:
> On 7/9/20 4:21 PM, Andy Shevchenko wrote:
> > On Thu, Jul 09, 2020 at 03:23:13PM +0200, Hans de Goede wrote:

...

> > You can use clamp_val().
> 
> I did not know about that, that will work nicely I will switch to clamp_val
> for the next version. I assume it is ok to keep your Reviewed-by with this
> very minor change?

Sure.

-- 
With Best Regards,
Andy Shevchenko


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

Re: [PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0

[Andy Shevchenko]

On Wed, Jul 08, 2020 at 11:14:22PM +0200, Hans de Goede wrote:
> The datasheet specifies that programming the base_unit part of the
> ctrl register to 0 results in a contineous low signal.
> 
> Adjust the get_state method to reflect this by setting pwm_state.period
> to 1 and duty_cycle to 0.

...

> + if (freq == 0) {
> + /* In this case the PWM outputs a continous low signal */

> + state->period = 1;

I guess this should be something like half of the range (so base unit calc
will give 128). Because with period = 1 (too small) it will give too small
base unit (if apply) and as a result we get high frequency pulses.

> + state->duty_cycle = 0;
> + } else {
>   state->period = NSEC_PER_SEC / (unsigned long)freq;
> + on_time_div *= state->period;
> + do_div(on_time_div, 255);
> + state->duty_cycle = on_time_div;
> + }

-- 
With Best Regards,
Andy Shevchenko


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

Re: [PATCH 11/20] Documentation: leds/ledtrig-transient: eliminate duplicated word

[Jacek Anaszewski]

On 7/7/20 8:04 PM, Randy Dunlap wrote:

Drop the doubled word "for".

Signed-off-by: Randy Dunlap 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Cc: Jacek Anaszewski 
Cc: Pavel Machek 
Cc: Dan Murphy 
Cc: linux-l...@vger.kernel.org
---
  Documentation/leds/ledtrig-transient.rst |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200701.orig/Documentation/leds/ledtrig-transient.rst
+++ linux-next-20200701/Documentation/leds/ledtrig-transient.rst
@@ -157,7 +157,7 @@ repeat the following step as needed::
echo 1 > activate - start timer = duration to run once
echo none > trigger
  
-This trigger is intended to be used for for the following example use cases:

+This trigger is intended to be used for the following example use cases:
  
   - Control of vibrate (phones, tablets etc.) hardware by user space app.

   - Use of LED by user space app as activity indicator.



Acked-by: Jacek Anaszewski 

--
Best regards,
Jacek Anaszewski
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] DRM PANEL DRIVERS: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.


 drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c 
b/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
index 3a0229d60095..09f6b0cac854 100644
--- a/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
+++ b/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- *  Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ *  Copyright (C) 2019 Texas Instruments Incorporated - https://www.ti.com
  *  Author: Peter Ujfalusi 
  */
 
-- 
2.27.0

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

[PATCH v3 10/14] drm/panfrost: add regulators to devfreq

[Clément Péron]

Some OPP tables specify voltage for each frequency. Devfreq can
handle these regulators but they should be get only 1 time to avoid
issue and know who is in charge.

If OPP table is probe don't init regulator.

Reviewed-by: Steven Price 
Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 
---
 drivers/gpu/drm/panfrost/panfrost_devfreq.c | 29 ++---
 drivers/gpu/drm/panfrost/panfrost_devfreq.h |  2 ++
 drivers/gpu/drm/panfrost/panfrost_device.c  | 11 +---
 3 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index d9007f44b772..8ab025d0035f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -93,14 +93,30 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
unsigned long cur_freq;
struct device *dev = &pfdev->pdev->dev;
struct devfreq *devfreq;
+   struct opp_table *opp_table;
struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
 
+   opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
+ pfdev->comp->num_supplies);
+   if (IS_ERR(opp_table)) {
+   ret = PTR_ERR(opp_table);
+   /* Continue if the optional regulator is missing */
+   if (ret != -ENODEV) {
+   DRM_DEV_ERROR(dev, "Couldn't set OPP regulators\n");
+   goto err_fini;
+   }
+   } else {
+   pfdevfreq->regulators_opp_table = opp_table;
+   }
+
ret = dev_pm_opp_of_add_table(dev);
-   if (ret == -ENODEV) /* Optional, continue without devfreq */
-   return 0;
-   else if (ret)
-   return ret;
+   if (ret) {
+   /* Optional, continue without devfreq */
+   if (ret == -ENODEV)
+   ret = 0;
+   goto err_fini;
+   }
pfdevfreq->opp_of_table_added = true;
 
spin_lock_init(&pfdevfreq->lock);
@@ -153,6 +169,11 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
pfdevfreq->opp_of_table_added = false;
}
+
+   if (pfdevfreq->regulators_opp_table) {
+   dev_pm_opp_put_regulators(pfdevfreq->regulators_opp_table);
+   pfdevfreq->regulators_opp_table = NULL;
+   }
 }
 
 void panfrost_devfreq_resume(struct panfrost_device *pfdev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index 210269944687..db6ea48e21f9 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -8,12 +8,14 @@
 #include 
 
 struct devfreq;
+struct opp_table;
 struct thermal_cooling_device;
 
 struct panfrost_device;
 
 struct panfrost_devfreq {
struct devfreq *devfreq;
+   struct opp_table *regulators_opp_table;
struct thermal_cooling_device *cooling;
bool opp_of_table_added;
 
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 0b0fb45aee82..1b5fc9221828 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -223,10 +223,13 @@ int panfrost_device_init(struct panfrost_device *pfdev)
goto out_clk;
}
 
-   err = panfrost_regulator_init(pfdev);
-   if (err) {
-   dev_err(pfdev->dev, "regulator init failed %d\n", err);
-   goto out_devfreq;
+   /* OPP will handle regulators */
+   if (!pfdev->pfdevfreq.opp_of_table_added) {
+   err = panfrost_regulator_init(pfdev);
+   if (err) {
+   dev_err(pfdev->dev, "regulator init failed %d\n", err);
+   goto out_devfreq;
+   }
}
 
err = panfrost_reset_init(pfdev);
-- 
2.25.1

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

[PATCH] drm/i915/selftests: Fix compare functions provided for sorting

[Sudeep Holla]

Both cmp_u32 and cmp_u64 are comparing the pointers instead of the value
at those pointers. This will result in incorrect/unsorted list. Fix it
by deferencing the pointers before comparison.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Sudeep Holla 
---
 drivers/gpu/drm/i915/gt/selftest_rps.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

Hi,

I am not sure if I can put 2 fixes tags, but these are the ones affected.

Fixes: 4ba74e53ada3 ("drm/i915/selftests: Verify frequency scaling with RPS")
Fixes: 8757797ff9c9 ("drm/i915/selftests: Repeat the rps clock frequency 
measurement")

I made similar mistake and after I fixed it, just looked if there are any
similar bugs and found this.

Regards,
Sudeep

diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c 
b/drivers/gpu/drm/i915/gt/selftest_rps.c
index 5049c3dd08a6..c91981e75ebf 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rps.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
@@ -44,9 +44,9 @@ static int cmp_u64(const void *A, const void *B)
 {
const u64 *a = A, *b = B;
 
-   if (a < b)
+   if (*a < *b)
return -1;
-   else if (a > b)
+   else if (*a > *b)
return 1;
else
return 0;
@@ -56,9 +56,9 @@ static int cmp_u32(const void *A, const void *B)
 {
const u32 *a = A, *b = B;
 
-   if (a < b)
+   if (*a < *b)
return -1;
-   else if (a > b)
+   else if (*a > *b)
return 1;
else
return 0;
-- 
2.17.1

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

[PATCH v3 12/14] arm64: dts: allwinner: h6: Add cooling map for GPU

[Clément Péron]

Add a simple cooling map for the GPU.

Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 
---
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 22 
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 78b1361dfbb9..8f514a2169aa 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -174,6 +174,7 @@ gpu: gpu@180 {
clocks = <&ccu CLK_GPU>, <&ccu CLK_BUS_GPU>;
clock-names = "core", "bus";
resets = <&ccu RST_BUS_GPU>;
+   #cooling-cells = <2>;
status = "disabled";
};
 
@@ -1012,6 +1013,27 @@ gpu-thermal {
polling-delay-passive = <0>;
polling-delay = <0>;
thermal-sensors = <&ths 1>;
+
+   trips {
+   gpu_alert: gpu-alert {
+   temperature = <85000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+
+   gpu-crit {
+   temperature = <10>;
+   hysteresis = <0>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <&gpu_alert>;
+   cooling-device = <&gpu THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   };
+   };
};
};
 };
-- 
2.25.1

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

Re: [RFC] Host1x/TegraDRM UAPI (sync points)

[Dmitry Osipenko]

08.07.2020 13:06, Mikko Perttunen пишет:
> On 7/7/20 2:06 PM, Dmitry Osipenko wrote:
>> 02.07.2020 15:10, Mikko Perttunen пишет:
>>> Ok, so we would have two kinds of syncpoints for the job; one
>>> for kernel job tracking; and one that userspace can
>>> manipulate as it wants to.
>>>
>>> Could we handle the job tracking syncpoint completely inside the kernel,
>>> i.e. allocate it in kernel during job submission, and add an increment
>>> for it at the end of the job (with condition OP_DONE)? For MLOCKing, the
>>> kernel already needs to insert a SYNCPT_INCR(OP_DONE) + WAIT +
>>> MLOCK_RELEASE sequence at the end of each job.
>>
>> If sync point is allocated within kernel, then we'll need to always
>> patch all job's sync point increments with the ID of the allocated sync
>> point, regardless of whether firewall enabled or not.
> 
> The idea was that the job tracking increment would also be added to the
> pushbuffer in the kernel, so gathers would only have increments for the
> "user syncpoints", if any. I think this should work for THI-based
> engines (e.g. VIC), you probably have better information about
> GR2D/GR3D. On newer Tegras we could use CHANNEL/APPID protection to
> prevent the gathers from incrementing these job tracking syncpoints.

Could you please clarify what is THI?

>> Secondly, I'm now recalling that only one sync point could be assigned
>> to a channel at a time on newer Tegras which support sync point
>> protection. So it sounds like we don't really have variants other than
>> to allocate one sync point per channel for the jobs usage if we want to
>> be able to push multiple jobs into channel's pushbuffer, correct?
>>
> 
> The other way around; each syncpoint can be assigned to one channel. One
> channel may have multiple syncpoints.

Okay! So we actually could use a single sync point per-job for user
increments + job tracking, correct?

>> ...
 Hmm, we actually should be able to have a one sync point per-channel
 for
 the job submission, similarly to what the current driver does!

 I'm keep forgetting about the waitbase existence!
>>>
>>> Tegra194 doesn't have waitbases, but if we are resubmitting all the jobs
>>> anyway, can't we just recalculate wait thresholds at that time?
>>
>> Yes, thresholds could be recalculated + job should be re-formed at the
>> push-time then.
>>
>> It also means that jobs always should be formed only at the push-time if
>> wait-command is utilized by cmdstream since the waits always need to be
>> patched because we won't know the thresholds until scheduler actually
>> runs the job.
> 
> Could we keep the job tracking syncpoints entirely within the kernel,
> and have all wait commands and other stuff that userspace does use the
> user syncpoints? Then kernel job tracking and userspace activity would
> be separate from each other.

I think this should work, but it's not clear to me what benefits this
brings to us if we could re-use the same user-allocated sync point for
both user increments + kernel job tracking.

Is the idea to protect from userspace incrementing sync point too much?
I.e. job could be treated as completed before CDMA is actually done with
it.

> Alternatively, if we know that jobs can only be removed from the middle
> of pushbuffers, and not added, we could replace any removed jobs with
> syncpoint increments in the pushbuffer and any thresholds would stay
> intact.

A bit unlikely that jobs could ever be removed from the middle of
hardware queue by the DRM scheduler.

Anyways, it should be nicer to shoot down everything and restart with a
clean slate when necessary, like it's already supposed to happen by the
scheduler.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] drm/mediatek: mtk_dpi: Convert to bridge driver

[Enric Balletbo i Serra]

Convert mtk_dpi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v2:
- Maintain error message when attach to bridge fails. (Boris)

 drivers/gpu/drm/mediatek/mtk_dpi.c | 71 ++
 1 file changed, 42 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index f7372dbdac0e..589ef33a1780 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -64,6 +64,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
+   struct drm_bridge bridge;
struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
@@ -83,9 +84,9 @@ struct mtk_dpi {
int refcount;
 };
 
-static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
+static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
 {
-   return container_of(e, struct mtk_dpi, encoder);
+   return container_of(b, struct mtk_dpi, bridge);
 }
 
 enum mtk_dpi_polarity {
@@ -521,50 +522,53 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
return 0;
 }
 
-static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
 {
-   return true;
+   drm_encoder_cleanup(encoder);
 }
 
-static void mtk_dpi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
+static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
+   .destroy = mtk_dpi_encoder_destroy,
+};
+
+static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+
+   return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
+&dpi->bridge, flags);
+}
+
+static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted_mode)
+{
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
drm_mode_copy(&dpi->mode, adjusted_mode);
 }
 
-static void mtk_dpi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_off(dpi);
 }
 
-static void mtk_dpi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_on(dpi);
mtk_dpi_set_display_mode(dpi, &dpi->mode);
 }
 
-static int mtk_dpi_atomic_check(struct drm_encoder *encoder,
-   struct drm_crtc_state *crtc_state,
-   struct drm_connector_state *conn_state)
-{
-   return 0;
-}
-
-static const struct drm_encoder_helper_funcs mtk_dpi_encoder_helper_funcs = {
-   .mode_fixup = mtk_dpi_encoder_mode_fixup,
-   .mode_set = mtk_dpi_encoder_mode_set,
-   .disable = mtk_dpi_encoder_disable,
-   .enable = mtk_dpi_encoder_enable,
-   .atomic_check = mtk_dpi_atomic_check,
+static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
+   .attach = mtk_dpi_bridge_attach,
+   .mode_set = mtk_dpi_bridge_mode_set,
+   .disable = mtk_dpi_bridge_disable,
+   .enable = mtk_dpi_bridge_enable,
 };
 
 static void mtk_dpi_start(struct mtk_ddp_comp *comp)
@@ -605,12 +609,11 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
dev_err(dev, "Failed to initialize decoder: %d\n", ret);
goto err_unregister;
}
-   drm_encoder_helper_add(&dpi->encoder, &mtk_dpi_encoder_helper_funcs);
 
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(&dpi->encoder, dpi->next_bridge, NULL, 0);
+   ret = drm_bridge_attach(&dpi->encoder, &dpi->bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -791,8 +794,15 @@ static int mtk_dpi_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, dpi);
 
+   dpi->bridge.funcs = &mtk_dpi_bridge_func

fbconsole needs more parameter validations.

[Tetsuo Handa]

Hello.

While trying to debug 
https://syzkaller.appspot.com/bug?extid=017265e8553724e514e8 ,
I noticed that a crash can happen without opening /dev/ttyXX .

For example, while a driver which syzbot is reporting accepts screen with
var.xres = var.yres = 0 (and a crash is not visible until trying to write to
/dev/ttyXX ), a driver for VMware environment which I'm using (dmesg says 
"fbcon:
svgadrmfb (fb0) is primary device") rejects screen with var.xres = var.yres = 0.
However, specifying var.xres = var.yres = 1 like below reproducer causes a crash
in my VMware environment.

--
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
const int fd = open("/dev/fb0", O_ACCMODE);
struct fb_var_screeninfo var = { };
ioctl(fd, FBIOGET_VSCREENINFO, &var);
var.xres = var.yres = 1;
ioctl(fd, FBIOPUT_VSCREENINFO, &var);
return 0;
}
--

--
[   20.10] BUG: unable to handle page fault for address: b80500d7b000
[   20.102225] #PF: supervisor write access in kernel mode
[   20.102226] #PF: error_code(0x0002) - not-present page
[   20.102227] PGD 13a48c067 P4D 13a48c067 PUD 13a48d067 PMD 132525067 PTE 0
[   20.102230] Oops: 0002 [#1] SMP
[   20.102232] CPU: 3 PID: 2786 Comm: a.out Not tainted 5.8.0-rc4+ #749
[   20.102233] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 02/27/2020
[   20.102237] RIP: 0010:bitfill_aligned+0x87/0x120 [cfbfillrect]
[   20.102238] Code: c3 45 85 db 0f 85 85 00 00 00 44 89 c0 31 d2 41 f7 f1 89 
c2 83 f8 07 76 41 8d 48 f8 c1 e9 03 48 83 c1 01 48 c1 e1 06 48 01 f1 <48> 89 3e 
48 89 7e 08 48 89 7e 10 48 89 7e 18 48 89 7e 20 48 89 7e
[   20.102239] RSP: 0018:b805012939a8 EFLAGS: 00010206
[   20.102240] RAX: 03fffe70 RBX: 9c20 RCX: b80520982000
[   20.102241] RDX: 03fffe70 RSI: b80500d7b000 RDI: 
[   20.102242] RBP: b805012939b8 R08: 9c20 R09: b80500d7aff8
[   20.102242] R10:  R11:  R12: 
[   20.102243] R13: 976734c0c000 R14:  R15: b80500982c80
[   20.102244] FS:  7f0c9589e740() GS:97673aec() 
knlGS:
[   20.102265] CS:  0010 DS:  ES:  CR0: 80050033
[   20.102265] CR2: b80500d7b000 CR3: 000136cdf004 CR4: 001606e0
[   20.102277] Call Trace:
[   20.102281]  cfb_fillrect+0x159/0x340 [cfbfillrect]
[   20.102385]  ? __mutex_unlock_slowpath+0x158/0x2d0
[   20.102493]  ? cfb_fillrect+0x340/0x340 [cfbfillrect]
[   20.102747]  vmw_fb_fillrect+0x12/0x30 [vmwgfx]
[   20.102755]  bit_clear_margins+0x92/0xf0 [fb]
[   20.102760]  fbcon_clear_margins+0x4c/0x50 [fb]
[   20.102763]  fbcon_switch+0x321/0x570 [fb]
[   20.102771]  redraw_screen+0xe0/0x250
[   20.102775]  fbcon_modechanged+0x164/0x1b0 [fb]
[   20.102779]  fbcon_update_vcs+0x15/0x20 [fb]
[   20.102781]  fb_set_var+0x364/0x3c0 [fb]
[   20.102817]  do_fb_ioctl+0x2ff/0x3f0 [fb]
[   20.102894]  ? find_held_lock+0x35/0xa0
[   20.103126]  ? __audit_syscall_entry+0xd8/0x120
[   20.103135]  ? kfree+0x25a/0x2b0
[   20.103139]  fb_ioctl+0x2e/0x40 [fb]
[   20.103141]  ksys_ioctl+0x86/0xc0
[   20.103144]  ? do_syscall_64+0x20/0xa0
[   20.103146]  __x64_sys_ioctl+0x15/0x20
[   20.103148]  do_syscall_64+0x54/0xa0
[   20.103151]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   20.103152] RIP: 0033:0x7f0c953b8307
[   20.103153] Code: Bad RIP value.
[   20.103154] RSP: 002b:7ffecbdce0f8 EFLAGS: 0246 ORIG_RAX: 
0010
[   20.103155] RAX: ffda RBX: 0003 RCX: 7f0c953b8307
[   20.103156] RDX: 7ffecbdce100 RSI: 4601 RDI: 0003
[   20.103156] RBP:  R08: 7f0c9568be80 R09: 
[   20.103157] R10: 7ffecbdcdb60 R11: 0246 R12: 004004f2
[   20.103158] R13: 7ffecbdce280 R14:  R15: 
[   20.103162] Modules linked in: mousedev rapl evdev input_leds led_class 
mac_hid psmouse pcspkr xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 
ipt_REJECT nf_reject_ipv4 xt_conntrack sg ebtable_nat af_packet ip6table_nat 
ip6table_mangle ip6table_raw iptable_nat nf_nat iptable_mangle iptable_raw 
nf_conntrack rtc_cmos nf_defrag_ipv4 ip_set nfnetlink ebtable_filter ebtables 
ip6table_filter ip6_tables iptable_filter bpfilter i2c_piix4 vmw_vmci ac 
intel_agp button intel_gtt ip_tables x_tables ata_generic pata_acpi serio_raw 
atkbd libps2 vmwgfx drm_kms_helper cfbfillrect syscopyarea cfbimgblt 
sysfillrect sysimgblt fb_sys_fops cfbcopyarea fb fbdev ttm drm i2c_core ahci 
drm_panel_orientation_quirks libahci backlight e1000 agpgart ata_piix libata 
i8042 serio unix ipv6 nf_defrag_ipv6
[   20.103194] CR2: b80500d7b000
[   20.103196] ---[ end trace b2348f839f6524f9 ]---
[   20.103198] RIP: 0010:bitfill_aligned+0x87/0x120 [cfbfillrect]
[   20.103200] Code: c3 45 85 db 0f 85 

Re: [PATCH v3 00/14] Add regulator devfreq support to Panfrost

[Clément Péron]

Hi,

On Thu, 9 Jul 2020 at 16:03, Clément Péron  wrote:
>
> Hi,
>
> This serie cleans and adds regulator support to Panfrost devfreq.
> This is mostly based on comment for the freshly introduced lima
> devfreq.
>
> We need to add regulator support because on Allwinner the GPU OPP
> table defines both frequencies and voltages.
>
> First patches [01-07] should not change the actual behavior
> and introduce a proper panfrost_devfreq struct.

Just saw that some changes have been made and pushed to 5.8-rc4.

I will push a v4 up to date.

Regards,
Clement


>
> Regards,
> Clément
>
> Changes since v2:
>  - Collect Alyssa Rosenzweig reviewed-by tags
>  - Fix opp_set_regulator before adding opp_table (introduce in v2)
>  - Call err_fini in case opp_add_table failed
>
> Changes since v1:
>  - Collect Steven Price reviewed-by tags
>  - Fix spinlock comment
>  - Drop OPP clock-name path
>  - Drop device_property_test patch
>  - Add rename error labels patch
>
>
> Clément Péron (14):
>   drm/panfrost: avoid static declaration
>   drm/panfrost: clean headers in devfreq
>   drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle
>   drm/panfrost: introduce panfrost_devfreq struct
>   drm/panfrost: use spinlock instead of atomic
>   drm/panfrost: properly handle error in probe
>   drm/panfrost: rename error labels in device_init
>   drm/panfrost: move devfreq_init()/fini() in device
>   drm/panfrost: dynamically alloc regulators
>   drm/panfrost: add regulators to devfreq
>   arm64: defconfig: Enable devfreq cooling device
>   arm64: dts: allwinner: h6: Add cooling map for GPU
>   [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
>   [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be always
>
>  .../dts/allwinner/sun50i-h6-beelink-gs1.dts   |   1 +
>  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 102 ++
>  arch/arm64/configs/defconfig  |   1 +
>  drivers/gpu/drm/panfrost/panfrost_devfreq.c   | 175 --
>  drivers/gpu/drm/panfrost/panfrost_devfreq.h   |  30 ++-
>  drivers/gpu/drm/panfrost/panfrost_device.c|  61 +++---
>  drivers/gpu/drm/panfrost/panfrost_device.h|  14 +-
>  drivers/gpu/drm/panfrost/panfrost_drv.c   |  15 +-
>  drivers/gpu/drm/panfrost/panfrost_job.c   |  10 +-
>  9 files changed, 296 insertions(+), 113 deletions(-)
>
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v14 0/2] Add initial support for slimport anx7625

[Xin Ji]

Hi all,

The following series add support for the Slimport ANX7625 transmitter, a
ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device.


This is the v14 version, any mistakes, please let me know, I will fix it in
the next series.

Change history:
v14: Fix comments from Sam and Nicolas
 - Check flags at drm_bridge_attach
 - Use panel_bridge instead of drm_panel
 - Fix not correct return value

v13: Fix comments from Launrent Pinchart and Rob Herring
 - Picked up Rob's Reviewed-By
 - Add .detect and .get_edid interface in bridge funcs.

v12: Fix comments from Hsin-Yi Wang
 - Rebase the code on kernel 5.7, fix DRM interface not match issue.

v11: Fix comments from Rob Herring
 - Update commit message.
 - Remove unused label.

v10: Fix comments from Rob Herring, Daniel.
 - Fix dt_binding_check warning.
 - Update description.

v9: Fix comments from Sam, Nicolas, Daniel
 - Remove extcon interface.
 - Remove DPI support.
 - Fix dt_binding_check complains.
 - Code clean up and update description.

v8: Fix comments from Nicolas.
 - Fix several coding format.
 - Update description.

v7:
 - Fix critical timing(eg:odd hfp/hbp) in "mode_fixup" interface,
   enhance MIPI RX tolerance by setting register MIPI_DIGITAL_ADJ_1 to 0x3D.


Xin Ji (2):
  dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema
  drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP

 .../bindings/display/bridge/analogix,anx7625.yaml  |   95 +
 drivers/gpu/drm/bridge/analogix/Kconfig|9 +
 drivers/gpu/drm/bridge/analogix/Makefile   |1 +
 drivers/gpu/drm/bridge/analogix/anx7625.c  | 1939 
 drivers/gpu/drm/bridge/analogix/anx7625.h  |  391 
 5 files changed, 2435 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h

-- 
2.7.4

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

[PATCH v3 06/14] drm/panfrost: properly handle error in probe

[Clément Péron]

Introduce a boolean to know if opp table has been added.

With this, we can call panfrost_devfreq_fini() in case of error
and release what has been initialised.

Reviewed-by: Steven Price 
Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 
---
 drivers/gpu/drm/panfrost/panfrost_devfreq.c | 25 -
 drivers/gpu/drm/panfrost/panfrost_devfreq.h |  1 +
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 78753cfb59fb..d9007f44b772 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -101,6 +101,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
return 0;
else if (ret)
return ret;
+   pfdevfreq->opp_of_table_added = true;
 
spin_lock_init(&pfdevfreq->lock);
 
@@ -109,8 +110,10 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
cur_freq = clk_get_rate(pfdev->clock);
 
opp = devfreq_recommended_opp(dev, &cur_freq, 0);
-   if (IS_ERR(opp))
-   return PTR_ERR(opp);
+   if (IS_ERR(opp)) {
+   ret = PTR_ERR(opp);
+   goto err_fini;
+   }
 
panfrost_devfreq_profile.initial_freq = cur_freq;
dev_pm_opp_put(opp);
@@ -119,8 +122,8 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
  DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
if (IS_ERR(devfreq)) {
DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
-   dev_pm_opp_of_remove_table(dev);
-   return PTR_ERR(devfreq);
+   ret = PTR_ERR(devfreq);
+   goto err_fini;
}
pfdevfreq->devfreq = devfreq;
 
@@ -131,15 +134,25 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
pfdevfreq->cooling = cooling;
 
return 0;
+
+err_fini:
+   panfrost_devfreq_fini(pfdev);
+   return ret;
 }
 
 void panfrost_devfreq_fini(struct panfrost_device *pfdev)
 {
struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
 
-   if (pfdevfreq->cooling)
+   if (pfdevfreq->cooling) {
devfreq_cooling_unregister(pfdevfreq->cooling);
-   dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
+   pfdevfreq->cooling = NULL;
+   }
+
+   if (pfdevfreq->opp_of_table_added) {
+   dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
+   pfdevfreq->opp_of_table_added = false;
+   }
 }
 
 void panfrost_devfreq_resume(struct panfrost_device *pfdev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index 3392df1020be..210269944687 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -15,6 +15,7 @@ struct panfrost_device;
 struct panfrost_devfreq {
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+   bool opp_of_table_added;
 
ktime_t busy_time;
ktime_t idle_time;
-- 
2.25.1

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

[PATCH v2 1/2] drm/mediatek: mtk_dpi: Rename bridge to next_bridge

[Enric Balletbo i Serra]

This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dpi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index d4f0fb7ad312..f7372dbdac0e 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -64,7 +64,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
-   struct drm_bridge *bridge;
+   struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
struct clk *engine_clk;
@@ -610,7 +610,7 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(&dpi->encoder, dpi->bridge, NULL, 0);
+   ret = drm_bridge_attach(&dpi->encoder, dpi->next_bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -770,11 +770,11 @@ static int mtk_dpi_probe(struct platform_device *pdev)
}
 
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- NULL, &dpi->bridge);
+ NULL, &dpi->next_bridge);
if (ret)
return ret;
 
-   dev_info(dev, "Found bridge node: %pOF\n", dpi->bridge->of_node);
+   dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
 
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
if (comp_id < 0) {
-- 
2.27.0

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

[PATCH v2] drm/msm: handle for EPROBE_DEFER for of_icc_get

[Jonathan Marek]

Check for errors instead of silently not using icc if the msm driver
probes before the interconnect driver.

Allow ENODATA for ocmem path, as it is optional and this error
is returned when "gfx-mem" path is provided but not "ocmem".

Remove the WARN_ON in msm_gpu_cleanup because INIT_LIST_HEAD won't have
been called on the list yet when going through the defer error path.

Changes in v2:
* Changed to not only check for EPROBE_DEFER

Signed-off-by: Jonathan Marek 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 17 ++---
 drivers/gpu/drm/msm/msm_gpu.c   |  2 --
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 89673c7ed473..0f5217202eb5 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -940,12 +940,20 @@ static int adreno_get_pwrlevels(struct device *dev,
 */
gpu->icc_path = of_icc_get(dev, NULL);
}
-   if (IS_ERR(gpu->icc_path))
+   if (IS_ERR(gpu->icc_path)) {
+   ret = PTR_ERR(gpu->icc_path);
gpu->icc_path = NULL;
+   return ret;
+   }
 
gpu->ocmem_icc_path = of_icc_get(dev, "ocmem");
-   if (IS_ERR(gpu->ocmem_icc_path))
+   if (IS_ERR(gpu->ocmem_icc_path)) {
+   ret = PTR_ERR(gpu->ocmem_icc_path);
gpu->ocmem_icc_path = NULL;
+   /* allow -ENODATA, ocmem icc is optional */
+   if (ret != -ENODATA)
+   return ret;
+   }
 
return 0;
 }
@@ -996,6 +1004,7 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
struct adreno_platform_config *config = pdev->dev.platform_data;
struct msm_gpu_config adreno_gpu_config  = { 0 };
struct msm_gpu *gpu = &adreno_gpu->base;
+   int ret;
 
adreno_gpu->funcs = funcs;
adreno_gpu->info = adreno_info(config->rev);
@@ -1007,7 +1016,9 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
 
adreno_gpu_config.nr_rings = nr_rings;
 
-   adreno_get_pwrlevels(&pdev->dev, gpu);
+   ret = adreno_get_pwrlevels(&pdev->dev, gpu);
+   if (ret)
+   return ret;
 
pm_runtime_set_autosuspend_delay(&pdev->dev,
adreno_gpu->info->inactive_period);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index a22d30622306..ccf9a0dd9706 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -959,8 +959,6 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
 
DBG("%s", gpu->name);
 
-   WARN_ON(!list_empty(&gpu->active_list));
-
for (i = 0; i < ARRAY_SIZE(gpu->rb); i++) {
msm_ringbuffer_destroy(gpu->rb[i]);
gpu->rb[i] = NULL;
-- 
2.26.1

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

Re: [PATCH v4 3/7] drm: msm: a6xx: set gpu freq through hfi

[Jonathan Marek]

On 7/9/20 4:00 PM, Akhil P Oommen wrote:

Newer targets support changing gpu frequency through HFI. So
use that wherever supported instead of the legacy method.



It was already using HFI on newer targets. Don't break it in one commit 
then fix it in the next.



Signed-off-by: Akhil P Oommen 
---
  drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 233afea..b547339 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -121,6 +121,12 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
dev_pm_opp *opp)
if (gpu_freq == gmu->gpu_freqs[perf_index])
break;
  
+	if (!gmu->legacy) {

+   a6xx_hfi_set_freq(gmu, gmu->current_perf_index);
+   icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+   return;
+   }
+
gmu->current_perf_index = perf_index;
gmu->freq = gmu->gpu_freqs[perf_index];
  
@@ -893,10 +899,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)

enable_irq(gmu->hfi_irq);
  
  	/* Set the GPU to the current freq */

-   if (gmu->legacy)
-   a6xx_gmu_set_initial_freq(gpu, gmu);
-   else
-   a6xx_hfi_set_freq(gmu, gmu->current_perf_index);
+   a6xx_gmu_set_initial_freq(gpu, gmu);
  
  	/*

 * "enable" the GX power domain which won't actually do anything but it


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

Re: [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline

[Jian-Hong Pan]

Hi Maxime,

Thanks for your version 4 patch again.
I took the patches and applied them upon next-20200708.

I make system cold reboot to multi-user target and the text console shows on the
screen. Then, I simply hot re-plug the HDMI cable on HDMI0 port, I not only lose
the text console on the screen (the display shows blank, backlight is off), but
also kernel does not probe modes for the HDMI connector again.

But HDMI1 does probe modes again for hot re-plugging. So, HDMI1 does not hit the
issue like HDMI0.

* System probes modes only once for HDMI0 port (HDMI-A-1), even hot re-plug HDMI
  cable to the same port:

[   15.611072] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:32:HDMI-A-1] probed modes :
[   15.611079] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[   15.611085] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
...
[   15.611298] [drm:drm_mode_debug_printmodeline] Modeline "720x400": 70 28320 
720 738 846 900 400 412 414 449 0x40 0x6
[   15.611303] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:38:HDMI-A-2]
[   15.612184] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:38:HDMI-A-2] disconnected
[   15.612191] [drm:drm_client_modeset_probe] connector 32 enabled? yes
[   15.612194] [drm:drm_client_modeset_probe] connector 38 enabled? no
[   15.612206] [drm:drm_client_modeset_probe] Not using firmware configuration
[   15.612213] [drm:drm_client_modeset_probe] looking for cmdline mode on 
connector 32
[   15.612218] [drm:drm_client_modeset_probe] looking for preferred mode on 
connector 32 0
[   15.612221] [drm:drm_client_modeset_probe] found mode 1920x1080
...
[  108.263384] [drm:output_poll_execute] [CONNECTOR:32:HDMI-A-1] status updated 
from disconnected to connected
[  108.264307] vc4-drm gpu: [drm:drm_fb_helper_hotplug_event.part.0] 
[  108.264312] [drm:drm_client_modeset_probe] 
[  108.264321] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:32:HDMI-A-1]
[  109.303379] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:38:HDMI-A-2]
[  109.304258] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:38:HDMI-A-2] disconnected
[  109.304266] [drm:drm_client_modeset_probe] No connectors reported connected 
with modes

* System probes modes again for HDMI1 port (HDMI-A-2), whenever hot re-plug the
  HDMI cable:

[  797.974649] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:38:HDMI-A-2] probed modes :
[  797.974656] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[  797.974662] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
...
[  797.974874] [drm:drm_mode_debug_printmodeline] Modeline "720x400": 70 28320 
720 738 846 900 400 412 414 449 0x40 0x6
[  797.974880] [drm:drm_client_modeset_probe] connector 32 enabled? no
[  797.974883] [drm:drm_client_modeset_probe] connector 38 enabled? yes
[  797.974895] [drm:drm_client_modeset_probe] Not using firmware configuration
[  797.974901] [drm:drm_client_modeset_probe] looking for cmdline mode on 
connector 38
[  797.974905] [drm:drm_client_modeset_probe] looking for preferred mode on 
connector 38 0
[  797.974908] [drm:drm_client_modeset_probe] found mode 1920x1080
...
[  852.242615] vc4-drm gpu: [drm:drm_client_dev_hotplug] fbdev: ret=0
[  873.718277] [drm:output_poll_execute] [CONNECTOR:38:HDMI-A-2] status updated 
from disconnected to connected
[  873.718332] vc4-drm gpu: [drm:drm_fb_helper_hotplug_event.part.0] 
[  873.718338] [drm:drm_client_modeset_probe]
...
[  874.264013] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:38:HDMI-A-2] probed modes :
[  874.264020] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[  874.264026] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
...
[  874.264239] [drm:drm_mode_debug_printmodeline] Modeline "720x400": 70 28320 
720 738 846 900 400 412 414 449 0x40 0x6
[  874.264244] [drm:drm_client_modeset_probe] connector 32 enabled? no
[  874.264247] [drm:drm_client_modeset_probe] connector 38 enabled? yes
[  874.264259] [drm:drm_client_modeset_probe] Not using firmware configuration
[  874.264264] [drm:drm_client_modeset_probe] looking for cmdline mode on 
connector 38
[  874.264268] [drm:drm_client_modeset_probe] looking for preferred mode on 
connector 38 0
[  874.264272] [drm:drm_client_modeset_probe] found mode 1920x1080

Here is the full dmesg: 
https://gist.github.com/starnight/5ffb86af552fedb9b6e5741d0540a878#file-dmesg-v4-log
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can

[Steev Klimaszewski]

On 7/9/20 10:17 PM, Steev Klimaszewski wrote:


On 7/9/20 10:12 PM, Steev Klimaszewski wrote:


On 7/9/20 9:14 PM, Doug Anderson wrote:

Hi,

On Thu, Jul 9, 2020 at 6:38 PM Doug Anderson  
wrote:

Hi,

On Thu, Jul 9, 2020 at 6:19 PM Steev Klimaszewski 
 wrote:

Hi Doug,

I've been testing 5.8 and linux-next on the Lenovo Yoga C630, and 
with this patch applied, there is really bad banding on the display.


I'm really bad at explaining it, but you can see the differences 
in the following:


24bit (pre-5.8) - https://dev.gentoo.org/~steev/files/image0.jpg

18bit (5.8/linux-next) - 
https://dev.gentoo.org/~steev/files/image1.jpg

Presumably this means that your panel is defined improperly? If the
panel reports that it's a 6 bits per pixel panel but it's actually an
8 bits per pixel panel then you'll run into this problem.

I would have to assume you have a bunch of out of tree patches to
support your hardware since I don't see any device trees in linuxnext
(other than cheza) that use this bridge chip.  Otherwise I could try
to check and confirm that was the problem.

Ah, interesting.  Maybe you have the panel:

boe,nv133fhm-n61

As far as I can tell from the datasheet (I have the similar
boe,nv133fhm-n62) this is a 6bpp panel.  ...but if you feed it 8bpp
the banding goes away!  Maybe the panel itself knows how to dither???
...or maybe the datasheet / edid are wrong and this is actually an
8bpp panel.  Seems unlikely...

In any case, one fix is to pick
, 


though right now that patch is only enabled for sc7180.  Maybe you
could figure out how to apply it to your hardware?

...another fix would be to pretend that your panel is 8bpp even though
it's actually 6bpp.  Ironically if anyone ever tried to configure BPP
from the EDID they'd go back to 6bpp.  You can read the EDID of your
panel with this:

bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
i2cdump ${bus} 0x50 i

When I do that and then decode it on the "boe,nv133fhm-n62" panel, I 
find:


6 bits per primary color channel

-Doug



Hi Doug,

Decoding it does show be to boe,nv133fhm-n61 - and yeah it does say 
it's 6-bit according to panelook's specs for it.



I derped again...

root@c630:~# bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
root@c630:~# i2cdump ${bus} 0x50 i > edid
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-16, address 0x50, mode i2c block
Continue? [Y/n]
root@c630:~# edid-decode edid
edid-decode (hex):

00 ff ff ff ff ff ff 00 09 e5 d1 07 00 00 00 00
01 1c 01 04 a5 1d 11 78 0a 1d b0 a6 58 54 9e 26
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 c0 39 80 18 71 38 28 40 30 20
36 00 26 a5 10 00 00 1a 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 1a 00 00 00 fe 00 42
4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe
00 4e 56 31 33 33 46 48 4d 2d 4e 36 31 0a 00 9a

03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb
fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73
44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61
92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2
66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70
43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc
45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3
30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29



EDID version: 1.4
Manufacturer: BOE Model 2001 Serial Number 0
Made in week 1 of 2018
Digital display
8 bits per primary color channel
DisplayPort interface
Maximum image size: 29 cm x 17 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:4:4
First detailed timing includes the native pixel format and preferred 
refresh rate

Color Characteristics
  Red:   0.6484, 0.3447
  Green: 0.3310, 0.6181
  Blue:  0.1503, 0.0615
  White: 0.3125, 0.3281
Established Timings I & II: none
Standard Timings: none
Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm
   1920 1968 2000 2200 ( 48  32 200)
   1080 1083 1089 1120 (  3   6  31)
   +hsync -vsync
   VertFreq: 60.000 Hz, HorFreq: 67.200 kHz
Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 1a  

Alphanumeric Data String: BOE CQ
Alphanumeric Data String: NV133FHM-N61
Checksum: 0x9a



Unknown EDID Extension Block 0x03
  03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb .&.w...qo...C.j.
  fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73  ... 9."nehwp..4s
  44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61 D!...m.b.*|...ja
  92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2 ...SL9...#.H.9..
  66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70 f.p..w.J..Lrn]Gp
  43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc C..x..A..j(.
  45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3 E*..5.4.>.^.
  30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29 0^.).H.1..;)
Checksum: 0x29 (should be 0x82)


- My edid does in fact say it's 8bit

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon]

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

--- Comment #55 from Stratos Zolotas (str...@gmail.com) ---
(In reply to Paul Menzel from comment #54)

> Thank you for your report. How quickly can you reproduce it? If you could
> bisect the issue to pinpoint the culprit commit between 5.7.5 and 5.7.7,
> that’d be great. Maybe open even a separate bug report, in case they are
> unrelated. They can always be marked as duplicates later.

If you guide me on what to do I can report back in some hours (not on that
system now). I had 4 crashes yesterday with kernel 5.7.7 in 3 hours doing daily
stuff (not gaming or something like that). System was unresponsive, ssh to the
box worked but reboot from console hangs also, only ALT+SysRq+B reboots the
system. I booted with the previous kernel (5.7.5) and was stable for over 6-7
hours.

-- 
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 2/4] drm/etnaviv: add loadavg accounting

[Lucas Stach]

Hi Christian,

Am Freitag, den 10.07.2020, 09:41 +0200 schrieb Christian Gmeiner:
> The GPU has an idle state register where each bit represents the idle
> state of a sub-GPU component like FE or TX. Sample this register
> every 10ms and calculate a simple moving average over the sub-GPU
> component idle states with a total observation time frame of 1s.
> 
> This provides us with a percentage based load of each sub-GPU
> component.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c | 14 
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 32 +++
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 29 
>  3 files changed, 75 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index f9afe11c50f0..b31920241c86 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -46,6 +46,19 @@ static void load_gpu(struct drm_device *dev)
>   }
>  }
>  
> +static void unload_gpu(struct drm_device *dev)
> +{
> + struct etnaviv_drm_private *priv = dev->dev_private;
> + unsigned int i;
> +
> + for (i = 0; i < ETNA_MAX_PIPES; i++) {
> + struct etnaviv_gpu *g = priv->gpu[i];
> +
> + if (g)
> + etnaviv_gpu_shutdown(g);
> + }
> +}
> +
>  static int etnaviv_open(struct drm_device *dev, struct drm_file *file)
>  {
>   struct etnaviv_drm_private *priv = dev->dev_private;
> @@ -581,6 +594,7 @@ static void etnaviv_unbind(struct device *dev)
>   struct drm_device *drm = dev_get_drvdata(dev);
>   struct etnaviv_drm_private *priv = drm->dev_private;
>  
> + unload_gpu(drm);
>   drm_dev_unregister(drm);
>  
>   component_unbind_all(dev, drm);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index a31eeff2b297..1f0eb7e00657 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -714,6 +714,28 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
>   gpu_write(gpu, VIVS_HI_INTR_ENBL, ~0U);
>  }
>  
> +static void etnaviv_loadavg_function(struct timer_list *t)
> +{
> + struct etnaviv_gpu *gpu = from_timer(gpu, t, loadavg_timer);
> + const u32 idle = gpu_read(gpu, VIVS_HI_IDLE_STATE);

This isn't guaranteed to work on a clock/power gated GPU. Also we
surely don't want to wake a idle system every 10ms just to sample a "no
load" value, so this needs some integration with runtime PM, to disable
the sampling when the GPU is powered down and enable when powered up.
The loadavg must be able to adapt to jumps in the sampling interval
while idle.

> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(etna_idle_module_names); i++)
> + if ((idle & etna_idle_module_names[i].bit))
> + sma_loadavg_add(&gpu->loadavg_value[i], 0);
> + else
> + sma_loadavg_add(&gpu->loadavg_value[i], 100);
> +
> + spin_lock_bh(&gpu->loadavg_spinlock);
> +
> + for (i = 0; i < ARRAY_SIZE(etna_idle_module_names); i++)
> + gpu->loadavg_percentage[i] = 
> sma_loadavg_read(&gpu->loadavg_value[i]);
> +
> + spin_unlock_bh(&gpu->loadavg_spinlock);
> +
> + mod_timer(t, jiffies + msecs_to_jiffies(10));

A jiffies based timer is much too coarse for a regular 10ms sampling.
On a typical 100Hz system 10ms is a single jiffy, so your timer will
fire anywhere in the range of ~0ms...~20ms. This won't get us a usable
measurement.

Regards,
Lucas

> +}
> +
>  int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
>  {
>   struct etnaviv_drm_private *priv = gpu->drm->dev_private;
> @@ -804,6 +826,10 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
>   for (i = 0; i < ARRAY_SIZE(gpu->event); i++)
>   complete(&gpu->event_free);
>  
> + /* Setup loadavg timer */
> + timer_setup(&gpu->loadavg_timer, etnaviv_loadavg_function, 0);
> + mod_timer(&gpu->loadavg_timer, jiffies + msecs_to_jiffies(10));
> +
>   /* Now program the hardware */
>   mutex_lock(&gpu->lock);
>   etnaviv_gpu_hw_init(gpu);
> @@ -824,6 +850,11 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
>   return ret;
>  }
>  
> +void etnaviv_gpu_shutdown(struct etnaviv_gpu *gpu)
> +{
> + del_timer(&gpu->loadavg_timer);
> +}
> +
>  #ifdef CONFIG_DEBUG_FS
>  struct dma_debug {
>   u32 address[2];
> @@ -1762,6 +1793,7 @@ static int etnaviv_gpu_platform_probe(struct 
> platform_device *pdev)
>   gpu->dev = &pdev->dev;
>   mutex_init(&gpu->lock);
>   mutex_init(&gpu->fence_lock);
> + spin_lock_init(&gpu->loadavg_spinlock);
>  
>   /* Map registers: */
>   gpu->mmio = devm_platform_ioremap_resource(pdev, 0);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index 8ea48697d132..a5b9c89c6744 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers

Re: [PATCH 0/4] Add support for GPU load values

[Lucas Stach]

Hi Christian,

Am Freitag, den 10.07.2020, 09:41 +0200 schrieb Christian Gmeiner:
> This patch series add support for loadavg values for GPU
> sub-components. I am adding a SMA algorithm as I was not
> really sure if EWMA would be a good fit for this use case.

1 second is a pretty long window in GPU time. Why do you feel that a
simple moving average is more appropriate than a exponentially
weighted one here? Note that I haven't given this any thought myself
and haven't made up my mind yet, so this is a honest question to
understand the reasoning behind your choice.

Regards,
Lucas

> Christian Gmeiner (4):
>   drm/etnaviv: add simple moving average (SMA)
>   drm/etnaviv: add loadavg accounting
>   drm/etnaviv: show loadavg in debugfs
>   drm/etnaviv: export loadavg via perfmon
> 
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c | 14 
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 44 -
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 29 +
>  drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 79 +++
>  drivers/gpu/drm/etnaviv/etnaviv_sma.h | 53 +++
>  5 files changed, 218 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_sma.h
> 

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

[PATCH][next] drm/amdgpu: fix spelling mistake "Falied" -> "Failed"

[Colin King]

From: Colin Ian King 

There is a spelling mistake in a DRM_ERROR error message. Fix it.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index e20695b44dbe..40706334f7a8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -1984,7 +1984,7 @@ static int psp_suspend(void *handle)
 
ret = psp_tmr_terminate(psp);
if (ret) {
-   DRM_ERROR("Falied to terminate tmr\n");
+   DRM_ERROR("Failed to terminate tmr\n");
return ret;
}
 
-- 
2.27.0

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

Re: [PATCH 0/4] Add support for GPU load values

[Christian Gmeiner]

Hoi Lucas

Am Fr., 10. Juli 2020 um 10:31 Uhr schrieb Lucas Stach :
>
> Hi Christian,
>
> Am Freitag, den 10.07.2020, 09:41 +0200 schrieb Christian Gmeiner:
> > This patch series add support for loadavg values for GPU
> > sub-components. I am adding a SMA algorithm as I was not
> > really sure if EWMA would be a good fit for this use case.
>
> 1 second is a pretty long window in GPU time. Why do you feel that a
> simple moving average is more appropriate than a exponentially
> weighted one here? Note that I haven't given this any thought myself
> and haven't made up my mind yet, so this is a honest question to
> understand the reasoning behind your choice.
>

I played with both variants but I 'feel' that SMA might be a better
fit. To be honest I
have no background in signal processing and stuff like this so.. I
will go the route you
guide me to :) I have kept the "interface" for SMA equal to the one EWMA uses
so I can easily switch between them.

-- 
greets
--
Christian Gmeiner, MSc

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

Re: [PATCH 2/4] drm/etnaviv: add loadavg accounting

[Christian Gmeiner]

Hoi Lucas,

Am Fr., 10. Juli 2020 um 10:19 Uhr schrieb Lucas Stach :
>
> Hi Christian,
>
> Am Freitag, den 10.07.2020, 09:41 +0200 schrieb Christian Gmeiner:
> > The GPU has an idle state register where each bit represents the idle
> > state of a sub-GPU component like FE or TX. Sample this register
> > every 10ms and calculate a simple moving average over the sub-GPU
> > component idle states with a total observation time frame of 1s.
> >
> > This provides us with a percentage based load of each sub-GPU
> > component.
> >
> > Signed-off-by: Christian Gmeiner 
> > ---
> >  drivers/gpu/drm/etnaviv/etnaviv_drv.c | 14 
> >  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 32 +++
> >  drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 29 
> >  3 files changed, 75 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
> > b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > index f9afe11c50f0..b31920241c86 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > @@ -46,6 +46,19 @@ static void load_gpu(struct drm_device *dev)
> >   }
> >  }
> >
> > +static void unload_gpu(struct drm_device *dev)
> > +{
> > + struct etnaviv_drm_private *priv = dev->dev_private;
> > + unsigned int i;
> > +
> > + for (i = 0; i < ETNA_MAX_PIPES; i++) {
> > + struct etnaviv_gpu *g = priv->gpu[i];
> > +
> > + if (g)
> > + etnaviv_gpu_shutdown(g);
> > + }
> > +}
> > +
> >  static int etnaviv_open(struct drm_device *dev, struct drm_file *file)
> >  {
> >   struct etnaviv_drm_private *priv = dev->dev_private;
> > @@ -581,6 +594,7 @@ static void etnaviv_unbind(struct device *dev)
> >   struct drm_device *drm = dev_get_drvdata(dev);
> >   struct etnaviv_drm_private *priv = drm->dev_private;
> >
> > + unload_gpu(drm);
> >   drm_dev_unregister(drm);
> >
> >   component_unbind_all(dev, drm);
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> > b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> > index a31eeff2b297..1f0eb7e00657 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> > @@ -714,6 +714,28 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu 
> > *gpu)
> >   gpu_write(gpu, VIVS_HI_INTR_ENBL, ~0U);
> >  }
> >
> > +static void etnaviv_loadavg_function(struct timer_list *t)
> > +{
> > + struct etnaviv_gpu *gpu = from_timer(gpu, t, loadavg_timer);
> > + const u32 idle = gpu_read(gpu, VIVS_HI_IDLE_STATE);
>
> This isn't guaranteed to work on a clock/power gated GPU. Also we
> surely don't want to wake a idle system every 10ms just to sample a "no
> load" value, so this needs some integration with runtime PM, to disable
> the sampling when the GPU is powered down and enable when powered up.
> The loadavg must be able to adapt to jumps in the sampling interval
> while idle.
>

Oh yea.. runtime PM.. I thought I was missing something. Will tackle this in the
next version.

>
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(etna_idle_module_names); i++)
> > + if ((idle & etna_idle_module_names[i].bit))
> > + sma_loadavg_add(&gpu->loadavg_value[i], 0);
> > + else
> > + sma_loadavg_add(&gpu->loadavg_value[i], 100);
> > +
> > + spin_lock_bh(&gpu->loadavg_spinlock);
> > +
> > + for (i = 0; i < ARRAY_SIZE(etna_idle_module_names); i++)
> > + gpu->loadavg_percentage[i] = 
> > sma_loadavg_read(&gpu->loadavg_value[i]);
> > +
> > + spin_unlock_bh(&gpu->loadavg_spinlock);
> > +
> > + mod_timer(t, jiffies + msecs_to_jiffies(10));
>
> A jiffies based timer is much too coarse for a regular 10ms sampling.
> On a typical 100Hz system 10ms is a single jiffy, so your timer will
> fire anywhere in the range of ~0ms...~20ms. This won't get us a usable
> measurement.
>

Makes sense.. will switch to hrtimers.

-- 
greets
--
Christian Gmeiner, MSc

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

Re: [PATCH v3 07/14] drm/panfrost: rename error labels in device_init

[Steven Price]

On 09/07/2020 15:03, Clément Péron wrote:

Rename goto labels in device_init it will be easier to maintain.

Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 


Nice clean up, thanks. As you noted this needs rebasing as the 
"regulator init" message has gone.


Reviewed-by: Steven Price 


---
  drivers/gpu/drm/panfrost/panfrost_device.c | 30 +++---
  1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 8136babd3ba9..cc16d102b275 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -215,57 +215,57 @@ int panfrost_device_init(struct panfrost_device *pfdev)
err = panfrost_regulator_init(pfdev);
if (err) {
dev_err(pfdev->dev, "regulator init failed %d\n", err);
-   goto err_out0;
+   goto out_clk;
}
  
  	err = panfrost_reset_init(pfdev);

if (err) {
dev_err(pfdev->dev, "reset init failed %d\n", err);
-   goto err_out1;
+   goto out_regulator;
}
  
  	err = panfrost_pm_domain_init(pfdev);

if (err)
-   goto err_out2;
+   goto out_reset;
  
  	res = platform_get_resource(pfdev->pdev, IORESOURCE_MEM, 0);

pfdev->iomem = devm_ioremap_resource(pfdev->dev, res);
if (IS_ERR(pfdev->iomem)) {
dev_err(pfdev->dev, "failed to ioremap iomem\n");
err = PTR_ERR(pfdev->iomem);
-   goto err_out3;
+   goto out_pm_domain;
}
  
  	err = panfrost_gpu_init(pfdev);

if (err)
-   goto err_out3;
+   goto out_pm_domain;
  
  	err = panfrost_mmu_init(pfdev);

if (err)
-   goto err_out4;
+   goto out_gpu;
  
  	err = panfrost_job_init(pfdev);

if (err)
-   goto err_out5;
+   goto out_mmu;
  
  	err = panfrost_perfcnt_init(pfdev);

if (err)
-   goto err_out6;
+   goto out_job;
  
  	return 0;

-err_out6:
+out_job:
panfrost_job_fini(pfdev);
-err_out5:
+out_mmu:
panfrost_mmu_fini(pfdev);
-err_out4:
+out_gpu:
panfrost_gpu_fini(pfdev);
-err_out3:
+out_pm_domain:
panfrost_pm_domain_fini(pfdev);
-err_out2:
+out_reset:
panfrost_reset_fini(pfdev);
-err_out1:
+out_regulator:
panfrost_regulator_fini(pfdev);
-err_out0:
+out_clk:
panfrost_clk_fini(pfdev);
return err;
  }



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

Re: [PATCH v3 08/14] drm/panfrost: move devfreq_init()/fini() in device

[Steven Price]

On 09/07/2020 15:03, Clément Péron wrote:

Later we will introduce devfreq probing regulator if they
are present. As regulator should be probe only one time we
need to get this logic in the device_init().

panfrost_device is already taking care of devfreq_resume()
and devfreq_suspend(), so it's not totally illogic to move
the devfreq_init() and devfreq_fini() here.

Reviewed-by: Alyssa Rosenzweig 
Signed-off-by: Clément Péron 


Reviewed-by: Steven Price 


---
  drivers/gpu/drm/panfrost/panfrost_device.c | 12 +++-
  drivers/gpu/drm/panfrost/panfrost_drv.c| 15 ++-
  2 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
b/drivers/gpu/drm/panfrost/panfrost_device.c
index cc16d102b275..464da1646398 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -212,10 +212,17 @@ int panfrost_device_init(struct panfrost_device *pfdev)
return err;
}
  
+	err = panfrost_devfreq_init(pfdev);

+   if (err) {
+   if (err != -EPROBE_DEFER)
+   dev_err(pfdev->dev, "devfreq init failed %d\n", err);
+   goto out_clk;
+   }
+
err = panfrost_regulator_init(pfdev);
if (err) {
dev_err(pfdev->dev, "regulator init failed %d\n", err);
-   goto out_clk;
+   goto out_devfreq;
}
  
  	err = panfrost_reset_init(pfdev);

@@ -265,6 +272,8 @@ int panfrost_device_init(struct panfrost_device *pfdev)
panfrost_reset_fini(pfdev);
  out_regulator:
panfrost_regulator_fini(pfdev);
+out_devfreq:
+   panfrost_devfreq_fini(pfdev);
  out_clk:
panfrost_clk_fini(pfdev);
return err;
@@ -278,6 +287,7 @@ void panfrost_device_fini(struct panfrost_device *pfdev)
panfrost_gpu_fini(pfdev);
panfrost_pm_domain_fini(pfdev);
panfrost_reset_fini(pfdev);
+   panfrost_devfreq_fini(pfdev);
panfrost_regulator_fini(pfdev);
panfrost_clk_fini(pfdev);
  }
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 882fecc33fdb..4dda68689015 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -14,7 +14,6 @@
  #include 
  
  #include "panfrost_device.h"

-#include "panfrost_devfreq.h"
  #include "panfrost_gem.h"
  #include "panfrost_mmu.h"
  #include "panfrost_job.h"
@@ -606,13 +605,6 @@ static int panfrost_probe(struct platform_device *pdev)
goto err_out0;
}
  
-	err = panfrost_devfreq_init(pfdev);

-   if (err) {
-   if (err != -EPROBE_DEFER)
-   dev_err(&pdev->dev, "Fatal error during devfreq 
init\n");
-   goto err_out1;
-   }
-
pm_runtime_set_active(pfdev->dev);
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_enable(pfdev->dev);
@@ -625,16 +617,14 @@ static int panfrost_probe(struct platform_device *pdev)
 */
err = drm_dev_register(ddev, 0);
if (err < 0)
-   goto err_out2;
+   goto err_out1;
  
  	panfrost_gem_shrinker_init(ddev);
  
  	return 0;
  
-err_out2:

-   pm_runtime_disable(pfdev->dev);
-   panfrost_devfreq_fini(pfdev);
  err_out1:
+   pm_runtime_disable(pfdev->dev);
panfrost_device_fini(pfdev);
  err_out0:
drm_dev_put(ddev);
@@ -650,7 +640,6 @@ static int panfrost_remove(struct platform_device *pdev)
panfrost_gem_shrinker_cleanup(ddev);
  
  	pm_runtime_get_sync(pfdev->dev);

-   panfrost_devfreq_fini(pfdev);
panfrost_device_fini(pfdev);
pm_runtime_put_sync_suspend(pfdev->dev);
pm_runtime_disable(pfdev->dev);



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

Re: [PATCH] drm/bridge/synopsys: dsi: add support for non-continuous HS clock

[Philippe CORNU]

On 7/1/20 9:42 PM, Yannick Fertre wrote:
> From: Antonio Borneo 
> 
> Current code enables the HS clock when video mode is started or to
> send out a HS command, and disables the HS clock to send out a LP
> command. This is not what DSI spec specify.
> 
> Enable HS clock either in command and in video mode.
> Set automatic HS clock management for panels and devices that
> support non-continuous HS clock.
> 
> Signed-off-by: Antonio Borneo 
> ---
>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 9 +++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index d580b2aa4ce9..979acaa90d00 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -365,7 +365,6 @@ static void dw_mipi_message_config(struct dw_mipi_dsi 
> *dsi,
>   if (lpm)
>   val |= CMD_MODE_ALL_LP;
>   
> - dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
>   dsi_write(dsi, DSI_CMD_MODE_CFG, val);
>   }
>   
> @@ -541,16 +540,22 @@ static void dw_mipi_dsi_video_mode_config(struct 
> dw_mipi_dsi *dsi)
>   static void dw_mipi_dsi_set_mode(struct dw_mipi_dsi *dsi,
>unsigned long mode_flags)
>   {
> + u32 val;
> +
>   dsi_write(dsi, DSI_PWR_UP, RESET);
>   
>   if (mode_flags & MIPI_DSI_MODE_VIDEO) {
>   dsi_write(dsi, DSI_MODE_CFG, ENABLE_VIDEO_MODE);
>   dw_mipi_dsi_video_mode_config(dsi);
> - dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);
>   } else {
>   dsi_write(dsi, DSI_MODE_CFG, ENABLE_CMD_MODE);
>   }
>   
> + val = PHY_TXREQUESTCLKHS;
> + if (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)
> + val |= AUTO_CLKLANE_CTRL;
> + dsi_write(dsi, DSI_LPCLK_CTRL, val);
> +
>   dsi_write(dsi, DSI_PWR_UP, POWERUP);
>   }
>   
> 

(+ Antonio)

Hi Yannick & Antonio,

Reviewed-by: Philippe Cornu 
Tested-by: Philippe Cornu 

(Tested with the 3 patches named
drm/bridge/synopsys: dsi: allow LP commands in video mode
drm/bridge/synopsys: dsi: allow sending longer LP commands
drm/bridge/synopsys: dsi: add support for non-continuous HS clock
on various dsi bridges + stm32mp157 disco board)

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

Re: [PATCH] drm/vc4/vc4_hdmi: fill ASoC card owner

[Stefan Wahren]

Hi Marek,

Am 02.07.20 um 08:58 schrieb Marek Szyprowski:
> On 01.07.2020 20:49, Stefan Wahren wrote:
>> Am 01.07.20 um 09:39 schrieb Marek Szyprowski:
>>> card->owner is a required property and since commit 81033c6b584b ("ALSA:
>>> core: Warn on empty module") a warning is issued if it is empty. Fix lack
>>> of it. This fixes following warning observed on RaspberryPi 3B board
>>> with ARM 32bit kernel and multi_v7_defconfig:
>>>
>>> [ cut here ]
>>> WARNING: CPU: 1 PID: 210 at sound/core/init.c:207 snd_card_new+0x378/0x398 
>>> [snd]
>>> Modules linked in: vc4(+) snd_soc_core ac97_bus snd_pcm_dmaengine bluetooth 
>>> snd_pcm snd_timer crc32_arm_ce raspberrypi_hwmon snd soundcore ecdh_generic 
>>> ecc bcm2835_thermal phy_generic
>>> CPU: 1 PID: 210 Comm: systemd-udevd Not tainted 
>>> 5.8.0-rc1-00027-g81033c6b584b #1087
>>> Hardware name: BCM2835
>>> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>>> [] (show_stack) from [] (dump_stack+0xd4/0xe8)
>>> [] (dump_stack) from [] (__warn+0xdc/0xf4)
>>> [] (__warn) from [] (warn_slowpath_fmt+0xb0/0xb8)
>>> [] (warn_slowpath_fmt) from [] 
>>> (snd_card_new+0x378/0x398 [snd])
>>> [] (snd_card_new [snd]) from [] 
>>> (snd_soc_bind_card+0x280/0x99c [snd_soc_core])
>>> [] (snd_soc_bind_card [snd_soc_core]) from [] 
>>> (devm_snd_soc_register_card+0x34/0x6c [snd_soc_core])
>>> [] (devm_snd_soc_register_card [snd_soc_core]) from [] 
>>> (vc4_hdmi_bind+0x43c/0x5f4 [vc4])
>>> [] (vc4_hdmi_bind [vc4]) from [] 
>>> (component_bind_all+0xec/0x24c)
>>> [] (component_bind_all) from [] 
>>> (vc4_drm_bind+0xd4/0x174 [vc4])
>>> [] (vc4_drm_bind [vc4]) from [] 
>>> (try_to_bring_up_master+0x160/0x1b0)
>>> [] (try_to_bring_up_master) from [] 
>>> (component_master_add_with_match+0xd0/0x104)
>>> [] (component_master_add_with_match) from [] 
>>> (vc4_platform_drm_probe+0x9c/0xbc [vc4])
>>> [] (vc4_platform_drm_probe [vc4]) from [] 
>>> (platform_drv_probe+0x6c/0xa4)
>>> [] (platform_drv_probe) from [] 
>>> (really_probe+0x210/0x350)
>>> [] (really_probe) from [] 
>>> (driver_probe_device+0x5c/0xb4)
>>> [] (driver_probe_device) from [] 
>>> (device_driver_attach+0x58/0x60)
>>> [] (device_driver_attach) from [] 
>>> (__driver_attach+0x80/0xbc)
>>> [] (__driver_attach) from [] 
>>> (bus_for_each_dev+0x68/0xb4)
>>> [] (bus_for_each_dev) from [] 
>>> (bus_add_driver+0x130/0x1e8)
>>> [] (bus_add_driver) from [] (driver_register+0x78/0x110)
>>> [] (driver_register) from [] 
>>> (do_one_initcall+0x50/0x220)
>>> [] (do_one_initcall) from [] (do_init_module+0x60/0x210)
>>> [] (do_init_module) from [] (load_module+0x1e34/0x2338)
>>> [] (load_module) from [] (sys_finit_module+0xac/0xbc)
>>> [] (sys_finit_module) from [] 
>>> (ret_fast_syscall+0x0/0x54)
>>> Exception stack(0xeded9fa8 to 0xeded9ff0)
>>> ...
>>> ---[ end trace 6414689569c2bc08 ]---
>>>
>>> Suggested-by: Takashi Iwai 
>>> Signed-off-by: Marek Szyprowski 
Tested-by: Stefan Wahren 
>> thanks for this patch. Any chance for a fixes tag here?
> Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support")
Thanks
>
> Best regards
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge/synopsys: dsi: allow sending longer LP commands

[Philippe CORNU]

On 7/1/20 4:31 PM, Yannick Fertre wrote:
> From: Antonio Borneo 
> 
> Current code does not properly computes the max length of LP
> commands that can be send during H or V sync, and rely on static
> values.
> Limiting the max LP length to 4 byte during the V-sync is overly
> conservative.
> 
> Relax the limit and allows longer LP commands (16 bytes) to be
> sent during V-sync.
> 
> Signed-off-by: Antonio Borneo 
> ---
>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 17 +
>   1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index d580b2aa4ce9..1a24ea648ef8 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -360,6 +360,15 @@ static void dw_mipi_message_config(struct dw_mipi_dsi 
> *dsi,
>   bool lpm = msg->flags & MIPI_DSI_MSG_USE_LPM;
>   u32 val = 0;
>   
> + /*
> +  * TODO dw drv improvements
> +  * largest packet sizes during hfp or during vsa/vpb/vfp
> +  * should be computed according to byte lane, lane number and only
> +  * if sending lp cmds in high speed is enable (PHY_TXREQUESTCLKHS)
> +  */
> + dsi_write(dsi, DSI_DPI_LP_CMD_TIM, OUTVACT_LPCMD_TIME(16)
> +   | INVACT_LPCMD_TIME(4));
> +
>   if (msg->flags & MIPI_DSI_MSG_REQ_ACK)
>   val |= ACK_RQST_EN;
>   if (lpm)
> @@ -611,14 +620,6 @@ static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi 
> *dsi,
>   dsi_write(dsi, DSI_DPI_VCID, DPI_VCID(dsi->channel));
>   dsi_write(dsi, DSI_DPI_COLOR_CODING, color);
>   dsi_write(dsi, DSI_DPI_CFG_POL, val);
> - /*
> -  * TODO dw drv improvements
> -  * largest packet sizes during hfp or during vsa/vpb/vfp
> -  * should be computed according to byte lane, lane number and only
> -  * if sending lp cmds in high speed is enable (PHY_TXREQUESTCLKHS)
> -  */
> - dsi_write(dsi, DSI_DPI_LP_CMD_TIM, OUTVACT_LPCMD_TIME(4)
> -   | INVACT_LPCMD_TIME(4));
>   }
>   
>   static void dw_mipi_dsi_packet_handler_config(struct dw_mipi_dsi *dsi)
> 

(+ Antonio)

Hi Yannick & Antonio,

Reviewed-by: Philippe Cornu 
Tested-by: Philippe Cornu 

(Tested with the 3 patches named
drm/bridge/synopsys: dsi: allow LP commands in video mode
drm/bridge/synopsys: dsi: allow sending longer LP commands
drm/bridge/synopsys: dsi: add support for non-continuous HS clock
on various dsi bridges + stm32mp157 disco board)

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

Re: [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline

[Stefan Wahren]

Hi Maxime,

Am 08.07.20 um 19:41 schrieb Maxime Ripard:
> Hi everyone,
>
> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
>
> The main differences are that there's two HDMI controllers and that there's
> more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
> have only 3 FIFOs. Both of those differences are breaking a bunch of
> expectations in the driver, so we first need a good bunch of cleanup and
> reworks to introduce support for the new controllers.
>
> Similarly, the HDMI controller has all its registers shuffled and split in
> multiple controllers now, so we need a bunch of changes to support this as
> well.
>
> Only the HDMI support is enabled for now (even though the DPI and DSI
> outputs have been tested too).
>
> Let me know if you have any comments
> Maxime
>
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: devicet...@vger.kernel.org
> Cc: Kamal Dasu 
> Cc: linux-...@vger.kernel.org
> Cc: Michael Turquette 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Stephen Boyd 
>
> Changes from v3:
>   - Rebased on top of next-20200708
>   - Added a name to the HDMI audio codec component
>   - Only disable the BCM2711 HDMI pixelvalves at boot
>   - Fixed an error in the HVS binding
>   - Fix a framebuffer size condition that was inverted
>   - Changed the channel allocation algorithm using Eric's suggestion
>   - Always write the muxing values instead of updating if needed
>   - Improved a bit the hvs_available_channels comment in the structure
>   - Change atomic_complete_commit code to use for_each_new_crtc_in_state
>   - Change the muxing code to take into account disparities between the
> BCM2711 and previous SoCs.
>   - Only change the clock rate on BCM2711 during a modeset
>   - Fix a crash at atomic_disable
>   - Use clk_set_min_rate for the core clock too
>   - Add a few defines, and simplify the FIFO level stuff
>   - Reordered the patches according to Eric's reviews
>   - Fixed a regression with VID_CTL setting on RPI3
>
i additionally applied "drm/vc4/vc4_hdmi: fill ASoC card owner" on top
of your series (potential merge conflict).

I didn't see any issues with a RPI 3B or RPI 4B.

So this whole series is

Tested-by: Stefan Wahren 

Regards
Stefan

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

Re: [PATCH v2] drm/bridge/synopsys: dsi: allow LP commands in video mode

[Philippe CORNU]

On 7/8/20 4:08 PM, Yannick Fertre wrote:
> From: Antonio Borneo 
> 
> Current code only sends LP commands in command mode.
> 
> Allows sending LP commands also in video mode by setting the
> proper flag in DSI_VID_MODE_CFG.
> 
> Signed-off-by: Antonio Borneo 
> ---
>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 8 
>   1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 1a24ea648ef8..e9a0f42ff99f 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -89,6 +89,7 @@
>   #define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS 0x1
>   #define VID_MODE_TYPE_BURST 0x2
>   #define VID_MODE_TYPE_MASK  0x3
> +#define ENABLE_LOW_POWER_CMD BIT(15)
>   #define VID_MODE_VPG_ENABLE BIT(16)
>   #define VID_MODE_VPG_HORIZONTAL BIT(24)
>   
> @@ -376,6 +377,13 @@ static void dw_mipi_message_config(struct dw_mipi_dsi 
> *dsi,
>   
>   dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
>   dsi_write(dsi, DSI_CMD_MODE_CFG, val);
> +
> + val = dsi_read(dsi, DSI_VID_MODE_CFG);
> + if (lpm)
> + val |= ENABLE_LOW_POWER_CMD;
> + else
> + val &= ~ENABLE_LOW_POWER_CMD;
> + dsi_write(dsi, DSI_VID_MODE_CFG, val);
>   }
>   
>   static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 
> hdr_val)
> 

(+ Antonio)

Hi Yannick & Antonio,

Reviewed-by: Philippe Cornu 
Tested-by: Philippe Cornu 

(Tested with the 3 patches named
drm/bridge/synopsys: dsi: allow LP commands in video mode
drm/bridge/synopsys: dsi: allow sending longer LP commands
drm/bridge/synopsys: dsi: add support for non-continuous HS clock
on various dsi bridges + stm32mp157 disco board)

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

Re: [PATCH] efi: avoid error message when booting under Xen

[Bartlomiej Zolnierkiewicz]

[ added EFI Maintainer & ML to Cc: ]

Hi,

On 7/9/20 11:17 AM, Jürgen Groß wrote:
> On 28.06.20 10:50, Jürgen Groß wrote:
>> Ping?
>>
>> On 10.06.20 16:10, Juergen Gross wrote:
>>> efifb_probe() will issue an error message in case the kernel is booted
>>> as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
>>> that message by calling efi_mem_desc_lookup() only if EFI_PARAVIRT
>>> isn't set.
>>>
>>> Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when 
>>> mapping the FB")
>>> Signed-off-by: Juergen Gross 
>>> ---
>>>   drivers/video/fbdev/efifb.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
>>> index 65491ae74808..f5eccd1373e9 100644
>>> --- a/drivers/video/fbdev/efifb.c
>>> +++ b/drivers/video/fbdev/efifb.c
>>> @@ -453,7 +453,7 @@ static int efifb_probe(struct platform_device *dev)
>>>   info->apertures->ranges[0].base = efifb_fix.smem_start;
>>>   info->apertures->ranges[0].size = size_remap;
>>> -    if (efi_enabled(EFI_BOOT) &&
>>> +    if (efi_enabled(EFI_BOOT) && !efi_enabled(EFI_PARAVIRT) &&
>>>   !efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
>>>   if ((efifb_fix.smem_start + efifb_fix.smem_len) >
>>>   (md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) {
>>>
>>
> 
> In case I see no reaction from the maintainer for another week I'll take
> this patch through the Xen tree.

From fbdev POV this change looks fine to me and I'm OK with merging it
through Xen or EFI tree:

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KASAN: use-after-free Read in drm_gem_object_release

[Greg KH]

On Fri, Jul 10, 2020 at 04:24:03PM +0800, butt3rflyh4ck wrote:
> I report a bug (in linux-5.8.0-rc4) found by syzkaller.

Great!

But can you also submit a fix for this as well?  We are drowning in
syzkaller reports and just throwing them at us doesn't really help
anyone here anymore.

thanks,

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

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon]

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

Duncan (1i5t5.dun...@cox.net) changed:

   What|Removed |Added

 Kernel Version|5.7-rc1 - 5.7 - 5.8-rc1+|5.7-rc1 - 5.7 - 5.8-rc4+

--- Comment #56 from Duncan (1i5t5.dun...@cox.net) ---
Some notes and a question (last * point):

* There seem to be two and it's now looking like three near identical bugs or
variants of the same bug, all with the very similar
amdgpu-dm-atomic-commit-tail/events-unbound-commit-work log trace.  

1) Until now all the reports seemed to start by 5.7.0 and presumably between
5.6.0 and 5.7-rc1, which was when I first saw it.  But now, comment #53 is
reporting an origin with 5.7.6 or 5.7.7 while 5.7.5 was fine.  That's on rx580,
which wikipedia says is polaris20.

2) Of the other two, one is reported fixed (on an rc5700/navi10) by commit
6eb3cf2e0 which we were asked to try above, that made it into 5.8-rc4, while...

3) My older rx460/polaris11, started with a pull shortly before 5.7-rc1 (that
I've been unable to properly bisect to, once for sure and it's looking like
twice, much to my frustration!) and continues all the way thru today's almost
5.8-rc5 -- the 6eb commit didn't help.

Seems the vega/navi graphics either started later (your 5.7.5 good, 5.7.7 bad)
or are fixed by 6eb, while my older polaris, started earlier and isn't fixed by
6eb.

BTW Stratos, that 6eb commit appears to be in the fresh 5.7.8 as well.  Seeing
if the bug is still there would thus be interesting.

* Chris mentioned variable-refresh-rate/VRR in comment #49.  He was wondering
if turning it OFF helped him as he had done so when migrating cards and hadn't
seen the problem on his rx480 after that.

I hadn't messed with VRR here on my rx460/polaris11, because I'm running dual
4k TVs as monitors and didn't think they supported it, yet I was the OP, so at
least on rx460 having VRR off doesn't seem to help.  But just for kicks I did
try turning it on yesterday while back on a stable 5.6.0, and then booted to
today's near-5.8-rc5 to test it.  Still got the graphics freeze.  So that
didn't appear to affect the bug here on my rx460 anyway.

Interestingly enough, tho, quite aside from this bug and maybe it's all in my
head, but despite thinking VRR shouldn't be available here and expecting no
difference, turning it on /does/ seem to make things smoother.  Now I'm
wondering if even without actual VRR, turning it on helps something stay in
sync better, at least on my hardware.Tho it doesn't seem to affect
how the bug triggers, maybe that'll be the hint necessary for the devs to
figure out what's different with the bug on my rx460 compared to the newer
stuff, thus helping them to fix the older stuff too.

* Now the question: Anybody with this bug that is **NOT** running multi-monitor
when it triggers?  Seems all I've seen are multi-monitor, but someone could
have simply not mentioned (or I just missed it) that they're seeing it on
single-monitor too.  (If you are running multi-monitor you don't need to post a
reply just for this, as that seems to be the reported default.  But having
explicit confirmation of whether it affects single-monitor or not could be
helpful.)

-- 
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: fbconsole needs more parameter validations.

[Greg Kroah-Hartman]

On Fri, Jul 10, 2020 at 02:56:58PM +0900, Tetsuo Handa wrote:
> Hello.
> 
> While trying to debug 
> https://syzkaller.appspot.com/bug?extid=017265e8553724e514e8 ,
> I noticed that a crash can happen without opening /dev/ttyXX .
> 
> For example, while a driver which syzbot is reporting accepts screen with
> var.xres = var.yres = 0 (and a crash is not visible until trying to write to
> /dev/ttyXX ), a driver for VMware environment which I'm using (dmesg says 
> "fbcon:
> svgadrmfb (fb0) is primary device") rejects screen with var.xres = var.yres = 
> 0.
> However, specifying var.xres = var.yres = 1 like below reproducer causes a 
> crash
> in my VMware environment.
> 
> --
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int main(int argc, char *argv[])
> {
> const int fd = open("/dev/fb0", O_ACCMODE);
> struct fb_var_screeninfo var = { };
> ioctl(fd, FBIOGET_VSCREENINFO, &var);
> var.xres = var.yres = 1;
> ioctl(fd, FBIOPUT_VSCREENINFO, &var);
> return 0;
> }
> --
> 
> --
> [   20.10] BUG: unable to handle page fault for address: b80500d7b000
> [   20.102225] #PF: supervisor write access in kernel mode
> [   20.102226] #PF: error_code(0x0002) - not-present page
> [   20.102227] PGD 13a48c067 P4D 13a48c067 PUD 13a48d067 PMD 132525067 PTE 0
> [   20.102230] Oops: 0002 [#1] SMP
> [   20.102232] CPU: 3 PID: 2786 Comm: a.out Not tainted 5.8.0-rc4+ #749
> [   20.102233] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
> Desktop Reference Platform, BIOS 6.00 02/27/2020
> [   20.102237] RIP: 0010:bitfill_aligned+0x87/0x120 [cfbfillrect]
> [   20.102238] Code: c3 45 85 db 0f 85 85 00 00 00 44 89 c0 31 d2 41 f7 f1 89 
> c2 83 f8 07 76 41 8d 48 f8 c1 e9 03 48 83 c1 01 48 c1 e1 06 48 01 f1 <48> 89 
> 3e 48 89 7e 08 48 89 7e 10 48 89 7e 18 48 89 7e 20 48 89 7e
> [   20.102239] RSP: 0018:b805012939a8 EFLAGS: 00010206
> [   20.102240] RAX: 03fffe70 RBX: 9c20 RCX: 
> b80520982000
> [   20.102241] RDX: 03fffe70 RSI: b80500d7b000 RDI: 
> 
> [   20.102242] RBP: b805012939b8 R08: 9c20 R09: 
> b80500d7aff8
> [   20.102242] R10:  R11:  R12: 
> 
> [   20.102243] R13: 976734c0c000 R14:  R15: 
> b80500982c80
> [   20.102244] FS:  7f0c9589e740() GS:97673aec() 
> knlGS:
> [   20.102265] CS:  0010 DS:  ES:  CR0: 80050033
> [   20.102265] CR2: b80500d7b000 CR3: 000136cdf004 CR4: 
> 001606e0
> [   20.102277] Call Trace:
> [   20.102281]  cfb_fillrect+0x159/0x340 [cfbfillrect]
> [   20.102385]  ? __mutex_unlock_slowpath+0x158/0x2d0
> [   20.102493]  ? cfb_fillrect+0x340/0x340 [cfbfillrect]
> [   20.102747]  vmw_fb_fillrect+0x12/0x30 [vmwgfx]
> [   20.102755]  bit_clear_margins+0x92/0xf0 [fb]
> [   20.102760]  fbcon_clear_margins+0x4c/0x50 [fb]
> [   20.102763]  fbcon_switch+0x321/0x570 [fb]
> [   20.102771]  redraw_screen+0xe0/0x250
> [   20.102775]  fbcon_modechanged+0x164/0x1b0 [fb]
> [   20.102779]  fbcon_update_vcs+0x15/0x20 [fb]
> [   20.102781]  fb_set_var+0x364/0x3c0 [fb]
> [   20.102817]  do_fb_ioctl+0x2ff/0x3f0 [fb]
> [   20.102894]  ? find_held_lock+0x35/0xa0
> [   20.103126]  ? __audit_syscall_entry+0xd8/0x120
> [   20.103135]  ? kfree+0x25a/0x2b0
> [   20.103139]  fb_ioctl+0x2e/0x40 [fb]
> [   20.103141]  ksys_ioctl+0x86/0xc0
> [   20.103144]  ? do_syscall_64+0x20/0xa0
> [   20.103146]  __x64_sys_ioctl+0x15/0x20
> [   20.103148]  do_syscall_64+0x54/0xa0
> [   20.103151]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [   20.103152] RIP: 0033:0x7f0c953b8307
> [   20.103153] Code: Bad RIP value.
> [   20.103154] RSP: 002b:7ffecbdce0f8 EFLAGS: 0246 ORIG_RAX: 
> 0010
> [   20.103155] RAX: ffda RBX: 0003 RCX: 
> 7f0c953b8307
> [   20.103156] RDX: 7ffecbdce100 RSI: 4601 RDI: 
> 0003
> [   20.103156] RBP:  R08: 7f0c9568be80 R09: 
> 
> [   20.103157] R10: 7ffecbdcdb60 R11: 0246 R12: 
> 004004f2
> [   20.103158] R13: 7ffecbdce280 R14:  R15: 
> 
> [   20.103162] Modules linked in: mousedev rapl evdev input_leds led_class 
> mac_hid psmouse pcspkr xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 
> ipt_REJECT nf_reject_ipv4 xt_conntrack sg ebtable_nat af_packet ip6table_nat 
> ip6table_mangle ip6table_raw iptable_nat nf_nat iptable_mangle iptable_raw 
> nf_conntrack rtc_cmos nf_defrag_ipv4 ip_set nfnetlink ebtable_filter ebtables 
> ip6table_filter ip6_tables iptable_filter bpfilter i2c_piix4 vmw_vmci ac 
> intel_agp button intel_gtt ip_tables x_tables ata_generic pata_acpi serio_raw 
> atkbd libps2 vmwgfx drm_kms_helper cfbfillrect syscopyarea cfbimgblt 
> sysfillrect sysimgblt fb_sys_fops cfbcopyarea fb fbdev ttm drm i2c_core ahci 
> drm_panel_orient

Re: [PATCH v6 2/4] driver core: add deferring probe reason to devices_deferred property

[Mark Brown]

On Fri, Jul 10, 2020 at 09:42:49AM +0200, Andrzej Hajda wrote:

> But the provider does not know if *get is called in probe context or 
> not, so it is not able to differentiate it.

> So the whole idea is for me suspicious/wrong. Kind of proof:

> 1. If you insist that provider's EPROBE_ERROR must be always propagated 
> to driver core then.

> 2. You must enforce that resources can be gathered only from probe.

> 3. But this is against current practice, even if majority of drivers 
> does it from probe, there are many which doesn't.

Those drivers are probably buggy anyway at this point given probe
deferral.


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

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon]

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

--- Comment #57 from Anthony Ruhier (anthony.ruh...@gmail.com) ---
To give some precision about the kernel version range, I'm staying on 5.6.19
for a while, which doesn't have the issue. It's pretty bad though, as it's EOL.

Only the 5.7 branch has it. So it's something that wasn't backported.

I also have multimonitors, with one with VRR, though I don't know if VRR
changes anything in my case as the 2 other screens don't support it.

-- 
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] drm/fb-helper: Fix vt restore

[Thomas Zimmermann]

Hi Daniel,

this patch might not be enougth. I started Xorg and then did 'kill -9'
on the Xorg process. Xorg went away, but the console did not come back.

Best regards
Thomas

Am 23.06.20 um 17:54 schrieb Daniel Vetter:
> In the past we had a pile of hacks to orchestrate access between fbdev
> emulation and native kms clients. We've tried to streamline this, by
> always preferring the kms side above fbdev calls when a drm master
> exists, because drm master controls access to the display resources.
> 
> Unfortunately this breaks existing userspace, specifically Xorg. When
> exiting Xorg first restores the console to text mode using the KDSET
> ioctl on the vt. This does nothing, because a drm master is still
> around. Then it drops the drm master status, which again does nothing,
> because logind is keeping additional drm fd open to be able to
> orchestrate vt switches. In the past this is the point where fbdev was
> restored, as part of the ->lastclose hook on the drm side.
> 
> Now to fix this regression we don't want to go back to letting fbdev
> restore things whenever it feels like, or to the pile of hacks we've
> had before. Instead try and go with a minimal exception to make the
> KDSET case work again, and nothing else.
> 
> This means that if userspace does a KDSET call when switching between
> graphical compositors, there will be some flickering with fbcon
> showing up for a bit. But a) that's not a regression and b) userspace
> can fix it by improving the vt switching dance - logind should have
> all the information it needs.
> 
> While pondering all this I'm also wondering wheter we should have a
> SWITCH_MASTER ioctl to allow race-free master status handover. But
> that's for another day.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208179
> Cc: shl...@fastmail.com
> Reported-and-Tested-by: shl...@fastmail.com
> Cc: Michel Dänzer 
> Fixes: 64914da24ea9 ("drm/fbdev-helper: don't force restores")
> Cc: Noralf Trønnes 
> Cc: Thomas Zimmermann 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc:  # v5.7+
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_fb_helper.c  | 63 +---
>  drivers/video/fbdev/core/fbcon.c |  3 +-
>  include/uapi/linux/fb.h  |  1 +
>  3 files changed, 52 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 170aa7689110..ae69bf8e9bcc 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -227,18 +227,9 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
>  }
>  EXPORT_SYMBOL(drm_fb_helper_debug_leave);
>  
> -/**
> - * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> - * @fb_helper: driver-allocated fbdev helper, can be NULL
> - *
> - * This should be called from driver's drm &drm_driver.lastclose callback
> - * when implementing an fbcon on top of kms using this helper. This ensures 
> that
> - * the user isn't greeted with a black screen when e.g. X dies.
> - *
> - * RETURNS:
> - * Zero if everything went ok, negative error code otherwise.
> - */
> -int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper 
> *fb_helper)
> +static int
> +__drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper,
> + bool force)
>  {
>   bool do_delayed;
>   int ret;
> @@ -250,7 +241,16 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
> drm_fb_helper *fb_helper)
>   return 0;
>  
>   mutex_lock(&fb_helper->lock);
> - ret = drm_client_modeset_commit(&fb_helper->client);
> + if (force) {
> + /*
> +  * Yes this is the _locked version which expects the master lock
> +  * to be held. But for forced restores we're intentionally
> +  * racing here, see drm_fb_helper_set_par().
> +  */
> + ret = drm_client_modeset_commit_locked(&fb_helper->client);
> + } else {
> + ret = drm_client_modeset_commit(&fb_helper->client);
> + }
>  
>   do_delayed = fb_helper->delayed_hotplug;
>   if (do_delayed)
> @@ -262,6 +262,22 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
> drm_fb_helper *fb_helper)
>  
>   return ret;
>  }
> +
> +/**
> + * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> + * @fb_helper: driver-allocated fbdev helper, can be NULL
> + *
> + * This should be called from driver's drm &drm_driver.lastclose callback
> + * when implementing an fbcon on top of kms using this helper. This ensures 
> that
> + * the user isn't greeted with a black screen when e.g. X dies.
> + *
> + * RETURNS:
> + * Zero if everything went ok, negative error code otherwise.
> + */
> +int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper 
> *fb_helper)
> +{
> + return __drm_fb_h

[Bug 208513] New: Radeon RX480 graphics freeze with RIP: 0010:amdgpu_dm_atomic_commit_tail+0x273/0x1100 [amdgpu]

[bugzilla-daemon]

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

Bug ID: 208513
   Summary: Radeon RX480 graphics freeze with RIP:
0010:amdgpu_dm_atomic_commit_tail+0x273/0x1100
[amdgpu]
   Product: Drivers
   Version: 2.5
Kernel Version: 5.7.7
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: blocking
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: jlp.b...@gmail.com
Regression: No

I get frequent freezes with kernel 5.7, especially when having Firefox 77 open
and watching videos. It looks like only graphics freezes as I can still hear
stuff going on in the background. This is what I can see using "journalctl
--boot=-1 -k" after reboot

general protection fault, probably for non-canonical address
0x9ca86a805968f7f1:  [#1] SMP NOPTI
CPU: 1 PID: 117 Comm: kworker/u8:3 Not tainted 5.7.7-1-debug #1 openSUSE
Tumbleweed (unreleased)
Hardware name: System manufacturer System Product Name/H170 PRO GAMING, BIOS
3805 05/16/2018
Workqueue: events_unbound commit_work [drm_kms_helper]
RIP: 0010:amdgpu_dm_atomic_commit_tail+0x273/0x1100 [amdgpu]
Code: 43 08 8b 90 80 04 00 00 41 83 c6 01 44 39 f2 0f 87 3a ff ff ff 48 83 bd
a0 fd ff ff 00 0f 84 03 01 00 00 48 8b bd a0 fd ff ff <80> bf b0 01 00 00 01 0f
86 ac 00 00 00 48 b9 00 00 00>
RSP: 0018:b8c40026bbe0 EFLAGS: 00010282
RAX: 99c28f74b000 RBX: 99c059f6c880 RCX: 99c1c32f7c00
RDX: 0006 RSI: c0b6d540 RDI: 9ca86a805968f7f1
RBP: b8c40026be68 R08: 0001 R09: 0001
R10: 03fb R11: 000898df R12: 99c037db8400
R13:  R14: 0006 R15: 99c037db8000
FS:  () GS:99c296c8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fb44bc04300 CR3: 00066a2e4006 CR4: 003606e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 ? ieee80211_sta_rx_queued_mgmt+0x89/0x2f0 [mac80211]
 ? update_load_avg+0x7e/0x630
 ? set_next_entity+0xab/0x200
 ? _raw_spin_unlock_irq+0xa/0x20
 ? finish_task_switch+0x77/0x280
 ? __schedule+0x205/0x560
 ? _raw_spin_unlock_irq+0xa/0x20
 ? wait_for_completion_timeout+0xcc/0x100
 commit_tail+0x94/0x130 [drm_kms_helper]
 process_one_work+0x1da/0x3a0
 worker_thread+0x46/0x320
 ? rescuer_thread+0x400/0x400
 kthread+0x115/0x140
 ? __kthread_bind_mask+0x60/0x60
 ret_from_fork+0x1f/0x40
Modules linked in: fuse ccm af_packet dmi_sysfs msr hid_logitech_hidpp joydev
intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal hid_logitech_dj
intel_powerclamp coretemp crct10dif_pcl>
 dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs
---[ end trace de4993090519763f ]---
RIP: 0010:amdgpu_dm_atomic_commit_tail+0x273/0x1100 [amdgpu]
Code: 43 08 8b 90 80 04 00 00 41 83 c6 01 44 39 f2 0f 87 3a ff ff ff 48 83 bd
a0 fd ff ff 00 0f 84 03 01 00 00 48 8b bd a0 fd ff ff <80> bf b0 01 00 00 01 0f
86 ac 00 00 00 48 b9 00 00 00>
RSP: 0018:b8c40026bbe0 EFLAGS: 00010282
RAX: 99c28f74b000 RBX: 99c059f6c880 RCX: 99c1c32f7c00
RDX: 0006 RSI: c0b6d540 RDI: 9ca86a805968f7f1
RBP: b8c40026be68 R08: 0001 R09: 0001
R10: 03fb R11: 000898df R12: 99c037db8400
R13:  R14: 0006 R15: 99c037db8000
FS:  () GS:99c296c8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fb44bc04300 CR3: 00066a2e4006 CR4: 003606e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400

Mesa is 20.1.2
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.37.0,
5.7.7-1-debug, LLVM 10.0.0) (0x67df)
Version: 20.1.2
Accelerated: yes
Video memory: 8192MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
VBO free memory - total: 7001 MB, largest block: 7001 MB
VBO free aux. memory - total: 7976 MB, largest block: 7976 MB
Texture free memory - total: 7001 MB, largest block: 7001 MB
Texture free aux. memory - total: 7976 MB, largest block: 7976 MB
Renderbuffer free memory - total: 7001 MB, largest block: 7001 MB
Renderbuffer free aux. memory - total: 7976 MB, largest block: 7976 MB
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 8192 MB
Total available memory: 16384 MB

[Bug 208513] Radeon RX480 graphics freeze with RIP: 0010:amdgpu_dm_atomic_commit_tail+0x273/0x1100 [amdgpu]

[bugzilla-daemon]

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

--- Comment #1 from Jure Repinc (jlp.b...@gmail.com) ---
Created attachment 290205
  --> https://bugzilla.kernel.org/attachment.cgi?id=290205&action=edit
dmesg

-- 
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 208513] Radeon RX480 graphics freeze with RIP: 0010:amdgpu_dm_atomic_commit_tail+0x273/0x1100 [amdgpu]

[bugzilla-daemon]

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

--- Comment #2 from Jure Repinc (jlp.b...@gmail.com) ---
Created attachment 290207
  --> https://bugzilla.kernel.org/attachment.cgi?id=290207&action=edit
Xorg.0.log

-- 
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] staging: android: ion: Skip sync if not mapped

[Greg Kroah-Hartman]

On Tue, Jul 07, 2020 at 08:43:30PM -0700, John Stultz wrote:
> On Fri, Jul 3, 2020 at 12:03 AM Greg Kroah-Hartman
>  wrote:
> > On Tue, Apr 21, 2020 at 10:05:44AM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Apr 20, 2020 at 01:03:39PM -0700, John Stultz wrote:
> > > > The dmabuf heaps have been in an official kernel now for all of three
> > > > weeks. So yea, we can "delete [ION] and see who even notices", but I
> > > > worry that may seem a bit like contempt for the folks doing the work
> > > > on transitioning over, which doesn't help getting them to participate
> > > > within the community.
> > >
> > > But they aren't participating in the community today as no one is
> > > touching the ion code.  So I fail to see how keeping a dead-end-version
> > > of ion in the kernel tree really affects anyone these days.
> >
> > So, any thoughts here?  What's the timeline for ion being able to be
> > removed that you are comfortable with?
> 
> Sorry for the slow reply.  So my earlier plan was to drop it after the next 
> LTS?

Ok, fair enough, we can wait until January.

thanks,

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

Re: KASAN: use-after-free Read in drm_gem_object_release

[Dan Carpenter]

On Fri, Jul 10, 2020 at 04:24:03PM +0800, butt3rflyh4ck wrote:
> I report a bug (in linux-5.8.0-rc4) found by syzkaller.
> 
> kernel config: 
> https://github.com/butterflyhack/syzkaller-fuzz/blob/master/v5.8.0-rc4.config
> 
> I test the reproducer and crash too.
> 
> In the drm_em_vram_t() function,  ttm_bo_init() function call
 ^
This a typo.  The function name is drm_gem_vram_init().

> ttm_bo_init_reserved(),
> the ttm_bo_init_reserved() function  call ttm_bo_put(), it will free
> gbo->bo that is struct ttm_buffer_object.
> 
> then, goto the err_drm_gem_object_release lable,
> drm_gem_object_release() function will free gbo->bo.base, so cause use
> after free.
> 

There is a third free in drm_gem_vram_create().  This is a triple free
bug.  The correct place to free this is in drm_gem_vram_create() because
that's where it was allocated.

This code is quite subtle so I'm not going to attempt to fix it because
I can't test it.

regards,
dan carpenter

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

Re: [PATCH v7 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

[Jim Quinlan]

Hi Christoph,

I'm sending all commits to  since most of
them are PCI related.  I don't send all patches to
linux-ker...@vger.kernel.org since I've read it is overused.  The --cc
list is generated by get_maintainer.pl.

IIRC, in a previous discussion you said you preferred NOT to get the
entire patchset by "--to Christoph"  but instead you would pick it off
from one of the "-to " kernel list sites.  It appears that  all
commits made it to the PCI list
(https://www.spinics.net/lists/linux-pci/).

Let me know what you want and I'll make it so.

Regards,
Jim


On Thu, Jul 9, 2020 at 6:31 AM Christoph Hellwig  wrote:
>
> I someone seem to get just this patch instead of the full series for
> review again..
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] Add support for GPU load values

[Christian Gmeiner]

Hi Lucas,

Am Fr., 10. Juli 2020 um 10:44 Uhr schrieb Christian Gmeiner
:
>
> Hoi Lucas
>
> Am Fr., 10. Juli 2020 um 10:31 Uhr schrieb Lucas Stach 
> :
> >
> > Hi Christian,
> >
> > Am Freitag, den 10.07.2020, 09:41 +0200 schrieb Christian Gmeiner:
> > > This patch series add support for loadavg values for GPU
> > > sub-components. I am adding a SMA algorithm as I was not
> > > really sure if EWMA would be a good fit for this use case.
> >
> > 1 second is a pretty long window in GPU time. Why do you feel that a
> > simple moving average is more appropriate than a exponentially
> > weighted one here? Note that I haven't given this any thought myself
> > and haven't made up my mind yet, so this is a honest question to
> > understand the reasoning behind your choice.
> >
>

I have v2 ready except for this point. If you want to go with EWMA could you
provide me with a good weight reciprocal value to use?

-- 
greets
--
Christian Gmeiner, MSc

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

Re: [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

[Maarten Lankhorst]

Op 09-07-2020 om 14:33 schreef Daniel Vetter:
> Comes up every few years, gets somewhat tedious to discuss, let's
> write this down once and for all.
>
> What I'm not sure about is whether the text should be more explicit in
> flat out mandating the amdkfd eviction fences for long running compute
> workloads or workloads where userspace fencing is allowed.
>
> v2: Now with dot graph!
>
> v3: Typo (Dave Airlie)

For first 5 patches, and patch 16, 17:

Reviewed-by: Maarten Lankhorst 

> Acked-by: Christian König 
> Acked-by: Daniel Stone 
> Cc: Jesse Natalie 
> Cc: Steve Pronovost 
> Cc: Jason Ekstrand 
> Cc: Felix Kuehling 
> Cc: Mika Kuoppala 
> Cc: Thomas Hellstrom 
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: Chris Wilson 
> Cc: Maarten Lankhorst 
> Cc: Christian König 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/driver-api/dma-buf.rst | 70 
>  1 file changed, 70 insertions(+)
>
> diff --git a/Documentation/driver-api/dma-buf.rst 
> b/Documentation/driver-api/dma-buf.rst
> index f8f6decde359..100bfd227265 100644
> --- a/Documentation/driver-api/dma-buf.rst
> +++ b/Documentation/driver-api/dma-buf.rst
> @@ -178,3 +178,73 @@ DMA Fence uABI/Sync File
>  .. kernel-doc:: include/linux/sync_file.h
> :internal:
>  
> +Indefinite DMA Fences
> +
> +
> +At various times &dma_fence with an indefinite time until dma_fence_wait()
> +finishes have been proposed. Examples include:
> +
> +* Future fences, used in HWC1 to signal when a buffer isn't used by the 
> display
> +  any longer, and created with the screen update that makes the buffer 
> visible.
> +  The time this fence completes is entirely under userspace's control.
> +
> +* Proxy fences, proposed to handle &drm_syncobj for which the fence has not 
> yet
> +  been set. Used to asynchronously delay command submission.
> +
> +* Userspace fences or gpu futexes, fine-grained locking within a command 
> buffer
> +  that userspace uses for synchronization across engines or with the CPU, 
> which
> +  are then imported as a DMA fence for integration into existing winsys
> +  protocols.
> +
> +* Long-running compute command buffers, while still using traditional end of
> +  batch DMA fences for memory management instead of context preemption DMA
> +  fences which get reattached when the compute job is rescheduled.
> +
> +Common to all these schemes is that userspace controls the dependencies of 
> these
> +fences and controls when they fire. Mixing indefinite fences with normal
> +in-kernel DMA fences does not work, even when a fallback timeout is included 
> to
> +protect against malicious userspace:
> +
> +* Only the kernel knows about all DMA fence dependencies, userspace is not 
> aware
> +  of dependencies injected due to memory management or scheduler decisions.
> +
> +* Only userspace knows about all dependencies in indefinite fences and when
> +  exactly they will complete, the kernel has no visibility.
> +
> +Furthermore the kernel has to be able to hold up userspace command submission
> +for memory management needs, which means we must support indefinite fences 
> being
> +dependent upon DMA fences. If the kernel also support indefinite fences in 
> the
> +kernel like a DMA fence, like any of the above proposal would, there is the
> +potential for deadlocks.
> +
> +.. kernel-render:: DOT
> +   :alt: Indefinite Fencing Dependency Cycle
> +   :caption: Indefinite Fencing Dependency Cycle
> +
> +   digraph "Fencing Cycle" {
> +  node [shape=box bgcolor=grey style=filled]
> +  kernel [label="Kernel DMA Fences"]
> +  userspace [label="userspace controlled fences"]
> +  kernel -> userspace [label="memory management"]
> +  userspace -> kernel [label="Future fence, fence proxy, ..."]
> +
> +  { rank=same; kernel userspace }
> +   }
> +
> +This means that the kernel might accidentally create deadlocks
> +through memory management dependencies which userspace is unaware of, which
> +randomly hangs workloads until the timeout kicks in. Workloads, which from
> +userspace's perspective, do not contain a deadlock.  In such a mixed fencing
> +architecture there is no single entity with knowledge of all dependencies.
> +Thefore preventing such deadlocks from within the kernel is not possible.
> +
> +The only solution to avoid dependencies loops is by not allowing indefinite
> +fences in the kernel. This means:
> +
> +* No future fences, proxy fences or userspace fences imported as DMA fences,
> +  with or without a timeout.
> +
> +* No DMA fences that signal end of batchbuffer for command submission where
> +  userspace is allowed to use userspace fencing or long running compute
> +  workloads. This also means no implicit fencing for shared buffers in these
> +  cases.


___
dri-devel mailing list
dri-devel@

Re: [PATCH] drm/fb-helper: Fix vt restore

[Daniel Vetter]

On Fri, Jul 10, 2020 at 1:31 PM Thomas Zimmermann  wrote:
>
> Hi Daniel,
>
> this patch might not be enougth. I started Xorg and then did 'kill -9'
> on the Xorg process. Xorg went away, but the console did not come back.

Hm don't you need to reset your terminal to text mode in that case
first? Iirc there's a sysrq. All again assuming not terribly modern
system where that stuff is all done by logind.
-Daniel

>
> Best regards
> Thomas
>
> Am 23.06.20 um 17:54 schrieb Daniel Vetter:
> > In the past we had a pile of hacks to orchestrate access between fbdev
> > emulation and native kms clients. We've tried to streamline this, by
> > always preferring the kms side above fbdev calls when a drm master
> > exists, because drm master controls access to the display resources.
> >
> > Unfortunately this breaks existing userspace, specifically Xorg. When
> > exiting Xorg first restores the console to text mode using the KDSET
> > ioctl on the vt. This does nothing, because a drm master is still
> > around. Then it drops the drm master status, which again does nothing,
> > because logind is keeping additional drm fd open to be able to
> > orchestrate vt switches. In the past this is the point where fbdev was
> > restored, as part of the ->lastclose hook on the drm side.
> >
> > Now to fix this regression we don't want to go back to letting fbdev
> > restore things whenever it feels like, or to the pile of hacks we've
> > had before. Instead try and go with a minimal exception to make the
> > KDSET case work again, and nothing else.
> >
> > This means that if userspace does a KDSET call when switching between
> > graphical compositors, there will be some flickering with fbcon
> > showing up for a bit. But a) that's not a regression and b) userspace
> > can fix it by improving the vt switching dance - logind should have
> > all the information it needs.
> >
> > While pondering all this I'm also wondering wheter we should have a
> > SWITCH_MASTER ioctl to allow race-free master status handover. But
> > that's for another day.
> >
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208179
> > Cc: shl...@fastmail.com
> > Reported-and-Tested-by: shl...@fastmail.com
> > Cc: Michel Dänzer 
> > Fixes: 64914da24ea9 ("drm/fbdev-helper: don't force restores")
> > Cc: Noralf Trønnes 
> > Cc: Thomas Zimmermann 
> > Cc: Daniel Vetter 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc:  # v5.7+
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c  | 63 +---
> >  drivers/video/fbdev/core/fbcon.c |  3 +-
> >  include/uapi/linux/fb.h  |  1 +
> >  3 files changed, 52 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 170aa7689110..ae69bf8e9bcc 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -227,18 +227,9 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
> >  }
> >  EXPORT_SYMBOL(drm_fb_helper_debug_leave);
> >
> > -/**
> > - * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> > - * @fb_helper: driver-allocated fbdev helper, can be NULL
> > - *
> > - * This should be called from driver's drm &drm_driver.lastclose callback
> > - * when implementing an fbcon on top of kms using this helper. This 
> > ensures that
> > - * the user isn't greeted with a black screen when e.g. X dies.
> > - *
> > - * RETURNS:
> > - * Zero if everything went ok, negative error code otherwise.
> > - */
> > -int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper 
> > *fb_helper)
> > +static int
> > +__drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper 
> > *fb_helper,
> > + bool force)
> >  {
> >   bool do_delayed;
> >   int ret;
> > @@ -250,7 +241,16 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
> > drm_fb_helper *fb_helper)
> >   return 0;
> >
> >   mutex_lock(&fb_helper->lock);
> > - ret = drm_client_modeset_commit(&fb_helper->client);
> > + if (force) {
> > + /*
> > +  * Yes this is the _locked version which expects the master 
> > lock
> > +  * to be held. But for forced restores we're intentionally
> > +  * racing here, see drm_fb_helper_set_par().
> > +  */
> > + ret = drm_client_modeset_commit_locked(&fb_helper->client);
> > + } else {
> > + ret = drm_client_modeset_commit(&fb_helper->client);
> > + }
> >
> >   do_delayed = fb_helper->delayed_hotplug;
> >   if (do_delayed)
> > @@ -262,6 +262,22 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
> > drm_fb_helper *fb_helper)
> >
> >   return ret;
> >  }
> > +
> > +/**
> > + * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> > + * @fb_helper: driver-all

Re: [PATCH 02/25] dma-fence: prime lockdep annotations

[Christian König]

Am 10.07.20 um 14:43 schrieb Jason Gunthorpe:

On Thu, Jul 09, 2020 at 10:09:11AM +0200, Daniel Vetter wrote:

Hi Jason,

Below the paragraph I've added after our discussions around dma-fences
outside of drivers/gpu. Good enough for an ack on this, or want something
changed?

Thanks, Daniel


+ * Note that only GPU drivers have a reasonable excuse for both requiring
+ * &mmu_interval_notifier and &shrinker callbacks at the same time as having to
+ * track asynchronous compute work using &dma_fence. No driver outside of
+ * drivers/gpu should ever call dma_fence_wait() in such contexts.

I was hoping we'd get to 'no driver outside GPU should even use
dma_fence()'


My last status was that V4L could come use dma_fences as well.

I'm not 100% sure, but wouldn't MMU notifier + dma_fence be a valid use 
case for things like custom FPGA interfaces as well?



Is that not reasonable?

When your annotations once anything uses dma_fence it has to assume
the worst cases, right?


Well a defensive approach is usually the best idea, yes.

Christian.



Jason


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

Re: [PATCH 02/25] dma-fence: prime lockdep annotations

[Christian König]

Am 10.07.20 um 14:54 schrieb Jason Gunthorpe:

On Fri, Jul 10, 2020 at 02:48:16PM +0200, Christian König wrote:

Am 10.07.20 um 14:43 schrieb Jason Gunthorpe:

On Thu, Jul 09, 2020 at 10:09:11AM +0200, Daniel Vetter wrote:

Hi Jason,

Below the paragraph I've added after our discussions around dma-fences
outside of drivers/gpu. Good enough for an ack on this, or want something
changed?

Thanks, Daniel


+ * Note that only GPU drivers have a reasonable excuse for both requiring
+ * &mmu_interval_notifier and &shrinker callbacks at the same time as having to
+ * track asynchronous compute work using &dma_fence. No driver outside of
+ * drivers/gpu should ever call dma_fence_wait() in such contexts.

I was hoping we'd get to 'no driver outside GPU should even use
dma_fence()'

My last status was that V4L could come use dma_fences as well.

I'm sure lots of places *could* use it, but I think I understood that
it is a bad idea unless you have to fit into the DRM uAPI?


It would be a bit questionable if you use the container objects we came 
up with in the DRM subsystem outside of it.


But using the dma_fence itself makes sense for everything which could do 
async DMA in general.



You are better to do something contained in the single driver where
locking can be analyzed.


I'm not 100% sure, but wouldn't MMU notifier + dma_fence be a valid use case
for things like custom FPGA interfaces as well?

I don't think we should expand the list of drivers that use this
technique.
Drivers that can't suspend should pin memory, not use blocked
notifiers to created pinned memory.


Agreed totally, it's a complete pain to maintain even for the GPU drivers.

Unfortunately that doesn't change users from requesting it. So I'm 
pretty sure we are going to see more of this.


Christian.



Jason


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

Re: [PATCH] drm/fb-helper: Fix vt restore

[Thomas Zimmermann]

Hi

Am 10.07.20 um 14:38 schrieb Daniel Vetter:
> On Fri, Jul 10, 2020 at 1:31 PM Thomas Zimmermann  wrote:
>>
>> Hi Daniel,
>>
>> this patch might not be enougth. I started Xorg and then did 'kill -9'
>> on the Xorg process. Xorg went away, but the console did not come back.
> 
> Hm don't you need to reset your terminal to text mode in that case
> first? Iirc there's a sysrq. All again assuming not terribly modern
> system where that stuff is all done by logind.

I don't know. I just noticed that kill -9 did not restore the terminal
and apparently it was related to these patches. Maybe it did not even
work before?

Best regards
Thomas

> -Daniel
> 
>>
>> Best regards
>> Thomas
>>
>> Am 23.06.20 um 17:54 schrieb Daniel Vetter:
>>> In the past we had a pile of hacks to orchestrate access between fbdev
>>> emulation and native kms clients. We've tried to streamline this, by
>>> always preferring the kms side above fbdev calls when a drm master
>>> exists, because drm master controls access to the display resources.
>>>
>>> Unfortunately this breaks existing userspace, specifically Xorg. When
>>> exiting Xorg first restores the console to text mode using the KDSET
>>> ioctl on the vt. This does nothing, because a drm master is still
>>> around. Then it drops the drm master status, which again does nothing,
>>> because logind is keeping additional drm fd open to be able to
>>> orchestrate vt switches. In the past this is the point where fbdev was
>>> restored, as part of the ->lastclose hook on the drm side.
>>>
>>> Now to fix this regression we don't want to go back to letting fbdev
>>> restore things whenever it feels like, or to the pile of hacks we've
>>> had before. Instead try and go with a minimal exception to make the
>>> KDSET case work again, and nothing else.
>>>
>>> This means that if userspace does a KDSET call when switching between
>>> graphical compositors, there will be some flickering with fbcon
>>> showing up for a bit. But a) that's not a regression and b) userspace
>>> can fix it by improving the vt switching dance - logind should have
>>> all the information it needs.
>>>
>>> While pondering all this I'm also wondering wheter we should have a
>>> SWITCH_MASTER ioctl to allow race-free master status handover. But
>>> that's for another day.
>>>
>>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208179
>>> Cc: shl...@fastmail.com
>>> Reported-and-Tested-by: shl...@fastmail.com
>>> Cc: Michel Dänzer 
>>> Fixes: 64914da24ea9 ("drm/fbdev-helper: don't force restores")
>>> Cc: Noralf Trønnes 
>>> Cc: Thomas Zimmermann 
>>> Cc: Daniel Vetter 
>>> Cc: Maarten Lankhorst 
>>> Cc: Maxime Ripard 
>>> Cc: David Airlie 
>>> Cc: Daniel Vetter 
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc:  # v5.7+
>>> Signed-off-by: Daniel Vetter 
>>> ---
>>>  drivers/gpu/drm/drm_fb_helper.c  | 63 +---
>>>  drivers/video/fbdev/core/fbcon.c |  3 +-
>>>  include/uapi/linux/fb.h  |  1 +
>>>  3 files changed, 52 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index 170aa7689110..ae69bf8e9bcc 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -227,18 +227,9 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
>>>  }
>>>  EXPORT_SYMBOL(drm_fb_helper_debug_leave);
>>>
>>> -/**
>>> - * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
>>> - * @fb_helper: driver-allocated fbdev helper, can be NULL
>>> - *
>>> - * This should be called from driver's drm &drm_driver.lastclose callback
>>> - * when implementing an fbcon on top of kms using this helper. This 
>>> ensures that
>>> - * the user isn't greeted with a black screen when e.g. X dies.
>>> - *
>>> - * RETURNS:
>>> - * Zero if everything went ok, negative error code otherwise.
>>> - */
>>> -int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper 
>>> *fb_helper)
>>> +static int
>>> +__drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper 
>>> *fb_helper,
>>> + bool force)
>>>  {
>>>   bool do_delayed;
>>>   int ret;
>>> @@ -250,7 +241,16 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
>>> drm_fb_helper *fb_helper)
>>>   return 0;
>>>
>>>   mutex_lock(&fb_helper->lock);
>>> - ret = drm_client_modeset_commit(&fb_helper->client);
>>> + if (force) {
>>> + /*
>>> +  * Yes this is the _locked version which expects the master 
>>> lock
>>> +  * to be held. But for forced restores we're intentionally
>>> +  * racing here, see drm_fb_helper_set_par().
>>> +  */
>>> + ret = drm_client_modeset_commit_locked(&fb_helper->client);
>>> + } else {
>>> + ret = drm_client_modeset_commit(&fb_helper->client);
>>> + }
>>>
>>>   do_delayed = fb_helper->delayed_hotplug;
>>>   if (do_delayed)
>>> @@ -262,6 +262

Re: [PATCH] efi: avoid error message when booting under Xen

[Ard Biesheuvel]

On Fri, 10 Jul 2020 at 13:17, Bartlomiej Zolnierkiewicz
 wrote:
>
>
> [ added EFI Maintainer & ML to Cc: ]
>
> Hi,
>
> On 7/9/20 11:17 AM, Jürgen Groß wrote:
> > On 28.06.20 10:50, Jürgen Groß wrote:
> >> Ping?
> >>
> >> On 10.06.20 16:10, Juergen Gross wrote:
> >>> efifb_probe() will issue an error message in case the kernel is booted
> >>> as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
> >>> that message by calling efi_mem_desc_lookup() only if EFI_PARAVIRT
> >>> isn't set.
> >>>

Why not test for EFI_MEMMAP instead of EFI_BOOT?


> >>> Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when 
> >>> mapping the FB")
> >>> Signed-off-by: Juergen Gross 
> >>> ---
> >>>   drivers/video/fbdev/efifb.c | 2 +-
> >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> >>> index 65491ae74808..f5eccd1373e9 100644
> >>> --- a/drivers/video/fbdev/efifb.c
> >>> +++ b/drivers/video/fbdev/efifb.c
> >>> @@ -453,7 +453,7 @@ static int efifb_probe(struct platform_device *dev)
> >>>   info->apertures->ranges[0].base = efifb_fix.smem_start;
> >>>   info->apertures->ranges[0].size = size_remap;
> >>> -if (efi_enabled(EFI_BOOT) &&
> >>> +if (efi_enabled(EFI_BOOT) && !efi_enabled(EFI_PARAVIRT) &&
> >>>   !efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
> >>>   if ((efifb_fix.smem_start + efifb_fix.smem_len) >
> >>>   (md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) {
> >>>
> >>
> >
> > In case I see no reaction from the maintainer for another week I'll take
> > this patch through the Xen tree.
>
> From fbdev POV this change looks fine to me and I'm OK with merging it
> through Xen or EFI tree:
>
> Acked-by: Bartlomiej Zolnierkiewicz 
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 2/5] driver core: add deferring probe reason to devices_deferred property

[Greg Kroah-Hartman]

On Thu, Jul 02, 2020 at 03:44:21PM +0200, Andrzej Hajda wrote:
> /sys/kernel/debug/devices_deferred property contains list of deferred devices.
> This list does not contain reason why the driver deferred probe, the patch
> improves it.
> The natural place to set the reason is dev_err_probe function introduced
> recently, ie. if dev_err_probe will be called with -EPROBE_DEFER instead of
> printk the message will be attached to a deferred device and printed when user
> reads devices_deferred property.
> 
> Signed-off-by: Andrzej Hajda 
> Reviewed-by: Mark Brown 
> Reviewed-by: Javier Martinez Canillas 
> Reviewed-by: Andy Shevchenko 
> Reviewed-by: Rafael J. Wysocki 
> ---
> v8:
> - improved commit message

I'm totally confused by this series.  Can you resend the whole thing,
as a full series, not just random individual patches in the series
incremented?  It's a pain to try to fish them all out as to which is the
"latest" with all of the needed reviewed by lines :(

thanks,

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

Re: [PATCH] efi: avoid error message when booting under Xen

[Jürgen Groß]

On 10.07.20 15:27, Ard Biesheuvel wrote:

On Fri, 10 Jul 2020 at 13:17, Bartlomiej Zolnierkiewicz
 wrote:



[ added EFI Maintainer & ML to Cc: ]

Hi,

On 7/9/20 11:17 AM, Jürgen Groß wrote:

On 28.06.20 10:50, Jürgen Groß wrote:

Ping?

On 10.06.20 16:10, Juergen Gross wrote:

efifb_probe() will issue an error message in case the kernel is booted
as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
that message by calling efi_mem_desc_lookup() only if EFI_PARAVIRT
isn't set.



Why not test for EFI_MEMMAP instead of EFI_BOOT?


Honestly I'm not sure EFI_BOOT is always set in that case. If you tell
me it is fine to just replace the test to check for EFI_MEMMAP I'm fine
to modify my patch.


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

Re: [PATCH] efi: avoid error message when booting under Xen

[Ard Biesheuvel]

On Fri, 10 Jul 2020 at 16:38, Jürgen Groß  wrote:
>
> On 10.07.20 15:27, Ard Biesheuvel wrote:
> > On Fri, 10 Jul 2020 at 13:17, Bartlomiej Zolnierkiewicz
> >  wrote:
> >>
> >>
> >> [ added EFI Maintainer & ML to Cc: ]
> >>
> >> Hi,
> >>
> >> On 7/9/20 11:17 AM, Jürgen Groß wrote:
> >>> On 28.06.20 10:50, Jürgen Groß wrote:
>  Ping?
> 
>  On 10.06.20 16:10, Juergen Gross wrote:
> > efifb_probe() will issue an error message in case the kernel is booted
> > as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
> > that message by calling efi_mem_desc_lookup() only if EFI_PARAVIRT
> > isn't set.
> >
> >
> > Why not test for EFI_MEMMAP instead of EFI_BOOT?
>
> Honestly I'm not sure EFI_BOOT is always set in that case. If you tell
> me it is fine to just replace the test to check for EFI_MEMMAP I'm fine
> to modify my patch.
>


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

Re: [PATCH 02/25] dma-fence: prime lockdep annotations

[Daniel Vetter]

On Fri, Jul 10, 2020 at 3:48 PM Jason Gunthorpe  wrote:
>
> On Fri, Jul 10, 2020 at 03:01:10PM +0200, Christian König wrote:
> > Am 10.07.20 um 14:54 schrieb Jason Gunthorpe:
> > > On Fri, Jul 10, 2020 at 02:48:16PM +0200, Christian König wrote:
> > > > Am 10.07.20 um 14:43 schrieb Jason Gunthorpe:
> > > > > On Thu, Jul 09, 2020 at 10:09:11AM +0200, Daniel Vetter wrote:
> > > > > > Hi Jason,
> > > > > >
> > > > > > Below the paragraph I've added after our discussions around 
> > > > > > dma-fences
> > > > > > outside of drivers/gpu. Good enough for an ack on this, or want 
> > > > > > something
> > > > > > changed?
> > > > > >
> > > > > > Thanks, Daniel
> > > > > >
> > > > > > > + * Note that only GPU drivers have a reasonable excuse for both 
> > > > > > > requiring
> > > > > > > + * &mmu_interval_notifier and &shrinker callbacks at the same 
> > > > > > > time as having to
> > > > > > > + * track asynchronous compute work using &dma_fence. No driver 
> > > > > > > outside of
> > > > > > > + * drivers/gpu should ever call dma_fence_wait() in such 
> > > > > > > contexts.
> > > > > I was hoping we'd get to 'no driver outside GPU should even use
> > > > > dma_fence()'
> > > > My last status was that V4L could come use dma_fences as well.
> > > I'm sure lots of places *could* use it, but I think I understood that
> > > it is a bad idea unless you have to fit into the DRM uAPI?
> >
> > It would be a bit questionable if you use the container objects we came up
> > with in the DRM subsystem outside of it.
> >
> > But using the dma_fence itself makes sense for everything which could do
> > async DMA in general.
>
> dma_fence only possibly makes some sense if you intend to expose the
> completion outside a single driver.
>
> The prefered kernel design pattern for this is to connect things with
> a function callback.
>
> So the actual use case of dma_fence is quite narrow and tightly linked
> to DRM.
>
> I don't think we should spread this beyond DRM, I can't see a reason.

Yeah v4l has a legit reason to use dma_fence, android wants that
there. There's even been patches proposed years ago, but never landed
because android is using some vendor hack horror show for camera
drivers right now.

But there is an effort going on to fix that (under the libcamera
heading), and I expect that once we have that, it'll want dma_fence
support. So outright excluding everyone from dma_fence is a bit too
much. They definitely shouldn't be used though for entirely
independent stuff.

> > > You are better to do something contained in the single driver where
> > > locking can be analyzed.
> > >
> > > > I'm not 100% sure, but wouldn't MMU notifier + dma_fence be a valid use 
> > > > case
> > > > for things like custom FPGA interfaces as well?
> > > I don't think we should expand the list of drivers that use this
> > > technique.
> > > Drivers that can't suspend should pin memory, not use blocked
> > > notifiers to created pinned memory.
> >
> > Agreed totally, it's a complete pain to maintain even for the GPU drivers.
> >
> > Unfortunately that doesn't change users from requesting it. So I'm pretty
> > sure we are going to see more of this.
>
> Kernel maintainers need to say no.
>
> The proper way to do DMA on no-faulting hardware is page pinning.
>
> Trying to improve performance of limited HW by using sketchy
> techniques at the cost of general system stability should be a NAK.

Well that's pretty much gpu drivers, all the horrors for a bit more speed :-)

On the text itself, should I upgrade to "must not" instead of "should
not"? Or more needed?
-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 v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can

[Rob Clark]

On Thu, Jul 9, 2020 at 11:15 PM Steev Klimaszewski  wrote:
>
> Hi,
>
> On 7/9/20 11:12 PM, Doug Anderson wrote:
> >> root@c630:~# bus=$(i2cdetect -l | grep sn65 | sed 
> >> 's/i2c-\([0-9]*\).*$/\1/')
> >> root@c630:~# i2cdump ${bus} 0x50 i > edid
> >> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> >> I will probe file /dev/i2c-16, address 0x50, mode i2c block
> >> Continue? [Y/n]
> >> root@c630:~# edid-decode edid
> >> edid-decode (hex):
> >>
> >> 00 ff ff ff ff ff ff 00 09 e5 d1 07 00 00 00 00
> >> 01 1c 01 04 a5 1d 11 78 0a 1d b0 a6 58 54 9e 26
> >> 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> >> 01 01 01 01 01 01 c0 39 80 18 71 38 28 40 30 20
> >> 36 00 26 a5 10 00 00 1a 00 00 00 00 00 00 00 00
> >> 00 00 00 00 00 00 00 00 00 1a 00 00 00 fe 00 42
> >> 4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe
> >> 00 4e 56 31 33 33 46 48 4d 2d 4e 36 31 0a 00 9a
> >>
> >> 03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb
> >> fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73
> >> 44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61
> >> 92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2
> >> 66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70
> >> 43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc
> >> 45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3
> >> 30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29
> >>
> >> 
> >>
> >> EDID version: 1.4
> >> Manufacturer: BOE Model 2001 Serial Number 0
> >> Made in week 1 of 2018
> >> Digital display
> >> 8 bits per primary color channel
> >> DisplayPort interface
> >> Maximum image size: 29 cm x 17 cm
> >> Gamma: 2.20
> >> Supported color formats: RGB 4:4:4, YCrCb 4:4:4
> >> First detailed timing includes the native pixel format and preferred
> >> refresh rate
> >> Color Characteristics
> >> Red:   0.6484, 0.3447
> >> Green: 0.3310, 0.6181
> >> Blue:  0.1503, 0.0615
> >> White: 0.3125, 0.3281
> >> Established Timings I & II: none
> >> Standard Timings: none
> >> Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm
> >>  1920 1968 2000 2200 ( 48  32 200)
> >>  1080 1083 1089 1120 (  3   6  31)
> >>  +hsync -vsync
> >>  VertFreq: 60.000 Hz, HorFreq: 67.200 kHz
> >> Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00
> >> 00 00 00 00 00 00 00 00 1a  
> >> Alphanumeric Data String: BOE CQ
> >> Alphanumeric Data String: NV133FHM-N61
> >> Checksum: 0x9a
> >>
> >> 
> >>
> >> Unknown EDID Extension Block 0x03
> >> 03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb .&.w...qo...C.j.
> >> fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73  ... 9."nehwp..4s
> >> 44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61 D!...m.b.*|...ja
> >> 92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2 ...SL9...#.H.9..
> >> 66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70 f.p..w.J..Lrn]Gp
> >> 43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc C..x..A..j(.
> >> 45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3 E*..5.4.>.^.
> >> 30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29 0^.).H.1..;)
> >> Checksum: 0x29 (should be 0x82)
> >>
> >>
> >> - My edid does in fact say it's 8bit
> > Crazy!  Mine:
> >
> > Extracted contents:
> > header:  00 ff ff ff ff ff ff 00
> > serial number:   09 e5 2d 08 00 00 00 00 23 1c
> > version: 01 04
> > basic params:95 1d 11 78 02
> > chroma info: d5 00 a6 58 54 9f 27 0f 4f 57
> > established: 00 00 00
> > standard:01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
> > descriptor 1:c0 39 80 18 71 38 28 40 30 20 36 00 26 a5 10 00 00 1a
> > descriptor 2:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > descriptor 3:00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20
> > descriptor 4:00 00 00 fe 00 4e 56 31 33 33 46 48 4d 2d 4e 36 32 0a
> > extensions:  00
> > checksum:40
> >
> > Manufacturer: BOE Model 82d Serial Number 0
> > Made week 35 of 2018
> > EDID version: 1.4
> > Digital display
> > 6 bits per primary color channel
> > DisplayPort interface
> > Maximum image size: 29 cm x 17 cm
> > Gamma: 2.20
> > Supported color formats: RGB 4:4:4
> > First detailed timing is preferred timing
> > Established timings supported:
> > Standard timings supported:
> > Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm
> > 1920 1968 2000 2200 hborder 0
> > 1080 1083 1089 1120 vborder 0
> > +hsync -vsync
> > Manufacturer-specified data, tag 0
> > ASCII string: BOE
> > ASCII string: NV133FHM-N62
> > Checksum: 0x40 (valid)
> >
> > Unknown extension block
> >
> > EDID block does NOT conform to EDID 1.3!
> >  Missing name descriptor
> >  Missing monitor ranges
> >  Detailed block string not properly terminated
> > EDID block does not conform at all!
> >  Has 128 nonconformant extension block(s)
>
> I did attempt to modify the patch, and I don't think I did it correctly
>
> 

Re: [PATCH v2 2/2] video: fbdev: amifb: add FIXMEs about {put,get}_user() failures

[Bartlomiej Zolnierkiewicz]

On 6/2/20 2:03 PM, Geert Uytterhoeven wrote:
> On Tue, Jun 2, 2020 at 1:52 PM Bartlomiej Zolnierkiewicz
>  wrote:
>> Since we lack the hardware (or proper emulator setup) for
>> testing needed changes add FIXMEs to document the issues
>> (so at least they are not forgotten).
>>
>> Cc: Al Viro 
>> Cc: Geert Uytterhoeven 
>> Signed-off-by: Bartlomiej Zolnierkiewicz 
> 
> Reviewed-by: Geert Uytterhoeven 

Applied to drm-misc-next tree.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bartlomiej Zolnierkiewicz]

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

Applied to drm-misc-next tree, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

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

Re: [PATCH v3] video: fbdev: ssd1307fb: Added support to Column offset

[Bartlomiej Zolnierkiewicz]

[ added dri-devel ML to Cc: ]

Hi,

Sorry for the delay.

On 5/13/20 8:48 PM, Rodrigo Alencar wrote:
> From: Rodrigo Rolim Mendes de Alencar 
> 
> This patch provides support for displays like VGM128064B0W10,
> which requires a column offset of 2, i.e., its segments starts
> in SEG2 and ends in SEG129.
> 
> Signed-off-by: Rodrigo Alencar <455.rodrigo.alen...@gmail.com>

Please resend with "From:" & "Signed-off-by:" tags fixed to match so
I can merge the patch.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  Documentation/devicetree/bindings/display/ssd1307fb.txt | 1 +
>  drivers/video/fbdev/ssd1307fb.c | 8 ++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt 
> b/Documentation/devicetree/bindings/display/ssd1307fb.txt
> index 27333b9551b3..2dcb6d12d137 100644
> --- a/Documentation/devicetree/bindings/display/ssd1307fb.txt
> +++ b/Documentation/devicetree/bindings/display/ssd1307fb.txt
> @@ -19,6 +19,7 @@ Optional properties:
>- vbat-supply: The supply for VBAT
>- solomon,segment-no-remap: Display needs normal (non-inverted) data column
>to segment mapping
> +  - solomon,col-offset: Offset of columns (COL/SEG) that the screen is 
> mapped to.
>- solomon,com-seq: Display uses sequential COM pin configuration
>- solomon,com-lrremap: Display uses left-right COM pin remap
>- solomon,com-invdir: Display uses inverted COM pin scan direction
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 8e06ba912d60..102f941104c0 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -74,6 +74,7 @@ struct ssd1307fb_par {
>   struct fb_info *info;
>   u8 lookup_table[4];
>   u32 page_offset;
> + u32 col_offset;
>   u32 prechargep1;
>   u32 prechargep2;
>   struct pwm_device *pwm;
> @@ -458,11 +459,11 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
>   if (ret < 0)
>   return ret;
>  
> - ret = ssd1307fb_write_cmd(par->client, 0x0);
> + ret = ssd1307fb_write_cmd(par->client, par->col_offset);
>   if (ret < 0)
>   return ret;
>  
> - ret = ssd1307fb_write_cmd(par->client, par->width - 1);
> + ret = ssd1307fb_write_cmd(par->client, par->col_offset + par->width - 
> 1);
>   if (ret < 0)
>   return ret;
>  
> @@ -626,6 +627,9 @@ static int ssd1307fb_probe(struct i2c_client *client)
>   if (device_property_read_u32(dev, "solomon,page-offset", 
> &par->page_offset))
>   par->page_offset = 1;
>  
> + if (device_property_read_u32(dev, "solomon,col-offset", 
> &par->col_offset))
> + par->col_offset = 0;
> +
>   if (device_property_read_u32(dev, "solomon,com-offset", 
> &par->com_offset))
>   par->com_offset = 0;
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][next] fbcon: Use array3_size() helper in scr_memcpyw()

[Bartlomiej Zolnierkiewicz]

On 6/16/20 1:15 AM, Gustavo A. R. Silva wrote:
> Use array3_size() helper instead of the open-coded version in scr_memcpyw()
> and scr_memsetw(). These sorts of multiplication factors need to be wrapped
> in array3_size().
> 
> This issue was found with the help of Coccinelle and, audited and fixed
> manually.
> 
> Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83
> Signed-off-by: Gustavo A. R. Silva 

Applied to drm-misc-next tree, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/video/fbdev/core/fbcon.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fbcon.c 
> b/drivers/video/fbdev/core/fbcon.c
> index 9d28a8e3328f..6af2734f2a7b 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -639,7 +639,7 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct 
> fb_info *info,
>  GFP_KERNEL);
>   if (save) {
>   int i = cols < new_cols ? cols : new_cols;
> - scr_memsetw(save, erase, logo_lines * new_cols * 2);
> + scr_memsetw(save, erase, array3_size(logo_lines, 
> new_cols, 2));
>   r = q - step;
>   for (cnt = 0; cnt < logo_lines; cnt++, r += i)
>   scr_memcpyw(save + cnt * new_cols, r, 2 * i);
> @@ -676,7 +676,7 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct 
> fb_info *info,
>   q = (unsigned short *) (vc->vc_origin +
>   vc->vc_size_row *
>   rows);
> - scr_memcpyw(q, save, logo_lines * new_cols * 2);
> + scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2));
>   vc->vc_y += logo_lines;
>   vc->vc_pos += logo_lines * vc->vc_size_row;
>   kfree(save);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] video: fbdev: amifb: add FIXME about dead APUS support

[Bartlomiej Zolnierkiewicz]

On 6/2/20 2:03 PM, Geert Uytterhoeven wrote:
> On Tue, Jun 2, 2020 at 1:50 PM Bartlomiej Zolnierkiewicz
>  wrote:
>> On 5/14/20 10:21 PM, Geert Uytterhoeven wrote:
>>> These #ifdefs are relics from APUS (Amiga Power-Up System), which
>>> added a PPC board.  APUS support was killed off a long time ago,
>>> when arch/ppc/ was still king, but these #ifdefs were missed, because
>>> they didn't test for CONFIG_APUS.
>>
>> Add FIXME about using the C code variants (APUS ones) in the future.
>>
>> Reported-by: Al Viro 
>> Reported-by: Geert Uytterhoeven 
>> Signed-off-by: Bartlomiej Zolnierkiewicz 
> 
> Reviewed-by: Geert Uytterhoeven 

Applied to drm-misc-next tree.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: savage: fix memory leak on error handling path in probe

[Bartlomiej Zolnierkiewicz]

On 6/19/20 6:21 PM, Evgeny Novikov wrote:
> savagefb_probe() calls savage_init_fb_info() that can successfully
> allocate memory for info->pixmap.addr but then fail when
> fb_alloc_cmap() fails. savagefb_probe() goes to label failed_init and
> does not free allocated memory. It is not valid to go to label
> failed_mmio since savage_init_fb_info() can fail during memory
> allocation as well. So, the patch free allocated memory on the error
> handling path in savage_init_fb_info() itself.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Evgeny Novikov 

Applied to drm-misc-next tree, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/video/fbdev/savage/savagefb_driver.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/video/fbdev/savage/savagefb_driver.c 
> b/drivers/video/fbdev/savage/savagefb_driver.c
> index 3c8ae87f0ea7..3fd87aeb6c79 100644
> --- a/drivers/video/fbdev/savage/savagefb_driver.c
> +++ b/drivers/video/fbdev/savage/savagefb_driver.c
> @@ -2157,6 +2157,8 @@ static int savage_init_fb_info(struct fb_info *info, 
> struct pci_dev *dev,
>   info->flags |= FBINFO_HWACCEL_COPYAREA |
>  FBINFO_HWACCEL_FILLRECT |
>  FBINFO_HWACCEL_IMAGEBLIT;
> + else
> + kfree(info->pixmap.addr);
>   }
>  #endif
>   return err;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omapfb: dss: Fix max fclk divider for omap36xx

[Bartlomiej Zolnierkiewicz]

On 6/30/20 8:26 PM, Adam Ford wrote:
> The drm/omap driver was fixed to correct an issue where using a
> divider of 32 breaks the DSS despite the TRM stating 32 is a valid
> number.  Through experimentation, it appears that 31 works, and
> it is consistent with the value used by the drm/omap driver.
> 
> This patch fixes the divider for fbdev driver instead of the drm.
> 
> Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
> 
> Cc:  #4.9+
> Signed-off-by: Adam Ford 

Applied to drm-misc-next tree, thanks.

(I marked patch as applicable to stable 4.5+ while merging)

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
> Linux 4.4 will need a similar patch, but it doesn't apply cleanly.
> 
> The DRM version of this same fix is:
> e2c4ed148cf3 ("drm/omap: fix max fclk divider for omap36xx")
> 
> 
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c 
> b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> index 7252d22dd117..bfc5c4c5a26a 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> @@ -833,7 +833,7 @@ static const struct dss_features omap34xx_dss_feats = {
>  };
>  
>  static const struct dss_features omap3630_dss_feats = {
> - .fck_div_max=   32,
> + .fck_div_max=   31,
>   .dss_fck_multiplier =   1,
>   .parent_clk_name=   "dpll4_ck",
>   .dpi_select_source  =   &dss_dpi_select_source_omap2_omap3,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bartlomiej Zolnierkiewicz]

On 6/20/20 1:27 PM, Sam Ravnborg wrote:
> Hi Gustavo.
> 
> On Wed, Jun 17, 2020 at 12:56:47PM -0500, Gustavo A. R. Silva wrote:
>> Make use of the struct_size() helper instead of an open-coded version
>> in order to avoid any potential type mistakes.
>>
>> This code was detected with the help of Coccinelle and, audited and
>> fixed manually.
>>
>> Signed-off-by: Gustavo A. R. Silva 
> 
> struct_size is defined in overflow.h - which is not included by fs.h.
> So we rely on overflow.h being pulled in by some other header - maybe
> slab.h in this case.
> Seems fragile, should this patch add an include of overflow.h?

$ git grep struct_size drivers/|wc -l
697

$ git grep overflow\\.h drivers/|wc -l
8

$ git grep overflow\\.h include/linux/
include/linux/device.h:#include 
include/linux/mm.h:#include 
include/linux/slab.h:#include 
include/linux/vmalloc.h:#include 

so I've applied the patch as it is (hoping that the issue is so
widespread that no-one tries to remove overflow.h from slab.h
without fixing drivers at the same time)..

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

>   Sam
> 
>> ---
>>  include/linux/fb.h | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/fb.h b/include/linux/fb.h
>> index 3b4b2f0c6994..2b530e6d86e4 100644
>> --- a/include/linux/fb.h
>> +++ b/include/linux/fb.h
>> @@ -506,8 +506,9 @@ struct fb_info {
>>  };
>>  
>>  static inline struct apertures_struct *alloc_apertures(unsigned int 
>> max_num) {
>> -struct apertures_struct *a = kzalloc(sizeof(struct apertures_struct)
>> -+ max_num * sizeof(struct aperture), GFP_KERNEL);
>> +struct apertures_struct *a;
>> +
>> +a = kzalloc(struct_size(a, ranges, max_num), GFP_KERNEL);
>>  if (!a)
>>  return NULL;
>>  a->count = max_num;
>> -- 
>> 2.27.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://protect2.fireeye.com/url?k=7bae4d09-26604cda-7bafc646-000babff317b-7eab3a2caa4b8b73&q=1&u=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel

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

Re: [PATCH] video: fbdev: neofb: fix memory leak in neo_scan_monitor()

[Bartlomiej Zolnierkiewicz]

On 6/30/20 9:54 PM, Evgeny Novikov wrote:
> neofb_probe() calls neo_scan_monitor() that can successfully allocate a
> memory for info->monspecs.modedb and proceed to case 0x03. There it does
> not free the memory and returns -1. neofb_probe() goes to label
> err_scan_monitor, thus, it does not free this memory through calling
> fb_destroy_modedb() as well. We can not go to label err_init_hw since
> neo_scan_monitor() can fail during memory allocation. So, the patch frees
> the memory directly for case 0x03.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Evgeny Novikov 

Applied to drm-misc-next tree, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/video/fbdev/neofb.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/video/fbdev/neofb.c b/drivers/video/fbdev/neofb.c
> index f5a676bfd67a..09a20d4ab35f 100644
> --- a/drivers/video/fbdev/neofb.c
> +++ b/drivers/video/fbdev/neofb.c
> @@ -1819,6 +1819,7 @@ static int neo_scan_monitor(struct fb_info *info)
>  #else
>   printk(KERN_ERR
>  "neofb: Only 640x480, 800x600/480 and 1024x768 panels 
> are currently supported\n");
> + kfree(info->monspecs.modedb);
>   return -1;
>  #endif
>   default:
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omapfb: fix multiple reference count leaks due to pm_runtime_get_sync

[Bartlomiej Zolnierkiewicz]

On 6/14/20 5:05 AM, Aditya Pakki wrote:
> On calling pm_runtime_get_sync() the reference count of the device
> is incremented. In case of failure, decrement the
> reference count before returning the error.
> 
> Signed-off-by: Aditya Pakki 

Applied to drm-misc-next tree, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 7 +--
>  drivers/video/fbdev/omap2/omapfb/dss/dsi.c   | 7 +--
>  drivers/video/fbdev/omap2/omapfb/dss/dss.c   | 7 +--
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 5 +++--
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 5 +++--
>  drivers/video/fbdev/omap2/omapfb/dss/venc.c  | 7 +--
>  6 files changed, 26 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c 
> b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> index 4a16798b2ecd..e2b572761bf6 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> @@ -520,8 +520,11 @@ int dispc_runtime_get(void)
>   DSSDBG("dispc_runtime_get\n");
>  
>   r = pm_runtime_get_sync(&dispc.pdev->dev);
> - WARN_ON(r < 0);
> - return r < 0 ? r : 0;
> + if (WARN_ON(r < 0)) {
> + pm_runtime_put_sync(&dispc.pdev->dev);
> + return r;
> + }
> + return 0;
>  }
>  EXPORT_SYMBOL(dispc_runtime_get);
>  
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c 
> b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> index d620376216e1..6f9c25fec994 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> @@ -1137,8 +1137,11 @@ static int dsi_runtime_get(struct platform_device 
> *dsidev)
>   DSSDBG("dsi_runtime_get\n");
>  
>   r = pm_runtime_get_sync(&dsi->pdev->dev);
> - WARN_ON(r < 0);
> - return r < 0 ? r : 0;
> + if (WARN_ON(r < 0)) {
> + pm_runtime_put_sync(&dsi->pdev->dev);
> + return r;
> + }
> + return 0;
>  }
>  
>  static void dsi_runtime_put(struct platform_device *dsidev)
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c 
> b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> index 7252d22dd117..3586579c838f 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> @@ -768,8 +768,11 @@ int dss_runtime_get(void)
>   DSSDBG("dss_runtime_get\n");
>  
>   r = pm_runtime_get_sync(&dss.pdev->dev);
> - WARN_ON(r < 0);
> - return r < 0 ? r : 0;
> + if (WARN_ON(r < 0)) {
> + pm_runtime_put_sync(&dss.pdev->dev);
> + return r;
> + }
> + return 0;
>  }
>  
>  void dss_runtime_put(void)
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c 
> b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> index 7060ae56c062..4804aab34298 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> @@ -39,9 +39,10 @@ static int hdmi_runtime_get(void)
>   DSSDBG("hdmi_runtime_get\n");
>  
>   r = pm_runtime_get_sync(&hdmi.pdev->dev);
> - WARN_ON(r < 0);
> - if (r < 0)
> + if (WARN_ON(r < 0)) {
> + pm_runtime_put_sync(&hdmi.pdev->dev);
>   return r;
> + }
>  
>   return 0;
>  }
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c 
> b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
> index ac49531e4732..a06b6f1355bd 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
> @@ -43,9 +43,10 @@ static int hdmi_runtime_get(void)
>   DSSDBG("hdmi_runtime_get\n");
>  
>   r = pm_runtime_get_sync(&hdmi.pdev->dev);
> - WARN_ON(r < 0);
> - if (r < 0)
> + if (WARN_ON(r < 0)) {
> + pm_runtime_put_sync(&hdmi.pdev->dev);
>   return r;
> + }
>  
>   return 0;
>  }
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c 
> b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> index d5404d56c922..0b0ad20afd63 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> @@ -348,8 +348,11 @@ static int venc_runtime_get(void)
>   DSSDBG("venc_runtime_get\n");
>  
>   r = pm_runtime_get_sync(&venc.pdev->dev);
> - WARN_ON(r < 0);
> - return r < 0 ? r : 0;
> + if (WARN_ON(r < 0)) {
> + pm_runtime_put_sync(&venc.pdev->dev);
> + return r;
> + }
> + return 0;
>  }
>  
>  static void venc_runtime_put(void)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel