From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [RFC 0/5] drm: Add support for tiny LCD displays Date: Wed, 16 Mar 2016 11:26:42 -0700 Message-ID: <87d1qub7od.fsf@eliezer.anholt.net> References: <1458135259-31050-1-git-send-email-noralf@tronnes.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1038307221==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 35AF06E9F5 for ; Wed, 16 Mar 2016 18:26:50 +0000 (UTC) In-Reply-To: <1458135259-31050-1-git-send-email-noralf@tronnes.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Noralf =?utf-8?Q?Tr=C3=B8nnes?= , dri-devel@lists.freedesktop.org Cc: thomas.petazzoni@free-electrons.com List-Id: dri-devel@lists.freedesktop.org --===============1038307221== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Noralf Tr=C3=B8nnes writes: > This is an attempt at providing a DRM version of drivers/staging/fbtft. > I'm sending this early before cleaning up the code hoping to get some > feedback in case there are better ways to structure this. > > The tinydrm module provides a very simplified view of DRM for displays th= at > has onboard video memory and is connected through a slow bus like SPI/I2C. > A driver using tinydrm has to provide a function that will be called from > the dirtyfb ioctl and optionally drm_panel functions which can be used to > set up the display controller and control backlight. > > tinydrm also has fbdev support using fb_deferred_io which is tied in thro= ugh > the dirtyfb function call. A driver can use the provided deferred work co= de > to collect dirtyfb calls and schedule display memory updates if it whishe= s. > The various display controllers can have library modules that handles > display updates. > Display controllers that have a similar register interface as the MIPI DB= I/DCS > controllers can use the lcdreg module for register access. > > struct tinydrm_device { > struct drm_device *base; > u32 width, height; > struct drm_panel panel; > [...] > int (*dirtyfb)(struct drm_framebuffer *fb, void *vmem, unsigned flags, > unsigned color, struct drm_clip_rect *clips, > unsigned num_clips); > }; This is awesome! I was wondering, have you considered what it would take to DMA framebuffer contents from somewhere in memory to these displays? Does that look doable to you? I'd love to be able to do something PRIME-like where vc4's doing the rendering and we're periodically updating the TFT with the result. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJW6aVjAAoJELXWKTbR/J7ojUwQAIoXFyMrLQ98roljEQNjOqat wqMuq3b3/gJ8k10ZugU/r4NwdZ+riC4XrANR3PjewoFfr/ylLsNIOD2eHxDBihaR HkiSKkWBpoJ54kIzvPcHVp6788oGE498h4XrjMHIznbVS/hxpy+DYJvcblr1dgda ZBLefMgKnSacdbuZj8Hq+hG11zfLL+rQIZZPhP6S8cHHf5uJ5Vg2b4tIB5nONTyP RCfGbjT869fsFbyJZ3IQN5JOx23LjKRcY2TBox8rTFO+8oHg1MHnbaf6kLZejuip Bqg9smuiDdP0VRUVnjkKVZ8CI37fN4Euk4lkWLJGOAOOiV82AZrnti8Vo7nHw3tR 9khBlzyAjFTBu5jvAABHa8rsUElZYu+JvvnT1/3+8DztSAwCE5gFQp3qNL0SvXIw PyOGqW3zBqjVOLw/JcqBmP0w+cY/0BvqQ6cB348/oxvrOEXBRwHo2i0QuX8qytDw Lezfgx2NdFUBfwHMVrgVnOfkzG1l0nR67SVRts3dxiaafzY1L2njnNbHnitbJNar KeRWJpiOcaSlD0dySGXbbVWVj0nLYXYoT7eqcYiavFH0XwL+xh+BiTTNJugEWy0/ C1yOAMPj2/aYaO817g9CzqCRYFqJ/iPDx1oTYaC2nITr8m6k8F0eiOp3pGn1zzSM TvtCTq70uJzgCR4I2jee =+y2k -----END PGP SIGNATURE----- --=-=-=-- --===============1038307221== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1038307221==--