From mboxrd@z Thu Jan 1 00:00:00 1970 From: Inki Dae Subject: Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem Date: Tue, 16 Aug 2016 13:40:05 +0900 Message-ID: <57B29925.4020600@samsung.com> References: <1470850251-9150-1-git-send-email-shuahkh@osg.samsung.com> <57ABB1ED.1080301@samsung.com> <57ABB31E.1070802@osg.samsung.com> <57AE0736.6020705@osg.samsung.com> <57AE0CCB.1010708@osg.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-reply-to: <57AE0CCB.1010708@osg.samsung.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Shuah Khan , jy0922.shim@samsung.com, sw0312.kim@samsung.com, kyungmin.park@samsung.com, airlied@linux.ie, kgene@kernel.org, k.kozlowski@samsung.com Cc: linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org List-Id: linux-samsung-soc@vger.kernel.org SGkgU2h1YWgsCgoyMDE264WEIDA47JuUIDEz7J28IDAyOjUy7JeQIFNodWFoIEtoYW4g7J20KOqw gCkg7JO0IOq4gDoKPiBPbiAwOC8xMi8yMDE2IDExOjI4IEFNLCBTaHVhaCBLaGFuIHdyb3RlOgo+ PiBPbiAwOC8xMC8yMDE2IDA1OjA1IFBNLCBTaHVhaCBLaGFuIHdyb3RlOgo+Pj4gT24gMDgvMTAv MjAxNiAwNDo1OSBQTSwgSW5raSBEYWUgd3JvdGU6Cj4+Pj4gSGkgU2h1YWgsCj4+Pj4KPj4+PiAy MDE264WEIDA47JuUIDEx7J28IDAyOjMw7JeQIFNodWFoIEtoYW4g7J20KOqwgCkg7JO0IOq4gDoK Pj4+Pj4gRml4IGV4eW5vc19kcm1fZ2VtX2NyZWF0ZV9pb2N0bCgpIGF0dGVtcHRzIHRvIGFsbG9j YXRlIG5vbi1jb250aWd1b3VzIEdFTQo+Pj4+PiBtZW1vcnkgd2l0aG91dCBJT01NVS4gSW4gdGhp cyBjYXNlLCB0aGVyZSBpcyBubyBwb2ludCBpbiBhdHRlbXB0aW5nIHRvCj4+Pj4KPj4+PiBEUk0g Z2VtIGNhbiBiZSB1c2VkIGZvciBOb24tRFJNIGRyaXZlcnMgc3VjaCBhcyBHUFUsIFY0TDIgYmFz ZWQgTXVsdGltZWRpYSBkZXZpY2UgYW5kIG90aGVyIERNQSBkZXZpY2VzLgo+Pj4+IEV2ZW4gdGhv dWdoIElPTU1VIHN1cHBvcnQgaXMgZGlzYWJsZWQsIG90aGVyIGZyYW1ld29yayBiYXNlZCBETUEg ZHJpdmVycyBjYW4gdXNlIElPTU1VIC0gaS5lLiwgR1BVIGRyaXZlciAtCj4+Pj4gYW5kIHRoZXkg Y2FuIHVzZSBub24tY29udGlndW91cyBHRU0gYnVmZmVyIHRocm91Z2ggVU1NLiAoRE1BQlVGKSAK Pj4+Pgo+Pj4+IFNvIEdFTSBhbGxvY2F0aW9uIHR5cGUgaXMgbm90IGRlcGVuZGVudCBvbiBJT01N VS4KPj4+Cj4+PiBIaSBJbmtpLAo+Pj4KPj4+IEkgYW0gc2VlaW5nIHRoZSBmb2xsb3dpbmcgZmFp bHVyZSB3aXRob3V0IElPTU1VIGFuZCBsaWdodCBkbSBmYWlscwo+Pj4gdG8gc3RhcnQ6Cj4+Pgo+ Pj4gW2RybTpleHlub3NfZHJtX2ZyYW1lYnVmZmVyX2luaXRdICpFUlJPUiogTm9uLWNvbnRpbmd1 b3VzIEdFTSBtZW1vcnkgaXMgbm90IHN1cHBvcnRlZC4KPj4+Cj4+PiBUaGUgY2hhbmdlIEkgbWFk ZSBmaXhlZCB0aGF0IHByb2JsZW0gYW5kIGxpZ2h0IGRtIHN0YXJ0cyB3aXRob3V0IElPTU1VLgo+ Pj4gSXMgdGhlcmUgYSBiZXR0ZXIgd2F5IHRvIGZpeCB0aGlzIHByb2JsZW0/IEN1cnJlbnRseSB3 aXRob3V0IElPTU1VLAo+Pj4gbGlnaHQgZG0gZG9lc24ndCBzdGFydC4KPj4+Cj4+PiBUaGlzIGlz IG9uIGxpbnV4X25leHQKPj4KPj4gSGkgSW5raSwKPj4KPj4gSSBhbSBsb29raW5nIGludG8gdGhp cyBmdXJ0aGVyIGFuZCBJIGFtIGZpbmRpbmcgaW5jb25zaXN0ZW50Cj4+IGNvbW1pdHMgd2l0aCBy ZWdhcmRzIHRvIEdFTSBjb250aWd1b3VzIGFuZCBub24tY29udGlndW91cwo+PiBidWZmZXJzLgo+ Pgo+PiBPa2F5IHdoYXQgeW91IHNhaWQgaXMgdGhhdDoKPj4KPj4gZXh5bW9kLWRybSBzaG91bGQg c3VwcG9ydCBub24tY29udGluZ3VvdXMgYW5kIGNvbnRpZ3VvdXMgR0VNIG1lbW9yeQo+PiB0eXBl IHdpdGggb3Igd2l0aG91dCBJT01NVQoKUmlnaHQuCgo+Pgo+PiBIb3dldmVyLCB0aGUgY29kZSBj dXJyZW50bHkgaXNuJ3QgZG9pbmcgdGhhdC4gVGhlIGZvbGxvd2luZwo+PiBjb21taXQgYWxsb2Nh dGVzIG5vbi1jb250aWd1b3VzIGJ1ZmZlcnMgd2hlbiBJT01NVSBpcyBlbmFibGVkCj4+IHRvIGhh bmRsZSBjb250aWd1b3VzIGFsbG9jYXRpb24gZmFpbHVyZXMuCj4+Cj4+IFRoZXJlIGFyZSBvdGhl ciBjb21taXRzIHRoYXQgcmVtb3ZlZCBjaGVja3MgZm9yIG5vbi1jb250aWcgdHlwZS4KPj4gTGV0 J3MgbG9vayBhdCB0aGUgZm9sbG93aW5nIGNhc2VzIHRvIHNlZSB3aGF0IHNob3VsZCBiZSB0aGUg ZHJpdmVyCj4+IGJlaGF2aW9yIGluIHRoZXNlIGNhc2VzOgo+Pgo+PiBJT01NVSBpcyBkaXNhYmxl ZDoKPj4KPj4gZXh5bm9zX2RybV9nZW1fY3JlYXRlX2lvY3RsKCkgZ2V0cyBjYWxsZWQgd2l0aCBO T05DT05USUcKPj4gLSBkcml2ZXIgc2hvdWxkIHRyeSB0byBhbGxvY2F0ZSBub24tY29udGlnCj4+ IC0gaWYgaXQgY2FuJ3QgYWxsb2NhdGUgbm9uLWNvbnRpZywgYWxsb2NhdGUgY29udGlnCj4+ICAg KCB0aGlzIHdpbGwgYWxsb3cgYXZvaWQgZmFpbHVyZSBsaWtlIHRoZSBvbmUgSSBhbSBzZWVpbmcp Cj4+Cj4+IGV4eW5vc19kcm1fZ2VtX2NyZWF0ZV9pb2N0bCgpIGdldHMgY2FsbGVkIHdpdGggQ09O VElHCj4+IC0gZHJpdmVyIHNob3VsZCB0cnkgdG8gYWxsb2NhdGUgY29udGlnCj4+IC0gaWYgaXQg Y2FuJ3QgYWxsb2NhdGUgY29udGlnLCBhbGxvY2F0ZSBub24tY29udGlnCj4+Cj4+IFdoYXQgaXMg Y29uZnVzaW5nIGlzIHRoZXJlIGFyZSBzZXZlcmFsIGNvZGUgcGF0aHMgaW4gdGhlCj4+IEdFTiBh bGxvY2F0aW9uIGFuZCBjaGVja2luZyBtZW1vcnkgdHlwZXMgYXJlIGVuZm9yY2luZwo+PiBub24t Y29udGlnIHdpdGggSU9NTVUuIENoZWNrIHRoaXMgcm91dGluZToKPj4KPj4gZXh5bm9zX2RybV9m cmFtZWJ1ZmZlcl9pbml0KCkgd2lsbCByZWplY3Qgbm9uLWNvbnRpZwo+PiBtZW1vcnkgdHlwZSB3 aGVuIGNoZWNrX2ZiX2dlbV9tZW1vcnlfdHlwZSgpIHJlamVjdHMKPj4gbm9uLWNvbnRpZyBHRU0g bWVtb3J5IHR5cGUgd2l0aG91dCBJT01NVS4KCk9ubHkgaW4gY2FzZSB0aGF0IHRoZSBnZW0gYnVm ZmVyIGlzIHVzZWQgZm9yIGZyYW1lYnVmZmVyLCBnZW0gbWVtb3J5IHR5cGUgc2hvdWxkIGJlIGNo ZWNrZWQgYmVjYXVzZSB0aGlzIG1lYW5zIHRoZSBETUEgb2YgRGlzcGxheSBjb250cm9sbGVyIGFj Y2Vzc2VzIHRoZSBnZW0gYnVmZmVyIHNvIHdpdGhvdXQgSU9NTVUgdGhlIERNQSBkZXZpY2UgY2Fu bm90IGFjY2VzcyBub24tY29udGlndW91cyBtZW1vcnkgcmVnaW9uLgpUaGF0IGlzIHdoeSBleHlu b3NfZHJtX2ZyYW1lYnVmZmVyX2luaXQgY2hlY2tzIGdlbSBtZW1vcnkgdHlwZSBmb3IgZmIgbm90 IHdoZW4gZ2VtIGlzIGNyZWF0ZWQuCgo+IAo+IAo+IG9rYXkgdGhlIHZlcnkgZmlyc3QgY29tbWl0 IHRoYXQgYWRkZWQgSU9NTVUgc3VwcG9ydAo+IGludHJvZHVjZWQgdGhlIGNvZGUgdGhhdCByZWpl Y3RzIG5vbi1jb250aWcgZ2VtIG1lbW9yeQo+IHR5cGUgd2l0aG91dCBJT01NVS4KPiAKPiBjb21t aXQgMDUxOWY5YTEyZDAxMTNjYWFiNzg5ODBjNDhhNzkwMmQyYmQ0MGMyYwo+IEF1dGhvcjogSW5r aSBEYWUgPGlua2kuZGFlQHNhbXN1bmcuY29tPgo+IERhdGU6ICAgU2F0IE9jdCAyMCAwNzo1Mzo0 MiAyMDEyIC0wNzAwCj4gCj4gICAgIGRybS9leHlub3M6IGFkZCBpb21tdSBzdXBwb3J0IGZvciBl eHlub3MgZHJtIGZyYW1ld29yawo+IAo+IEFueXdheSwgaWYgaXQgaXMgdGggcmlnaHQgY2hhbmdl IHRvIGZpeCBjaGVja19mYl9nZW1fbWVtb3J5X3R5cGUoKQo+IHRvIG5vdCByZWplY3QgTk9OQ09O VElHX0JVRkZFUiwgdGhlbiBJIGNhbiBtYWtlIHRoYXQgY2hhbmdlCgpObywgYXMgSSBtZW50aW9u ZWQgYWJvdmUsIHRoZSBnZW0gYnVmZmVyIGZvciBmYiBpcyBkZXBlbmRlbnQgb24gSU9NTVUgYmVj YXVzZSB0aGUgZ2VtIGJ1ZmZlciBmb3IgZmIgaXMgdXNlZCBieSBETUEgZGV2aWNlIC0gRklNRCwg REVDT04gb3IgTWl4ZXIuCllvdSB3b3VsZCBuZWVkIHRvIHVuZGVyc3RhbmQgdGhhdCBnZW0gYnVm ZmVyIGNhbiBiZSB1c2VkIGZvciBvdGhlciBwdXJwb3NlcyAtIDJELzNEIG9yIHBvc3QgcHJvY2Vz cyBkZXZpY2VzIHdoaWNoIGRvbid0IHVzZSBmcmFtZWJ1ZmZlciAtIG5vdCBkaXNwbGF5IGNvbnRy b2xsZXIgd2hpY2ggdXNlcyBmcmFtZWJ1ZmZlciB0byBzY2Fub3V0CgpUaGFua3MsCklua2kgRGFl Cgo+IGluc3RlYWQgb2YgdGhpcyBwYXRjaCBJIHNlbnQuCj4gCj4+Cj4+IFNvIHRoZXJlIGlzIGlu Y29uc2lzdGVuY3kgaW4gdGhlIG5vbi1jb250aWcgdnMuIGNvbnRpZwo+PiBHRU0gc3VwcG9ydCBp biBleHlub3MtZHJtLiBJIHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgY2xlYW5lZAo+PiB1cCB0byBn ZXQgdGhlIGRlc2lyZWQgYmVoYXZpb3IuCj4+Cj4+IFRoZSBmb2xsb3dpbmcgY29tbWl0IGFsbG9j YXRlcyBub24tY29udGlndW91cyBidWZmZXJzIHdoZW4gSU9NTVUgaXMKPj4gZW5hYmxlZCB0byBo YW5kbGUgY29udGlndW91cyBhbGxvY2F0aW9uIGZhaWx1cmVzLgo+Pgo+PiBUaGVyZSBhcmUgb3Ro ZXIgY29tbWl0cyB0aGF0IHJlbW92ZWQgY2hlY2tzIGZvciBub24tY29udGlnIHR5cGUuCj4+IExl dCdzIGxvb2sgYXQgdGhlIGZvbGxvd2luZyBjYXNlcyB0byBzZWUgd2hhdCBzaG91bGQgYmUgdGhl IGRyaXZlcgo+PiBiZWhhdmlvciBpbiB0aGVzZSBjYXNlczoKPj4KPj4gY29tbWl0IDEyMmJlZWE4 NGJiOTAyMzZiMWFlNTQ1ZjA4MjY3YWY1ODU5MWMyMWIKPj4gQXV0aG9yOiBSYWh1bCBTaGFybWEg PFJhaHVsLlNoYXJtYUBzYW1zdW5nLmNvbT4KPj4gRGF0ZTogICBXZWQgTWF5IDcgMTc6MjE6Mjkg MjAxNCArMDUzMAo+Pgo+PiAgICAgZHJtL2V4eW5vczogYWxsb2NhdGUgbm9uLWNvbnRpZ291cyBi dWZmZXJzIHdoZW4gaW9tbXUgaXMgZW5hYmxlZAo+PiAgICAgCj4+ICAgICBBbGxvdyB0byBhbGxv Y2F0ZSBub24tY29udGlnb3VzIGJ1ZmZlcnMgd2hlbiBpb21tdSBpcyBlbmFibGVkLgo+PiAgICAg Q3VycmVudGx5LCBpdCB0cmllcyB0byBhbGxvY2F0ZXMgY29udGlnb3VzIGJ1ZmZlciB3aGljaCBj b25zaXN0ZW50bHkKPj4gICAgIGZhaWwgZm9yIGxhcmdlIGJ1ZmZlcnMgYW5kIHRoZW4gZmFsbCBi YWNrIHRvIG5vbiBjb250aWdvdXMuIEFwYXJ0Cj4+ICAgICBmcm9tIGJlaW5nIHNsb3csIHRoaXMg aW1wbGVtZW50YXRpb24gaXMgYWxzbyB2ZXJ5IG5vaXN5IGFuZCBmaWxscwo+PiAgICAgdGhlIHNj cmVlbiB3aXRoIGFsbG9jIGZhaWwgbG9ncy4KPj4gICAgIAo+PiAgICAgU2lnbmVkLW9mZi1ieTog UmFodWwgU2hhcm1hIDxSYWh1bC5TaGFybWFAc2Ftc3VuZy5jb20+Cj4+ICAgICBSZXZpZXdlZC1i eTogU2FjaGluIEthbWF0IDxzYWNoaW4ua2FtYXRAbGluYXJvLm9yZz4KPj4gICAgIFNpZ25lZC1v ZmYtYnk6IElua2kgRGFlIDxpbmtpLmRhZUBzYW1zdW5nLmNvbT4KPj4KPj4KPj4gY29tbWl0IGVh NmQ2NmMzYTc5NzM3NmQyMWIyM2RjODI2MTczM2NlMzU5NzAwMTQKPj4gQXV0aG9yOiBJbmtpIERh ZSA8aW5raS5kYWVAc2Ftc3VuZy5jb20+Cj4+IERhdGU6ICAgRnJpIE5vdiAyIDE2OjEwOjM5IDIw MTIgKzA5MDAKPj4KPj4gICAgIGRybS9leHlub3M6IHJlbW92ZSBFWFlOT1NfQk9fTk9OQ09OVElH IHR5cGUgY2hlY2tpbmcuCj4+ICAgICAKPj4gICAgIFdpdGggaW9tbXUgc3VwcG9ydCwgbm9uLWNv bnRpbnVvdXMgYnVmZmVyIGFsc28gaXMgc3VwcG9ydGVkIHNvCj4+ICAgICB0aGlzIHBhdGNoIHJl bW92ZXMgdGhlc2UgY2hlY2tpbmcgZnJvbSBleHlub3NfZHJtX2dlbV9nZXQvcHV0X2RtYV9hZGRy Cj4+ICAgICBmdW5jaXRvbi4KPj4gICAgIAo+PiAgICAgVGhpcyBwYXRjaCBpcyBiYXNlZCBvbiB0 aGUgYmVsb3cgcGF0Y2ggc2V0LCAiZHJtL2V4eW5vczogYWRkCj4+ICAgICBpb21tdSBzdXBwb3J0 IGZvciAtbmV4dCIuCj4+ICAgICAgICAgaHR0cDovL3d3dy5zcGluaWNzLm5ldC9saXN0cy9kcmkt ZGV2ZWwvbXNnMjkwNDEuaHRtbAo+PiAgICAgCj4+ICAgICBTaWduZWQtb2ZmLWJ5OiBJbmtpIERh ZSA8aW5raS5kYWVAc2Ftc3VuZy5jb20+Cj4+ICAgICBTaWduZWQtb2ZmLWJ5OiBLeXVuZ21pbiBQ YXJrIDxreXVuZ21pbi5wYXJrQHNhbXN1bmcuY29tPgo+Pgo+PiBjb21taXQgMmIzNTg5MmU5ZGE2 NzJkZjQwY2U4OTBiZmZjNGY5ZjYxMTljNTdlMAo+PiBBdXRob3I6IElua2kgRGFlIDxpbmtpLmRh ZUBzYW1zdW5nLmNvbT4KPj4gRGF0ZTogICBGcmkgTWFyIDE2IDE4OjQ3OjA1IDIwMTIgKzA5MDAK Pj4KPj4gICAgIGRybS9leHlub3M6IHVwZGF0ZSBnZW0gYW5kIGJ1ZmZlciBmcmFtZXdvcmsuCj4+ ICAgICAKPj4gICAgIHdpdGggdGhpcyBwYXRjaCwgd2UgY2FuIGFsbG9jYXRlIHBoeXNpY2FsbHkg Y29udGludW91cyBvciBub24tY29udGludW91cwo+PiAgICAgbWVtb3J5IGFuZCBhbHNvIGl0IGNy ZWF0ZXMgc2NhdHRlcmxpc3QgZm9yIGlvbW11IHN1cHBvcnQgc28gYWxsb2NhdGVkCj4+ICAgICBt ZW1vcnkgcmVnaW9uIGNhbiBiZSBtYXBwZWQgdG8gaW9tbXUgcGFnZSB0YWJsZSB1c2luZyBzY2F0 dGVybGlzdC4KPj4gICAgIAo+PiAgICAgU2lnbmVkLW9mZi1ieTogSW5raSBEYWUgPGlua2kuZGFl QHNhbXN1bmcuY29tPgo+PiAgICAgU2lnbmVkLW9mZi1ieTogS3l1bmdtaW4gUGFyayA8a3l1bmdt aW4ucGFya0BzYW1zdW5nLmNvbT4KPj4gICAgIFNpZ25lZC1vZmYtYnk6IERhdmUgQWlybGllIDxh aXJsaWVkQHJlZGhhdC5jb20+Cj4+Cj4+IC0tIFNodWFoCj4+Cj4gCj4gLS0KPiBUbyB1bnN1YnNj cmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgtc2Ft c3VuZy1zb2MiIGluCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtl cm5lbC5vcmcKPiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5rZXJuZWwub3Jn L21ham9yZG9tby1pbmZvLmh0bWwKPiAKPiAKPiAKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlz dHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4v bGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: inki.dae@samsung.com (Inki Dae) Date: Tue, 16 Aug 2016 13:40:05 +0900 Subject: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem In-Reply-To: <57AE0CCB.1010708@osg.samsung.com> References: <1470850251-9150-1-git-send-email-shuahkh@osg.samsung.com> <57ABB1ED.1080301@samsung.com> <57ABB31E.1070802@osg.samsung.com> <57AE0736.6020705@osg.samsung.com> <57AE0CCB.1010708@osg.samsung.com> Message-ID: <57B29925.4020600@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Shuah, 2016? 08? 13? 02:52? Shuah Khan ?(?) ? ?: > On 08/12/2016 11:28 AM, Shuah Khan wrote: >> On 08/10/2016 05:05 PM, Shuah Khan wrote: >>> On 08/10/2016 04:59 PM, Inki Dae wrote: >>>> Hi Shuah, >>>> >>>> 2016? 08? 11? 02:30? Shuah Khan ?(?) ? ?: >>>>> Fix exynos_drm_gem_create_ioctl() attempts to allocate non-contiguous GEM >>>>> memory without IOMMU. In this case, there is no point in attempting to >>>> >>>> DRM gem can be used for Non-DRM drivers such as GPU, V4L2 based Multimedia device and other DMA devices. >>>> Even though IOMMU support is disabled, other framework based DMA drivers can use IOMMU - i.e., GPU driver - >>>> and they can use non-contiguous GEM buffer through UMM. (DMABUF) >>>> >>>> So GEM allocation type is not dependent on IOMMU. >>> >>> Hi Inki, >>> >>> I am seeing the following failure without IOMMU and light dm fails >>> to start: >>> >>> [drm:exynos_drm_framebuffer_init] *ERROR* Non-continguous GEM memory is not supported. >>> >>> The change I made fixed that problem and light dm starts without IOMMU. >>> Is there a better way to fix this problem? Currently without IOMMU, >>> light dm doesn't start. >>> >>> This is on linux_next >> >> Hi Inki, >> >> I am looking into this further and I am finding inconsistent >> commits with regards to GEM contiguous and non-contiguous >> buffers. >> >> Okay what you said is that: >> >> exymod-drm should support non-continguous and contiguous GEM memory >> type with or without IOMMU Right. >> >> However, the code currently isn't doing that. The following >> commit allocates non-contiguous buffers when IOMMU is enabled >> to handle contiguous allocation failures. >> >> There are other commits that removed checks for non-contig type. >> Let's look at the following cases to see what should be the driver >> behavior in these cases: >> >> IOMMU is disabled: >> >> exynos_drm_gem_create_ioctl() gets called with NONCONTIG >> - driver should try to allocate non-contig >> - if it can't allocate non-contig, allocate contig >> ( this will allow avoid failure like the one I am seeing) >> >> exynos_drm_gem_create_ioctl() gets called with CONTIG >> - driver should try to allocate contig >> - if it can't allocate contig, allocate non-contig >> >> What is confusing is there are several code paths in the >> GEN allocation and checking memory types are enforcing >> non-contig with IOMMU. Check this routine: >> >> exynos_drm_framebuffer_init() will reject non-contig >> memory type when check_fb_gem_memory_type() rejects >> non-contig GEM memory type without IOMMU. Only in case that the gem buffer is used for framebuffer, gem memory type should be checked because this means the DMA of Display controller accesses the gem buffer so without IOMMU the DMA device cannot access non-contiguous memory region. That is why exynos_drm_framebuffer_init checks gem memory type for fb not when gem is created. > > > okay the very first commit that added IOMMU support > introduced the code that rejects non-contig gem memory > type without IOMMU. > > commit 0519f9a12d0113caab78980c48a7902d2bd40c2c > Author: Inki Dae > Date: Sat Oct 20 07:53:42 2012 -0700 > > drm/exynos: add iommu support for exynos drm framework > > Anyway, if it is th right change to fix check_fb_gem_memory_type() > to not reject NONCONTIG_BUFFER, then I can make that change No, as I mentioned above, the gem buffer for fb is dependent on IOMMU because the gem buffer for fb is used by DMA device - FIMD, DECON or Mixer. You would need to understand that gem buffer can be used for other purposes - 2D/3D or post process devices which don't use framebuffer - not display controller which uses framebuffer to scanout Thanks, Inki Dae > instead of this patch I sent. > >> >> So there is inconsistency in the non-contig vs. contig >> GEM support in exynos-drm. I think this needs to be cleaned >> up to get the desired behavior. >> >> The following commit allocates non-contiguous buffers when IOMMU is >> enabled to handle contiguous allocation failures. >> >> There are other commits that removed checks for non-contig type. >> Let's look at the following cases to see what should be the driver >> behavior in these cases: >> >> commit 122beea84bb90236b1ae545f08267af58591c21b >> Author: Rahul Sharma >> Date: Wed May 7 17:21:29 2014 +0530 >> >> drm/exynos: allocate non-contigous buffers when iommu is enabled >> >> Allow to allocate non-contigous buffers when iommu is enabled. >> Currently, it tries to allocates contigous buffer which consistently >> fail for large buffers and then fall back to non contigous. Apart >> from being slow, this implementation is also very noisy and fills >> the screen with alloc fail logs. >> >> Signed-off-by: Rahul Sharma >> Reviewed-by: Sachin Kamat >> Signed-off-by: Inki Dae >> >> >> commit ea6d66c3a797376d21b23dc8261733ce35970014 >> Author: Inki Dae >> Date: Fri Nov 2 16:10:39 2012 +0900 >> >> drm/exynos: remove EXYNOS_BO_NONCONTIG type checking. >> >> With iommu support, non-continuous buffer also is supported so >> this patch removes these checking from exynos_drm_gem_get/put_dma_addr >> funciton. >> >> This patch is based on the below patch set, "drm/exynos: add >> iommu support for -next". >> http://www.spinics.net/lists/dri-devel/msg29041.html >> >> Signed-off-by: Inki Dae >> Signed-off-by: Kyungmin Park >> >> commit 2b35892e9da672df40ce890bffc4f9f6119c57e0 >> Author: Inki Dae >> Date: Fri Mar 16 18:47:05 2012 +0900 >> >> drm/exynos: update gem and buffer framework. >> >> with this patch, we can allocate physically continuous or non-continuous >> memory and also it creates scatterlist for iommu support so allocated >> memory region can be mapped to iommu page table using scatterlist. >> >> Signed-off-by: Inki Dae >> Signed-off-by: Kyungmin Park >> Signed-off-by: Dave Airlie >> >> -- Shuah >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751360AbcHPEkQ (ORCPT ); Tue, 16 Aug 2016 00:40:16 -0400 Received: from mailout1.samsung.com ([203.254.224.24]:46704 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750729AbcHPEkO (ORCPT ); Tue, 16 Aug 2016 00:40:14 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfee68e-f79cb6d000006cfe-80-57b2992b2ed6 Content-transfer-encoding: 8BIT Message-id: <57B29925.4020600@samsung.com> Date: Tue, 16 Aug 2016 13:40:05 +0900 From: Inki Dae User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Shuah Khan , jy0922.shim@samsung.com, sw0312.kim@samsung.com, kyungmin.park@samsung.com, airlied@linux.ie, kgene@kernel.org, k.kozlowski@samsung.com Cc: dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem References: <1470850251-9150-1-git-send-email-shuahkh@osg.samsung.com> <57ABB1ED.1080301@samsung.com> <57ABB31E.1070802@osg.samsung.com> <57AE0736.6020705@osg.samsung.com> <57AE0CCB.1010708@osg.samsung.com> In-reply-to: <57AE0CCB.1010708@osg.samsung.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsWyRsSkUFd75qZwg0eXNCx6z51ksrjy9T2b xYt7F1ksXr8wtOh//JrZ4mzTG3aLTY+vsVpc3jWHzWLG+X1MFlO/fGCxmDH5JZsDt8emVZ1s Htu/PWD1uN99nMlj85J6jy39d9k9+rasYvT4vEkugD2KyyYlNSezLLVI3y6BK+PGmR9sBStM KlYszGxgfKvZxcjJISFgInHg61kWCFtM4sK99WxdjFwcQgIrGCUO/XzAAlP0e/EaFojELEaJ NU+XMIIkeAUEJX5MvgeU4OBgFpCXOHIpG8JUl5gyJRei/AGjxPmjy9ghyrUkuqc/ZAWxWQRU JTbcncUGYrMB2RNX3GcD6RUViJDoPlEJ0isisJVRYvq8q2B7mQV6GCV2nJ0JNkhYIFZizd+P 7FCXMknsWHEe7AhOAX2JI0esQOISAn/ZJbb9a2CE2CYg8W3yIbAaCQFZiU0HmCEek5Q4uOIG ywRGsVlI3pmF8M4shHcWMDKvYhRNLUguKE5KLzLSK07MLS7NS9dLzs/dxAiM1NP/nvXtYLx5 wPoQowAHoxIPbwPPpnAh1sSy4srcQ4ymQDdMZJYSTc4HpoO8knhDYzMjC1MTU2Mjc0szJXHe BKmfwUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYPQ0eh7/8+Ye1X3du1aHpAkV/ZNrXua/Q kr9aVqscWMN/WYe7IeFf/saZVnW206bUBM9MjVqq9eDHNIfzHeFbz/kYNxqYsUfPahXX3rnr 1K/d2V9NuB8ypvUL/13CVsnJ5Copftpi2pd/H+rlN34S3PTe8Rer4bQt3/lK9t+d2SijnFWq 9bFSiaU4I9FQi7moOBEAaDQCTc8CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42I5/e+xoK72zE3hBn2XFC16z51ksrjy9T2b xYt7F1ksXr8wtOh//JrZ4mzTG3aLTY+vsVpc3jWHzWLG+X1MFlO/fGCxmDH5JZsDt8emVZ1s Htu/PWD1uN99nMlj85J6jy39d9k9+rasYvT4vEkugD2qgdEmIzUxJbVIITUvOT8lMy/dVsk7 ON453tTMwFDX0NLCXEkhLzE31VbJxSdA1y0zB+hGJYWyxJxSoFBAYnGxkr4dpgmhIW66FjCN Ebq+IUFwPUYGaCBhDWPGjTM/2ApWmFSsWJjZwPhWs4uRk0NCwETi9+I1LBC2mMSFe+vZuhi5 OIQEZjFKrHm6hBEkwSsgKPFj8j2gIg4OZgF5iSOXsiFMdYkpU3Ihyh8wSpw/uowdolxLonv6 Q1YQm0VAVWLD3VlsIDYbkD1xxX02kF5RgQiJ7hOVIL0iAlsZJabPu8oC4jAL9DBK7Dg7E2yQ sECsxJq/H9khNqxgktix4jzYEZwC+hJHjlhNYAS6EuG8WQjnzUI4bwEj8ypGidSC5ILipPRc w7zUcr3ixNzi0rx0veT83E2M4GTwTGoH48Fd7ocYBTgYlXh4TzBsChdiTSwrrsw9xCjBwawk wtsxDSjEm5JYWZValB9fVJqTWnyI0RTov4nMUqLJ+cBElVcSb2hsYmZkaWRuaGFkbK4kzvv4 /7owIYH0xJLU7NTUgtQimD4mDk6pBsbC1rcPzMy1d/HbnPFaePH9YcFX0a6cN6dd482f3Rs3 y112nUPFEs6MuU3J0r/XP/j/rk2Tzay+Zpl6qkXb9a8FGRE/TBhXFK64IPwtMCjlwP+6WddP Xtr6i1G6ZcOUR6/0nqcFdvW4egRfUvL9x9MhwfA8mW23te25BxdW73viN2VNj3aeeLcSS3FG oqEWc1FxIgArxjd2HAMAAA== DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Shuah, 2016년 08월 13일 02:52에 Shuah Khan 이(가) 쓴 글: > On 08/12/2016 11:28 AM, Shuah Khan wrote: >> On 08/10/2016 05:05 PM, Shuah Khan wrote: >>> On 08/10/2016 04:59 PM, Inki Dae wrote: >>>> Hi Shuah, >>>> >>>> 2016년 08월 11일 02:30에 Shuah Khan 이(가) 쓴 글: >>>>> Fix exynos_drm_gem_create_ioctl() attempts to allocate non-contiguous GEM >>>>> memory without IOMMU. In this case, there is no point in attempting to >>>> >>>> DRM gem can be used for Non-DRM drivers such as GPU, V4L2 based Multimedia device and other DMA devices. >>>> Even though IOMMU support is disabled, other framework based DMA drivers can use IOMMU - i.e., GPU driver - >>>> and they can use non-contiguous GEM buffer through UMM. (DMABUF) >>>> >>>> So GEM allocation type is not dependent on IOMMU. >>> >>> Hi Inki, >>> >>> I am seeing the following failure without IOMMU and light dm fails >>> to start: >>> >>> [drm:exynos_drm_framebuffer_init] *ERROR* Non-continguous GEM memory is not supported. >>> >>> The change I made fixed that problem and light dm starts without IOMMU. >>> Is there a better way to fix this problem? Currently without IOMMU, >>> light dm doesn't start. >>> >>> This is on linux_next >> >> Hi Inki, >> >> I am looking into this further and I am finding inconsistent >> commits with regards to GEM contiguous and non-contiguous >> buffers. >> >> Okay what you said is that: >> >> exymod-drm should support non-continguous and contiguous GEM memory >> type with or without IOMMU Right. >> >> However, the code currently isn't doing that. The following >> commit allocates non-contiguous buffers when IOMMU is enabled >> to handle contiguous allocation failures. >> >> There are other commits that removed checks for non-contig type. >> Let's look at the following cases to see what should be the driver >> behavior in these cases: >> >> IOMMU is disabled: >> >> exynos_drm_gem_create_ioctl() gets called with NONCONTIG >> - driver should try to allocate non-contig >> - if it can't allocate non-contig, allocate contig >> ( this will allow avoid failure like the one I am seeing) >> >> exynos_drm_gem_create_ioctl() gets called with CONTIG >> - driver should try to allocate contig >> - if it can't allocate contig, allocate non-contig >> >> What is confusing is there are several code paths in the >> GEN allocation and checking memory types are enforcing >> non-contig with IOMMU. Check this routine: >> >> exynos_drm_framebuffer_init() will reject non-contig >> memory type when check_fb_gem_memory_type() rejects >> non-contig GEM memory type without IOMMU. Only in case that the gem buffer is used for framebuffer, gem memory type should be checked because this means the DMA of Display controller accesses the gem buffer so without IOMMU the DMA device cannot access non-contiguous memory region. That is why exynos_drm_framebuffer_init checks gem memory type for fb not when gem is created. > > > okay the very first commit that added IOMMU support > introduced the code that rejects non-contig gem memory > type without IOMMU. > > commit 0519f9a12d0113caab78980c48a7902d2bd40c2c > Author: Inki Dae > Date: Sat Oct 20 07:53:42 2012 -0700 > > drm/exynos: add iommu support for exynos drm framework > > Anyway, if it is th right change to fix check_fb_gem_memory_type() > to not reject NONCONTIG_BUFFER, then I can make that change No, as I mentioned above, the gem buffer for fb is dependent on IOMMU because the gem buffer for fb is used by DMA device - FIMD, DECON or Mixer. You would need to understand that gem buffer can be used for other purposes - 2D/3D or post process devices which don't use framebuffer - not display controller which uses framebuffer to scanout Thanks, Inki Dae > instead of this patch I sent. > >> >> So there is inconsistency in the non-contig vs. contig >> GEM support in exynos-drm. I think this needs to be cleaned >> up to get the desired behavior. >> >> The following commit allocates non-contiguous buffers when IOMMU is >> enabled to handle contiguous allocation failures. >> >> There are other commits that removed checks for non-contig type. >> Let's look at the following cases to see what should be the driver >> behavior in these cases: >> >> commit 122beea84bb90236b1ae545f08267af58591c21b >> Author: Rahul Sharma >> Date: Wed May 7 17:21:29 2014 +0530 >> >> drm/exynos: allocate non-contigous buffers when iommu is enabled >> >> Allow to allocate non-contigous buffers when iommu is enabled. >> Currently, it tries to allocates contigous buffer which consistently >> fail for large buffers and then fall back to non contigous. Apart >> from being slow, this implementation is also very noisy and fills >> the screen with alloc fail logs. >> >> Signed-off-by: Rahul Sharma >> Reviewed-by: Sachin Kamat >> Signed-off-by: Inki Dae >> >> >> commit ea6d66c3a797376d21b23dc8261733ce35970014 >> Author: Inki Dae >> Date: Fri Nov 2 16:10:39 2012 +0900 >> >> drm/exynos: remove EXYNOS_BO_NONCONTIG type checking. >> >> With iommu support, non-continuous buffer also is supported so >> this patch removes these checking from exynos_drm_gem_get/put_dma_addr >> funciton. >> >> This patch is based on the below patch set, "drm/exynos: add >> iommu support for -next". >> http://www.spinics.net/lists/dri-devel/msg29041.html >> >> Signed-off-by: Inki Dae >> Signed-off-by: Kyungmin Park >> >> commit 2b35892e9da672df40ce890bffc4f9f6119c57e0 >> Author: Inki Dae >> Date: Fri Mar 16 18:47:05 2012 +0900 >> >> drm/exynos: update gem and buffer framework. >> >> with this patch, we can allocate physically continuous or non-continuous >> memory and also it creates scatterlist for iommu support so allocated >> memory region can be mapped to iommu page table using scatterlist. >> >> Signed-off-by: Inki Dae >> Signed-off-by: Kyungmin Park >> Signed-off-by: Dave Airlie >> >> -- Shuah >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > >