Multiple issues with omapdrm

[Rob Clark]

On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> 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?

it was broken all along, because you need to drmOpen("omap") so the
module should have been called omap.ko from the beginning

> I had a quick look at libdrm. It calls server_info->load_module() but I
> couldn't figure out where that call actually goes...

it's registered from xserver, fyi

>> 2) sorting out the modprobe of panel drivers..  although with the
>> current structure of omapdrm+omapdss I can't think of any clean way to
>> 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?

well, then we'd just build it all into one .ko

> 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.

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

BR,
-R

>  Tomi
>
>