On 21.12.2012 23:19, Stephen Warren wrote:
I see the situation more like:
There's host1x hardware.
There's a low-level driver just for host1x itself; the host1x driver.
There's a high-level driver for the entire host1x complex of devices.
That is tegradrm. There may be more high-level drivers in the future (e.g. v4l2 camera driver if it needs to aggregate a bunch of host1x sub-devices liek tegradrm does).
- The presence of the host1x DT node logically implies that both the two
drivers in the previous two points should be instantiated.
Linux instantiates a single device per DT node.
So, it's host1x's responsibility to instantiate the other device(s). I
think it's reasonable for the host1x driver to know exactly what features the host1x HW complex supports; raw host1x access being one, and the higher level concept of a tegradrm being another. So, it's reasonable for host1x to trigger the instantiation of tegradrm.
- If DRM core didn't stomp on the device object's drvdata (or whichever
field it is), I would recommend not creating a dummy device at all, but rather having the host1x driver directly implement multiple driver interfaces. There are many examples like this already in the kernel, e.g. combined GPIO+IRQ driver, combined GPIO+IRQ+pinctrl driver, etc.
We had a phone call with Stephen yesterday, and I finally understood why unbroken chain from DT to tegra-drm is important. The goals are to be able to modprobe tegra-drm without ill effects, and to auto-load tegra-drm module. I had been chasing a totally different goal.
Sorry about all the churn.
I think we have now two ways to go forward with cons and pros: 1) Keep host1x and tegra-drm as separate driver + Code almost done - we need dummy device and dummy driver - extra code and API when host1x creates dummy device and its passed to tegra-drm - tegra-drm device would need to be a child of host1x device. Having virtual and real devices as host1x children sounds weird.
2) Merge host1x and tegra-drm into one module. drm is a subcomponent, and whatever other personalities we wish would also be subcomponents of host1x. host1x calls tegra-drm directly to handle preparation for drm initialization. As they're in the same module, circular dependency is ok. + Simpler conceptually (no dummy device/driver) + Less code - Proposal doesn't yet exist
Thierry, what do you think? I'd prefer option 2, as that keeps things simple and still fulfills the requirements. We probably would redo the patch "Remove redundant host1x" to actually move drm under host1x, and adds calls from host1x to parse_dt() directly. We'd probably leave the code otherwise mostly as it is now, so we'll drop whatever modifications we've done so far in my proposals. You can later pick up some things from our proposals if you want, but it's then up to you.
We could also later think about generalizing some of the list management to belong to host1x, but that'd be a follow-up and we can decide that later.
Terje