mbox series

[RFC,0/2] drm/msm/dp: refactor the msm dp driver resources

Message ID 20230223135635.30659-1-quic_sbillaka@quicinc.com (mailing list archive)
Headers show
Series drm/msm/dp: refactor the msm dp driver resources | expand

Message

Sankeerth Billakanti (QUIC) Feb. 23, 2023, 1:56 p.m. UTC
The DP driver resources are currently enabled and disabled directly based on code flow.
As mentioned in bug 230631602, we want to do the following:

1) Refactor the dp/edp parsing code to move it to probe (it is currently done in bind).

2) Then bind all the power resources needed for AUX in pm_runtime_ops.

3) Handle EPROBE_DEFER cases of the panel-eDP aux device.

4) Verify DP functionality is unaffected.

These code changes will parse the resources and get the edp panel during probe.
All the necessary resources required for the aux transactions are moved to pm_runtime ops.
They are enabled or disabled via get/put sync functions.

This is a RFC to verify with the community if the approach we are taking is correct.

https://partnerissuetracker.corp.google.com/issues/230631602

Sankeerth Billakanti (2):
  drm/msm/dp: enumerate edp panel during driver probe
  drm/msm/dp: enable pm_runtime support for dp driver

 drivers/gpu/drm/msm/dp/dp_aux.c     | 155 +++++++++++++++++++++--
 drivers/gpu/drm/msm/dp/dp_catalog.c |  12 ++
 drivers/gpu/drm/msm/dp/dp_catalog.h |   1 +
 drivers/gpu/drm/msm/dp/dp_display.c | 185 ++++++++++++++--------------
 drivers/gpu/drm/msm/dp/dp_power.c   |   7 --
 5 files changed, 250 insertions(+), 110 deletions(-)

Comments

Dmitry Baryshkov Feb. 23, 2023, 3:18 p.m. UTC | #1
On Thu, 23 Feb 2023 at 15:57, Sankeerth Billakanti
<quic_sbillaka@quicinc.com> wrote:
>
> The DP driver resources are currently enabled and disabled directly based on code flow.
> As mentioned in bug 230631602, we want to do the following:

private bug tracker

>
> 1) Refactor the dp/edp parsing code to move it to probe (it is currently done in bind).

This is good. I'd suggest splitting this into smaller chunks. First,
move all resource binding, then move the actual dp_aux handling. It
would be easier to review it this way.

> 2) Then bind all the power resources needed for AUX in pm_runtime_ops.
>
> 3) Handle EPROBE_DEFER cases of the panel-eDP aux device.

This is not handled properly. The eDP aux probing is asynchronous, so
you should move the second stage into the done_probing() part, rather
than relying on the -EPROBE_DEFER. There can be cases, when the panel
driver is not available at the DP's probe time. In such cases we
should leave the DP driver probed, then wait for the panel before
binding the component.

> 4) Verify DP functionality is unaffected.
>
> These code changes will parse the resources and get the edp panel during probe.
> All the necessary resources required for the aux transactions are moved to pm_runtime ops.
> They are enabled or disabled via get/put sync functions.
>
> This is a RFC to verify with the community if the approach we are taking is correct.
>
> https://partnerissuetracker.corp.google.com/issues/230631602

This link is useless, since its contents are not public.

>
> Sankeerth Billakanti (2):
>   drm/msm/dp: enumerate edp panel during driver probe
>   drm/msm/dp: enable pm_runtime support for dp driver
>
>  drivers/gpu/drm/msm/dp/dp_aux.c     | 155 +++++++++++++++++++++--
>  drivers/gpu/drm/msm/dp/dp_catalog.c |  12 ++
>  drivers/gpu/drm/msm/dp/dp_catalog.h |   1 +
>  drivers/gpu/drm/msm/dp/dp_display.c | 185 ++++++++++++++--------------
>  drivers/gpu/drm/msm/dp/dp_power.c   |   7 --
>  5 files changed, 250 insertions(+), 110 deletions(-)
>
> --
> 2.39.0
>
Sankeerth Billakanti (QUIC) March 1, 2023, 8:17 a.m. UTC | #2
>> The DP driver resources are currently enabled and disabled directly based
>on code flow.
>> As mentioned in bug 230631602, we want to do the following:
>
>private bug tracker
>

Will remove the reference for this.

>>
>> 1) Refactor the dp/edp parsing code to move it to probe (it is currently done
>in bind).
>
>This is good. I'd suggest splitting this into smaller chunks. First, move all
>resource binding, then move the actual dp_aux handling. It would be easier to
>review it this way.
>

Okay, will move the resource binding patch first.

>> 2) Then bind all the power resources needed for AUX in pm_runtime_ops.
>>
>> 3) Handle EPROBE_DEFER cases of the panel-eDP aux device.
>
>This is not handled properly. The eDP aux probing is asynchronous, so you
>should move the second stage into the done_probing() part, rather than
>relying on the -EPROBE_DEFER. There can be cases, when the panel driver is
>not available at the DP's probe time. In such cases we should leave the DP
>driver probed, then wait for the panel before binding the component.
>

Okay, I will explore this.

>> 4) Verify DP functionality is unaffected.
>>
>> These code changes will parse the resources and get the edp panel during
>probe.
>> All the necessary resources required for the aux transactions are moved to
>pm_runtime ops.
>> They are enabled or disabled via get/put sync functions.
>>
>> This is a RFC to verify with the community if the approach we are taking is
>correct.
>>
>> https://partnerissuetracker.corp.google.com/issues/230631602
>
>This link is useless, since its contents are not public.
>


Okay, I will remove it.

>>
>> Sankeerth Billakanti (2):
>>   drm/msm/dp: enumerate edp panel during driver probe
>>   drm/msm/dp: enable pm_runtime support for dp driver
>>
>>  drivers/gpu/drm/msm/dp/dp_aux.c     | 155 +++++++++++++++++++++--
>>  drivers/gpu/drm/msm/dp/dp_catalog.c |  12 ++
>>  drivers/gpu/drm/msm/dp/dp_catalog.h |   1 +
>>  drivers/gpu/drm/msm/dp/dp_display.c | 185 ++++++++++++++--------------
>>  drivers/gpu/drm/msm/dp/dp_power.c   |   7 --
>>  5 files changed, 250 insertions(+), 110 deletions(-)
>>
>> --
>> 2.39.0
>>
>
>
>--
>With best wishes
>Dmitry