From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Date: Wed, 27 Apr 2016 09:45:31 +0000 Subject: Re: [PATCH v2 4/8] drm/fb-helper: Add fb_deferred_io support Message-Id: <57208A3B.4020909@tronnes.org> List-Id: References: <1461530942-22485-1-git-send-email-noralf@tronnes.org> <1461530942-22485-5-git-send-email-noralf@tronnes.org> <20160425090957.GQ2510@phenom.ffwll.local> <571F9656.1090506@tronnes.org> <20160426171902.GA2558@phenom.ffwll.local> In-Reply-To: <20160426171902.GA2558@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, laurent.pinchart@ideasonboard.com, tomi.valkeinen@ti.com, linux-kernel@vger.kernel.org Den 26.04.2016 19:19, skrev Daniel Vetter: > On Tue, Apr 26, 2016 at 06:24:54PM +0200, Noralf Tr=F8nnes wrote: >> Den 25.04.2016 11:09, skrev Daniel Vetter: >>> On Sun, Apr 24, 2016 at 10:48:58PM +0200, Noralf Tr=F8nnes wrote: >>>> This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled. >>>> The fbdev framebuffer changes are flushed using the callback >>>> (struct drm_framebuffer *)->funcs->dirty() by a dedicated worker >>>> ensuring that it always runs in process context. >>>> >>>> Signed-off-by: Noralf Tr=F8nnes >>>> --- >>>> >>>> Changes since v1: >>>> - Use a dedicated worker to run the framebuffer flushing like qxl does >>>> - Add parameter descriptions to drm_fb_helper_deferred_io >>>> >>>> drivers/gpu/drm/drm_fb_helper.c | 127 ++++++++++++++++++++++++++++++= +++++++++- >>>> include/drm/drm_fb_helper.h | 17 ++++++ >>>> 2 files changed, 143 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_= helper.c >>>> index 855108e..46ee6f8 100644 >>>> --- a/drivers/gpu/drm/drm_fb_helper.c >>>> +++ b/drivers/gpu/drm/drm_fb_helper.c >>>> @@ -40,6 +40,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> >>>> static bool drm_fbdev_emulation =3D true; >>>> module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600); >>>> @@ -48,6 +49,10 @@ MODULE_PARM_DESC(fbdev_emulation, >>>> >>>> static LIST_HEAD(kernel_fb_helper_list); >>>> >>>> +static void drm_fb_helper_dirty_init(struct drm_fb_helper *helper); >>>> +static void drm_fb_helper_dirty(struct fb_info *info, u32 x, u32 y, >>>> + u32 width, u32 height); >>>> + >>>> /** >>>> * DOC: fbdev helpers >>>> * >>>> @@ -84,6 +89,16 @@ static LIST_HEAD(kernel_fb_helper_list); >>>> * and set up an initial configuration using the detected hardware, = drivers >>>> * should call drm_fb_helper_single_add_all_connectors() followed by >>>> * drm_fb_helper_initial_config(). >>>> + * >>>> + * If CONFIG_FB_DEFERRED_IO is enabled and >>>> + * (struct drm_framebuffer *)->funcs->dirty is set, the >>>> + * drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit} functi= ons >>>> + * will accumulate changes and schedule (struct fb_helper).dirty_work= to run >>>> + * right away. This worker then calls the dirty() function ensuring t= hat it >>>> + * will always run in process context since the fb_*() function could= be >>>> + * running in atomic context. If drm_fb_helper_deferred_io() is used = as the >>>> + * deferred_io callback it will also schedule dirty_work with the dam= age >>>> + * collected from the mmap page writes. >>> One thing to consider (and personally I don't care either way) is wheth= er >>> we shouldn't just select CONFIG_FB_DEFERRED_IO if the fbdev helpers are >>> enabled. Pushing that out to drivers is imo a bit fragile. >>> >>> But like I said I'm ok with either way. >> My concern was adding code and data that only a few drivers would >> actually use. But of course there's the tradeoff with complexity. >> I use this to enable it: >> select FB_DEFERRED_IO if DRM_KMS_FB_HELPER >> >> I guess the maintainer has to make this choice between size and complexi= ty >> :-) >> I can enable it by default if you want, drm is both huge and complex so I >> don't know what's best. >> >> As a sidenote, I have also put all the fbdev code in a file of it's own = to >> make it simple with regards to the DRM_FBDEV_EMULATION user option: >> tinydrm-$(CONFIG_DRM_KMS_FB_HELPER) +=3D tinydrm-fbdev.o > Ok, if you ask maintainers then please nuke the #ifdef from .c files. If > you select CONFIG_DRM_KMS_FB_HELPER, then you get hdmi, edid, dp aux, dp > mst and whatever else helpers, even if you don't need them. Adding 3 > functions for defio when you select fbdev helpers and maybe don't need > them is totally harmless. And removing the #ifdef will look so much better > ;-) Will do :-) Kernel development is just my hobby so I'm not well versed in all of this. >>>> */ >>>> >>>> /** >>>> @@ -401,11 +416,14 @@ backoff: >>>> static int restore_fbdev_mode(struct drm_fb_helper *fb_helper) >>>> { >>>> struct drm_device *dev =3D fb_helper->dev; >>>> + struct fb_info *info =3D fb_helper->fbdev; >>>> struct drm_plane *plane; >>>> int i; >>>> >>>> drm_warn_on_modeset_not_all_locked(dev); >>>> >>>> + drm_fb_helper_dirty(info, 0, 0, info->var.xres, info->var.yres); >>> Why is this needed? If you do a modeset (or pageflip or whatever) drive= rs >>> are supposed to re-upload the entire screen. We've talked about adding a >>> dirty rectangle to atomic to allow userspace to optimize this, but there >>> should _never_ be a need to do a dirtyfb call around a modeset. Probably >>> just a driver bug in your panel drm drivers? >> Ok, in tinydrm I now set a flag in &drm_simple_display_pipe_funcs >> ->plane_update to indicate that the next dirty() should do the whole >> framebuffer which seems to work fine. >> Should I actually perform the update as well? >> If so I would need to add a worker in tinydrm to do that. > Yes, plane update should always do a full update. Not sure how you get > away with delaying that to ->dirty, maybe modesetting isn't > double-buffering when you don't have a GL that could do glamour. > > ->dirty is _only_ for frontbuffer rendering, not for page-flipping to an > entirely new buffer. In short if someone calls ->dirty on a buffer which > is currently not being displayed than a) they're silly b) drivers should > treat it as a no-op. Maybe we need a helper to do that ... > -Daniel drm_fb_helper will call dirty() as long as there's fbdev activity, so the driver needs to take that into account. For instance fbcon with a blinking cursor will trigger calls even if a buffer has been set up on the drm side. tinydrm checks the fb against the fb set on the plane and if it differs it's a no-op. Noralf. From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Subject: Re: [PATCH v2 4/8] drm/fb-helper: Add fb_deferred_io support Date: Wed, 27 Apr 2016 11:45:31 +0200 Message-ID: <57208A3B.4020909@tronnes.org> References: <1461530942-22485-1-git-send-email-noralf@tronnes.org> <1461530942-22485-5-git-send-email-noralf@tronnes.org> <20160425090957.GQ2510@phenom.ffwll.local> <571F9656.1090506@tronnes.org> <20160426171902.GA2558@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9E0A16EA30 for ; Wed, 27 Apr 2016 09:45:35 +0000 (UTC) In-Reply-To: <20160426171902.GA2558@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, laurent.pinchart@ideasonboard.com, tomi.valkeinen@ti.com, linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org CkRlbiAyNi4wNC4yMDE2IDE5OjE5LCBza3JldiBEYW5pZWwgVmV0dGVyOgo+IE9uIFR1ZSwgQXBy IDI2LCAyMDE2IGF0IDA2OjI0OjU0UE0gKzAyMDAsIE5vcmFsZiBUcsO4bm5lcyB3cm90ZToKPj4g RGVuIDI1LjA0LjIwMTYgMTE6MDksIHNrcmV2IERhbmllbCBWZXR0ZXI6Cj4+PiBPbiBTdW4sIEFw ciAyNCwgMjAxNiBhdCAxMDo0ODo1OFBNICswMjAwLCBOb3JhbGYgVHLDuG5uZXMgd3JvdGU6Cj4+ Pj4gVGhpcyBhZGRzIGRlZmVycmVkIGlvIHN1cHBvcnQgaWYgQ09ORklHX0ZCX0RFRkVSUkVEX0lP IGlzIGVuYWJsZWQuCj4+Pj4gVGhlIGZiZGV2IGZyYW1lYnVmZmVyIGNoYW5nZXMgYXJlIGZsdXNo ZWQgdXNpbmcgdGhlIGNhbGxiYWNrCj4+Pj4gKHN0cnVjdCBkcm1fZnJhbWVidWZmZXIgKiktPmZ1 bmNzLT5kaXJ0eSgpIGJ5IGEgZGVkaWNhdGVkIHdvcmtlcgo+Pj4+IGVuc3VyaW5nIHRoYXQgaXQg YWx3YXlzIHJ1bnMgaW4gcHJvY2VzcyBjb250ZXh0Lgo+Pj4+Cj4+Pj4gU2lnbmVkLW9mZi1ieTog Tm9yYWxmIFRyw7hubmVzIDxub3JhbGZAdHJvbm5lcy5vcmc+Cj4+Pj4gLS0tCj4+Pj4KPj4+PiBD aGFuZ2VzIHNpbmNlIHYxOgo+Pj4+IC0gVXNlIGEgZGVkaWNhdGVkIHdvcmtlciB0byBydW4gdGhl IGZyYW1lYnVmZmVyIGZsdXNoaW5nIGxpa2UgcXhsIGRvZXMKPj4+PiAtIEFkZCBwYXJhbWV0ZXIg ZGVzY3JpcHRpb25zIHRvIGRybV9mYl9oZWxwZXJfZGVmZXJyZWRfaW8KPj4+Pgo+Pj4+ICAgZHJp dmVycy9ncHUvZHJtL2RybV9mYl9oZWxwZXIuYyB8IDEyNyArKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKystCj4+Pj4gICBpbmNsdWRlL2RybS9kcm1fZmJfaGVscGVyLmggICAg IHwgIDE3ICsrKysrKwo+Pj4+ICAgMiBmaWxlcyBjaGFuZ2VkLCAxNDMgaW5zZXJ0aW9ucygrKSwg MSBkZWxldGlvbigtKQo+Pj4+Cj4+Pj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1L2RybS9kcm1f ZmJfaGVscGVyLmMgYi9kcml2ZXJzL2dwdS9kcm0vZHJtX2ZiX2hlbHBlci5jCj4+Pj4gaW5kZXgg ODU1MTA4ZS4uNDZlZTZmOCAxMDA2NDQKPj4+PiAtLS0gYS9kcml2ZXJzL2dwdS9kcm0vZHJtX2Zi X2hlbHBlci5jCj4+Pj4gKysrIGIvZHJpdmVycy9ncHUvZHJtL2RybV9mYl9oZWxwZXIuYwo+Pj4+ IEBAIC00MCw2ICs0MCw3IEBACj4+Pj4gICAjaW5jbHVkZSA8ZHJtL2RybV9jcnRjX2hlbHBlci5o Pgo+Pj4+ICAgI2luY2x1ZGUgPGRybS9kcm1fYXRvbWljLmg+Cj4+Pj4gICAjaW5jbHVkZSA8ZHJt L2RybV9hdG9taWNfaGVscGVyLmg+Cj4+Pj4gKyNpbmNsdWRlIDxkcm0vZHJtX3JlY3QuaD4KPj4+ Pgo+Pj4+ICAgc3RhdGljIGJvb2wgZHJtX2ZiZGV2X2VtdWxhdGlvbiA9IHRydWU7Cj4+Pj4gICBt b2R1bGVfcGFyYW1fbmFtZWQoZmJkZXZfZW11bGF0aW9uLCBkcm1fZmJkZXZfZW11bGF0aW9uLCBi b29sLCAwNjAwKTsKPj4+PiBAQCAtNDgsNiArNDksMTAgQEAgTU9EVUxFX1BBUk1fREVTQyhmYmRl dl9lbXVsYXRpb24sCj4+Pj4KPj4+PiAgIHN0YXRpYyBMSVNUX0hFQUQoa2VybmVsX2ZiX2hlbHBl cl9saXN0KTsKPj4+Pgo+Pj4+ICtzdGF0aWMgdm9pZCBkcm1fZmJfaGVscGVyX2RpcnR5X2luaXQo c3RydWN0IGRybV9mYl9oZWxwZXIgKmhlbHBlcik7Cj4+Pj4gK3N0YXRpYyB2b2lkIGRybV9mYl9o ZWxwZXJfZGlydHkoc3RydWN0IGZiX2luZm8gKmluZm8sIHUzMiB4LCB1MzIgeSwKPj4+PiArCQkJ CXUzMiB3aWR0aCwgdTMyIGhlaWdodCk7Cj4+Pj4gKwo+Pj4+ICAgLyoqCj4+Pj4gICAgKiBET0M6 IGZiZGV2IGhlbHBlcnMKPj4+PiAgICAqCj4+Pj4gQEAgLTg0LDYgKzg5LDE2IEBAIHN0YXRpYyBM SVNUX0hFQUQoa2VybmVsX2ZiX2hlbHBlcl9saXN0KTsKPj4+PiAgICAqIGFuZCBzZXQgdXAgYW4g aW5pdGlhbCBjb25maWd1cmF0aW9uIHVzaW5nIHRoZSBkZXRlY3RlZCBoYXJkd2FyZSwgZHJpdmVy cwo+Pj4+ICAgICogc2hvdWxkIGNhbGwgZHJtX2ZiX2hlbHBlcl9zaW5nbGVfYWRkX2FsbF9jb25u ZWN0b3JzKCkgZm9sbG93ZWQgYnkKPj4+PiAgICAqIGRybV9mYl9oZWxwZXJfaW5pdGlhbF9jb25m aWcoKS4KPj4+PiArICoKPj4+PiArICogSWYgQ09ORklHX0ZCX0RFRkVSUkVEX0lPIGlzIGVuYWJs ZWQgYW5kCj4+Pj4gKyAqIChzdHJ1Y3QgZHJtX2ZyYW1lYnVmZmVyICopLT5mdW5jcy0+ZGlydHkg aXMgc2V0LCB0aGUKPj4+PiArICogZHJtX2ZiX2hlbHBlcl97Y2ZiLHN5c31fe3dyaXRlLGZpbGxy ZWN0LGNvcHlhcmVhLGltYWdlYmxpdH0gZnVuY3Rpb25zCj4+Pj4gKyAqIHdpbGwgYWNjdW11bGF0 ZSBjaGFuZ2VzIGFuZCBzY2hlZHVsZSAoc3RydWN0IGZiX2hlbHBlcikuZGlydHlfd29yayB0byBy dW4KPj4+PiArICogcmlnaHQgYXdheS4gVGhpcyB3b3JrZXIgdGhlbiBjYWxscyB0aGUgZGlydHko KSBmdW5jdGlvbiBlbnN1cmluZyB0aGF0IGl0Cj4+Pj4gKyAqIHdpbGwgYWx3YXlzIHJ1biBpbiBw cm9jZXNzIGNvbnRleHQgc2luY2UgdGhlIGZiXyooKSBmdW5jdGlvbiBjb3VsZCBiZQo+Pj4+ICsg KiBydW5uaW5nIGluIGF0b21pYyBjb250ZXh0LiBJZiBkcm1fZmJfaGVscGVyX2RlZmVycmVkX2lv KCkgaXMgdXNlZCBhcyB0aGUKPj4+PiArICogZGVmZXJyZWRfaW8gY2FsbGJhY2sgaXQgd2lsbCBh bHNvIHNjaGVkdWxlIGRpcnR5X3dvcmsgd2l0aCB0aGUgZGFtYWdlCj4+Pj4gKyAqIGNvbGxlY3Rl ZCBmcm9tIHRoZSBtbWFwIHBhZ2Ugd3JpdGVzLgo+Pj4gT25lIHRoaW5nIHRvIGNvbnNpZGVyIChh bmQgcGVyc29uYWxseSBJIGRvbid0IGNhcmUgZWl0aGVyIHdheSkgaXMgd2hldGhlcgo+Pj4gd2Ug c2hvdWxkbid0IGp1c3Qgc2VsZWN0IENPTkZJR19GQl9ERUZFUlJFRF9JTyBpZiB0aGUgZmJkZXYg aGVscGVycyBhcmUKPj4+IGVuYWJsZWQuIFB1c2hpbmcgdGhhdCBvdXQgdG8gZHJpdmVycyBpcyBp bW8gYSBiaXQgZnJhZ2lsZS4KPj4+Cj4+PiBCdXQgbGlrZSBJIHNhaWQgSSdtIG9rIHdpdGggZWl0 aGVyIHdheS4KPj4gTXkgY29uY2VybiB3YXMgYWRkaW5nIGNvZGUgYW5kIGRhdGEgdGhhdCBvbmx5 IGEgZmV3IGRyaXZlcnMgd291bGQKPj4gYWN0dWFsbHkgdXNlLiBCdXQgb2YgY291cnNlIHRoZXJl J3MgdGhlIHRyYWRlb2ZmIHdpdGggY29tcGxleGl0eS4KPj4gSSB1c2UgdGhpcyB0byBlbmFibGUg aXQ6Cj4+ICAgICAgICAgIHNlbGVjdCBGQl9ERUZFUlJFRF9JTyBpZiBEUk1fS01TX0ZCX0hFTFBF Ugo+Pgo+PiBJIGd1ZXNzIHRoZSBtYWludGFpbmVyIGhhcyB0byBtYWtlIHRoaXMgY2hvaWNlIGJl dHdlZW4gc2l6ZSBhbmQgY29tcGxleGl0eQo+PiA6LSkKPj4gSSBjYW4gZW5hYmxlIGl0IGJ5IGRl ZmF1bHQgaWYgeW91IHdhbnQsIGRybSBpcyBib3RoIGh1Z2UgYW5kIGNvbXBsZXggc28gSQo+PiBk b24ndCBrbm93IHdoYXQncyBiZXN0Lgo+Pgo+PiBBcyBhIHNpZGVub3RlLCBJIGhhdmUgYWxzbyBw dXQgYWxsIHRoZSBmYmRldiBjb2RlIGluIGEgZmlsZSBvZiBpdCdzIG93biB0bwo+PiBtYWtlIGl0 IHNpbXBsZSB3aXRoIHJlZ2FyZHMgdG8gdGhlIERSTV9GQkRFVl9FTVVMQVRJT04gdXNlciBvcHRp b246Cj4+IHRpbnlkcm0tJChDT05GSUdfRFJNX0tNU19GQl9IRUxQRVIpICAgICArPSB0aW55ZHJt LWZiZGV2Lm8KPiBPaywgaWYgeW91IGFzayBtYWludGFpbmVycyB0aGVuIHBsZWFzZSBudWtlIHRo ZSAjaWZkZWYgZnJvbSAuYyBmaWxlcy4gSWYKPiB5b3Ugc2VsZWN0IENPTkZJR19EUk1fS01TX0ZC X0hFTFBFUiwgdGhlbiB5b3UgZ2V0IGhkbWksIGVkaWQsIGRwIGF1eCwgZHAKPiBtc3QgYW5kIHdo YXRldmVyIGVsc2UgaGVscGVycywgZXZlbiBpZiB5b3UgZG9uJ3QgbmVlZCB0aGVtLiBBZGRpbmcg Mwo+IGZ1bmN0aW9ucyBmb3IgZGVmaW8gd2hlbiB5b3Ugc2VsZWN0IGZiZGV2IGhlbHBlcnMgYW5k IG1heWJlIGRvbid0IG5lZWQKPiB0aGVtIGlzIHRvdGFsbHkgaGFybWxlc3MuIEFuZCByZW1vdmlu ZyB0aGUgI2lmZGVmIHdpbGwgbG9vayBzbyBtdWNoIGJldHRlcgo+IDstKQoKV2lsbCBkbyA6LSkK S2VybmVsIGRldmVsb3BtZW50IGlzIGp1c3QgbXkgaG9iYnkgc28gSSdtIG5vdCB3ZWxsIHZlcnNl ZCBpbiBhbGwgb2YgdGhpcy4KCj4+Pj4gICAgKi8KPj4+Pgo+Pj4+ICAgLyoqCj4+Pj4gQEAgLTQw MSwxMSArNDE2LDE0IEBAIGJhY2tvZmY6Cj4+Pj4gICBzdGF0aWMgaW50IHJlc3RvcmVfZmJkZXZf bW9kZShzdHJ1Y3QgZHJtX2ZiX2hlbHBlciAqZmJfaGVscGVyKQo+Pj4+ICAgewo+Pj4+ICAgCXN0 cnVjdCBkcm1fZGV2aWNlICpkZXYgPSBmYl9oZWxwZXItPmRldjsKPj4+PiArCXN0cnVjdCBmYl9p bmZvICppbmZvID0gZmJfaGVscGVyLT5mYmRldjsKPj4+PiAgIAlzdHJ1Y3QgZHJtX3BsYW5lICpw bGFuZTsKPj4+PiAgIAlpbnQgaTsKPj4+Pgo+Pj4+ICAgCWRybV93YXJuX29uX21vZGVzZXRfbm90 X2FsbF9sb2NrZWQoZGV2KTsKPj4+Pgo+Pj4+ICsJZHJtX2ZiX2hlbHBlcl9kaXJ0eShpbmZvLCAw LCAwLCBpbmZvLT52YXIueHJlcywgaW5mby0+dmFyLnlyZXMpOwo+Pj4gV2h5IGlzIHRoaXMgbmVl ZGVkPyBJZiB5b3UgZG8gYSBtb2Rlc2V0IChvciBwYWdlZmxpcCBvciB3aGF0ZXZlcikgZHJpdmVy cwo+Pj4gYXJlIHN1cHBvc2VkIHRvIHJlLXVwbG9hZCB0aGUgZW50aXJlIHNjcmVlbi4gV2UndmUg dGFsa2VkIGFib3V0IGFkZGluZyBhCj4+PiBkaXJ0eSByZWN0YW5nbGUgdG8gYXRvbWljIHRvIGFs bG93IHVzZXJzcGFjZSB0byBvcHRpbWl6ZSB0aGlzLCBidXQgdGhlcmUKPj4+IHNob3VsZCBfbmV2 ZXJfIGJlIGEgbmVlZCB0byBkbyBhIGRpcnR5ZmIgY2FsbCBhcm91bmQgYSBtb2Rlc2V0LiBQcm9i YWJseQo+Pj4ganVzdCBhIGRyaXZlciBidWcgaW4geW91ciBwYW5lbCBkcm0gZHJpdmVycz8KPj4g T2ssIGluIHRpbnlkcm0gSSBub3cgc2V0IGEgZmxhZyBpbiAmZHJtX3NpbXBsZV9kaXNwbGF5X3Bp cGVfZnVuY3MKPj4gLT5wbGFuZV91cGRhdGUgdG8gaW5kaWNhdGUgdGhhdCB0aGUgbmV4dCBkaXJ0 eSgpIHNob3VsZCBkbyB0aGUgd2hvbGUKPj4gZnJhbWVidWZmZXIgd2hpY2ggc2VlbXMgdG8gd29y ayBmaW5lLgo+PiBTaG91bGQgSSBhY3R1YWxseSBwZXJmb3JtIHRoZSB1cGRhdGUgYXMgd2VsbD8K Pj4gSWYgc28gSSB3b3VsZCBuZWVkIHRvIGFkZCBhIHdvcmtlciBpbiB0aW55ZHJtIHRvIGRvIHRo YXQuCj4gWWVzLCBwbGFuZSB1cGRhdGUgc2hvdWxkIGFsd2F5cyBkbyBhIGZ1bGwgdXBkYXRlLiBO b3Qgc3VyZSBob3cgeW91IGdldAo+IGF3YXkgd2l0aCBkZWxheWluZyB0aGF0IHRvIC0+ZGlydHks IG1heWJlIG1vZGVzZXR0aW5nIGlzbid0Cj4gZG91YmxlLWJ1ZmZlcmluZyB3aGVuIHlvdSBkb24n dCBoYXZlIGEgR0wgdGhhdCBjb3VsZCBkbyBnbGFtb3VyLgo+Cj4gLT5kaXJ0eSBpcyBfb25seV8g Zm9yIGZyb250YnVmZmVyIHJlbmRlcmluZywgbm90IGZvciBwYWdlLWZsaXBwaW5nIHRvIGFuCj4g ZW50aXJlbHkgbmV3IGJ1ZmZlci4gSW4gc2hvcnQgaWYgc29tZW9uZSBjYWxscyAtPmRpcnR5IG9u IGEgYnVmZmVyIHdoaWNoCj4gaXMgY3VycmVudGx5IG5vdCBiZWluZyBkaXNwbGF5ZWQgdGhhbiBh KSB0aGV5J3JlIHNpbGx5IGIpIGRyaXZlcnMgc2hvdWxkCj4gdHJlYXQgaXQgYXMgYSBuby1vcC4g TWF5YmUgd2UgbmVlZCBhIGhlbHBlciB0byBkbyB0aGF0IC4uLgo+IC1EYW5pZWwKCmRybV9mYl9o ZWxwZXIgd2lsbCBjYWxsIGRpcnR5KCkgYXMgbG9uZyBhcyB0aGVyZSdzIGZiZGV2IGFjdGl2aXR5 LCBzbyB0aGUKZHJpdmVyIG5lZWRzIHRvIHRha2UgdGhhdCBpbnRvIGFjY291bnQuIEZvciBpbnN0 YW5jZSBmYmNvbiB3aXRoIGEgYmxpbmtpbmcKY3Vyc29yIHdpbGwgdHJpZ2dlciBjYWxscyBldmVu IGlmIGEgYnVmZmVyIGhhcyBiZWVuIHNldCB1cCBvbiB0aGUgZHJtIHNpZGUuCnRpbnlkcm0gY2hl Y2tzIHRoZSBmYiBhZ2FpbnN0IHRoZSBmYiBzZXQgb24gdGhlIHBsYW5lIGFuZCBpZiBpdCBkaWZm ZXJzCml0J3MgYSBuby1vcC4KCk5vcmFsZi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3Rz LmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753769AbcD0Jpj (ORCPT ); Wed, 27 Apr 2016 05:45:39 -0400 Received: from smtp.domeneshop.no ([194.63.252.55]:35786 "EHLO smtp.domeneshop.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753700AbcD0Jpf (ORCPT ); Wed, 27 Apr 2016 05:45:35 -0400 Subject: Re: [PATCH v2 4/8] drm/fb-helper: Add fb_deferred_io support To: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, laurent.pinchart@ideasonboard.com, tomi.valkeinen@ti.com, linux-kernel@vger.kernel.org References: <1461530942-22485-1-git-send-email-noralf@tronnes.org> <1461530942-22485-5-git-send-email-noralf@tronnes.org> <20160425090957.GQ2510@phenom.ffwll.local> <571F9656.1090506@tronnes.org> <20160426171902.GA2558@phenom.ffwll.local> From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Message-ID: <57208A3B.4020909@tronnes.org> Date: Wed, 27 Apr 2016 11:45:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160426171902.GA2558@phenom.ffwll.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Den 26.04.2016 19:19, skrev Daniel Vetter: > On Tue, Apr 26, 2016 at 06:24:54PM +0200, Noralf Trønnes wrote: >> Den 25.04.2016 11:09, skrev Daniel Vetter: >>> On Sun, Apr 24, 2016 at 10:48:58PM +0200, Noralf Trønnes wrote: >>>> This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled. >>>> The fbdev framebuffer changes are flushed using the callback >>>> (struct drm_framebuffer *)->funcs->dirty() by a dedicated worker >>>> ensuring that it always runs in process context. >>>> >>>> Signed-off-by: Noralf Trønnes >>>> --- >>>> >>>> Changes since v1: >>>> - Use a dedicated worker to run the framebuffer flushing like qxl does >>>> - Add parameter descriptions to drm_fb_helper_deferred_io >>>> >>>> drivers/gpu/drm/drm_fb_helper.c | 127 +++++++++++++++++++++++++++++++++++++++- >>>> include/drm/drm_fb_helper.h | 17 ++++++ >>>> 2 files changed, 143 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c >>>> index 855108e..46ee6f8 100644 >>>> --- a/drivers/gpu/drm/drm_fb_helper.c >>>> +++ b/drivers/gpu/drm/drm_fb_helper.c >>>> @@ -40,6 +40,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> >>>> static bool drm_fbdev_emulation = true; >>>> module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600); >>>> @@ -48,6 +49,10 @@ MODULE_PARM_DESC(fbdev_emulation, >>>> >>>> static LIST_HEAD(kernel_fb_helper_list); >>>> >>>> +static void drm_fb_helper_dirty_init(struct drm_fb_helper *helper); >>>> +static void drm_fb_helper_dirty(struct fb_info *info, u32 x, u32 y, >>>> + u32 width, u32 height); >>>> + >>>> /** >>>> * DOC: fbdev helpers >>>> * >>>> @@ -84,6 +89,16 @@ static LIST_HEAD(kernel_fb_helper_list); >>>> * and set up an initial configuration using the detected hardware, drivers >>>> * should call drm_fb_helper_single_add_all_connectors() followed by >>>> * drm_fb_helper_initial_config(). >>>> + * >>>> + * If CONFIG_FB_DEFERRED_IO is enabled and >>>> + * (struct drm_framebuffer *)->funcs->dirty is set, the >>>> + * drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit} functions >>>> + * will accumulate changes and schedule (struct fb_helper).dirty_work to run >>>> + * right away. This worker then calls the dirty() function ensuring that it >>>> + * will always run in process context since the fb_*() function could be >>>> + * running in atomic context. If drm_fb_helper_deferred_io() is used as the >>>> + * deferred_io callback it will also schedule dirty_work with the damage >>>> + * collected from the mmap page writes. >>> One thing to consider (and personally I don't care either way) is whether >>> we shouldn't just select CONFIG_FB_DEFERRED_IO if the fbdev helpers are >>> enabled. Pushing that out to drivers is imo a bit fragile. >>> >>> But like I said I'm ok with either way. >> My concern was adding code and data that only a few drivers would >> actually use. But of course there's the tradeoff with complexity. >> I use this to enable it: >> select FB_DEFERRED_IO if DRM_KMS_FB_HELPER >> >> I guess the maintainer has to make this choice between size and complexity >> :-) >> I can enable it by default if you want, drm is both huge and complex so I >> don't know what's best. >> >> As a sidenote, I have also put all the fbdev code in a file of it's own to >> make it simple with regards to the DRM_FBDEV_EMULATION user option: >> tinydrm-$(CONFIG_DRM_KMS_FB_HELPER) += tinydrm-fbdev.o > Ok, if you ask maintainers then please nuke the #ifdef from .c files. If > you select CONFIG_DRM_KMS_FB_HELPER, then you get hdmi, edid, dp aux, dp > mst and whatever else helpers, even if you don't need them. Adding 3 > functions for defio when you select fbdev helpers and maybe don't need > them is totally harmless. And removing the #ifdef will look so much better > ;-) Will do :-) Kernel development is just my hobby so I'm not well versed in all of this. >>>> */ >>>> >>>> /** >>>> @@ -401,11 +416,14 @@ backoff: >>>> static int restore_fbdev_mode(struct drm_fb_helper *fb_helper) >>>> { >>>> struct drm_device *dev = fb_helper->dev; >>>> + struct fb_info *info = fb_helper->fbdev; >>>> struct drm_plane *plane; >>>> int i; >>>> >>>> drm_warn_on_modeset_not_all_locked(dev); >>>> >>>> + drm_fb_helper_dirty(info, 0, 0, info->var.xres, info->var.yres); >>> Why is this needed? If you do a modeset (or pageflip or whatever) drivers >>> are supposed to re-upload the entire screen. We've talked about adding a >>> dirty rectangle to atomic to allow userspace to optimize this, but there >>> should _never_ be a need to do a dirtyfb call around a modeset. Probably >>> just a driver bug in your panel drm drivers? >> Ok, in tinydrm I now set a flag in &drm_simple_display_pipe_funcs >> ->plane_update to indicate that the next dirty() should do the whole >> framebuffer which seems to work fine. >> Should I actually perform the update as well? >> If so I would need to add a worker in tinydrm to do that. > Yes, plane update should always do a full update. Not sure how you get > away with delaying that to ->dirty, maybe modesetting isn't > double-buffering when you don't have a GL that could do glamour. > > ->dirty is _only_ for frontbuffer rendering, not for page-flipping to an > entirely new buffer. In short if someone calls ->dirty on a buffer which > is currently not being displayed than a) they're silly b) drivers should > treat it as a no-op. Maybe we need a helper to do that ... > -Daniel drm_fb_helper will call dirty() as long as there's fbdev activity, so the driver needs to take that into account. For instance fbcon with a blinking cursor will trigger calls even if a buffer has been set up on the drm side. tinydrm checks the fb against the fb set on the plane and if it differs it's a no-op. Noralf.