From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mauro Carvalho Chehab Date: Mon, 23 Apr 2018 13:55:57 +0000 Subject: Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP Message-Id: <20180423105557.267c5ecf@vento.lan> List-Id: References: <2542100.cElVns0SR0@amdc3058> In-Reply-To: <2542100.cElVns0SR0@amdc3058> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Bartlomiej Zolnierkiewicz Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, Mauro Carvalho Chehab , Tomi Valkeinen , Laurent Pinchart , Linux Media Mailing List Em Mon, 23 Apr 2018 14:47:28 +0200 Bartlomiej Zolnierkiewicz 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 > > 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. Thanks, Mauro From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mauro Carvalho Chehab Subject: Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP Date: Mon, 23 Apr 2018 10:55:57 -0300 Message-ID: <20180423105557.267c5ecf@vento.lan> References: <2542100.cElVns0SR0@amdc3058> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from osg.samsung.com (osg.samsung.com [64.30.133.232]) by gabe.freedesktop.org (Postfix) with ESMTP id 3967B89DA6 for ; Mon, 23 Apr 2018 13:56:06 +0000 (UTC) In-Reply-To: <2542100.cElVns0SR0@amdc3058> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Bartlomiej Zolnierkiewicz Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, Mauro Carvalho Chehab , Tomi Valkeinen , Laurent Pinchart , Linux Media Mailing List List-Id: dri-devel@lists.freedesktop.org RW0gTW9uLCAyMyBBcHIgMjAxOCAxNDo0NzoyOCArMDIwMApCYXJ0bG9taWVqIFpvbG5pZXJraWV3 aWN6IDxiLnpvbG5pZXJraWVAc2Ftc3VuZy5jb20+IGVzY3JldmV1OgoKPiBPbiBGcmlkYXksIEFw cmlsIDIwLCAyMDE4IDAxOjQyOjUxIFBNIE1hdXJvIENhcnZhbGhvIENoZWhhYiB3cm90ZToKPiA+ IEFkZCBzdHVicyBmb3Igb21hcGZiX2Rzcy5oLCBpbiB0aGUgY2FzZSBpdCBpcyBpbmNsdWRlZCBi eQo+ID4gc29tZSBkcml2ZXIgd2hlbiBDT05GSUdfRkJfT01BUDIgaXMgbm90IGRlZmluZWQsIHdp dGggY2FuCj4gPiBoYXBwZW4gb24gQVJNIHdoZW4gRFJNX09NQVAgaXMgbm90ICduJy4KPiA+IAo+ ID4gVGhhdCBhbGxvd3MgYnVpbGRpbmcgc3VjaCBkcml2ZXIocykgd2l0aCBDT01QSUxFX1RFU1Qu Cj4gPiAKPiA+IFNpZ25lZC1vZmYtYnk6IE1hdXJvIENhcnZhbGhvIENoZWhhYiA8bWNoZWhhYkBz LW9wZW5zb3VyY2UuY29tPiAgCj4gCj4gVGhpcyBwYXRjaCBzaG91bGQgYmUgZHJvcHBlZCAodG9n ZXRoZXIgd2l0aCBwYXRjaCAjNi83KSBhcyBpdCB3YXMKPiBzdXBlcnNlZGVkIGJ5IGEgYmV0dGVy IHNvbHV0aW9uIHN1Z2dlc3RlZCBieSBMYXVyZW50Ogo+IAo+IGh0dHBzOi8vcGF0Y2h3b3JrLmtl cm5lbC5vcmcvcGF0Y2gvMTAzMjUxOTMvCj4gCj4gQUNLLWVkIGJ5IFRvbWk6Cj4gCj4gaHR0cHM6 Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMvZHJpLWRldmVsL21zZzE3MTkxOC5odG1sCj4gCj4gYW5k IGFscmVhZHkgbWVyZ2VkIGJ5IHlvdSAoY29tbWl0IDczNzhmMTE0OTg4NCAibWVkaWE6IG9tYXAy Ogo+IG9tYXBmYjogYWxsb3cgYnVpbGRpbmcgaXQgd2l0aCBDT01QSUxFX1RFU1QiKS4uCgpJICJy ZXNzdXJlY3RlZCIgdGhpcyBwYXRjaCBkdWUgdG8gcGF0Y2ggNi83LgoKVGhlIHByb2JsZW0gd2l0 aCB0aGUgc29sdXRpb24gYWxyZWFkeSBhY2tlZC9tZXJnZWQgaXMgdGhhdAppdCB3b3JrcyAqb25s eSogaWYgeW91IGRvbid0IHRyeSB0byBidWlsZCBmb3IgQVJNLgoKQXQgdGhlIG1vbWVudCB5b3Ug d2FudCB0byBidWlsZCBhIEZCX09NQVAyLWRlcGVuZGVudCBkcml2ZXIKb24gQVJNIHdpdGggYWxs eWVzYyBvbmZpZywgRFJNX09NQVAgd2lsbCBiZSB0cnVlLCBhbmQgRkJfT01BUDIKd2lsbCBiZSBk aXNhYmxlZDoKCgltZW51Y29uZmlnIEZCX09NQVAyCiAgICAgICAgCXRyaXN0YXRlICJPTUFQMisg ZnJhbWUgYnVmZmVyIHN1cHBvcnQiCgkgICAgICAgIGRlcGVuZHMgb24gRkIKICAgICAgICAJZGVw ZW5kcyBvbiBEUk1fT01BUCA9IG4KCk9uZSBzb2x1dGlvbiBtaWdodCBiZSB0byBjaGFuZ2UgdGhl IGRlcGVuZHMgb24gdG86CiAgICAgICAgCWRlcGVuZHMgb24gKERSTV9PTUFQID0gbiB8fCBDT01Q SUxFX1RFU1QpCgpCdXQgc29tZW9uZSBwb2ludGVkIG1lIHRoYXQgdGhlIGFib3ZlIGNoZWNrIHdh cyBhZGRlZCB0byBhdm9pZCBidWlsZGluZwpkdXBsaWNhdGVkIHN5bWJvbHMuIFNvLCB0aGUgYWJv dmUgd291bGQgY2F1c2UgYnVpbGQgZmFpbHVyZXMuCgpTbywgaW4gb3JkZXIgdG8gYnVpbGQgZm9y IEFSTSB3aXRoIERSTV9PTUFQIHNlbGVjdGVkIChhbGx5ZXNjb25maWcsCmFsbG1vZGNvbmZpZyks IHdlIGhhdmUgdGhlIGZvbGxvd2luZyBhbHRlcm5hdGl2ZXM6CgoJMSkgYXBwbHkgcGF0Y2ggNS83 OwoJMikgbWFrZSBzdXJlIHRoYXQgRkJfT01BUDIgYW5kIERSTV9PTUFQIHdvbid0IGRlY2xhcmUg dGhlCgkgICBzYW1lIG5vbi1zdGF0aWMgc3ltYm9sczsKCTMpIHJlZGVzaWduIEZCX09NQVAyIHRv IHdvcmsgd2l0aCBEUk1fT01BUCBidWlsdC4KCkkgc3VzcGVjdCB0aGF0ICgxKSBpcyBlYXNpZXIu CgpUaGFua3MsCk1hdXJvCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9w Lm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1k ZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from osg.samsung.com ([64.30.133.232]:40782 "EHLO osg.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755215AbeDWN4G (ORCPT ); Mon, 23 Apr 2018 09:56:06 -0400 Date: Mon, 23 Apr 2018 10:55:57 -0300 From: Mauro Carvalho Chehab To: Bartlomiej Zolnierkiewicz Cc: Linux Media Mailing List , Mauro Carvalho Chehab , dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, Laurent Pinchart , Tomi Valkeinen Subject: Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP Message-ID: <20180423105557.267c5ecf@vento.lan> In-Reply-To: <2542100.cElVns0SR0@amdc3058> References: <2542100.cElVns0SR0@amdc3058> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: Em Mon, 23 Apr 2018 14:47:28 +0200 Bartlomiej Zolnierkiewicz 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 > > 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. Thanks, Mauro