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 at 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
>