On Wed, Dec 5, 2012 at 2:28 PM, Thierry Reding
[off-list ref] wrote:

quoted

Imo that's worse, since now drm manages even more of the driver->hw
binding process. In my dream world the drm driver just registers a
normal driver at module load time directly with whatever bus it's
interested in, and then, from it the bus' ->probe callback setups up
the entire driver, calling down into drm to setup up interfaces to
userspace (dev node, sysfs, and whatever is required to implement the
ioctls) and uses the various helper libraries provided. So host1x
providing a virtual device that tegradrm can match sounds much better
(if that helps in decoupling from host1x).

Okay, now I see where you're going. You want to replace the various
drm_*_init() functions with something more fine-grained that does the
initialization manually in each driver. Is that it? The obvious
disadvantage is that a lot of code would have to be duplicated, though
that can presumably be factored out into further helpers if necessary.

On that note, I just noticed that drm_platform_init() actually binds a
single platform_device to the drm_driver, which isn't going to work very
well in case there are two devices that want to use the same driver. It
would be nice to get rid of that limitation as well while at it.

Yeah, it's the lack of generality that irks me, and writing driver
init code is one giant sequence of setup function calls anyway -
sprinkling 1-2 more doesn't really matter, but helps a lot if it
results in the driver being in full control (e.g. if you need to
reorder due to some special requirement, that's much easier to do then
than with the current hoop-jumping). But like I've said, a bit a
bigger fish to fry, just wanted to point you into that direction ...

quoted

Or simply call the tegradrm setup from host1x directly, creating a
depency on the tegradrm module. When trying to unload host1x it can
then also call down into tegradrm to tear down the drm device.
Afterwards you should be able to unload tegradrm without fuzz. And if
the hard dependcy is an issue for other host1x clients this
setup/teardown could be wrapped into an #ifdef CONFIG_TEGRADRM.

This is what I originally proposed. However, since tegra-drm will need
to call functions provided by host1x we have a cyclic dependency.
Wouldn't that prevent either module from being unloaded?

You could pass down a host1x interface struct with a vtable to
tegradrm (plus some static inline helpers to make those not a pain to
call). The other possibility (and I'm not proud at all of that code)
which we've used in the intel-ips driver is to use symbol_get at
runtime - but there the requirement was explicitly that intel-ips
needs to work on server systems without the drm/i915 driver loaded,
but still always have the support for interacting with it compiled in
(to make distros happy). It's all rather awkward though ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch