Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

[Stephen Warren]

On 01/07/2013 01:20 AM, Terje BergstrÃm wrote:
> On 04.01.2013 22:25, Stephen Warren wrote:
>> On 01/04/2013 03:09 AM, Terje BergstrÃm wrote:
>> ...
>>> 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
...
>>>  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
>>
>> But that said, I agree this approach would be very reasonable; it seems
>> to me that host1x really is the main HW behind a DRM driver or a V4L2
>> driver or ... As such, it seems quite reasonable for a single struct
>> device to exist that represents host1x, and for the driver for that
>> device to register both a DRM and a V4L2 driver etc. The code could
>> physically be organized into separate modules, and under different
>> Kconfig options for configurability etc.
>>
>> But either way, I'll let you (Thierry and Terje) work out which way to go.
> 
> If we want separate modules, we'd need the dummy device & dummy driver
> binding between them.

I haven't really thought it through, but I don't think so; I was
thinking separate modules more just to allow linking smaller chunks of
code at once rather than allowing optional functionality via loading (or
not) various modules. Hence, simple function calls between the
files/modules. Still, there may well be no need at all to split it into
separate modules.
--
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/