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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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