From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: -next plans/status Date: Thu, 6 Nov 2014 17:02:45 +0100 Message-ID: <20141106160243.GA14873@ulmo.nvidia.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2036949931==" Return-path: Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by gabe.freedesktop.org (Postfix) with ESMTP id 025376E858 for ; Thu, 6 Nov 2014 08:02:52 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so1505624pab.18 for ; Thu, 06 Nov 2014 08:02:51 -0800 (PST) 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: Dave Airlie Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org --===============2036949931== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 03, 2014 at 08:29:24AM +1000, Dave Airlie wrote: > So since -rc5/6 cutoff last merge windows was so successful from my > POV, I think I'll keep trucking with the idea. >=20 > Things I have on my radar for this window, outside normal driver pull req= uests: >=20 > a) rockchip drm - this needs IOMMU driver merged first so I can even > compile it, on hold but shouldn't be a problem if the iommu driver > gets merged somewhere first. >=20 > b) atmel hlcdc - where are we on the precursor patches for this? >=20 > c) atomic - Daniel seems to have done a good job pulling the helpers > in line, Rob, Sean, Collabora - please jump on board and get this > thing over the line. >=20 > d) Exynos/bridge/make my chromebook work upstream patches, where are > we on these, Ajay/Thierry I believe you are in the know. Daniel briefly looked at this and was somewhat disgusted with how little safety this framework has built in. The infrastructure was copied from DRM panel which therefore suffers from the same shortcomings. I've been working on a small set of patches to implement some generic mechanism to add reference counting and such for this type of infrastructure. Until those patches are ready I think we either can't merge the patches or we take the risk that drivers will actually use the current fragile infrastructure in a safe way and then supply the safer infrastructure later on. Thierry --DocE+STaALJfprDB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUW5ujAAoJEN0jrNd/PrOhNCMQAK5rWcpropWAFyF2Th/gjXxj UEw7kCbVRg0tt7rzI5IegY++qR6SmAYNbQfQ9U5XD5A3rkWqZisB4jLo3htxZIqd G6cOOutLQYerTgD+RQvtF3u12AUcuschwvAqeRsujHUgyBmaSCCwh37RexqgtB9F 8z+a1SHtNBu15T/Fu12l6YXaqC0uOHEUOZmAypsokJr2LyDfbGDV/IXmJy30DhHZ Ace5QQLqp0h27/qrNffUakfSlTfOy5aYH3OVpcwOT6wlI2ABNy0fY4Y3FMGrWLIu tbqS+YdHidc34Sq9LAtLNXi4xAKP/6BR58QzqaFwe7gj9Uz4UOgICyCgLWVXucml KQ3a/9X2d6Bp1BfOSH0FXaTPd9YShoSUCFZSsxNDGwDBGDWFjphBfCPKZ3Fxay79 Rfp+PQJQg3hsU37MMkvdq268UEQ/zDkKmo/rKUiITgYepwFyM5fN3jno5YGzcj/q whY9CqR7VeT6yN4Parhp/WIWOAFJgGA5aJIUVhqUWIGycpOdXl3HuceJorC97IWG dOTcfIzvv9i5gXeO5kB2dEMvW9v4P0J14KUudCY+NcO0GnNwcRf5IecI9OnZ8fsg s5JRVwJj+KLV8af2mGoH/dZBFLRYNA5sFsZB+tHo7VToHOrzY6mE4HU1AiQTQMMF KdFX7NrBebWAEmxCZj/J =7Yvy -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- --===============2036949931== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============2036949931==--