Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Fri, Jul 3, 2015 at 8:32 AM, Thierry Reding wrote: > On Tue, Jun 30, 2015 at 11:04:45AM +0200, Daniel Vetter wrote: >> On Tue, Jun 30, 2015 at 10:31 AM, Benjamin Gaignard >> wrote: >> > I think that what have been done by Rob with module_param is also a good >> > idea: >> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934 >> > >> > Can you mix compilation flag and module param ? >> >> Hm, the point of the kconfig is to not require all the legacy baggage >> from fbdev. But I guess a module option could be added later on too. >> bochs has it too. > > I think the option would primarily be useful for testing. I've often > needed to test modesetting code without fbdev getting in the way and the > only way to currently do that is by recompiling with legacy fbdev > disabled. The option would allow an fbdev-enabled kernel to be used but > disable the fbdev code if desired. and for debugging.. when things are going wrong it's nice for the first modeset to not happen under console_lock ;-) BR, -R > Thierry > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Jun 30, 2015 at 11:04:45AM +0200, Daniel Vetter wrote: > On Tue, Jun 30, 2015 at 10:31 AM, Benjamin Gaignard > wrote: > > I think that what have been done by Rob with module_param is also a good > > idea: > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934 > > > > Can you mix compilation flag and module param ? > > Hm, the point of the kconfig is to not require all the legacy baggage > from fbdev. But I guess a module option could be added later on too. > bochs has it too. I think the option would primarily be useful for testing. I've often needed to test modesetting code without fbdev getting in the way and the only way to currently do that is by recompiling with legacy fbdev disabled. The option would allow an fbdev-enabled kernel to be used but disable the fbdev code if desired. Thierry pgp7NTiItVHYl.pgp Description: PGP signature
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Jun 30, 2015 at 11:04:45AM +0200, Daniel Vetter wrote: On Tue, Jun 30, 2015 at 10:31 AM, Benjamin Gaignard benjamin.gaign...@linaro.org wrote: I think that what have been done by Rob with module_param is also a good idea: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934 Can you mix compilation flag and module param ? Hm, the point of the kconfig is to not require all the legacy baggage from fbdev. But I guess a module option could be added later on too. bochs has it too. I think the option would primarily be useful for testing. I've often needed to test modesetting code without fbdev getting in the way and the only way to currently do that is by recompiling with legacy fbdev disabled. The option would allow an fbdev-enabled kernel to be used but disable the fbdev code if desired. Thierry pgp7NTiItVHYl.pgp Description: PGP signature
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Fri, Jul 3, 2015 at 8:32 AM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Jun 30, 2015 at 11:04:45AM +0200, Daniel Vetter wrote: On Tue, Jun 30, 2015 at 10:31 AM, Benjamin Gaignard benjamin.gaign...@linaro.org wrote: I think that what have been done by Rob with module_param is also a good idea: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934 Can you mix compilation flag and module param ? Hm, the point of the kconfig is to not require all the legacy baggage from fbdev. But I guess a module option could be added later on too. bochs has it too. I think the option would primarily be useful for testing. I've often needed to test modesetting code without fbdev getting in the way and the only way to currently do that is by recompiling with legacy fbdev disabled. The option would allow an fbdev-enabled kernel to be used but disable the fbdev code if desired. and for debugging.. when things are going wrong it's nice for the first modeset to not happen under console_lock ;-) BR, -R Thierry ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi, On 06/30/2015 02:01 PM, Benjamin Gaignard wrote: Hi, I think that what have been done by Rob with module_param is also a good idea: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934 Can you mix compilation flag and module param ? I guess this won't be hard to do once we have a common fbdev emulation config option. We could consider this as a drm top level module param. I'll keep this in mind. Thanks, Archit Benjamin 2015-06-30 9:56 GMT+02:00 Archit Taneja : Hi, On 06/30/2015 12:40 PM, Daniel Vetter wrote: Any updates on this or too much distractions? I really think doing this would be awesome for the drm subsystem, instead of reinventing this wheel for each driver. I'd started on this again. I've got more free time now than before, so I should have something in a week or so. I agree it will help a lot (there are already two new drivers since we started discussing this!) Archit -Daniel On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter wrote: On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote: Hi, On 03/13/2015 02:36 PM, Daniel Vetter wrote: On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote: On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Hm yeah that's somewhat annoying indeed. What about the following: 1. We move all the #include from drivers into drm_fb_helper.h 2. Then we add stubs for these functions in drm_fb_helper.h, like this #if defined(CONFIG_FB) #include #else /* static inline stubs for all the fb stuff used by kms drivers */ #endif Imo this makes sense since kms drivers really have a bit a special situation with fbdev. They're not full-blown fbdev drivers and can be useful fully without fbdev. I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs won't really work because struct declarations(like fb_info) also get removed. I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself, but that seemed a bit too intrusive. This is what I'm currently doing: - Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would actually benefit if we have drm fb helpers for them. They are used in exactly the same manner by all the drivers. - For the rest of the functions that are sparsely used, I was considering making very simple drm_fb_* wrapper functions. Something like: void
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Jun 30, 2015 at 10:31 AM, Benjamin Gaignard wrote: > I think that what have been done by Rob with module_param is also a good idea: > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934 > > Can you mix compilation flag and module param ? Hm, the point of the kconfig is to not require all the legacy baggage from fbdev. But I guess a module option could be added later on too. bochs has it too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi, I think that what have been done by Rob with module_param is also a good idea: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934 Can you mix compilation flag and module param ? Benjamin 2015-06-30 9:56 GMT+02:00 Archit Taneja : > Hi, > > On 06/30/2015 12:40 PM, Daniel Vetter wrote: >> >> Any updates on this or too much distractions? I really think doing >> this would be awesome for the drm subsystem, instead of reinventing >> this wheel for each driver. > > > I'd started on this again. I've got more free time now than before, so I > should have something in a week or so. I agree it will help a lot (there are > already two new drivers since we started discussing this!) > > Archit > > >> -Daniel >> >> On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter wrote: >>> >>> On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote: Hi, On 03/13/2015 02:36 PM, Daniel Vetter wrote: > > On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote: >> >> >> >> On 03/11/2015 08:47 PM, Daniel Vetter wrote: >>> >>> On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: > > On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: >> >> On 03/10/2015 03:35 PM, Daniel Vetter wrote: >>> >>> On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: > > On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: >> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index 151a050..38f83a0 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER >> help >> FBDEV helpers for KMS drivers. >> >> +config DRM_FBDEV_EMULATION >> + bool "Enable legacy fbdev support for your modesetting >> driver" >> + depends on DRM >> + select DRM_KMS_HELPER >> + select DRM_KMS_FB_HELPER >> + select FB_SYS_FILLRECT >> + select FB_SYS_COPYAREA >> + select FB_SYS_IMAGEBLIT >> + select FB_SYS_FOPS >> + select FB_CFB_FILLRECT >> + select FB_CFB_COPYAREA >> + select FB_CFB_IMAGEBLIT >> + default y >> + help >> + Choose this option if you have a need for the legacy >> fbdev >> + support. Note that this support also provide the linux >> console >> + support on top of your modesetting driver. > > > Maybe clarify that for linux console support you also need > CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? >>> >>> >>> Hm right I've missed that. Reminds me that you need one more >>> patch at the >>> end to remove all the various select DRM_KMS_FB_HELPER from all >>> drm >>> drivers. Otherwise this knob here won't work by default if you >>> e.g. select >>> radeon. In general we can't mix explicit options with menu >>> entries with a >>> select. >> >> >> I was trying that out. Removing DRM_KMS_FB_HELPER and having >> DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff >> internally in >> their respective xyz_fbdev.c files. > > > But with the stubbed out functions that should work, right? Why > doesn't > it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. >>> >>> >>> Hm, sounds like we need another patch to stub out fb_set_suspend when >>> fbdev isn't enabled. Is there anything else? >> >> >> There are a handful of fb core functions which are called by drm >> drivers: >> >> fb_alloc_cmap/fb_dealloc_cmap >> >> fb_sys_read/fb_sys_write >> >> register_framebuffer/unregister_framebuffer/unlink_framebuffer/ >> remove_conflicting_framebuffers >> >> fb_set_suspend >> >> fb_deferred_io_init/fb_deferred_io_cleanup >> >> framebuffer_alloc/framebuffer_release > > > Hm yeah that's somewhat annoying indeed. What about the following: > 1. We move all the #include from drivers into > drm_fb_helper.h > > 2. Then we add stubs for these
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi,
On 06/30/2015 12:40 PM, Daniel Vetter wrote:
Any updates on this or too much distractions? I really think doing
this would be awesome for the drm subsystem, instead of reinventing
this wheel for each driver.
I'd started on this again. I've got more free time now than before, so I
should have something in a week or so. I agree it will help a lot (there
are already two new drivers since we started discussing this!)
Archit
-Daniel
On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter wrote:
On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:
Hi,
On 03/13/2015 02:36 PM, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
On 03/11/2015 08:47 PM, Daniel Vetter wrote:
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
On 03/10/2015 03:35 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool "Enable legacy fbdev support for your modesetting driver"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
DRM_KMS_FB_HELPER selects that for us, right?
Hm right I've missed that. Reminds me that you need one more patch at the
end to remove all the various select DRM_KMS_FB_HELPER from all drm
drivers. Otherwise this knob here won't work by default if you e.g. select
radeon. In general we can't mix explicit options with menu entries with a
select.
I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in
their respective xyz_fbdev.c files.
But with the stubbed out functions that should work, right? Why doesn't
it?
There are still calls to functions from fb core like fb_set_suspend and
register_framebuffer which aren't covered by the drm fb helper functions.
Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?
There are a handful of fb core functions which are called by drm drivers:
fb_alloc_cmap/fb_dealloc_cmap
fb_sys_read/fb_sys_write
register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers
fb_set_suspend
fb_deferred_io_init/fb_deferred_io_cleanup
framebuffer_alloc/framebuffer_release
Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include from drivers into drm_fb_helper.h
2. Then we add stubs for these functions in drm_fb_helper.h, like this
#if defined(CONFIG_FB)
#include
#else
/* static inline stubs for all the fb stuff used by kms drivers */
#endif
Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.
I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.
I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself,
but that seemed a bit too intrusive.
This is what I'm currently doing:
- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would
actually benefit if we have drm fb helpers for them. They are used in
exactly the same manner by all the drivers.
- For the rest of the functions that are sparsely used, I was considering
making very simple drm_fb_* wrapper functions. Something like:
void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
{
if (helper->fbdev)
fb_deferred_io_init(helper->fbdev);
}
We could have all fb calls called within drm_fb_helper.c, creating
drm_fb_helper_* stub functions would then be an easier task. What do you
think?
That's actually an option I considered, but I hoped we could do it with
less work. If this indeed works and you can create the patch that would be
awesome.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Any updates on this or too much distractions? I really think doing this would be awesome for the drm subsystem, instead of reinventing this wheel for each driver. -Daniel On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter wrote: > On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote: >> Hi, >> >> On 03/13/2015 02:36 PM, Daniel Vetter wrote: >> >On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote: >> >> >> >> >> >>On 03/11/2015 08:47 PM, Daniel Vetter wrote: >> >>>On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: >> >> >> On 03/10/2015 05:47 PM, Daniel Vetter wrote: >> >On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: >> >>On 03/10/2015 03:35 PM, Daniel Vetter wrote: >> >>>On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: >> On 03/10/2015 03:17 PM, Daniel Vetter wrote: >> >On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: >> >>diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> >>index 151a050..38f83a0 100644 >> >>--- a/drivers/gpu/drm/Kconfig >> >>+++ b/drivers/gpu/drm/Kconfig >> >>@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER >> >>help >> >> FBDEV helpers for KMS drivers. >> >> >> >>+config DRM_FBDEV_EMULATION >> >>+ bool "Enable legacy fbdev support for your modesetting driver" >> >>+ depends on DRM >> >>+ select DRM_KMS_HELPER >> >>+ select DRM_KMS_FB_HELPER >> >>+ select FB_SYS_FILLRECT >> >>+ select FB_SYS_COPYAREA >> >>+ select FB_SYS_IMAGEBLIT >> >>+ select FB_SYS_FOPS >> >>+ select FB_CFB_FILLRECT >> >>+ select FB_CFB_COPYAREA >> >>+ select FB_CFB_IMAGEBLIT >> >>+ default y >> >>+ help >> >>+ Choose this option if you have a need for the legacy fbdev >> >>+ support. Note that this support also provide the linux >> >>console >> >>+ support on top of your modesetting driver. >> > >> >Maybe clarify that for linux console support you also need >> >CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. >> >> DRM_KMS_FB_HELPER selects that for us, right? >> >>> >> >>>Hm right I've missed that. Reminds me that you need one more patch at >> >>>the >> >>>end to remove all the various select DRM_KMS_FB_HELPER from all drm >> >>>drivers. Otherwise this knob here won't work by default if you e.g. >> >>>select >> >>>radeon. In general we can't mix explicit options with menu entries >> >>>with a >> >>>select. >> >> >> >>I was trying that out. Removing DRM_KMS_FB_HELPER and having >> >>DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff >> >>internally in >> >>their respective xyz_fbdev.c files. >> > >> >But with the stubbed out functions that should work, right? Why doesn't >> >it? >> >> There are still calls to functions from fb core like fb_set_suspend and >> register_framebuffer which aren't covered by the drm fb helper functions. >> >>> >> >>>Hm, sounds like we need another patch to stub out fb_set_suspend when >> >>>fbdev isn't enabled. Is there anything else? >> >> >> >>There are a handful of fb core functions which are called by drm drivers: >> >> >> >>fb_alloc_cmap/fb_dealloc_cmap >> >> >> >>fb_sys_read/fb_sys_write >> >> >> >>register_framebuffer/unregister_framebuffer/unlink_framebuffer/ >> >>remove_conflicting_framebuffers >> >> >> >>fb_set_suspend >> >> >> >>fb_deferred_io_init/fb_deferred_io_cleanup >> >> >> >>framebuffer_alloc/framebuffer_release >> > >> >Hm yeah that's somewhat annoying indeed. What about the following: >> >1. We move all the #include from drivers into drm_fb_helper.h >> > >> >2. Then we add stubs for these functions in drm_fb_helper.h, like this >> > >> >#if defined(CONFIG_FB) >> >#include >> >#else >> > >> >/* static inline stubs for all the fb stuff used by kms drivers */ >> >#endif >> > >> >Imo this makes sense since kms drivers really have a bit a special >> >situation with fbdev. They're not full-blown fbdev drivers and can be >> >useful fully without fbdev. >> > >> >> I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs >> won't really work because struct declarations(like fb_info) also get >> removed. >> >> I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself, >> but that seemed a bit too intrusive. >> >> This is what I'm currently doing: >> >> - Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would >> actually benefit if we have drm fb helpers for them. They are used in >> exactly the same manner by all the drivers. >> >> - For the rest of the functions that are sparsely used, I was considering >> making very simple drm_fb_* wrapper functions. Something like: >> >> void
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi,
I think that what have been done by Rob with module_param is also a good idea:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934
Can you mix compilation flag and module param ?
Benjamin
2015-06-30 9:56 GMT+02:00 Archit Taneja arch...@codeaurora.org:
Hi,
On 06/30/2015 12:40 PM, Daniel Vetter wrote:
Any updates on this or too much distractions? I really think doing
this would be awesome for the drm subsystem, instead of reinventing
this wheel for each driver.
I'd started on this again. I've got more free time now than before, so I
should have something in a week or so. I agree it will help a lot (there are
already two new drivers since we started discussing this!)
Archit
-Daniel
On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:
Hi,
On 03/13/2015 02:36 PM, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
On 03/11/2015 08:47 PM, Daniel Vetter wrote:
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
On 03/10/2015 03:35 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool Enable legacy fbdev support for your modesetting
driver
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy
fbdev
+ support. Note that this support also provide the linux
console
+ support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
DRM_KMS_FB_HELPER selects that for us, right?
Hm right I've missed that. Reminds me that you need one more
patch at the
end to remove all the various select DRM_KMS_FB_HELPER from all
drm
drivers. Otherwise this knob here won't work by default if you
e.g. select
radeon. In general we can't mix explicit options with menu
entries with a
select.
I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff
internally in
their respective xyz_fbdev.c files.
But with the stubbed out functions that should work, right? Why
doesn't
it?
There are still calls to functions from fb core like fb_set_suspend
and
register_framebuffer which aren't covered by the drm fb helper
functions.
Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?
There are a handful of fb core functions which are called by drm
drivers:
fb_alloc_cmap/fb_dealloc_cmap
fb_sys_read/fb_sys_write
register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers
fb_set_suspend
fb_deferred_io_init/fb_deferred_io_cleanup
framebuffer_alloc/framebuffer_release
Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include linux/fb.h from drivers into
drm_fb_helper.h
2. Then we add stubs for these functions in drm_fb_helper.h, like this
#if defined(CONFIG_FB)
#include linux/fb.h
#else
/* static inline stubs for all the fb stuff used by kms drivers */
#endif
Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.
I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.
I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h
itself,
but that seemed a bit too intrusive.
This is what I'm currently doing:
- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap
would
actually benefit if we have drm fb helpers for them. They are used in
exactly the same manner by all the drivers.
- For the rest of the functions that are sparsely used, I was
considering
making very simple drm_fb_* wrapper functions. Something like:
void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
{
if (helper-fbdev)
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi, On 06/30/2015 02:01 PM, Benjamin Gaignard wrote: Hi, I think that what have been done by Rob with module_param is also a good idea: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934 Can you mix compilation flag and module param ? I guess this won't be hard to do once we have a common fbdev emulation config option. We could consider this as a drm top level module param. I'll keep this in mind. Thanks, Archit Benjamin 2015-06-30 9:56 GMT+02:00 Archit Taneja arch...@codeaurora.org: Hi, On 06/30/2015 12:40 PM, Daniel Vetter wrote: Any updates on this or too much distractions? I really think doing this would be awesome for the drm subsystem, instead of reinventing this wheel for each driver. I'd started on this again. I've got more free time now than before, so I should have something in a week or so. I agree it will help a lot (there are already two new drivers since we started discussing this!) Archit -Daniel On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote: Hi, On 03/13/2015 02:36 PM, Daniel Vetter wrote: On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote: On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Hm yeah that's somewhat annoying indeed. What about the following: 1. We move all the #include linux/fb.h from drivers into drm_fb_helper.h 2. Then we add stubs for these functions in drm_fb_helper.h, like this #if defined(CONFIG_FB) #include linux/fb.h #else /* static inline stubs for all the fb stuff used by kms drivers */ #endif Imo this makes sense since kms drivers really have a bit a special situation with fbdev. They're not full-blown fbdev drivers and can be useful fully without fbdev. I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs won't really work because struct declarations(like fb_info) also get removed. I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself, but that seemed a bit too intrusive. This is what I'm currently doing: - Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would actually benefit if we have drm fb helpers for them. They are used in exactly the same manner by all the drivers. - For the rest of the functions that are sparsely used, I was considering making very simple drm_fb_* wrapper
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi,
On 06/30/2015 12:40 PM, Daniel Vetter wrote:
Any updates on this or too much distractions? I really think doing
this would be awesome for the drm subsystem, instead of reinventing
this wheel for each driver.
I'd started on this again. I've got more free time now than before, so I
should have something in a week or so. I agree it will help a lot (there
are already two new drivers since we started discussing this!)
Archit
-Daniel
On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:
Hi,
On 03/13/2015 02:36 PM, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
On 03/11/2015 08:47 PM, Daniel Vetter wrote:
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
On 03/10/2015 03:35 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool Enable legacy fbdev support for your modesetting driver
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
DRM_KMS_FB_HELPER selects that for us, right?
Hm right I've missed that. Reminds me that you need one more patch at the
end to remove all the various select DRM_KMS_FB_HELPER from all drm
drivers. Otherwise this knob here won't work by default if you e.g. select
radeon. In general we can't mix explicit options with menu entries with a
select.
I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in
their respective xyz_fbdev.c files.
But with the stubbed out functions that should work, right? Why doesn't
it?
There are still calls to functions from fb core like fb_set_suspend and
register_framebuffer which aren't covered by the drm fb helper functions.
Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?
There are a handful of fb core functions which are called by drm drivers:
fb_alloc_cmap/fb_dealloc_cmap
fb_sys_read/fb_sys_write
register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers
fb_set_suspend
fb_deferred_io_init/fb_deferred_io_cleanup
framebuffer_alloc/framebuffer_release
Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include linux/fb.h from drivers into drm_fb_helper.h
2. Then we add stubs for these functions in drm_fb_helper.h, like this
#if defined(CONFIG_FB)
#include linux/fb.h
#else
/* static inline stubs for all the fb stuff used by kms drivers */
#endif
Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.
I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.
I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself,
but that seemed a bit too intrusive.
This is what I'm currently doing:
- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would
actually benefit if we have drm fb helpers for them. They are used in
exactly the same manner by all the drivers.
- For the rest of the functions that are sparsely used, I was considering
making very simple drm_fb_* wrapper functions. Something like:
void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
{
if (helper-fbdev)
fb_deferred_io_init(helper-fbdev);
}
We could have all fb calls called within drm_fb_helper.c, creating
drm_fb_helper_* stub functions would then be an easier task. What do you
think?
That's actually an option I considered, but I hoped we could do it with
less work. If this indeed works and you can create the patch that would be
awesome.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
Qualcomm Innovation Center, Inc. is a member of Code
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Jun 30, 2015 at 10:31 AM, Benjamin Gaignard benjamin.gaign...@linaro.org wrote: I think that what have been done by Rob with module_param is also a good idea: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934 Can you mix compilation flag and module param ? Hm, the point of the kconfig is to not require all the legacy baggage from fbdev. But I guess a module option could be added later on too. bochs has it too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Any updates on this or too much distractions? I really think doing
this would be awesome for the drm subsystem, instead of reinventing
this wheel for each driver.
-Daniel
On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:
Hi,
On 03/13/2015 02:36 PM, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
On 03/11/2015 08:47 PM, Daniel Vetter wrote:
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
On 03/10/2015 03:35 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool Enable legacy fbdev support for your modesetting driver
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux
console
+ support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
DRM_KMS_FB_HELPER selects that for us, right?
Hm right I've missed that. Reminds me that you need one more patch at
the
end to remove all the various select DRM_KMS_FB_HELPER from all drm
drivers. Otherwise this knob here won't work by default if you e.g.
select
radeon. In general we can't mix explicit options with menu entries
with a
select.
I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff
internally in
their respective xyz_fbdev.c files.
But with the stubbed out functions that should work, right? Why doesn't
it?
There are still calls to functions from fb core like fb_set_suspend and
register_framebuffer which aren't covered by the drm fb helper functions.
Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?
There are a handful of fb core functions which are called by drm drivers:
fb_alloc_cmap/fb_dealloc_cmap
fb_sys_read/fb_sys_write
register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers
fb_set_suspend
fb_deferred_io_init/fb_deferred_io_cleanup
framebuffer_alloc/framebuffer_release
Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include linux/fb.h from drivers into drm_fb_helper.h
2. Then we add stubs for these functions in drm_fb_helper.h, like this
#if defined(CONFIG_FB)
#include linux/fb.h
#else
/* static inline stubs for all the fb stuff used by kms drivers */
#endif
Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.
I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.
I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself,
but that seemed a bit too intrusive.
This is what I'm currently doing:
- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would
actually benefit if we have drm fb helpers for them. They are used in
exactly the same manner by all the drivers.
- For the rest of the functions that are sparsely used, I was considering
making very simple drm_fb_* wrapper functions. Something like:
void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
{
if (helper-fbdev)
fb_deferred_io_init(helper-fbdev);
}
We could have all fb calls called within drm_fb_helper.c, creating
drm_fb_helper_* stub functions would then be an easier task. What do you
think?
That's actually an option I considered, but I hoped we could do it with
less work. If this indeed works and you can create the patch that would be
awesome.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:
> Hi,
>
> On 03/13/2015 02:36 PM, Daniel Vetter wrote:
> >On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
> >>
> >>
> >>On 03/11/2015 08:47 PM, Daniel Vetter wrote:
> >>>On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
>
>
> On 03/10/2015 05:47 PM, Daniel Vetter wrote:
> >On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
> >>On 03/10/2015 03:35 PM, Daniel Vetter wrote:
> >>>On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
> On 03/10/2015 03:17 PM, Daniel Vetter wrote:
> >On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
> >>diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> >>index 151a050..38f83a0 100644
> >>--- a/drivers/gpu/drm/Kconfig
> >>+++ b/drivers/gpu/drm/Kconfig
> >>@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
> >>help
> >> FBDEV helpers for KMS drivers.
> >>
> >>+config DRM_FBDEV_EMULATION
> >>+ bool "Enable legacy fbdev support for your modesetting driver"
> >>+ depends on DRM
> >>+ select DRM_KMS_HELPER
> >>+ select DRM_KMS_FB_HELPER
> >>+ select FB_SYS_FILLRECT
> >>+ select FB_SYS_COPYAREA
> >>+ select FB_SYS_IMAGEBLIT
> >>+ select FB_SYS_FOPS
> >>+ select FB_CFB_FILLRECT
> >>+ select FB_CFB_COPYAREA
> >>+ select FB_CFB_IMAGEBLIT
> >>+ default y
> >>+ help
> >>+ Choose this option if you have a need for the legacy fbdev
> >>+ support. Note that this support also provide the linux console
> >>+ support on top of your modesetting driver.
> >
> >Maybe clarify that for linux console support you also need
> >CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
>
> DRM_KMS_FB_HELPER selects that for us, right?
> >>>
> >>>Hm right I've missed that. Reminds me that you need one more patch at
> >>>the
> >>>end to remove all the various select DRM_KMS_FB_HELPER from all drm
> >>>drivers. Otherwise this knob here won't work by default if you e.g.
> >>>select
> >>>radeon. In general we can't mix explicit options with menu entries
> >>>with a
> >>>select.
> >>
> >>I was trying that out. Removing DRM_KMS_FB_HELPER and having
> >>DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff
> >>internally in
> >>their respective xyz_fbdev.c files.
> >
> >But with the stubbed out functions that should work, right? Why doesn't
> >it?
>
> There are still calls to functions from fb core like fb_set_suspend and
> register_framebuffer which aren't covered by the drm fb helper functions.
> >>>
> >>>Hm, sounds like we need another patch to stub out fb_set_suspend when
> >>>fbdev isn't enabled. Is there anything else?
> >>
> >>There are a handful of fb core functions which are called by drm drivers:
> >>
> >>fb_alloc_cmap/fb_dealloc_cmap
> >>
> >>fb_sys_read/fb_sys_write
> >>
> >>register_framebuffer/unregister_framebuffer/unlink_framebuffer/
> >>remove_conflicting_framebuffers
> >>
> >>fb_set_suspend
> >>
> >>fb_deferred_io_init/fb_deferred_io_cleanup
> >>
> >>framebuffer_alloc/framebuffer_release
> >
> >Hm yeah that's somewhat annoying indeed. What about the following:
> >1. We move all the #include from drivers into drm_fb_helper.h
> >
> >2. Then we add stubs for these functions in drm_fb_helper.h, like this
> >
> >#if defined(CONFIG_FB)
> >#include
> >#else
> >
> >/* static inline stubs for all the fb stuff used by kms drivers */
> >#endif
> >
> >Imo this makes sense since kms drivers really have a bit a special
> >situation with fbdev. They're not full-blown fbdev drivers and can be
> >useful fully without fbdev.
> >
>
> I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
> won't really work because struct declarations(like fb_info) also get
> removed.
>
> I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself,
> but that seemed a bit too intrusive.
>
> This is what I'm currently doing:
>
> - Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would
> actually benefit if we have drm fb helpers for them. They are used in
> exactly the same manner by all the drivers.
>
> - For the rest of the functions that are sparsely used, I was considering
> making very simple drm_fb_* wrapper functions. Something like:
>
> void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
> {
> if (helper->fbdev)
> fb_deferred_io_init(helper->fbdev);
> }
>
> We could have all fb calls called within drm_fb_helper.c, creating
> drm_fb_helper_* stub functions would then be an easier task. What do you
> think?
That's actually an option I considered, but I hoped we could do it with
less work.
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi,
On 03/13/2015 02:36 PM, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
On 03/11/2015 08:47 PM, Daniel Vetter wrote:
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
On 03/10/2015 03:35 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool "Enable legacy fbdev support for your modesetting driver"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
DRM_KMS_FB_HELPER selects that for us, right?
Hm right I've missed that. Reminds me that you need one more patch at the
end to remove all the various select DRM_KMS_FB_HELPER from all drm
drivers. Otherwise this knob here won't work by default if you e.g. select
radeon. In general we can't mix explicit options with menu entries with a
select.
I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in
their respective xyz_fbdev.c files.
But with the stubbed out functions that should work, right? Why doesn't
it?
There are still calls to functions from fb core like fb_set_suspend and
register_framebuffer which aren't covered by the drm fb helper functions.
Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?
There are a handful of fb core functions which are called by drm drivers:
fb_alloc_cmap/fb_dealloc_cmap
fb_sys_read/fb_sys_write
register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers
fb_set_suspend
fb_deferred_io_init/fb_deferred_io_cleanup
framebuffer_alloc/framebuffer_release
Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include from drivers into drm_fb_helper.h
2. Then we add stubs for these functions in drm_fb_helper.h, like this
#if defined(CONFIG_FB)
#include
#else
/* static inline stubs for all the fb stuff used by kms drivers */
#endif
Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.
I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.
I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h
itself, but that seemed a bit too intrusive.
This is what I'm currently doing:
- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap
would actually benefit if we have drm fb helpers for them. They are used
in exactly the same manner by all the drivers.
- For the rest of the functions that are sparsely used, I was
considering making very simple drm_fb_* wrapper functions. Something like:
void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
{
if (helper->fbdev)
fb_deferred_io_init(helper->fbdev);
}
We could have all fb calls called within drm_fb_helper.c, creating
drm_fb_helper_* stub functions would then be an easier task. What do you
think?
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi,
On 03/13/2015 02:36 PM, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
On 03/11/2015 08:47 PM, Daniel Vetter wrote:
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
On 03/10/2015 03:35 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool Enable legacy fbdev support for your modesetting driver
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
DRM_KMS_FB_HELPER selects that for us, right?
Hm right I've missed that. Reminds me that you need one more patch at the
end to remove all the various select DRM_KMS_FB_HELPER from all drm
drivers. Otherwise this knob here won't work by default if you e.g. select
radeon. In general we can't mix explicit options with menu entries with a
select.
I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in
their respective xyz_fbdev.c files.
But with the stubbed out functions that should work, right? Why doesn't
it?
There are still calls to functions from fb core like fb_set_suspend and
register_framebuffer which aren't covered by the drm fb helper functions.
Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?
There are a handful of fb core functions which are called by drm drivers:
fb_alloc_cmap/fb_dealloc_cmap
fb_sys_read/fb_sys_write
register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers
fb_set_suspend
fb_deferred_io_init/fb_deferred_io_cleanup
framebuffer_alloc/framebuffer_release
Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include linux/fb.h from drivers into drm_fb_helper.h
2. Then we add stubs for these functions in drm_fb_helper.h, like this
#if defined(CONFIG_FB)
#include linux/fb.h
#else
/* static inline stubs for all the fb stuff used by kms drivers */
#endif
Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.
I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.
I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h
itself, but that seemed a bit too intrusive.
This is what I'm currently doing:
- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap
would actually benefit if we have drm fb helpers for them. They are used
in exactly the same manner by all the drivers.
- For the rest of the functions that are sparsely used, I was
considering making very simple drm_fb_* wrapper functions. Something like:
void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
{
if (helper-fbdev)
fb_deferred_io_init(helper-fbdev);
}
We could have all fb calls called within drm_fb_helper.c, creating
drm_fb_helper_* stub functions would then be an easier task. What do you
think?
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:
Hi,
On 03/13/2015 02:36 PM, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
On 03/11/2015 08:47 PM, Daniel Vetter wrote:
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
On 03/10/2015 03:35 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool Enable legacy fbdev support for your modesetting driver
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
DRM_KMS_FB_HELPER selects that for us, right?
Hm right I've missed that. Reminds me that you need one more patch at
the
end to remove all the various select DRM_KMS_FB_HELPER from all drm
drivers. Otherwise this knob here won't work by default if you e.g.
select
radeon. In general we can't mix explicit options with menu entries
with a
select.
I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff
internally in
their respective xyz_fbdev.c files.
But with the stubbed out functions that should work, right? Why doesn't
it?
There are still calls to functions from fb core like fb_set_suspend and
register_framebuffer which aren't covered by the drm fb helper functions.
Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?
There are a handful of fb core functions which are called by drm drivers:
fb_alloc_cmap/fb_dealloc_cmap
fb_sys_read/fb_sys_write
register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers
fb_set_suspend
fb_deferred_io_init/fb_deferred_io_cleanup
framebuffer_alloc/framebuffer_release
Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include linux/fb.h from drivers into drm_fb_helper.h
2. Then we add stubs for these functions in drm_fb_helper.h, like this
#if defined(CONFIG_FB)
#include linux/fb.h
#else
/* static inline stubs for all the fb stuff used by kms drivers */
#endif
Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.
I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.
I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself,
but that seemed a bit too intrusive.
This is what I'm currently doing:
- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would
actually benefit if we have drm fb helpers for them. They are used in
exactly the same manner by all the drivers.
- For the rest of the functions that are sparsely used, I was considering
making very simple drm_fb_* wrapper functions. Something like:
void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
{
if (helper-fbdev)
fb_deferred_io_init(helper-fbdev);
}
We could have all fb calls called within drm_fb_helper.c, creating
drm_fb_helper_* stub functions would then be an easier task. What do you
think?
That's actually an option I considered, but I hoped we could do it with
less work. If this indeed works and you can create the patch that would be
awesome.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/13/2015 02:36 PM, Daniel Vetter wrote: On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote: On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Hm yeah that's somewhat annoying indeed. What about the following: 1. We move all the #include from drivers into drm_fb_helper.h 2. Then we add stubs for these functions in drm_fb_helper.h, like this #if defined(CONFIG_FB) #include #else /* static inline stubs for all the fb stuff used by kms drivers */ #endif Imo this makes sense since kms drivers really have a bit a special situation with fbdev. They're not full-blown fbdev drivers and can be useful fully without fbdev. What do you think? This looks good! I'll give it a try. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Fri, 13 Mar 2015, Daniel Vetter wrote: > #if defined(CONFIG_FB) > #include > #else Side note, #if IS_ENABLED(CONFIG_FB) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote: > > > On 03/11/2015 08:47 PM, Daniel Vetter wrote: > >On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: > >> > >> > >>On 03/10/2015 05:47 PM, Daniel Vetter wrote: > >>>On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: > On 03/10/2015 03:35 PM, Daniel Vetter wrote: > >On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: > >>On 03/10/2015 03:17 PM, Daniel Vetter wrote: > >>>On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 151a050..38f83a0 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER > help > FBDEV helpers for KMS drivers. > > +config DRM_FBDEV_EMULATION > + bool "Enable legacy fbdev support for your modesetting driver" > + depends on DRM > + select DRM_KMS_HELPER > + select DRM_KMS_FB_HELPER > + select FB_SYS_FILLRECT > + select FB_SYS_COPYAREA > + select FB_SYS_IMAGEBLIT > + select FB_SYS_FOPS > + select FB_CFB_FILLRECT > + select FB_CFB_COPYAREA > + select FB_CFB_IMAGEBLIT > + default y > + help > + Choose this option if you have a need for the legacy fbdev > + support. Note that this support also provide the linux console > + support on top of your modesetting driver. > >>> > >>>Maybe clarify that for linux console support you also need > >>>CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. > >> > >>DRM_KMS_FB_HELPER selects that for us, right? > > > >Hm right I've missed that. Reminds me that you need one more patch at the > >end to remove all the various select DRM_KMS_FB_HELPER from all drm > >drivers. Otherwise this knob here won't work by default if you e.g. > >select > >radeon. In general we can't mix explicit options with menu entries with a > >select. > > I was trying that out. Removing DRM_KMS_FB_HELPER and having > DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally > in > their respective xyz_fbdev.c files. > >>> > >>>But with the stubbed out functions that should work, right? Why doesn't > >>>it? > >> > >>There are still calls to functions from fb core like fb_set_suspend and > >>register_framebuffer which aren't covered by the drm fb helper functions. > > > >Hm, sounds like we need another patch to stub out fb_set_suspend when > >fbdev isn't enabled. Is there anything else? > > There are a handful of fb core functions which are called by drm drivers: > > fb_alloc_cmap/fb_dealloc_cmap > > fb_sys_read/fb_sys_write > > register_framebuffer/unregister_framebuffer/unlink_framebuffer/ > remove_conflicting_framebuffers > > fb_set_suspend > > fb_deferred_io_init/fb_deferred_io_cleanup > > framebuffer_alloc/framebuffer_release Hm yeah that's somewhat annoying indeed. What about the following: 1. We move all the #include from drivers into drm_fb_helper.h 2. Then we add stubs for these functions in drm_fb_helper.h, like this #if defined(CONFIG_FB) #include #else /* static inline stubs for all the fb stuff used by kms drivers */ #endif Imo this makes sense since kms drivers really have a bit a special situation with fbdev. They're not full-blown fbdev drivers and can be useful fully without fbdev. What do you think? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. The problem with the patch as-is the massive amounts of selects the FB helper still has. We need to get rid of them so that when you disable fbdev emulation you can indeed disable fbcon and the entire fbdev subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER and moving all the selects to DRM_FBDEV_EMULATION should work out? If that doesn't work we need to look again how to better stub things out I think. That's true. Also, as Jani pointed out, maybe it isn't the best idea to make every kms driver select DRM_FBDEV_EMULATION? Maybe the drivers that are currently built with fbdev emulation by default can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y, the drivers should run as is. Later, we could take up each driver and build the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915 and msm? Yeah we definitely can't mix select with a user-visible option. I think we just need to fix up the remaining functions and create stubs for them if needed and then drop all the selects. Well in DRM_FBDEV_EMULATION we should still select for fbcon since otherwise tons of bug reports about "where is my fbcon with kms?". I'll give this a try. Although, it would be a better idea to make the drivers not call these at all when fbdev emulation isn't asked for. With the stubs, if someone does try to use the driver with DRM_FBDEV_EMULATION not set, the worst that'll happen would be that the driver fails to probe. Which isn't so bad. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. The problem with the patch as-is the massive amounts of selects the FB helper still has. We need to get rid of them so that when you disable fbdev emulation you can indeed disable fbcon and the entire fbdev subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER and moving all the selects to DRM_FBDEV_EMULATION should work out? If that doesn't work we need to look again how to better stub things out I think. That's true. Also, as Jani pointed out, maybe it isn't the best idea to make every kms driver select DRM_FBDEV_EMULATION? Maybe the drivers that are currently built with fbdev emulation by default can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y, the drivers should run as is. Later, we could take up each driver and build the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915 and msm? Yeah we definitely can't mix select with a user-visible option. I think we just need to fix up the remaining functions and create stubs for them if needed and then drop all the selects. Well in DRM_FBDEV_EMULATION we should still select for fbcon since otherwise tons of bug reports about where is my fbcon with kms?. I'll give this a try. Although, it would be a better idea to make the drivers not call these at all when fbdev emulation isn't asked for. With the stubs, if someone does try to use the driver with DRM_FBDEV_EMULATION not set, the worst that'll happen would be that the driver fails to probe. Which isn't so bad. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Fri, 13 Mar 2015, Daniel Vetter dan...@ffwll.ch wrote: #if defined(CONFIG_FB) #include linux/fb.h #else Side note, #if IS_ENABLED(CONFIG_FB) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote: On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Hm yeah that's somewhat annoying indeed. What about the following: 1. We move all the #include linux/fb.h from drivers into drm_fb_helper.h 2. Then we add stubs for these functions in drm_fb_helper.h, like this #if defined(CONFIG_FB) #include linux/fb.h #else /* static inline stubs for all the fb stuff used by kms drivers */ #endif Imo this makes sense since kms drivers really have a bit a special situation with fbdev. They're not full-blown fbdev drivers and can be useful fully without fbdev. What do you think? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/13/2015 02:36 PM, Daniel Vetter wrote: On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote: On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Hm yeah that's somewhat annoying indeed. What about the following: 1. We move all the #include linux/fb.h from drivers into drm_fb_helper.h 2. Then we add stubs for these functions in drm_fb_helper.h, like this #if defined(CONFIG_FB) #include linux/fb.h #else /* static inline stubs for all the fb stuff used by kms drivers */ #endif Imo this makes sense since kms drivers really have a bit a special situation with fbdev. They're not full-blown fbdev drivers and can be useful fully without fbdev. What do you think? This looks good! I'll give it a try. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: > > > On 03/10/2015 05:47 PM, Daniel Vetter wrote: > >On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: > >>On 03/10/2015 03:35 PM, Daniel Vetter wrote: > >>>On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: > On 03/10/2015 03:17 PM, Daniel Vetter wrote: > >On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: > >>diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > >>index 151a050..38f83a0 100644 > >>--- a/drivers/gpu/drm/Kconfig > >>+++ b/drivers/gpu/drm/Kconfig > >>@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER > >>help > >> FBDEV helpers for KMS drivers. > >> > >>+config DRM_FBDEV_EMULATION > >>+ bool "Enable legacy fbdev support for your modesetting driver" > >>+ depends on DRM > >>+ select DRM_KMS_HELPER > >>+ select DRM_KMS_FB_HELPER > >>+ select FB_SYS_FILLRECT > >>+ select FB_SYS_COPYAREA > >>+ select FB_SYS_IMAGEBLIT > >>+ select FB_SYS_FOPS > >>+ select FB_CFB_FILLRECT > >>+ select FB_CFB_COPYAREA > >>+ select FB_CFB_IMAGEBLIT > >>+ default y > >>+ help > >>+ Choose this option if you have a need for the legacy fbdev > >>+ support. Note that this support also provide the linux console > >>+ support on top of your modesetting driver. > > > >Maybe clarify that for linux console support you also need > >CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. > > DRM_KMS_FB_HELPER selects that for us, right? > >>> > >>>Hm right I've missed that. Reminds me that you need one more patch at the > >>>end to remove all the various select DRM_KMS_FB_HELPER from all drm > >>>drivers. Otherwise this knob here won't work by default if you e.g. select > >>>radeon. In general we can't mix explicit options with menu entries with a > >>>select. > >> > >>I was trying that out. Removing DRM_KMS_FB_HELPER and having > >>DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in > >>their respective xyz_fbdev.c files. > > > >But with the stubbed out functions that should work, right? Why doesn't > >it? > > There are still calls to functions from fb core like fb_set_suspend and > register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? > >>Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and > >>replace them with 'select DRM_FBDEV_EMULATION'? > >> > >>Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds > >>for fb related function calls/declarations in each driver, something that's > >>already done for i915 and msm drivers. > > > >The problem with the patch as-is the massive amounts of selects the FB > >helper still has. We need to get rid of them so that when you disable > >fbdev emulation you can indeed disable fbcon and the entire fbdev > >subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER > >and moving all the selects to DRM_FBDEV_EMULATION should work out? If that > >doesn't work we need to look again how to better stub things out I think. > > That's true. Also, as Jani pointed out, maybe it isn't the best idea to make > every kms driver select DRM_FBDEV_EMULATION? > > Maybe the drivers that are currently built with fbdev emulation by default > can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y, > the drivers should run as is. Later, we could take up each driver and build > the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915 > and msm? Yeah we definitely can't mix select with a user-visible option. I think we just need to fix up the remaining functions and create stubs for them if needed and then drop all the selects. Well in DRM_FBDEV_EMULATION we should still select for fbcon since otherwise tons of bug reports about "where is my fbcon with kms?". -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. The problem with the patch as-is the massive amounts of selects the FB helper still has. We need to get rid of them so that when you disable fbdev emulation you can indeed disable fbcon and the entire fbdev subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER and moving all the selects to DRM_FBDEV_EMULATION should work out? If that doesn't work we need to look again how to better stub things out I think. That's true. Also, as Jani pointed out, maybe it isn't the best idea to make every kms driver select DRM_FBDEV_EMULATION? Maybe the drivers that are currently built with fbdev emulation by default can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y, the drivers should run as is. Later, we could take up each driver and build the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915 and msm? Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. The problem with the patch as-is the massive amounts of selects the FB helper still has. We need to get rid of them so that when you disable fbdev emulation you can indeed disable fbcon and the entire fbdev subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER and moving all the selects to DRM_FBDEV_EMULATION should work out? If that doesn't work we need to look again how to better stub things out I think. That's true. Also, as Jani pointed out, maybe it isn't the best idea to make every kms driver select DRM_FBDEV_EMULATION? Maybe the drivers that are currently built with fbdev emulation by default can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y, the drivers should run as is. Later, we could take up each driver and build the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915 and msm? Yeah we definitely can't mix select with a user-visible option. I think we just need to fix up the remaining functions and create stubs for them if needed and then drop all the selects. Well in DRM_FBDEV_EMULATION we should still select for fbcon since otherwise tons of bug reports about where is my fbcon with kms?. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. The problem with the patch as-is the massive amounts of selects the FB helper still has. We need to get rid of them so that when you disable fbdev emulation you can indeed disable fbcon and the entire fbdev subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER and moving all the selects to DRM_FBDEV_EMULATION should work out? If that doesn't work we need to look again how to better stub things out I think. That's true. Also, as Jani pointed out, maybe it isn't the best idea to make every kms driver select DRM_FBDEV_EMULATION? Maybe the drivers that are currently built with fbdev emulation by default can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y, the drivers should run as is. Later, we could take up each driver and build the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915 and msm? Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 09:03 PM, Jani Nikula wrote: On Tue, 10 Mar 2015, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Slightly tangential: As a rule of thumb, you should not "select" anything that is visible in menuconfig or has dependencies [1]. This will break the build eventually, and attempts to fix it are troublesome [2]. Thanks, I'll keep this in mind! Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, 10 Mar 2015, Archit Taneja wrote: > On 03/10/2015 03:35 PM, Daniel Vetter wrote: >> On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: >>> >>> >>> On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: >>> DRM_KMS_FB_HELPER selects that for us, right? >> >> Hm right I've missed that. Reminds me that you need one more patch at the >> end to remove all the various select DRM_KMS_FB_HELPER from all drm >> drivers. Otherwise this knob here won't work by default if you e.g. select >> radeon. In general we can't mix explicit options with menu entries with a >> select. > > I was trying that out. Removing DRM_KMS_FB_HELPER and having > DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff > internally in their respective xyz_fbdev.c files. > > Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers > and replace them with 'select DRM_FBDEV_EMULATION'? Slightly tangential: As a rule of thumb, you should not "select" anything that is visible in menuconfig or has dependencies [1]. This will break the build eventually, and attempts to fix it are troublesome [2]. BR, Jani. [1] Documentation/kbuild/kconfig-language.txt [2] http://mid.gmane.org/1413580403-16225-1-git-send-email-jani.nik...@intel.com -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: > On 03/10/2015 03:35 PM, Daniel Vetter wrote: > >On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: > >>On 03/10/2015 03:17 PM, Daniel Vetter wrote: > >>>On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 151a050..38f83a0 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER > help > FBDEV helpers for KMS drivers. > > +config DRM_FBDEV_EMULATION > + bool "Enable legacy fbdev support for your modesetting driver" > + depends on DRM > + select DRM_KMS_HELPER > + select DRM_KMS_FB_HELPER > + select FB_SYS_FILLRECT > + select FB_SYS_COPYAREA > + select FB_SYS_IMAGEBLIT > + select FB_SYS_FOPS > + select FB_CFB_FILLRECT > + select FB_CFB_COPYAREA > + select FB_CFB_IMAGEBLIT > + default y > + help > + Choose this option if you have a need for the legacy fbdev > + support. Note that this support also provide the linux console > + support on top of your modesetting driver. > >>> > >>>Maybe clarify that for linux console support you also need > >>>CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. > >> > >>DRM_KMS_FB_HELPER selects that for us, right? > > > >Hm right I've missed that. Reminds me that you need one more patch at the > >end to remove all the various select DRM_KMS_FB_HELPER from all drm > >drivers. Otherwise this knob here won't work by default if you e.g. select > >radeon. In general we can't mix explicit options with menu entries with a > >select. > > I was trying that out. Removing DRM_KMS_FB_HELPER and having > DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in > their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? > Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and > replace them with 'select DRM_FBDEV_EMULATION'? > > Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds > for fb related function calls/declarations in each driver, something that's > already done for i915 and msm drivers. The problem with the patch as-is the massive amounts of selects the FB helper still has. We need to get rid of them so that when you disable fbdev emulation you can indeed disable fbcon and the entire fbdev subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER and moving all the selects to DRM_FBDEV_EMULATION should work out? If that doesn't work we need to look again how to better stub things out I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: > > > On 03/10/2015 03:17 PM, Daniel Vetter wrote: > >On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: > >>Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. > >>Most modesetting drivers enable provide fbdev emulation by default by > >>selecting > >>KMS FB helpers. A few provide a separate Kconfig option for the user to > >>enable > >>or disbale fbdev emulation. > >> > >>Enabling fbdev emulation is finally a distro-level decision. Having a top > >>level > >>Kconfig option for fbdev emulation helps by providing a uniform way to > >>enable/disable fbdev emulation for any modesetting driver. It also lets us > >>remove unnecessary driver specific Kconfig options that causes bloat. > >> > >>With a top level Kconfig in place, we can stub out the fb helper functions > >>when > >>not needed without breaking functionality. Having stub functions also > >>prevents > >>drivers to require wrapping fb helper function calls with #ifdefs. > >> > >>DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation > >>by > >>default and majority of distributions expect the fbdev interface in the > >>kernel. > >> > >>For now, this config selects both FB_SYS_* and FB_CFB_* configs as some > >>modesetting drivers use the former and other the later. This needs to be > >>taken > >>care of in a better way. > >> > >>Signed-off-by: Archit Taneja > >>--- > >> drivers/gpu/drm/Kconfig | 18 +++ > >> drivers/gpu/drm/Makefile| 4 ++ > >> include/drm/drm_fb_helper.h | 120 > >> > >> 3 files changed, 142 insertions(+) > >> > >>diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > >>index 151a050..38f83a0 100644 > >>--- a/drivers/gpu/drm/Kconfig > >>+++ b/drivers/gpu/drm/Kconfig > >>@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER > >>help > >> FBDEV helpers for KMS drivers. > >> > >>+config DRM_FBDEV_EMULATION > >>+ bool "Enable legacy fbdev support for your modesetting driver" > >>+ depends on DRM > >>+ select DRM_KMS_HELPER > >>+ select DRM_KMS_FB_HELPER > >>+ select FB_SYS_FILLRECT > >>+ select FB_SYS_COPYAREA > >>+ select FB_SYS_IMAGEBLIT > >>+ select FB_SYS_FOPS > >>+ select FB_CFB_FILLRECT > >>+ select FB_CFB_COPYAREA > >>+ select FB_CFB_IMAGEBLIT > >>+ default y > >>+ help > >>+ Choose this option if you have a need for the legacy fbdev > >>+ support. Note that this support also provide the linux console > >>+ support on top of your modesetting driver. > > > >Maybe clarify that for linux console support you also need > >CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. > > DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:16 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. + config DRM_LOAD_EDID_FIRMWARE bool "Allow to specify an EDID data set instead of probing for it" depends on DRM_KMS_HELPER diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c239b9..c1d44b2 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o + +ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y) drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o +endif This should work as drm_kms_helper-$CONFIG_DRM_FBDEV_EMULATION += drm_fb_helper.o since both -y and -m are merged together. Ah right. I'll fix that. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Archit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
> Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
> Most modesetting drivers enable provide fbdev emulation by default by
> selecting
> KMS FB helpers. A few provide a separate Kconfig option for the user to enable
> or disbale fbdev emulation.
>
> Enabling fbdev emulation is finally a distro-level decision. Having a top
> level
> Kconfig option for fbdev emulation helps by providing a uniform way to
> enable/disable fbdev emulation for any modesetting driver. It also lets us
> remove unnecessary driver specific Kconfig options that causes bloat.
>
> With a top level Kconfig in place, we can stub out the fb helper functions
> when
> not needed without breaking functionality. Having stub functions also prevents
> drivers to require wrapping fb helper function calls with #ifdefs.
>
> DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by
> default and majority of distributions expect the fbdev interface in the
> kernel.
>
> For now, this config selects both FB_SYS_* and FB_CFB_* configs as some
> modesetting drivers use the former and other the later. This needs to be taken
> care of in a better way.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/Kconfig | 18 +++
> drivers/gpu/drm/Makefile| 4 ++
> include/drm/drm_fb_helper.h | 120
>
> 3 files changed, 142 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 151a050..38f83a0 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
> help
> FBDEV helpers for KMS drivers.
>
> +config DRM_FBDEV_EMULATION
> + bool "Enable legacy fbdev support for your modesetting driver"
> + depends on DRM
> + select DRM_KMS_HELPER
> + select DRM_KMS_FB_HELPER
> + select FB_SYS_FILLRECT
> + select FB_SYS_COPYAREA
> + select FB_SYS_IMAGEBLIT
> + select FB_SYS_FOPS
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + default y
> + help
> + Choose this option if you have a need for the legacy fbdev
> + support. Note that this support also provide the linux console
> + support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
-Daniel
> +
> config DRM_LOAD_EDID_FIRMWARE
> bool "Allow to specify an EDID data set instead of probing for it"
> depends on DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2c239b9..c1d44b2 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o
> drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
> drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> +
> +ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y)
> drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
> +endif
> +
> drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
>
> obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 21b944c..dbfce1a 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -103,6 +103,7 @@ struct drm_fb_helper {
> bool delayed_hotplug;
> };
>
> +#ifdef CONFIG_DRM_FBDEV_EMULATION
> void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
> *helper,
> const struct drm_fb_helper_funcs *funcs);
> int drm_fb_helper_init(struct drm_device *dev,
> @@ -139,4 +140,123 @@ drm_pick_cmdline_mode(struct drm_fb_helper_connector
> *fb_helper_conn,
> int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
> drm_connector *connector);
> int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
> struct drm_connector *connector);
> +#else
> +static inline void drm_fb_helper_prepare(struct drm_device *dev,
> + struct drm_fb_helper *helper,
> + const struct drm_fb_helper_funcs *funcs)
> +{
> +}
> +
> +static inline int drm_fb_helper_init(struct drm_device *dev,
> +struct drm_fb_helper *helper, int crtc_count,
> +int max_conn)
> +{
> + return 0;
> +}
> +
> +static inline void drm_fb_helper_fini(struct drm_fb_helper *helper)
> +{
> +}
> +
> +static inline int drm_fb_helper_blank(int blank, struct fb_info *info)
> +{
> + return 0;
> +}
> +
> +static inline int drm_fb_helper_pan_display(struct fb_var_screeninfo *var,
> + struct fb_info *info)
> +{
> +
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
> Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
> Most modesetting drivers enable provide fbdev emulation by default by
> selecting
> KMS FB helpers. A few provide a separate Kconfig option for the user to enable
> or disbale fbdev emulation.
>
> Enabling fbdev emulation is finally a distro-level decision. Having a top
> level
> Kconfig option for fbdev emulation helps by providing a uniform way to
> enable/disable fbdev emulation for any modesetting driver. It also lets us
> remove unnecessary driver specific Kconfig options that causes bloat.
>
> With a top level Kconfig in place, we can stub out the fb helper functions
> when
> not needed without breaking functionality. Having stub functions also prevents
> drivers to require wrapping fb helper function calls with #ifdefs.
>
> DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by
> default and majority of distributions expect the fbdev interface in the
> kernel.
>
> For now, this config selects both FB_SYS_* and FB_CFB_* configs as some
> modesetting drivers use the former and other the later. This needs to be taken
> care of in a better way.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/Kconfig | 18 +++
> drivers/gpu/drm/Makefile| 4 ++
> include/drm/drm_fb_helper.h | 120
>
> 3 files changed, 142 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 151a050..38f83a0 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
> help
> FBDEV helpers for KMS drivers.
>
> +config DRM_FBDEV_EMULATION
> + bool "Enable legacy fbdev support for your modesetting driver"
> + depends on DRM
> + select DRM_KMS_HELPER
> + select DRM_KMS_FB_HELPER
> + select FB_SYS_FILLRECT
> + select FB_SYS_COPYAREA
> + select FB_SYS_IMAGEBLIT
> + select FB_SYS_FOPS
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + default y
> + help
> + Choose this option if you have a need for the legacy fbdev
> + support. Note that this support also provide the linux console
> + support on top of your modesetting driver.
> +
> config DRM_LOAD_EDID_FIRMWARE
> bool "Allow to specify an EDID data set instead of probing for it"
> depends on DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2c239b9..c1d44b2 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o
> drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
> drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> +
> +ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y)
> drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
> +endif
This should work as
drm_kms_helper-$CONFIG_DRM_FBDEV_EMULATION += drm_fb_helper.o
since both -y and -m are merged together.
-Daniel
> +
> drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
>
> obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 21b944c..dbfce1a 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -103,6 +103,7 @@ struct drm_fb_helper {
> bool delayed_hotplug;
> };
>
> +#ifdef CONFIG_DRM_FBDEV_EMULATION
> void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
> *helper,
> const struct drm_fb_helper_funcs *funcs);
> int drm_fb_helper_init(struct drm_device *dev,
> @@ -139,4 +140,123 @@ drm_pick_cmdline_mode(struct drm_fb_helper_connector
> *fb_helper_conn,
> int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
> drm_connector *connector);
> int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
> struct drm_connector *connector);
> +#else
> +static inline void drm_fb_helper_prepare(struct drm_device *dev,
> + struct drm_fb_helper *helper,
> + const struct drm_fb_helper_funcs *funcs)
> +{
> +}
> +
> +static inline int drm_fb_helper_init(struct drm_device *dev,
> +struct drm_fb_helper *helper, int crtc_count,
> +int max_conn)
> +{
> + return 0;
> +}
> +
> +static inline void drm_fb_helper_fini(struct drm_fb_helper *helper)
> +{
> +}
> +
> +static inline int drm_fb_helper_blank(int blank, struct fb_info *info)
> +{
> + return 0;
> +}
> +
> +static inline int drm_fb_helper_pan_display(struct fb_var_screeninfo *var,
> + struct fb_info *info)
> +{
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja arch...@codeaurora.org --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Archit -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
Most modesetting drivers enable provide fbdev emulation by default by
selecting
KMS FB helpers. A few provide a separate Kconfig option for the user to enable
or disbale fbdev emulation.
Enabling fbdev emulation is finally a distro-level decision. Having a top
level
Kconfig option for fbdev emulation helps by providing a uniform way to
enable/disable fbdev emulation for any modesetting driver. It also lets us
remove unnecessary driver specific Kconfig options that causes bloat.
With a top level Kconfig in place, we can stub out the fb helper functions
when
not needed without breaking functionality. Having stub functions also prevents
drivers to require wrapping fb helper function calls with #ifdefs.
DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by
default and majority of distributions expect the fbdev interface in the
kernel.
For now, this config selects both FB_SYS_* and FB_CFB_* configs as some
modesetting drivers use the former and other the later. This needs to be taken
care of in a better way.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/Kconfig | 18 +++
drivers/gpu/drm/Makefile| 4 ++
include/drm/drm_fb_helper.h | 120
3 files changed, 142 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool Enable legacy fbdev support for your modesetting driver
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
+
config DRM_LOAD_EDID_FIRMWARE
bool Allow to specify an EDID data set instead of probing for it
depends on DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c239b9..c1d44b2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+
+ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y)
drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
+endif
This should work as
drm_kms_helper-$CONFIG_DRM_FBDEV_EMULATION += drm_fb_helper.o
since both modename-y and modename-m are merged together.
-Daniel
+
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 21b944c..dbfce1a 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -103,6 +103,7 @@ struct drm_fb_helper {
bool delayed_hotplug;
};
+#ifdef CONFIG_DRM_FBDEV_EMULATION
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
*helper,
const struct drm_fb_helper_funcs *funcs);
int drm_fb_helper_init(struct drm_device *dev,
@@ -139,4 +140,123 @@ drm_pick_cmdline_mode(struct drm_fb_helper_connector
*fb_helper_conn,
int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
drm_connector *connector);
int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
struct drm_connector *connector);
+#else
+static inline void drm_fb_helper_prepare(struct drm_device *dev,
+ struct drm_fb_helper *helper,
+ const struct drm_fb_helper_funcs *funcs)
+{
+}
+
+static inline int drm_fb_helper_init(struct drm_device *dev,
+struct drm_fb_helper *helper, int crtc_count,
+int max_conn)
+{
+ return 0;
+}
+
+static inline void drm_fb_helper_fini(struct drm_fb_helper *helper)
+{
+}
+
+static inline int drm_fb_helper_blank(int blank, struct fb_info *info)
+{
+ return 0;
+}
+
+static inline int drm_fb_helper_pan_display(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ return 0;
+}
+
+static inline int drm_fb_helper_set_par(struct fb_info *info)
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja arch...@codeaurora.org --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. The problem with the patch as-is the massive amounts of selects the FB helper still has. We need to get rid of them so that when you disable fbdev emulation you can indeed disable fbcon and the entire fbdev subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER and moving all the selects to DRM_FBDEV_EMULATION should work out? If that doesn't work we need to look again how to better stub things out I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
Most modesetting drivers enable provide fbdev emulation by default by
selecting
KMS FB helpers. A few provide a separate Kconfig option for the user to enable
or disbale fbdev emulation.
Enabling fbdev emulation is finally a distro-level decision. Having a top
level
Kconfig option for fbdev emulation helps by providing a uniform way to
enable/disable fbdev emulation for any modesetting driver. It also lets us
remove unnecessary driver specific Kconfig options that causes bloat.
With a top level Kconfig in place, we can stub out the fb helper functions
when
not needed without breaking functionality. Having stub functions also prevents
drivers to require wrapping fb helper function calls with #ifdefs.
DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by
default and majority of distributions expect the fbdev interface in the
kernel.
For now, this config selects both FB_SYS_* and FB_CFB_* configs as some
modesetting drivers use the former and other the later. This needs to be taken
care of in a better way.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/Kconfig | 18 +++
drivers/gpu/drm/Makefile| 4 ++
include/drm/drm_fb_helper.h | 120
3 files changed, 142 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool Enable legacy fbdev support for your modesetting driver
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
-Daniel
+
config DRM_LOAD_EDID_FIRMWARE
bool Allow to specify an EDID data set instead of probing for it
depends on DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c239b9..c1d44b2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+
+ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y)
drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
+endif
+
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 21b944c..dbfce1a 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -103,6 +103,7 @@ struct drm_fb_helper {
bool delayed_hotplug;
};
+#ifdef CONFIG_DRM_FBDEV_EMULATION
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
*helper,
const struct drm_fb_helper_funcs *funcs);
int drm_fb_helper_init(struct drm_device *dev,
@@ -139,4 +140,123 @@ drm_pick_cmdline_mode(struct drm_fb_helper_connector
*fb_helper_conn,
int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
drm_connector *connector);
int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
struct drm_connector *connector);
+#else
+static inline void drm_fb_helper_prepare(struct drm_device *dev,
+ struct drm_fb_helper *helper,
+ const struct drm_fb_helper_funcs *funcs)
+{
+}
+
+static inline int drm_fb_helper_init(struct drm_device *dev,
+struct drm_fb_helper *helper, int crtc_count,
+int max_conn)
+{
+ return 0;
+}
+
+static inline void drm_fb_helper_fini(struct drm_fb_helper *helper)
+{
+}
+
+static inline int drm_fb_helper_blank(int blank, struct fb_info *info)
+{
+ return 0;
+}
+
+static inline int drm_fb_helper_pan_display(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ return 0;
+}
+
+static inline int drm_fb_helper_set_par(struct fb_info *info)
+{
+ return 0;
+}
+
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja arch...@codeaurora.org --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:16 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja arch...@codeaurora.org --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. + config DRM_LOAD_EDID_FIRMWARE bool Allow to specify an EDID data set instead of probing for it depends on DRM_KMS_HELPER diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c239b9..c1d44b2 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o + +ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y) drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o +endif This should work as drm_kms_helper-$CONFIG_DRM_FBDEV_EMULATION += drm_fb_helper.o since both modename-y and modename-m are merged together. Ah right. I'll fix that. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 09:03 PM, Jani Nikula wrote: On Tue, 10 Mar 2015, Archit Taneja arch...@codeaurora.org wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Slightly tangential: As a rule of thumb, you should not select anything that is visible in menuconfig or has dependencies [1]. This will break the build eventually, and attempts to fix it are troublesome [2]. Thanks, I'll keep this in mind! Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, 10 Mar 2015, Archit Taneja arch...@codeaurora.org wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Slightly tangential: As a rule of thumb, you should not select anything that is visible in menuconfig or has dependencies [1]. This will break the build eventually, and attempts to fix it are troublesome [2]. BR, Jani. [1] Documentation/kbuild/kconfig-language.txt [2] http://mid.gmane.org/1413580403-16225-1-git-send-email-jani.nik...@intel.com -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
