exynos-drm registration: infinite loop

[Matwey V. Kornilov]

2014-11-06 11:45 GMT+03:00 Inki Dae <inki.dae at samsung.com>:
> On 2014년 11월 06일 17:03, Andrzej Hajda wrote:
>> On 11/06/2014 07:23 AM, Inki Dae wrote:
>>> On 2014년 11월 05일 23:38, Thierry Reding wrote:
>>>> On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote:
>>>>> Hi,
>>>>>
>>>>> I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have Exynos DRM
>>>>> of course, but I run multi-platform kernel where CONFIG_DRM_EXYNOS is
>>>>> set to 'y'.
>>>>> The issue here is that the platform probe/init goes to infinite loop
>>>>> as the following:
>>>>>
>>>>> [    5.717343] platform exynos-drm: Driver exynos-drm requests probe deferral
>>>>> [    5.726848] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
>>>>> [    5.734700] platform exynos-drm: Driver exynos-drm requests probe deferral
>>>>> [    5.744044] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
>>>>> [    5.752010] platform exynos-drm: Driver exynos-drm requests probe deferral
>>>>> [    5.761377] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
>>>>> [    5.769291] platform exynos-drm: Driver exynos-drm requests probe deferral
>>>>>
>>>>> It is quite unexpectable behavior. I would expect that the exynos-drm
>>>>> failed to initialize with 'no device' error.
>>>>>
>>>>> See also for the reference: https://bugzilla.kernel.org/show_bug.cgi?id=87691
>>>>
>>>> The reason for this seems to be that Exynos DRM instantiates a dummy
>>>> device that it can bind to (see exynos_drm_init()). Now this code is
>>>> executed unconditonally, so the device will be created whether or not
>>>> the kernel/module runs on an Exynos SoC. The driver should really bind
>>>> to some real device rather than instantiating a dummy. Or if it must
>>>> bind to a dummy then the code needs to at least check that it's running
>>>> on an Exynos SoC before instantiating the dummy.
>>>>
>>>
>>> Right, I also think the problem is because we use a dummay device for
>>> Exynos drm. As you mentioned, this device can always be bound as long as
>>> Exynos drm driver is enabled even without real device. So this issue
>>> gives us that we need super device node again. Actually, I had already
>>> tried the use  of the super device node like below for Exynos drm but
>>> other Samsung guys didn't want to use it.
>>>      http://lists.freedesktop.org/archives/dri-devel/2014-April/056618.html
>>>
>>> I think now we have the reason that we should use super device node so I
>>> will try to support the super device for Exynos drm like other ARM drm
>>> drivers did. However, for this, I'd like to listen to other opinions
>>> for a while before that.
>>
>> It is enough to check if there are platform devices compatible with
>> drivers registered by exynos_drm_dev.
>>
>
> Yes, we can do it simply. However, I'm not still clear to handle these
> issues in this manner because if we use the super device which is the
> most generic way then Exynos drm can have real device node so we don't
> need such exception codes anymore. And with the super device, I'm not
> sure whether there are other issues or not we can face but it would be
> enough to consider only generic ways.
>
> Anyway, I will decide how to handle Exynos drm device after listening to
> more other opinions.

However, what is about CONFIG_DRM_EXYNOS = 'm' ?
I suppose that the super device and the appropriate record in dts will
make alias and auto-load work.

>
> Thanks,
> Inki Dae
>
>> Regards
>> Andrzej
>>
>>>
>>> Thanks,
>>> Inki Dae
>>>
>>>> Thierry
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>
>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>>
>



-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2207@jabber.ru