From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mauro Carvalho Chehab Date: Mon, 23 Apr 2018 14:25:21 +0000 Subject: Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP Message-Id: <20180423112521.52b2a230@vento.lan> List-Id: References: <2542100.cElVns0SR0@amdc3058> <5379683.QunLsIS18Z@amdc3058> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tomi Valkeinen Cc: linux-fbdev@vger.kernel.org, Bartlomiej Zolnierkiewicz , dri-devel@lists.freedesktop.org, Mauro Carvalho Chehab , Laurent Pinchart , Linux Media Mailing List Em Mon, 23 Apr 2018 17:11:14 +0300 Tomi Valkeinen escreveu: > On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote: > > > Ideally we should be able to build both drivers in the same kernel > > (especially as modules). > > > > I was hoping that it could be fixed easily but then I discovered > > the root source of the problem: > > > > drivers/gpu/drm/omapdrm/dss/display.o: In function `omapdss_unregister_display': > > display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display' > > drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first defined here > > The main problem is that omapdrm and omapfb are two different drivers > for the same HW. You need to pick one, even if we would change those > functions and fix the link issue. > > At some point in time we could compile both as modules (but not > built-in), but the only use for that was development/testing and in the > end made our life more difficult. So, now you must fully disable one of > them to enable the other. And, actually, we even have boot-time code, > not included in the module itself, which gets enabled when omapdrm is > enabled. > > While it's of course good to support COMPILE_TEST, if using COMPILE_TEST > with omapfb is problematic, I'm not sure if it's worth to spend time on > that. We should be moving away from omapfb to omapdrm. Yeah, moving away from omapfb sounds the best alternative. As it seems that there's just one driver currently depending on it, I guess it shouldn't be that hard to do such change from Kernel's view, but I may be wrong, as I've no clue what this would mean to userspace. 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 11:25:21 -0300 Message-ID: <20180423112521.52b2a230@vento.lan> References: <2542100.cElVns0SR0@amdc3058> <5379683.QunLsIS18Z@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 3F2546E1F1 for ; Mon, 23 Apr 2018 14:25:27 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Tomi Valkeinen Cc: linux-fbdev@vger.kernel.org, Bartlomiej Zolnierkiewicz , dri-devel@lists.freedesktop.org, Mauro Carvalho Chehab , Laurent Pinchart , Linux Media Mailing List List-Id: dri-devel@lists.freedesktop.org RW0gTW9uLCAyMyBBcHIgMjAxOCAxNzoxMToxNCArMDMwMApUb21pIFZhbGtlaW5lbiA8dG9taS52 YWxrZWluZW5AdGkuY29tPiBlc2NyZXZldToKCj4gT24gMjMvMDQvMTggMTY6NTYsIEJhcnRsb21p ZWogWm9sbmllcmtpZXdpY3ogd3JvdGU6Cj4gCj4gPiBJZGVhbGx5IHdlIHNob3VsZCBiZSBhYmxl IHRvIGJ1aWxkIGJvdGggZHJpdmVycyBpbiB0aGUgc2FtZSBrZXJuZWwKPiA+IChlc3BlY2lhbGx5 IGFzIG1vZHVsZXMpLgo+ID4gCj4gPiBJIHdhcyBob3BpbmcgdGhhdCBpdCBjb3VsZCBiZSBmaXhl ZCBlYXNpbHkgYnV0IHRoZW4gSSBkaXNjb3ZlcmVkCj4gPiB0aGUgcm9vdCBzb3VyY2Ugb2YgdGhl IHByb2JsZW06Cj4gPiAKPiA+IGRyaXZlcnMvZ3B1L2RybS9vbWFwZHJtL2Rzcy9kaXNwbGF5Lm86 IEluIGZ1bmN0aW9uIGBvbWFwZHNzX3VucmVnaXN0ZXJfZGlzcGxheSc6Cj4gPiBkaXNwbGF5LmM6 KC50ZXh0KzB4MmMpOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBvbWFwZHNzX3VucmVnaXN0ZXJf ZGlzcGxheScKPiA+IGRyaXZlcnMvdmlkZW8vZmJkZXYvb21hcDIvb21hcGZiL2Rzcy9kaXNwbGF5 Lm86ZGlzcGxheS5jOigudGV4dCsweDE5OCk6IGZpcnN0IGRlZmluZWQgaGVyZSAgCj4gCj4gVGhl IG1haW4gcHJvYmxlbSBpcyB0aGF0IG9tYXBkcm0gYW5kIG9tYXBmYiBhcmUgdHdvIGRpZmZlcmVu dCBkcml2ZXJzCj4gZm9yIHRoZSBzYW1lIEhXLiBZb3UgbmVlZCB0byBwaWNrIG9uZSwgZXZlbiBp ZiB3ZSB3b3VsZCBjaGFuZ2UgdGhvc2UKPiBmdW5jdGlvbnMgYW5kIGZpeCB0aGUgbGluayBpc3N1 ZS4KPiAKPiBBdCBzb21lIHBvaW50IGluIHRpbWUgd2UgY291bGQgY29tcGlsZSBib3RoIGFzIG1v ZHVsZXMgKGJ1dCBub3QKPiBidWlsdC1pbiksIGJ1dCB0aGUgb25seSB1c2UgZm9yIHRoYXQgd2Fz IGRldmVsb3BtZW50L3Rlc3RpbmcgYW5kIGluIHRoZQo+IGVuZCBtYWRlIG91ciBsaWZlIG1vcmUg ZGlmZmljdWx0LiBTbywgbm93IHlvdSBtdXN0IGZ1bGx5IGRpc2FibGUgb25lIG9mCj4gdGhlbSB0 byBlbmFibGUgdGhlIG90aGVyLiBBbmQsIGFjdHVhbGx5LCB3ZSBldmVuIGhhdmUgYm9vdC10aW1l IGNvZGUsCj4gbm90IGluY2x1ZGVkIGluIHRoZSBtb2R1bGUgaXRzZWxmLCB3aGljaCBnZXRzIGVu YWJsZWQgd2hlbiBvbWFwZHJtIGlzCj4gZW5hYmxlZC4KPiAKPiBXaGlsZSBpdCdzIG9mIGNvdXJz ZSBnb29kIHRvIHN1cHBvcnQgQ09NUElMRV9URVNULCBpZiB1c2luZyBDT01QSUxFX1RFU1QKPiB3 aXRoIG9tYXBmYiBpcyBwcm9ibGVtYXRpYywgSSdtIG5vdCBzdXJlIGlmIGl0J3Mgd29ydGggdG8g c3BlbmQgdGltZSBvbgo+IHRoYXQuIFdlIHNob3VsZCBiZSBtb3ZpbmcgYXdheSBmcm9tIG9tYXBm YiB0byBvbWFwZHJtLgoKWWVhaCwgbW92aW5nIGF3YXkgZnJvbSBvbWFwZmIgc291bmRzIHRoZSBi ZXN0IGFsdGVybmF0aXZlLiBBcyBpdCBzZWVtcyB0aGF0CnRoZXJlJ3MganVzdCBvbmUgZHJpdmVy IGN1cnJlbnRseSBkZXBlbmRpbmcgb24gaXQsIEkgZ3Vlc3MgaXQgc2hvdWxkbid0IGJlCnRoYXQg aGFyZCB0byBkbyBzdWNoIGNoYW5nZSBmcm9tIEtlcm5lbCdzIHZpZXcsIGJ1dCBJIG1heSBiZSB3 cm9uZywgYXMgSSd2ZQpubyBjbHVlIHdoYXQgdGhpcyB3b3VsZCBtZWFuIHRvIHVzZXJzcGFjZS4K ClRoYW5rcywKTWF1cm8KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Au b3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRl dmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from osg.samsung.com ([64.30.133.232]:46555 "EHLO osg.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755110AbeDWOZ0 (ORCPT ); Mon, 23 Apr 2018 10:25:26 -0400 Date: Mon, 23 Apr 2018 11:25:21 -0300 From: Mauro Carvalho Chehab To: Tomi Valkeinen Cc: Bartlomiej Zolnierkiewicz , Linux Media Mailing List , Mauro Carvalho Chehab , , , Laurent Pinchart Subject: Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP Message-ID: <20180423112521.52b2a230@vento.lan> In-Reply-To: References: <2542100.cElVns0SR0@amdc3058> <5379683.QunLsIS18Z@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 17:11:14 +0300 Tomi Valkeinen escreveu: > On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote: > > > Ideally we should be able to build both drivers in the same kernel > > (especially as modules). > > > > I was hoping that it could be fixed easily but then I discovered > > the root source of the problem: > > > > drivers/gpu/drm/omapdrm/dss/display.o: In function `omapdss_unregister_display': > > display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display' > > drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first defined here > > The main problem is that omapdrm and omapfb are two different drivers > for the same HW. You need to pick one, even if we would change those > functions and fix the link issue. > > At some point in time we could compile both as modules (but not > built-in), but the only use for that was development/testing and in the > end made our life more difficult. So, now you must fully disable one of > them to enable the other. And, actually, we even have boot-time code, > not included in the module itself, which gets enabled when omapdrm is > enabled. > > While it's of course good to support COMPILE_TEST, if using COMPILE_TEST > with omapfb is problematic, I'm not sure if it's worth to spend time on > that. We should be moving away from omapfb to omapdrm. Yeah, moving away from omapfb sounds the best alternative. As it seems that there's just one driver currently depending on it, I guess it shouldn't be that hard to do such change from Kernel's view, but I may be wrong, as I've no clue what this would mean to userspace. Thanks, Mauro