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

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

--- Comment #30 from mn...@protonmail.com ---
I've been looking at this bug for a while now and I'll try to share what I've
found about it.

In some conditions, when amdgpu_dm_atomic_commit_tail calls
dm_atomic_get_new_state, dm_atomic_get_new_state returns a struct
dm_atomic_state* with an garbage context pointer.

I've also found that this bug exclusively occurs when commit_work is on the
workqueue. After forcing drm_atomic_helper_commit to run all of the commits
without adding to the workqueue and running the OS, the issue seems to have
disappeared. The system was stable for at least 1.5 hours before I manually
shut it down (meanwhile it has usually crashed within 30-45 minutes).

Perhaps there's some sort of race condition occurring after commit_work is
queued?

-- 
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] fbtft-bus.c: Removing that prohibited space before ')'

2020-06-27 Thread kernel test robot
Hi K,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v5.8-rc2 next-20200626]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/B-K-Karthik/fbtft-bus-c-Removing-that-prohibited-space-before/20200627-125315
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
92cd1b5d65f5c67147c7da39a3c2ad7e6ff81027
config: x86_64-randconfig-r015-20200628 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
a43b99a1e38e2beffb68a6db93f216f511e7fd41)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All errors (new ones prefixed by >>):

>> drivers/staging/fbtft/fbtft-bus.c:65:53: error: too few arguments provided 
>> to function-like macro invocation
   define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
   ^
   drivers/staging/fbtft/fbtft-bus.c:14:9: note: macro 'define_fbtft_write_reg' 
defined here
   #define define_fbtft_write_reg(func, buffer_type, data_type, modifier)   
 \
   ^
>> drivers/staging/fbtft/fbtft-bus.c:65:1: error: unknown type name 
>> 'define_fbtft_write_reg'
   define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
   ^
   drivers/staging/fbtft/fbtft-bus.c:67:57: error: too few arguments provided 
to function-like macro invocation
   define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
   ^
   drivers/staging/fbtft/fbtft-bus.c:14:9: note: macro 'define_fbtft_write_reg' 
defined here
   #define define_fbtft_write_reg(func, buffer_type, data_type, modifier)   
 \
   ^
   drivers/staging/fbtft/fbtft-bus.c:67:1: error: unknown type name 
'define_fbtft_write_reg'
   define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
   ^
>> drivers/staging/fbtft/fbtft-bus.c:86:3: error: non-void function 
>> 'fbtft_write_reg8_bus9' should return a value [-Wreturn-type]
   return;
   ^
   drivers/staging/fbtft/fbtft-bus.c:109:3: error: non-void function 
'fbtft_write_reg8_bus9' should return a value [-Wreturn-type]
   return;
   ^
   6 errors generated.

vim +65 drivers/staging/fbtft/fbtft-bus.c

64  
  > 65  define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
66  define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
  > 67  define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
68  
69  void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
70  {
71  va_list args;
72  int i, ret;
73  int pad = 0;
74  u16 *buf = (u16 *)par->buf;
75  
76  if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) {
77  va_start(args, len);
78  for (i = 0; i < len; i++)
79  *(((u8 *)buf) + i) = (u8)va_arg(args, unsigned 
int);
80  va_end(args);
81  fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
82par->info->device, u8, buf, len, "%s: 
",
83__func__);
84  }
85  if (len <= 0)
  > 86  return;
87  
88  if (par->spi && (par->spi->bits_per_word == 8)) {
89  /* we're emulating 9-bit, pad start of buffer with 
no-ops
90   * (assuming here that zero is a no-op)
91   */
92  pad = (len % 4) ? 4 - (len % 4) : 0;
93  for (i = 0; i < pad; i++)
94  *buf++ = 0x000;
95  }
96  
97  va_start(args, len);
98  *buf++ = (u8)va_arg(args, unsigned int);
99  i = len - 1;
   100  while (i--) {
   101  *buf = (u8)va_arg(args, unsigned int);
   102  *buf++ |= 0x100; /* dc=1 */
   103  }
   104  va_end(args);
   105  ret = par->fbtftops.write(par, par->buf, (len + pad) * 
sizeof(u16));
   106  if (ret < 0) {
   107  dev_err(par->info->device,
   108

[PATCH] drm: gma500: Convert to GPIO descriptors

2020-06-27 Thread Linus Walleij
Finalize he conversion of GMA500 to use only GPIO descriptors.
The GPIO look-up-table is associated with the device directly
in the GMA500 Medfield chip driver since no explicit platform
type device (such as in x86/platform/intel-mid) exists: the
GMA500 probes directly from the PCI device. Apparently GPIOs
88 and 34 are used on all of these so just go ahead and
register those for resetting the DSI pipes.

Cc: Patrik Jakobsson 
Signed-off-by: Linus Walleij 
---
 drivers/gpu/drm/gma500/mdfld_device.c | 20 +
 drivers/gpu/drm/gma500/mdfld_dsi_dpi.c|  2 +-
 drivers/gpu/drm/gma500/mdfld_dsi_output.c | 51 ---
 drivers/gpu/drm/gma500/mdfld_dsi_output.h |  2 +-
 drivers/gpu/drm/gma500/mdfld_output.h |  2 +-
 drivers/gpu/drm/gma500/psb_intel_drv.h|  1 -
 6 files changed, 49 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_device.c 
b/drivers/gpu/drm/gma500/mdfld_device.c
index b718efccdcf2..be9cf6b1e3b3 100644
--- a/drivers/gpu/drm/gma500/mdfld_device.c
+++ b/drivers/gpu/drm/gma500/mdfld_device.c
@@ -6,6 +6,7 @@
  **/
 
 #include 
+#include 
 
 #include 
 
@@ -505,12 +506,31 @@ static const struct psb_offset mdfld_regmap[3] = {
},
 };
 
+/*
+ * The GPIO lines for resetting DSI pipe 0 and 2 are available in the
+ * PCI device :00:0c.0 on the Medfield.
+ */
+static struct gpiod_lookup_table mdfld_dsi_pipe_gpio_table = {
+   .table  = {
+   GPIO_LOOKUP(":00:0c.0", 128, "dsi-pipe0-reset",
+   GPIO_ACTIVE_HIGH),
+   GPIO_LOOKUP(":00:0c.0", 34, "dsi-pipe2-reset",
+   GPIO_ACTIVE_HIGH),
+   { },
+   },
+};
+
 static int mdfld_chip_setup(struct drm_device *dev)
 {
struct drm_psb_private *dev_priv = dev->dev_private;
if (pci_enable_msi(dev->pdev))
dev_warn(dev->dev, "Enabling MSI failed!\n");
dev_priv->regmap = mdfld_regmap;
+
+   /* Associate the GPIO lines with the DRM device */
+   mdfld_dsi_pipe_gpio_table.dev_id = dev_name(dev->dev);
+   gpiod_add_lookup_table(_dsi_pipe_gpio_table);
+
return mid_chip_setup(dev);
 }
 
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
index c976a9dd9240..ae1223f631a7 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
@@ -955,7 +955,7 @@ struct mdfld_dsi_encoder *mdfld_dsi_dpi_init(struct 
drm_device *dev,
 
/* panel hard-reset */
if (p_funcs->reset) {
-   ret = p_funcs->reset(pipe);
+   ret = p_funcs->reset(dev, pipe);
if (ret) {
DRM_ERROR("Panel %d hard-reset failed\n", pipe);
return NULL;
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index f350ac1ead18..c9478261964a 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -432,42 +433,42 @@ static int mdfld_dsi_get_default_config(struct drm_device 
*dev,
return 0;
 }
 
-int mdfld_dsi_panel_reset(int pipe)
+int mdfld_dsi_panel_reset(struct drm_device *ddev, int pipe)
 {
-   unsigned gpio;
-   int ret = 0;
-
+   struct device *dev = ddev->dev;
+   struct gpio_desc *gpiod;
+
+   /*
+* Raise the GPIO reset line for the corresponding pipe to HIGH,
+* this is probably because it is active low so this takes the
+* respective pipe out of reset. (We have no code to put it back
+* into reset in this driver.)
+*/
switch (pipe) {
case 0:
-   gpio = 128;
+   gpiod = gpiod_get(dev, "dsi-pipe0-reset", GPIOD_OUT_HIGH);
+   if (IS_ERR(gpiod))
+   return PTR_ERR(gpiod);
break;
case 2:
-   gpio = 34;
+   gpiod = gpiod_get(dev, "dsi-pipe2-reset", GPIOD_OUT_HIGH);
+   if (IS_ERR(gpiod))
+   return PTR_ERR(gpiod);
break;
default:
-   DRM_ERROR("Invalid output\n");
+   DRM_DEV_ERROR(dev, "Invalid output pipe\n");
return -EINVAL;
}
+   gpiod_put(gpiod);
 
-   ret = gpio_request(gpio, "gfx");
-   if (ret) {
-   DRM_ERROR("gpio_rqueset failed\n");
-   return ret;
-   }
-
-   ret = gpio_direction_output(gpio, 1);
-   if (ret) {
-   DRM_ERROR("gpio_direction_output failed\n");
-   goto gpio_error;
-   }
+   /* Always read the pipe0 GPIO line, FIXME: explain why! */
+   gpiod = gpiod_get(dev, "dsi-pipe0-reset", GPIOD_ASIS);
+   if (IS_ERR(gpiod))
+   

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

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

zzyx...@gmail.com changed:

   What|Removed |Added

 CC||zzyx...@gmail.com

--- Comment #29 from zzyx...@gmail.com ---
Just hit this on Archlinux with linux-5.7.6 on a Vega 64. So far I've had three
crashes mostly occuring within the first few minutes of uptime. I'm not running
kwin or chrome, just a light window manager (bspwm) and compton.

During the first two, steam's fossilize was running which lead me to suspect it
was triggered by an interaction with that. However the third crashed before I
even managed to start steam, so either I'm just lucky or my system is good at
triggering this. @Duncan I'm not sure if you want to muddle your bisect results
with a different system configuration, but I'm happy to help test commits if
that would be helpful.

I've noticed the call traces reported in the kernel log are slightly different
for each crash; I'm not sure if they're likely to be useful or not. Here's at
least the one from my first crash:

Jun 27 14:04:40 erebor kernel: general protection fault, probably for
non-canonical address 0x5dda9795528973db:  [#1] PREEMPT SMP NOPTI
Jun 27 14:04:40 erebor kernel: CPU: 14 PID: 193610 Comm: kworker/u32:14
Tainted: G   OE 5.7.6-arch1-1 #1
Jun 27 14:04:40 erebor kernel: Hardware name: To Be Filled By O.E.M. To Be
Filled By O.E.M./AB350 Pro4, BIOS P4.90 06/14/2018
Jun 27 14:04:40 erebor kernel: Workqueue: events_unbound commit_work
[drm_kms_helper]
Jun 27 14:04:40 erebor kernel: RIP:
0010:amdgpu_dm_atomic_commit_tail+0x2aa/0x2310 [amdgpu]
Jun 27 14:04:40 erebor kernel: Code: 4f 08 8b 81 e0 02 00 00 41 83 c5 01 44 39
e8 0f 87 46 ff ff ff 48 83 bd f0 fc ff ff 00 0f 84 03 01 00 00 48 8b bd f0 fc
ff ff <80> bf b0 01 00 00 01 0f 86 ac 00 00>
Jun 27 14:04:40 erebor kernel: RSP: 0018:bcec0a4afaf8 EFLAGS: 00010206
Jun 27 14:04:40 erebor kernel: RAX: 0006 RBX: 9b71dbaed000 RCX:
9b7472e4b800
Jun 27 14:04:40 erebor kernel: RDX: 9b72504ea400 RSI: c13181e0 RDI:
5dda9795528973db
Jun 27 14:04:40 erebor kernel: RBP: bcec0a4afe60 R08: 0001 R09:
0001
Jun 27 14:04:40 erebor kernel: R10: 0082 R11: 000730e2 R12:

Jun 27 14:04:40 erebor kernel: R13: 0006 R14: 9b71dbaed800 R15:
9b71a8fdb580
Jun 27 14:04:40 erebor kernel: FS:  ()
GS:9b747ef8() knlGS:
Jun 27 14:04:40 erebor kernel: CS:  0010 DS:  ES:  CR0:
80050033
Jun 27 14:04:40 erebor kernel: CR2: 56460ce164b0 CR3: 000341c86000 CR4:
003406e0
Jun 27 14:04:40 erebor kernel: Call Trace:
Jun 27 14:04:40 erebor kernel:  ? __erst_read+0x160/0x1d0
Jun 27 14:04:40 erebor kernel:  ? __switch_to_asm+0x34/0x70
Jun 27 14:04:40 erebor kernel:  ? __switch_to_asm+0x40/0x70
Jun 27 14:04:40 erebor kernel:  ? __switch_to_asm+0x34/0x70
Jun 27 14:04:40 erebor kernel:  ? __switch_to_asm+0x40/0x70
Jun 27 14:04:40 erebor kernel:  ? rescuer_thread+0x3f0/0x3f0
Jun 27 14:04:40 erebor kernel:  commit_tail+0x94/0x130 [drm_kms_helper]
Jun 27 14:04:40 erebor kernel:  process_one_work+0x1da/0x3d0
Jun 27 14:04:40 erebor kernel:  ? rescuer_thread+0x3f0/0x3f0
Jun 27 14:04:40 erebor kernel:  worker_thread+0x4d/0x3e0
Jun 27 14:04:40 erebor kernel:  ? rescuer_thread+0x3f0/0x3f0
Jun 27 14:04:40 erebor kernel:  kthread+0x13e/0x160
Jun 27 14:04:40 erebor kernel:  ? __kthread_bind_mask+0x60/0x60
Jun 27 14:04:40 erebor kernel:  ret_from_fork+0x22/0x40
Jun 27 14:04:40 erebor kernel: Modules linked in: snd_seq_midi snd_seq_dummy
snd_seq_midi_event snd_hrtimer snd_seq fuse ccm 8021q garp mrp stp llc
snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_de>
Jun 27 14:04:40 erebor kernel:  blake2b_generic libcrc32c crc32c_generic xor
uas usb_storage raid6_pq crc32c_intel xhci_pci xhci_hcd
Jun 27 14:04:40 erebor kernel: ---[ end trace cb5c0d96dd991657 ]---
Jun 27 14:04:40 erebor kernel: RIP:
0010:amdgpu_dm_atomic_commit_tail+0x2aa/0x2310 [amdgpu]
Jun 27 14:04:40 erebor kernel: Code: 4f 08 8b 81 e0 02 00 00 41 83 c5 01 44 39
e8 0f 87 46 ff ff ff 48 83 bd f0 fc ff ff 00 0f 84 03 01 00 00 48 8b bd f0 fc
ff ff <80> bf b0 01 00 00 01 0f 86 ac 00 00>
Jun 27 14:04:40 erebor kernel: RSP: 0018:bcec0a4afaf8 EFLAGS: 00010206
Jun 27 14:04:40 erebor kernel: RAX: 0006 RBX: 9b71dbaed000 RCX:
9b7472e4b800
Jun 27 14:04:40 erebor kernel: RDX: 9b72504ea400 RSI: c13181e0 RDI:
5dda9795528973db
Jun 27 14:04:40 erebor kernel: RBP: bcec0a4afe60 R08: 0001 R09:
0001
Jun 27 14:04:40 erebor kernel: R10: 0082 R11: 000730e2 R12:

Jun 27 14:04:40 erebor kernel: R13: 0006 R14: 9b71dbaed800 R15:
9b71a8fdb580
Jun 27 14:04:40 erebor kernel: FS:  ()
GS:9b747ef8() 

Re: [PATCH] drm: gma500: Drop surplus include

2020-06-27 Thread Linus Walleij
On Sat, Jun 27, 2020 at 10:07 PM Patrik Jakobsson
 wrote:
> On Sat, Jun 27, 2020 at 12:01 AM Linus Walleij  
> wrote:
> >
> > This file includes  but does not use any
> > symbols from it, drop the include.
>
> Hi Linus,
> Seems the include should be moved to mdfld_dsi_output.c instead.

Yeah we are in include file hell :/

I'll figure it out.

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


Re: [PATCH v1 2/2] drm/panel-simple: Add missing BUS descriptions for some panels

2020-06-27 Thread Laurent Pinchart
Hi Dmitry,

Thank you for the patch.

On Mon, Jun 22, 2020 at 01:27:42AM +0300, Dmitry Osipenko wrote:
> This patch adds missing BUS fields to the display panel descriptions of
> the panels which are found on NVIDIA Tegra devices:
> 
>   1. AUO B101AW03
>   2. Chunghwa CLAA070WP03XG
>   3. Chunghwa CLAA101WA01A
>   4. Chunghwa CLAA101WB01
>   5. Innolux N156BGE L21
>   6. Samsung LTN101NT05
> 
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 87edd2bdf09a..986df9937650 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -698,6 +698,8 @@ static const struct panel_desc auo_b101aw03 = {
>   .width = 223,
>   .height = 125,
>   },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,

Does DRM_BUS_FLAG_PIXDATA_DRIVE_* make sense for LVDS ?

The rest looks good, except the Samsung panel for which I haven't been
able to locate a datasheet.

Reviewed-by: Laurent Pinchart 

>   .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
> @@ -1352,6 +1354,8 @@ static const struct panel_desc chunghwa_claa070wp03xg = 
> {
>   .width = 94,
>   .height = 150,
>   },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
>   .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
> @@ -1375,6 +1379,8 @@ static const struct panel_desc chunghwa_claa101wa01a = {
>   .width = 220,
>   .height = 120,
>   },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
>   .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
> @@ -1398,6 +1404,8 @@ static const struct panel_desc chunghwa_claa101wb01 = {
>   .width = 223,
>   .height = 125,
>   },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
>   .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
> @@ -2071,6 +2079,8 @@ static const struct panel_desc innolux_n156bge_l21 = {
>   .width = 344,
>   .height = 193,
>   },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
>   .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  
> @@ -3018,6 +3028,8 @@ static const struct panel_desc samsung_ltn101nt05 = {
>   .width = 223,
>   .height = 125,
>   },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
>   .connector_type = DRM_MODE_CONNECTOR_LVDS,
>  };
>  

-- 
Regards,

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


Re: [PATCH v1 0/2] Improve descriptions of a few simple-panels

2020-06-27 Thread Sam Ravnborg
On Mon, Jun 22, 2020 at 01:27:40AM +0300, Dmitry Osipenko wrote:
> Hello,
> 
> This is a follow up to [1], which was already applied to drm-misc and then
> Laurent Pinchart spotted some problems. This series addresses those problems.
> 
> [1] 
> https://patchwork.ozlabs.org/project/linux-tegra/patch/20200617222703.17080-8-dig...@gmail.com/
> 
> Dmitry Osipenko (2):
>   drm/panel-simple: Correct EDT ET057090DHU connector type
>   drm/panel-simple: Add missing BUS descriptions for some panels

Thanks for the quick fixes, both are now applied to drm-misc-next.

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


Re: [PATCH v2 6/6] drm/msm/a6xx: Add support for per-instance pagetables

2020-06-27 Thread Rob Clark
On Sat, Jun 27, 2020 at 12:56 PM Rob Clark  wrote:
>
> On Fri, Jun 26, 2020 at 1:04 PM Jordan Crouse  wrote:
> >
> > Add support for using per-instance pagetables if all the dependencies are
> > available.
> >
> > Signed-off-by: Jordan Crouse 
> > ---
> >
> >  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 43 +++
> >  drivers/gpu/drm/msm/msm_ringbuffer.h  |  1 +
> >  2 files changed, 44 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
> > b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > index aa53f47b7e8b..95ed2ceac121 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > @@ -79,6 +79,34 @@ static void get_stats_counter(struct msm_ringbuffer 
> > *ring, u32 counter,
> > OUT_RING(ring, upper_32_bits(iova));
> >  }
> >
> > +static void a6xx_set_pagetable(struct msm_gpu *gpu, struct msm_ringbuffer 
> > *ring,
> > +   struct msm_file_private *ctx)
> > +{
> > +   phys_addr_t ttbr;
> > +   u32 asid;
> > +
> > +   if (msm_iommu_pagetable_params(ctx->aspace->mmu, , ))
> > +   return;
> > +
> > +   /* Execute the table update */
> > +   OUT_PKT7(ring, CP_SMMU_TABLE_UPDATE, 4);
> > +   OUT_RING(ring, lower_32_bits(ttbr));
> > +   OUT_RING(ring, (((u64) asid) << 48) | upper_32_bits(ttbr));
> > +   /* CONTEXTIDR is currently unused */
> > +   OUT_RING(ring, 0);
> > +   /* CONTEXTBANK is currently unused */
> > +   OUT_RING(ring, 0);
> > +
> > +   /*
> > +* Write the new TTBR0 to the memstore. This is good for debugging.
> > +*/
> > +   OUT_PKT7(ring, CP_MEM_WRITE, 4);
> > +   OUT_RING(ring, lower_32_bits(rbmemptr(ring, ttbr0)));
> > +   OUT_RING(ring, upper_32_bits(rbmemptr(ring, ttbr0)));
> > +   OUT_RING(ring, lower_32_bits(ttbr));
> > +   OUT_RING(ring, (((u64) asid) << 48) | upper_32_bits(ttbr));
> > +}
> > +
> >  static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> > struct msm_file_private *ctx)
> >  {
> > @@ -89,6 +117,8 @@ static void a6xx_submit(struct msm_gpu *gpu, struct 
> > msm_gem_submit *submit,
> > struct msm_ringbuffer *ring = submit->ring;
> > unsigned int i;
> >
> > +   a6xx_set_pagetable(gpu, ring, ctx);
> > +
> > get_stats_counter(ring, REG_A6XX_RBBM_PERFCTR_CP_0_LO,
> > rbmemptr_stats(ring, index, cpcycles_start));
> >
> > @@ -872,6 +902,18 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
> > return (unsigned long)busy_time;
> >  }
> >
> > +struct msm_gem_address_space *a6xx_address_space_instance(struct msm_gpu 
> > *gpu)
> > +{
> > +   struct msm_mmu *mmu;
> > +
> > +   mmu = msm_iommu_pagetable_create(gpu->aspace->mmu);
> > +   if (IS_ERR(mmu))
> > +   return msm_gem_address_space_get(gpu->aspace);
> > +
> > +   return msm_gem_address_space_create(mmu,
> > +   "gpu", 0x1ULL, 0x1ULL);
> > +}
> > +
> >  static const struct adreno_gpu_funcs funcs = {
> > .base = {
> > .get_param = adreno_get_param,
> > @@ -895,6 +937,7 @@ static const struct adreno_gpu_funcs funcs = {
> > .gpu_state_put = a6xx_gpu_state_put,
> >  #endif
> > .create_address_space = adreno_iommu_create_address_space,
> > +   .address_space_instance = a6xx_address_space_instance,
>
> Hmm, maybe instead of .address_space_instance, something like
> .create_context_address_space?
>
> Since like .create_address_space, it is creating an address space..
> the difference is that it is a per context/process aspace..
>


or maybe just .create_pgtable and return the 'struct msm_mmu' (which
is itself starting to become less of a great name)..

The only other thing a6xx_address_space_instance() adds is knowing
where the split is between the kernel and user pgtables, and I suppose
that isn't a thing that would really be changing between gens?

BR,
-R

> BR,
> -R
>
> > },
> > .get_timestamp = a6xx_get_timestamp,
> >  };
> > diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.h 
> > b/drivers/gpu/drm/msm/msm_ringbuffer.h
> > index 7764373d0ed2..0987d6bf848c 100644
> > --- a/drivers/gpu/drm/msm/msm_ringbuffer.h
> > +++ b/drivers/gpu/drm/msm/msm_ringbuffer.h
> > @@ -31,6 +31,7 @@ struct msm_rbmemptrs {
> > volatile uint32_t fence;
> >
> > volatile struct msm_gpu_submit_stats 
> > stats[MSM_GPU_SUBMIT_STATS_COUNT];
> > +   volatile u64 ttbr0;
> >  };
> >
> >  struct msm_ringbuffer {
> > --
> > 2.17.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: gma500: Drop surplus include

2020-06-27 Thread Patrik Jakobsson
On Sat, Jun 27, 2020 at 12:01 AM Linus Walleij  wrote:
>
> This file includes  but does not use any
> symbols from it, drop the include.

Hi Linus,
Seems the include should be moved to mdfld_dsi_output.c instead.

Thanks
Patrik

>
> Cc: Patrik Jakobsson 
> Signed-off-by: Linus Walleij 
> ---
>  drivers/gpu/drm/gma500/psb_intel_drv.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h 
> b/drivers/gpu/drm/gma500/psb_intel_drv.h
> index fb601983cef0..9221d1f545b0 100644
> --- a/drivers/gpu/drm/gma500/psb_intel_drv.h
> +++ b/drivers/gpu/drm/gma500/psb_intel_drv.h
> @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include "gma_display.h"
>
>  /*
> --
> 2.25.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 6/6] drm/msm/a6xx: Add support for per-instance pagetables

2020-06-27 Thread Rob Clark
On Fri, Jun 26, 2020 at 1:04 PM Jordan Crouse  wrote:
>
> Add support for using per-instance pagetables if all the dependencies are
> available.
>
> Signed-off-by: Jordan Crouse 
> ---
>
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 43 +++
>  drivers/gpu/drm/msm/msm_ringbuffer.h  |  1 +
>  2 files changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index aa53f47b7e8b..95ed2ceac121 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -79,6 +79,34 @@ static void get_stats_counter(struct msm_ringbuffer *ring, 
> u32 counter,
> OUT_RING(ring, upper_32_bits(iova));
>  }
>
> +static void a6xx_set_pagetable(struct msm_gpu *gpu, struct msm_ringbuffer 
> *ring,
> +   struct msm_file_private *ctx)
> +{
> +   phys_addr_t ttbr;
> +   u32 asid;
> +
> +   if (msm_iommu_pagetable_params(ctx->aspace->mmu, , ))
> +   return;
> +
> +   /* Execute the table update */
> +   OUT_PKT7(ring, CP_SMMU_TABLE_UPDATE, 4);
> +   OUT_RING(ring, lower_32_bits(ttbr));
> +   OUT_RING(ring, (((u64) asid) << 48) | upper_32_bits(ttbr));
> +   /* CONTEXTIDR is currently unused */
> +   OUT_RING(ring, 0);
> +   /* CONTEXTBANK is currently unused */
> +   OUT_RING(ring, 0);
> +
> +   /*
> +* Write the new TTBR0 to the memstore. This is good for debugging.
> +*/
> +   OUT_PKT7(ring, CP_MEM_WRITE, 4);
> +   OUT_RING(ring, lower_32_bits(rbmemptr(ring, ttbr0)));
> +   OUT_RING(ring, upper_32_bits(rbmemptr(ring, ttbr0)));
> +   OUT_RING(ring, lower_32_bits(ttbr));
> +   OUT_RING(ring, (((u64) asid) << 48) | upper_32_bits(ttbr));
> +}
> +
>  static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> struct msm_file_private *ctx)
>  {
> @@ -89,6 +117,8 @@ static void a6xx_submit(struct msm_gpu *gpu, struct 
> msm_gem_submit *submit,
> struct msm_ringbuffer *ring = submit->ring;
> unsigned int i;
>
> +   a6xx_set_pagetable(gpu, ring, ctx);
> +
> get_stats_counter(ring, REG_A6XX_RBBM_PERFCTR_CP_0_LO,
> rbmemptr_stats(ring, index, cpcycles_start));
>
> @@ -872,6 +902,18 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
> return (unsigned long)busy_time;
>  }
>
> +struct msm_gem_address_space *a6xx_address_space_instance(struct msm_gpu 
> *gpu)
> +{
> +   struct msm_mmu *mmu;
> +
> +   mmu = msm_iommu_pagetable_create(gpu->aspace->mmu);
> +   if (IS_ERR(mmu))
> +   return msm_gem_address_space_get(gpu->aspace);
> +
> +   return msm_gem_address_space_create(mmu,
> +   "gpu", 0x1ULL, 0x1ULL);
> +}
> +
>  static const struct adreno_gpu_funcs funcs = {
> .base = {
> .get_param = adreno_get_param,
> @@ -895,6 +937,7 @@ static const struct adreno_gpu_funcs funcs = {
> .gpu_state_put = a6xx_gpu_state_put,
>  #endif
> .create_address_space = adreno_iommu_create_address_space,
> +   .address_space_instance = a6xx_address_space_instance,

Hmm, maybe instead of .address_space_instance, something like
.create_context_address_space?

Since like .create_address_space, it is creating an address space..
the difference is that it is a per context/process aspace..

BR,
-R

> },
> .get_timestamp = a6xx_get_timestamp,
>  };
> diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.h 
> b/drivers/gpu/drm/msm/msm_ringbuffer.h
> index 7764373d0ed2..0987d6bf848c 100644
> --- a/drivers/gpu/drm/msm/msm_ringbuffer.h
> +++ b/drivers/gpu/drm/msm/msm_ringbuffer.h
> @@ -31,6 +31,7 @@ struct msm_rbmemptrs {
> volatile uint32_t fence;
>
> volatile struct msm_gpu_submit_stats 
> stats[MSM_GPU_SUBMIT_STATS_COUNT];
> +   volatile u64 ttbr0;
>  };
>
>  struct msm_ringbuffer {
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 00/27] Converter R-Car DU to the DRM bridge connector helper

2020-06-27 Thread Sam Ravnborg
Hi Liu,

thanks for the notice.

Laurent, I trust you will take a look and resolve this.

Sam

On Thu, Jun 25, 2020 at 04:48:01PM +0800, Liu Ying wrote:
> Hi Sam,
> 
> On Tue, 2020-06-23 at 20:55 +0200, Sam Ravnborg wrote:
> > Hi Laurent.
> > 
> > On Tue, May 26, 2020 at 04:14:38AM +0300, Laurent Pinchart wrote:
> > > Hello,
> > > 
> > > This patch series converts the R-Car DU driver to use the DRM
> > > bridge
> > > connector helper drm_bridge_connector_init().
> > > 
> > > The bulk of the series is conversion of the adv7511, simple-bridge,
> > > rcar-lbds and dw-hdmi drivers to make connector creation optional
> > > (through the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag).
> > > 
> > > The series starts with the adv7511 driver, previously posted as
> > > "[PATCH
> > > 0/4] drm: bridge: adv7511: Enable usage with DRM bridge connector
> > > helper" ([1]). Patches 01/27 to 04/27 incorporate all the received
> > > review comments.
> > > 
> > > The next three patches address the simple-bridge driver, previously
> > > posted as "[PATCH 0/2] drm: bridge: simple-bridge: Enable usage
> > > with DRM
> > > bridge connector helper". Patch 05/27 is an additional fix that
> > > stems
> > > from the review, and patches 06/27 and 07/27 incorporate all the
> > > received review comments.
> > > 
> > > Patch 08/27 is a new patch that addresses the rcar-lvds driver.
> > > Instead
> > > of implementing direct support for DRM_BRIDGE_ATTACH_NO_CONNECTOR,
> > > it
> > > simply removes code that shouldn't have been in the driver in the
> > > first
> > > place by switching to the panel bridge helper.
> > > 
> > > Patches 09/27 to 22/27 then address the dw-hdmi driver. That's a
> > > more
> > > sizeable rework, due to the fact that the driver implements a mid-
> > > layer
> > > for platform-specific glue, with the internal drm_connector being
> > > used
> > > throughout the whole code. There's no rocket science there, but
> > > patch
> > > 10/27 should be noted for adding a new argument to the
> > > drm_bridge_funcs.mode_valid() function. Please see individual
> > > patches
> > > for details.
> > > 
> > > Patch 23/27 adds support to the dw-hdmi driver to attach to a
> > > downstream
> > > bridge if one is specified in DT. As the DT port number
> > > corresponding to
> > > the video output differs between platforms that integrate the dw-
> > > hdmi
> > > (some of them even don't have a video output port, which should
> > > probably
> > > be fixed, but that's out of scope for this series), the port number
> > > has
> > > to be specified by the platform glue layer. Patch 24/27 does so for
> > > the
> > > R-Car dw-hdmi driver.
> > > 
> > > Patch 25/27 is a drive-by fix for an error path issue in the rcar-
> > > du
> > > driver. Patch 26/27 finally makes use of the
> > > drm_bridge_connector_init()
> > > helper.
> > > 
> > > Unfortunately, this breaks the VGA output on R-Car Gen3 platforms.
> > > On
> > > those platforms, the VGA DDC lines are not connected, and there is
> > > no
> > > mean for software to detect the VGA output connection status. When
> > > the
> > > simple-bridge driver creates a connector, it automatically adds
> > > default
> > > modes when no DDC is available. This behavious is also present int
> > > the
> > > DRM probe helper drm_helper_probe_single_connector_modes(), but
> > > only
> > > when the connector status is connector_status_connected. As the
> > > driver
> > > (rightfully) reports connector_status_unconnected, no modes are
> > > added.
> > > Patch 27/27 fixes this issue by extending addition of default modes
> > > in
> > > drm_helper_probe_single_connector_modes() when the output status is
> > > unknown. An alternative approach would be to implement this
> > > behaviour in
> > > the bridge connector helper (drm_bridge_connector.c).
> > > 
> > > All the modified drivers have been compile-tested, and the series
> > > has
> > > been tested on a Renesas R-Car Salvator-XS board with the VGA, HDMI
> > > and
> > > LVDS outputs.
> > > 
> > > [1] 
> > > https://lore.kernel.org/dri-devel/20200409004610.12346-1-laurent.pinchart+rene...@ideasonboard.com/
> > > [2] 
> > > https://lore.kernel.org/dri-devel/20200409003636.11792-1-laurent.pinchart+rene...@ideasonboard.com/
> > 
> > As we briefly discussed on IRC the first 21 patches are now applied
> > to
> > drm-misc-next.
> 
> I see patch '[22/27] drm: bridge: dw-hdmi: Make connector creation
> optional' is applied to drm-misc-next.
> That patch would introduce an uninitialized mutex accessing issue as I
> mentioned in the patch[1]. And, the patch intends to fix the issue in
> the first place.
> 
> [1] https://patchwork.freedesktop.org/patch/370560/
> 
> 
> Regards,
> Liu Ying
> 
> > The rcar-du specific patches was left out and the last patch was
> > likewise not applied in this round- mostly because it was the coming
> > after several rcar-du patches and I was not sure if there was some
> > dependencies to consider.
> > 
> > With this set in we have more examples 

[RFC v8 9/9] drm/nouveau/kms/nvd9-: Add CRC support

2020-06-27 Thread Lyude Paul
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:

https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt

We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp" sources: outp-active/auto for a CRC of
the scanout region, outp-complete for a CRC of both the scanout and
blanking/sync region combined, and outp-inactive for a CRC of only the
blanking/sync region. For each source, nouveau selects the appropriate
tap point based on the output path in use. We also expose an "rg"
source, which allows for capturing CRCs of the scanout raster before
it's encoded into a video signal in the output path. This tap point is
referred to as the raster generator.

Note that while there's some other neat features that can be used with
CRC capture on nvidia hardware, like capturing from two CRC sources
simultaneously, I couldn't see any usecase for them and did not
implement them.

Nvidia only allows for accessing CRCs through a shared DMA region that
we program through the core EVO/NvDisplay channel which is referred to
as the notifier context. The notifier context is limited to either 255
(for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and
unfortunately the hardware simply drops CRCs and reports an overflow
once all available entries in the notifier context are filled.

Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit
on how many CRCs can be captured, we work around this in nouveau by
allocating two separate notifier contexts for each head instead of one.
We schedule a vblank worker ahead of time so that once we start getting
close to filling up all of the available entries in the notifier
context, we can swap the currently used notifier context out with
another pre-prepared notifier context in a manner similar to page
flipping.

Unfortunately, the hardware only allows us to this by flushing two
separate updates on the core channel: one to release the current
notifier context handle, and one to program the next notifier context's
handle. When the hardware processes the first update, the CRC for the
current frame is lost. However, the second update can be flushed
immediately without waiting for the first to complete so that CRC
generation resumes on the next frame. According to Nvidia's hardware
engineers, there isn't any cleaner way of flipping notifier contexts
that would avoid this.

Since using vblank workers to swap out the notifier context will ensure
we can usually flush both updates to hardware within the timespan of a
single frame, we can also ensure that there will only be exactly one
frame lost between the first and second update being executed by the
hardware. This gives us the guarantee that we're always correctly
matching each CRC entry with it's respective frame even after a context
flip. And since IGT will retrieve the CRC entry for a frame by waiting
until it receives a CRC for any subsequent frames, this doesn't cause an
issue with any tests and is much simpler than trying to change the
current DRM API to accommodate.

In order to facilitate testing of correct handling of this limitation,
we also expose a debugfs interface to manually control the threshold for
when we start trying to flip the notifier context. We will use this in
igt to trigger a context flip for testing purposes without needing to
wait for the notifier to completely fill up. This threshold is reset
to the default value set by nouveau after each capture, and is exposed
in a separate folder within each CRTC's debugfs directory labelled
"nv_crc".

Changes since v1:
* Forgot to finish saving crc.h before saving, whoops. This just adds
  some corrections to the empty function declarations that we use if
  CONFIG_DEBUG_FS isn't enabled.
Changes since v2:
* Don't check return code from debugfs_create_dir() or
  debugfs_create_file() - Greg K-H
Changes since v3:
  (no functional changes)
* Fix SPDX license identifiers (checkpatch)
* s/uint32_t/u32/ (checkpatch)
* Fix indenting in switch cases (checkpatch)
Changes since v4:
* Remove unneeded param changes with nv50_head_flush_clr/set
* Rebase
Changes since v5:
* Remove set but unused variable (outp) in nv50_crc_atomic_check() -
  Kbuild bot

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv04/crtc.c |  25 +-
 drivers/gpu/drm/nouveau/dispnv50/Kbuild |   4 +
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  20 +
 drivers/gpu/drm/nouveau/dispnv50/core.h |   4 +
 drivers/gpu/drm/nouveau/dispnv50/core907d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/core917d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/corec37d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/corec57d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/crc.c  | 714 
 drivers/gpu/drm/nouveau/dispnv50/crc.h  | 125 
 drivers/gpu/drm/nouveau/dispnv50/crc907d.c  | 139 
 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c  | 153 +
 

[RFC v8 8/9] drm/nouveau/kms/nv50-: Move hard-coded object handles into header

2020-06-27 Thread Lyude Paul
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just go ahead and move any hard-coded
handles into a single header. This is just to keep things slightly
organized, and to make it a little bit easier if we need to add more
handles in the future.

This patch should contain no functional changes.

Changes since v3:
* Correct SPDX license identifier (checkpatch)

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c|  7 +--
 drivers/gpu/drm/nouveau/dispnv50/handles.h | 15 +++
 drivers/gpu/drm/nouveau/dispnv50/wndw.c|  3 ++-
 3 files changed, 22 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/dispnv50/handles.h

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 090882794f7d6..bf7ba1e1c0f74 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -26,6 +26,7 @@
 #include "core.h"
 #include "head.h"
 #include "wndw.h"
+#include "handles.h"
 
 #include 
 #include 
@@ -154,7 +155,8 @@ nv50_dmac_create(struct nvif_device *device, struct 
nvif_object *disp,
if (!syncbuf)
return 0;
 
-   ret = nvif_object_init(>base.user, 0xf000, NV_DMA_IN_MEMORY,
+   ret = nvif_object_init(>base.user, NV50_DISP_HANDLE_SYNCBUF,
+  NV_DMA_IN_MEMORY,
   &(struct nv_dma_v0) {
.target = NV_DMA_V0_TARGET_VRAM,
.access = NV_DMA_V0_ACCESS_RDWR,
@@ -165,7 +167,8 @@ nv50_dmac_create(struct nvif_device *device, struct 
nvif_object *disp,
if (ret)
return ret;
 
-   ret = nvif_object_init(>base.user, 0xf001, NV_DMA_IN_MEMORY,
+   ret = nvif_object_init(>base.user, NV50_DISP_HANDLE_VRAM,
+  NV_DMA_IN_MEMORY,
   &(struct nv_dma_v0) {
.target = NV_DMA_V0_TARGET_VRAM,
.access = NV_DMA_V0_ACCESS_RDWR,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/handles.h 
b/drivers/gpu/drm/nouveau/dispnv50/handles.h
new file mode 100644
index 0..d1beeb9a444db
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/dispnv50/handles.h
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: MIT
+#ifndef __NV50_KMS_HANDLES_H__
+#define __NV50_KMS_HANDLES_H__
+
+/*
+ * Various hard-coded object handles that nouveau uses. These are made-up by
+ * nouveau developers, not Nvidia. The only significance of the handles chosen
+ * is that they must all be unique.
+ */
+#define NV50_DISP_HANDLE_SYNCBUF
0xf000
+#define NV50_DISP_HANDLE_VRAM   
0xf001
+
+#define NV50_DISP_HANDLE_WNDW_CTX(kind)(0xfb00 | 
kind)
+
+#endif /* !__NV50_KMS_HANDLES_H__ */
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c 
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 720fe75de1859..293ccfdba17ef 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -21,6 +21,7 @@
  */
 #include "wndw.h"
 #include "wimm.h"
+#include "handles.h"
 
 #include 
 #include 
@@ -59,7 +60,7 @@ nv50_wndw_ctxdma_new(struct nv50_wndw *wndw, struct 
drm_framebuffer *fb)
int ret;
 
nouveau_framebuffer_get_layout(fb, , );
-   handle = 0xfb00 | kind;
+   handle = NV50_DISP_HANDLE_WNDW_CTX(kind);
 
list_for_each_entry(ctxdma, >ctxdma.list, head) {
if (ctxdma->object.handle == handle)
-- 
2.26.2

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


[RFC v8 7/9] drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h

2020-06-27 Thread Lyude Paul
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.

So, expose the struct in disp.h.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 18 --
 drivers/gpu/drm/nouveau/dispnv50/disp.h | 14 ++
 2 files changed, 14 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 368069a5b181a..090882794f7d6 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -57,24 +57,6 @@
 
 #include 
 
-/**
- * Atomic state
- */
-
-struct nv50_outp_atom {
-   struct list_head head;
-
-   struct drm_encoder *encoder;
-   bool flush_disable;
-
-   union nv50_outp_atom_mask {
-   struct {
-   bool ctrl:1;
-   };
-   u8 mask;
-   } set, clr;
-};
-
 /**
  * EVO channel
  */
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.h 
b/drivers/gpu/drm/nouveau/dispnv50/disp.h
index 696e70a6b98b6..c7b72fa850995 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.h
@@ -71,6 +71,20 @@ struct nv50_dmac {
struct mutex lock;
 };
 
+struct nv50_outp_atom {
+   struct list_head head;
+
+   struct drm_encoder *encoder;
+   bool flush_disable;
+
+   union nv50_outp_atom_mask {
+   struct {
+   bool ctrl:1;
+   };
+   u8 mask;
+   } set, clr;
+};
+
 int nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
 const s32 *oclass, u8 head, void *data, u32 size,
 u64 syncbuf, struct nv50_dmac *dmac);
-- 
2.26.2

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


[RFC v8 3/9] drm/vblank: Add vblank works

2020-06-27 Thread Lyude Paul
Add some kind of vblank workers. The interface is similar to regular
delayed works, and is mostly based off kthread_work. It allows for
scheduling delayed works that execute once a particular vblank sequence
has passed. It also allows for accurate flushing of scheduled vblank
works - in that flushing waits for both the vblank sequence and job
execution to complete, or for the work to get cancelled - whichever
comes first.

Whatever hardware programming we do in the work must be fast (must at
least complete during the vblank or scanout period, sometimes during the
first few scanlines of the vblank). As such we use a high-priority
per-CRTC thread to accomplish this.

Changes since v7:
* Stuff drm_vblank_internal.h and drm_vblank_work_internal.h contents
  into drm_internal.h
* Get rid of unnecessary spinlock in drm_crtc_vblank_on()
* Remove !vblank->worker check
* Grab vbl_lock in drm_vblank_work_schedule()
* Mention self-rearming work items in drm_vblank_work_schedule() kdocs
* Return 1 from drm_vblank_work_schedule() if the work was scheduled
  successfully, 0 or error code otherwise
* Use drm_dbg_core() instead of DRM_DEV_ERROR() in
  drm_vblank_work_schedule()
* Remove vblank->worker checks in drm_vblank_destroy_worker() and
  drm_vblank_flush_worker()
Changes since v6:
* Get rid of ->pending and seqcounts, and implement flushing through
  simpler means - danvet
* Get rid of work_lock, just use drm_device->event_lock
* Move drm_vblank_work item cleanup into drm_crtc_vblank_off() so that
  we ensure that all vblank work has finished before disabling vblanks
* Add checks into drm_crtc_vblank_reset() so we yell if it gets called
  while there's vblank workers active
* Grab event_lock in both drm_crtc_vblank_on()/drm_crtc_vblank_off(),
  the main reason for this is so that other threads calling
  drm_vblank_work_schedule() are blocked from attempting to schedule
  while we're in the middle of enabling/disabling vblanks.
* Move drm_handle_vblank_works() call below drm_handle_vblank_events()
* Simplify drm_vblank_work_cancel_sync()
* Fix drm_vblank_work_cancel_sync() documentation
* Move wake_up_all() calls out of spinlock where we can. The only one I
  left was the call to wake_up_all() in drm_vblank_handle_works() as
  this seemed like it made more sense just living in that function
  (which is all technically under lock)
* Move drm_vblank_work related functions into their own source files
* Add drm_vblank_internal.h so we can export some functions we don't
  want drivers using, but that we do need to use in drm_vblank_work.c
* Add a bunch of documentation
Changes since v4:
* Get rid of kthread interfaces we tried adding and move all of the
  locking into drm_vblank.c. For implementing drm_vblank_work_flush(),
  we now use a wait_queue and sequence counters in order to
  differentiate between multiple work item executions.
* Get rid of drm_vblank_work_cancel() - this would have been pretty
  difficult to actually reimplement and it occurred to me that neither
  nouveau or i915 are even planning to use this function. Since there's
  also no async cancel function for most of the work interfaces in the
  kernel, it seems a bit unnecessary anyway.
* Get rid of to_drm_vblank_work() since we now are also able to just
  pass the struct drm_vblank_work to work item callbacks anyway
Changes since v3:
* Use our own spinlocks, don't integrate so tightly with kthread_works
Changes since v2:
* Use kthread_workers instead of reinventing the wheel.

Cc: Tejun Heo 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Reviewed-by: Daniel Vetter 
Co-developed-by: Ville Syrjälä 
Signed-off-by: Lyude Paul 
---
 Documentation/gpu/drm-kms.rst |  15 ++
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_internal.h|  27 +++
 drivers/gpu/drm/drm_vblank.c  |  44 +++--
 drivers/gpu/drm/drm_vblank_work.c | 267 ++
 include/drm/drm_vblank.h  |  20 +++
 include/drm/drm_vblank_work.h |  71 
 7 files changed, 430 insertions(+), 16 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_vblank_work.c
 create mode 100644 include/drm/drm_vblank_work.h

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 975cfeb8a3532..3c5ae4f6dfd23 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -543,3 +543,18 @@ Vertical Blanking and Interrupt Handling Functions 
Reference
 
 .. kernel-doc:: drivers/gpu/drm/drm_vblank.c
:export:
+
+Vertical Blank Work
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_vblank_work.c
+   :doc: vblank works
+
+Vertical Blank Work Functions Reference
+---
+
+.. kernel-doc:: include/drm/drm_vblank_work.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_vblank_work.c
+   :export:
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c0e5a7e59536..02ee5faf1a925 100644
--- a/drivers/gpu/drm/Makefile
+++ 

[RFC v8 4/9] drm/nouveau/kms/nv140-: Don't modify depth in state during atomic commit

2020-06-27 Thread Lyude Paul
Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's depth in the atomic state hasn't been modified.

Normally this wouldn't matter, since we don't modify OR state outside of
modesets, but since the CRC capture region is implemented as part of the
OR state in hardware we'll want to make sure all commits modifying OR
state are idempotent so as to avoid changing the depth unexpectedly.

So, fix this by simply not writing the reduced depth value we come up
with to the atomic state.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 11 +++
 drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 11 +++
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c 
b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
index 4a9a32b89f746..9ef3c603fc43e 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
@@ -27,17 +27,20 @@ static void
 headc37d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
 {
struct nv50_dmac *core = _disp(head->base.base.dev)->core->chan;
+   u8 depth;
u32 *push;
+
if ((push = evo_wait(core, 2))) {
/*XXX: This is a dirty hack until OR depth handling is
 * improved later for deep colour etc.
 */
switch (asyh->or.depth) {
-   case 6: asyh->or.depth = 5; break;
-   case 5: asyh->or.depth = 4; break;
-   case 2: asyh->or.depth = 1; break;
-   case 0: asyh->or.depth = 4; break;
+   case 6: depth = 5; break;
+   case 5: depth = 4; break;
+   case 2: depth = 1; break;
+   case 0: depth = 4; break;
default:
+   depth = asyh->or.depth;
WARN_ON(1);
break;
}
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c 
b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
index 859131a8bc3c8..97141eb8e75ab 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
@@ -27,17 +27,20 @@ static void
 headc57d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
 {
struct nv50_dmac *core = _disp(head->base.base.dev)->core->chan;
+   u8 depth;
u32 *push;
+
if ((push = evo_wait(core, 2))) {
/*XXX: This is a dirty hack until OR depth handling is
 * improved later for deep colour etc.
 */
switch (asyh->or.depth) {
-   case 6: asyh->or.depth = 5; break;
-   case 5: asyh->or.depth = 4; break;
-   case 2: asyh->or.depth = 1; break;
-   case 0: asyh->or.depth = 4; break;
+   case 6: depth = 5; break;
+   case 5: depth = 4; break;
+   case 2: depth = 1; break;
+   case 0: depth = 4; break;
default:
+   depth = asyh->or.depth;
WARN_ON(1);
break;
}
-- 
2.26.2

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


[RFC v8 0/9] drm/nouveau: Introduce CRC support for gf119+

2020-06-27 Thread Lyude Paul
Nvidia released some documentation on how CRC support works on their
GPUs, hooray!

So: this patch series implements said CRC support in nouveau, along with
adding some special debugfs interfaces for some relevant igt-gpu-tools
tests (already on the ML).

First - we add some new functionality to kthread_work in the kernel, and
then use this to add a new feature to DRM that Ville Syrjälä came up
with: vblank workers. Basically, this is just a generic DRM interface
that allows for scheduling high-priority workers that start on a given
vblank interrupt. Note that while we're currently only using this in
nouveau, Intel has plans to use this for i915 as well (hence why they
came up with it!).

And finally: in order to implement the last feature, we expose some new
functions in the kernel's kthread_worker infrastructure so that we can
de-complicate our implementation of this.

Anyway-welcome to the future! :)

Major changes since v7:
* Drop /harm/armh/ patch
* Address danvet's comments
* Drop "drm/nouveau/kms/nv50-: Unroll error cleanup in
  nv50_head_create()"
Major changes since v6:
* Move vblank_work related functions into their own files
* Write documentation
* Simplify work flushing and cancellation by getting rid of seqcounts
  and ->pending
Major changes since v4:
* Remove the interfaces we tried adding to kthread_worker and use a wait
  queue + seqcount in order to implement flushing vblank workers.
* Rebase
Major changes since v3:
* Style fixes on nouveau patches from checkpatch, no functional changes
* Don't integrate so tightly with kthread_work (and use our own lock),
  instead introduce some new functions for doing simple async flushing
  and cancelling. I think this interface looks a lot more acceptable
  then what I was previously trying.
* Apply some changes requested by danvet
Major changes since v2:
* Use kthread_worker instead of kthreadd for vblank workers
* Don't check debugfs return values

Lyude Paul (9):
  drm/vblank: Register drmm cleanup action once per drm_vblank_crtc
  drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_off()
  drm/vblank: Add vblank works
  drm/nouveau/kms/nv140-: Don't modify depth in state during atomic
commit
  drm/nouveau/kms/nv50-: Fix disabling dithering
  drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom
  drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h
  drm/nouveau/kms/nv50-: Move hard-coded object handles into header
  drm/nouveau/kms/nvd9-: Add CRC support

 Documentation/gpu/drm-kms.rst   |  15 +
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_internal.h  |  27 +
 drivers/gpu/drm/drm_vblank.c|  72 +-
 drivers/gpu/drm/drm_vblank_work.c   | 267 
 drivers/gpu/drm/nouveau/dispnv04/crtc.c |  25 +-
 drivers/gpu/drm/nouveau/dispnv50/Kbuild |   4 +
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  21 +
 drivers/gpu/drm/nouveau/dispnv50/core.h |   4 +
 drivers/gpu/drm/nouveau/dispnv50/core907d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/core917d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/corec37d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/corec57d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/crc.c  | 714 
 drivers/gpu/drm/nouveau/dispnv50/crc.h  | 125 
 drivers/gpu/drm/nouveau/dispnv50/crc907d.c  | 139 
 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c  | 153 +
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  58 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.h |  24 +
 drivers/gpu/drm/nouveau/dispnv50/handles.h  |  16 +
 drivers/gpu/drm/nouveau/dispnv50/head.c |  98 ++-
 drivers/gpu/drm/nouveau/dispnv50/head.h |  12 +-
 drivers/gpu/drm/nouveau/dispnv50/head907d.c |  14 +-
 drivers/gpu/drm/nouveau/dispnv50/headc37d.c |  27 +-
 drivers/gpu/drm/nouveau/dispnv50/headc57d.c |  20 +-
 drivers/gpu/drm/nouveau/dispnv50/wndw.c |   3 +-
 drivers/gpu/drm/nouveau/nouveau_display.c   |  60 +-
 include/drm/drm_vblank.h|  20 +
 include/drm/drm_vblank_work.h   |  71 ++
 29 files changed, 1861 insertions(+), 142 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_vblank_work.c
 create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc.c
 create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc.h
 create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc907d.c
 create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c
 create mode 100644 drivers/gpu/drm/nouveau/dispnv50/handles.h
 create mode 100644 include/drm/drm_vblank_work.h

-- 
2.26.2

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


[RFC v8 5/9] drm/nouveau/kms/nv50-: Fix disabling dithering

2020-06-27 Thread Lyude Paul
While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.

So, fix it by never enabling dithering when it's disabled.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/head.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index 8f6455697ba72..ed6819519f6d8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -84,18 +84,20 @@ nv50_head_atomic_check_dither(struct nv50_head_atom *armh,
 {
u32 mode = 0x00;
 
-   if (asyc->dither.mode == DITHERING_MODE_AUTO) {
-   if (asyh->base.depth > asyh->or.bpc * 3)
-   mode = DITHERING_MODE_DYNAMIC2X2;
-   } else {
-   mode = asyc->dither.mode;
-   }
+   if (asyc->dither.mode) {
+   if (asyc->dither.mode == DITHERING_MODE_AUTO) {
+   if (asyh->base.depth > asyh->or.bpc * 3)
+   mode = DITHERING_MODE_DYNAMIC2X2;
+   } else {
+   mode = asyc->dither.mode;
+   }
 
-   if (asyc->dither.depth == DITHERING_DEPTH_AUTO) {
-   if (asyh->or.bpc >= 8)
-   mode |= DITHERING_DEPTH_8BPC;
-   } else {
-   mode |= asyc->dither.depth;
+   if (asyc->dither.depth == DITHERING_DEPTH_AUTO) {
+   if (asyh->or.bpc >= 8)
+   mode |= DITHERING_DEPTH_8BPC;
+   } else {
+   mode |= asyc->dither.depth;
+   }
}
 
asyh->dither.enable = mode;
-- 
2.26.2

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


[RFC v8 6/9] drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom

2020-06-27 Thread Lyude Paul
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary reason we'll need this is for CRC support.

See: on nvidia hardware, each CRC entry in the CRC notifier dma context
has a "tag". This tag corresponds to the nth update on a specific
EVO/NvDisplay channel, which itself is referred to as the "controlling
channel". For gf119+ this can be the core channel, ovly channel, or base
channel. Since we don't expose CRC entry tags to userspace, we simply
ignore this feature and always use the core channel as the controlling
channel. Simple.

Things get a little bit more complicated on gv100+ though. GV100+ only
lets us set the controlling channel to a specific wndw channel, and that
wndw must be owned by the head that we're grabbing CRCs when we enable
CRC generation. Thus, we always need to make sure that each atomic head
state has at least one wndw that is mapped to the head, which will be
used as the controlling channel.

Note that since we don't have flexible wndw mappings yet, we don't
expect to run into any scenarios yet where we'd have a head with no
mapped wndws. When we do add support for flexible wndw mappings however,
we'll need to make sure that we handle reprogramming CRC capture if our
controlling wndw is moved to another head (and potentially reject the
new head state entirely if we can't find another available wndw to
replace it).

With that being said, nouveau currently tracks wndw visibility on heads.
It does not keep track of the actual ownership mappings, which are
(currently) statically programmed. To fix this, we introduce another
bitmask into nv50_head_atom.wndw to keep track of ownership separately
from visibility. We then introduce a nv50_head callback to handle
populating the wndw ownership map, and call it during the atomic check
phase when core->assign_windows is set to true.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  1 +
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 16 
 drivers/gpu/drm/nouveau/dispnv50/head.h |  2 ++
 drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 10 ++
 drivers/gpu/drm/nouveau/dispnv50/headc57d.c |  2 ++
 5 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h 
b/drivers/gpu/drm/nouveau/dispnv50/atom.h
index 24f7700768dab..62faaf60f47a5 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
@@ -18,6 +18,7 @@ struct nv50_head_atom {
 
struct {
u32 mask;
+   u32 owned;
u32 olut;
} wndw;
 
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index d472942102f50..368069a5b181a 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2287,12 +2287,28 @@ static int
 nv50_disp_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
 {
struct nv50_atom *atom = nv50_atom(state);
+   struct nv50_core *core = nv50_disp(dev)->core;
struct drm_connector_state *old_connector_state, *new_connector_state;
struct drm_connector *connector;
struct drm_crtc_state *new_crtc_state;
struct drm_crtc *crtc;
+   struct nv50_head *head;
+   struct nv50_head_atom *asyh;
int ret, i;
 
+   if (core->assign_windows && core->func->head->static_wndw_map) {
+   drm_for_each_crtc(crtc, dev) {
+   new_crtc_state = drm_atomic_get_crtc_state(state,
+  crtc);
+   if (IS_ERR(new_crtc_state))
+   return PTR_ERR(new_crtc_state);
+
+   head = nv50_head(crtc);
+   asyh = nv50_head_atom(new_crtc_state);
+   core->func->head->static_wndw_map(head, asyh);
+   }
+   }
+
/* We need to handle colour management on a per-plane basis. */
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->color_mgmt_changed) {
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.h 
b/drivers/gpu/drm/nouveau/dispnv50/head.h
index c32b27cdaefc9..c05bbba9e247c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.h
@@ -40,6 +40,7 @@ struct nv50_head_func {
void (*dither)(struct nv50_head *, struct nv50_head_atom *);
void (*procamp)(struct nv50_head *, struct nv50_head_atom *);
void (*or)(struct nv50_head *, struct nv50_head_atom *);
+   void (*static_wndw_map)(struct nv50_head *, struct nv50_head_atom *);
 };
 
 extern const struct nv50_head_func head507d;
@@ -86,6 +87,7 @@ int 

[RFC v8 2/9] drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_off()

2020-06-27 Thread Lyude Paul
This got me confused for a bit while looking over this code: I had been
planning on adding some blocking function calls into this function, but
seeing the irqsave/irqrestore variants of spin_(un)lock() didn't make it
very clear whether or not that would actually be safe.

So I went ahead and reviewed every single driver in the kernel that uses
this function, and they all fall into three categories:

* Driver probe code
* ->atomic_disable() callbacks
* Legacy modesetting callbacks

All of these will be guaranteed to have IRQs enabled, which means it's
perfectly safe to block here. Just to make things a little less
confusing to others in the future, let's switch over to
spin_lock_irq()/spin_unlock_irq() to make that fact a little more
obvious.

Signed-off-by: Lyude Paul 
Reviewed-by: Daniel Vetter 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_vblank.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index ce5c1e1d29963..e895f5331fdb4 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1283,13 +1283,12 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
struct drm_pending_vblank_event *e, *t;
 
ktime_t now;
-   unsigned long irqflags;
u64 seq;
 
if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
return;
 
-   spin_lock_irqsave(>event_lock, irqflags);
+   spin_lock_irq(>event_lock);
 
spin_lock(>vbl_lock);
drm_dbg_vbl(dev, "crtc %d, vblank enabled %d, inmodeset %d\n",
@@ -1325,7 +1324,7 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
drm_vblank_put(dev, pipe);
send_vblank_event(dev, e, seq, now);
}
-   spin_unlock_irqrestore(>event_lock, irqflags);
+   spin_unlock_irq(>event_lock);
 
/* Will be reset by the modeset helpers when re-enabling the crtc by
 * calling drm_calc_timestamping_constants(). */
-- 
2.26.2

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


[RFC v8 1/9] drm/vblank: Register drmm cleanup action once per drm_vblank_crtc

2020-06-27 Thread Lyude Paul
Since we'll be allocating resources for kthread_create_worker() in the
next commit (which could fail and require us to clean up the mess),
let's simplify the cleanup process a bit by registering a
drm_vblank_init_release() action for each drm_vblank_crtc so they're
still cleaned up if we fail to initialize one of them.

Changes since v3:
* Use drmm_add_action_or_reset() - Daniel Vetter

Cc: Ville Syrjälä 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Reviewed-by: Daniel Vetter 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_vblank.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 85e5f2db16085..ce5c1e1d29963 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -492,16 +492,12 @@ static void vblank_disable_fn(struct timer_list *t)
 
 static void drm_vblank_init_release(struct drm_device *dev, void *ptr)
 {
-   unsigned int pipe;
-
-   for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = ptr;
 
-   drm_WARN_ON(dev, READ_ONCE(vblank->enabled) &&
-   drm_core_check_feature(dev, DRIVER_MODESET));
+   drm_WARN_ON(dev, READ_ONCE(vblank->enabled) &&
+   drm_core_check_feature(dev, DRIVER_MODESET));
 
-   del_timer_sync(>disable_timer);
-   }
+   del_timer_sync(>disable_timer);
 }
 
 /**
@@ -511,7 +507,7 @@ static void drm_vblank_init_release(struct drm_device *dev, 
void *ptr)
  *
  * This function initializes vblank support for @num_crtcs display pipelines.
  * Cleanup is handled automatically through a cleanup function added with
- * drmm_add_action().
+ * drmm_add_action_or_reset().
  *
  * Returns:
  * Zero on success or a negative error code on failure.
@@ -530,10 +526,6 @@ int drm_vblank_init(struct drm_device *dev, unsigned int 
num_crtcs)
 
dev->num_crtcs = num_crtcs;
 
-   ret = drmm_add_action(dev, drm_vblank_init_release, NULL);
-   if (ret)
-   return ret;
-
for (i = 0; i < num_crtcs; i++) {
struct drm_vblank_crtc *vblank = >vblank[i];
 
@@ -542,6 +534,11 @@ int drm_vblank_init(struct drm_device *dev, unsigned int 
num_crtcs)
init_waitqueue_head(>queue);
timer_setup(>disable_timer, vblank_disable_fn, 0);
seqlock_init(>seqlock);
+
+   ret = drmm_add_action_or_reset(dev, drm_vblank_init_release,
+  vblank);
+   if (ret)
+   return ret;
}
 
return 0;
-- 
2.26.2

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


Re: [Freedreno] [PATCH v9 6/7] drm/msm: Set the global virtual address range from the IOMMU domain

2020-06-27 Thread Rob Clark
On Fri, Jun 26, 2020 at 1:01 PM Jordan Crouse  wrote:
>
> Use the aperture settings from the IOMMU domain to set up the virtual
> address range for the GPU. This allows us to transparently deal with
> IOMMU side features (like split pagetables).
>
> Signed-off-by: Jordan Crouse 
> ---
>
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 13 +++--
>  drivers/gpu/drm/msm/msm_iommu.c |  7 +++
>  2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 5db06b590943..3e717c1ebb7f 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -192,9 +192,18 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
> struct iommu_domain *iommu = iommu_domain_alloc(_bus_type);
> struct msm_mmu *mmu = msm_iommu_new(>dev, iommu);
> struct msm_gem_address_space *aspace;
> +   u64 start, size;
>
> -   aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
> -   0x - SZ_16M);
> +   /*
> +* Use the aperture start or SZ_16M, whichever is greater. This will
> +* ensure that we align with the allocated pagetable range while still
> +* allowing room in the lower 32 bits for GMEM and whatnot
> +*/
> +   start = max_t(u64, SZ_16M, iommu->geometry.aperture_start);
> +   size = iommu->geometry.aperture_end - start + 1;
> +
> +   aspace = msm_gem_address_space_create(mmu, "gpu",
> +   start & GENMASK(48, 0), size);

hmm, I kinda think this isn't going to play well for the 32b gpus
(pre-a5xx).. possibly we should add address space size to 'struct
adreno_info'?

Or I guess it is always going to be the same for all devices within a
generation?  So it could just be passed in to adreno_gpu_init()

Hopefully that makes things smoother if we someday had more than 48bits..

BR,
-R

>
> if (IS_ERR(aspace) && !IS_ERR(mmu))
> mmu->funcs->destroy(mmu);
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 3a381a9674c9..1b6635504069 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -36,6 +36,10 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t 
> iova,
> struct msm_iommu *iommu = to_msm_iommu(mmu);
> size_t ret;
>
> +   /* The arm-smmu driver expects the addresses to be sign extended */
> +   if (iova & BIT_ULL(48))
> +   iova |= GENMASK_ULL(63, 49);
> +
> ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
> WARN_ON(!ret);
>
> @@ -46,6 +50,9 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t 
> iova, size_t len)
>  {
> struct msm_iommu *iommu = to_msm_iommu(mmu);
>
> +   if (iova & BIT_ULL(48))
> +   iova |= GENMASK_ULL(63, 49);
> +
> iommu_unmap(iommu->domain, iova, len);
>
> return 0;
> --
> 2.17.1
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] dt-bindings: serial: add generic DT binding for announcing RTS/CTS lines

2020-06-27 Thread Greg Kroah-Hartman
On Wed, May 20, 2020 at 03:39:31PM +0200, Erwan Le Ray wrote:
> Add support of generic DT binding for annoucing RTS/CTS lines. The initial
> binding 'st,hw-flow-control' is not needed anymore since generic binding
> is available, but is kept for backward compatibility.
> 
> Signed-off-by: Erwan Le Ray 
> 
> diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml 
> b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> index 75b8521eb7cb..06d5f251ec88 100644
> --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> @@ -35,9 +35,11 @@ properties:
>  description: label associated with this uart
>  
>st,hw-flow-ctrl:
> -description: enable hardware flow control
> +description: enable hardware flow control (deprecated)
>  $ref: /schemas/types.yaml#/definitions/flag
>  
> +  uart-has-rtscts: true
> +
>dmas:
>  minItems: 1
>  maxItems: 2
> -- 
> 2.17.1
> 

Did this get ignored by the DT maintainers?  :(
___
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

2020-06-27 Thread Grygorii Strashko




On 26/06/2020 13:01, 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 probe_err function introduced recently,
ie. if probe_err will be called with -EPROBE_DEFER instead of printk the message
will be attached to deferred device and printed when user read devices_deferred
property.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Mark Brown 
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Andy Shevchenko 
---
  drivers/base/base.h |  3 +++
  drivers/base/core.c |  8 ++--
  drivers/base/dd.c   | 23 ++-
  3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/base/base.h b/drivers/base/base.h
index 95c22c0f9036..6954fccab3d7 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -93,6 +93,7 @@ struct device_private {
struct klist_node knode_class;
struct list_head deferred_probe;
struct device_driver *async_driver;
+   char *deferred_probe_reason;
struct device *device;
u8 dead:1;
  };
@@ -134,6 +135,8 @@ extern void device_release_driver_internal(struct device 
*dev,
  extern void driver_detach(struct device_driver *drv);
  extern int driver_probe_device(struct device_driver *drv, struct device *dev);
  extern void driver_deferred_probe_del(struct device *dev);
+extern void device_set_deferred_probe_reson(const struct device *dev,
+   struct va_format *vaf);
  static inline int driver_match_device(struct device_driver *drv,
  struct device *dev)
  {
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 3a827c82933f..fee047f03681 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3963,6 +3963,8 @@ define_dev_printk_level(_dev_info, KERN_INFO);
   * This helper implements common pattern present in probe functions for error
   * checking: print debug or error message depending if the error value is
   * -EPROBE_DEFER and propagate error upwards.
+ * In case of -EPROBE_DEFER it sets also defer probe reason, which can be
+ * checked later by reading devices_deferred debugfs attribute.
   * It replaces code sequence:
   *if (err != -EPROBE_DEFER)
   *dev_err(dev, ...);
@@ -3984,10 +3986,12 @@ int dev_err_probe(const struct device *dev, int err, 
const char *fmt, ...)
vaf.fmt = fmt;
vaf.va = 
  
-	if (err != -EPROBE_DEFER)

+   if (err != -EPROBE_DEFER) {
dev_err(dev, "error %d: %pV", err, );
-   else
+   } else {
+   device_set_deferred_probe_reson(dev, );
dev_dbg(dev, "error %d: %pV", err, );
+   }
  
  	va_end(args);
  
diff --git a/drivers/base/dd.c b/drivers/base/dd.c

index 9a1d940342ac..dd5683b61f74 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "base.h"

  #include "power/power.h"
@@ -136,6 +137,8 @@ void driver_deferred_probe_del(struct device *dev)
if (!list_empty(>p->deferred_probe)) {
dev_dbg(dev, "Removed from deferred list\n");
list_del_init(>p->deferred_probe);
+   kfree(dev->p->deferred_probe_reason);
+   dev->p->deferred_probe_reason = NULL;
}
mutex_unlock(_probe_mutex);
  }
@@ -211,6 +214,23 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
  }
  
+/**

+ * device_set_deferred_probe_reson() - Set defer probe reason message for 
device
+ * @dev: the pointer to the struct device
+ * @vaf: the pointer to va_format structure with message
+ */
+void device_set_deferred_probe_reson(const struct device *dev, struct 
va_format *vaf)
+{
+   const char *drv = dev_driver_string(dev);
+
+   mutex_lock(_probe_mutex);
+
+   kfree(dev->p->deferred_probe_reason);
+   dev->p->deferred_probe_reason = kasprintf(GFP_KERNEL, "%s: %pV", drv, 
vaf);
+
+   mutex_unlock(_probe_mutex);
+}
+
  /*
   * 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(_probe_mutex);
  
  	list_for_each_entry(curr, _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(_probe_mutex);
  



Sry, may be i missing smth, but shouldn't it be optional
(CONFIG_DEBUG_FS is probably too generic).

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


[Bug 207673] amdgpu/radeon: crash due to over temperature

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

--- Comment #5 from phileimer (p...@jpmr.org) ---
Created attachment 289897
  --> https://bugzilla.kernel.org/attachment.cgi?id=289897=edit
amdgpu: kernel log when over temperature crash

-- 
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 v2] drm/atomic_helper: add a flag for duplicating drm_private_obj state

2020-06-27 Thread Shawn Guo
From: Shawn Guo 

The msm/mdp5 driver uses state of drm_private_obj as its global atomic
state, which keeps the assignment of hwpipe to plane.  With
drm_private_obj missing from duplicate state call in context of atomic
suspend/resume helpers, mdp5 suspend works with no problem only for the
very first time.  Any subsequent suspend will hit the following warning,
because hwpipe assignment doesn't get duplicated for suspend state.

$ echo mem > /sys/power/state
[   38.44] PM: suspend entry (deep)
[   38.85] PM: Syncing filesystems ... done.
[   38.114630] Freezing user space processes ... (elapsed 0.001 seconds) done.
[   38.115912] OOM killer disabled.
[   38.115914] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[   38.122170] [ cut here ]
[   38.122212] WARNING: CPU: 0 PID: 1747 at 
drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c:145 mdp5_pipe_release+0x90/0xc0
[   38.122215] Modules linked in:
[   38.12] CPU: 0 PID: 1747 Comm: sh Not tainted 
4.19.107-00515-g9d5e4d7a33ed-dirty #323
[   38.14] Hardware name: Square, Inc. T2 Devkit (DT)
[   38.18] pstate: 4005 (nZcv daif -PAN -UAO)
[   38.122230] pc : mdp5_pipe_release+0x90/0xc0
[   38.122233] lr : mdp5_pipe_release+0x90/0xc0
[   38.122235] sp : 0d13b7f0
[   38.122236] x29: 0d13b7f0 x28: 
[   38.122240] x27: 0002 x26: 800079adce00
[   38.122243] x25: 800079405200 x24: 
[   38.122246] x23: 80007a78cc08 x22: 80007b1cc018
[   38.122249] x21: 80007b1cc000 x20: 80007b317080
[   38.122252] x19: 80007a78ce80 x18: 0002
[   38.122255] x17:  x16: 
[   38.122258] x15: fff0 x14: 08c3fb48
[   38.122261] x13: 08cdac4a x12: 08c3f000
[   38.122264] x11:  x10: 08cda000
[   38.122267] x9 :  x8 : 08ce4a40
[   38.122269] x7 :  x6 : 39ea41a9
[   38.122272] x5 :  x4 : 
[   38.122275] x3 :  x2 : c7580c109cae4500
[   38.122278] x1 :  x0 : 0024
[   38.122281] Call trace:
[   38.122285]  mdp5_pipe_release+0x90/0xc0
[   38.122288]  mdp5_plane_atomic_check+0x2c0/0x448
[   38.122294]  drm_atomic_helper_check_planes+0xd0/0x208
[   38.122298]  drm_atomic_helper_check+0x38/0xa8
[   38.122302]  drm_atomic_check_only+0x3e8/0x630
[   38.122305]  drm_atomic_commit+0x18/0x58
[   38.122309]  __drm_atomic_helper_disable_all.isra.12+0x15c/0x1a8
[   38.122312]  drm_atomic_helper_suspend+0x80/0xf0
[   38.122316]  msm_pm_suspend+0x4c/0x70
[   38.122320]  dpm_run_callback.isra.6+0x20/0x68
[   38.122323]  __device_suspend+0x110/0x308
[   38.122326]  dpm_suspend+0x100/0x1f0
[   38.122329]  dpm_suspend_start+0x64/0x70
[   38.122334]  suspend_devices_and_enter+0x110/0x500
[   38.122336]  pm_suspend+0x268/0x2c0
[   38.122339]  state_store+0x88/0x110
[   38.122345]  kobj_attr_store+0x14/0x28
[   38.122352]  sysfs_kf_write+0x3c/0x50
[   38.122355]  kernfs_fop_write+0x118/0x1e0
[   38.122360]  __vfs_write+0x30/0x168
[   38.122363]  vfs_write+0xa4/0x1a8
[   38.122366]  ksys_write+0x64/0xe8
[   38.122368]  __arm64_sys_write+0x18/0x20
[   38.122374]  el0_svc_common+0x6c/0x178
[   38.122377]  el0_svc_compat_handler+0x1c/0x28
[   38.122381]  el0_svc_compat+0x8/0x18
[   38.122383] ---[ end trace 24145b7d8545345b ]---
[   38.491552] Disabling non-boot CPUs ...

Let's add a flag for duplicating the state of drm_private_obj and set
the flag from msm/mdp5 driver, so that the problem can be fixed while
other drivers using drm_private_obj stay unaffected.

Signed-off-by: Shawn Guo 
---
Changes for v2:
 - Add a flag to duplicate the state of drm_private_obj conditionally,
   so that other drivers using drm_private_obj stay unaffected.

 drivers/gpu/drm/drm_atomic_helper.c  | 22 ++
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  7 +++
 include/drm/drm_atomic.h | 11 +++
 3 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 85d163f16801..4bf041730b9e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3140,6 +3140,7 @@ drm_atomic_helper_duplicate_state(struct drm_device *dev,
struct drm_atomic_state *state;
struct drm_connector *conn;
struct drm_connector_list_iter conn_iter;
+   struct drm_private_obj *priv_obj;
struct drm_plane *plane;
struct drm_crtc *crtc;
int err = 0;
@@ -3184,6 +3185,19 @@ drm_atomic_helper_duplicate_state(struct drm_device *dev,
}
drm_connector_list_iter_end(_iter);
 
+   drm_for_each_privobj(priv_obj, dev) {
+   struct drm_private_state *priv_state;
+
+   if (!priv_obj->needs_duplicate_state)
+   continue;
+
+   priv_state = 

Re: [PATCH] dt-bindings: display: vc4: dpi: Fix panel warning

2020-06-27 Thread Sam Ravnborg
On Fri, Jun 26, 2020 at 02:11:31PM +0200, Maxime Ripard wrote:
> The example used in the DPI binding before the conversion to YAML had a
> simple-panel example that got carried over to the YAML binding.
> 
> However, that example doesn't match the simple-panel binding and results in
> validation errors. Since it's only marginally helpful, let's remove that
> part of the example entirely.
> 
> Fixes: 094536003e06 ("dt-bindings: display: Convert VC4 bindings to schemas")
> Signed-off-by: Maxime Ripard 
Acked-by: Sam Ravnborg 
> ---
>  .../devicetree/bindings/display/brcm,bcm2835-dpi.yaml  | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml 
> b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
> index 58213c564e03..5c1024bbc1b3 100644
> --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
> @@ -45,16 +45,6 @@ examples:
>- |
>  #include 
>  
> -panel: panel {
> -compatible = "ontat,yx700wv03", "simple-panel";
> -
> -port {
> -panel_in: endpoint {
> -remote-endpoint = <_out>;
> -};
> -};
> -};
> -
>  dpi: dpi@7e208000 {
>  compatible = "brcm,bcm2835-dpi";
>  reg = <0x7e208000 0x8c>;
> -- 
> 2.26.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] dt-bindings: display: vc4: dpi: Fix panel warning

2020-06-27 Thread Maxime Ripard
The example used in the DPI binding before the conversion to YAML had a
simple-panel example that got carried over to the YAML binding.

However, that example doesn't match the simple-panel binding and results in
validation errors. Since it's only marginally helpful, let's remove that
part of the example entirely.

Fixes: 094536003e06 ("dt-bindings: display: Convert VC4 bindings to schemas")
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/display/brcm,bcm2835-dpi.yaml  | 10 --
 1 file changed, 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml 
b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
index 58213c564e03..5c1024bbc1b3 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
@@ -45,16 +45,6 @@ examples:
   - |
 #include 
 
-panel: panel {
-compatible = "ontat,yx700wv03", "simple-panel";
-
-port {
-panel_in: endpoint {
-remote-endpoint = <_out>;
-};
-};
-};
-
 dpi: dpi@7e208000 {
 compatible = "brcm,bcm2835-dpi";
 reg = <0x7e208000 0x8c>;
-- 
2.26.2

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


Re: [RFC] Host1x/TegraDRM UAPI (drm_tegra_channel_map)

2020-06-27 Thread Dmitry Osipenko
26.06.2020 10:34, Thierry Reding пишет:
> On Fri, Jun 26, 2020 at 01:47:46AM +0300, Dmitry Osipenko wrote:
>> 23.06.2020 15:09, Mikko Perttunen пишет:
>>> ### DRM_TEGRA_CHANNEL_MAP
>>>
>>> Make memory accessible by the engine while executing work on the channel.
>>>
>>> ```
>>> #define DRM_TEGRA_CHANNEL_MAP_READWRITE    (1<<0)
>>>
>>> struct drm_tegra_channel_map {
>>>     /*
>>>  * [in] ID of the channel for which to map memory to.
>>>  */
>>>     __u32 channel_id;
>>>     /*
>>>  * [in] GEM handle of the memory to map.
>>>  */
>>>     __u32 handle;
>>>
>>>     /*
>>>  * [in] Offset in GEM handle of the memory area to map.
>>>  *
>>>  * Must be aligned by 4K.
>>>  */
>>>     __u64 offset;
>>
>> Could you please give a use-case example for this partial mapping?
>>
>> I vaguely recalling that maybe it was me who suggested this in the past..
>>
>> I kinda see that this could be useful for a case where userspace
>> allocates a large chunk of memory and then performs sub-allocations in
>> the userspace driver. But do we have a real-world example for this right
>> now?
> 
> I think the main point about this IOCTL was to make mapping/unmapping
> more efficient and avoid relocations for situations where we know it is
> safe to do so.
> 
> The fact that this can be used to create partial mappings is mostly just
> an added bonus, in my opinion. Doing this doesn't create much complexity
> but in turn gives us a lot more flexibility.
> 
> A couple of places where I think this could be useful are OpenGL and
> Vulkan, both of which support buffer suballocation. This has a couple of
> advantages on modern GPUs where sometimes you want to use very large
> allocation granularity, etc.
> 
> Now, I don't think that we'll see much of that in Tegra DRM directly,
> although grate could certainly make use of this, I suspect. However, I
> think for interoperation of dGPU and Tegra DRM (with VIC for post-
> processing, or hopefully some of the other hardware acceleration
> engines at some point), this might come in handy.
> 
> There are other possible use-cases within just Tegra DRM as well. We may
> want to only partially map planar buffers for video post-processing, for
> example. Or map each plane separately.
> 
>> Please see more below.
>>
>>>     /*
>>>  * [in] Length of memory area to map in bytes.
>>>  *
>>>  * Must be aligned by 4K.
>>>  */
>>>     __u64 length;
>>>
>>>     /*
>>>  * [out] IOVA of mapped memory. Userspace can use this IOVA
>>>  *   directly to refer to the memory to skip using relocations.
>>>  *   Only available if hardware memory isolation is enabled.
>>>  *
>>>  *   Will be set to 0x___ if unavailable.
>>>  */
>>>     __u64 iova;
>>>
>>>     /*
>>>  * [out] ID corresponding to the mapped memory to be used for
>>>  *   relocations or unmapping.
>>>  */
>>>     __u32 mapping_id;
>>>     /*
>>>  * [in] Flags.
>>>  */
>>>     __u32 flags;
>>>
>>>     __u32 reserved[6];
>>> };
>>
>> It looks to me that we actually need a bit different thing here.
>>
>> This MAP IOCTL maps a portion of a GEM and then returns the mapping_id.
>> And I think we need something more flexible that will allow us to use
>> GEM handles for the relocation IDs, which should fit nicely with the
>> DMA-reservations.
>>
>> What about an IOCTL that wraps GEM into another GEM? We could wrap a
>> portion of GEM_A into a GEM_B, and then map the GEM_B using the MAP IOCTL.
>>
>> It could be something like this:
>>
>> ### DRM_TEGRA_BO_WRAP
>>
>> struct drm_tegra_wrap_bo {
>>  __u32 bo_handle_wrapped; // out
>>  __u32 bo_handle; // in
>>  __u64 offset;
>>  __u64 length;
>> };
>>
>> ### DRM_TEGRA_CHANNEL_MAP
>>
>> struct drm_tegra_channel_map {
>> __u32 channels_mask;
>>  __u32 mapping_id;
>> __u32 bo_handle;
>> __u32 flags;
>> __u64 iova;
>> };
>>
>> ===
>>
>> This allows multiple mapping_ids to have the same backing GEM, so the
>> mapping_id could be resolved into a BO during of job's submission for
>> the DMA-reservations handling.
> 
> That's pretty much what we have already above, isn't it? Just because we
> call the field "mapping_id" doesn't mean that in the background we can't
> create a GEM object and return it's handle as "mapping_id".
> 
> One advantage of Mikko's proposal is that we have a single IOCTL rather
> than two to create the mapping, making it a bit more lightweight.

Thinking a bit more about it, I now changed my mind.

There is no need to perform implicit fencing on each suballocation,
instead explicit fencing should be used for the suballocations.

So, we will need to add the relocation flags for the direction and
explicit (or implicit) fencing per-relocation. The direction will tell
how fence should be 

Re: Warning triggered in drm_dp_delayed_destroy_work workqueue

2020-06-27 Thread Luis Henriques
On Fri, Jun 26, 2020 at 05:06:00PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 26, 2020 at 03:40:20PM +0200, Daniel Vetter wrote:
> > Adding Lyude, she's been revamping all the lifetime refcouting in the
> > dp code last few kernel releases. At a glance I don't even have an
> > idea what's going wrong here ...
> 
> Already fixed by Imre I believe.
> 
> 7d11507605a7 ("drm/dp_mst: Fix the DDC I2C device unregistration of an MST 
> port")
> 

Ah!  It does seems to be the same issue indeed!  Thanks a lot for pointing
me at this commit.  Hopefully this fix can be included in 5.8.  Not that
I'm seeing this WARNING frequently, but frequent enough to annoy me :-)

Cheers,
--
Luis

> > -Daniel
> > 
> > On Thu, Jun 25, 2020 at 12:22 PM Luis Henriques  wrote:
> > >
> > > Hi!
> > >
> > > I've been seeing this warning occasionally, not sure if it has been
> > > reported yet.  It's not a regression as I remember seeing it in, at least,
> > > 5.7.
> > >
> > > Anyway, here it is:
> > >
> > > [ cut here ]
> > > sysfs group 'power' not found for kobject 'i2c-7'
> > > WARNING: CPU: 1 PID: 17996 at fs/sysfs/group.c:279 
> > > sysfs_remove_group+0x74/0x80
> > > Modules linked in: ccm(E) dell_rbtn(E) iwlmvm(E) mei_wdt(E) mac80211(E) 
> > > libarc4(E) uvcvideo(E) dell_laptop(E) videobuf2_vmalloc(E) intel_rapl_>
> > >  soundcore(E) intel_soc_dts_iosf(E) rng_core(E) battery(E) acpi_pad(E) 
> > > sparse_keymap(E) acpi_thermal_rel(E) intel_pch_thermal(E) int3402_therm>
> > >  sysfillrect(E) intel_lpss(E) sysimgblt(E) fb_sys_fops(E) idma64(E) 
> > > scsi_mod(E) virt_dma(E) mfd_core(E) drm(E) fan(E) thermal(E) i2c_hid(E) 
> > > hi>
> > > CPU: 1 PID: 17996 Comm: kworker/1:1 Tainted: GE 
> > > 5.8.0-rc2+ #36
> > > Hardware name: Dell Inc. Precision 5510/0N8J4R, BIOS 1.14.2 05/25/2020
> > > Workqueue: events drm_dp_delayed_destroy_work [drm_kms_helper]
> > > RIP: 0010:sysfs_remove_group+0x74/0x80
> > > Code: ff 5b 48 89 ef 5d 41 5c e9 79 bc ff ff 48 89 ef e8 01 b8 ff ff eb 
> > > cc 49 8b 14 24 48 8b 33 48 c7 c7 90 ac 8b 93 e8 de b1 d4 ff <0f> 0b 5b>
> > > RSP: :b12d40c13c38 EFLAGS: 00010282
> > > RAX:  RBX: 936e6a60 RCX: 0027
> > > RDX: 0027 RSI: 0086 RDI: 8e37de097b68
> > > RBP:  R08: 8e37de097b60 R09: 93fb4624
> > > R10: 0904 R11: 0001002c R12: 8e37d3081c18
> > > R13: 8e375f1450a8 R14:  R15: 8e375f145410
> > > FS:  () GS:8e37de08() 
> > > knlGS:
> > > CS:  0010 DS:  ES:  CR0: 80050033
> > > CR2:  CR3: 0004ab20a001 CR4: 003606e0
> > > DR0:  DR1:  DR2: 
> > > DR3:  DR6: fffe0ff0 DR7: 0400
> > > Call Trace:
> > >  device_del+0x97/0x3f0
> > >  cdev_device_del+0x15/0x30
> > >  put_i2c_dev+0x7b/0x90 [i2c_dev]
> > >  i2cdev_detach_adapter+0x33/0x60 [i2c_dev]
> > >  notifier_call_chain+0x47/0x70
> > >  blocking_notifier_call_chain+0x3d/0x60
> > >  device_del+0x8f/0x3f0
> > >  device_unregister+0x16/0x60
> > >  i2c_del_adapter+0x247/0x300
> > >  drm_dp_port_set_pdt+0x90/0x2c0 [drm_kms_helper]
> > >  drm_dp_delayed_destroy_work+0x2be/0x340 [drm_kms_helper]
> > >  process_one_work+0x1ae/0x370
> > >  worker_thread+0x50/0x3a0
> > >  ? process_one_work+0x370/0x370
> > >  kthread+0x11b/0x140
> > >  ? kthread_associate_blkcg+0x90/0x90
> > >  ret_from_fork+0x22/0x30
> > > ---[ end trace 16486ad3c2627482 ]---
> > > [ cut here ]
> > >
> > > Cheers,
> > > --
> > > Luis
> > 
> > 
> > 
> > -- 
> > 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
> 
> -- 
> Ville Syrjälä
> Intel

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


[PATCH] drm/connector: fix minor typos in comments

2020-06-27 Thread Antonio Borneo
Some of these comments are part of the Linux GPU Driver Developer's
Guide.
Fix some minor typo in the comments and remove a repeated 'the'.

Signed-off-by: Antonio Borneo 
---
 drivers/gpu/drm/drm_connector.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d877ddc6dc57..cb62fb8e594e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -38,7 +38,7 @@
  * DOC: overview
  *
  * In DRM connectors are the general abstraction for display sinks, and include
- * als fixed panels or anything else that can display pixels in some form. As
+ * also fixed panels or anything else that can display pixels in some form. As
  * opposed to all other KMS objects representing hardware (like CRTC, encoder 
or
  * plane abstractions) connectors can be hotplugged and unplugged at runtime.
  * Hence they are reference-counted using drm_connector_get() and
@@ -129,7 +129,7 @@ EXPORT_SYMBOL(drm_get_connector_type_name);
 
 /**
  * drm_connector_get_cmdline_mode - reads the user's cmdline mode
- * @connector: connector to quwery
+ * @connector: connector to query
  *
  * The kernel supports per-connector configuration of its consoles through
  * use of the video= parameter. This function parses that option and
@@ -991,7 +991,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  * DP MST sinks), or high-res integrated panels (like dual-link DSI) which
  * are not gen-locked. Note that for tiled panels which are genlocked, like
  * dual-link LVDS or dual-link DSI, the driver should try to not expose the
- * tiling and virtualize both _crtc and _plane if needed. Drivers
+ * tiling and virtualise both _crtc and _plane if needed. Drivers
  * should update this value using drm_connector_set_tile_property().
  * Userspace cannot change this property.
  * link-status:
@@ -1131,7 +1131,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = 
{
  *
  * It will even need to do colorspace conversion and get all layers
  * to one common colorspace for blending. It can use either GL, Media
- * or display engine to get this done based on the capabilties of the
+ * or display engine to get this done based on the capabilities of the
  * associated hardware.
  *
  * Driver expects metadata to be put in  hdr_output_metadata
@@ -1614,7 +1614,7 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
  * variable refresh rate capability for a connector.
  *
  * Returns:
- * Zero on success, negative errono on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_connector_attach_vrr_capable_property(
struct drm_connector *connector)
@@ -1759,7 +1759,7 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
  * HDMI connectors.
  *
  * Returns:
- * Zero on success, negative errono on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
 {
@@ -1788,7 +1788,7 @@ EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
  * DP connectors.
  *
  * Returns:
- * Zero on success, negative errono on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
 {
@@ -1840,7 +1840,7 @@ EXPORT_SYMBOL(drm_mode_create_content_type_property);
  * drm_mode_create_suggested_offset_properties - create suggests offset 
properties
  * @dev: DRM device
  *
- * Create the the suggested x/y offset property for connectors.
+ * Create the suggested x/y offset property for connectors.
  */
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev)
 {
@@ -1963,7 +1963,7 @@ int drm_connector_update_edid_property(struct 
drm_connector *connector,
size = EDID_LENGTH * (1 + edid->extensions);
 
/* Set the display info, using edid if available, otherwise
-* reseting the values to defaults. This duplicates the work
+* resetting the values to defaults. This duplicates the work
 * done in drm_add_edid_modes, but that function is not
 * consistently called before this one in all drivers and the
 * computation is cheap enough that it seems better to
@@ -2076,7 +2076,7 @@ void drm_connector_set_vrr_capable_property(
 EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
 
 /**
- * drm_connector_set_panel_orientation - sets the connecter's panel_orientation
+ * drm_connector_set_panel_orientation - sets the connector's panel_orientation
  * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  *
@@ -2131,7 +2131,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 
 /**
  * drm_connector_set_panel_orientation_with_quirk -
- * set the connecter's panel_orientation after checking for quirks
+ * set the connector's 

Re: [RFC] Host1x/TegraDRM UAPI

2020-06-27 Thread Dmitry Osipenko
26.06.2020 16:38, Daniel Vetter пишет:
> On Fri, Jun 26, 2020 at 01:40:40PM +0200, Thierry Reding wrote:
>> On Fri, Jun 26, 2020 at 01:06:58PM +0200, Karol Herbst wrote:
>>> On Tue, Jun 23, 2020 at 3:03 PM Mikko Perttunen  wrote:

 # Host1x/TegraDRM UAPI proposal

 This is a proposal for a stable UAPI for Host1x and TegraDRM, to replace
 the current TegraDRM UAPI that is behind `STAGING` and quite obsolete in
 many ways.

 I haven't written any implementation yet -- I'll do that once there is
 some agreement on the high-level design.

 Current open items:

 * The syncpoint UAPI allows userspace to create sync_file FDs with
 arbitrary syncpoint fences. dma_fence code currently seems to assume all
 fences will be signaled, which would not necessarily be the case with
 this interface.
 * Previously present GEM IOCTLs (GEM_CREATE, GEM_MMAP) are not present.
 Not sure if they are still needed.

>>>
>>> Hi, as this wasn't addressed here (and sorry if I missed it): is there
>>> an open source userspace making use of this UAPI? Because this is
>>> something which needs to be seen before it can be included at all.
>>
>> There's a set of commits that implement an earlier draft here:
>>
>> https://github.com/thierryreding/linux/tree/for-5.6/drm-tegra-destage-abi
>>
>> and corresponding changes to libdrm to make use of that and implement
>> tests using the various generations of VIC here:
>>
>> https://cgit.freedesktop.org/~tagr/drm/log/
>>
>> Before actually jumping to an implementation we wanted to go over the
>> design a bit more to avoid wasting a lot of work, like we've done in
>> the past. Turns out it isn't easy to get everyone to agree on a good
>> ABI. Who would've thought? =)
>>
>> I expect that once the discussion around the ABI settles Mikko will
>> start on implementing this ABI in the kernel and we'll update the
>> libdrm patches to make use of the new ABI as well.
> 
> Do we have more than libdrm and tests for this, like something somewhat
> functional? Since tegradrm landed years ago we've refined the criteria a
> bit in this regard, latest version is explicit in that it needs to be
> something that's functional (for end-users in some form), not just
> infrastructure and tests.

We have Opentegra [1] and VDPAU [2] userspace drivers for older Tegra
SoCs that have been using the staging UAPI for years now.

[1] https://github.com/grate-driver/xf86-video-opentegra
[2] https://github.com/grate-driver/libvdpau-tegra

The UAPI and the kernel driver updates are very needed for these drivers
because of the missing UAPI synchronization features and performance
problems of the kernel driver.

So we already have some real-world userspace for the testing!

It's not the first and not the second time we're discussing the Tegra
DRM UAPI changes, but this time it feels like there is a good chance
that it will finally materialize and I'm very happy about it :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4] drm/doc: device hot-unplug for userspace

2020-06-27 Thread Noralf Trønnes


Den 22.06.2020 16.05, skrev Pekka Paalanen:
> From: Pekka Paalanen 
> 
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
> 
> Written by Daniel Vetter's request and largely based on his comments in IRC 
> and
> from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
> 
> A related Wayland protocol change proposal is at
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35
> 
> Signed-off-by: Pekka Paalanen 
> Reviewed-by: Daniel Vetter 
> Cc: Andrey Grodzovsky 
> Cc: Dave Airlie 
> Cc: Sean Paul 
> Cc: Simon Ser 
> Cc: Noralf Trønnes 
> Cc: Ben Skeggs 
> Cc: Christian König 
> Cc: Harry Wentland 
> Cc: Karol Herbst 
> 
> ---
> 
> Harry and Christian, could one of you ack this on behalf of AMD
> drivers?
> 
> Ben or Karol, could you ack on behalf of Nouveau?
> 
> Noralf, would this work for the tiny drivers etc.?
> 

Looks good to me:

Acked-by: Noralf Trønnes 

> This is only about laying out plans for the future, not about what
> drivers do today. We'd just like to be sure the goals are reasonable and
> everyone is aware of the idea.
> 
> Thanks,
> pq
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] fbtft-bus.c:

2020-06-27 Thread kernel test robot
Hi K,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v5.8-rc2 next-20200626]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/B-K-Karthik/fbtft-bus-c/20200627-125213
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
92cd1b5d65f5c67147c7da39a3c2ad7e6ff81027
config: i386-randconfig-a005-20200624 (attached as .config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=i386 

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

All error/warnings (new ones prefixed by >>):

   drivers/staging/fbtft/fbtft-bus.c:65:53: error: macro 
"define_fbtft_write_reg" requires 4 arguments, but only 3 given
define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
^
>> drivers/staging/fbtft/fbtft-bus.c:15:1: error: expected '=', ',', ';', 'asm' 
>> or '__attribute__' before 'void'
void func(struct fbtft_par *par, int len, ...)  
  \
^
>> drivers/staging/fbtft/fbtft-bus.c:66:1: note: in expansion of macro 
>> 'define_fbtft_write_reg'
define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
^~
   drivers/staging/fbtft/fbtft-bus.c:67:57: error: macro 
"define_fbtft_write_reg" requires 4 arguments, but only 3 given
define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
^
   drivers/staging/fbtft/fbtft-bus.c:69:1: error: expected '=', ',', ';', 'asm' 
or '__attribute__' before 'void'
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
^~~~

vim +15 drivers/staging/fbtft/fbtft-bus.c

c296d5f9957c03 Thomas Petazzoni   2014-12-31   7  
c296d5f9957c03 Thomas Petazzoni   2014-12-31   8  
/*
c296d5f9957c03 Thomas Petazzoni   2014-12-31   9   *
c296d5f9957c03 Thomas Petazzoni   2014-12-31  10   *   void (*write_reg)(struct 
fbtft_par *par, int len, ...);
c296d5f9957c03 Thomas Petazzoni   2014-12-31  11   *
c296d5f9957c03 Thomas Petazzoni   2014-12-31  12   
*/
c296d5f9957c03 Thomas Petazzoni   2014-12-31  13  
8d8825b420ffb3 Alfonso Lima Astor 2017-10-17  14  #define 
define_fbtft_write_reg(func, buffer_type, data_type, modifier)\
c296d5f9957c03 Thomas Petazzoni   2014-12-31 @15  void func(struct fbtft_par 
*par, int len, ...)\
c296d5f9957c03 Thomas Petazzoni   2014-12-31  16  { 
\
c296d5f9957c03 Thomas Petazzoni   2014-12-31  17va_list args;   
  \
c296d5f9957c03 Thomas Petazzoni   2014-12-31  18int i, ret; 
  \
c296d5f9957c03 Thomas Petazzoni   2014-12-31  19int offset = 0; 
  \
8d8825b420ffb3 Alfonso Lima Astor 2017-10-17  20buffer_type *buf = 
(buffer_type *)par->buf;   \
c296d5f9957c03 Thomas Petazzoni   2014-12-31  21
  \
c296d5f9957c03 Thomas Petazzoni   2014-12-31  22if (unlikely(par->debug 
& DEBUG_WRITE_REGISTER)) {\
c296d5f9957c03 Thomas Petazzoni   2014-12-31  23va_start(args, 
len);  \
c296d5f9957c03 Thomas Petazzoni   2014-12-31  24for (i = 0; i < 
len; i++) {   \
cc1c0eea8527bd Renato Soma2018-04-17  25buf[i] 
= modifier((data_type)va_arg(args, \
cc1c0eea8527bd Renato Soma2018-04-17  26
unsigned int));   \
c296d5f9957c03 Thomas Petazzoni   2014-12-31  27}   
  \
c296d5f9957c03 Thomas Petazzoni   2014-12-31  28va_end(args);   
  \
cc1c0eea8527bd Renato Soma2018-04-17  29
fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,  \
cc1c0eea8527bd Renato Soma2018-04-17  30
  par->info->device, buffer_type, buf, len,   \
cc1c0eea8527bd Renato Soma2018-04-17  31
  "%s: ", __f

Re: [PATCH] fbtft-bus.c:

2020-06-27 Thread kernel test robot
Hi K,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v5.8-rc2 next-20200626]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/B-K-Karthik/fbtft-bus-c/20200627-125213
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
92cd1b5d65f5c67147c7da39a3c2ad7e6ff81027
config: m68k-randconfig-r016-20200624 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=m68k 

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

All errors (new ones prefixed by >>):

   In file included from include/linux/build_bug.h:5,
from include/linux/bits.h:23,
from include/linux/gpio/consumer.h:5,
from drivers/staging/fbtft/fbtft-bus.c:4:
   include/linux/scatterlist.h: In function 'sg_set_buf':
   arch/m68k/include/asm/page_mm.h:169:49: warning: ordered comparison of 
pointer with null pointer [-Wextra]
 169 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void 
*)PAGE_OFFSET && (void *)(kaddr) < high_memory)
 | ^~
   include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
  78 | # define unlikely(x) __builtin_expect(!!(x), 0)
 |  ^
   include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON'
 143 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~
   include/linux/scatterlist.h:143:10: note: in expansion of macro 
'virt_addr_valid'
 143 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~~
   drivers/staging/fbtft/fbtft-bus.c: At top level:
>> drivers/staging/fbtft/fbtft-bus.c:65:53: error: macro 
>> "define_fbtft_write_reg" requires 4 arguments, but only 3 given
  65 | define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
 | ^
   drivers/staging/fbtft/fbtft-bus.c:14: note: macro "define_fbtft_write_reg" 
defined here
  14 | #define define_fbtft_write_reg(func, buffer_type, data_type, 
modifier)\
 | 
>> drivers/staging/fbtft/fbtft-bus.c:65:23: error: expected ';' before 'void'
  65 | define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
 |   ^
 |   ;
   drivers/staging/fbtft/fbtft-bus.c:67:57: error: macro 
"define_fbtft_write_reg" requires 4 arguments, but only 3 given
  67 | define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
 | ^
   drivers/staging/fbtft/fbtft-bus.c:14: note: macro "define_fbtft_write_reg" 
defined here
  14 | #define define_fbtft_write_reg(func, buffer_type, data_type, 
modifier)\
 | 
   drivers/staging/fbtft/fbtft-bus.c:67:23: error: expected ';' before 'void'
  67 | define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
 |   ^
 |   ;
  68 | 
  69 | void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
 |    

vim +/define_fbtft_write_reg +65 drivers/staging/fbtft/fbtft-bus.c

64  
  > 65  define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
66  define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
67  define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
68  

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


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


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

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

--- Comment #28 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to rtmasura+kernel from comment #27)
> and another crash, chrome's good at causing them (watching youtube). Used -s
> "" for the setting which I think should set it to 'auto', and what I assumed
> was default. I've changed that to -s "off" to see if that helps.

You just added those updates as I was typing a comment pointing out that
chrome/chromium in your bug; bugzilla warned of a mid-air collision! 
Chrom(e|ium) has new vulkan accel code and very likely exercises some of the
same relatively new amdgpu kernel code kwin does, so both of them triggering
the bug wouldn't surprise me at all.

As it happens I switched back to firefox during the 5.6 kernel cycle, so
haven't seen chromium's interaction with the (kernel 5.7) bug myself, but once
I saw it in that trace I said to myself I bet that's his trigger!


FWIW I advanced a couple more bisect steps pretty quickly as it was triggering
as I tried to complete system updates (which on gentoo of course means building
the packages), but then I hit an apparently good kernel, and uptime says 3 days
now, something I've not seen in awhile!  Only thing is, I finished those
updates and they were pretty calm the next couple days, so I've not been
stressing the system to the same extent, either.  Given the problems I got
myself into the first bisect run, I'm going to run on this kernel a bit longer
before I do that bisect good to advance a step.  If it reaches a week and I've
done either a good system update or a some heavy 4k@60 youtube on firefox, I'll
call it good, but I'm not ready to yet.

The good news is, in a couple more bisect steps I'll be down to some practical
number of remaining commits to report the range here, and if they have the
time, a dev with a practiced eye should be able to narrow it down by say 3/4
(two steps ahead of my bisect), leaving something actually practical to examine
closer.  After that it'll be past the point of my bisect being the only
bottleneck, if it's big enough to get dev priority time, of course.  If not,
I'll just have to keep plugging away at the bisect...

-- 
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 3/4] media: camss: vfe: Use trace_printk for debugging only

2020-06-27 Thread Nicolas Boichat
trace_printk should not be used in production code. Since
tracing interrupts is presumably latency sensitive, pr_dbg is
not appropriate, so guard the call with a preprocessor symbol
that can be defined for debugging purpose.

Signed-off-by: Nicolas Boichat 

---
 drivers/media/platform/qcom/camss/camss-vfe-4-1.c | 2 ++
 drivers/media/platform/qcom/camss/camss-vfe-4-7.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c 
b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
index 174a36be6f5d866..0c57171fae4f9e9 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
@@ -936,8 +936,10 @@ static irqreturn_t vfe_isr(int irq, void *dev)
 
vfe->ops->isr_read(vfe, , );
 
+#ifdef CAMSS_VFE_TRACE_IRQ
trace_printk("VFE: status0 = 0x%08x, status1 = 0x%08x\n",
 value0, value1);
+#endif
 
if (value0 & VFE_0_IRQ_STATUS_0_RESET_ACK)
vfe->isr_ops.reset_ack(vfe);
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c 
b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
index 0dca8bf9281e774..307675925e5c779 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
@@ -1058,8 +1058,10 @@ static irqreturn_t vfe_isr(int irq, void *dev)
 
vfe->ops->isr_read(vfe, , );
 
+#ifdef CAMSS_VFE_TRACE_IRQ
trace_printk("VFE: status0 = 0x%08x, status1 = 0x%08x\n",
 value0, value1);
+#endif
 
if (value0 & VFE_0_IRQ_STATUS_0_RESET_ACK)
vfe->isr_ops.reset_ack(vfe);
-- 
2.27.0.212.ge8ba1cc988-goog

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


[PATCH v2 4/4] kernel/trace: Add TRACING_ALLOW_PRINTK config option

2020-06-27 Thread Nicolas Boichat
trace_printk is meant as a debugging tool, and should not be
compiled into production code without specific debug Kconfig
options enabled, or source code changes, as indicated by the
warning that shows up on boot if any trace_printk is called:
 **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **
 **  **
 ** trace_printk() being used. Allocating extra memory.  **
 **  **
 ** This means that this is a DEBUG kernel and it is **
 ** unsafe for production use.   **

If this option is set to n, the kernel will generate a
build-time error if trace_printk is used.

Note that the code to handle trace_printk is still present,
so this does not prevent people from compiling out-of-tree
kernel modules with the option set to =y, or BPF programs.

Signed-off-by: Nicolas Boichat 

---

Changes since v1:
 - Use static_assert instead of __static_assert (Jason Gunthorpe)
 - Fix issues that can be detected by this patch (running some
   randconfig in a loop, kernel test robot, or manual inspection),
   by:
   - Making some debug config options that use trace_printk depend
 on the new config option.
   - Adding 3 patches before this one.

There is a question from Alexei whether the warning is warranted,
and it's possibly too strongly worded, but the fact is, we do
not want trace_printk to be sprinkled in kernel code by default,
unless a very specific Kconfig command is enabled (or preprocessor
macro).

There's at least 3 reasons that I can come up with:
 1. trace_printk introduces some overhead.
 2. If the kernel keeps adding always-enabled trace_printk, it will
be much harder for developers to make use of trace_printk for
debugging.
 3. People may assume that trace_printk is for debugging only, and
may accidentally output sensitive data (theoritical at this
stage).

 drivers/gpu/drm/i915/Kconfig.debug |  4 ++--
 fs/f2fs/Kconfig|  1 +
 include/linux/kernel.h | 17 -
 kernel/trace/Kconfig   | 10 ++
 samples/Kconfig|  2 ++
 5 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 1cb28c20807c59d..fa30f9bdc82311f 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -84,7 +84,7 @@ config DRM_I915_ERRLOG_GEM
 config DRM_I915_TRACE_GEM
bool "Insert extra ftrace output from the GEM internals"
depends on DRM_I915_DEBUG_GEM
-   select TRACING
+   depends on TRACING_ALLOW_PRINTK
default n
help
  Enable additional and verbose debugging output that will spam
@@ -98,7 +98,7 @@ config DRM_I915_TRACE_GEM
 config DRM_I915_TRACE_GTT
bool "Insert extra ftrace output from the GTT internals"
depends on DRM_I915_DEBUG_GEM
-   select TRACING
+   depends on TRACING_ALLOW_PRINTK
default n
help
  Enable additional and verbose debugging output that will spam
diff --git a/fs/f2fs/Kconfig b/fs/f2fs/Kconfig
index d13c5c6a978769b..d161d96cc1b7418 100644
--- a/fs/f2fs/Kconfig
+++ b/fs/f2fs/Kconfig
@@ -80,6 +80,7 @@ config F2FS_IO_TRACE
bool "F2FS IO tracer"
depends on F2FS_FS
depends on FUNCTION_TRACER
+   depends on TRACING_ALLOW_PRINTK
help
  F2FS IO trace is based on a function trace, which gathers process
  information and block IO patterns in the filesystem level.
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 196607aaf653082..8abce95b0c95a0e 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -721,10 +721,15 @@ do {  
\
 #define trace_printk(fmt, ...) \
 do {   \
char ___STR[] = __stringify((__VA_ARGS__)); \
+   \
+   static_assert(  \
+   IS_ENABLED(CONFIG_TRACING_ALLOW_PRINTK),\
+   "trace_printk called, please enable 
CONFIG_TRACING_ALLOW_PRINTK."); \
+   \
if (sizeof(___STR) > 3) \
do_trace_printk(fmt, ##__VA_ARGS__);\
else\
-   trace_puts(fmt);\
+   do_trace_puts(fmt); \
 } while (0)
 
 #define do_trace_printk(fmt, args...)  \
@@ -773,6 +778,13 @@ int __trace_printk(unsigned long ip, const char *fmt, ...);
  */
 
 #define trace_puts(str) ({ \
+   static_assert(  \
+   

[PATCH 2/4] media: atomisp: Replace trace_printk by pr_info

2020-06-27 Thread Nicolas Boichat
trace_printk should not be used in production code, replace it
call with pr_info.

Signed-off-by: Nicolas Boichat 

---
 drivers/staging/media/atomisp/pci/hmm/hmm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/hmm/hmm.c 
b/drivers/staging/media/atomisp/pci/hmm/hmm.c
index 42fef17798622f1..2bd39b4939f16d2 100644
--- a/drivers/staging/media/atomisp/pci/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/hmm/hmm.c
@@ -735,11 +735,11 @@ ia_css_ptr hmm_host_vaddr_to_hrt_vaddr(const void *ptr)
 
 void hmm_show_mem_stat(const char *func, const int line)
 {
-   trace_printk("tol_cnt=%d usr_size=%d res_size=%d res_cnt=%d sys_size=%d 
 dyc_thr=%d dyc_size=%d.\n",
-hmm_mem_stat.tol_cnt,
-hmm_mem_stat.usr_size, hmm_mem_stat.res_size,
-hmm_mem_stat.res_cnt, hmm_mem_stat.sys_size,
-hmm_mem_stat.dyc_thr, hmm_mem_stat.dyc_size);
+   pr_info("tol_cnt=%d usr_size=%d res_size=%d res_cnt=%d sys_size=%d  
dyc_thr=%d dyc_size=%d.\n",
+   hmm_mem_stat.tol_cnt,
+   hmm_mem_stat.usr_size, hmm_mem_stat.res_size,
+   hmm_mem_stat.res_cnt, hmm_mem_stat.sys_size,
+   hmm_mem_stat.dyc_thr, hmm_mem_stat.dyc_size);
 }
 
 void hmm_init_mem_stat(int res_pgnr, int dyc_en, int dyc_pgnr)
-- 
2.27.0.212.ge8ba1cc988-goog

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


[PATCH 1/4] usb: cdns3: gadget: Replace trace_printk by dev_dbg

2020-06-27 Thread Nicolas Boichat
trace_printk should not be used in production code, replace it
call with dev_dbg.

Signed-off-by: Nicolas Boichat 

---

Unclear why a trace_printk was used in the first place, it's
possible that some rate-limiting is necessary here.

 drivers/usb/cdns3/gadget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index 5e24c2e57c0d8c8..c303ab7c62d1651 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -421,7 +421,7 @@ static int cdns3_start_all_request(struct cdns3_device 
*priv_dev,
if ((priv_req->flags & REQUEST_INTERNAL) ||
(priv_ep->flags & EP_TDLCHK_EN) ||
priv_ep->use_streams) {
-   trace_printk("Blocking external request\n");
+   dev_dbg(priv_dev->dev, "Blocking external request\n");
return ret;
}
}
-- 
2.27.0.212.ge8ba1cc988-goog

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


[PATCH 0/4] Detect and remove trace_printk

2020-06-27 Thread Nicolas Boichat
trace_printk is meant as a debugging tool, and should not be
compiled into production code without specific debug Kconfig
options enabled or source code changes.

Patches 1 to 3 remove/disable trace_printk that should not
be enabled by default.

Patch 4 adds a config option that can be used to detect such
trace_printk at compile time (instead of printing a nasty
warning at runtime).

Nicolas Boichat (4):
  usb: cdns3: gadget: Replace trace_printk by dev_dbg
  media: atomisp: Replace trace_printk by pr_info
  media: camss: vfe: Use trace_printk for debugging only
  kernel/trace: Add TRACING_ALLOW_PRINTK config option

 drivers/gpu/drm/i915/Kconfig.debug  |  4 ++--
 .../media/platform/qcom/camss/camss-vfe-4-1.c   |  2 ++
 .../media/platform/qcom/camss/camss-vfe-4-7.c   |  2 ++
 drivers/staging/media/atomisp/pci/hmm/hmm.c | 10 +-
 drivers/usb/cdns3/gadget.c  |  2 +-
 fs/f2fs/Kconfig |  1 +
 include/linux/kernel.h  | 17 -
 kernel/trace/Kconfig| 10 ++
 samples/Kconfig |  2 ++
 9 files changed, 41 insertions(+), 9 deletions(-)

-- 
2.27.0.212.ge8ba1cc988-goog

___
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

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

--- Comment #27 from rtmasura+ker...@hotmail.com ---
and another crash, chrome's good at causing them (watching youtube). Used -s ""
for the setting which I think should set it to 'auto', and what I assumed was
default. I've changed that to -s "off" to see if that helps.

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