From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tobias Jakobi Subject: Re: exynos-drm: display manager fails to start without IOMMU problem Date: Wed, 19 Oct 2016 18:23:50 +0200 Message-ID: <58079E16.50302@math.uni-bielefeld.de> 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> <57B29925.4020600@samsung.com> <1b2c3b31-7127-af2f-18a2-f3a28567e28d@osg.samsung.com> <2173cc13-7c77-1a38-501d-2c0f522ff5d5@osg.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <2173cc13-7c77-1a38-501d-2c0f522ff5d5@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 , Inki Dae , jy0922.shim@samsung.com, sw0312.kim@samsung.com, kyungmin.park@samsung.com, airlied@linux.ie, kgene@kernel.org, Krzysztof Kozlowski 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 SGVsbG8gU2h1YWgsCgpqdXN0IGEgc2hvcnQgbm90ZSB0aGF0IG1vcmUgbWlzbGVhZGluZyBjb21t ZW50cyBhYm91dCBkZWZhdWx0IGFsbG9jYXRpb24KZmxhZ3MgY2FuIGJlIGZvdW5kIGluIGxpYmRy bS4KCmh0dHBzOi8vY2dpdC5mcmVlZGVza3RvcC5vcmcvbWVzYS9kcm0vdHJlZS9leHlub3MvZXh5 bm9zX2RybS5jCgpTZWUgZS5nLiB0aGUgY29tbWVudCBmb3IgZXh5bm9zX2JvX2NyZWF0ZSgpLgoK SW4gbXkgb3BpbmlvbiwgdGhlIHdob2xlIGFwcHJvYWNoIHRvIF9zZXRfIGEgYml0IHRvIGdldCBu b24tY29udGlnaW91cwptZW1vcnkgaXMgbWVzc2VkIHVwLiBJdCB3b3VsZCBtYWtlIG1vcmUgc2Vu c2UgdG8gbWUgdG8gc2V0IGEgYml0IHRvCnJlcXVlc3QgYW4gYWRkaXRpb25hbCBwcm9wZXJ0eSAo aGVyZSAiYmVpbmcgY29udGlndW91cyIpIG9mIHRoZSBtZW1vcnkuCgpBbnl3YXksIGNsZWFyaW5n IHVwIHRoaXMgc2l0dWF0aW9uIGlzIGhpZ2hseSBhcHByZWNpYXRlZCEKCk1vcmUgY29tbWVudHMg YmVsb3cuCgpXaXRoIGJlc3Qgd2lzaGVzLApUb2JpYXMKCgoKU2h1YWggS2hhbiB3cm90ZToKPiBS ZXN0YXJ0aW5nIHRoZSB0aHJlYWQgd2l0aCBhIGRpZmZlcmVudCBzdWJqZWN0IGxpbmU6Cj4gCj4g SSBoYXZlbid0IGdpdmVuIHVwIG9uIHRoaXMgeWV0LiBJIGFtIHN0aWxsIHNlZWluZyB0aGUgZm9s bG93aW5nIGZhaWx1cmU6Cj4gCj4gQWRkaXRpb25hbCBkZWJ1ZyBtZXNzYWdlcyBJIGFkZGVkOgo+ IFsgICAxNS4yODc0MDNdIGV4eW5vc19kcm1fZ2VtX2NyZWF0ZV9pb2N0bCgpIDEKPiBbICAgMTUu Mjg3NDE5XSBleHlub3NfZHJtX2dlbV9jcmVhdGUoKSBmbGFncyAxCj4gCj4gWyAgIDE1LjMxMTUx MV0gW2RybTpleHlub3NfZHJtX2ZyYW1lYnVmZmVyX2luaXRdICpFUlJPUiogTm9uLWNvbnRpZ3Vv dXMgR0VNIG1lbW9yeSBpcyBub3Qgc3VwcG9ydGVkLgo+IAo+IEFkZGl0aW9uYWwgZGVidWcgbWVz c2FnZSBJIGFkZGVkOgo+IFsgICAxNS4zMTg5ODFdIFtkcm06ZXh5bm9zX3VzZXJfZmJfY3JlYXRl XSAqRVJST1IqIGZhaWxlZCB0byBpbml0aWFsaXplIGZyYW1lYnVmZmVyCj4gCj4gVGhpcyBpcyB3 aGF0IGhhcHBlbnM6Cj4gCj4gMS4gZXh5bm9zX2RybV9nZW1fY3JlYXRlX2lvY3RsKCkgZ2V0cyBj YWxsZWQgd2l0aCBFWFlOT1NfQk9fTk9OQ09OVElHIHJlcXVlc3QKPiAyLiBleHlub3NfZHJtX2dl bV9jcmVhdGUoMCBnb2VzIGFoZWFkIGFuZCBjcmVhdGVzIHRoZSBHRU0gYnVmZmVycwo+IDMuIGV4 eW5vc191c2VyX2ZiX2NyZWF0ZSgpIHRyaWVzIHRvIGFzc29jaWF0ZSBHRU0gdG8gZmIgYW5kIGZh aWxzIGR1cmluZwo+ICAgIGNoZWNrX2ZiX2dlbV9tZW1vcnlfdHlwZSgpCj4gCj4gQXQgdGhpcyBw b2ludCwgdGhlcmUgaXMgbm8gcmVjb3ZlcnkgYW5kIGxpZ2h0ZG0gZmFpbHMKPiAKPiB4Zjg2LXZp ZGVvLWFybXNvYy9zcmMvZHJtbW9kZV9leHlub3MvZHJtbW9kZV9leHlub3MuYyBhc3N1bWVzIGNv bnRpZ3VvdXMKPiBhbGxvY2F0aW9ucyBhcmUgbm90IHN1cHBvcnRlZCBpbiBzb21lIGV4eW5vcyBk cm0gdmVyc2lvbnM6IFRoZSBmb2xsb3dpbmcKPiBjb21taXQgaW50cm9kdWNlZCB0aGlzIGNoYW5n ZToKPiAKPiBodHRwczovL2dpdC5saW5hcm8ub3JnL2FybS94b3JnL2RyaXZlci94Zjg2LXZpZGVv LWFybXNvYy5naXQvY29tbWl0ZGlmZi8zYmUxZjYyNzM0NDFmZTk1ZGQ0NDJmNDQwNjQzODczMjJl MTZiN2U5Cj4gCj4gZXhjZXJwdHMgZnJvbSB0aGUgZGlmZjotICAgICAgIGlmIChjcmVhdGVfZ2Vt LT5idWZfdHlwZSA9PSBBUk1TT0NfQk9fU0NBTk9VVCkKPiAtICAgICAgICAgICAgICAgY3JlYXRl X2V4eW5vcy5mbGFncyA9IEVYWU5PU19CT19DT05USUc7Cj4gLSAgICAgICBlbHNlCj4gLSAgICAg ICAgICAgICAgIGNyZWF0ZV9leHlub3MuZmxhZ3MgPSBFWFlOT1NfQk9fTk9OQ09OVElHOwo+ICsK PiArICAgICAgIC8qIENvbnRpZ3VvdXMgYWxsb2NhdGlvbnMgYXJlIG5vdCBzdXBwb3J0ZWQgaW4g c29tZSBleHlub3MgZHJtIHZlcnNpb25zLgo+ICsgICAgICAgICogV2hlbiB0aGV5IGFyZSBzdXBw b3J0ZWQgYWxsIGFsbG9jYXRpb25zIGFyZSBlZmZlY3RpdmVseSBjb250aWd1b3VzCj4gKyAgICAg ICAgKiBhbnl3YXksIHNvIGZvciBzaW1wbGljaXR5IHdlIGFsd2F5cyByZXF1ZXN0IG5vbiBjb250 aWd1b3VzIGJ1ZmZlcnMuCj4gKyAgICAgICAgKi8KPiArICAgICAgIGNyZWF0ZV9leHlub3MuZmxh Z3MgPSBFWFlOT1NfQk9fTk9OQ09OVElHOwo+IAo+IFRoZXJlIG1pZ2h0IGhhdmUgYmVlbiBsb2dp YyBvbiBleHlub3NfZHJtIHRoYXQgZm9yY2VkIENvbnRpZyB3aGVuIGl0IGNvdWRuJ3QKPiBzdXBw b3J0IE5PTkNPTlRJRy4gQXQgbGVhc3QsIHRoYXQgaXMgd2hhdCB0aGlzIGNvbW1lbnQgc3VnZ2Vz dHMuIFRoaXMgYXNzdW1wdGlvbgo+IGRvZXNuJ3QgYXBwZWFyIHRvIGJlIGEgZ29vZCBvbmUgYW5k IG5vdCBzdXJlIGlmIHRoaXMgY2hhbmdlIHdhcyBtYWRlIHRvIGZpeCBhIGJ1Zy4KPiAKPiBBZnRl ciB0aGUgSU9NTVUgc3VwcG9ydCwgdGhpcyBhc3N1bXB0aW9uIGlzIG5vIGxvbmdlciB0cnVlLiBI ZW5jZSwgd2l0aCBJT01NVQo+IHN1cHBvcnQsIGxhdGVzdCBrZXJuZWxzIGhhdmUgYSBtaXNtYXRj aCB3aXRoIHRoZSBpbnN0YWxsZWQgeGY4Ni12aWRlby1hcm1zb2MKPiAKPiBUaGlzIGlzIHdoYXQg SSBhbSBydW5uaW5nIGludG8uIFRoaXMgbGVhZHMgdG8gdGhlIGZvbGxvd2luZyBxdWVzdGlvbjoK PiAKPiAxLiBIb3cgZG8gd2UgZW5zdXJlIGV4eW5vc19kcm0ga2VybmVsIGNoYW5nZXMgZG9uJ3Qg YnJlYWsgdXNlci1zcGFjZQo+ICAgIHNwZWNpZmljYWxseSB4Zjg2LXZpZGVvLWFybXNvYwo+IDIu IFRoaXMgc2VlbXMgdG8gaGF2ZSBnb25lIHVuZGV0ZWN0ZWQgZm9yIGEgd2hpbGUuIEkgc2VlIGEg Y2hhbmdlIGluCj4gICAgZXh5bm9zX2RybV9nZW1fZHVtYl9jcmVhdGUoKSB0aGF0IGlzIHByb2Jh Ymx5IGFkZHJlc3NpbmcgdGhpcyB0eXBlCj4gICAgb2YgYnJlYWthZ2UuIENvbW1pdCAxMjJiZWVh ODRiYjkwMjM2YjFhZTU0NWYwODI2N2FmNTg1OTFjMjFiIGFkZHMKPiAgICBoYW5kbGluZyBmb3Ig SU9NTVUgTk9OQ09OVElHIGNhc2UuCkkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGNvbW1pdCBpcyBy ZWxhdGVkIHRvIHRoZSBpc3N1ZSwgc2luY2UgaXQgaXMgb25seQp1c2VkIGZvciB0aGUgZ2VuZXJp YyBkdW1iIGJ1ZmZlciBpb2N0bCwgd2hpbGUgYXJtc29jIGlzIHVzaW5nIGFuIEV4eW5vcwpzcGVj aWZpYyBpb2N0bC4KClNvIGluIHBhcnRpY3VsYXIgeW91IHNob3VsZG4ndCBzZWUgdGhlIGlzc3Vl IHdpdGgKeGY4Ni12aWRlby1tb2Rlc2V0dGluZy4gTWlnaHQgYmUgd29ydGggdHJ5aW5nIHRoYXQg b25lIG91dD8KCgo+IAo+IEFueXdheSwgSSBhbSBpbnRlcmVzdGVkIGluIGdldHRpbmcgdGhlIGV4 eW5vc19kcm0ga2VybmVsIHNpZGUgY29kZQo+IGFuZCB4Zjg2LXZpZGVvLWFybXNvYyBpbiBzeW5j IHRvIHJlc29sdmUgdGhlIGlzc3VlLgo+IAo+IENvdWxkIHlvdSByZWNvbW1lbmQgYSBnb2luZyBm b3J3YXJkIHBsYW4/Cj4gCj4gSSBjYW4gc3VibWl0IGEgcGF0Y2ggdG8geGY4Ni12aWRlby1hcm1z b2MuIEkgYW0gYWxzbyBsb29raW5nIGFoZWFkIHRvCj4gc2VlIGlmIHdlIGNhbiBhdm9pZCBzdWNo IGJyZWFrcyBpbiB0aGUgZnV0dXJlIGJ5IGtlZXBpbmcga2VybmVsIGFuZAo+IHhmODYtdmlkZW8t YXJtc29jIGluIHN5bmMuCj4gCj4gdGhhbmtzLAo+IC0tIFNodWFoCj4gCj4gLS0KPiBUbyB1bnN1 YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgt c2Ftc3VuZy1zb2MiIGluCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2Vy Lmtlcm5lbC5vcmcKPiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5rZXJuZWwu b3JnL21ham9yZG9tby1pbmZvLmh0bWwKPiAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3Rz LmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: tjakobi@math.uni-bielefeld.de (Tobias Jakobi) Date: Wed, 19 Oct 2016 18:23:50 +0200 Subject: exynos-drm: display manager fails to start without IOMMU problem In-Reply-To: <2173cc13-7c77-1a38-501d-2c0f522ff5d5@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> <57B29925.4020600@samsung.com> <1b2c3b31-7127-af2f-18a2-f3a28567e28d@osg.samsung.com> <2173cc13-7c77-1a38-501d-2c0f522ff5d5@osg.samsung.com> Message-ID: <58079E16.50302@math.uni-bielefeld.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello Shuah, just a short note that more misleading comments about default allocation flags can be found in libdrm. https://cgit.freedesktop.org/mesa/drm/tree/exynos/exynos_drm.c See e.g. the comment for exynos_bo_create(). In my opinion, the whole approach to _set_ a bit to get non-contigious memory is messed up. It would make more sense to me to set a bit to request an additional property (here "being contiguous") of the memory. Anyway, clearing up this situation is highly appreciated! More comments below. With best wishes, Tobias Shuah Khan wrote: > Restarting the thread with a different subject line: > > I haven't given up on this yet. I am still seeing the following failure: > > Additional debug messages I added: > [ 15.287403] exynos_drm_gem_create_ioctl() 1 > [ 15.287419] exynos_drm_gem_create() flags 1 > > [ 15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM memory is not supported. > > Additional debug message I added: > [ 15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize framebuffer > > This is what happens: > > 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG request > 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers > 3. exynos_user_fb_create() tries to associate GEM to fb and fails during > check_fb_gem_memory_type() > > At this point, there is no recovery and lightdm fails > > xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous > allocations are not supported in some exynos drm versions: The following > commit introduced this change: > > https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9 > > excerpts from the diff:- if (create_gem->buf_type == ARMSOC_BO_SCANOUT) > - create_exynos.flags = EXYNOS_BO_CONTIG; > - else > - create_exynos.flags = EXYNOS_BO_NONCONTIG; > + > + /* Contiguous allocations are not supported in some exynos drm versions. > + * When they are supported all allocations are effectively contiguous > + * anyway, so for simplicity we always request non contiguous buffers. > + */ > + create_exynos.flags = EXYNOS_BO_NONCONTIG; > > There might have been logic on exynos_drm that forced Contig when it coudn't > support NONCONTIG. At least, that is what this comment suggests. This assumption > doesn't appear to be a good one and not sure if this change was made to fix a bug. > > After the IOMMU support, this assumption is no longer true. Hence, with IOMMU > support, latest kernels have a mismatch with the installed xf86-video-armsoc > > This is what I am running into. This leads to the following question: > > 1. How do we ensure exynos_drm kernel changes don't break user-space > specifically xf86-video-armsoc > 2. This seems to have gone undetected for a while. I see a change in > exynos_drm_gem_dumb_create() that is probably addressing this type > of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds > handling for IOMMU NONCONTIG case. I don't think that this commit is related to the issue, since it is only used for the generic dumb buffer ioctl, while armsoc is using an Exynos specific ioctl. So in particular you shouldn't see the issue with xf86-video-modesetting. Might be worth trying that one out? > > Anyway, I am interested in getting the exynos_drm kernel side code > and xf86-video-armsoc in sync to resolve the issue. > > Could you recommend a going forward plan? > > I can submit a patch to xf86-video-armsoc. I am also looking ahead to > see if we can avoid such breaks in the future by keeping kernel and > xf86-video-armsoc in sync. > > thanks, > -- 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 S946047AbcJSQYX (ORCPT ); Wed, 19 Oct 2016 12:24:23 -0400 Received: from smtp.math.uni-bielefeld.de ([129.70.45.10]:52653 "EHLO smtp.math.uni-bielefeld.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938894AbcJSQX4 (ORCPT ); Wed, 19 Oct 2016 12:23:56 -0400 Subject: Re: exynos-drm: display manager fails to start without IOMMU problem To: Shuah Khan , Inki Dae , jy0922.shim@samsung.com, sw0312.kim@samsung.com, kyungmin.park@samsung.com, airlied@linux.ie, kgene@kernel.org, Krzysztof Kozlowski Cc: dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org 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> <57B29925.4020600@samsung.com> <1b2c3b31-7127-af2f-18a2-f3a28567e28d@osg.samsung.com> <2173cc13-7c77-1a38-501d-2c0f522ff5d5@osg.samsung.com> From: Tobias Jakobi Message-ID: <58079E16.50302@math.uni-bielefeld.de> Date: Wed, 19 Oct 2016 18:23:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: <2173cc13-7c77-1a38-501d-2c0f522ff5d5@osg.samsung.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Shuah, just a short note that more misleading comments about default allocation flags can be found in libdrm. https://cgit.freedesktop.org/mesa/drm/tree/exynos/exynos_drm.c See e.g. the comment for exynos_bo_create(). In my opinion, the whole approach to _set_ a bit to get non-contigious memory is messed up. It would make more sense to me to set a bit to request an additional property (here "being contiguous") of the memory. Anyway, clearing up this situation is highly appreciated! More comments below. With best wishes, Tobias Shuah Khan wrote: > Restarting the thread with a different subject line: > > I haven't given up on this yet. I am still seeing the following failure: > > Additional debug messages I added: > [ 15.287403] exynos_drm_gem_create_ioctl() 1 > [ 15.287419] exynos_drm_gem_create() flags 1 > > [ 15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM memory is not supported. > > Additional debug message I added: > [ 15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize framebuffer > > This is what happens: > > 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG request > 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers > 3. exynos_user_fb_create() tries to associate GEM to fb and fails during > check_fb_gem_memory_type() > > At this point, there is no recovery and lightdm fails > > xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous > allocations are not supported in some exynos drm versions: The following > commit introduced this change: > > https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9 > > excerpts from the diff:- if (create_gem->buf_type == ARMSOC_BO_SCANOUT) > - create_exynos.flags = EXYNOS_BO_CONTIG; > - else > - create_exynos.flags = EXYNOS_BO_NONCONTIG; > + > + /* Contiguous allocations are not supported in some exynos drm versions. > + * When they are supported all allocations are effectively contiguous > + * anyway, so for simplicity we always request non contiguous buffers. > + */ > + create_exynos.flags = EXYNOS_BO_NONCONTIG; > > There might have been logic on exynos_drm that forced Contig when it coudn't > support NONCONTIG. At least, that is what this comment suggests. This assumption > doesn't appear to be a good one and not sure if this change was made to fix a bug. > > After the IOMMU support, this assumption is no longer true. Hence, with IOMMU > support, latest kernels have a mismatch with the installed xf86-video-armsoc > > This is what I am running into. This leads to the following question: > > 1. How do we ensure exynos_drm kernel changes don't break user-space > specifically xf86-video-armsoc > 2. This seems to have gone undetected for a while. I see a change in > exynos_drm_gem_dumb_create() that is probably addressing this type > of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds > handling for IOMMU NONCONTIG case. I don't think that this commit is related to the issue, since it is only used for the generic dumb buffer ioctl, while armsoc is using an Exynos specific ioctl. So in particular you shouldn't see the issue with xf86-video-modesetting. Might be worth trying that one out? > > Anyway, I am interested in getting the exynos_drm kernel side code > and xf86-video-armsoc in sync to resolve the issue. > > Could you recommend a going forward plan? > > I can submit a patch to xf86-video-armsoc. I am also looking ahead to > see if we can avoid such breaks in the future by keeping kernel and > xf86-video-armsoc in sync. > > thanks, > -- 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 >