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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: pgpypdUBVBtN0.pgp
Description: PGP signature


[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux