exynos-drm registration: infinite loop

2014-11-06 Thread Inki Dae
On 2014년 11월 06일 18:29, Thierry Reding wrote:
> On Thu, Nov 06, 2014 at 03:23:27PM +0900, 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.
> 
> Irrespective of any long-term solution you need to fix this as soon as
> possible because this currently causes all sorts of weirdness when
> booting a multi-platform kernel on non-Exynos boards. Probably the
> easiest for now would be to add some soc_is_exynos*() check at the very
> beginning of exynos_drm_init().

Got it.

Thanks,
Inki Dae

> 
> Thierry
> 



exynos-drm registration: infinite loop

2014-11-06 Thread Inki Dae
On 2014년 11월 06일 17:49, Matwey V. Kornilov wrote:
> 2014-11-06 11:45 GMT+03:00 Inki Dae :
>> 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.

I'm not sure what is your concern but with the super device, Exynos drm
driver will also support legacy way so it would have no any dt broken.
And I think now the auto-load already works well so any problem wouldn't
be incurred with the super device. Is there my missing something ?

Thanks,
Inki Dae

> 
>>
>> 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

>>>
>>>
>>
> 
> 
> 



exynos-drm registration: infinite loop

2014-11-06 Thread Inki Dae
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.

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
>>
> 
> 



exynos-drm registration: infinite loop

2014-11-06 Thread Inki Dae
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.

Thanks,
Inki Dae

> Thierry
> 
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 



exynos-drm registration: infinite loop

2014-11-06 Thread Inki Dae

Hi,

On 2014년 11월 05일 02:18, 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
> 


I will check and resolve this issue soon. It seems that there is
something we missed.

Thanks,
Inki Dae



exynos-drm registration: infinite loop

2014-11-06 Thread Matwey V. Kornilov
2014-11-06 11:45 GMT+03:00 Inki Dae :
> 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 at jabber.ru


exynos-drm registration: infinite loop

2014-11-06 Thread Thierry Reding
On Thu, Nov 06, 2014 at 03:23:27PM +0900, 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.

Irrespective of any long-term solution you need to fix this as soon as
possible because this currently causes all sorts of weirdness when
booting a multi-platform kernel on non-Exynos boards. Probably the
easiest for now would be to add some soc_is_exynos*() check at the very
beginning of exynos_drm_init().

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 



exynos-drm registration: infinite loop

2014-11-06 Thread Andrzej Hajda
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.

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
> 



exynos-drm registration: infinite loop

2014-11-05 Thread Matwey V. Kornilov
2014-11-05 17:38 GMT+03:00 Thierry Reding :
> 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.
>
> Thierry

Could it be fixed somehow?

By the way, I am not sure that exynos_drm_match_add behaves correctly.
It returns EPROBE_DEFER when there are no matches, but it doesn't
check (probably can not check) whether all the probes have been run.

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


exynos-drm registration: infinite loop

2014-11-05 Thread Thierry Reding
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.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 



exynos-drm registration: infinite loop

2014-11-04 Thread Matwey V. Kornilov
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