On Thu, Dec 13, 2012 at 10:58:55AM -0700, Stephen Warren wrote:
On 12/13/2012 01:57 AM, Thierry Reding wrote:
On Thu, Dec 13, 2012 at 10:48:55AM +0200, Terje Bergström wrote:
On 12.12.2012 18:08, Thierry Reding wrote:
I've briefly discussed this with Stephen on IRC because I thought I had remembered him objecting to the idea of adding a dummy device just for this purpose. It turns out, however, that what he didn't like was to add a dummy node to the DT just to make this happen, but he has no (strong) objections to a dummy platform device.
While I'm not very happy about that solution, I've been going over it for a week now and haven't come up with any better alternative that doesn't have its own disadvantages. So perhaps we should go ahead and implement that. For the host1x driver this really just means creating a platform device and adding it to the system, with some of the fields tweaked to make things work.
Even the virtual device is not too beautiful. The problem is that the virtual device is not physical parent for DC, HDMI, etc, so dev_get_drvdata(pdev->dev.parent) returns the data from host1x device, not the virtual device.
We'll post with something that goes around this, but it's not going to be too pretty. Let's try to find the solution once we get the code out.
After some more discussion with Stephen on IRC we came to the conclusion that the easiest might be to have tegra-drm call into host1x with something like:
void host1x_set_drm_device(struct host1x *host1x, struct device *dev);
If host1x is registering the dummy device that causes tegradrm to be instantiated, then presumably there's no need for the API above, since host1x will already have the struct device * for tegradrm, since it created it?
Right, that won't be necessary of course. As long as the driver-private data of the device stays NULL until tegra-drm is ready (has finished probing) just getting the struct device from the clients and looking at that should be enough.
Thierry