From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: Multiple issues with omapdrm Date: Wed, 5 Jun 2013 15:16:04 +0300 Message-ID: <51AF2C04.9010406@ti.com> References: <51AEFDEF.7060602@ti.com> <51AF2282.9000004@ti.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1887005824==" Return-path: Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by gabe.freedesktop.org (Postfix) with ESMTP id 2AAC6E5C37 for ; Wed, 5 Jun 2013 05:16:07 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Rob Clark Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org --===============1887005824== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TSERDGEECISDDMWXQEKB" ------enig2TSERDGEECISDDMWXQEKB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05/06/13 14:52, Rob Clark wrote: > On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen = wrote: >> On 05/06/13 13:57, Rob Clark wrote: >> >>> 1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we >>> need to rename the .ko >> >> Has something been changed that broke that? Or was "omapdrm" just a >> badly chosen name from the start? If drmOpen("omapdrm") works now, >> doesn't changing the module name break userspace compatibility? >=20 > it was broken all along, because you need to drmOpen("omap") so the > module should have been called omap.ko from the beginning But it wasn't, so wouldn't changing it break userspace compatibility? Why do you "need" drmOpen("omap")? Is it just a convention to use that kind of name, instead of "omapdrm" style name? >> I had a quick look at libdrm. It calls server_info->load_module() but = I >> couldn't figure out where that call actually goes... >=20 > it's registered from xserver, fyi Ah ok. So in my testing, running without X, there's actually no module loading happening. The test tools print something like "trying to load module omapdrm...success." but I guess that only means that the module is already there. >>> 2) sorting out the modprobe of panel drivers.. although with the >>> current structure of omapdrm+omapdss I can't think of any clean way t= o >>> handle this. I suppose we could do a hack with a bunch of >>> request_module()s >> >> If omapdrm and omapdss were merged, what would be the clean way be? Or= >> did you mean some other structure? >=20 > well, then we'd just build it all into one .ko So you didn't actually mean omapdrm+omapdss, but omapdrm + omapdss + all-the-panel-drivers? And then have some kind of forced method to probe the panels at omapdrm start? That would be quite a horrible solution, in my opinion =3D). It would als= o be even worse when we get platform independent panel drivers, as all the drm drivers using those panel drivers would include all the panel drivers= =2E >> I'm no expert on this, but my understanding is that udev (or such) >> should load the modules for the devices that the board has. If it's a >> requirement that the drm drivers are loaded only by a call to drmOpen(= ) >> (why is that?), then maybe udev could load only the panel drivers. >=20 > I'm not quite sure the entire history offhand.. maybe drmOpen() > pre-dated that? At any rate, the main issue is just ensuring the > panel modules (if they are split out into different .ko's) are loaded > first I think there should be a core display facility in the kernel to which the panel drivers register the displays in probe(). At boot time udev would go through /sys, find the panel devices somehow (how? modalias is probably somehow involved..), and load their respective modules. Later, when X is started, omapdrm and omapdss are loaded, and at that point all the panels are already there. Tomi ------enig2TSERDGEECISDDMWXQEKB 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.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRrywEAAoJEPo9qoy8lh71jZ0P/RcgTp/+Mm77dQJOyj6NS93m Azi33kzHRFIGPNekAV5I0AIEwjnSrwgQckAYozGgxaflzaUyeX8IWeDKekqJ66Mi +GCWs/b7sVWffZB2gC6DbLMP4rQETKL2eOpf0c5oiMeGK1qB9lJopnFKKIpTkWN4 4OnPDohNK26VmNZNEEOt+kcn4MdUGAxQ93io97n0m8F7P3PasfSiLcqplwRRSSIe 98FgsvJZlLycaLvkT0bYAULXOt3JOE/yXkjDuOTV8/v4MjqnNodaw5rrfu/cJKD2 RaqzGFC02yXPEWG7LygOGLpufQ8YqXJsDd5+mjDfP19H8FnaWoe9WrYqD9u7aItn dbA39i30DpK6Bi1sswrY9YZIr/jV5GcLc6TBdyfm9uY0H6flD24+vAMOHk2SZ6Dj ipCY4FJ0LVJRR+dkUwWCUJlAMikBi/Tv0Do9SDUpv2al6D/PjTR0oTVFBYXnjvDZ IF2wRMc6B4PiiH5+2qAg/5qms3871WYFxdDP8oT3iopyxtLxpqezcQeLFe1tOwvu tEiFCOHTI9VyHZwvtoxbYrty9Bt/NLXnHlMJjVewF2sZgiS4zbgbdJVMr7RhMtxL 4wI9/fD2yNmRnx+u4NEXi3fv2IOrjahv0H70A6ID3GXVKeJhj/Jkn4Rode9fcvua 4jbxZnNxTAPxBQgldzQ8 =0K8c -----END PGP SIGNATURE----- ------enig2TSERDGEECISDDMWXQEKB-- --===============1887005824== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1887005824==--