[PATCH] drm/tegra: Fix Kconfig dependencies

[Thierry Reding]

On Wed, Jan 08, 2014 at 05:48:44AM -0800, Guenter Roeck wrote:
> On 01/08/2014 05:29 AM, Thierry Reding wrote:
> >On Mon, Jan 06, 2014 at 08:20:55AM -0800, Guenter Roeck wrote:
> >>On Mon, Jan 06, 2014 at 04:39:47PM +0100, Thierry Reding wrote:
> >>>On Sun, Jan 05, 2014 at 10:22:51AM -0800, Guenter Roeck wrote:
> >>>>arm:allmodconfig fails to build with several undefined drm and host1x symbols.
> >>>>
> >>>>drivers/gpu/drm/tegra/bus.c:52: undefined reference to `drm_dev_alloc'
> >>>>drivers/gpu/drm/tegra/bus.c:56: undefined reference to `drm_dev_register'
> >>>>drivers/gpu/drm/tegra/bus.c:67: undefined reference to `drm_dev_free'
> >>>>drivers/gpu/drm/tegra/bus.c:75: undefined reference to `drm_put_dev'
> >>>>drivers/gpu/drm/tegra/drm.c:445: undefined reference to `host1x_syncpt_get_base'
> >>>>drivers/gpu/drm/tegra/drm.c:449: undefined reference to `host1x_syncpt_base_id'
> >>>>
> >>>>and so on.
> >>>>
> >>>>This is caused by DRM=m but DRM_TEGRA=y. DRM_TEGRA is bool while DRM is
> >>>>tristate. DRM_TEGRA can not be set to tristate because it depends on unexported
> >>>>host1x symbols (and possibly others). Fix by updating DRM_TEGRA dependency.
> >>>>
> >>>>Also, the DRM_TEGRA help text states that it can be built as module.
> >>>>Remove that text since it is not (or no longer) correct.
> >>>>
> >>>>Signed-off-by: Guenter Roeck <linux at roeck-us.net>
> >>>>---
> >>>>  drivers/gpu/drm/tegra/Kconfig |    5 +----
> >>>>  1 file changed, 1 insertion(+), 4 deletions(-)
> >>>
> >>>Hi Guenter,
> >>>
> >>>I think this should be fixed in latest next, where it is now possible to
> >>>build the Tegra DRM driver as a module. All needed host1x symbols are
> >>>exported as well.
> >>>
> >>>One thing that strikes me as odd, though, is that I've always thought
> >>>Kconfig would warn if a symbol selected as =y depended on a symbol
> >>>selected as =m, precisely because of what you describe above. menuconfig
> >>>complains about it pretty loudly as well.
> >>>
> >>>Oh, but I see that if I change DRM_TEGRA back to be bool, then Kconfig
> >>>doesn't complain anymore, even if DRM_TEGRA=y and DRM=m. Should that
> >>>perhaps be considered a bug?
> >>>
> >>No idea. All I know is that it causes a build failure ;-).
> >>
> >>Anyway, are there plans to push the patches changing DRM_TEGRA to tristate
> >>into 3.13 ? This is one of the reasons for arm:allmodconfig to fail. If there
> >>are no plans to push the patches into 3.13, I think it would make sense
> >>to send my patch to Linus and apply the tristate changes on top of it.
> >
> >The patches to change DRM_TEGRA to tristate are part of what is queued
> >for 3.14. While I agree that having allmodconfig working is a worthwhile
> >goal in itself for build testing, I'm not sure it warrants a patch this
> >late in the release cycle that will cause conflicts during the merge
> >window.
> >
> >It also seems like there are other issues that prevent allmodconfig to
> >build successfully on ARM not all of them being as easy to fix as this
> >one.
> >
> 
> All other problems are being addressed.

Okay, if this is indeed the only remaining issue then I think it makes
sense indeed to go through the trouble of fixing it right away rather
than waiting for 3.14.

> If arm:allmodconfig is not pursued as buildable, trying to build it is worthless,
> and I'll drop it from my list of test builds for -stable. Thanks for letting me know.

Right, I hadn't considered -stable builds and this is an issue that's
new in 3.13, isn't it? In that case, and since this is the only
remaining issue, the above patch:

Acked-by: Thierry Reding <treding at nvidia.com>

Dave, since this is a single patch for 3.13 it might be easier for you
to pick it up directly rather than have me send out a pull request.
Either way is fine with me, though.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140108/9c34bd54/attachment.pgp>