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

[Inki Dae]

Hi Dave,


2013/10/29 Dave Airlie <airlied at gmail.com>:
> On Tue, Oct 29, 2013 at 12:56 PM, Inki Dae <inki.dae at samsung.com> wrote:
>> 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.
>>
>
> I talked with a lot of people last week at Kernel Summit and I'll send
> a summary of it really soon,
>
> I think we should move exynos in that direction, but I'll just point out below,
>> 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.
>
> There is no need to bind a Linux device to each DT node, having a separate
> device driver per-DT node isn't a requirement and tying the Linux device model
> so closely to the DT binding is a bad idea. For something like exynos (also imx,
> msm etc) we have a very specific set of IP blocks per SoC and a single driver
> that just enumerates what blocks are required using DT and gets the
> configuration
> information for the blocks from DT without binding should be fine.
>
> So if you have off-chip blocks that are separable then we would
> possibly do bindings

Yes, We have no the off-chip blocks.

> to DT nodes, but it isn't essential. So I'd like to move away from the
> 1:1 DT node/driver
> model as it seriously over complicates things. We have agreed we
> should possibly add
> a display virtual node in the DT bindings for a single driver to use
> as a binding point.

Got it and thanks you for comments. The display virtual node seems
similar to super node posted by Russell King so just my concern is
that the display virtual node can be accepted by device tree people.
Anyway, I'll remove this patch. I really wish that the display virtual
node can lead us to more perfect world.

Thanks,
Inki Dae

>
>
>> 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.
>>
> I'll follow up later, but yes a single driver is what we should aim for in
> cases where the blocks are quite coherent and all from a single source.
>
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel