* [PATCH v2 0/2] drm: Support framebuffer panning @ 2017-02-02 10:31 ` Maxime Ripard 0 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-02 10:31 UTC (permalink / raw) To: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul Cc: dri-devel, linux-kernel, Stefan Christ, Maxime Ripard Hi, This is a respin of the previous serie called "Support fast framebuffer panning for i.MX6" made by Stefan 6 monthes ago. The imx6 bits have been removed, and the comments that were made at that time fixed (hopefully). Let me know what you think, Maxime Changes from v1: - Added drm_fb_helper_ioctl to DRM_FB_HELPER_DEFAULT_OPS - Expanded a bit the kerneldoc for drm_fb_helper_ioctl - Added some locking to drm_fb_helper_ioctl - Checked that the framebuffer is indeed attached before allowing ioctl - Added a module parameter to specify the number of framebuffers to allocate Initial cover letter: Support fast framebuffer panning for i.MX6 im currently working on supporting double/tripple buffering for the framebuffer emulation on the i.MX6. While working on it I noticed that the mainline kernel does not support some features in the generic drm framebuffer emulation for framebuffer panning and vsync synchronisation. They are needed for simple framebuffer applications and some OpenGL libraries using double buffering with FBIOPUT_VSCREENINFO, FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY. Stefan Christ (1): drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC Xinliang Liu (1): drm/cma-helper: Add multi buffer support for cma fbdev drivers/gpu/drm/Kconfig | 8 ++++- drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++- drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++- include/drm/drm_fb_helper.h | 5 ++- 4 files changed, 74 insertions(+), 2 deletions(-) base-commit: 8b394ae674998d4ade6cb48aec3fca5445908dfe -- git-series 0.8.11 ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 0/2] drm: Support framebuffer panning @ 2017-02-02 10:31 ` Maxime Ripard 0 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-02 10:31 UTC (permalink / raw) To: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul Cc: Maxime Ripard, Stefan Christ, linux-kernel, dri-devel Hi, This is a respin of the previous serie called "Support fast framebuffer panning for i.MX6" made by Stefan 6 monthes ago. The imx6 bits have been removed, and the comments that were made at that time fixed (hopefully). Let me know what you think, Maxime Changes from v1: - Added drm_fb_helper_ioctl to DRM_FB_HELPER_DEFAULT_OPS - Expanded a bit the kerneldoc for drm_fb_helper_ioctl - Added some locking to drm_fb_helper_ioctl - Checked that the framebuffer is indeed attached before allowing ioctl - Added a module parameter to specify the number of framebuffers to allocate Initial cover letter: Support fast framebuffer panning for i.MX6 im currently working on supporting double/tripple buffering for the framebuffer emulation on the i.MX6. While working on it I noticed that the mainline kernel does not support some features in the generic drm framebuffer emulation for framebuffer panning and vsync synchronisation. They are needed for simple framebuffer applications and some OpenGL libraries using double buffering with FBIOPUT_VSCREENINFO, FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY. Stefan Christ (1): drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC Xinliang Liu (1): drm/cma-helper: Add multi buffer support for cma fbdev drivers/gpu/drm/Kconfig | 8 ++++- drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++- drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++- include/drm/drm_fb_helper.h | 5 ++- 4 files changed, 74 insertions(+), 2 deletions(-) base-commit: 8b394ae674998d4ade6cb48aec3fca5445908dfe -- git-series 0.8.11 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-02 10:31 ` Maxime Ripard @ 2017-02-02 10:31 ` Maxime Ripard -1 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-02 10:31 UTC (permalink / raw) To: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul Cc: dri-devel, linux-kernel, Stefan Christ, Maxime Ripard, Xinliang Liu From: Xinliang Liu <xinliang.liu@linaro.org> This patch add a config to support to create multi buffer for cma fbdev. Such as double buffer and triple buffer. Cma fbdev is convient to add a legency fbdev. And still many Android devices use fbdev now and at least double buffer is needed for these Android devices, so that a buffer flip can be operated. It will need some time for Android device vendors to abondon legency fbdev. So multi buffer for fbdev is needed. Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> [s.christ@phytec.de: Picking patch from https://lkml.org/lkml/2015/9/14/188] Signed-off-by: Stefan Christ <s.christ@phytec.de> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> --- drivers/gpu/drm/Kconfig | 8 ++++++++ drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++++++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index ebfe8404c25f..2ca9bb26a4e4 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER help Choose this if you need the KMS CMA helper functions +config DRM_CMA_FBDEV_BUFFER_NUM + int "Cma Fbdev Buffer Number" + depends on DRM_KMS_CMA_HELPER + default 1 + help + Defines the buffer number of cma fbdev. Default is one buffer. + For double buffer please set to 2 and 3 for triple buffer. + source "drivers/gpu/drm/i2c/Kconfig" source "drivers/gpu/drm/arm/Kconfig" diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c index 81b3558302b5..e3f8b9e720a0 100644 --- a/drivers/gpu/drm/drm_fb_cma_helper.c +++ b/drivers/gpu/drm/drm_fb_cma_helper.c @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi) kfree(fbi->fbops); } +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM; +module_param(fbdev_num_buffers, int, 0444); +MODULE_PARM_DESC(fbdev_num_buffers, + "Number of frame buffers to allocate [default=" + __MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]"); + /* * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function that * needs custom struct drm_framebuffer_funcs, like dirty() for deferred_io use. @@ -437,7 +443,7 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper, bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8); mode_cmd.width = sizes->surface_width; - mode_cmd.height = sizes->surface_height; + mode_cmd.height = sizes->surface_height * fbdev_num_buffers; mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel; mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, sizes->surface_depth); -- git-series 0.8.11 ^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev @ 2017-02-02 10:31 ` Maxime Ripard 0 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-02 10:31 UTC (permalink / raw) To: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul Cc: Maxime Ripard, Stefan Christ, linux-kernel, dri-devel From: Xinliang Liu <xinliang.liu@linaro.org> This patch add a config to support to create multi buffer for cma fbdev. Such as double buffer and triple buffer. Cma fbdev is convient to add a legency fbdev. And still many Android devices use fbdev now and at least double buffer is needed for these Android devices, so that a buffer flip can be operated. It will need some time for Android device vendors to abondon legency fbdev. So multi buffer for fbdev is needed. Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> [s.christ@phytec.de: Picking patch from https://lkml.org/lkml/2015/9/14/188] Signed-off-by: Stefan Christ <s.christ@phytec.de> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> --- drivers/gpu/drm/Kconfig | 8 ++++++++ drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++++++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index ebfe8404c25f..2ca9bb26a4e4 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER help Choose this if you need the KMS CMA helper functions +config DRM_CMA_FBDEV_BUFFER_NUM + int "Cma Fbdev Buffer Number" + depends on DRM_KMS_CMA_HELPER + default 1 + help + Defines the buffer number of cma fbdev. Default is one buffer. + For double buffer please set to 2 and 3 for triple buffer. + source "drivers/gpu/drm/i2c/Kconfig" source "drivers/gpu/drm/arm/Kconfig" diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c index 81b3558302b5..e3f8b9e720a0 100644 --- a/drivers/gpu/drm/drm_fb_cma_helper.c +++ b/drivers/gpu/drm/drm_fb_cma_helper.c @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi) kfree(fbi->fbops); } +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM; +module_param(fbdev_num_buffers, int, 0444); +MODULE_PARM_DESC(fbdev_num_buffers, + "Number of frame buffers to allocate [default=" + __MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]"); + /* * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function that * needs custom struct drm_framebuffer_funcs, like dirty() for deferred_io use. @@ -437,7 +443,7 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper, bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8); mode_cmd.width = sizes->surface_width; - mode_cmd.height = sizes->surface_height; + mode_cmd.height = sizes->surface_height * fbdev_num_buffers; mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel; mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, sizes->surface_depth); -- git-series 0.8.11 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-02 10:31 ` Maxime Ripard @ 2017-02-09 17:04 ` Daniel Vetter -1 siblings, 0 replies; 44+ messages in thread From: Daniel Vetter @ 2017-02-09 17:04 UTC (permalink / raw) To: Maxime Ripard Cc: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, linux-kernel, dri-devel On Thu, Feb 02, 2017 at 11:31:56AM +0100, Maxime Ripard wrote: > From: Xinliang Liu <xinliang.liu@linaro.org> > > This patch add a config to support to create multi buffer for cma fbdev. > Such as double buffer and triple buffer. > > Cma fbdev is convient to add a legency fbdev. And still many Android > devices use fbdev now and at least double buffer is needed for these > Android devices, so that a buffer flip can be operated. It will need > some time for Android device vendors to abondon legency fbdev. So multi > buffer for fbdev is needed. > > Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> > [s.christ@phytec.de: Picking patch from > https://lkml.org/lkml/2015/9/14/188] > Signed-off-by: Stefan Christ <s.christ@phytec.de> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/gpu/drm/Kconfig | 8 ++++++++ > drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++++++- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index ebfe8404c25f..2ca9bb26a4e4 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER > help > Choose this if you need the KMS CMA helper functions > > +config DRM_CMA_FBDEV_BUFFER_NUM > + int "Cma Fbdev Buffer Number" > + depends on DRM_KMS_CMA_HELPER > + default 1 > + help > + Defines the buffer number of cma fbdev. Default is one buffer. > + For double buffer please set to 2 and 3 for triple buffer. > + > source "drivers/gpu/drm/i2c/Kconfig" > > source "drivers/gpu/drm/arm/Kconfig" > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c > index 81b3558302b5..e3f8b9e720a0 100644 > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi) > kfree(fbi->fbops); > } > > +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM; > +module_param(fbdev_num_buffers, int, 0444); > +MODULE_PARM_DESC(fbdev_num_buffers, > + "Number of frame buffers to allocate [default=" > + __MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]"); Pure bikshed: Should this be an overallocation %? 200 for double-buffering, 100 as the default? Slightly less bikesheddy: Can't we do this in the core helpers somehow? I'd be nice if this is not cma specific. If it's not possible, I'd at least move the symbol to drm_fb_helper.c, and add some kernel-doc around it. That allows any other non-cma driver to at least implement support for this. That also has the benefit of featuring it more prominently, in our docs. Besides these bikesheds/question, looks all reasonable to me. If you can get some more acks would be great, but will merge anyway. -Daniel > + > /* > * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function that > * needs custom struct drm_framebuffer_funcs, like dirty() for deferred_io use. > @@ -437,7 +443,7 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper, > bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8); > > mode_cmd.width = sizes->surface_width; > - mode_cmd.height = sizes->surface_height; > + mode_cmd.height = sizes->surface_height * fbdev_num_buffers; > mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel; > mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, > sizes->surface_depth); > -- > git-series 0.8.11 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev @ 2017-02-09 17:04 ` Daniel Vetter 0 siblings, 0 replies; 44+ messages in thread From: Daniel Vetter @ 2017-02-09 17:04 UTC (permalink / raw) To: Maxime Ripard; +Cc: linux-kernel, dri-devel, Daniel Vetter, Stefan Christ On Thu, Feb 02, 2017 at 11:31:56AM +0100, Maxime Ripard wrote: > From: Xinliang Liu <xinliang.liu@linaro.org> > > This patch add a config to support to create multi buffer for cma fbdev. > Such as double buffer and triple buffer. > > Cma fbdev is convient to add a legency fbdev. And still many Android > devices use fbdev now and at least double buffer is needed for these > Android devices, so that a buffer flip can be operated. It will need > some time for Android device vendors to abondon legency fbdev. So multi > buffer for fbdev is needed. > > Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> > [s.christ@phytec.de: Picking patch from > https://lkml.org/lkml/2015/9/14/188] > Signed-off-by: Stefan Christ <s.christ@phytec.de> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/gpu/drm/Kconfig | 8 ++++++++ > drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++++++- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index ebfe8404c25f..2ca9bb26a4e4 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER > help > Choose this if you need the KMS CMA helper functions > > +config DRM_CMA_FBDEV_BUFFER_NUM > + int "Cma Fbdev Buffer Number" > + depends on DRM_KMS_CMA_HELPER > + default 1 > + help > + Defines the buffer number of cma fbdev. Default is one buffer. > + For double buffer please set to 2 and 3 for triple buffer. > + > source "drivers/gpu/drm/i2c/Kconfig" > > source "drivers/gpu/drm/arm/Kconfig" > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c > index 81b3558302b5..e3f8b9e720a0 100644 > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi) > kfree(fbi->fbops); > } > > +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM; > +module_param(fbdev_num_buffers, int, 0444); > +MODULE_PARM_DESC(fbdev_num_buffers, > + "Number of frame buffers to allocate [default=" > + __MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]"); Pure bikshed: Should this be an overallocation %? 200 for double-buffering, 100 as the default? Slightly less bikesheddy: Can't we do this in the core helpers somehow? I'd be nice if this is not cma specific. If it's not possible, I'd at least move the symbol to drm_fb_helper.c, and add some kernel-doc around it. That allows any other non-cma driver to at least implement support for this. That also has the benefit of featuring it more prominently, in our docs. Besides these bikesheds/question, looks all reasonable to me. If you can get some more acks would be great, but will merge anyway. -Daniel > + > /* > * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function that > * needs custom struct drm_framebuffer_funcs, like dirty() for deferred_io use. > @@ -437,7 +443,7 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper, > bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8); > > mode_cmd.width = sizes->surface_width; > - mode_cmd.height = sizes->surface_height; > + mode_cmd.height = sizes->surface_height * fbdev_num_buffers; > mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel; > mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, > sizes->surface_depth); > -- > git-series 0.8.11 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-09 17:04 ` Daniel Vetter @ 2017-02-10 15:27 ` Maxime Ripard -1 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-10 15:27 UTC (permalink / raw) To: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, linux-kernel, dri-devel [-- Attachment #1: Type: text/plain, Size: 3314 bytes --] Hi Daniel, On Thu, Feb 09, 2017 at 06:04:38PM +0100, Daniel Vetter wrote: > On Thu, Feb 02, 2017 at 11:31:56AM +0100, Maxime Ripard wrote: > > From: Xinliang Liu <xinliang.liu@linaro.org> > > > > This patch add a config to support to create multi buffer for cma fbdev. > > Such as double buffer and triple buffer. > > > > Cma fbdev is convient to add a legency fbdev. And still many Android > > devices use fbdev now and at least double buffer is needed for these > > Android devices, so that a buffer flip can be operated. It will need > > some time for Android device vendors to abondon legency fbdev. So multi > > buffer for fbdev is needed. > > > > Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> > > [s.christ@phytec.de: Picking patch from > > https://lkml.org/lkml/2015/9/14/188] > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > --- > > drivers/gpu/drm/Kconfig | 8 ++++++++ > > drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++++++- > > 2 files changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > > index ebfe8404c25f..2ca9bb26a4e4 100644 > > --- a/drivers/gpu/drm/Kconfig > > +++ b/drivers/gpu/drm/Kconfig > > @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER > > help > > Choose this if you need the KMS CMA helper functions > > > > +config DRM_CMA_FBDEV_BUFFER_NUM > > + int "Cma Fbdev Buffer Number" > > + depends on DRM_KMS_CMA_HELPER > > + default 1 > > + help > > + Defines the buffer number of cma fbdev. Default is one buffer. > > + For double buffer please set to 2 and 3 for triple buffer. > > + > > source "drivers/gpu/drm/i2c/Kconfig" > > > > source "drivers/gpu/drm/arm/Kconfig" > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c > > index 81b3558302b5..e3f8b9e720a0 100644 > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > > @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi) > > kfree(fbi->fbops); > > } > > > > +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM; > > +module_param(fbdev_num_buffers, int, 0444); > > +MODULE_PARM_DESC(fbdev_num_buffers, > > + "Number of frame buffers to allocate [default=" > > + __MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]"); > > Pure bikshed: Should this be an overallocation %? 200 for > double-buffering, 100 as the default? I'm not against it, but would it make sense to allocate something like 120% of a buffer? > Slightly less bikesheddy: Can't we do this in the core helpers somehow? I guess that would move it to drm_fb_helper_single_fb_probe then? It makes sense. > I'd be nice if this is not cma specific. If it's not possible, I'd at > least move the symbol to drm_fb_helper.c, and add some kernel-doc around > it. That allows any other non-cma driver to at least implement support for > this. That also has the benefit of featuring it more prominently, in our > docs. I'll move it and add the kerneldoc. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev @ 2017-02-10 15:27 ` Maxime Ripard 0 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-10 15:27 UTC (permalink / raw) To: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, linux-kernel, dri-devel [-- Attachment #1.1: Type: text/plain, Size: 3314 bytes --] Hi Daniel, On Thu, Feb 09, 2017 at 06:04:38PM +0100, Daniel Vetter wrote: > On Thu, Feb 02, 2017 at 11:31:56AM +0100, Maxime Ripard wrote: > > From: Xinliang Liu <xinliang.liu@linaro.org> > > > > This patch add a config to support to create multi buffer for cma fbdev. > > Such as double buffer and triple buffer. > > > > Cma fbdev is convient to add a legency fbdev. And still many Android > > devices use fbdev now and at least double buffer is needed for these > > Android devices, so that a buffer flip can be operated. It will need > > some time for Android device vendors to abondon legency fbdev. So multi > > buffer for fbdev is needed. > > > > Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> > > [s.christ@phytec.de: Picking patch from > > https://lkml.org/lkml/2015/9/14/188] > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > --- > > drivers/gpu/drm/Kconfig | 8 ++++++++ > > drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++++++- > > 2 files changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > > index ebfe8404c25f..2ca9bb26a4e4 100644 > > --- a/drivers/gpu/drm/Kconfig > > +++ b/drivers/gpu/drm/Kconfig > > @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER > > help > > Choose this if you need the KMS CMA helper functions > > > > +config DRM_CMA_FBDEV_BUFFER_NUM > > + int "Cma Fbdev Buffer Number" > > + depends on DRM_KMS_CMA_HELPER > > + default 1 > > + help > > + Defines the buffer number of cma fbdev. Default is one buffer. > > + For double buffer please set to 2 and 3 for triple buffer. > > + > > source "drivers/gpu/drm/i2c/Kconfig" > > > > source "drivers/gpu/drm/arm/Kconfig" > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c > > index 81b3558302b5..e3f8b9e720a0 100644 > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > > @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi) > > kfree(fbi->fbops); > > } > > > > +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM; > > +module_param(fbdev_num_buffers, int, 0444); > > +MODULE_PARM_DESC(fbdev_num_buffers, > > + "Number of frame buffers to allocate [default=" > > + __MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]"); > > Pure bikshed: Should this be an overallocation %? 200 for > double-buffering, 100 as the default? I'm not against it, but would it make sense to allocate something like 120% of a buffer? > Slightly less bikesheddy: Can't we do this in the core helpers somehow? I guess that would move it to drm_fb_helper_single_fb_probe then? It makes sense. > I'd be nice if this is not cma specific. If it's not possible, I'd at > least move the symbol to drm_fb_helper.c, and add some kernel-doc around > it. That allows any other non-cma driver to at least implement support for > this. That also has the benefit of featuring it more prominently, in our > docs. I'll move it and add the kerneldoc. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-02 10:31 ` Maxime Ripard @ 2017-02-12 12:28 ` Laurent Pinchart -1 siblings, 0 replies; 44+ messages in thread From: Laurent Pinchart @ 2017-02-12 12:28 UTC (permalink / raw) To: dri-devel Cc: Maxime Ripard, Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, linux-kernel Hi Maxime, Thank you for the patch. On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > From: Xinliang Liu <xinliang.liu@linaro.org> > > This patch add a config to support to create multi buffer for cma fbdev. > Such as double buffer and triple buffer. > > Cma fbdev is convient to add a legency fbdev. And still many Android > devices use fbdev now and at least double buffer is needed for these > Android devices, so that a buffer flip can be operated. It will need > some time for Android device vendors to abondon legency fbdev. So multi > buffer for fbdev is needed. How exactly do we expect Android to move away from fbdev if we add features to the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a thing from the past and that they'd better migrate now. > Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> > [s.christ@phytec.de: Picking patch from > https://lkml.org/lkml/2015/9/14/188] > Signed-off-by: Stefan Christ <s.christ@phytec.de> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/gpu/drm/Kconfig | 8 ++++++++ > drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++++++- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index ebfe8404c25f..2ca9bb26a4e4 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER > help > Choose this if you need the KMS CMA helper functions > > +config DRM_CMA_FBDEV_BUFFER_NUM > + int "Cma Fbdev Buffer Number" > + depends on DRM_KMS_CMA_HELPER > + default 1 > + help > + Defines the buffer number of cma fbdev. Default is one buffer. > + For double buffer please set to 2 and 3 for triple buffer. > + > source "drivers/gpu/drm/i2c/Kconfig" > > source "drivers/gpu/drm/arm/Kconfig" > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c > b/drivers/gpu/drm/drm_fb_cma_helper.c index 81b3558302b5..e3f8b9e720a0 > 100644 > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info > *fbi) kfree(fbi->fbops); > } > > +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM; > +module_param(fbdev_num_buffers, int, 0444); > +MODULE_PARM_DESC(fbdev_num_buffers, > + "Number of frame buffers to allocate [default=" > + __MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]"); > + > /* > * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function > that * needs custom struct drm_framebuffer_funcs, like dirty() for > deferred_io use. @@ -437,7 +443,7 @@ int > drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper, > bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8); > > mode_cmd.width = sizes->surface_width; > - mode_cmd.height = sizes->surface_height; > + mode_cmd.height = sizes->surface_height * fbdev_num_buffers; > mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel; > mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, > sizes->surface_depth); -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev @ 2017-02-12 12:28 ` Laurent Pinchart 0 siblings, 0 replies; 44+ messages in thread From: Laurent Pinchart @ 2017-02-12 12:28 UTC (permalink / raw) To: dri-devel; +Cc: linux-kernel, Daniel Vetter, Maxime Ripard, Stefan Christ Hi Maxime, Thank you for the patch. On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > From: Xinliang Liu <xinliang.liu@linaro.org> > > This patch add a config to support to create multi buffer for cma fbdev. > Such as double buffer and triple buffer. > > Cma fbdev is convient to add a legency fbdev. And still many Android > devices use fbdev now and at least double buffer is needed for these > Android devices, so that a buffer flip can be operated. It will need > some time for Android device vendors to abondon legency fbdev. So multi > buffer for fbdev is needed. How exactly do we expect Android to move away from fbdev if we add features to the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a thing from the past and that they'd better migrate now. > Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> > [s.christ@phytec.de: Picking patch from > https://lkml.org/lkml/2015/9/14/188] > Signed-off-by: Stefan Christ <s.christ@phytec.de> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/gpu/drm/Kconfig | 8 ++++++++ > drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++++++- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index ebfe8404c25f..2ca9bb26a4e4 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER > help > Choose this if you need the KMS CMA helper functions > > +config DRM_CMA_FBDEV_BUFFER_NUM > + int "Cma Fbdev Buffer Number" > + depends on DRM_KMS_CMA_HELPER > + default 1 > + help > + Defines the buffer number of cma fbdev. Default is one buffer. > + For double buffer please set to 2 and 3 for triple buffer. > + > source "drivers/gpu/drm/i2c/Kconfig" > > source "drivers/gpu/drm/arm/Kconfig" > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c > b/drivers/gpu/drm/drm_fb_cma_helper.c index 81b3558302b5..e3f8b9e720a0 > 100644 > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info > *fbi) kfree(fbi->fbops); > } > > +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM; > +module_param(fbdev_num_buffers, int, 0444); > +MODULE_PARM_DESC(fbdev_num_buffers, > + "Number of frame buffers to allocate [default=" > + __MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]"); > + > /* > * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function > that * needs custom struct drm_framebuffer_funcs, like dirty() for > deferred_io use. @@ -437,7 +443,7 @@ int > drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper, > bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8); > > mode_cmd.width = sizes->surface_width; > - mode_cmd.height = sizes->surface_height; > + mode_cmd.height = sizes->surface_height * fbdev_num_buffers; > mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel; > mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, > sizes->surface_depth); -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-12 12:28 ` Laurent Pinchart @ 2017-02-13 10:54 ` Maxime Ripard -1 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-13 10:54 UTC (permalink / raw) To: Laurent Pinchart Cc: dri-devel, Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2228 bytes --] Hi Laurent, On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > Hi Maxime, > > Thank you for the patch. > > On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > > From: Xinliang Liu <xinliang.liu@linaro.org> > > > > This patch add a config to support to create multi buffer for cma fbdev. > > Such as double buffer and triple buffer. > > > > Cma fbdev is convient to add a legency fbdev. And still many Android > > devices use fbdev now and at least double buffer is needed for these > > Android devices, so that a buffer flip can be operated. It will need > > some time for Android device vendors to abondon legency fbdev. So multi > > buffer for fbdev is needed. > > How exactly do we expect Android to move away from fbdev if we add features to > the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a > thing from the past and that they'd better migrate now. If your point is that merging this patch will slow down the Android move away from fbdev, I disagree with that (obviously). I don't care at all about Android on my platform of choice, but don't see how that merging this patch will change anything. Let's be honest, Android trees typically have thousands of patches on top of mainline. Do you think a simple, 15 LoC, patch will make any difference to vendors? If they want to stay on fbdev and have that feature, they'll just merge this patch, done. However, what I do see is that three different people/organisations have now expressed interest in that feature, on three different SoCs. If that patch needed a significant rework of the fbdev layer, then yes, I might agree that it's not worth it. But in this case, it's pretty trivial. The only people you're "punishing" here with that kind of concern are the people who actually play fair and want not to have any patches and everything upstream. I guess a much better strategy would be to provide an incentive to moving to KMS. And I truely think there's one already, so it's just a matter of time before people switch over. Fbdev emulation or not. Ma -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev @ 2017-02-13 10:54 ` Maxime Ripard 0 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-13 10:54 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-kernel, dri-devel, Daniel Vetter, Stefan Christ [-- Attachment #1.1: Type: text/plain, Size: 2228 bytes --] Hi Laurent, On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > Hi Maxime, > > Thank you for the patch. > > On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > > From: Xinliang Liu <xinliang.liu@linaro.org> > > > > This patch add a config to support to create multi buffer for cma fbdev. > > Such as double buffer and triple buffer. > > > > Cma fbdev is convient to add a legency fbdev. And still many Android > > devices use fbdev now and at least double buffer is needed for these > > Android devices, so that a buffer flip can be operated. It will need > > some time for Android device vendors to abondon legency fbdev. So multi > > buffer for fbdev is needed. > > How exactly do we expect Android to move away from fbdev if we add features to > the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a > thing from the past and that they'd better migrate now. If your point is that merging this patch will slow down the Android move away from fbdev, I disagree with that (obviously). I don't care at all about Android on my platform of choice, but don't see how that merging this patch will change anything. Let's be honest, Android trees typically have thousands of patches on top of mainline. Do you think a simple, 15 LoC, patch will make any difference to vendors? If they want to stay on fbdev and have that feature, they'll just merge this patch, done. However, what I do see is that three different people/organisations have now expressed interest in that feature, on three different SoCs. If that patch needed a significant rework of the fbdev layer, then yes, I might agree that it's not worth it. But in this case, it's pretty trivial. The only people you're "punishing" here with that kind of concern are the people who actually play fair and want not to have any patches and everything upstream. I guess a much better strategy would be to provide an incentive to moving to KMS. And I truely think there's one already, so it's just a matter of time before people switch over. Fbdev emulation or not. Ma -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-13 10:54 ` Maxime Ripard @ 2017-02-13 11:20 ` Daniel Stone -1 siblings, 0 replies; 44+ messages in thread From: Daniel Stone @ 2017-02-13 11:20 UTC (permalink / raw) To: Maxime Ripard Cc: Laurent Pinchart, Linux Kernel Mailing List, dri-devel, Daniel Vetter, Stefan Christ Hi Maxime, On 13 February 2017 at 10:54, Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: >> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: >> > This patch add a config to support to create multi buffer for cma fbdev. >> > Such as double buffer and triple buffer. >> > >> > Cma fbdev is convient to add a legency fbdev. And still many Android >> > devices use fbdev now and at least double buffer is needed for these >> > Android devices, so that a buffer flip can be operated. It will need >> > some time for Android device vendors to abondon legency fbdev. So multi >> > buffer for fbdev is needed. >> >> How exactly do we expect Android to move away from fbdev if we add features to >> the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a >> thing from the past and that they'd better migrate now. > > If your point is that merging this patch will slow down the Android > move away from fbdev, I disagree with that (obviously). > > I don't care at all about Android on my platform of choice, but don't > see how that merging this patch will change anything. > > Let's be honest, Android trees typically have thousands of patches on > top of mainline. Do you think a simple, 15 LoC, patch will make any > difference to vendors? If they want to stay on fbdev and have that > feature, they'll just merge this patch, done. So, in that case, why not just let them do that? They'd already have to add patches to use this, surely; we don't have anything in mainline kernels which allows people to actually use this larger allocation. Apart from software mmap() and using panning to do flips, but I'm taking it as a given that people shipping Android on their devices aren't using software rendering. > However, what I do see is that three different people/organisations > have now expressed interest in that feature, on three different > SoCs. If that patch needed a significant rework of the fbdev layer, > then yes, I might agree that it's not worth it. But in this case, it's > pretty trivial. > > The only people you're "punishing" here with that kind of concern are > the people who actually play fair and want not to have any patches and > everything upstream. I would hazard a guess that most users of this have out-of-tree GPU drivers. > I guess a much better strategy would be to provide an incentive to > moving to KMS. And I truely think there's one already, so it's just a > matter of time before people switch over. Fbdev emulation or not. The concern makes sense, but on the other hand, fbdev is deprecated: no new drivers, and no new features. Cheers, Daniel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev @ 2017-02-13 11:20 ` Daniel Stone 0 siblings, 0 replies; 44+ messages in thread From: Daniel Stone @ 2017-02-13 11:20 UTC (permalink / raw) To: Maxime Ripard Cc: Daniel Vetter, Stefan Christ, Laurent Pinchart, dri-devel, Linux Kernel Mailing List Hi Maxime, On 13 February 2017 at 10:54, Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: >> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: >> > This patch add a config to support to create multi buffer for cma fbdev. >> > Such as double buffer and triple buffer. >> > >> > Cma fbdev is convient to add a legency fbdev. And still many Android >> > devices use fbdev now and at least double buffer is needed for these >> > Android devices, so that a buffer flip can be operated. It will need >> > some time for Android device vendors to abondon legency fbdev. So multi >> > buffer for fbdev is needed. >> >> How exactly do we expect Android to move away from fbdev if we add features to >> the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a >> thing from the past and that they'd better migrate now. > > If your point is that merging this patch will slow down the Android > move away from fbdev, I disagree with that (obviously). > > I don't care at all about Android on my platform of choice, but don't > see how that merging this patch will change anything. > > Let's be honest, Android trees typically have thousands of patches on > top of mainline. Do you think a simple, 15 LoC, patch will make any > difference to vendors? If they want to stay on fbdev and have that > feature, they'll just merge this patch, done. So, in that case, why not just let them do that? They'd already have to add patches to use this, surely; we don't have anything in mainline kernels which allows people to actually use this larger allocation. Apart from software mmap() and using panning to do flips, but I'm taking it as a given that people shipping Android on their devices aren't using software rendering. > However, what I do see is that three different people/organisations > have now expressed interest in that feature, on three different > SoCs. If that patch needed a significant rework of the fbdev layer, > then yes, I might agree that it's not worth it. But in this case, it's > pretty trivial. > > The only people you're "punishing" here with that kind of concern are > the people who actually play fair and want not to have any patches and > everything upstream. I would hazard a guess that most users of this have out-of-tree GPU drivers. > I guess a much better strategy would be to provide an incentive to > moving to KMS. And I truely think there's one already, so it's just a > matter of time before people switch over. Fbdev emulation or not. The concern makes sense, but on the other hand, fbdev is deprecated: no new drivers, and no new features. Cheers, Daniel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-13 11:20 ` Daniel Stone @ 2017-02-14 20:09 ` Daniel Vetter -1 siblings, 0 replies; 44+ messages in thread From: Daniel Vetter @ 2017-02-14 20:09 UTC (permalink / raw) To: Daniel Stone Cc: Maxime Ripard, Daniel Vetter, Stefan Christ, Laurent Pinchart, dri-devel, Linux Kernel Mailing List On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > Hi Maxime, > > On 13 February 2017 at 10:54, Maxime Ripard > <maxime.ripard@free-electrons.com> wrote: > > On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > >> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > >> > This patch add a config to support to create multi buffer for cma fbdev. > >> > Such as double buffer and triple buffer. > >> > > >> > Cma fbdev is convient to add a legency fbdev. And still many Android > >> > devices use fbdev now and at least double buffer is needed for these > >> > Android devices, so that a buffer flip can be operated. It will need > >> > some time for Android device vendors to abondon legency fbdev. So multi > >> > buffer for fbdev is needed. > >> > >> How exactly do we expect Android to move away from fbdev if we add features to > >> the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a > >> thing from the past and that they'd better migrate now. > > > > If your point is that merging this patch will slow down the Android > > move away from fbdev, I disagree with that (obviously). > > > > I don't care at all about Android on my platform of choice, but don't > > see how that merging this patch will change anything. > > > > Let's be honest, Android trees typically have thousands of patches on > > top of mainline. Do you think a simple, 15 LoC, patch will make any > > difference to vendors? If they want to stay on fbdev and have that > > feature, they'll just merge this patch, done. > > So, in that case, why not just let them do that? They'd already have > to add patches to use this, surely; we don't have anything in mainline > kernels which allows people to actually use this larger allocation. > Apart from software mmap() and using panning to do flips, but I'm > taking it as a given that people shipping Android on their devices > aren't using software rendering. I think we need to make a distinction between fbdev the subsystem in the kernel, and fbdev the uabi: - fbdev the subsystem is completely dead in upstream. I think we have full agreement on that. - fbdev the uabi isn't, and if we can get more users from fbdev based drivers to kms/atomic drivers by adding fairly simple stuff like this, I'm all for it. Which means: Yes, I fully plan to merge this, it makes sense. It even _helps_ by making fbdev-the-subsystem even deader. Making live hard for out-of-tree folks or folks with shit userspace doesn't make sense, at least if the only benefit for us is that we'll feel pure about our intentions :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev @ 2017-02-14 20:09 ` Daniel Vetter 0 siblings, 0 replies; 44+ messages in thread From: Daniel Vetter @ 2017-02-14 20:09 UTC (permalink / raw) To: Daniel Stone Cc: Linux Kernel Mailing List, dri-devel, Laurent Pinchart, Daniel Vetter, Maxime Ripard, Stefan Christ On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > Hi Maxime, > > On 13 February 2017 at 10:54, Maxime Ripard > <maxime.ripard@free-electrons.com> wrote: > > On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > >> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > >> > This patch add a config to support to create multi buffer for cma fbdev. > >> > Such as double buffer and triple buffer. > >> > > >> > Cma fbdev is convient to add a legency fbdev. And still many Android > >> > devices use fbdev now and at least double buffer is needed for these > >> > Android devices, so that a buffer flip can be operated. It will need > >> > some time for Android device vendors to abondon legency fbdev. So multi > >> > buffer for fbdev is needed. > >> > >> How exactly do we expect Android to move away from fbdev if we add features to > >> the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a > >> thing from the past and that they'd better migrate now. > > > > If your point is that merging this patch will slow down the Android > > move away from fbdev, I disagree with that (obviously). > > > > I don't care at all about Android on my platform of choice, but don't > > see how that merging this patch will change anything. > > > > Let's be honest, Android trees typically have thousands of patches on > > top of mainline. Do you think a simple, 15 LoC, patch will make any > > difference to vendors? If they want to stay on fbdev and have that > > feature, they'll just merge this patch, done. > > So, in that case, why not just let them do that? They'd already have > to add patches to use this, surely; we don't have anything in mainline > kernels which allows people to actually use this larger allocation. > Apart from software mmap() and using panning to do flips, but I'm > taking it as a given that people shipping Android on their devices > aren't using software rendering. I think we need to make a distinction between fbdev the subsystem in the kernel, and fbdev the uabi: - fbdev the subsystem is completely dead in upstream. I think we have full agreement on that. - fbdev the uabi isn't, and if we can get more users from fbdev based drivers to kms/atomic drivers by adding fairly simple stuff like this, I'm all for it. Which means: Yes, I fully plan to merge this, it makes sense. It even _helps_ by making fbdev-the-subsystem even deader. Making live hard for out-of-tree folks or folks with shit userspace doesn't make sense, at least if the only benefit for us is that we'll feel pure about our intentions :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-14 20:09 ` Daniel Vetter @ 2017-02-14 21:25 ` Laurent Pinchart -1 siblings, 0 replies; 44+ messages in thread From: Laurent Pinchart @ 2017-02-14 21:25 UTC (permalink / raw) To: Daniel Vetter Cc: Daniel Stone, Maxime Ripard, Daniel Vetter, Stefan Christ, dri-devel, Linux Kernel Mailing List Hi Daniel, On Tuesday 14 Feb 2017 21:09:51 Daniel Vetter wrote: > On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > > On 13 February 2017 at 10:54, Maxime Ripard wrote: > >> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > >>> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > >>>> This patch add a config to support to create multi buffer for cma > >>>> fbdev. Such as double buffer and triple buffer. > >>>> > >>>> Cma fbdev is convient to add a legency fbdev. And still many Android > >>>> devices use fbdev now and at least double buffer is needed for these > >>>> Android devices, so that a buffer flip can be operated. It will need > >>>> some time for Android device vendors to abondon legency fbdev. So > >>>> multi buffer for fbdev is needed. > >>> > >>> How exactly do we expect Android to move away from fbdev if we add > >>> features to the fbdev compat layer ? I'd much rather make it clear to > >>> them that fbdev is a thing from the past and that they'd better > >>> migrate now. > >> > >> If your point is that merging this patch will slow down the Android > >> move away from fbdev, I disagree with that (obviously). > >> > >> I don't care at all about Android on my platform of choice, but don't > >> see how that merging this patch will change anything. > >> > >> Let's be honest, Android trees typically have thousands of patches on > >> top of mainline. Do you think a simple, 15 LoC, patch will make any > >> difference to vendors? If they want to stay on fbdev and have that > >> feature, they'll just merge this patch, done. > > > > So, in that case, why not just let them do that? They'd already have > > to add patches to use this, surely; we don't have anything in mainline > > kernels which allows people to actually use this larger allocation. > > Apart from software mmap() and using panning to do flips, but I'm > > taking it as a given that people shipping Android on their devices > > aren't using software rendering. > > I think we need to make a distinction between fbdev the subsystem in the > kernel, and fbdev the uabi: > > - fbdev the subsystem is completely dead in upstream. I think we have full > agreement on that. > - fbdev the uabi isn't, and if we can get more users from fbdev based > drivers to kms/atomic drivers by adding fairly simple stuff like this, > I'm all for it. The real question, in my opinion, is how to get more users for the DRM/KMS userspace API, to help killing the fbdev API. What's the incentive for userspace to migrate if we tell them that we're going to support the fbdev API forever, and will even go through the trouble of extending the supported feature set ? I have a customer who wouldn't have migrated their userspace to DRM/KMS if these two patches had been merged a few years ago. I'd rather *reduce* the supported feature set over time until we can finally switch fbdev off. > Which means: Yes, I fully plan to merge this, it makes sense. It even > _helps_ by making fbdev-the-subsystem even deader. Making live hard for > out-of-tree folks or folks with shit userspace doesn't make sense, at > least if the only benefit for us is that we'll feel pure about our > intentions :-) -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev @ 2017-02-14 21:25 ` Laurent Pinchart 0 siblings, 0 replies; 44+ messages in thread From: Laurent Pinchart @ 2017-02-14 21:25 UTC (permalink / raw) To: Daniel Vetter Cc: Linux Kernel Mailing List, dri-devel, Daniel Vetter, Maxime Ripard, Stefan Christ Hi Daniel, On Tuesday 14 Feb 2017 21:09:51 Daniel Vetter wrote: > On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > > On 13 February 2017 at 10:54, Maxime Ripard wrote: > >> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > >>> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > >>>> This patch add a config to support to create multi buffer for cma > >>>> fbdev. Such as double buffer and triple buffer. > >>>> > >>>> Cma fbdev is convient to add a legency fbdev. And still many Android > >>>> devices use fbdev now and at least double buffer is needed for these > >>>> Android devices, so that a buffer flip can be operated. It will need > >>>> some time for Android device vendors to abondon legency fbdev. So > >>>> multi buffer for fbdev is needed. > >>> > >>> How exactly do we expect Android to move away from fbdev if we add > >>> features to the fbdev compat layer ? I'd much rather make it clear to > >>> them that fbdev is a thing from the past and that they'd better > >>> migrate now. > >> > >> If your point is that merging this patch will slow down the Android > >> move away from fbdev, I disagree with that (obviously). > >> > >> I don't care at all about Android on my platform of choice, but don't > >> see how that merging this patch will change anything. > >> > >> Let's be honest, Android trees typically have thousands of patches on > >> top of mainline. Do you think a simple, 15 LoC, patch will make any > >> difference to vendors? If they want to stay on fbdev and have that > >> feature, they'll just merge this patch, done. > > > > So, in that case, why not just let them do that? They'd already have > > to add patches to use this, surely; we don't have anything in mainline > > kernels which allows people to actually use this larger allocation. > > Apart from software mmap() and using panning to do flips, but I'm > > taking it as a given that people shipping Android on their devices > > aren't using software rendering. > > I think we need to make a distinction between fbdev the subsystem in the > kernel, and fbdev the uabi: > > - fbdev the subsystem is completely dead in upstream. I think we have full > agreement on that. > - fbdev the uabi isn't, and if we can get more users from fbdev based > drivers to kms/atomic drivers by adding fairly simple stuff like this, > I'm all for it. The real question, in my opinion, is how to get more users for the DRM/KMS userspace API, to help killing the fbdev API. What's the incentive for userspace to migrate if we tell them that we're going to support the fbdev API forever, and will even go through the trouble of extending the supported feature set ? I have a customer who wouldn't have migrated their userspace to DRM/KMS if these two patches had been merged a few years ago. I'd rather *reduce* the supported feature set over time until we can finally switch fbdev off. > Which means: Yes, I fully plan to merge this, it makes sense. It even > _helps_ by making fbdev-the-subsystem even deader. Making live hard for > out-of-tree folks or folks with shit userspace doesn't make sense, at > least if the only benefit for us is that we'll feel pure about our > intentions :-) -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-14 21:25 ` Laurent Pinchart @ 2017-02-15 12:51 ` Maxime Ripard -1 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-15 12:51 UTC (permalink / raw) To: Laurent Pinchart Cc: Daniel Vetter, Daniel Stone, Daniel Vetter, Stefan Christ, dri-devel, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 4407 bytes --] Hi, On Tue, Feb 14, 2017 at 11:25:08PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Tuesday 14 Feb 2017 21:09:51 Daniel Vetter wrote: > > On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > > > On 13 February 2017 at 10:54, Maxime Ripard wrote: > > >> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > > >>> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > > >>>> This patch add a config to support to create multi buffer for cma > > >>>> fbdev. Such as double buffer and triple buffer. > > >>>> > > >>>> Cma fbdev is convient to add a legency fbdev. And still many Android > > >>>> devices use fbdev now and at least double buffer is needed for these > > >>>> Android devices, so that a buffer flip can be operated. It will need > > >>>> some time for Android device vendors to abondon legency fbdev. So > > >>>> multi buffer for fbdev is needed. > > >>> > > >>> How exactly do we expect Android to move away from fbdev if we add > > >>> features to the fbdev compat layer ? I'd much rather make it clear to > > >>> them that fbdev is a thing from the past and that they'd better > > >>> migrate now. > > >> > > >> If your point is that merging this patch will slow down the Android > > >> move away from fbdev, I disagree with that (obviously). > > >> > > >> I don't care at all about Android on my platform of choice, but don't > > >> see how that merging this patch will change anything. > > >> > > >> Let's be honest, Android trees typically have thousands of patches on > > >> top of mainline. Do you think a simple, 15 LoC, patch will make any > > >> difference to vendors? If they want to stay on fbdev and have that > > >> feature, they'll just merge this patch, done. > > > > > > So, in that case, why not just let them do that? They'd already have > > > to add patches to use this, surely; we don't have anything in mainline > > > kernels which allows people to actually use this larger allocation. > > > Apart from software mmap() and using panning to do flips, but I'm > > > taking it as a given that people shipping Android on their devices > > > aren't using software rendering. > > > > I think we need to make a distinction between fbdev the subsystem in the > > kernel, and fbdev the uabi: > > > > - fbdev the subsystem is completely dead in upstream. I think we have full > > agreement on that. > > - fbdev the uabi isn't, and if we can get more users from fbdev based > > drivers to kms/atomic drivers by adding fairly simple stuff like this, > > I'm all for it. > > The real question, in my opinion, is how to get more users for the DRM/KMS > userspace API, to help killing the fbdev API. What's the incentive for > userspace to migrate if we tell them that we're going to support the fbdev API > forever, and will even go through the trouble of extending the supported > feature set ? I have a customer who wouldn't have migrated their userspace to > DRM/KMS if these two patches had been merged a few years ago. If those patches are not in, then I can see three ways to support old / deficient userspaces: 1) Carry those patches out of tree 2) Write an fbdev driver for the display engine 3) Rewrite the userspace components While 3. would arguably be the best option, this isn't always one, unfortunately. And as a community, I think 1 and 2 are not very good for us. 1. will drive away vendors from our community, undermining the effort we've been doing for a few years. And 2 will result in a driver we really don't want to merge (so useless), and even if it would out of tree, that would make it one less system / board / SoC *with* DRM/KMS APIs, reducing the interest of switching for application developpers. If we really want to make people switch to DRM / KMS, we have to make it ubiquitous. And if we want to make it ubiquitous, we really want to have a transition period where people will have both APIs, supported in a decent enough way. And then, that's a win for everyone, because in the process you get fbdev (booo!) and KMS (yay!), allowing for people to switch over, and eventually kill the emulation entirely. But it's far too early for that. I mean, we don't even have an fbv replacement yet... Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev @ 2017-02-15 12:51 ` Maxime Ripard 0 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-15 12:51 UTC (permalink / raw) To: Laurent Pinchart Cc: Linux Kernel Mailing List, dri-devel, Daniel Vetter, Stefan Christ [-- Attachment #1.1: Type: text/plain, Size: 4407 bytes --] Hi, On Tue, Feb 14, 2017 at 11:25:08PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Tuesday 14 Feb 2017 21:09:51 Daniel Vetter wrote: > > On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > > > On 13 February 2017 at 10:54, Maxime Ripard wrote: > > >> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > > >>> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > > >>>> This patch add a config to support to create multi buffer for cma > > >>>> fbdev. Such as double buffer and triple buffer. > > >>>> > > >>>> Cma fbdev is convient to add a legency fbdev. And still many Android > > >>>> devices use fbdev now and at least double buffer is needed for these > > >>>> Android devices, so that a buffer flip can be operated. It will need > > >>>> some time for Android device vendors to abondon legency fbdev. So > > >>>> multi buffer for fbdev is needed. > > >>> > > >>> How exactly do we expect Android to move away from fbdev if we add > > >>> features to the fbdev compat layer ? I'd much rather make it clear to > > >>> them that fbdev is a thing from the past and that they'd better > > >>> migrate now. > > >> > > >> If your point is that merging this patch will slow down the Android > > >> move away from fbdev, I disagree with that (obviously). > > >> > > >> I don't care at all about Android on my platform of choice, but don't > > >> see how that merging this patch will change anything. > > >> > > >> Let's be honest, Android trees typically have thousands of patches on > > >> top of mainline. Do you think a simple, 15 LoC, patch will make any > > >> difference to vendors? If they want to stay on fbdev and have that > > >> feature, they'll just merge this patch, done. > > > > > > So, in that case, why not just let them do that? They'd already have > > > to add patches to use this, surely; we don't have anything in mainline > > > kernels which allows people to actually use this larger allocation. > > > Apart from software mmap() and using panning to do flips, but I'm > > > taking it as a given that people shipping Android on their devices > > > aren't using software rendering. > > > > I think we need to make a distinction between fbdev the subsystem in the > > kernel, and fbdev the uabi: > > > > - fbdev the subsystem is completely dead in upstream. I think we have full > > agreement on that. > > - fbdev the uabi isn't, and if we can get more users from fbdev based > > drivers to kms/atomic drivers by adding fairly simple stuff like this, > > I'm all for it. > > The real question, in my opinion, is how to get more users for the DRM/KMS > userspace API, to help killing the fbdev API. What's the incentive for > userspace to migrate if we tell them that we're going to support the fbdev API > forever, and will even go through the trouble of extending the supported > feature set ? I have a customer who wouldn't have migrated their userspace to > DRM/KMS if these two patches had been merged a few years ago. If those patches are not in, then I can see three ways to support old / deficient userspaces: 1) Carry those patches out of tree 2) Write an fbdev driver for the display engine 3) Rewrite the userspace components While 3. would arguably be the best option, this isn't always one, unfortunately. And as a community, I think 1 and 2 are not very good for us. 1. will drive away vendors from our community, undermining the effort we've been doing for a few years. And 2 will result in a driver we really don't want to merge (so useless), and even if it would out of tree, that would make it one less system / board / SoC *with* DRM/KMS APIs, reducing the interest of switching for application developpers. If we really want to make people switch to DRM / KMS, we have to make it ubiquitous. And if we want to make it ubiquitous, we really want to have a transition period where people will have both APIs, supported in a decent enough way. And then, that's a win for everyone, because in the process you get fbdev (booo!) and KMS (yay!), allowing for people to switch over, and eventually kill the emulation entirely. But it's far too early for that. I mean, we don't even have an fbv replacement yet... Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-15 12:51 ` Maxime Ripard (?) @ 2017-02-17 11:30 ` Laurent Pinchart -1 siblings, 0 replies; 44+ messages in thread From: Laurent Pinchart @ 2017-02-17 11:30 UTC (permalink / raw) To: Maxime Ripard Cc: Daniel Vetter, Daniel Stone, Daniel Vetter, Stefan Christ, dri-devel, Linux Kernel Mailing List Hi Maxime, On Wednesday 15 Feb 2017 13:51:29 Maxime Ripard wrote: > On Tue, Feb 14, 2017 at 11:25:08PM +0200, Laurent Pinchart wrote: > > On Tuesday 14 Feb 2017 21:09:51 Daniel Vetter wrote: > >> On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > >>> On 13 February 2017 at 10:54, Maxime Ripard wrote: > >>>> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > >>>>> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > >>>>>> This patch add a config to support to create multi buffer for cma > >>>>>> fbdev. Such as double buffer and triple buffer. > >>>>>> > >>>>>> Cma fbdev is convient to add a legency fbdev. And still many > >>>>>> Android devices use fbdev now and at least double buffer is needed > >>>>>> for these Android devices, so that a buffer flip can be operated. It > >>>>>> will need some time for Android device vendors to abondon legency > >>>>>> fbdev. So multi buffer for fbdev is needed. > >>>>> > >>>>> How exactly do we expect Android to move away from fbdev if we add > >>>>> features to the fbdev compat layer ? I'd much rather make it clear > >>>>> to them that fbdev is a thing from the past and that they'd better > >>>>> migrate now. > >>>> > >>>> If your point is that merging this patch will slow down the Android > >>>> move away from fbdev, I disagree with that (obviously). > >>>> > >>>> I don't care at all about Android on my platform of choice, but don't > >>>> see how that merging this patch will change anything. > >>>> > >>>> Let's be honest, Android trees typically have thousands of patches on > >>>> top of mainline. Do you think a simple, 15 LoC, patch will make any > >>>> difference to vendors? If they want to stay on fbdev and have that > >>>> feature, they'll just merge this patch, done. > >>> > >>> So, in that case, why not just let them do that? They'd already have > >>> to add patches to use this, surely; we don't have anything in mainline > >>> kernels which allows people to actually use this larger allocation. > >>> Apart from software mmap() and using panning to do flips, but I'm > >>> taking it as a given that people shipping Android on their devices > >>> aren't using software rendering. > >> > >> I think we need to make a distinction between fbdev the subsystem in the > >> kernel, and fbdev the uabi: > >> > >> - fbdev the subsystem is completely dead in upstream. I think we have > >> full agreement on that. > >> > >> - fbdev the uabi isn't, and if we can get more users from fbdev based > >> drivers to kms/atomic drivers by adding fairly simple stuff like this, > >> I'm all for it. > > > > The real question, in my opinion, is how to get more users for the DRM/KMS > > userspace API, to help killing the fbdev API. What's the incentive for > > userspace to migrate if we tell them that we're going to support the fbdev > > API forever, and will even go through the trouble of extending the > > supported feature set ? I have a customer who wouldn't have migrated > > their userspace to DRM/KMS if these two patches had been merged a few > > years ago. > > If those patches are not in, then I can see three ways to support old > / deficient userspaces: > 1) Carry those patches out of tree > 2) Write an fbdev driver for the display engine > 3) Rewrite the userspace components > > While 3. would arguably be the best option, this isn't always one, > unfortunately. I agree that it's not a solution that can be deployed overnight, but it's clearly what we all (as in kernel community and system vendors) need to head towards. > And as a community, I think 1 and 2 are not very good for us. 1. will > drive away vendors from our community, undermining the effort we've > been doing for a few years. And 2 will result in a driver we really > don't want to merge (so useless), and even if it would out of tree, > that would make it one less system / board / SoC *with* DRM/KMS APIs, > reducing the interest of switching for application developpers. > > If we really want to make people switch to DRM / KMS, we have to make > it ubiquitous. And if we want to make it ubiquitous, we really want to > have a transition period where people will have both APIs, supported > in a decent enough way. Haven't we had such a grace period already, until the fbdev subsystem stopped accepting new drivers ? It has hardly been an overnight switch. > And then, that's a win for everyone, because in the process you get > fbdev (booo!) and KMS (yay!), allowing for people to switch over, and > eventually kill the emulation entirely. But it's far too early for > that. I mean, we don't even have an fbv replacement yet... We're talking about http://s-tech.elsat.net.pl/fbv/, whose latest release dates from 2011 ? :-) https://github.com/tomba/kmsxx/blob/master/utils/kmsview.cpp It won't be hard to add support for BMP, GIF, JPG or PNG. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-13 11:20 ` Daniel Stone @ 2017-02-15 12:38 ` Maxime Ripard -1 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-15 12:38 UTC (permalink / raw) To: Daniel Stone Cc: Laurent Pinchart, Linux Kernel Mailing List, dri-devel, Daniel Vetter, Stefan Christ [-- Attachment #1: Type: text/plain, Size: 3483 bytes --] Hi, On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > Hi Maxime, > > On 13 February 2017 at 10:54, Maxime Ripard > <maxime.ripard@free-electrons.com> wrote: > > On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > >> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > >> > This patch add a config to support to create multi buffer for cma fbdev. > >> > Such as double buffer and triple buffer. > >> > > >> > Cma fbdev is convient to add a legency fbdev. And still many Android > >> > devices use fbdev now and at least double buffer is needed for these > >> > Android devices, so that a buffer flip can be operated. It will need > >> > some time for Android device vendors to abondon legency fbdev. So multi > >> > buffer for fbdev is needed. > >> > >> How exactly do we expect Android to move away from fbdev if we add features to > >> the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a > >> thing from the past and that they'd better migrate now. > > > > If your point is that merging this patch will slow down the Android > > move away from fbdev, I disagree with that (obviously). > > > > I don't care at all about Android on my platform of choice, but don't > > see how that merging this patch will change anything. > > > > Let's be honest, Android trees typically have thousands of patches on > > top of mainline. Do you think a simple, 15 LoC, patch will make any > > difference to vendors? If they want to stay on fbdev and have that > > feature, they'll just merge this patch, done. > > So, in that case, why not just let them do that? They'd already have > to add patches to use this, surely; we don't have anything in mainline > kernels which allows people to actually use this larger allocation. > Apart from software mmap() and using panning to do flips, but I'm > taking it as a given that people shipping Android on their devices > aren't using software rendering. My point was that you're not doing it more difficult for people not willing to contribute upstream, you're just making it more difficult for people who want to contribute. The whole argument to engage vendors upstream is that we sell them that eventually they will be able to just use whatever kernel release is on kernel.org or in their distro of choice. If those people depend on a feature that is entirely rejected upstream, then they'll have to carry that patch in their tree, creating a BSP in the process. And that reduces greatly the strength of the "you should contribute" argument, making them less involved. > > However, what I do see is that three different people/organisations > > have now expressed interest in that feature, on three different > > SoCs. If that patch needed a significant rework of the fbdev layer, > > then yes, I might agree that it's not worth it. But in this case, it's > > pretty trivial. > > > > The only people you're "punishing" here with that kind of concern are > > the people who actually play fair and want not to have any patches and > > everything upstream. > > I would hazard a guess that most users of this have out-of-tree GPU > drivers. Out of tree GPU drivers, that can be distributed separately from the kernel, just like any out of tree module can. This doesn't require any kernel patches at all. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev @ 2017-02-15 12:38 ` Maxime Ripard 0 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-15 12:38 UTC (permalink / raw) To: Daniel Stone Cc: Daniel Vetter, Stefan Christ, Laurent Pinchart, dri-devel, Linux Kernel Mailing List [-- Attachment #1.1: Type: text/plain, Size: 3483 bytes --] Hi, On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > Hi Maxime, > > On 13 February 2017 at 10:54, Maxime Ripard > <maxime.ripard@free-electrons.com> wrote: > > On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > >> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > >> > This patch add a config to support to create multi buffer for cma fbdev. > >> > Such as double buffer and triple buffer. > >> > > >> > Cma fbdev is convient to add a legency fbdev. And still many Android > >> > devices use fbdev now and at least double buffer is needed for these > >> > Android devices, so that a buffer flip can be operated. It will need > >> > some time for Android device vendors to abondon legency fbdev. So multi > >> > buffer for fbdev is needed. > >> > >> How exactly do we expect Android to move away from fbdev if we add features to > >> the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a > >> thing from the past and that they'd better migrate now. > > > > If your point is that merging this patch will slow down the Android > > move away from fbdev, I disagree with that (obviously). > > > > I don't care at all about Android on my platform of choice, but don't > > see how that merging this patch will change anything. > > > > Let's be honest, Android trees typically have thousands of patches on > > top of mainline. Do you think a simple, 15 LoC, patch will make any > > difference to vendors? If they want to stay on fbdev and have that > > feature, they'll just merge this patch, done. > > So, in that case, why not just let them do that? They'd already have > to add patches to use this, surely; we don't have anything in mainline > kernels which allows people to actually use this larger allocation. > Apart from software mmap() and using panning to do flips, but I'm > taking it as a given that people shipping Android on their devices > aren't using software rendering. My point was that you're not doing it more difficult for people not willing to contribute upstream, you're just making it more difficult for people who want to contribute. The whole argument to engage vendors upstream is that we sell them that eventually they will be able to just use whatever kernel release is on kernel.org or in their distro of choice. If those people depend on a feature that is entirely rejected upstream, then they'll have to carry that patch in their tree, creating a BSP in the process. And that reduces greatly the strength of the "you should contribute" argument, making them less involved. > > However, what I do see is that three different people/organisations > > have now expressed interest in that feature, on three different > > SoCs. If that patch needed a significant rework of the fbdev layer, > > then yes, I might agree that it's not worth it. But in this case, it's > > pretty trivial. > > > > The only people you're "punishing" here with that kind of concern are > > the people who actually play fair and want not to have any patches and > > everything upstream. > > I would hazard a guess that most users of this have out-of-tree GPU > drivers. Out of tree GPU drivers, that can be distributed separately from the kernel, just like any out of tree module can. This doesn't require any kernel patches at all. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-15 12:38 ` Maxime Ripard @ 2017-02-17 11:23 ` Laurent Pinchart -1 siblings, 0 replies; 44+ messages in thread From: Laurent Pinchart @ 2017-02-17 11:23 UTC (permalink / raw) To: Maxime Ripard Cc: Daniel Stone, Linux Kernel Mailing List, dri-devel, Daniel Vetter, Stefan Christ Hi Maxime, On Wednesday 15 Feb 2017 13:38:44 Maxime Ripard wrote: > On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > > On 13 February 2017 at 10:54, Maxime Ripard wrote: > >> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > >>> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > >>>> This patch add a config to support to create multi buffer for cma > >>>> fbdev. Such as double buffer and triple buffer. > >>>> > >>>> Cma fbdev is convient to add a legency fbdev. And still many Android > >>>> devices use fbdev now and at least double buffer is needed for these > >>>> Android devices, so that a buffer flip can be operated. It will need > >>>> some time for Android device vendors to abondon legency fbdev. So > >>>> multi buffer for fbdev is needed. > >>> > >>> How exactly do we expect Android to move away from fbdev if we add > >>> features to the fbdev compat layer ? I'd much rather make it clear to > >>> them that fbdev is a thing from the past and that they'd better > >>> migrate now. > >> > >> If your point is that merging this patch will slow down the Android > >> move away from fbdev, I disagree with that (obviously). > >> > >> I don't care at all about Android on my platform of choice, but don't > >> see how that merging this patch will change anything. > >> > >> Let's be honest, Android trees typically have thousands of patches on > >> top of mainline. Do you think a simple, 15 LoC, patch will make any > >> difference to vendors? If they want to stay on fbdev and have that > >> feature, they'll just merge this patch, done. > > > > So, in that case, why not just let them do that? They'd already have > > to add patches to use this, surely; we don't have anything in mainline > > kernels which allows people to actually use this larger allocation. > > Apart from software mmap() and using panning to do flips, but I'm > > taking it as a given that people shipping Android on their devices > > aren't using software rendering. > > My point was that you're not doing it more difficult for people not > willing to contribute upstream, you're just making it more difficult > for people who want to contribute. > > The whole argument to engage vendors upstream is that we sell them > that eventually they will be able to just use whatever kernel release > is on kernel.org or in their distro of choice. > > If those people depend on a feature that is entirely rejected > upstream, then they'll have to carry that patch in their tree, > creating a BSP in the process. And that reduces greatly the strength > of the "you should contribute" argument, making them less involved. No, they should not carry an out-of-tree patch, they should not use that feature in the first place. fbdev is a dead-end, Linux has clearly decided to move to DRM/KMS. Any vendor who wants to keep using fbdev is shooting themselves in the foot, as the more they depend on fbdev, the more painful it will be to switch later when they will have no choice. Switching sooner than later is the best decision, and I'd argue that by making it easier to stay on fbdev we would actually hurt those vendors in the longer term. > >> However, what I do see is that three different people/organisations > >> have now expressed interest in that feature, on three different > >> SoCs. If that patch needed a significant rework of the fbdev layer, > >> then yes, I might agree that it's not worth it. But in this case, it's > >> pretty trivial. > >> > >> The only people you're "punishing" here with that kind of concern are > >> the people who actually play fair and want not to have any patches and > >> everything upstream. > > > > I would hazard a guess that most users of this have out-of-tree GPU > > drivers. > > Out of tree GPU drivers, that can be distributed separately from the > kernel, just like any out of tree module can. This doesn't require any > kernel patches at all. That might be true in some cases, but usually those GPU drivers require heavy patching of at least the display controller driver. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev @ 2017-02-17 11:23 ` Laurent Pinchart 0 siblings, 0 replies; 44+ messages in thread From: Laurent Pinchart @ 2017-02-17 11:23 UTC (permalink / raw) To: Maxime Ripard Cc: Daniel Vetter, dri-devel, Stefan Christ, Linux Kernel Mailing List Hi Maxime, On Wednesday 15 Feb 2017 13:38:44 Maxime Ripard wrote: > On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > > On 13 February 2017 at 10:54, Maxime Ripard wrote: > >> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > >>> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > >>>> This patch add a config to support to create multi buffer for cma > >>>> fbdev. Such as double buffer and triple buffer. > >>>> > >>>> Cma fbdev is convient to add a legency fbdev. And still many Android > >>>> devices use fbdev now and at least double buffer is needed for these > >>>> Android devices, so that a buffer flip can be operated. It will need > >>>> some time for Android device vendors to abondon legency fbdev. So > >>>> multi buffer for fbdev is needed. > >>> > >>> How exactly do we expect Android to move away from fbdev if we add > >>> features to the fbdev compat layer ? I'd much rather make it clear to > >>> them that fbdev is a thing from the past and that they'd better > >>> migrate now. > >> > >> If your point is that merging this patch will slow down the Android > >> move away from fbdev, I disagree with that (obviously). > >> > >> I don't care at all about Android on my platform of choice, but don't > >> see how that merging this patch will change anything. > >> > >> Let's be honest, Android trees typically have thousands of patches on > >> top of mainline. Do you think a simple, 15 LoC, patch will make any > >> difference to vendors? If they want to stay on fbdev and have that > >> feature, they'll just merge this patch, done. > > > > So, in that case, why not just let them do that? They'd already have > > to add patches to use this, surely; we don't have anything in mainline > > kernels which allows people to actually use this larger allocation. > > Apart from software mmap() and using panning to do flips, but I'm > > taking it as a given that people shipping Android on their devices > > aren't using software rendering. > > My point was that you're not doing it more difficult for people not > willing to contribute upstream, you're just making it more difficult > for people who want to contribute. > > The whole argument to engage vendors upstream is that we sell them > that eventually they will be able to just use whatever kernel release > is on kernel.org or in their distro of choice. > > If those people depend on a feature that is entirely rejected > upstream, then they'll have to carry that patch in their tree, > creating a BSP in the process. And that reduces greatly the strength > of the "you should contribute" argument, making them less involved. No, they should not carry an out-of-tree patch, they should not use that feature in the first place. fbdev is a dead-end, Linux has clearly decided to move to DRM/KMS. Any vendor who wants to keep using fbdev is shooting themselves in the foot, as the more they depend on fbdev, the more painful it will be to switch later when they will have no choice. Switching sooner than later is the best decision, and I'd argue that by making it easier to stay on fbdev we would actually hurt those vendors in the longer term. > >> However, what I do see is that three different people/organisations > >> have now expressed interest in that feature, on three different > >> SoCs. If that patch needed a significant rework of the fbdev layer, > >> then yes, I might agree that it's not worth it. But in this case, it's > >> pretty trivial. > >> > >> The only people you're "punishing" here with that kind of concern are > >> the people who actually play fair and want not to have any patches and > >> everything upstream. > > > > I would hazard a guess that most users of this have out-of-tree GPU > > drivers. > > Out of tree GPU drivers, that can be distributed separately from the > kernel, just like any out of tree module can. This doesn't require any > kernel patches at all. That might be true in some cases, but usually those GPU drivers require heavy patching of at least the display controller driver. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC 2017-02-02 10:31 ` Maxime Ripard @ 2017-02-02 10:31 ` Maxime Ripard -1 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-02 10:31 UTC (permalink / raw) To: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul Cc: dri-devel, linux-kernel, Stefan Christ, Maxime Ripard From: Stefan Christ <s.christ@phytec.de> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic framebuffer emulation driver. Legacy framebuffer users like non kms/drm based OpenGL(ES)/EGL implementations may require the ioctl to synchronize drawing or buffer flip for double buffering. It is tested on the i.MX6. Code is based on https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 Signed-off-by: Stefan Christ <s.christ@phytec.de> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> --- drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++- include/drm/drm_fb_helper.h | 5 ++- 2 files changed, 59 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index e934b541feea..39a3532e311c 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) EXPORT_SYMBOL(drm_fb_helper_setcmap); /** + * drm_fb_helper_ioctl - legacy ioctl implementation + * @info: fbdev registered by the helper + * @cmd: ioctl command + * @arg: ioctl argument + * + * A helper to implement the standard fbdev ioctl. Only + * FBIO_WAITFORVSYNC is implemented for now. + */ +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) +{ + struct drm_fb_helper *fb_helper = info->par; + struct drm_device *dev = fb_helper->dev; + unsigned int i; + int ret = 0; + + drm_modeset_lock_all(dev); + if (!drm_fb_helper_is_bound(fb_helper)) { + drm_modeset_unlock_all(dev); + return -EBUSY; + } + + switch (cmd) { + case FBIO_WAITFORVSYNC: + for (i = 0; i < fb_helper->crtc_count; i++) { + struct drm_mode_set *mode_set; + struct drm_crtc *crtc; + + mode_set = &fb_helper->crtc_info[i].mode_set; + crtc = mode_set->crtc; + + /* + * Only call drm_crtc_wait_one_vblank for crtcs that + * are currently enabled. + */ + if (!crtc->enabled) + continue; + + ret = drm_crtc_vblank_get(crtc); + if (!ret) { + drm_crtc_wait_one_vblank(crtc); + drm_crtc_vblank_put(crtc); + } + } + goto unlock; + default: + ret = -ENOTTY; + } + +unlock: + drm_modeset_unlock_all(dev); + return ret; +} +EXPORT_SYMBOL(drm_fb_helper_ioctl); + +/** * drm_fb_helper_check_var - implementation for ->fb_check_var * @var: screeninfo to check * @info: fbdev registered by the helper diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h index 975deedd593e..460be9d9fa98 100644 --- a/include/drm/drm_fb_helper.h +++ b/include/drm/drm_fb_helper.h @@ -230,7 +230,8 @@ struct drm_fb_helper { .fb_blank = drm_fb_helper_blank, \ .fb_pan_display = drm_fb_helper_pan_display, \ .fb_debug_enter = drm_fb_helper_debug_enter, \ - .fb_debug_leave = drm_fb_helper_debug_leave + .fb_debug_leave = drm_fb_helper_debug_leave, \ + .fb_ioctl = drm_fb_helper_ioctl #ifdef CONFIG_DRM_FBDEV_EMULATION void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper, @@ -286,6 +287,8 @@ void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper, int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info); +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg); + int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper); int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel); int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper); -- git-series 0.8.11 ^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC @ 2017-02-02 10:31 ` Maxime Ripard 0 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-02 10:31 UTC (permalink / raw) To: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul Cc: Maxime Ripard, Stefan Christ, linux-kernel, dri-devel From: Stefan Christ <s.christ@phytec.de> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic framebuffer emulation driver. Legacy framebuffer users like non kms/drm based OpenGL(ES)/EGL implementations may require the ioctl to synchronize drawing or buffer flip for double buffering. It is tested on the i.MX6. Code is based on https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 Signed-off-by: Stefan Christ <s.christ@phytec.de> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> --- drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++- include/drm/drm_fb_helper.h | 5 ++- 2 files changed, 59 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index e934b541feea..39a3532e311c 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) EXPORT_SYMBOL(drm_fb_helper_setcmap); /** + * drm_fb_helper_ioctl - legacy ioctl implementation + * @info: fbdev registered by the helper + * @cmd: ioctl command + * @arg: ioctl argument + * + * A helper to implement the standard fbdev ioctl. Only + * FBIO_WAITFORVSYNC is implemented for now. + */ +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) +{ + struct drm_fb_helper *fb_helper = info->par; + struct drm_device *dev = fb_helper->dev; + unsigned int i; + int ret = 0; + + drm_modeset_lock_all(dev); + if (!drm_fb_helper_is_bound(fb_helper)) { + drm_modeset_unlock_all(dev); + return -EBUSY; + } + + switch (cmd) { + case FBIO_WAITFORVSYNC: + for (i = 0; i < fb_helper->crtc_count; i++) { + struct drm_mode_set *mode_set; + struct drm_crtc *crtc; + + mode_set = &fb_helper->crtc_info[i].mode_set; + crtc = mode_set->crtc; + + /* + * Only call drm_crtc_wait_one_vblank for crtcs that + * are currently enabled. + */ + if (!crtc->enabled) + continue; + + ret = drm_crtc_vblank_get(crtc); + if (!ret) { + drm_crtc_wait_one_vblank(crtc); + drm_crtc_vblank_put(crtc); + } + } + goto unlock; + default: + ret = -ENOTTY; + } + +unlock: + drm_modeset_unlock_all(dev); + return ret; +} +EXPORT_SYMBOL(drm_fb_helper_ioctl); + +/** * drm_fb_helper_check_var - implementation for ->fb_check_var * @var: screeninfo to check * @info: fbdev registered by the helper diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h index 975deedd593e..460be9d9fa98 100644 --- a/include/drm/drm_fb_helper.h +++ b/include/drm/drm_fb_helper.h @@ -230,7 +230,8 @@ struct drm_fb_helper { .fb_blank = drm_fb_helper_blank, \ .fb_pan_display = drm_fb_helper_pan_display, \ .fb_debug_enter = drm_fb_helper_debug_enter, \ - .fb_debug_leave = drm_fb_helper_debug_leave + .fb_debug_leave = drm_fb_helper_debug_leave, \ + .fb_ioctl = drm_fb_helper_ioctl #ifdef CONFIG_DRM_FBDEV_EMULATION void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper, @@ -286,6 +287,8 @@ void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper, int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info); +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg); + int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper); int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel); int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper); -- git-series 0.8.11 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC 2017-02-02 10:31 ` Maxime Ripard @ 2017-02-09 17:01 ` Daniel Vetter -1 siblings, 0 replies; 44+ messages in thread From: Daniel Vetter @ 2017-02-09 17:01 UTC (permalink / raw) To: Maxime Ripard Cc: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, linux-kernel, dri-devel On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > From: Stefan Christ <s.christ@phytec.de> > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > based OpenGL(ES)/EGL implementations may require the ioctl to > synchronize drawing or buffer flip for double buffering. It is tested on > the i.MX6. > > Code is based on > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++- > include/drm/drm_fb_helper.h | 5 ++- > 2 files changed, 59 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index e934b541feea..39a3532e311c 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) > EXPORT_SYMBOL(drm_fb_helper_setcmap); > > /** > + * drm_fb_helper_ioctl - legacy ioctl implementation > + * @info: fbdev registered by the helper > + * @cmd: ioctl command > + * @arg: ioctl argument > + * > + * A helper to implement the standard fbdev ioctl. Only > + * FBIO_WAITFORVSYNC is implemented for now. > + */ > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) > +{ > + struct drm_fb_helper *fb_helper = info->par; > + struct drm_device *dev = fb_helper->dev; > + unsigned int i; > + int ret = 0; > + > + drm_modeset_lock_all(dev); > + if (!drm_fb_helper_is_bound(fb_helper)) { > + drm_modeset_unlock_all(dev); > + return -EBUSY; > + } > + > + switch (cmd) { > + case FBIO_WAITFORVSYNC: > + for (i = 0; i < fb_helper->crtc_count; i++) { > + struct drm_mode_set *mode_set; > + struct drm_crtc *crtc; > + > + mode_set = &fb_helper->crtc_info[i].mode_set; > + crtc = mode_set->crtc; > + > + /* > + * Only call drm_crtc_wait_one_vblank for crtcs that > + * are currently enabled. > + */ > + if (!crtc->enabled) > + continue; This needs locking, and the interface spec for vblank_get says you'll get an -EINVAL if the pipe is off. I'd say drop this, and instead eat the -EINVAL from vblank_get and explain in a comment why you do that. The trouble is that ->enabled is legacy state, atomic drivers don't need to update it (helpers do it by default, but only for transition reasons), and it's not synchronized to the real state changes at all. vblank_get otoh is. Otherwise lgtm. -Daniel > + > + ret = drm_crtc_vblank_get(crtc); > + if (!ret) { > + drm_crtc_wait_one_vblank(crtc); > + drm_crtc_vblank_put(crtc); > + } > + } > + goto unlock; > + default: > + ret = -ENOTTY; > + } > + > +unlock: > + drm_modeset_unlock_all(dev); > + return ret; > +} > +EXPORT_SYMBOL(drm_fb_helper_ioctl); > + > +/** > * drm_fb_helper_check_var - implementation for ->fb_check_var > * @var: screeninfo to check > * @info: fbdev registered by the helper > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h > index 975deedd593e..460be9d9fa98 100644 > --- a/include/drm/drm_fb_helper.h > +++ b/include/drm/drm_fb_helper.h > @@ -230,7 +230,8 @@ struct drm_fb_helper { > .fb_blank = drm_fb_helper_blank, \ > .fb_pan_display = drm_fb_helper_pan_display, \ > .fb_debug_enter = drm_fb_helper_debug_enter, \ > - .fb_debug_leave = drm_fb_helper_debug_leave > + .fb_debug_leave = drm_fb_helper_debug_leave, \ > + .fb_ioctl = drm_fb_helper_ioctl > > #ifdef CONFIG_DRM_FBDEV_EMULATION > void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper, > @@ -286,6 +287,8 @@ void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper, > > int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info); > > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg); > + > int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper); > int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel); > int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper); > -- > git-series 0.8.11 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC @ 2017-02-09 17:01 ` Daniel Vetter 0 siblings, 0 replies; 44+ messages in thread From: Daniel Vetter @ 2017-02-09 17:01 UTC (permalink / raw) To: Maxime Ripard; +Cc: linux-kernel, dri-devel, Daniel Vetter, Stefan Christ On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > From: Stefan Christ <s.christ@phytec.de> > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > based OpenGL(ES)/EGL implementations may require the ioctl to > synchronize drawing or buffer flip for double buffering. It is tested on > the i.MX6. > > Code is based on > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++- > include/drm/drm_fb_helper.h | 5 ++- > 2 files changed, 59 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index e934b541feea..39a3532e311c 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) > EXPORT_SYMBOL(drm_fb_helper_setcmap); > > /** > + * drm_fb_helper_ioctl - legacy ioctl implementation > + * @info: fbdev registered by the helper > + * @cmd: ioctl command > + * @arg: ioctl argument > + * > + * A helper to implement the standard fbdev ioctl. Only > + * FBIO_WAITFORVSYNC is implemented for now. > + */ > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) > +{ > + struct drm_fb_helper *fb_helper = info->par; > + struct drm_device *dev = fb_helper->dev; > + unsigned int i; > + int ret = 0; > + > + drm_modeset_lock_all(dev); > + if (!drm_fb_helper_is_bound(fb_helper)) { > + drm_modeset_unlock_all(dev); > + return -EBUSY; > + } > + > + switch (cmd) { > + case FBIO_WAITFORVSYNC: > + for (i = 0; i < fb_helper->crtc_count; i++) { > + struct drm_mode_set *mode_set; > + struct drm_crtc *crtc; > + > + mode_set = &fb_helper->crtc_info[i].mode_set; > + crtc = mode_set->crtc; > + > + /* > + * Only call drm_crtc_wait_one_vblank for crtcs that > + * are currently enabled. > + */ > + if (!crtc->enabled) > + continue; This needs locking, and the interface spec for vblank_get says you'll get an -EINVAL if the pipe is off. I'd say drop this, and instead eat the -EINVAL from vblank_get and explain in a comment why you do that. The trouble is that ->enabled is legacy state, atomic drivers don't need to update it (helpers do it by default, but only for transition reasons), and it's not synchronized to the real state changes at all. vblank_get otoh is. Otherwise lgtm. -Daniel > + > + ret = drm_crtc_vblank_get(crtc); > + if (!ret) { > + drm_crtc_wait_one_vblank(crtc); > + drm_crtc_vblank_put(crtc); > + } > + } > + goto unlock; > + default: > + ret = -ENOTTY; > + } > + > +unlock: > + drm_modeset_unlock_all(dev); > + return ret; > +} > +EXPORT_SYMBOL(drm_fb_helper_ioctl); > + > +/** > * drm_fb_helper_check_var - implementation for ->fb_check_var > * @var: screeninfo to check > * @info: fbdev registered by the helper > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h > index 975deedd593e..460be9d9fa98 100644 > --- a/include/drm/drm_fb_helper.h > +++ b/include/drm/drm_fb_helper.h > @@ -230,7 +230,8 @@ struct drm_fb_helper { > .fb_blank = drm_fb_helper_blank, \ > .fb_pan_display = drm_fb_helper_pan_display, \ > .fb_debug_enter = drm_fb_helper_debug_enter, \ > - .fb_debug_leave = drm_fb_helper_debug_leave > + .fb_debug_leave = drm_fb_helper_debug_leave, \ > + .fb_ioctl = drm_fb_helper_ioctl > > #ifdef CONFIG_DRM_FBDEV_EMULATION > void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper, > @@ -286,6 +287,8 @@ void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper, > > int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info); > > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg); > + > int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper); > int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel); > int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper); > -- > git-series 0.8.11 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC 2017-02-09 17:01 ` Daniel Vetter @ 2017-02-09 17:38 ` Daniel Stone -1 siblings, 0 replies; 44+ messages in thread From: Daniel Stone @ 2017-02-09 17:38 UTC (permalink / raw) To: Maxime Ripard, Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, Linux Kernel Mailing List, dri-devel Hi, On 9 February 2017 at 17:01, Daniel Vetter <daniel@ffwll.ch> wrote: > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: >> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) >> +{ >> + struct drm_fb_helper *fb_helper = info->par; >> + struct drm_device *dev = fb_helper->dev; >> + unsigned int i; >> + int ret = 0; >> + >> + drm_modeset_lock_all(dev); >> + if (!drm_fb_helper_is_bound(fb_helper)) { >> + drm_modeset_unlock_all(dev); >> + return -EBUSY; >> + } >> + >> + switch (cmd) { >> + case FBIO_WAITFORVSYNC: >> + for (i = 0; i < fb_helper->crtc_count; i++) { >> + struct drm_mode_set *mode_set; >> + struct drm_crtc *crtc; >> + >> + mode_set = &fb_helper->crtc_info[i].mode_set; >> + crtc = mode_set->crtc; >> + >> + /* >> + * Only call drm_crtc_wait_one_vblank for crtcs that >> + * are currently enabled. >> + */ >> + if (!crtc->enabled) >> + continue; > > This needs locking More locking than the drm_modeset_lock_all() above the switch? Ouch. :) Cheers, Daniel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC @ 2017-02-09 17:38 ` Daniel Stone 0 siblings, 0 replies; 44+ messages in thread From: Daniel Stone @ 2017-02-09 17:38 UTC (permalink / raw) To: Maxime Ripard, Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, Linux Kernel Mailing List, dri-devel Hi, On 9 February 2017 at 17:01, Daniel Vetter <daniel@ffwll.ch> wrote: > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: >> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) >> +{ >> + struct drm_fb_helper *fb_helper = info->par; >> + struct drm_device *dev = fb_helper->dev; >> + unsigned int i; >> + int ret = 0; >> + >> + drm_modeset_lock_all(dev); >> + if (!drm_fb_helper_is_bound(fb_helper)) { >> + drm_modeset_unlock_all(dev); >> + return -EBUSY; >> + } >> + >> + switch (cmd) { >> + case FBIO_WAITFORVSYNC: >> + for (i = 0; i < fb_helper->crtc_count; i++) { >> + struct drm_mode_set *mode_set; >> + struct drm_crtc *crtc; >> + >> + mode_set = &fb_helper->crtc_info[i].mode_set; >> + crtc = mode_set->crtc; >> + >> + /* >> + * Only call drm_crtc_wait_one_vblank for crtcs that >> + * are currently enabled. >> + */ >> + if (!crtc->enabled) >> + continue; > > This needs locking More locking than the drm_modeset_lock_all() above the switch? Ouch. :) Cheers, Daniel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC 2017-02-09 17:38 ` Daniel Stone @ 2017-02-09 19:06 ` Daniel Vetter -1 siblings, 0 replies; 44+ messages in thread From: Daniel Vetter @ 2017-02-09 19:06 UTC (permalink / raw) To: Daniel Stone Cc: Maxime Ripard, Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, Linux Kernel Mailing List, dri-devel On Thu, Feb 09, 2017 at 05:38:26PM +0000, Daniel Stone wrote: > Hi, > > On 9 February 2017 at 17:01, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > >> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) > >> +{ > >> + struct drm_fb_helper *fb_helper = info->par; > >> + struct drm_device *dev = fb_helper->dev; > >> + unsigned int i; > >> + int ret = 0; > >> + > >> + drm_modeset_lock_all(dev); > >> + if (!drm_fb_helper_is_bound(fb_helper)) { > >> + drm_modeset_unlock_all(dev); > >> + return -EBUSY; > >> + } > >> + > >> + switch (cmd) { > >> + case FBIO_WAITFORVSYNC: > >> + for (i = 0; i < fb_helper->crtc_count; i++) { > >> + struct drm_mode_set *mode_set; > >> + struct drm_crtc *crtc; > >> + > >> + mode_set = &fb_helper->crtc_info[i].mode_set; > >> + crtc = mode_set->crtc; > >> + > >> + /* > >> + * Only call drm_crtc_wait_one_vblank for crtcs that > >> + * are currently enabled. > >> + */ > >> + if (!crtc->enabled) > >> + continue; > > > > This needs locking > > More locking than the drm_modeset_lock_all() above the switch? Ouch. :) Oh, I didn't spot that one. Well, that one should be removed imo, we dont want any vblank wait path to hold these locks, it looks bad. Otoh we still need to grab the dev->mode_config.mutex, because that's also the fbdev lock. There's a plan somewhere to give the fbdev helpers their own lock, so switching to just mode_config.mutex + the changes I suggestd would be good. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC @ 2017-02-09 19:06 ` Daniel Vetter 0 siblings, 0 replies; 44+ messages in thread From: Daniel Vetter @ 2017-02-09 19:06 UTC (permalink / raw) To: Daniel Stone Cc: Linux Kernel Mailing List, dri-devel, Daniel Vetter, Maxime Ripard, Stefan Christ On Thu, Feb 09, 2017 at 05:38:26PM +0000, Daniel Stone wrote: > Hi, > > On 9 February 2017 at 17:01, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > >> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) > >> +{ > >> + struct drm_fb_helper *fb_helper = info->par; > >> + struct drm_device *dev = fb_helper->dev; > >> + unsigned int i; > >> + int ret = 0; > >> + > >> + drm_modeset_lock_all(dev); > >> + if (!drm_fb_helper_is_bound(fb_helper)) { > >> + drm_modeset_unlock_all(dev); > >> + return -EBUSY; > >> + } > >> + > >> + switch (cmd) { > >> + case FBIO_WAITFORVSYNC: > >> + for (i = 0; i < fb_helper->crtc_count; i++) { > >> + struct drm_mode_set *mode_set; > >> + struct drm_crtc *crtc; > >> + > >> + mode_set = &fb_helper->crtc_info[i].mode_set; > >> + crtc = mode_set->crtc; > >> + > >> + /* > >> + * Only call drm_crtc_wait_one_vblank for crtcs that > >> + * are currently enabled. > >> + */ > >> + if (!crtc->enabled) > >> + continue; > > > > This needs locking > > More locking than the drm_modeset_lock_all() above the switch? Ouch. :) Oh, I didn't spot that one. Well, that one should be removed imo, we dont want any vblank wait path to hold these locks, it looks bad. Otoh we still need to grab the dev->mode_config.mutex, because that's also the fbdev lock. There's a plan somewhere to give the fbdev helpers their own lock, so switching to just mode_config.mutex + the changes I suggestd would be good. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC 2017-02-02 10:31 ` Maxime Ripard @ 2017-02-10 14:06 ` Ville Syrjälä -1 siblings, 0 replies; 44+ messages in thread From: Ville Syrjälä @ 2017-02-10 14:06 UTC (permalink / raw) To: Maxime Ripard Cc: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, linux-kernel, dri-devel On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > From: Stefan Christ <s.christ@phytec.de> > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > based OpenGL(ES)/EGL implementations may require the ioctl to > synchronize drawing or buffer flip for double buffering. It is tested on > the i.MX6. > > Code is based on > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++- > include/drm/drm_fb_helper.h | 5 ++- > 2 files changed, 59 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index e934b541feea..39a3532e311c 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) > EXPORT_SYMBOL(drm_fb_helper_setcmap); > > /** > + * drm_fb_helper_ioctl - legacy ioctl implementation > + * @info: fbdev registered by the helper > + * @cmd: ioctl command > + * @arg: ioctl argument > + * > + * A helper to implement the standard fbdev ioctl. Only > + * FBIO_WAITFORVSYNC is implemented for now. > + */ > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) > +{ > + struct drm_fb_helper *fb_helper = info->par; > + struct drm_device *dev = fb_helper->dev; > + unsigned int i; > + int ret = 0; > + > + drm_modeset_lock_all(dev); > + if (!drm_fb_helper_is_bound(fb_helper)) { > + drm_modeset_unlock_all(dev); > + return -EBUSY; > + } > + > + switch (cmd) { > + case FBIO_WAITFORVSYNC: > + for (i = 0; i < fb_helper->crtc_count; i++) { FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want to do this for all the crtcs. Though what that crtc means for fb is rather poorly defined. > + struct drm_mode_set *mode_set; > + struct drm_crtc *crtc; > + > + mode_set = &fb_helper->crtc_info[i].mode_set; > + crtc = mode_set->crtc; > + > + /* > + * Only call drm_crtc_wait_one_vblank for crtcs that > + * are currently enabled. > + */ > + if (!crtc->enabled) > + continue; > + > + ret = drm_crtc_vblank_get(crtc); > + if (!ret) { > + drm_crtc_wait_one_vblank(crtc); > + drm_crtc_vblank_put(crtc); > + } This looks quite sub-optimal. It should rather do something along the lines of what drm_atomic_helper_wait_for_vblanks() does. > + } > + goto unlock; > + default: > + ret = -ENOTTY; > + } > + > +unlock: > + drm_modeset_unlock_all(dev); > + return ret; > +} > +EXPORT_SYMBOL(drm_fb_helper_ioctl); > + > +/** > * drm_fb_helper_check_var - implementation for ->fb_check_var > * @var: screeninfo to check > * @info: fbdev registered by the helper > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h > index 975deedd593e..460be9d9fa98 100644 > --- a/include/drm/drm_fb_helper.h > +++ b/include/drm/drm_fb_helper.h > @@ -230,7 +230,8 @@ struct drm_fb_helper { > .fb_blank = drm_fb_helper_blank, \ > .fb_pan_display = drm_fb_helper_pan_display, \ > .fb_debug_enter = drm_fb_helper_debug_enter, \ > - .fb_debug_leave = drm_fb_helper_debug_leave > + .fb_debug_leave = drm_fb_helper_debug_leave, \ > + .fb_ioctl = drm_fb_helper_ioctl > > #ifdef CONFIG_DRM_FBDEV_EMULATION > void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper, > @@ -286,6 +287,8 @@ void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper, > > int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info); > > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg); > + > int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper); > int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel); > int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper); > -- > git-series 0.8.11 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC @ 2017-02-10 14:06 ` Ville Syrjälä 0 siblings, 0 replies; 44+ messages in thread From: Ville Syrjälä @ 2017-02-10 14:06 UTC (permalink / raw) To: Maxime Ripard; +Cc: linux-kernel, dri-devel, Daniel Vetter, Stefan Christ On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > From: Stefan Christ <s.christ@phytec.de> > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > based OpenGL(ES)/EGL implementations may require the ioctl to > synchronize drawing or buffer flip for double buffering. It is tested on > the i.MX6. > > Code is based on > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++- > include/drm/drm_fb_helper.h | 5 ++- > 2 files changed, 59 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index e934b541feea..39a3532e311c 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) > EXPORT_SYMBOL(drm_fb_helper_setcmap); > > /** > + * drm_fb_helper_ioctl - legacy ioctl implementation > + * @info: fbdev registered by the helper > + * @cmd: ioctl command > + * @arg: ioctl argument > + * > + * A helper to implement the standard fbdev ioctl. Only > + * FBIO_WAITFORVSYNC is implemented for now. > + */ > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) > +{ > + struct drm_fb_helper *fb_helper = info->par; > + struct drm_device *dev = fb_helper->dev; > + unsigned int i; > + int ret = 0; > + > + drm_modeset_lock_all(dev); > + if (!drm_fb_helper_is_bound(fb_helper)) { > + drm_modeset_unlock_all(dev); > + return -EBUSY; > + } > + > + switch (cmd) { > + case FBIO_WAITFORVSYNC: > + for (i = 0; i < fb_helper->crtc_count; i++) { FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want to do this for all the crtcs. Though what that crtc means for fb is rather poorly defined. > + struct drm_mode_set *mode_set; > + struct drm_crtc *crtc; > + > + mode_set = &fb_helper->crtc_info[i].mode_set; > + crtc = mode_set->crtc; > + > + /* > + * Only call drm_crtc_wait_one_vblank for crtcs that > + * are currently enabled. > + */ > + if (!crtc->enabled) > + continue; > + > + ret = drm_crtc_vblank_get(crtc); > + if (!ret) { > + drm_crtc_wait_one_vblank(crtc); > + drm_crtc_vblank_put(crtc); > + } This looks quite sub-optimal. It should rather do something along the lines of what drm_atomic_helper_wait_for_vblanks() does. > + } > + goto unlock; > + default: > + ret = -ENOTTY; > + } > + > +unlock: > + drm_modeset_unlock_all(dev); > + return ret; > +} > +EXPORT_SYMBOL(drm_fb_helper_ioctl); > + > +/** > * drm_fb_helper_check_var - implementation for ->fb_check_var > * @var: screeninfo to check > * @info: fbdev registered by the helper > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h > index 975deedd593e..460be9d9fa98 100644 > --- a/include/drm/drm_fb_helper.h > +++ b/include/drm/drm_fb_helper.h > @@ -230,7 +230,8 @@ struct drm_fb_helper { > .fb_blank = drm_fb_helper_blank, \ > .fb_pan_display = drm_fb_helper_pan_display, \ > .fb_debug_enter = drm_fb_helper_debug_enter, \ > - .fb_debug_leave = drm_fb_helper_debug_leave > + .fb_debug_leave = drm_fb_helper_debug_leave, \ > + .fb_ioctl = drm_fb_helper_ioctl > > #ifdef CONFIG_DRM_FBDEV_EMULATION > void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper, > @@ -286,6 +287,8 @@ void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper, > > int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info); > > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg); > + > int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper); > int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel); > int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper); > -- > git-series 0.8.11 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC 2017-02-10 14:06 ` Ville Syrjälä @ 2017-02-13 10:35 ` Maxime Ripard -1 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-13 10:35 UTC (permalink / raw) To: Ville Syrjälä Cc: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, linux-kernel, dri-devel [-- Attachment #1: Type: text/plain, Size: 3476 bytes --] Hi Ville, On Fri, Feb 10, 2017 at 04:06:05PM +0200, Ville Syrjälä wrote: > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > > From: Stefan Christ <s.christ@phytec.de> > > > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > > based OpenGL(ES)/EGL implementations may require the ioctl to > > synchronize drawing or buffer flip for double buffering. It is tested on > > the i.MX6. > > > > Code is based on > > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 > > > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > --- > > drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++- > > include/drm/drm_fb_helper.h | 5 ++- > > 2 files changed, 59 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > > index e934b541feea..39a3532e311c 100644 > > --- a/drivers/gpu/drm/drm_fb_helper.c > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) > > EXPORT_SYMBOL(drm_fb_helper_setcmap); > > > > /** > > + * drm_fb_helper_ioctl - legacy ioctl implementation > > + * @info: fbdev registered by the helper > > + * @cmd: ioctl command > > + * @arg: ioctl argument > > + * > > + * A helper to implement the standard fbdev ioctl. Only > > + * FBIO_WAITFORVSYNC is implemented for now. > > + */ > > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) > > +{ > > + struct drm_fb_helper *fb_helper = info->par; > > + struct drm_device *dev = fb_helper->dev; > > + unsigned int i; > > + int ret = 0; > > + > > + drm_modeset_lock_all(dev); > > + if (!drm_fb_helper_is_bound(fb_helper)) { > > + drm_modeset_unlock_all(dev); > > + return -EBUSY; > > + } > > + > > + switch (cmd) { > > + case FBIO_WAITFORVSYNC: > > + for (i = 0; i < fb_helper->crtc_count; i++) { > > FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want > to do this for all the crtcs. Though what that crtc means for fb is > rather poorly defined. I guess I could just use that index to retrieve only the right CRTC in fb_helper->crtc_info. > > > + struct drm_mode_set *mode_set; > > + struct drm_crtc *crtc; > > + > > + mode_set = &fb_helper->crtc_info[i].mode_set; > > + crtc = mode_set->crtc; > > + > > + /* > > + * Only call drm_crtc_wait_one_vblank for crtcs that > > + * are currently enabled. > > + */ > > + if (!crtc->enabled) > > + continue; > > + > > + ret = drm_crtc_vblank_get(crtc); > > + if (!ret) { > > + drm_crtc_wait_one_vblank(crtc); > > + drm_crtc_vblank_put(crtc); > > + } > > This looks quite sub-optimal. It should rather do something along the > lines of what drm_atomic_helper_wait_for_vblanks() does. How is that suboptimal? As far as I can see, they are both doing the same thing (except one does for all the CRTCs, but I guess that would no longer be needed with the change you suggested above): - drm_crtc_vblank_get - Wait for the vblank count to change - drm_crtc_vblank_put Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC @ 2017-02-13 10:35 ` Maxime Ripard 0 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-13 10:35 UTC (permalink / raw) To: Ville Syrjälä Cc: linux-kernel, dri-devel, Daniel Vetter, Stefan Christ [-- Attachment #1.1: Type: text/plain, Size: 3476 bytes --] Hi Ville, On Fri, Feb 10, 2017 at 04:06:05PM +0200, Ville Syrjälä wrote: > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > > From: Stefan Christ <s.christ@phytec.de> > > > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > > based OpenGL(ES)/EGL implementations may require the ioctl to > > synchronize drawing or buffer flip for double buffering. It is tested on > > the i.MX6. > > > > Code is based on > > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 > > > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > --- > > drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++- > > include/drm/drm_fb_helper.h | 5 ++- > > 2 files changed, 59 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > > index e934b541feea..39a3532e311c 100644 > > --- a/drivers/gpu/drm/drm_fb_helper.c > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) > > EXPORT_SYMBOL(drm_fb_helper_setcmap); > > > > /** > > + * drm_fb_helper_ioctl - legacy ioctl implementation > > + * @info: fbdev registered by the helper > > + * @cmd: ioctl command > > + * @arg: ioctl argument > > + * > > + * A helper to implement the standard fbdev ioctl. Only > > + * FBIO_WAITFORVSYNC is implemented for now. > > + */ > > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) > > +{ > > + struct drm_fb_helper *fb_helper = info->par; > > + struct drm_device *dev = fb_helper->dev; > > + unsigned int i; > > + int ret = 0; > > + > > + drm_modeset_lock_all(dev); > > + if (!drm_fb_helper_is_bound(fb_helper)) { > > + drm_modeset_unlock_all(dev); > > + return -EBUSY; > > + } > > + > > + switch (cmd) { > > + case FBIO_WAITFORVSYNC: > > + for (i = 0; i < fb_helper->crtc_count; i++) { > > FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want > to do this for all the crtcs. Though what that crtc means for fb is > rather poorly defined. I guess I could just use that index to retrieve only the right CRTC in fb_helper->crtc_info. > > > + struct drm_mode_set *mode_set; > > + struct drm_crtc *crtc; > > + > > + mode_set = &fb_helper->crtc_info[i].mode_set; > > + crtc = mode_set->crtc; > > + > > + /* > > + * Only call drm_crtc_wait_one_vblank for crtcs that > > + * are currently enabled. > > + */ > > + if (!crtc->enabled) > > + continue; > > + > > + ret = drm_crtc_vblank_get(crtc); > > + if (!ret) { > > + drm_crtc_wait_one_vblank(crtc); > > + drm_crtc_vblank_put(crtc); > > + } > > This looks quite sub-optimal. It should rather do something along the > lines of what drm_atomic_helper_wait_for_vblanks() does. How is that suboptimal? As far as I can see, they are both doing the same thing (except one does for all the CRTCs, but I guess that would no longer be needed with the change you suggested above): - drm_crtc_vblank_get - Wait for the vblank count to change - drm_crtc_vblank_put Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC 2017-02-13 10:35 ` Maxime Ripard @ 2017-02-13 14:45 ` Ville Syrjälä -1 siblings, 0 replies; 44+ messages in thread From: Ville Syrjälä @ 2017-02-13 14:45 UTC (permalink / raw) To: Maxime Ripard Cc: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, linux-kernel, dri-devel On Mon, Feb 13, 2017 at 11:35:18AM +0100, Maxime Ripard wrote: > Hi Ville, > > On Fri, Feb 10, 2017 at 04:06:05PM +0200, Ville Syrjälä wrote: > > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > > > From: Stefan Christ <s.christ@phytec.de> > > > > > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > > > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > > > based OpenGL(ES)/EGL implementations may require the ioctl to > > > synchronize drawing or buffer flip for double buffering. It is tested on > > > the i.MX6. > > > > > > Code is based on > > > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 > > > > > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > > --- > > > drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++- > > > include/drm/drm_fb_helper.h | 5 ++- > > > 2 files changed, 59 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > > > index e934b541feea..39a3532e311c 100644 > > > --- a/drivers/gpu/drm/drm_fb_helper.c > > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) > > > EXPORT_SYMBOL(drm_fb_helper_setcmap); > > > > > > /** > > > + * drm_fb_helper_ioctl - legacy ioctl implementation > > > + * @info: fbdev registered by the helper > > > + * @cmd: ioctl command > > > + * @arg: ioctl argument > > > + * > > > + * A helper to implement the standard fbdev ioctl. Only > > > + * FBIO_WAITFORVSYNC is implemented for now. > > > + */ > > > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) > > > +{ > > > + struct drm_fb_helper *fb_helper = info->par; > > > + struct drm_device *dev = fb_helper->dev; > > > + unsigned int i; > > > + int ret = 0; > > > + > > > + drm_modeset_lock_all(dev); > > > + if (!drm_fb_helper_is_bound(fb_helper)) { > > > + drm_modeset_unlock_all(dev); > > > + return -EBUSY; > > > + } > > > + > > > + switch (cmd) { > > > + case FBIO_WAITFORVSYNC: > > > + for (i = 0; i < fb_helper->crtc_count; i++) { > > > > FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want > > to do this for all the crtcs. Though what that crtc means for fb is > > rather poorly defined. > > I guess I could just use that index to retrieve only the right CRTC in > fb_helper->crtc_info. > > > > > > + struct drm_mode_set *mode_set; > > > + struct drm_crtc *crtc; > > > + > > > + mode_set = &fb_helper->crtc_info[i].mode_set; > > > + crtc = mode_set->crtc; > > > + > > > + /* > > > + * Only call drm_crtc_wait_one_vblank for crtcs that > > > + * are currently enabled. > > > + */ > > > + if (!crtc->enabled) > > > + continue; > > > + > > > + ret = drm_crtc_vblank_get(crtc); > > > + if (!ret) { > > > + drm_crtc_wait_one_vblank(crtc); > > > + drm_crtc_vblank_put(crtc); > > > + } > > > > This looks quite sub-optimal. It should rather do something along the > > lines of what drm_atomic_helper_wait_for_vblanks() does. > > How is that suboptimal? You're serializing the waits rather than doing them in parallel. Let's look at a simple three crtc example (|=vblank): time --> CRTC 1: | | | | CRTC 2: | | | | CRTC 3: | | | | Your code waits until here: | | | 1 2 3 ^ Optimal code would wait until here: | ^ -- Ville Syrjälä Intel OTC ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC @ 2017-02-13 14:45 ` Ville Syrjälä 0 siblings, 0 replies; 44+ messages in thread From: Ville Syrjälä @ 2017-02-13 14:45 UTC (permalink / raw) To: Maxime Ripard; +Cc: linux-kernel, dri-devel, Daniel Vetter, Stefan Christ On Mon, Feb 13, 2017 at 11:35:18AM +0100, Maxime Ripard wrote: > Hi Ville, > > On Fri, Feb 10, 2017 at 04:06:05PM +0200, Ville Syrjälä wrote: > > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > > > From: Stefan Christ <s.christ@phytec.de> > > > > > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > > > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > > > based OpenGL(ES)/EGL implementations may require the ioctl to > > > synchronize drawing or buffer flip for double buffering. It is tested on > > > the i.MX6. > > > > > > Code is based on > > > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 > > > > > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > > --- > > > drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++- > > > include/drm/drm_fb_helper.h | 5 ++- > > > 2 files changed, 59 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > > > index e934b541feea..39a3532e311c 100644 > > > --- a/drivers/gpu/drm/drm_fb_helper.c > > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) > > > EXPORT_SYMBOL(drm_fb_helper_setcmap); > > > > > > /** > > > + * drm_fb_helper_ioctl - legacy ioctl implementation > > > + * @info: fbdev registered by the helper > > > + * @cmd: ioctl command > > > + * @arg: ioctl argument > > > + * > > > + * A helper to implement the standard fbdev ioctl. Only > > > + * FBIO_WAITFORVSYNC is implemented for now. > > > + */ > > > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) > > > +{ > > > + struct drm_fb_helper *fb_helper = info->par; > > > + struct drm_device *dev = fb_helper->dev; > > > + unsigned int i; > > > + int ret = 0; > > > + > > > + drm_modeset_lock_all(dev); > > > + if (!drm_fb_helper_is_bound(fb_helper)) { > > > + drm_modeset_unlock_all(dev); > > > + return -EBUSY; > > > + } > > > + > > > + switch (cmd) { > > > + case FBIO_WAITFORVSYNC: > > > + for (i = 0; i < fb_helper->crtc_count; i++) { > > > > FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want > > to do this for all the crtcs. Though what that crtc means for fb is > > rather poorly defined. > > I guess I could just use that index to retrieve only the right CRTC in > fb_helper->crtc_info. > > > > > > + struct drm_mode_set *mode_set; > > > + struct drm_crtc *crtc; > > > + > > > + mode_set = &fb_helper->crtc_info[i].mode_set; > > > + crtc = mode_set->crtc; > > > + > > > + /* > > > + * Only call drm_crtc_wait_one_vblank for crtcs that > > > + * are currently enabled. > > > + */ > > > + if (!crtc->enabled) > > > + continue; > > > + > > > + ret = drm_crtc_vblank_get(crtc); > > > + if (!ret) { > > > + drm_crtc_wait_one_vblank(crtc); > > > + drm_crtc_vblank_put(crtc); > > > + } > > > > This looks quite sub-optimal. It should rather do something along the > > lines of what drm_atomic_helper_wait_for_vblanks() does. > > How is that suboptimal? You're serializing the waits rather than doing them in parallel. Let's look at a simple three crtc example (|=vblank): time --> CRTC 1: | | | | CRTC 2: | | | | CRTC 3: | | | | Your code waits until here: | | | 1 2 3 ^ Optimal code would wait until here: | ^ -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC 2017-02-13 14:45 ` Ville Syrjälä @ 2017-02-15 14:06 ` Maxime Ripard -1 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-15 14:06 UTC (permalink / raw) To: Ville Syrjälä Cc: Daniel Vetter, David Airlie, Jani Nikula, Sean Paul, Stefan Christ, linux-kernel, dri-devel [-- Attachment #1: Type: text/plain, Size: 4402 bytes --] Hi, On Mon, Feb 13, 2017 at 04:45:33PM +0200, Ville Syrjälä wrote: > On Mon, Feb 13, 2017 at 11:35:18AM +0100, Maxime Ripard wrote: > > Hi Ville, > > > > On Fri, Feb 10, 2017 at 04:06:05PM +0200, Ville Syrjälä wrote: > > > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > > > > From: Stefan Christ <s.christ@phytec.de> > > > > > > > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > > > > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > > > > based OpenGL(ES)/EGL implementations may require the ioctl to > > > > synchronize drawing or buffer flip for double buffering. It is tested on > > > > the i.MX6. > > > > > > > > Code is based on > > > > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 > > > > > > > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > > > --- > > > > drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++- > > > > include/drm/drm_fb_helper.h | 5 ++- > > > > 2 files changed, 59 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > > > > index e934b541feea..39a3532e311c 100644 > > > > --- a/drivers/gpu/drm/drm_fb_helper.c > > > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > > > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) > > > > EXPORT_SYMBOL(drm_fb_helper_setcmap); > > > > > > > > /** > > > > + * drm_fb_helper_ioctl - legacy ioctl implementation > > > > + * @info: fbdev registered by the helper > > > > + * @cmd: ioctl command > > > > + * @arg: ioctl argument > > > > + * > > > > + * A helper to implement the standard fbdev ioctl. Only > > > > + * FBIO_WAITFORVSYNC is implemented for now. > > > > + */ > > > > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) > > > > +{ > > > > + struct drm_fb_helper *fb_helper = info->par; > > > > + struct drm_device *dev = fb_helper->dev; > > > > + unsigned int i; > > > > + int ret = 0; > > > > + > > > > + drm_modeset_lock_all(dev); > > > > + if (!drm_fb_helper_is_bound(fb_helper)) { > > > > + drm_modeset_unlock_all(dev); > > > > + return -EBUSY; > > > > + } > > > > + > > > > + switch (cmd) { > > > > + case FBIO_WAITFORVSYNC: > > > > + for (i = 0; i < fb_helper->crtc_count; i++) { > > > > > > FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want > > > to do this for all the crtcs. Though what that crtc means for fb is > > > rather poorly defined. > > > > I guess I could just use that index to retrieve only the right CRTC in > > fb_helper->crtc_info. > > > > > > > > > + struct drm_mode_set *mode_set; > > > > + struct drm_crtc *crtc; > > > > + > > > > + mode_set = &fb_helper->crtc_info[i].mode_set; > > > > + crtc = mode_set->crtc; > > > > + > > > > + /* > > > > + * Only call drm_crtc_wait_one_vblank for crtcs that > > > > + * are currently enabled. > > > > + */ > > > > + if (!crtc->enabled) > > > > + continue; > > > > + > > > > + ret = drm_crtc_vblank_get(crtc); > > > > + if (!ret) { > > > > + drm_crtc_wait_one_vblank(crtc); > > > > + drm_crtc_vblank_put(crtc); > > > > + } > > > > > > This looks quite sub-optimal. It should rather do something along the > > > lines of what drm_atomic_helper_wait_for_vblanks() does. > > > > How is that suboptimal? > > You're serializing the waits rather than doing them in parallel. > > Let's look at a simple three crtc example (|=vblank): > > time --> > CRTC 1: | | | | > CRTC 2: | | | | > CRTC 3: | | | | > > Your code waits until here: > | | | > 1 2 3 > ^ > > Optimal code would wait until here: > | > ^ Ah, right. But then, this would happen only if we loop over all the CRTCs, which shouldn't happen in the v2 as you suggested. Out of curiosity, how could we fix this if we were to loop over all the framebuffers? By waiting on any vblank count to change? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC @ 2017-02-15 14:06 ` Maxime Ripard 0 siblings, 0 replies; 44+ messages in thread From: Maxime Ripard @ 2017-02-15 14:06 UTC (permalink / raw) To: Ville Syrjälä Cc: linux-kernel, dri-devel, Daniel Vetter, Stefan Christ [-- Attachment #1.1: Type: text/plain, Size: 4402 bytes --] Hi, On Mon, Feb 13, 2017 at 04:45:33PM +0200, Ville Syrjälä wrote: > On Mon, Feb 13, 2017 at 11:35:18AM +0100, Maxime Ripard wrote: > > Hi Ville, > > > > On Fri, Feb 10, 2017 at 04:06:05PM +0200, Ville Syrjälä wrote: > > > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > > > > From: Stefan Christ <s.christ@phytec.de> > > > > > > > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic > > > > framebuffer emulation driver. Legacy framebuffer users like non kms/drm > > > > based OpenGL(ES)/EGL implementations may require the ioctl to > > > > synchronize drawing or buffer flip for double buffering. It is tested on > > > > the i.MX6. > > > > > > > > Code is based on > > > > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196 > > > > > > > > Signed-off-by: Stefan Christ <s.christ@phytec.de> > > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > > > --- > > > > drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++- > > > > include/drm/drm_fb_helper.h | 5 ++- > > > > 2 files changed, 59 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > > > > index e934b541feea..39a3532e311c 100644 > > > > --- a/drivers/gpu/drm/drm_fb_helper.c > > > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > > > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) > > > > EXPORT_SYMBOL(drm_fb_helper_setcmap); > > > > > > > > /** > > > > + * drm_fb_helper_ioctl - legacy ioctl implementation > > > > + * @info: fbdev registered by the helper > > > > + * @cmd: ioctl command > > > > + * @arg: ioctl argument > > > > + * > > > > + * A helper to implement the standard fbdev ioctl. Only > > > > + * FBIO_WAITFORVSYNC is implemented for now. > > > > + */ > > > > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) > > > > +{ > > > > + struct drm_fb_helper *fb_helper = info->par; > > > > + struct drm_device *dev = fb_helper->dev; > > > > + unsigned int i; > > > > + int ret = 0; > > > > + > > > > + drm_modeset_lock_all(dev); > > > > + if (!drm_fb_helper_is_bound(fb_helper)) { > > > > + drm_modeset_unlock_all(dev); > > > > + return -EBUSY; > > > > + } > > > > + > > > > + switch (cmd) { > > > > + case FBIO_WAITFORVSYNC: > > > > + for (i = 0; i < fb_helper->crtc_count; i++) { > > > > > > FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want > > > to do this for all the crtcs. Though what that crtc means for fb is > > > rather poorly defined. > > > > I guess I could just use that index to retrieve only the right CRTC in > > fb_helper->crtc_info. > > > > > > > > > + struct drm_mode_set *mode_set; > > > > + struct drm_crtc *crtc; > > > > + > > > > + mode_set = &fb_helper->crtc_info[i].mode_set; > > > > + crtc = mode_set->crtc; > > > > + > > > > + /* > > > > + * Only call drm_crtc_wait_one_vblank for crtcs that > > > > + * are currently enabled. > > > > + */ > > > > + if (!crtc->enabled) > > > > + continue; > > > > + > > > > + ret = drm_crtc_vblank_get(crtc); > > > > + if (!ret) { > > > > + drm_crtc_wait_one_vblank(crtc); > > > > + drm_crtc_vblank_put(crtc); > > > > + } > > > > > > This looks quite sub-optimal. It should rather do something along the > > > lines of what drm_atomic_helper_wait_for_vblanks() does. > > > > How is that suboptimal? > > You're serializing the waits rather than doing them in parallel. > > Let's look at a simple three crtc example (|=vblank): > > time --> > CRTC 1: | | | | > CRTC 2: | | | | > CRTC 3: | | | | > > Your code waits until here: > | | | > 1 2 3 > ^ > > Optimal code would wait until here: > | > ^ Ah, right. But then, this would happen only if we loop over all the CRTCs, which shouldn't happen in the v2 as you suggested. Out of curiosity, how could we fix this if we were to loop over all the framebuffers? By waiting on any vblank count to change? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev @ 2017-02-16 12:28 Tobias Jakobi 2017-02-16 18:41 ` Maxime Ripard 0 siblings, 1 reply; 44+ messages in thread From: Tobias Jakobi @ 2017-02-16 12:28 UTC (permalink / raw) To: ML dri-devel; +Cc: daniel.vetter, maxime.ripard, s.christ, Laurent Pinchart Hello, I'm not sure if I'm missing something here, but I don't see how this is supposed to work. This just multiplies the height of the drm_mode_fb_cmd2 object with the number of buffers. Let's say I have width=1024, height=768, then now I have a framebuffer which has height=2304 (in the num_buffers=3 case). At some point this FB is set as the primary plane, giving us a 1024x2304 mode. I don't think that this is intended. In my opinion this multi-buffer thing should touch drm_mode_fb_cmd2 at all. The underlying BO should be larger, but not the FB itself. If this is supposed to work, then the fbdev helpers should create as many FBs as there are buffers, and then offset each of these FB into the BO. What I'm also not seeing is code that handles the fbdev's virtual resolutions. After all num_buffers should only increase those. Same for the panning ioctl(). So, is this just a part of a larger series? I remember seeing such a hack in the Hardkernel vendor kernel. But there it only worked because of some bug in the crtc (mixer) code. With best wishes, Tobias P.S.: I'm signed up to dri-devel in digest mode, so sorry if this mail doesn't properly show up in the corresponding ml thread. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-16 12:28 [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Tobias Jakobi @ 2017-02-16 18:41 ` Maxime Ripard 2017-02-17 12:49 ` Tobias Jakobi 0 siblings, 1 reply; 44+ messages in thread From: Maxime Ripard @ 2017-02-16 18:41 UTC (permalink / raw) To: Tobias Jakobi; +Cc: daniel.vetter, s.christ, ML dri-devel, Laurent Pinchart [-- Attachment #1.1: Type: text/plain, Size: 1244 bytes --] Hi, On Thu, Feb 16, 2017 at 01:28:24PM +0100, Tobias Jakobi wrote: > Hello, > > I'm not sure if I'm missing something here, but I don't see how this is > supposed to work. > > This just multiplies the height of the drm_mode_fb_cmd2 object with the > number of buffers. Let's say I have width=1024, height=768, then now I > have a framebuffer which has height=2304 (in the num_buffers=3 case). At > some point this FB is set as the primary plane, giving us a 1024x2304 > mode. I don't think that this is intended. > > In my opinion this multi-buffer thing should touch drm_mode_fb_cmd2 at > all. The underlying BO should be larger, but not the FB itself. If this > is supposed to work, then the fbdev helpers should create as many FBs as > there are buffers, and then offset each of these FB into the BO. This only increases the virtual resolution, not the visible one. > What I'm also not seeing is code that handles the fbdev's virtual > resolutions. After all num_buffers should only increase those. Same for > the panning ioctl(). This is already implemented through drm_fb_helper_pan_display. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev 2017-02-16 18:41 ` Maxime Ripard @ 2017-02-17 12:49 ` Tobias Jakobi 0 siblings, 0 replies; 44+ messages in thread From: Tobias Jakobi @ 2017-02-17 12:49 UTC (permalink / raw) To: Maxime Ripard; +Cc: daniel.vetter, s.christ, ML dri-devel, Laurent Pinchart Hello Maxime, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2017 at 01:28:24PM +0100, Tobias Jakobi wrote: >> Hello, >> >> I'm not sure if I'm missing something here, but I don't see how this is >> supposed to work. >> >> This just multiplies the height of the drm_mode_fb_cmd2 object with the >> number of buffers. Let's say I have width=1024, height=768, then now I >> have a framebuffer which has height=2304 (in the num_buffers=3 case). At >> some point this FB is set as the primary plane, giving us a 1024x2304 >> mode. I don't think that this is intended. >> >> In my opinion this multi-buffer thing should touch drm_mode_fb_cmd2 at >> all. The underlying BO should be larger, but not the FB itself. If this >> is supposed to work, then the fbdev helpers should create as many FBs as >> there are buffers, and then offset each of these FB into the BO. > > This only increases the virtual resolution, not the visible one. hmm, OK, I guess I need to test this again then. The last time I checked such an approach was on vanilla-4.7.y IIRC. And there it failed miserably. >> What I'm also not seeing is code that handles the fbdev's virtual >> resolutions. After all num_buffers should only increase those. Same for >> the panning ioctl(). > > This is already implemented through drm_fb_helper_pan_display. Thanks, I'll take a look! With best wishes, Tobias > > Maxime > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2017-02-17 12:49 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-02 10:31 [PATCH v2 0/2] drm: Support framebuffer panning Maxime Ripard 2017-02-02 10:31 ` Maxime Ripard 2017-02-02 10:31 ` [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Maxime Ripard 2017-02-02 10:31 ` Maxime Ripard 2017-02-09 17:04 ` Daniel Vetter 2017-02-09 17:04 ` Daniel Vetter 2017-02-10 15:27 ` Maxime Ripard 2017-02-10 15:27 ` Maxime Ripard 2017-02-12 12:28 ` Laurent Pinchart 2017-02-12 12:28 ` Laurent Pinchart 2017-02-13 10:54 ` Maxime Ripard 2017-02-13 10:54 ` Maxime Ripard 2017-02-13 11:20 ` Daniel Stone 2017-02-13 11:20 ` Daniel Stone 2017-02-14 20:09 ` Daniel Vetter 2017-02-14 20:09 ` Daniel Vetter 2017-02-14 21:25 ` Laurent Pinchart 2017-02-14 21:25 ` Laurent Pinchart 2017-02-15 12:51 ` Maxime Ripard 2017-02-15 12:51 ` Maxime Ripard 2017-02-17 11:30 ` Laurent Pinchart 2017-02-15 12:38 ` Maxime Ripard 2017-02-15 12:38 ` Maxime Ripard 2017-02-17 11:23 ` Laurent Pinchart 2017-02-17 11:23 ` Laurent Pinchart 2017-02-02 10:31 ` [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC Maxime Ripard 2017-02-02 10:31 ` Maxime Ripard 2017-02-09 17:01 ` Daniel Vetter 2017-02-09 17:01 ` Daniel Vetter 2017-02-09 17:38 ` Daniel Stone 2017-02-09 17:38 ` Daniel Stone 2017-02-09 19:06 ` Daniel Vetter 2017-02-09 19:06 ` Daniel Vetter 2017-02-10 14:06 ` Ville Syrjälä 2017-02-10 14:06 ` Ville Syrjälä 2017-02-13 10:35 ` Maxime Ripard 2017-02-13 10:35 ` Maxime Ripard 2017-02-13 14:45 ` Ville Syrjälä 2017-02-13 14:45 ` Ville Syrjälä 2017-02-15 14:06 ` Maxime Ripard 2017-02-15 14:06 ` Maxime Ripard 2017-02-16 12:28 [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Tobias Jakobi 2017-02-16 18:41 ` Maxime Ripard 2017-02-17 12:49 ` Tobias Jakobi
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.