linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
Cc: "David Airlie" <airlied-cv59FeDIM0c@public.gmane.org>,
	"Terje Bergström"
	<tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"Stephen Warren"
	<swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] drm/tegra: Fix Kconfig dependencies
Date: Wed, 8 Jan 2014 21:04:45 +0100	[thread overview]
Message-ID: <20140108200444.GC1298@ulmo.nvidia.com> (raw)
In-Reply-To: <20140108162402.GA6928-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 5148 bytes --]

On Wed, Jan 08, 2014 at 08:24:02AM -0800, Guenter Roeck wrote:
> On Wed, Jan 08, 2014 at 03:01:39PM +0100, Thierry Reding wrote:
> > 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-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
> > > >>>>---
> > > >>>>  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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > 
> > 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.
> > 
> 
> For now I have dropped arm:allmodconfig from my list of build tests and replaced
> it with a number of additional individual target builds. As I had this or
> similar discussions ever since I started testing -stable builds, my conclusion
> is that the arm community isn't much interested in keeping arm:allmodconfig
> buildable. If that ever changes, I'll be happy to add it back in.

I can't speak for the community as a whole, but I'm certainly interested
in having more automated build coverage. Last time I attempted an allmod
build on ARM myself, which must have been at least 3 months ago, there
were quite a few issues and I didn't have the time to fix all of them. I
hadn't realize that things had improved that much recently.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

      parent reply	other threads:[~2014-01-08 20:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-05 18:22 [PATCH] drm/tegra: Fix Kconfig dependencies Guenter Roeck
     [not found] ` <1388946171-29459-1-git-send-email-linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2014-01-06 15:39   ` Thierry Reding
     [not found]     ` <20140106153945.GA6721-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2014-01-06 16:20       ` Guenter Roeck
2014-01-08 13:29         ` Thierry Reding
     [not found]           ` <20140108132924.GA1592-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2014-01-08 13:48             ` Guenter Roeck
     [not found]               ` <52CD573C.4020501-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2014-01-08 14:01                 ` Thierry Reding
     [not found]                   ` <20140108140137.GA21974-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2014-01-08 16:24                     ` Guenter Roeck
     [not found]                       ` <20140108162402.GA6928-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2014-01-08 20:04                         ` Thierry Reding [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140108200444.GC1298@ulmo.nvidia.com \
    --to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=airlied-cv59FeDIM0c@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).