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 |
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
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
> > 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
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 --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);
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(+)