drm/exynos: change callback argument of sub driver with device

[Inki Dae]

Hi,

2013/10/29 Olof Johansson <olof at lixom.net>:
> On Mon, Oct 28, 2013 at 6:35 AM, Inki Dae <inki.dae at samsung.com> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel