Hi, 2013/10/29 Olof Johansson <olof@xxxxxxxxx>: > On Mon, Oct 28, 2013 at 6:35 AM, Inki Dae <inki.dae@xxxxxxxxxxx> wrote: >> This patch makes callback funtions of each sub driver to be called >> with device object instead of display and manager. >> >> Exynos drm framework doesn't need to pass a manager or a display >> when calling callback function of each sub driver, and each sub >> driver can get its own context from device object. So this patch >> hides sub driver's context from framework. > > This is a step backwards. There should be no need to have every driver > have a full struct device associated with it, so removing the > requirement to have a struct device is the right thing to do (and this > patch undoes that). Did you look into Sean patch set? most patch set is great but some part of that patch set makes us to use tricky codes. So below is my question, 1. Where DT binding of a real device should be done in? in real device driver? or don't care wherever? My answer is that DT binding should be done in real device driver. However, now Sean patch set makes some tricky codes to be used in Exynos drm framework. I'm not sure that you had already looked into the ptn3460 lvds bridge driver but in Sean patch set, DT binding of the ptn3460 driver will be done in Exynos drm framework, not real device driver. Is that reasonable to you? And I guess the reason Sean is trying to pass manager and display into sub driver, is for using the ptn3460 driver including some tricky codes. 2. ARM SoC based DRM driver can be perfect single driver? I think most ARM SoC have separated hw resources so DRM driver for ARM couldn't be a perfect single driver. So ARM based DRM driver includes some separated device drivers, and is just used as a single driver. If you don't think so, Could you remove all stuff related to platform device from KMS drivers? If so, Where DT binding of each KMS driver should be done in? So if ARM based DRM driver cannot be a perfect single driver, and we should use DRM driver including separated device drivers then shouldn't we deal with the rule that other frameworks call some driver's callback with device object, and each device driver sets its own context into driver_data, not manager. If there is my missing something, plese give me your comments. > Sticking to the strict driver model on all display IP on SoCs is > making things overly complicated. Sean is clearly moving the Exynos > DRM in the right direction with his restructuring, so please don't > undo his work like this. Especially not without cc:ing him on the > patches. I think we had have discussions enough about this patch with Sean at other email threads, and In the email threads, I told Sean that I will post fixed patch instead of Sean. Anyway, I missed ccing him. Sorry about that. Thanks, Inki Dae > > > -Olof > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
