dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
Date: Fri, 4 May 2018 10:52:39 -0300	[thread overview]
Message-ID: <20180504105227.70c756c8@vento.lan> (raw)
In-Reply-To: <52576986.R85hrt8lfa@amdc3058>

Em Wed, 25 Apr 2018 12:47:34 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:

> On Monday, April 23, 2018 10:55:57 AM Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 14:47:28 +0200
> > Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:
> >   
> > > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > > > Add stubs for omapfb_dss.h, in the case it is included by
> > > > some driver when CONFIG_FB_OMAP2 is not defined, with can
> > > > happen on ARM when DRM_OMAP is not 'n'.
> > > > 
> > > > That allows building such driver(s) with COMPILE_TEST.
> > > > 
> > > > Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>    
> > > 
> > > This patch should be dropped (together with patch #6/7) as it was
> > > superseded by a better solution suggested by Laurent:
> > > 
> > > https://patchwork.kernel.org/patch/10325193/
> > > 
> > > ACK-ed by Tomi:
> > > 
> > > https://www.spinics.net/lists/dri-devel/msg171918.html
> > > 
> > > and already merged by you (commit 7378f1149884 "media: omap2:
> > > omapfb: allow building it with COMPILE_TEST")..  
> > 
> > I "ressurected" this patch due to patch 6/7.
> > 
> > The problem with the solution already acked/merged is that
> > it works *only* if you don't try to build for ARM.
> > 
> > At the moment you want to build a FB_OMAP2-dependent driver
> > on ARM with allyesc onfig, DRM_OMAP will be true, and FB_OMAP2
> > will be disabled:
> > 
> > 	menuconfig FB_OMAP2
> >         	tristate "OMAP2+ frame buffer support"
> > 	        depends on FB
> >         	depends on DRM_OMAP = n
> > 
> > One solution might be to change the depends on to:
> >         	depends on (DRM_OMAP = n || COMPILE_TEST)
> > 
> > But someone pointed me that the above check was added to avoid building
> > duplicated symbols. So, the above would cause build failures.
> > 
> > So, in order to build for ARM with DRM_OMAP selected (allyesconfig,
> > allmodconfig), we have the following alternatives:
> > 
> > 	1) apply patch 5/7;
> > 	2) make sure that FB_OMAP2 and DRM_OMAP won't declare the
> > 	   same non-static symbols;
> > 	3) redesign FB_OMAP2 to work with DRM_OMAP built.
> > 
> > I suspect that (1) is easier.  
> 
> I agree.
> 
> You can merge this patch through your tree with:
> 
> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Thanks, I'll merge it. It would still be really cool if Tony
or someone else could find a better way for omap3isp driver to
not depend on it.

Regards,
Maur

Thanks,
Mauro
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-05-04 13:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-20 17:42 [PATCH 0/7] Enable most media drivers to build on ARM Mauro Carvalho Chehab
2018-04-20 17:42 ` [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP Mauro Carvalho Chehab
2018-04-23 12:47   ` Bartlomiej Zolnierkiewicz
2018-04-23 13:55     ` Mauro Carvalho Chehab
2018-04-25 10:47       ` Bartlomiej Zolnierkiewicz
2018-05-04 13:52         ` Mauro Carvalho Chehab [this message]
2018-04-23 13:56     ` Bartlomiej Zolnierkiewicz
2018-04-23 14:11       ` Tomi Valkeinen
2018-04-23 14:25         ` Mauro Carvalho Chehab
2018-04-25 11:13         ` Bartlomiej Zolnierkiewicz
2018-04-26  6:36           ` Tomi Valkeinen
2018-04-23 14:22       ` Mauro Carvalho Chehab
2018-04-23 19:48         ` Laurent Pinchart
2018-04-23 20:09           ` Mauro Carvalho Chehab
2018-04-23 20:22             ` Laurent Pinchart
2018-04-25  6:24             ` Tomi Valkeinen
2018-04-25  9:03               ` Laurent Pinchart
2018-04-25  9:33                 ` Tomi Valkeinen
2018-04-25 10:02                   ` Laurent Pinchart
2018-04-25 10:10                     ` Tomi Valkeinen
2018-04-25 10:28                       ` Laurent Pinchart

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=20180504105227.70c756c8@vento.lan \
    --to=mchehab+samsung@kernel.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=tomi.valkeinen@ti.com \
    /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