diff mbox series

[v6,5/8] drm/msm/dp: prevent multiple votes for dp resources

Message ID 1648656179-10347-6-git-send-email-quic_sbillaka@quicinc.com (mailing list archive)
State New, archived
Headers show
Series Add support for the eDP panel over aux_bus | expand

Commit Message

Sankeerth Billakanti (QUIC) March 30, 2022, 4:02 p.m. UTC
The aux_bus support with the dp_display driver will enable the dp
resources during msm_dp_modeset_init. The host_init has to return early
if the core is already initialized to prevent putting an additional vote
for the dp controller resources.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/msm/dp/dp_display.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

Comments

Doug Anderson March 31, 2022, 11:23 p.m. UTC | #1
Hi,

On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
<quic_sbillaka@quicinc.com> wrote:
>
> The aux_bus support with the dp_display driver will enable the dp
> resources during msm_dp_modeset_init. The host_init has to return early
> if the core is already initialized to prevent putting an additional vote
> for the dp controller resources.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>  drivers/gpu/drm/msm/dp/dp_display.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)

I'm not a huge fan of this but I'll leave it up to Dmitry. In general
it feels like there should be _a_ place that enables these resources.
Checks like this make it feel like we just scattershot enabling
resources in a bunch of random places instead of coming up with the
design for enabling them in the right place.

In any case, if we do end up landing this patch, it sure feels like it
needs to move earlier in the patch series, right? This patch shouldn't
hurt even without the other patches in the series but if you apply the
earlier patches in the series without this one then you'll have a bug,
right? That means this needs to come earlier.

-Doug
Dmitry Baryshkov April 8, 2022, 4:14 p.m. UTC | #2
On 01/04/2022 02:23, Doug Anderson wrote:
> Hi,
> 
> On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
> <quic_sbillaka@quicinc.com> wrote:
>>
>> The aux_bus support with the dp_display driver will enable the dp
>> resources during msm_dp_modeset_init. The host_init has to return early
>> if the core is already initialized to prevent putting an additional vote
>> for the dp controller resources.
>>
>> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
>> ---
>>   drivers/gpu/drm/msm/dp/dp_display.c | 10 ++++++++++
>>   1 file changed, 10 insertions(+)
> 
> I'm not a huge fan of this but I'll leave it up to Dmitry. In general
> it feels like there should be _a_ place that enables these resources.
> Checks like this make it feel like we just scattershot enabling
> resources in a bunch of random places instead of coming up with the
> design for enabling them in the right place.

I'd prefer to see a check for eDP in dp_display_config_hpd(). Or even 
better to see that this function isn't called for eDP at all.

> 
> In any case, if we do end up landing this patch, it sure feels like it
> needs to move earlier in the patch series, right? This patch shouldn't
> hurt even without the other patches in the series but if you apply the
> earlier patches in the series without this one then you'll have a bug,
> right? That means this needs to come earlier.
> 
> -Doug
Sankeerth Billakanti April 8, 2022, 5:12 p.m. UTC | #3
> > On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
> > <quic_sbillaka@quicinc.com> wrote:
> >>
> >> The aux_bus support with the dp_display driver will enable the dp
> >> resources during msm_dp_modeset_init. The host_init has to return
> >> early if the core is already initialized to prevent putting an
> >> additional vote for the dp controller resources.
> >>
> >> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> >> ---
> >>   drivers/gpu/drm/msm/dp/dp_display.c | 10 ++++++++++
> >>   1 file changed, 10 insertions(+)
> >
> > I'm not a huge fan of this but I'll leave it up to Dmitry. In general
> > it feels like there should be _a_ place that enables these resources.
> > Checks like this make it feel like we just scattershot enabling
> > resources in a bunch of random places instead of coming up with the
> > design for enabling them in the right place.
> 
> I'd prefer to see a check for eDP in dp_display_config_hpd(). Or even better
> to see that this function isn't called for eDP at all.
>

This needs to be called when eDP is not using the aux_bus path. If the eDP panel is
given as a separate panel driver, then the resources need to be enabled here.

If we don't want to support eDP without aux_bus, then we can skip this function.
 
> >
> > In any case, if we do end up landing this patch, it sure feels like it
> > needs to move earlier in the patch series, right? This patch shouldn't
> > hurt even without the other patches in the series but if you apply the
> > earlier patches in the series without this one then you'll have a bug,
> > right? That means this needs to come earlier.
> >
> > -Doug
> 
> 
> --
> With best wishes
> Dmitry

Thank you,
Sankeerth
Dmitry Baryshkov April 8, 2022, 6:02 p.m. UTC | #4
On Fri, 8 Apr 2022 at 20:12, Sankeerth Billakanti
<sbillaka@qti.qualcomm.com> wrote:
>
> > > On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
> > > <quic_sbillaka@quicinc.com> wrote:
> > >>
> > >> The aux_bus support with the dp_display driver will enable the dp
> > >> resources during msm_dp_modeset_init. The host_init has to return
> > >> early if the core is already initialized to prevent putting an
> > >> additional vote for the dp controller resources.
> > >>
> > >> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > >> ---
> > >>   drivers/gpu/drm/msm/dp/dp_display.c | 10 ++++++++++
> > >>   1 file changed, 10 insertions(+)
> > >
> > > I'm not a huge fan of this but I'll leave it up to Dmitry. In general
> > > it feels like there should be _a_ place that enables these resources.
> > > Checks like this make it feel like we just scattershot enabling
> > > resources in a bunch of random places instead of coming up with the
> > > design for enabling them in the right place.
> >
> > I'd prefer to see a check for eDP in dp_display_config_hpd(). Or even better
> > to see that this function isn't called for eDP at all.
> >
>
> This needs to be called when eDP is not using the aux_bus path. If the eDP panel is
> given as a separate panel driver, then the resources need to be enabled here.
>
> If we don't want to support eDP without aux_bus, then we can skip this function.

I think it's up to you to decide, if it's necessary or not.
But if it is, please change it accordingly.

> > >
> > > In any case, if we do end up landing this patch, it sure feels like it
> > > needs to move earlier in the patch series, right? This patch shouldn't
> > > hurt even without the other patches in the series but if you apply the
> > > earlier patches in the series without this one then you'll have a bug,
> > > right? That means this needs to come earlier.
> > >
> > > -Doug
> >
> >
> > --
> > With best wishes
> > Dmitry
>
> Thank you,
> Sankeerth
diff mbox series

Patch

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index 888ff03..798b30b 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -420,6 +420,11 @@  static void dp_display_host_init(struct dp_display_private *dp)
 		dp->dp_display.connector_type, dp->core_initialized,
 		dp->phy_initialized);
 
+	if (dp->core_initialized) {
+		DRM_DEBUG_DP("DP core already initialized\n");
+		return;
+	}
+
 	dp_power_init(dp->power, false);
 	dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
 	dp_aux_init(dp->aux);
@@ -432,6 +437,11 @@  static void dp_display_host_deinit(struct dp_display_private *dp)
 		dp->dp_display.connector_type, dp->core_initialized,
 		dp->phy_initialized);
 
+	if (!dp->core_initialized) {
+		DRM_DEBUG_DP("DP core not initialized\n");
+		return;
+	}
+
 	dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
 	dp_aux_deinit(dp->aux);
 	dp_power_deinit(dp->power);