One thing I've run into in the past when trying to make changes in drm core, and Daniel Vetter has mentioned the same, is that it is a bit of a pain to compile test things for the arm drivers that do not support CONFIG_ARCH_MULTIPLATFORM. I went through a while back and fixed up the low hanging fruit (basically the drivers that just needed a Kconfig change). But, IIRC some of the backlight related code in shmob had some non-trivial plat dependencies. And I think when tegra came in, it introduced some non-trivial plat dependencies.
What do others think about requiring multiarch or no arch dependencies for new drivers, and cleaning up existing drivers. Even if it is at reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some of the backlight code in shmob) or doesn't even work but is just for the purpose of being able to compile test the rest of the code?
Thoughts?
BR, -R
On Sun, Jan 20, 2013 at 4:08 PM, Rob Clark robdclark@gmail.com wrote:
One thing I've run into in the past when trying to make changes in drm core, and Daniel Vetter has mentioned the same, is that it is a bit of a pain to compile test things for the arm drivers that do not support CONFIG_ARCH_MULTIPLATFORM. I went through a while back and fixed up the low hanging fruit (basically the drivers that just needed a Kconfig change). But, IIRC some of the backlight related code in shmob had some non-trivial plat dependencies. And I think when tegra came in, it introduced some non-trivial plat dependencies.
What do others think about requiring multiarch or no arch dependencies for new drivers, and cleaning up existing drivers. Even if it is at reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some of the backlight code in shmob) or doesn't even work but is just for the purpose of being able to compile test the rest of the code?
Thoughts?
Definitely in favour of this. Also, I think the arm world _really_ needs something like Wu Fenggungs 0-day kernel testing/building machines, which checks every commit pushed to around a 150 git kernel maintainer repos with randconfigs, sparse (and iirc other static checkers like cocinelle), and test-boots them on kvm. It's not just that every driver seems to need it's own special defconfig/platform to even be selectable in Kconfig, they also seem to randomly (and often) break compilation if you're on the wrong tree or don't have the exactly required golden config ...
I don't have any issues with compile-testing on different architectures. But this kind of pain makes larger subsystem reworks like the drm kms locking rework I've just done unnecessarily cumbersome.
Cheers, Daniel
On Sun, Jan 20, 2013 at 04:42:55PM +0100, Daniel Vetter wrote:
On Sun, Jan 20, 2013 at 4:08 PM, Rob Clark robdclark@gmail.com wrote:
One thing I've run into in the past when trying to make changes in drm core, and Daniel Vetter has mentioned the same, is that it is a bit of a pain to compile test things for the arm drivers that do not support CONFIG_ARCH_MULTIPLATFORM. I went through a while back and fixed up the low hanging fruit (basically the drivers that just needed a Kconfig change). But, IIRC some of the backlight related code in shmob had some non-trivial plat dependencies. And I think when tegra came in, it introduced some non-trivial plat dependencies.
What do others think about requiring multiarch or no arch dependencies for new drivers, and cleaning up existing drivers. Even if it is at reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some of the backlight code in shmob) or doesn't even work but is just for the purpose of being able to compile test the rest of the code?
Thoughts?
Definitely in favour of this. Also, I think the arm world _really_ needs something like Wu Fenggungs 0-day kernel testing/building machines, which checks every commit pushed to around a 150 git kernel maintainer repos with randconfigs, sparse (and iirc other static checkers like cocinelle), and test-boots them on kvm. It's not just that every driver seems to need it's own special defconfig/platform to even be selectable in Kconfig, they also seem to randomly (and often) break compilation if you're on the wrong tree or don't have the exactly required golden config ...
That's true. Unfortunately due to the many repositories involved there seem to be quite a few dependencies involved to get all the pieces to build properly. linux-next is usually in pretty good shape, however. I've been running an automated build over at least all ARM defconfigs in linux-next for a few days and sent out patches for build failures. But I'm not sure if I can keep that up, or at least not on a daily basis.
Obviously it doesn't help the DRM problem all that much. But I agree with Rob that the only thing that will really help is multi-platform support.
Thierry
On Sun, Jan 20, 2013 at 09:08:34AM -0600, Rob Clark wrote:
One thing I've run into in the past when trying to make changes in drm core, and Daniel Vetter has mentioned the same, is that it is a bit of a pain to compile test things for the arm drivers that do not support CONFIG_ARCH_MULTIPLATFORM. I went through a while back and fixed up the low hanging fruit (basically the drivers that just needed a Kconfig change). But, IIRC some of the backlight related code in shmob had some non-trivial plat dependencies. And I think when tegra came in, it introduced some non-trivial plat dependencies.
I've talked to Stephen about this a few days ago and his (tentative) plan is to support ARCH_MULTIPLATFORM in 3.9. I'm not sure if that's soon enough for you. I think the one remaining platform dependency is the tegra_periph_reset_{assert,deassert}() which should be gone with the common clock framework changes which should go into 3.9. Stephen has other work-in-progress patches for the rest, so I think chances are actually pretty good to get this ready for 3.9.
What do others think about requiring multiarch or no arch dependencies for new drivers, and cleaning up existing drivers. Even if it is at reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some of the backlight code in shmob) or doesn't even work but is just for the purpose of being able to compile test the rest of the code?
I imagine that on Tegra we could add dummy implementations for the reset functions, which should allow it to build it for non-Tegra. However, I don't think it's really worth the churn to do this now just to remove them again in 3.9. The general direction would seem to be to require new platforms to be multi-platform from the start, so any new drivers should not cause the same pain anyway.
Thierry
On Mon, Jan 21, 2013 at 1:17 AM, Thierry Reding thierry.reding@avionic-design.de wrote:
On Sun, Jan 20, 2013 at 09:08:34AM -0600, Rob Clark wrote:
One thing I've run into in the past when trying to make changes in drm core, and Daniel Vetter has mentioned the same, is that it is a bit of a pain to compile test things for the arm drivers that do not support CONFIG_ARCH_MULTIPLATFORM. I went through a while back and fixed up the low hanging fruit (basically the drivers that just needed a Kconfig change). But, IIRC some of the backlight related code in shmob had some non-trivial plat dependencies. And I think when tegra came in, it introduced some non-trivial plat dependencies.
I've talked to Stephen about this a few days ago and his (tentative) plan is to support ARCH_MULTIPLATFORM in 3.9. I'm not sure if that's soon enough for you. I think the one remaining platform dependency is the tegra_periph_reset_{assert,deassert}() which should be gone with the common clock framework changes which should go into 3.9. Stephen has other work-in-progress patches for the rest, so I think chances are actually pretty good to get this ready for 3.9.
What do others think about requiring multiarch or no arch dependencies for new drivers, and cleaning up existing drivers. Even if it is at reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some of the backlight code in shmob) or doesn't even work but is just for the purpose of being able to compile test the rest of the code?
I imagine that on Tegra we could add dummy implementations for the reset functions, which should allow it to build it for non-Tegra. However, I don't think it's really worth the churn to do this now just to remove them again in 3.9. The general direction would seem to be to require new platforms to be multi-platform from the start, so any new drivers should not cause the same pain anyway.
Cool! I think if we are good for multiarch for 3.9, that is probably fine. If it slip out longer than that, then we can do stub fxns as a temporary solution.
BR, -R
Thierry
Hi Rob,
On Sunday 20 January 2013 09:08:34 Rob Clark wrote:
One thing I've run into in the past when trying to make changes in drm core, and Daniel Vetter has mentioned the same, is that it is a bit of a pain to compile test things for the arm drivers that do not support CONFIG_ARCH_MULTIPLATFORM. I went through a while back and fixed up the low hanging fruit (basically the drivers that just needed a Kconfig change). But, IIRC some of the backlight related code in shmob had some non-trivial plat dependencies.
I've just compiled the shmob-drm driver without any error on x86_64. The CMA GEM helpers don't compile due to missing dma_(alloc|free)_writecombine though (but that would only be an issue if we require no arch dependency at all, not with multiarch).
And I think when tegra came in, it introduced some non-trivial plat dependencies.
What do others think about requiring multiarch or no arch dependencies for new drivers, and cleaning up existing drivers. Even if it is at reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some of the backlight code in shmob) or doesn't even work but is just for the purpose of being able to compile test the rest of the code?
Thoughts?
That sounds good to me, but would result in many drivers being exposed on x86 even though they're useless on that platform. Would it make sense to add a new CONFIG_COMPILE_TEST (or similar) Kconfig option used for compilation tests only ? The shmob driver would then depend on SUPERH || ARCH_MULTIPLATFORM || COMPILE_TEST.
I'm pretty sure I've seen a similar proposal quite recently but I can't remember where.
On Mon, Jan 21, 2013 at 9:47 AM, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Rob,
On Sunday 20 January 2013 09:08:34 Rob Clark wrote:
One thing I've run into in the past when trying to make changes in drm core, and Daniel Vetter has mentioned the same, is that it is a bit of a pain to compile test things for the arm drivers that do not support CONFIG_ARCH_MULTIPLATFORM. I went through a while back and fixed up the low hanging fruit (basically the drivers that just needed a Kconfig change). But, IIRC some of the backlight related code in shmob had some non-trivial plat dependencies.
I've just compiled the shmob-drm driver without any error on x86_64. The CMA GEM helpers don't compile due to missing dma_(alloc|free)_writecombine though (but that would only be an issue if we require no arch dependency at all, not with multiarch).
ahh, ok.. maybe I should try again. I'm pretty sure I was hitting some issues around the backlight code before, but maybe that has been fixed since then.
Anyways, if it builds for multi-platform, maybe you could send a patch for the kconfig?
And I think when tegra came in, it introduced some non-trivial plat dependencies.
What do others think about requiring multiarch or no arch dependencies for new drivers, and cleaning up existing drivers. Even if it is at reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some of the backlight code in shmob) or doesn't even work but is just for the purpose of being able to compile test the rest of the code?
Thoughts?
That sounds good to me, but would result in many drivers being exposed on x86 even though they're useless on that platform. Would it make sense to add a new CONFIG_COMPILE_TEST (or similar) Kconfig option used for compilation tests only ? The shmob driver would then depend on SUPERH || ARCH_MULTIPLATFORM || COMPILE_TEST.
fwiw, CONFIG_OF seems to filter things out on x86.. but I could live doing one arm build and one x86 build to compile test things.
CONFIG_COMPILE_TEST might be a good idea if we need stub fxn hacks to build (ie. driver is known not to be functional).. sounds like that will shortly not be an issue for tegra, and if shmobile already buids on multiplatform, then maybe we won't need this.
BR, -R
I'm pretty sure I've seen a similar proposal quite recently but I can't remember where.
-- Regards,
Laurent Pinchart
Hi Rob,
On Monday 21 January 2013 09:54:01 Rob Clark wrote:
On Mon, Jan 21, 2013 at 9:47 AM, Laurent Pinchart wrote:
On Sunday 20 January 2013 09:08:34 Rob Clark wrote:
One thing I've run into in the past when trying to make changes in drm core, and Daniel Vetter has mentioned the same, is that it is a bit of a pain to compile test things for the arm drivers that do not support CONFIG_ARCH_MULTIPLATFORM. I went through a while back and fixed up the low hanging fruit (basically the drivers that just needed a Kconfig change). But, IIRC some of the backlight related code in shmob had some non-trivial plat dependencies.
I've just compiled the shmob-drm driver without any error on x86_64. The CMA GEM helpers don't compile due to missing dma_(alloc|free)_writecombine though (but that would only be an issue if we require no arch dependency at all, not with multiarch).
ahh, ok.. maybe I should try again. I'm pretty sure I was hitting some issues around the backlight code before, but maybe that has been fixed since then.
Anyways, if it builds for multi-platform, maybe you could send a patch for the kconfig?
Do you prefer a dependency on (ARM || SUPERH) or (ARCH_MULTIPLATFORM || SUPERH) ?
And I think when tegra came in, it introduced some non-trivial plat dependencies.
What do others think about requiring multiarch or no arch dependencies for new drivers, and cleaning up existing drivers. Even if it is at reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some of the backlight code in shmob) or doesn't even work but is just for the purpose of being able to compile test the rest of the code?
Thoughts?
That sounds good to me, but would result in many drivers being exposed on x86 even though they're useless on that platform. Would it make sense to add a new CONFIG_COMPILE_TEST (or similar) Kconfig option used for compilation tests only ? The shmob driver would then depend on SUPERH || ARCH_MULTIPLATFORM || COMPILE_TEST.
fwiw, CONFIG_OF seems to filter things out on x86.. but I could live doing one arm build and one x86 build to compile test things.
CONFIG_COMPILE_TEST might be a good idea if we need stub fxn hacks to build (ie. driver is known not to be functional).. sounds like that will shortly not be an issue for tegra, and if shmobile already buids on multiplatform, then maybe we won't need this.
CONFIG_COMPILE_TEST could be used to avoid exposing drivers on platforms where they're not useful, while still enabling an easy way to compile them all. The shmob-drm driver would then depend on
(ARCH_SHMOBILE || SUPERH || COMPILE_TEST)
I'm pretty sure I've seen a similar proposal quite recently but I can't remember where.
On Tue, Jan 22, 2013 at 7:29 PM, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Rob,
On Monday 21 January 2013 09:54:01 Rob Clark wrote:
On Mon, Jan 21, 2013 at 9:47 AM, Laurent Pinchart wrote:
On Sunday 20 January 2013 09:08:34 Rob Clark wrote:
One thing I've run into in the past when trying to make changes in drm core, and Daniel Vetter has mentioned the same, is that it is a bit of a pain to compile test things for the arm drivers that do not support CONFIG_ARCH_MULTIPLATFORM. I went through a while back and fixed up the low hanging fruit (basically the drivers that just needed a Kconfig change). But, IIRC some of the backlight related code in shmob had some non-trivial plat dependencies.
I've just compiled the shmob-drm driver without any error on x86_64. The CMA GEM helpers don't compile due to missing dma_(alloc|free)_writecombine though (but that would only be an issue if we require no arch dependency at all, not with multiarch).
ahh, ok.. maybe I should try again. I'm pretty sure I was hitting some issues around the backlight code before, but maybe that has been fixed since then.
Anyways, if it builds for multi-platform, maybe you could send a patch for the kconfig?
Do you prefer a dependency on (ARM || SUPERH) or (ARCH_MULTIPLATFORM || SUPERH) ?
I did the latter in the other drivers.. but no strong preference. Paint your bikeshed whichever color :-P
And I think when tegra came in, it introduced some non-trivial plat dependencies.
What do others think about requiring multiarch or no arch dependencies for new drivers, and cleaning up existing drivers. Even if it is at reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some of the backlight code in shmob) or doesn't even work but is just for the purpose of being able to compile test the rest of the code?
Thoughts?
That sounds good to me, but would result in many drivers being exposed on x86 even though they're useless on that platform. Would it make sense to add a new CONFIG_COMPILE_TEST (or similar) Kconfig option used for compilation tests only ? The shmob driver would then depend on SUPERH || ARCH_MULTIPLATFORM || COMPILE_TEST.
fwiw, CONFIG_OF seems to filter things out on x86.. but I could live doing one arm build and one x86 build to compile test things.
CONFIG_COMPILE_TEST might be a good idea if we need stub fxn hacks to build (ie. driver is known not to be functional).. sounds like that will shortly not be an issue for tegra, and if shmobile already buids on multiplatform, then maybe we won't need this.
CONFIG_COMPILE_TEST could be used to avoid exposing drivers on platforms where they're not useful, while still enabling an easy way to compile them all. The shmob-drm driver would then depend on
(ARCH_SHMOBILE || SUPERH || COMPILE_TEST)
well, part of the end goal of ARCH_MULTIPLATFORM is to actually be able to have one kernel that can eventually boot on multiple platforms..
I guess for more embedded products, people will always have some custom tailored defconfig, so I wouldn't be concerned about having default defconfigs enable too much stuff.
BR, -R
I'm pretty sure I've seen a similar proposal quite recently but I can't remember where.
-- Regards,
Laurent Pinchart
On Wed, Jan 23, 2013 at 02:29:25AM +0100, Laurent Pinchart wrote:
Hi Rob,
On Monday 21 January 2013 09:54:01 Rob Clark wrote:
On Mon, Jan 21, 2013 at 9:47 AM, Laurent Pinchart wrote:
On Sunday 20 January 2013 09:08:34 Rob Clark wrote:
One thing I've run into in the past when trying to make changes in drm core, and Daniel Vetter has mentioned the same, is that it is a bit of a pain to compile test things for the arm drivers that do not support CONFIG_ARCH_MULTIPLATFORM. I went through a while back and fixed up the low hanging fruit (basically the drivers that just needed a Kconfig change). But, IIRC some of the backlight related code in shmob had some non-trivial plat dependencies.
I've just compiled the shmob-drm driver without any error on x86_64. The CMA GEM helpers don't compile due to missing dma_(alloc|free)_writecombine though (but that would only be an issue if we require no arch dependency at all, not with multiarch).
ahh, ok.. maybe I should try again. I'm pretty sure I was hitting some issues around the backlight code before, but maybe that has been fixed since then.
Anyways, if it builds for multi-platform, maybe you could send a patch for the kconfig?
Do you prefer a dependency on (ARM || SUPERH) or (ARCH_MULTIPLATFORM || SUPERH) ?
I suggest ARM instead of ARCH_MULTIPLATFORM since the former is the real requirement for being able to compile it.
Sascha
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Laurent Pinchart -
Rob Clark -
Sascha Hauer -
Thierry Reding