[PATCH 07/36] drm/omap: Init fbdev emulation only when we have displays

[Tomi Valkeinen]

On 30/11/16 15:46, Daniel Vetter wrote:
> On Wed, Nov 30, 2016 at 01:17:09PM +0200, Tomi Valkeinen wrote:
>> From: Peter Ujfalusi <peter.ujfalusi at ti.com>
>>
>> Do not try to init the fbdev if either num_crtcs or num_connectors is 0.
>> In this case we do not have display so the fbdev init would fail anyways.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
>> ---
>>  drivers/gpu/drm/omapdrm/omap_fbdev.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c b/drivers/gpu/drm/omapdrm/omap_fbdev.c
>> index 8d8ac173f55d..2b045262f8ad 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
>> @@ -255,6 +255,9 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device *dev)
>>  	struct drm_fb_helper *helper;
>>  	int ret = 0;
>>  
>> +	if (!priv->num_crtcs || !priv->num_connectors)
>> +		return NULL;
> 
> Thierry Redding had patches to implement this in a generic fashion in the
> fbdev emulation (just wait with fbdev init until the first screen shows
> up). Would be great to polish up that work (I've reviewed the original
> series already) and land it, instead of driver hacks forever.
> 
> https://patchwork.freedesktop.org/patch/91448/

This is not doing the same thing, or at least the point is not the same.

OMAP DSS has writeback support, which can be used in a plain
memory-to-memory mode (not yet in the mainline, though). The need for
this patch came up when people tried to use WB on boards that don't have
any displays.

So this was not about deferred setup but skipping fbdev totally if we
don't have any display outputs.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/c02e482b/attachment.sig>