On Thu, Dec 13, 2012 at 10:58:55AM -0700, Stephen Warren wrote:

On 12/13/2012 01:57 AM, Thierry Reding wrote:

quoted

On Thu, Dec 13, 2012 at 10:48:55AM +0200, Terje Bergström wrote:

quoted

On 12.12.2012 18:08, Thierry Reding wrote:

quoted

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