thoughts on requiring multi-arch support for arm drm drivers?

thoughts on requiring multi-arch support for arm drm drivers?

[Rob Clark]

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

Re: thoughts on requiring multi-arch support for arm drm drivers?

[Daniel Vetter]

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: thoughts on requiring multi-arch support for arm drm drivers?

[Daniel Vetter]

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: thoughts on requiring multi-arch support for arm drm drivers?

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1839 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: thoughts on requiring multi-arch support for arm drm drivers?

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2313 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: thoughts on requiring multi-arch support for arm drm drivers?

[Rob Clark]

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

Re: thoughts on requiring multi-arch support for arm drm drivers?

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

Re: thoughts on requiring multi-arch support for arm drm drivers?

[Rob Clark]

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
>

Re: thoughts on requiring multi-arch support for arm drm drivers?

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

-- 
Regards,

Laurent Pinchart

Re: thoughts on requiring multi-arch support for arm drm drivers?

[Rob Clark]

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
>

Re: thoughts on requiring multi-arch support for arm drm drivers?

[Sascha Hauer]

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

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |