On Mon, Jan 21, 2013 at 1:17 AM, Thierry Reding
<thierry.reding@xxxxxxxxxxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
