Re: [PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge

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

 



On Tue, Oct 28, 2014 at 04:05:34PM +0100, Thierry Reding wrote:
> On Tue, Oct 28, 2014 at 08:16:44PM +0530, Ajay kumar wrote:
> > On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding
> > <thierry.reding@xxxxxxxxx> wrote:
> > > On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote:
> > >> On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar <ajaynumb@xxxxxxxxx> wrote:
> > >> > On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter <daniel@xxxxxxxx> wrote:
> > > [...]
> > >> >> Hm, if you do this can you pls also update drm_panel accordingly? It
> > >> >> shouldn't be a lot of fuzz and would make things around drm+dt more
> > >> >> consistent.
> > >> > Are you talking about using struct device_node instead of struct device?
> > >> > I guess you have misplaced the comment under the wrong section!
> > >>
> > >> Yeah, that should have been one up ;-)
> > >
> > > Like I said earlier, I don't think dropping struct device * in favour of
> > > struct device_node * is a good idea.
> > I am not sure about drm_panel.
> > But, I am not really doing anything with the struct device pointer in
> > case of bridge.
> > So, just wondering if it is really needed?
> 
> I think it's useful to have it just to send the right message. DRM panel
> and DRM bridge aren't specific to device tree. They are completely
> generic and can work with any type of device, whether it was
> instantiated from the device tree or some other infrastructure. Dropping
> struct device * will make it effectively useless on anything but DT. I
> don't think we should strive for that, even if only DT-enabled platforms
> currently use them.

See my other reply, but I now think we should put neither into drm
structures. This "find me the driver structures for this device" problem
looks really generic, and it has nothing to do with the drm structures and
concepts like bridges/panels at all. It shouldn't be in there at all.

Adding it looks very much like reintroducing the drm midlayer that we just
finally made obsolete, just not at the top-level (struct drm_device) but
at a bunch of leaf nodes. I expect all the same issues though. And I'm
definitely not looking to de-midlayer more stuff that we're just adding.

Imo this should be solved as a separate helper thing, maybe in the driver
core akin to the component helpers from Russell.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  Powered by Linux