All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling
@ 2016-08-29  9:50 ` Peter Ujfalusi
  0 siblings, 0 replies; 6+ messages in thread
From: Peter Ujfalusi @ 2016-08-29  9:50 UTC (permalink / raw)
  To: airlied, daniel.vetter
  Cc: dri-devel, linux-kernel, ville.syrjala, tomi.valkeinen

drm_kms_helper_poll_enable_locked() should check if we have delayed event
pending and if we have, schedule the work to run without delay.

Currently the output_poll_work is only scheduled if any of the connectors
have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
already registered to be handled. The detection will be delayd by
DRM_OUTPUT_POLL_PERIOD in any case.
Furthermore if none of the connectors are marked as POLL_CONNECT or
POLL_DISCONNECT because all connectors are either POLL_HPD or they are
always connected: the output_poll_work will not run at all even if we
have delayed event marked.

When none of the connectors require polling, their initial status change
from unknown to connected/disconnected is not going to be handled until
the first kms application starts or if we have fb console enabled.

With this change we can react more quickly to output status changes after
enabling the poll but most importantly it will correct the behavior when
none of the connector have POLL_CONNECT or POLL_DISCONNECT flag set - they
are either POLL_HPD or the .polled is 0. The initial status change is going
to be handled correctly as well.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 drivers/gpu/drm/drm_probe_helper.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index a0df377d7d1c..f6b64d7d3528 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
 {
 	bool poll = false;
 	struct drm_connector *connector;
+	unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
 
 	WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
 
@@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
 			poll = true;
 	}
 
+	if (dev->mode_config.delayed_event) {
+		poll = true;
+		delay = 0;
+	}
+
 	if (poll)
-		schedule_delayed_work(&dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
+		schedule_delayed_work(&dev->mode_config.output_poll_work, delay);
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
 
-- 
2.9.3

^ permalink raw reply related	[flat|nested] 6+ messages in thread
* [PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling
@ 2016-08-29  9:50 ` Peter Ujfalusi
  0 siblings, 0 replies; 6+ messages in thread
From: Peter Ujfalusi @ 2016-08-29  9:50 UTC (permalink / raw)
  To: airlied, daniel.vetter
  Cc: dri-devel, linux-kernel, ville.syrjala, tomi.valkeinen

drm_kms_helper_poll_enable_locked() should check if we have delayed event
pending and if we have, schedule the work to run without delay.

Currently the output_poll_work is only scheduled if any of the connectors
have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
already registered to be handled. The detection will be delayd by
DRM_OUTPUT_POLL_PERIOD in any case.
Furthermore if none of the connectors are marked as POLL_CONNECT or
POLL_DISCONNECT because all connectors are either POLL_HPD or they are
always connected: the output_poll_work will not run at all even if we
have delayed event marked.

When none of the connectors require polling, their initial status change
from unknown to connected/disconnected is not going to be handled until
the first kms application starts or if we have fb console enabled.

With this change we can react more quickly to output status changes after
enabling the poll but most importantly it will correct the behavior when
none of the connector have POLL_CONNECT or POLL_DISCONNECT flag set - they
are either POLL_HPD or the .polled is 0. The initial status change is going
to be handled correctly as well.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 drivers/gpu/drm/drm_probe_helper.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index a0df377d7d1c..f6b64d7d3528 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
 {
 	bool poll = false;
 	struct drm_connector *connector;
+	unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
 
 	WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
 
@@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
 			poll = true;
 	}
 
+	if (dev->mode_config.delayed_event) {
+		poll = true;
+		delay = 0;
+	}
+
 	if (poll)
-		schedule_delayed_work(&dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
+		schedule_delayed_work(&dev->mode_config.output_poll_work, delay);
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
 
-- 
2.9.3

^ permalink raw reply related	[flat|nested] 6+ messages in thread
* Re: [PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling
  2016-08-29  9:50 ` Peter Ujfalusi
@ 2016-08-29 12:58   ` Daniel Vetter
  -1 siblings, 0 replies; 6+ messages in thread
From: Daniel Vetter @ 2016-08-29 12:58 UTC (permalink / raw)
  To: Peter Ujfalusi
  Cc: airlied, daniel.vetter, dri-devel, linux-kernel, ville.syrjala,
	tomi.valkeinen

On Mon, Aug 29, 2016 at 12:50:22PM +0300, Peter Ujfalusi wrote:
> drm_kms_helper_poll_enable_locked() should check if we have delayed event
> pending and if we have, schedule the work to run without delay.
> 
> Currently the output_poll_work is only scheduled if any of the connectors
> have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
> DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
> already registered to be handled. The detection will be delayd by
> DRM_OUTPUT_POLL_PERIOD in any case.
> Furthermore if none of the connectors are marked as POLL_CONNECT or
> POLL_DISCONNECT because all connectors are either POLL_HPD or they are
> always connected: the output_poll_work will not run at all even if we
> have delayed event marked.
> 
> When none of the connectors require polling, their initial status change
> from unknown to connected/disconnected is not going to be handled until
> the first kms application starts or if we have fb console enabled.
> 
> With this change we can react more quickly to output status changes after
> enabling the poll but most importantly it will correct the behavior when
> none of the connector have POLL_CONNECT or POLL_DISCONNECT flag set - they
> are either POLL_HPD or the .polled is 0. The initial status change is going
> to be handled correctly as well.

Don't we need to set delayed_event somewhere too first? At least I don't
really understand how this speeds things up ... The patch itself looks
like a valid bugfix, but the description confuses me a bit. I think if you
delete the above paragraph (starting with "With this change we can react
...") then it's all good.
-Daniel

> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
> index a0df377d7d1c..f6b64d7d3528 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
>  {
>  	bool poll = false;
>  	struct drm_connector *connector;
> +	unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
>  
>  	WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
>  
> @@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
>  			poll = true;
>  	}
>  
> +	if (dev->mode_config.delayed_event) {
> +		poll = true;
> +		delay = 0;
> +	}
> +
>  	if (poll)
> -		schedule_delayed_work(&dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
> +		schedule_delayed_work(&dev->mode_config.output_poll_work, delay);
>  }
>  EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
>  
> -- 
> 2.9.3
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling
@ 2016-08-29 12:58   ` Daniel Vetter
  0 siblings, 0 replies; 6+ messages in thread
From: Daniel Vetter @ 2016-08-29 12:58 UTC (permalink / raw)
  To: Peter Ujfalusi; +Cc: daniel.vetter, linux-kernel, dri-devel, tomi.valkeinen

On Mon, Aug 29, 2016 at 12:50:22PM +0300, Peter Ujfalusi wrote:
> drm_kms_helper_poll_enable_locked() should check if we have delayed event
> pending and if we have, schedule the work to run without delay.
> 
> Currently the output_poll_work is only scheduled if any of the connectors
> have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
> DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
> already registered to be handled. The detection will be delayd by
> DRM_OUTPUT_POLL_PERIOD in any case.
> Furthermore if none of the connectors are marked as POLL_CONNECT or
> POLL_DISCONNECT because all connectors are either POLL_HPD or they are
> always connected: the output_poll_work will not run at all even if we
> have delayed event marked.
> 
> When none of the connectors require polling, their initial status change
> from unknown to connected/disconnected is not going to be handled until
> the first kms application starts or if we have fb console enabled.
> 
> With this change we can react more quickly to output status changes after
> enabling the poll but most importantly it will correct the behavior when
> none of the connector have POLL_CONNECT or POLL_DISCONNECT flag set - they
> are either POLL_HPD or the .polled is 0. The initial status change is going
> to be handled correctly as well.

Don't we need to set delayed_event somewhere too first? At least I don't
really understand how this speeds things up ... The patch itself looks
like a valid bugfix, but the description confuses me a bit. I think if you
delete the above paragraph (starting with "With this change we can react
...") then it's all good.
-Daniel

> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
> index a0df377d7d1c..f6b64d7d3528 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
>  {
>  	bool poll = false;
>  	struct drm_connector *connector;
> +	unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
>  
>  	WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
>  
> @@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
>  			poll = true;
>  	}
>  
> +	if (dev->mode_config.delayed_event) {
> +		poll = true;
> +		delay = 0;
> +	}
> +
>  	if (poll)
> -		schedule_delayed_work(&dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
> +		schedule_delayed_work(&dev->mode_config.output_poll_work, delay);
>  }
>  EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
>  
> -- 
> 2.9.3
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling
  2016-08-29 12:58   ` Daniel Vetter
@ 2016-08-29 13:30     ` Peter Ujfalusi
  -1 siblings, 0 replies; 6+ messages in thread
From: Peter Ujfalusi @ 2016-08-29 13:30 UTC (permalink / raw)
  To: airlied, dri-devel, linux-kernel, ville.syrjala, tomi.valkeinen

On 08/29/16 15:58, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 12:50:22PM +0300, Peter Ujfalusi wrote:
>> drm_kms_helper_poll_enable_locked() should check if we have delayed event
>> pending and if we have, schedule the work to run without delay.
>>
>> Currently the output_poll_work is only scheduled if any of the connectors
>> have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
>> DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
>> already registered to be handled. The detection will be delayd by
>> DRM_OUTPUT_POLL_PERIOD in any case.
>> Furthermore if none of the connectors are marked as POLL_CONNECT or
>> POLL_DISCONNECT because all connectors are either POLL_HPD or they are
>> always connected: the output_poll_work will not run at all even if we
>> have delayed event marked.
>>
>> When none of the connectors require polling, their initial status change
>> from unknown to connected/disconnected is not going to be handled until
>> the first kms application starts or if we have fb console enabled.
>>
>> With this change we can react more quickly to output status changes after
>> enabling the poll but most importantly it will correct the behavior when
>> none of the connector have POLL_CONNECT or POLL_DISCONNECT flag set - they
>> are either POLL_HPD or the .polled is 0. The initial status change is going
>> to be handled correctly as well.
> 
> Don't we need to set delayed_event somewhere too first? At least I don't
> really understand how this speeds things up

The delayed_event is set first in the
drm_helper_probe_single_connector_modes_merge_bits() when the force is not set.
The drm_kms_helper_poll_init() is called by drivers when they have their
connectors set up. So when probing the drivers we will first set up the
connectors, they will move from connector_status_unknown to connected or
disconnected and the delayed_event is set.
Later the drm_kms_helper_poll_init() is called and that will schedule the work
with DRM_OUTPUT_POLL_PERIOD. So even if we now know the state of the
connectors, they will be checked by the poll_work when the work is running
with a delay. If we set the delay to 0 the detection will run much faster.

Is this makes more sense?

> ... The patch itself looks
> like a valid bugfix, but the description confuses me a bit. I think if you
> delete the above paragraph (starting with "With this change we can react
> ...") then it's all good.

I can drop the last paragraph.

> -Daniel
> 
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>>  drivers/gpu/drm/drm_probe_helper.c | 8 +++++++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
>> index a0df377d7d1c..f6b64d7d3528 100644
>> --- a/drivers/gpu/drm/drm_probe_helper.c
>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> @@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
>>  {
>>  	bool poll = false;
>>  	struct drm_connector *connector;
>> +	unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
>>  
>>  	WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
>>  
>> @@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
>>  			poll = true;
>>  	}
>>  
>> +	if (dev->mode_config.delayed_event) {
>> +		poll = true;
>> +		delay = 0;
>> +	}
>> +
>>  	if (poll)
>> -		schedule_delayed_work(&dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
>> +		schedule_delayed_work(&dev->mode_config.output_poll_work, delay);
>>  }
>>  EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
>>  
>> -- 
>> 2.9.3
>>
> 


-- 
Péter

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling
@ 2016-08-29 13:30     ` Peter Ujfalusi
  0 siblings, 0 replies; 6+ messages in thread
From: Peter Ujfalusi @ 2016-08-29 13:30 UTC (permalink / raw)
  To: airlied, dri-devel, linux-kernel, ville.syrjala, tomi.valkeinen

On 08/29/16 15:58, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 12:50:22PM +0300, Peter Ujfalusi wrote:
>> drm_kms_helper_poll_enable_locked() should check if we have delayed event
>> pending and if we have, schedule the work to run without delay.
>>
>> Currently the output_poll_work is only scheduled if any of the connectors
>> have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
>> DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
>> already registered to be handled. The detection will be delayd by
>> DRM_OUTPUT_POLL_PERIOD in any case.
>> Furthermore if none of the connectors are marked as POLL_CONNECT or
>> POLL_DISCONNECT because all connectors are either POLL_HPD or they are
>> always connected: the output_poll_work will not run at all even if we
>> have delayed event marked.
>>
>> When none of the connectors require polling, their initial status change
>> from unknown to connected/disconnected is not going to be handled until
>> the first kms application starts or if we have fb console enabled.
>>
>> With this change we can react more quickly to output status changes after
>> enabling the poll but most importantly it will correct the behavior when
>> none of the connector have POLL_CONNECT or POLL_DISCONNECT flag set - they
>> are either POLL_HPD or the .polled is 0. The initial status change is going
>> to be handled correctly as well.
> 
> Don't we need to set delayed_event somewhere too first? At least I don't
> really understand how this speeds things up

The delayed_event is set first in the
drm_helper_probe_single_connector_modes_merge_bits() when the force is not set.
The drm_kms_helper_poll_init() is called by drivers when they have their
connectors set up. So when probing the drivers we will first set up the
connectors, they will move from connector_status_unknown to connected or
disconnected and the delayed_event is set.
Later the drm_kms_helper_poll_init() is called and that will schedule the work
with DRM_OUTPUT_POLL_PERIOD. So even if we now know the state of the
connectors, they will be checked by the poll_work when the work is running
with a delay. If we set the delay to 0 the detection will run much faster.

Is this makes more sense?

> ... The patch itself looks
> like a valid bugfix, but the description confuses me a bit. I think if you
> delete the above paragraph (starting with "With this change we can react
> ...") then it's all good.

I can drop the last paragraph.

> -Daniel
> 
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>>  drivers/gpu/drm/drm_probe_helper.c | 8 +++++++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
>> index a0df377d7d1c..f6b64d7d3528 100644
>> --- a/drivers/gpu/drm/drm_probe_helper.c
>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> @@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
>>  {
>>  	bool poll = false;
>>  	struct drm_connector *connector;
>> +	unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
>>  
>>  	WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
>>  
>> @@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
>>  			poll = true;
>>  	}
>>  
>> +	if (dev->mode_config.delayed_event) {
>> +		poll = true;
>> +		delay = 0;
>> +	}
>> +
>>  	if (poll)
>> -		schedule_delayed_work(&dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
>> +		schedule_delayed_work(&dev->mode_config.output_poll_work, delay);
>>  }
>>  EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
>>  
>> -- 
>> 2.9.3
>>
> 


-- 
Péter

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-08-29 13:30 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-29  9:50 [PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling Peter Ujfalusi
2016-08-29  9:50 ` Peter Ujfalusi
2016-08-29 12:58 ` Daniel Vetter
2016-08-29 12:58   ` Daniel Vetter
2016-08-29 13:30   ` Peter Ujfalusi
2016-08-29 13:30     ` Peter Ujfalusi

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.