On Wed, Oct 29, 2014 at 10:09:04AM +0100, Andrzej Hajda wrote: > On 10/29/2014 08:58 AM, Daniel Vetter wrote: > > 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 > > > > As I understand you want something generic to look for panels, bridges, > whatever and, like components, it should allow to safe hot plug/unplug. > I have proposed such thing few months ago [1]. Have you looked at it? > > [1]: https://lkml.org/lkml/2014/4/30/345 Yeah I think I've looked but wasn't convinced. I do agree though that we should definitely aim for something in the driver core. Since if Greg doesn't like it it's not suddenly better if we just hide it in the drm subsystem. This really smells like a generic issue - after all we already have a two implementations with bridges&panels already. So maybe we need to augment the component framework with the possibility to add additional devices later on at runtime, or something similar. Not really sure since I don't have actual practice with these issues since i915 doesn't (yet) have these problems. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
