Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
From: Terje BergstrÃm
Date: Tue Dec 18 2012 - 01:33:05 EST
On 17.12.2012 22:55, Stephen Warren wrote:
> On 12/16/2012 09:37 AM, Terje BergstrÃm wrote:
> ...
>> ... Sure we could tell DC to ask its parent
>> (host1x), and call host1x driver with platform_device pointer found that
>> way, and host1x would return a pointer to tegradrm's data. Hanging the
>> data onto host1x driver is just a more complicated way of implementing
>> global data
>
> No it's not; at that point, the data is no longer global, but specific
> to the driver instance.
We have only one tegradrm, so the advantage is theoretical - the one
driver gets the same pointer in both cases.
If we use static pointer with an accessor function, we can keep the
solution contained to one source code file and the ownership of data is
clear - tegradrm allocates and deallocates the object and is the sole
user. Code is already in the patchset I sent.
Shared responsibility with host1x and tegradrm would work probably
something like this:
tegradrm creates an object, and passes the reference to host1x
(host1x_set_drm_pdata(host1x_platform_dev, object). host1x sets the
pdata to a member in struct host1x. A getter host1x_get_drm_pdata()
allows retrieving the object. DC would call it with
"host1x_get_drm_pdata(to_platform_device(pdev->dev.parent))".
This assumes that tegradrm would keep ownership of the data and free it
before host1x gets unloaded.
To me this sounds like a steep price and I fail to see the advantage.
Dummy device is something that would come then on top of this mechanism.
Terje
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/