On Tue, Jan 22, 2013 at 7:29 PM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> 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 > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
