From: Daniel Vetter <daniel@ffwll.ch> To: Thomas Zimmermann <tzimmermann@suse.de> Cc: linux-fbdev@vger.kernel.org, b.zolnierkie@samsung.com, airlied@linux.ie, gregkh@linuxfoundation.org, michel@daenzer.net, corbet@lwn.net, malat@debian.org, dri-devel@lists.freedesktop.org, sean@poorly.run Subject: Re: [PATCH v2 00/15] DRM fbconv helpers for converting fbdev drivers Date: Tue, 15 Oct 2019 14:33:18 +0000 [thread overview] Message-ID: <20191015143318.GP11828@phenom.ffwll.local> (raw) In-Reply-To: <20191014140416.28517-1-tzimmermann@suse.de> Hi Thomas, On Mon, Oct 14, 2019 at 04:04:01PM +0200, Thomas Zimmermann wrote: > (was: DRM driver for fbdev devices) > > This is version 2 of the fbdev conversion helpers. It's more or less a > rewrite of the original patchset. > > The fbdev subsystem is considered legacy and will probably be removed at > some point. This would mean the loss of a signifanct number of drivers. > Some of the affected hardware is not in use any longer, but some hardware > is still around and provides good(-enough) framebuffers. > > The fbconv helpers allow for running the current DRM stack on top of fbdev > drivers. It's a set of functions that convert between fbdev interfaces and > DRM interfaces. Based on SHMEM and simple KMS helpers, it only offers the > basic functionality of a framebuffer, but should be compatible with most > existing fbdev drivers. > > A DRM driver using fbconv helpers consists of > > * DRM stub code that calls into fbconv helpers, and > * the original fbdev driver code. > > The fbdev driver code has to be modified to register itself with the > stub driver instead of the fbdev core framework. A tutorial on how to use > the helpers is part of this patchset. The resulting driver hybrid can be > refactored into a first-class DRM driver. The fbconv helpers contain a > number of comments, labeled 'DRM porting note', which explain the required > steps. > > I tested the current patchset with the following drivers: atyfb, aty128fb, > matroxfb, pm2fb, pm3fb, rivafb, s3fb, savagefb, sisfb, tdfxfb and tridentfb. > With each, I was able to successfully start with fbcon enabled, run weston and > X11. The drivers are available at [1]. For reference, the patchset includes > the Matrox stub driver. So I really don't want to rain on the parade here, since if you think this is useful when converting fbdev drivers I'll buy that, and I'm all for getting more modern drivers into drm. But I have a bunch of concerns with the approach you're proposing here: - we've tried staging for drm driver refactoring, it hurts. Separate tree plus the quick pace in refactoring create lots of pains. And for small drivers refacotoring before it's not buying you anything above refactoring in your own personal tree. And for big drivers we're fairly lenient with merging drivers that aren't fully polished yet, if there's a team serious enough with cleaning up the mess. I think even merging partial drivers directly under drivers/gpu (but behind CONFIG_BROKEN) is better than staging. - we've had conversion helpers before (for the legacy kms -> atomic upgrade). They constantly broke, pretty much every release when someone wanted to use them they first had to fix them up again. I think having those helpers is good, but better to just have them in some branch somewhere where it's clear that they might not work anymore on latest upstream. - especially for some of these simple fbdev drivers I feel like just typing a new driver from scratch might be simpler. A few more concerns specifically for your mga example: - We already have a mga driver. Might be better to integrate support for older mgas into that than have a parallel driver. - Your helper is based on simple display pipe, and I think for these old mga chips (especially the dual pipe mga 450 and 550) simple display pipe helper is more a hindering detour than actual help. From a quick read through the code (especially all the custom ioctls) you definitely want separate TV-out connector to expose all the tv mode properties (instead of the custom ioctls). - On the topic of ioctls, looks like we could add FBIOGET_VBLANK to our generic implementation in the fbdev helpers. So here's my alternative proposal: - You push this as a branch onto a gitlab repo (freedesktop.org or wherever you feel like). - You add a gitlab CI target to autobuild the very nice kerneldoc you've created. Feel free to also do this with anything else you're familiar with, it's just I know gitlab and it's real simple to get a few docs autogenerated and published with it. - We add a todo.rst patch linking to your branch and the docs and a few lines on how to best convert an fbdev driver over to kms/atomic. And all the drivers would land the usual way, like any of the other drivers we've added to drivers/gpu/drm over the past few years. Thoughts? Cheers, Daniel > > v2: > * rename to fbconv helpers > * rewrite as helper library > * switch over to simple KMS helpers > * switch over to SHMEM > * add documentation > > [1] https://gitlab.freedesktop.org/tzimmermann/linux/commits/fbconv-plus-drivers > > Thomas Zimmermann (15): > fbdev: Export fb_check_foreignness() > fbdev: Export FBPIXMAPSIZE > drm/simple-kms-helper: Add mode_fixup() to simple display pipe > drm: Add fbconv helper module > drm/fbconv: Add DRM <-> fbdev pixel-format conversion > drm/fbconv: Add mode conversion DRM <-> fbdev > drm/fbconv: Add modesetting infrastructure > drm/fbconv: Add plane-state check and update > drm/fbconv: Mode-setting pipeline enable / disable > drm/fbconv: Reimplement several fbdev interfaces > drm/fbconv: Add helpers for init and cleanup of fb_info structures > drm/fbconv: Add helper documentation > staging: Add mgakms driver > staging/mgakms: Import matroxfb driver source code > staging/mgakms: Update matroxfb driver code for DRM > > Documentation/gpu/drm-kms-helpers.rst | 12 + > Documentation/gpu/todo.rst | 15 + > drivers/gpu/drm/Kconfig | 11 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/drm_fbconv_helper.c | 2126 +++++++++++++++++ > drivers/gpu/drm/drm_simple_kms_helper.c | 15 + > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/mgakms/Kconfig | 18 + > drivers/staging/mgakms/Makefile | 17 + > drivers/staging/mgakms/g450_pll.c | 539 +++++ > drivers/staging/mgakms/g450_pll.h | 13 + > drivers/staging/mgakms/i2c-matroxfb.c | 238 ++ > drivers/staging/mgakms/matroxfb_DAC1064.c | 1082 +++++++++ > drivers/staging/mgakms/matroxfb_DAC1064.h | 174 ++ > drivers/staging/mgakms/matroxfb_Ti3026.c | 746 ++++++ > drivers/staging/mgakms/matroxfb_Ti3026.h | 10 + > drivers/staging/mgakms/matroxfb_accel.c | 519 +++++ > drivers/staging/mgakms/matroxfb_accel.h | 9 + > drivers/staging/mgakms/matroxfb_base.c | 2592 +++++++++++++++++++++ > drivers/staging/mgakms/matroxfb_base.h | 700 ++++++ > drivers/staging/mgakms/matroxfb_crtc2.h | 35 + > drivers/staging/mgakms/matroxfb_g450.c | 640 +++++ > drivers/staging/mgakms/matroxfb_g450.h | 10 + > drivers/staging/mgakms/matroxfb_maven.h | 21 + > drivers/staging/mgakms/matroxfb_misc.c | 815 +++++++ > drivers/staging/mgakms/matroxfb_misc.h | 22 + > drivers/staging/mgakms/mga_device.c | 68 + > drivers/staging/mgakms/mga_device.h | 30 + > drivers/staging/mgakms/mga_drv.c | 129 + > drivers/staging/mgakms/mga_drv.h | 14 + > drivers/video/fbdev/core/fbmem.c | 5 +- > include/drm/drm_fbconv_helper.h | 150 ++ > include/drm/drm_simple_kms_helper.h | 43 + > include/linux/fb.h | 3 + > 35 files changed, 10822 insertions(+), 3 deletions(-) > create mode 100644 drivers/gpu/drm/drm_fbconv_helper.c > create mode 100644 drivers/staging/mgakms/Kconfig > create mode 100644 drivers/staging/mgakms/Makefile > create mode 100644 drivers/staging/mgakms/g450_pll.c > create mode 100644 drivers/staging/mgakms/g450_pll.h > create mode 100644 drivers/staging/mgakms/i2c-matroxfb.c > create mode 100644 drivers/staging/mgakms/matroxfb_DAC1064.c > create mode 100644 drivers/staging/mgakms/matroxfb_DAC1064.h > create mode 100644 drivers/staging/mgakms/matroxfb_Ti3026.c > create mode 100644 drivers/staging/mgakms/matroxfb_Ti3026.h > create mode 100644 drivers/staging/mgakms/matroxfb_accel.c > create mode 100644 drivers/staging/mgakms/matroxfb_accel.h > create mode 100644 drivers/staging/mgakms/matroxfb_base.c > create mode 100644 drivers/staging/mgakms/matroxfb_base.h > create mode 100644 drivers/staging/mgakms/matroxfb_crtc2.h > create mode 100644 drivers/staging/mgakms/matroxfb_g450.c > create mode 100644 drivers/staging/mgakms/matroxfb_g450.h > create mode 100644 drivers/staging/mgakms/matroxfb_maven.h > create mode 100644 drivers/staging/mgakms/matroxfb_misc.c > create mode 100644 drivers/staging/mgakms/matroxfb_misc.h > create mode 100644 drivers/staging/mgakms/mga_device.c > create mode 100644 drivers/staging/mgakms/mga_device.h > create mode 100644 drivers/staging/mgakms/mga_drv.c > create mode 100644 drivers/staging/mgakms/mga_drv.h > create mode 100644 include/drm/drm_fbconv_helper.h > > -- > 2.23.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch> To: Thomas Zimmermann <tzimmermann@suse.de> Cc: linux-fbdev@vger.kernel.org, b.zolnierkie@samsung.com, airlied@linux.ie, gregkh@linuxfoundation.org, michel@daenzer.net, corbet@lwn.net, malat@debian.org, dri-devel@lists.freedesktop.org, sean@poorly.run Subject: Re: [PATCH v2 00/15] DRM fbconv helpers for converting fbdev drivers Date: Tue, 15 Oct 2019 16:33:18 +0200 [thread overview] Message-ID: <20191015143318.GP11828@phenom.ffwll.local> (raw) In-Reply-To: <20191014140416.28517-1-tzimmermann@suse.de> Hi Thomas, On Mon, Oct 14, 2019 at 04:04:01PM +0200, Thomas Zimmermann wrote: > (was: DRM driver for fbdev devices) > > This is version 2 of the fbdev conversion helpers. It's more or less a > rewrite of the original patchset. > > The fbdev subsystem is considered legacy and will probably be removed at > some point. This would mean the loss of a signifanct number of drivers. > Some of the affected hardware is not in use any longer, but some hardware > is still around and provides good(-enough) framebuffers. > > The fbconv helpers allow for running the current DRM stack on top of fbdev > drivers. It's a set of functions that convert between fbdev interfaces and > DRM interfaces. Based on SHMEM and simple KMS helpers, it only offers the > basic functionality of a framebuffer, but should be compatible with most > existing fbdev drivers. > > A DRM driver using fbconv helpers consists of > > * DRM stub code that calls into fbconv helpers, and > * the original fbdev driver code. > > The fbdev driver code has to be modified to register itself with the > stub driver instead of the fbdev core framework. A tutorial on how to use > the helpers is part of this patchset. The resulting driver hybrid can be > refactored into a first-class DRM driver. The fbconv helpers contain a > number of comments, labeled 'DRM porting note', which explain the required > steps. > > I tested the current patchset with the following drivers: atyfb, aty128fb, > matroxfb, pm2fb, pm3fb, rivafb, s3fb, savagefb, sisfb, tdfxfb and tridentfb. > With each, I was able to successfully start with fbcon enabled, run weston and > X11. The drivers are available at [1]. For reference, the patchset includes > the Matrox stub driver. So I really don't want to rain on the parade here, since if you think this is useful when converting fbdev drivers I'll buy that, and I'm all for getting more modern drivers into drm. But I have a bunch of concerns with the approach you're proposing here: - we've tried staging for drm driver refactoring, it hurts. Separate tree plus the quick pace in refactoring create lots of pains. And for small drivers refacotoring before it's not buying you anything above refactoring in your own personal tree. And for big drivers we're fairly lenient with merging drivers that aren't fully polished yet, if there's a team serious enough with cleaning up the mess. I think even merging partial drivers directly under drivers/gpu (but behind CONFIG_BROKEN) is better than staging. - we've had conversion helpers before (for the legacy kms -> atomic upgrade). They constantly broke, pretty much every release when someone wanted to use them they first had to fix them up again. I think having those helpers is good, but better to just have them in some branch somewhere where it's clear that they might not work anymore on latest upstream. - especially for some of these simple fbdev drivers I feel like just typing a new driver from scratch might be simpler. A few more concerns specifically for your mga example: - We already have a mga driver. Might be better to integrate support for older mgas into that than have a parallel driver. - Your helper is based on simple display pipe, and I think for these old mga chips (especially the dual pipe mga 450 and 550) simple display pipe helper is more a hindering detour than actual help. From a quick read through the code (especially all the custom ioctls) you definitely want separate TV-out connector to expose all the tv mode properties (instead of the custom ioctls). - On the topic of ioctls, looks like we could add FBIOGET_VBLANK to our generic implementation in the fbdev helpers. So here's my alternative proposal: - You push this as a branch onto a gitlab repo (freedesktop.org or wherever you feel like). - You add a gitlab CI target to autobuild the very nice kerneldoc you've created. Feel free to also do this with anything else you're familiar with, it's just I know gitlab and it's real simple to get a few docs autogenerated and published with it. - We add a todo.rst patch linking to your branch and the docs and a few lines on how to best convert an fbdev driver over to kms/atomic. And all the drivers would land the usual way, like any of the other drivers we've added to drivers/gpu/drm over the past few years. Thoughts? Cheers, Daniel > > v2: > * rename to fbconv helpers > * rewrite as helper library > * switch over to simple KMS helpers > * switch over to SHMEM > * add documentation > > [1] https://gitlab.freedesktop.org/tzimmermann/linux/commits/fbconv-plus-drivers > > Thomas Zimmermann (15): > fbdev: Export fb_check_foreignness() > fbdev: Export FBPIXMAPSIZE > drm/simple-kms-helper: Add mode_fixup() to simple display pipe > drm: Add fbconv helper module > drm/fbconv: Add DRM <-> fbdev pixel-format conversion > drm/fbconv: Add mode conversion DRM <-> fbdev > drm/fbconv: Add modesetting infrastructure > drm/fbconv: Add plane-state check and update > drm/fbconv: Mode-setting pipeline enable / disable > drm/fbconv: Reimplement several fbdev interfaces > drm/fbconv: Add helpers for init and cleanup of fb_info structures > drm/fbconv: Add helper documentation > staging: Add mgakms driver > staging/mgakms: Import matroxfb driver source code > staging/mgakms: Update matroxfb driver code for DRM > > Documentation/gpu/drm-kms-helpers.rst | 12 + > Documentation/gpu/todo.rst | 15 + > drivers/gpu/drm/Kconfig | 11 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/drm_fbconv_helper.c | 2126 +++++++++++++++++ > drivers/gpu/drm/drm_simple_kms_helper.c | 15 + > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/mgakms/Kconfig | 18 + > drivers/staging/mgakms/Makefile | 17 + > drivers/staging/mgakms/g450_pll.c | 539 +++++ > drivers/staging/mgakms/g450_pll.h | 13 + > drivers/staging/mgakms/i2c-matroxfb.c | 238 ++ > drivers/staging/mgakms/matroxfb_DAC1064.c | 1082 +++++++++ > drivers/staging/mgakms/matroxfb_DAC1064.h | 174 ++ > drivers/staging/mgakms/matroxfb_Ti3026.c | 746 ++++++ > drivers/staging/mgakms/matroxfb_Ti3026.h | 10 + > drivers/staging/mgakms/matroxfb_accel.c | 519 +++++ > drivers/staging/mgakms/matroxfb_accel.h | 9 + > drivers/staging/mgakms/matroxfb_base.c | 2592 +++++++++++++++++++++ > drivers/staging/mgakms/matroxfb_base.h | 700 ++++++ > drivers/staging/mgakms/matroxfb_crtc2.h | 35 + > drivers/staging/mgakms/matroxfb_g450.c | 640 +++++ > drivers/staging/mgakms/matroxfb_g450.h | 10 + > drivers/staging/mgakms/matroxfb_maven.h | 21 + > drivers/staging/mgakms/matroxfb_misc.c | 815 +++++++ > drivers/staging/mgakms/matroxfb_misc.h | 22 + > drivers/staging/mgakms/mga_device.c | 68 + > drivers/staging/mgakms/mga_device.h | 30 + > drivers/staging/mgakms/mga_drv.c | 129 + > drivers/staging/mgakms/mga_drv.h | 14 + > drivers/video/fbdev/core/fbmem.c | 5 +- > include/drm/drm_fbconv_helper.h | 150 ++ > include/drm/drm_simple_kms_helper.h | 43 + > include/linux/fb.h | 3 + > 35 files changed, 10822 insertions(+), 3 deletions(-) > create mode 100644 drivers/gpu/drm/drm_fbconv_helper.c > create mode 100644 drivers/staging/mgakms/Kconfig > create mode 100644 drivers/staging/mgakms/Makefile > create mode 100644 drivers/staging/mgakms/g450_pll.c > create mode 100644 drivers/staging/mgakms/g450_pll.h > create mode 100644 drivers/staging/mgakms/i2c-matroxfb.c > create mode 100644 drivers/staging/mgakms/matroxfb_DAC1064.c > create mode 100644 drivers/staging/mgakms/matroxfb_DAC1064.h > create mode 100644 drivers/staging/mgakms/matroxfb_Ti3026.c > create mode 100644 drivers/staging/mgakms/matroxfb_Ti3026.h > create mode 100644 drivers/staging/mgakms/matroxfb_accel.c > create mode 100644 drivers/staging/mgakms/matroxfb_accel.h > create mode 100644 drivers/staging/mgakms/matroxfb_base.c > create mode 100644 drivers/staging/mgakms/matroxfb_base.h > create mode 100644 drivers/staging/mgakms/matroxfb_crtc2.h > create mode 100644 drivers/staging/mgakms/matroxfb_g450.c > create mode 100644 drivers/staging/mgakms/matroxfb_g450.h > create mode 100644 drivers/staging/mgakms/matroxfb_maven.h > create mode 100644 drivers/staging/mgakms/matroxfb_misc.c > create mode 100644 drivers/staging/mgakms/matroxfb_misc.h > create mode 100644 drivers/staging/mgakms/mga_device.c > create mode 100644 drivers/staging/mgakms/mga_device.h > create mode 100644 drivers/staging/mgakms/mga_drv.c > create mode 100644 drivers/staging/mgakms/mga_drv.h > create mode 100644 include/drm/drm_fbconv_helper.h > > -- > 2.23.0 > -- 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
next prev parent reply other threads:[~2019-10-15 14:33 UTC|newest] Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-14 14:04 [PATCH v2 00/15] DRM fbconv helpers for converting fbdev drivers Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-14 14:04 ` [PATCH v2 01/15] fbdev: Export fb_check_foreignness() Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-14 14:04 ` [PATCH v2 02/15] fbdev: Export FBPIXMAPSIZE Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-14 14:04 ` [PATCH v2 03/15] drm/simple-kms-helper: Add mode_fixup() to simple display pipe Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-14 14:04 ` [PATCH v2 04/15] drm: Add fbconv helper module Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-14 14:04 ` [PATCH v2 05/15] drm/fbconv: Add DRM <-> fbdev pixel-format conversion Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-14 20:30 ` Sam Ravnborg 2019-10-14 20:30 ` Sam Ravnborg 2019-10-15 5:48 ` Thomas Zimmermann 2019-10-15 5:48 ` Thomas Zimmermann 2019-10-14 14:04 ` [PATCH v2 06/15] drm/fbconv: Add mode conversion DRM <-> fbdev Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-14 14:04 ` [PATCH v2 07/15] drm/fbconv: Add modesetting infrastructure Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-14 14:04 ` [PATCH v2 08/15] drm/fbconv: Add plane-state check and update Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-15 8:30 ` kbuild test robot 2019-10-15 8:30 ` kbuild test robot 2019-10-15 8:30 ` kbuild test robot 2019-10-15 17:28 ` kbuild test robot 2019-10-15 17:28 ` kbuild test robot 2019-10-15 17:28 ` kbuild test robot 2019-10-14 14:04 ` [PATCH v2 09/15] drm/fbconv: Mode-setting pipeline enable / disable Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2022-05-28 20:17 ` Geert Uytterhoeven 2022-05-28 20:17 ` Geert Uytterhoeven 2022-05-30 7:47 ` Thomas Zimmermann 2022-05-30 7:47 ` Thomas Zimmermann 2022-05-30 8:34 ` Geert Uytterhoeven 2022-05-30 8:34 ` Geert Uytterhoeven 2022-07-01 20:01 ` Geert Uytterhoeven 2022-07-01 20:01 ` Geert Uytterhoeven 2019-10-14 14:04 ` [PATCH v2 10/15] drm/fbconv: Reimplement several fbdev interfaces Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-14 14:04 ` [PATCH v2 11/15] drm/fbconv: Add helpers for init and cleanup of fb_info structures Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-14 14:04 ` [PATCH v2 12/15] drm/fbconv: Add helper documentation Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-15 8:40 ` kbuild test robot 2019-10-15 8:40 ` kbuild test robot 2019-10-15 8:40 ` kbuild test robot 2019-10-14 14:04 ` [PATCH v2 13/15] staging: Add mgakms driver Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-14 14:04 ` [PATCH v2 14/15] staging/mgakms: Import matroxfb driver source code Thomas Zimmermann 2019-10-15 11:48 ` Ville Syrjälä 2019-10-15 11:48 ` Ville Syrjälä 2019-10-15 12:46 ` Thomas Zimmermann 2019-10-15 12:46 ` Thomas Zimmermann 2019-10-14 14:04 ` [PATCH v2 15/15] staging/mgakms: Update matroxfb driver code for DRM Thomas Zimmermann 2019-10-14 14:04 ` Thomas Zimmermann 2019-10-17 16:04 ` kbuild test robot 2019-10-17 16:04 ` kbuild test robot 2019-10-17 16:19 ` kbuild test robot 2019-10-17 16:19 ` kbuild test robot 2019-10-17 16:19 ` kbuild test robot 2019-10-14 20:36 ` [PATCH v2 00/15] DRM fbconv helpers for converting fbdev drivers Sam Ravnborg 2019-10-14 20:36 ` Sam Ravnborg 2019-10-15 6:11 ` Thomas Zimmermann 2019-10-15 6:11 ` Thomas Zimmermann 2019-10-15 14:33 ` Daniel Vetter [this message] 2019-10-15 14:33 ` Daniel Vetter 2019-10-15 17:28 ` Thomas Zimmermann 2019-10-15 17:28 ` Thomas Zimmermann 2019-10-15 17:48 ` Daniel Vetter 2019-10-15 17:48 ` Daniel Vetter 2019-10-15 18:05 ` Greg KH 2019-10-15 18:05 ` Greg KH 2019-10-15 18:13 ` Ville Syrjälä 2019-10-15 18:13 ` Ville Syrjälä 2019-10-15 18:28 ` Ville Syrjälä 2019-10-15 18:28 ` Ville Syrjälä
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191015143318.GP11828@phenom.ffwll.local \ --to=daniel@ffwll.ch \ --cc=airlied@linux.ie \ --cc=b.zolnierkie@samsung.com \ --cc=corbet@lwn.net \ --cc=dri-devel@lists.freedesktop.org \ --cc=gregkh@linuxfoundation.org \ --cc=linux-fbdev@vger.kernel.org \ --cc=malat@debian.org \ --cc=michel@daenzer.net \ --cc=sean@poorly.run \ --cc=tzimmermann@suse.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.