From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Date: Thu, 04 Dec 2014 09:09:27 +0000 Subject: Re: [PATCHv2 0/4] LS1021A: Add dcfb framebuffer driver support. Message-Id: <548024C7.3060004@ti.com> MIME-Version: 1 Content-Type: multipart/mixed; boundary="mL5BEnnrNRXb4R5hjrHE155ThGAeTR2rP" List-Id: References: <1417598162-40433-1-git-send-email-Li.Xiubo@freescale.com> <4810522.t9QFQYHtHI@wuerfel> <548016D9.6030006@ti.com> In-Reply-To: To: "Li.Xiubo@freescale.com" Cc: Arnd Bergmann , "plagnioj@jcrosoft.com" , "linux-fbdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "shawn.guo@linaro.org" , "alexander.stein@systec-electronic.com" --mL5BEnnrNRXb4R5hjrHE155ThGAeTR2rP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04/12/14 10:30, Li.Xiubo@freescale.com wrote: > Sorry for confusing, it was delayed for other reasons internal. >=20 > I am not familiar about the DRM, and I'd like to know if the DRM driver= will be > support, should I also develop the libdrm too ? Or just coding in kerne= l level ? For simple drm drivers (this looks like it would be a simple one), I don't think there's any need for libdrm support. The generic DRM interfaces should be enough, so just kernel level coding needed. > Is there any Document about how to have /dev/fbX device to use ? There's DRM documentation here: https://www.kernel.org/doc/htmldocs/drm/index.html And many existing drivers to use as examples. The dri-devel list (http://lists.freedesktop.org/mailman/listinfo/dri-devel), which is the mailing list used for DRM development, is active and you probably can get more support from there than from the fbdev list. It should not be a huge effort to write a drm driver for a simple LCD controller like this. I would bet that you can write a working driver in a week. > If possible, I'd like this could be accept for this time. And I will ad= d the DRM > Version later(for developing and testing will take a long time). I'm sorry but "it was delayed for internal reasons" and "our customer needs this driver" are not very good reasons for getting a driver merged to mainline Linux. You can provide your driver to your customer as a separate patch series which they can apply. There should be no conflicts or other issues there, so it should be simple. Tomi --mL5BEnnrNRXb4R5hjrHE155ThGAeTR2rP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUgCTHAAoJEPo9qoy8lh71epsP/3qOMkBzesv84dMaRyVqJi8R GAhluShgPWDoYoCEmsKnbNAr6nCptqxPhrMlQxd+2zn98Ybsnl6Cw19Ofsz6knm5 WDMIzGK0UPWGPziyNpWXoDmQZ6V86790dKbbcxsD7nQUK1AIXBh/pNA8n+yt4wU/ hjyog+JYg+Jb+eLNGSwxGkwoiA6yBhtqOMbaHrk7p+5KsGjeJczUao48N1o+iyn2 fDVwlWt4zrEQBf4xa937v1gOTBJ03esl7tMpNoHys5vaQZocCr01UiGADpMsJWXf ylD4bO6YsJxvovcECDJ5dzOb1gQGJRKr9lFDFqSX7XUq35kjTdD9cyzYedgG6RvD cZBeGr7ksEq7E74lKSgn3xP2yvkSKCVLDzSSpW7chxxLOnIUKPTwWQwIdrPnanc9 S3STM+vtBr5j1CMo1xaragNmFXBH6lbAfnVbrUb1JVGAwEXLdYVlEBZH8hwtG+1A 5VkSkJu9WM+2JO58vcHvGF3Y2GrtgK+emROcwDiqFDh4Mcf5bUJuabjDQBX7slKD z8fhFRKGHlOXLp5nXsMTuvddjoOc3oCNuAAMv46x7jZrzpLTyyOMQyWkxd2QAfWv Nm2jPbMrR3n43sKZ6T075/NkPRA0IzF7UOiQlFk3lPBwTa5hNJsMIIQDibuEuniz yiRqPtRAkF1cxfH51hFa =s4Y2 -----END PGP SIGNATURE----- --mL5BEnnrNRXb4R5hjrHE155ThGAeTR2rP--