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

Thierry Reding thierry.reding at avionic-design.de
Tue Jan 15 03:30:49 PST 2013


On Fri, Jan 04, 2013 at 01:25:06PM -0700, 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
> 
> Just to play devil's advocate:
> 
> I suspect that's only a few lines of code.
> 
> >    - tegra-drm device would need to be a child of host1x device. Having
> > virtual and real devices as host1x children sounds weird.
> 
> And I doubt that would cause problems.
> 
> >  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.

Sorry for not getting back to you on this earlier. I just remembered
this thread when I saw Terje's latest patch series.

I agree that having everything in one location will make things a lot
easier, even if it means we have to add the tegra-drm driver to a new
location. In the long run I think this will pay off, though.

That said, I see that Terje has chosen this approach in his latest
series, so it's all good.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130115/8ecb3af9/attachment.pgp>


More information about the dri-devel mailing list