Re: [PATCH v3] drm/dp_mst: Fix return code on sideband message failure
On Tue, 2021-07-13 at 15:24 -0700, khs...@codeaurora.org wrote:
> On 2021-07-07 01:37, Jani Nikula wrote:
> > On Tue, 06 Jul 2021, Kuogee Hsieh wrote:
> > > From: Rajkumar Subbiah
> > >
> > > Commit 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing +
> > > selftests") added some debug code for sideband message tracing. But
> > > it seems to have unintentionally changed the behavior on sideband
> > > message
> > > failure. It catches and returns failure only if DRM_UT_DP is enabled.
> > > Otherwise it ignores the error code and returns success. So on an MST
> > > unplug, the caller is unaware that the clear payload message failed
> > > and
> > > ends up waiting for 4 seconds for the response. Fixes the issue by
> > > returning the proper error code.
> > >
> > > Changes in V2:
> > > -- Revise commit text as review comment
> > > -- add Fixes text
> > >
> > > Changes in V3:
> > > -- remove "unlikely" optimization
> > >
> > > Fixes: 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing +
> > > selftests")
> > >
> > > Signed-off-by: Rajkumar Subbiah
> > > Signed-off-by: Kuogee Hsieh
> > >
> > > Reviewed-by: Stephen Boyd
> >
> > Reviewed-by: Jani Nikula
> >
> >
> > > ---
> Lyude,
> Any comments from you?
> Thanks,
Hey! Sorry did I forget to respond to this?
Reviewed-by: Lyude Paul
>
> > > drivers/gpu/drm/drm_dp_mst_topology.c | 10 ++
> > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 1590144..df91110 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -2887,11 +2887,13 @@ static int process_single_tx_qlock(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > > idx += tosend + 1;
> > >
> > > ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
> > > - if (unlikely(ret) && drm_debug_enabled(DRM_UT_DP)) {
> > > - struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> > > + if (ret) {
> > > + if (drm_debug_enabled(DRM_UT_DP)) {
> > > + struct drm_printer p =
> > > drm_debug_printer(DBG_PREFIX);
> > >
> > > - drm_printf(&p, "sideband msg failed to send\n");
> > > - drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> > > + drm_printf(&p, "sideband msg failed to send\n");
> > > + drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> > > + }
> > > return ret;
> > > }
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On Fri, 2021-07-23 at 11:24 +0200, Daniel Vetter wrote:
> On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > When the backlight support is disabled, the driver fails to build:
> >
> > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > 'nv50_sor_atomic_disable':
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> > nouveau_connector' has no member named 'backlight'
> > 1665 | struct nouveau_backlight *backlight = nv_connector-
> > >backlight;
> > | ^~
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
> > undefined type 'struct nouveau_backlight'
> > 1670 | if (backlight && backlight->uses_dpcd) {
> > | ^~
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
> > undefined type 'struct nouveau_backlight'
> > 1671 | ret = drm_edp_backlight_disable(aux, &backlight-
> > >edp_info);
> > | ^~
> >
> > The patch that introduced the problem already contains some #ifdef
> > checks, so just add another one that makes it build again.
> >
> > Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight
> > support for nouveau")
> > Signed-off-by: Arnd Bergmann
>
> Can we just toss the idea that BACKTLIGHT=n is a reasonable config for
> drm drivers using backlights, and add depends BACKLIGHT to all of
> them?
Yeah - I'm fine with this IMHO, at least for the drivers actually supporting
backlights in some manner (I assume this is most of them though)
>
> I mean this is a perfect source of continued patch streams to keep us
> all busy, but beyond that I really don't see the point ... I frankly
> have better things to do, and especially with the big drivers we have
> making backlight optional saves comparitively nothing.
> -Daniel
>
> > ---
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index 093e1f7163b3..fcf53e24db21 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -1659,20 +1659,23 @@ static void
> > nv50_sor_atomic_disable(struct drm_encoder *encoder, struct
> > drm_atomic_state *state)
> > {
> > struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> > - struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> > struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
> > struct nouveau_connector *nv_connector =
> > nv50_outp_get_old_connector(state, nv_encoder);
> > - struct nouveau_backlight *backlight = nv_connector->backlight;
> > struct drm_dp_aux *aux = &nv_connector->aux;
> > - int ret;
> > u8 pwr;
> >
> > +#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
> > + struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> > + struct nouveau_backlight *backlight = nv_connector->backlight;
> > +
> > if (backlight && backlight->uses_dpcd) {
> > - ret = drm_edp_backlight_disable(aux, &backlight-
> > >edp_info);
> > + int ret = drm_edp_backlight_disable(aux, &backlight-
> > >edp_info);
> > +
> > if (ret < 0)
> > NV_ERROR(drm, "Failed to disable backlight on
> > [CONNECTOR:%d:%s]: %d\n",
> > nv_connector->base.base.id, nv_connector-
> > >base.name, ret);
> > }
> > +#endif
> >
> > if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> > int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
> > --
> > 2.29.2
> >
>
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH v3] drm/dp_mst: Fix return code on sideband message failure
On Thu, 2021-07-22 at 15:28 -0700, khs...@codeaurora.org wrote: > > It looks like this patch is good to go (mainlined). > Anything needed from me to do? > Thanks, Do you have access for pushing this patch? If not let me know and I can go ahead and push it to drm-misc-next for you. -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [RESEND PATCH v6 11/14] drm/mst: Convert debug printers to debug category printers
Reviewed-by: Lyude Paul
On Wed, 2021-07-21 at 13:55 -0400, Sean Paul wrote:
> From: Sean Paul
>
> The printers in dp_mst are meant to be gated on DRM_UT_DP, so use the
> debug category printer to avoid dumping mst transactions to the wrong
> place.
>
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-12-s...@poorly.run
> #v5
>
> Changes in v5:
> -Added to the set
> Changes in v6:
> -None
> Reviewed-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index ad0795afc21c..b1dddecad4c6 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1356,7 +1356,8 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
> }
> out:
> if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) {
> - struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> + struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
> +
> DBG_PREFIX);
>
> drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> }
> @@ -2873,7 +2874,8 @@ static int process_single_tx_qlock(struct
> drm_dp_mst_topology_mgr *mgr,
>
> ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
> if (unlikely(ret) && drm_debug_enabled(DRM_UT_DP)) {
> - struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> + struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
> +
> DBG_PREFIX);
>
> drm_printf(&p, "sideband msg failed to send\n");
> drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> @@ -2917,7 +2919,8 @@ static void drm_dp_queue_down_tx(struct
> drm_dp_mst_topology_mgr *mgr,
> list_add_tail(&txmsg->next, &mgr->tx_msg_downq);
>
> if (drm_debug_enabled(DRM_UT_DP)) {
> - struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> + struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
> +
> DBG_PREFIX);
>
> drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> }
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH v3] drm/dp_mst: Fix return code on sideband message failure
Nice timing, you literally got me as I was 2 minutes away from leaving work for the day :P. I will go ahead and push it now. BTW - in the future I recommend using dim to add Fixes: tags as it'll add Cc: to stable as appropriate (this patch in particular should be Cc: sta...@vger.kernel.org # v5.3+). will add these tags when I push it On Tue, 2021-07-27 at 15:41 -0700, khs...@codeaurora.org wrote: > On 2021-07-27 12:21, Lyude Paul wrote: > > On Thu, 2021-07-22 at 15:28 -0700, khs...@codeaurora.org wrote: > > > > > > It looks like this patch is good to go (mainlined). > > > Anything needed from me to do? > > > Thanks, > > > > Do you have access for pushing this patch? If not let me know and I can > > go > > ahead and push it to drm-misc-next for you. > no, I do not have access to drm-misc-next. > Please push it for me. > Thanks a lots. > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [Intel-gfx] [PATCH v2 00/20] drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers
JFYI too - there was a legitimate looking CI failure on intel with this series, so don't be surprised if I have to respin a patch or two (I should be able to get it asap as I finally just cleared most of the stuff on my plate off for a while) On Thu, 2021-04-08 at 14:13 +0300, Jani Nikula wrote: > On Thu, 08 Apr 2021, Daniel Vetter wrote: > > I think Dave caught up on pulls to drm-next, so after a backmerge of that > > to drm-misc-next I think should be all fine to apply directly, no need for > > topic branch. > > Yup. We've done the backmerges to drm-intel-next and drm-intel-gt-next, > and are all in sync, it's only the drm-next -> drm-misc-next backmerge > that's still needed. > > BR, > Jani. > -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've asked me a question, are waiting for a review/merge on a patch, etc. and I haven't responded in a while, please feel free to send me another email to check on my status. I don't bite! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/30] drm/tegra: Don't register DP AUX channels before connectors
On Wed, 2021-04-14 at 18:49 +0200, Thierry Reding wrote: > On Fri, Feb 19, 2021 at 04:52:59PM -0500, Lyude Paul wrote: > > As pointed out by the documentation for drm_dp_aux_register(), > > drm_dp_aux_init() should be used in situations where the AUX channel for a > > display driver can potentially be registered before it's respective DRM > > driver. This is the case with Tegra, since the DP aux channel exists as a > > platform device instead of being a grandchild of the DRM device. > > > > Since we're about to add a backpointer to a DP AUX channel's respective > > DRM > > device, let's fix this so that we don't potentially allow userspace to use > > the AUX channel before we've associated it with it's DRM connector. > > > > Signed-off-by: Lyude Paul > > --- > > drivers/gpu/drm/tegra/dpaux.c | 11 ++- > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c > > index 105fb9cdbb3b..ea56c6ec25e4 100644 > > --- a/drivers/gpu/drm/tegra/dpaux.c > > +++ b/drivers/gpu/drm/tegra/dpaux.c > > @@ -534,9 +534,7 @@ static int tegra_dpaux_probe(struct platform_device > > *pdev) > > dpaux->aux.transfer = tegra_dpaux_transfer; > > dpaux->aux.dev = &pdev->dev; > > > > - err = drm_dp_aux_register(&dpaux->aux); > > - if (err < 0) > > - return err; > > + drm_dp_aux_init(&dpaux->aux); > > I just noticed that this change causes an error on some setups that I > haven't seen before. The problem is that the SOR driver tries to grab a > reference to the I2C device to make sure it doesn't go away while it has > a pointer to it. > > However, since now the I2C adapter hasn't been registered yet, I get > this: > > [ 15.013969] kobject: '(null)' (5c903e43): is not > initialized, yet kobject_get() is being called. > > I recall that you wanted to make this change so that a backpointer to > the DRM device could be added (I think that's patch 15 of the series), > but I didn't see that patch get merged, so it's a bit difficult to try > and fix this up. I'm pretty sure I already merged the tegra change in drm-misc-next, so if it's causing issues you probably should send out a revert for now and I can r-b it so we can figure out a better solution for this in the mean time > Has the situation changed? Do we no longer need the backpointer? If we > still want it, what's the plan for merging the change? Should I work > under the assumption that patch will make it in sometime and try to fix > this on top of that? yes we do still need the backpointer - I'm just still working on getting reviews for some of the other parts of this series, and have been on PTO/busy with a couple of other things. > > I'm thinking that perhaps we can move the I2C adapter registration into > drm_dp_aux_init() since that's independent of the DRM device. Yeah this makes sense for me - I can try to make this change on the next respin of this series. What kind of setup were you able to reproduce issues on this with btw? > It would > also make a bit more sense from the Tegra driver's point of view where > all devices would be created during the ->probe() path, and only during > the ->init() path would the connection between DRM device and DRM DP AUX > device be established. > > Thierry -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 00/20] drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers
Since it's been asked quite a few times on some of the various DP related patch series I've submitted to use the new DRM printk helpers, and it technically wasn't really trivial to do this before due to the lack of a consistent way to find a drm_device for an AUX channel, this patch series aims to address this. In this series we: * (NEW!) Move i2c adapter setup into drm_dp_aux_init() and add drm_dp_aux_fini() * Clean-up potentially erroneous usages of drm_dp_aux_init() and drm_dp_aux_register() so that actual AUX registration doesn't happen until we have an associated DRM device * Clean-up any obvious errors in drivers we find along the way * Add a backpointer to the respective drm_device for an AUX channel in drm_dp_aux.drm_dev, and hook it up in every driver with an AUX channel across the tree * Add a new ratelimited print helper we'll need for converting the DP helpers over to using the new DRM printk helpers * Fix any inconsistencies with logging in drm_dp_helper.c so we always have the aux channel name printed * Prepare the various DP helpers so they can find the correct drm_device to use for logging * And finally, convert all of the DP helpers over to using drm_dbg_*() and drm_err(). Lyude Paul (20): drm/amdgpu: Add error handling to amdgpu_dm_initialize_dp_connector() drm/dp: Add __no_check to drm_dp_aux_register() drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister drm/dp: Add backpointer to drm_device in drm_dp_aux drm/dp: Clarify DP AUX registration time drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay() drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay() drm/dp: Always print aux channel name in logs drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect() drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_set_tmds_output() drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_max_tmds_clock() drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_get_tmds_output() drm/dp_dual_mode: Pass drm_device to drm_lspcon_(get|set)_mode() drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw() drm/print: Handle potentially NULL drm_devices in drm_dbg_* drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*() drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using drm_err/drm_dbg_kms() drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*() .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 7 +- drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 17 +- drivers/gpu/drm/amd/amdgpu/atombios_dp.h | 2 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 49 ++- .../display/amdgpu_dm/amdgpu_dm_mst_types.h | 6 +- .../drm/bridge/analogix/analogix-anx6345.c| 3 + .../drm/bridge/analogix/analogix-anx78xx.c| 3 + .../drm/bridge/analogix/analogix_dp_core.c| 2 + .../drm/bridge/cadence/cdns-mhdp8546-core.c | 26 +- drivers/gpu/drm/bridge/tc358767.c | 6 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 17 +- drivers/gpu/drm/drm_dp_aux_dev.c | 6 + drivers/gpu/drm/drm_dp_dual_mode_helper.c | 68 ++-- drivers/gpu/drm/drm_dp_helper.c | 260 +++- drivers/gpu/drm/drm_dp_mst_topology.c | 376 +- drivers/gpu/drm/i915/display/intel_dp_aux.c | 11 +- drivers/gpu/drm/i915/display/intel_dp_aux.h | 2 +- .../drm/i915/display/intel_dp_link_training.c | 6 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 7 +- drivers/gpu/drm/i915/display/intel_lspcon.c | 17 +- drivers/gpu/drm/msm/dp/dp_aux.c | 1 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 6 +- drivers/gpu/drm/msm/edp/edp.h | 3 +- drivers/gpu/drm/msm/edp/edp_aux.c | 6 +- drivers/gpu/drm/msm/edp/edp_ctrl.c| 8 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 27 +- drivers/gpu/drm/radeon/atombios_dp.c | 5 +- drivers/gpu/drm/radeon/radeon_connectors.c| 1 + drivers/gpu/drm/tegra/dpaux.c | 15 +- drivers/gpu/drm/xlnx/zynqmp_dp.c | 6 +- include/drm/drm_dp_dual_mode_helper.h | 14 +- include/drm/drm_dp_helper.h | 24 +- include/drm/drm_dp_mst_helper.h | 3 +- include/drm/drm_print.h | 20 +- 36 files changed, 631 insertions(+), 431 deletions(-) -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/20] drm/amdgpu: Add error handling to amdgpu_dm_initialize_dp_connector()
While working on moving i2c device registration into drm_dp_aux_init() - I
realized that in order to do so we need to make sure that drivers calling
drm_dp_aux_init() handle any errors it could possibly return. In the
process of doing that, I noticed that the majority of AMD's code for DP
connector creation doesn't attempt to do any real error handling.
So, let's fix this and also cleanup amdgpu_dm_initialize_dp_connector()
while we're at it. This way we can handle the error codes from
drm_dp_aux_init().
Signed-off-by: Lyude Paul
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 44 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.h | 6 +--
3 files changed, 45 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a0c8c41e4e57..fc5d315bbb05 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7608,10 +7608,9 @@ static int amdgpu_dm_connector_init(struct
amdgpu_display_manager *dm,
aconnector->i2c = i2c;
res = i2c_add_adapter(&i2c->base);
-
if (res) {
DRM_ERROR("Failed to register hw i2c %d\n", link->link_index);
- goto out_free;
+ goto fail_free;
}
connector_type = to_drm_connector_type(link->connector_signal);
@@ -7625,8 +7624,7 @@ static int amdgpu_dm_connector_init(struct
amdgpu_display_manager *dm,
if (res) {
DRM_ERROR("connector_init failed\n");
- aconnector->connector_id = -1;
- goto out_free;
+ goto fail_id;
}
drm_connector_helper_add(
@@ -7643,15 +7641,22 @@ static int amdgpu_dm_connector_init(struct
amdgpu_display_manager *dm,
drm_connector_attach_encoder(
&aconnector->base, &aencoder->base);
- if (connector_type == DRM_MODE_CONNECTOR_DisplayPort
- || connector_type == DRM_MODE_CONNECTOR_eDP)
- amdgpu_dm_initialize_dp_connector(dm, aconnector,
link->link_index);
-
-out_free:
- if (res) {
- kfree(i2c);
- aconnector->i2c = NULL;
+ if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+ connector_type == DRM_MODE_CONNECTOR_eDP) {
+ res = amdgpu_dm_initialize_dp_connector(dm, aconnector,
link->link_index);
+ if (res)
+ goto fail_cleanup;
}
+
+ return 0;
+fail_cleanup:
+ drm_connector_cleanup(&aconnector->base);
+fail_id:
+ aconnector->connector_id = -1;
+fail_free:
+ kfree(i2c);
+ aconnector->i2c = NULL;
+
return res;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 73cdb9fe981a..3dee9cce9c9e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -425,33 +425,39 @@ static const struct drm_dp_mst_topology_cbs dm_mst_cbs = {
.add_connector = dm_dp_add_mst_connector,
};
-void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
- struct amdgpu_dm_connector *aconnector,
- int link_index)
+int amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
+ struct amdgpu_dm_connector *aconnector,
+ int link_index)
{
- aconnector->dm_dp_aux.aux.name =
- kasprintf(GFP_KERNEL, "AMDGPU DM aux hw bus %d",
- link_index);
- aconnector->dm_dp_aux.aux.transfer = dm_dp_aux_transfer;
- aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc;
+ struct amdgpu_dm_dp_aux *dm_aux = &aconnector->dm_dp_aux;
+ int ret;
- drm_dp_aux_init(&aconnector->dm_dp_aux.aux);
- drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
- &aconnector->base);
+ dm_aux->aux.name = kasprintf(GFP_KERNEL, "AMDGPU DM aux hw bus %d",
link_index);
+ if (!dm_aux->aux.name)
+ return -ENOMEM;
+
+ dm_aux->aux.transfer = dm_dp_aux_transfer;
+ dm_aux->ddc_service = aconnector->dc_link->ddc;
+
+ drm_dp_aux_init(&dm_aux->aux);
+ drm_dp_cec_register_connector(&dm_aux->aux, &aconnector->base);
if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
- return;
+ return 0;
aconnector->mst_mgr.cbs = &dm_mst_cbs;
- drm_dp_ms
[PATCH v3 02/20] drm/dp: Add __no_check to drm_dp_aux_register()
Since we're about to make it so that drm_dp_aux_init() can fail (and thus - should have it's return value checked) - we should require that callers of drm_dp_aux_register() also check it's return value since drm_dp_aux_init() can be called from there. Signed-off-by: Lyude Paul --- include/drm/drm_dp_helper.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 1e85c2021f2f..e44b0ee7b85e 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -2010,7 +2010,7 @@ bool drm_dp_lttpr_pre_emphasis_level_3_supported(const u8 caps[DP_LTTPR_PHY_CAP_ void drm_dp_remote_aux_init(struct drm_dp_aux *aux); void drm_dp_aux_init(struct drm_dp_aux *aux); -int drm_dp_aux_register(struct drm_dp_aux *aux); +__must_check int drm_dp_aux_register(struct drm_dp_aux *aux); void drm_dp_aux_unregister(struct drm_dp_aux *aux); int drm_dp_start_crc(struct drm_dp_aux *aux, struct drm_crtc *crtc); -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/20] drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini
When moving around drm_dp_aux_register() calls, it turned out we
accidentally managed to cause issues with the Tegra driver due to the fact
the Tegra driver would attempt to retrieve a reference to the AUX channel's
i2c adapter - which wouldn't be initialized until drm_dp_aux_register() is
called.
This doesn't actually make a whole ton of sense, as it's not unexpected for
a driver to need to be able to use an AUX adapter before it's been
registered. Likewise-it's not unexpected for a driver to try using the i2c
adapter for said AUX channel before it's been registered as well. In fact,
the current documentation for drm_dp_aux_init() even seems to imply that
drm_dp_aux_init() is supposed to be handling i2c adapter creation for this
precise reason - not drm_dp_aux_register().
Since the i2c adapter doesn't need to be linked to the DRM device in any
way, we can just fix this problem by moving i2c adapter creation out of
drm_dp_aux_register() and into drm_dp_aux_init(). Additionally, since this
means that drm_dp_aux_init() can fail we go ahead and add a __must_check
attribute to it so that drivers don't ignore its return status on failures.
And finally, we add a drm_dp_aux_fini() and hook it up in all DRM drivers
across the kernel to take care of cleaning up the i2c adapter once it's no
longer needed.
This should also fix the regressions noted in the Tegra driver.
Signed-off-by: Lyude Paul
Fixes: 39c17ae60ea9 ("drm/tegra: Don't register DP AUX channels before
connectors")
Cc: Thierry Reding
Cc: Thierry Reding
---
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 7 +-
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 10 ++-
drivers/gpu/drm/amd/amdgpu/atombios_dp.h | 2 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 6 +-
.../drm/bridge/analogix/analogix-anx6345.c| 2 +
.../drm/bridge/analogix/analogix-anx78xx.c| 2 +
.../drm/bridge/analogix/analogix_dp_core.c| 1 +
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 14 ++-
drivers/gpu/drm/bridge/tc358767.c | 5 +-
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 16 ++--
drivers/gpu/drm/drm_dp_helper.c | 88 ++-
drivers/gpu/drm/i915/display/intel_dp_aux.c | 10 ++-
drivers/gpu/drm/i915/display/intel_dp_aux.h | 2 +-
drivers/gpu/drm/msm/dp/dp_aux.c | 1 +
drivers/gpu/drm/msm/edp/edp_aux.c | 1 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 1 +
drivers/gpu/drm/radeon/radeon_connectors.c| 1 +
drivers/gpu/drm/tegra/dpaux.c | 14 ++-
drivers/gpu/drm/xlnx/zynqmp_dp.c | 1 +
include/drm/drm_dp_helper.h | 3 +-
20 files changed, 140 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index b9c11c2b2885..23b2134a651b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1963,8 +1963,11 @@ amdgpu_connector_add(struct amdgpu_device *adev,
connector->display_info.subpixel_order = subpixel_order;
- if (has_aux)
- amdgpu_atombios_dp_aux_init(amdgpu_connector);
+ if (has_aux) {
+ int ret = amdgpu_atombios_dp_aux_init(amdgpu_connector);
+ if (ret)
+ goto failed;
+ }
if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_eDP) {
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index a3ba9ca11e98..54c209ab8c9f 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -184,12 +184,18 @@ amdgpu_atombios_dp_aux_transfer(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *m
return ret;
}
-void amdgpu_atombios_dp_aux_init(struct amdgpu_connector *amdgpu_connector)
+int amdgpu_atombios_dp_aux_init(struct amdgpu_connector *amdgpu_connector)
{
+ int ret;
+
amdgpu_connector->ddc_bus->rec.hpd = amdgpu_connector->hpd.hpd;
amdgpu_connector->ddc_bus->aux.transfer =
amdgpu_atombios_dp_aux_transfer;
- drm_dp_aux_init(&amdgpu_connector->ddc_bus->aux);
+ ret = drm_dp_aux_init(&amdgpu_connector->ddc_bus->aux);
+ if (ret)
+ return ret;
+
amdgpu_connector->ddc_bus->has_aux = true;
+ return ret;
}
/* general DP utility functions */
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.h
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.h
index f59d85eaddf0..6b65cbf009fd 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.h
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.h
@@ -24,7 +24,7 @@
#ifndef __ATOMBIOS_DP_H__
#define __ATOMBIOS_DP_H__
-void amdgpu_atombios_dp_aux_init(struct amdgpu_connector *amdgpu_connector);
+int amdgpu_atombios_dp_aux
[PATCH v3 04/20] drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace
Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index c5e2bc75b226..518e9a441c21 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -1719,10 +1719,14 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
dev_dbg(mhdp->dev, "%s\n", __func__);
+ ret = drm_dp_aux_register(&mhdp->aux);
+ if (ret < 0)
+ return ret;
+
if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
ret = cdns_mhdp_connector_init(mhdp);
if (ret)
- return ret;
+ goto aux_unregister;
}
spin_lock(&mhdp->start_lock);
@@ -1738,6 +1742,9 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
mhdp->regs + CDNS_APB_INT_MASK);
return 0;
+aux_unregister:
+ drm_dp_aux_unregister(&mhdp->aux);
+ return ret;
}
static void cdns_mhdp_configure_video(struct cdns_mhdp_device *mhdp,
@@ -2082,6 +2089,8 @@ static void cdns_mhdp_detach(struct drm_bridge *bridge)
dev_dbg(mhdp->dev, "%s\n", __func__);
+ drm_dp_aux_unregister(&mhdp->aux);
+
spin_lock(&mhdp->start_lock);
mhdp->bridge_attached = false;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 05/20] drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister
Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index e5a93fab856e..56eaa29b34d6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -401,7 +401,6 @@ nouveau_connector_destroy(struct drm_connector *connector)
drm_connector_cleanup(connector);
if (nv_connector->aux.transfer) {
drm_dp_cec_unregister_connector(&nv_connector->aux);
- drm_dp_aux_unregister(&nv_connector->aux);
drm_dp_aux_fini(&nv_connector->aux);
kfree(nv_connector->aux.name);
}
@@ -906,13 +905,29 @@ nouveau_connector_late_register(struct drm_connector
*connector)
int ret;
ret = nouveau_backlight_init(connector);
+ if (ret)
+ return ret;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ ret = drm_dp_aux_register(&nouveau_connector(connector)->aux);
+ if (ret)
+ goto backlight_fini;
+ }
+
+ return 0;
+backlight_fini:
+ nouveau_backlight_fini(connector);
return ret;
}
static void
nouveau_connector_early_unregister(struct drm_connector *connector)
{
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+ drm_dp_aux_unregister(&nouveau_connector(connector)->aux);
+
nouveau_backlight_fini(connector);
}
@@ -1344,14 +1359,14 @@ nouveau_connector_create(struct drm_device *dev,
snprintf(aux_name, sizeof(aux_name), "sor-%04x-%04x",
dcbe->hasht, dcbe->hashm);
nv_connector->aux.name = kstrdup(aux_name, GFP_KERNEL);
- ret = drm_dp_aux_register(&nv_connector->aux);
+ ret = drm_dp_aux_init(&nv_connector->aux);
if (ret) {
- NV_ERROR(drm, "failed to register aux channel\n");
+ NV_ERROR(drm, "Failed to init AUX adapter for
sor-%04x-%04x: %d\n",
+dcbe->hasht, dcbe->hashm, ret);
kfree(nv_connector);
return ERR_PTR(ret);
}
- funcs = &nouveau_connector_funcs;
- break;
+ fallthrough;
default:
funcs = &nouveau_connector_funcs;
break;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/20] drm/dp: Add backpointer to drm_device in drm_dp_aux
This is something that we've wanted for a while now: the ability to actually look up the respective drm_device for a given drm_dp_aux struct. This will also allow us to transition over to using the drm_dbg_*() helpers for debug message printing, as we'll finally have a drm_device to reference for doing so. Note that there is one limitation with this - because some DP AUX adapters exist as platform devices which are initialized independently of their respective DRM devices, one cannot rely on drm_dp_aux->drm_dev to always be non-NULL until drm_dp_aux_register() has been called. We make sure to point this out in the documentation for struct drm_dp_aux. v3: * Add WARN_ON_ONCE() to drm_dp_aux_register() if drm_dev isn't filled out Signed-off-by: Lyude Paul Acked-by: Thierry Reding --- drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 7 --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 + drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 1 + drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 1 + drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 1 + drivers/gpu/drm/bridge/tc358767.c| 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c| 1 + drivers/gpu/drm/drm_dp_aux_dev.c | 6 ++ drivers/gpu/drm/drm_dp_helper.c | 2 ++ drivers/gpu/drm/drm_dp_mst_topology.c| 1 + drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 + drivers/gpu/drm/msm/edp/edp.h| 3 +-- drivers/gpu/drm/msm/edp/edp_aux.c| 5 +++-- drivers/gpu/drm/msm/edp/edp_ctrl.c | 2 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 1 + drivers/gpu/drm/radeon/atombios_dp.c | 1 + drivers/gpu/drm/tegra/dpaux.c| 1 + drivers/gpu/drm/xlnx/zynqmp_dp.c | 1 + include/drm/drm_dp_helper.h | 9 - 20 files changed, 38 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c index 54c209ab8c9f..14a097322238 100644 --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c @@ -190,11 +190,12 @@ int amdgpu_atombios_dp_aux_init(struct amdgpu_connector *amdgpu_connector) amdgpu_connector->ddc_bus->rec.hpd = amdgpu_connector->hpd.hpd; amdgpu_connector->ddc_bus->aux.transfer = amdgpu_atombios_dp_aux_transfer; + amdgpu_connector->ddc_bus->aux.drm_dev = amdgpu_connector->base.dev; + ret = drm_dp_aux_init(&amdgpu_connector->ddc_bus->aux); - if (ret) - return ret; + if (!ret) + amdgpu_connector->ddc_bus->has_aux = true; - amdgpu_connector->ddc_bus->has_aux = true; return ret; } diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c index 51fbbf3ef59b..a98bd3b521b2 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c @@ -438,6 +438,7 @@ int amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm, dm_aux->aux.transfer = dm_dp_aux_transfer; dm_aux->ddc_service = aconnector->dc_link->ddc; + dm_aux->aux.drm_dev = dm->ddev; ret = drm_dp_aux_init(&dm_aux->aux); if (ret) diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c index c105dcb79c37..f4e6a53f3821 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c @@ -537,6 +537,7 @@ static int anx6345_bridge_attach(struct drm_bridge *bridge, /* Register aux channel */ anx6345->aux.name = "DP-AUX"; anx6345->aux.dev = &anx6345->client->dev; + anx6345->aux.drm_dev = bridge->dev; anx6345->aux.transfer = anx6345_aux_transfer; err = drm_dp_aux_register(&anx6345->aux); diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c index 0778458e81be..7bd28c077181 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c @@ -905,6 +905,7 @@ static int anx78xx_bridge_attach(struct drm_bridge *bridge, /* Register aux channel */ anx78xx->aux.name = "DP-AUX"; anx78xx->aux.dev = &anx78xx->client->dev; + anx78xx->aux.drm_dev = bridge->dev; anx78xx->aux.transfer = anx78xx_aux_transfer; err = drm_dp
[PATCH v3 07/20] drm/dp: Clarify DP AUX registration time
The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly correct, except for the fact that they made the assumption that all AUX devices were grandchildren of their respective DRM devices. This is the case for most normal GPUs, but is almost never the case with SoCs and display bridges. So, let's fix this documentation to clarify when the right time to use drm_dp_aux_init() or drm_dp_aux_register() is. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_helper.c | 57 + 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index b34105c41867..b197fdac2334 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1728,13 +1728,21 @@ EXPORT_SYMBOL(drm_dp_remote_aux_init); * drm_dp_aux_init() - minimally initialise an aux channel * @aux: DisplayPort AUX channel * - * If you need to use the drm_dp_aux's i2c adapter prior to registering it - * with the outside world, call drm_dp_aux_init() first. You must still - * call drm_dp_aux_register() once the connector has been registered to - * allow userspace access to the auxiliary DP channel. Once the AUX channel is - * no longer being used and has been unregistered with - * drm_dp_aux_unregister(), the driver must clean up any resources it's - * allocated with drm_dp_aux_fini(). + * If you need to use the drm_dp_aux's i2c adapter prior to registering it with + * the outside world, call drm_dp_aux_init() first. For drivers which are + * grandparents to their AUX adapters (e.g. the AUX adapter is parented by a + * &drm_connector), you must still call drm_dp_aux_register() once the connector + * has been registered to allow userspace access to the auxiliary DP channel. + * Likewise, for such drivers you should also assign &drm_dp_aux.drm_dev as + * early as possible so that the &drm_device that corresponds to the AUX adapter + * may be mentioned in debugging output from the DRM DP helpers. + * + * For devices which use a separate platform device for their AUX adapters, this + * may be called as early as required by the driver. + * + * Once the AUX channel is no longer being used and has been unregistered with + * drm_dp_aux_unregister(), the driver must clean up any resources its allocated with + * drm_dp_aux_fini(). * * Returns: * %0 on success, negative error code on failure @@ -1794,19 +1802,28 @@ EXPORT_SYMBOL(drm_dp_aux_fini); * drm_dp_aux_register() - register aux channel * @aux: DisplayPort AUX channel * - * Automatically calls drm_dp_aux_init() if this hasn't been done yet. The - * driver must make sure to call drm_dp_aux_unregister() to unregister the - * device, and drm_dp_aux_fini() to cleanup the device after it's been - * unregistered. - * - * This should only be called when the underlying &struct drm_connector is - * initialized already. Therefore the best place to call this is from - * &drm_connector_funcs.late_register. Not that drivers which don't follow this - * will Oops when CONFIG_DRM_DP_AUX_CHARDEV is enabled. - * - * Drivers which need to use the aux channel before that point (e.g. at driver - * load time, before drm_dev_register() has been called) need to call - * drm_dp_aux_init(). + * Automatically calls drm_dp_aux_init() if this hasn't been done yet. This + * should only be called once the parent of @aux, &drm_dp_aux.dev, is + * initialized. For devices which are grandparents of their AUX channels, + * &drm_dp_aux.dev will typically be the &drm_connector &device which + * corresponds to @aux. For these devices, it's advised to call + * drm_dp_aux_register() in &drm_connector_funcs.late_register, and likewise to + * call drm_dp_aux_unregister() in &drm_connector_funcs.early_unregister. + * Functions which don't follow this will likely Oops when + * %CONFIG_DRM_DP_AUX_CHARDEV is enabled. + * + * For devices where the AUX channel is a device that exists independently of + * the &drm_device that uses it, such as SoCs and bridge devices, it is + * recommended to call drm_dp_aux_register() after a &drm_device has been + * assigned to &drm_dp_aux.drm_dev, and likewise to call + * drm_dp_aux_unregister() once the &drm_device should no longer be associated + * with the AUX channel (e.g. on bridge detach). Additionally, the driver must + * call drm_dp_aux_fini() on @aux once it's been unregistered and is no longer + * in use. + * + * Drivers which need to use the aux channel before either of the two points + * mentioned above need to call drm_dp_aux_init() in order to use the AUX + * channel before registration. * * Returns 0 on success or a negative error code on failure. */ -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/20] drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
drivers/gpu/drm/msm/edp/edp_ctrl.c| 2 +-
drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
include/drm/drm_dp_helper.h | 4 +++-
8 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 14a097322238..b0eaeb6afd29 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -617,7 +617,7 @@ amdgpu_atombios_dp_link_train_cr(struct
amdgpu_atombios_dp_link_train_info *dp_i
dp_info->tries = 0;
voltage = 0xff;
while (1) {
- drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
+ drm_dp_link_train_clock_recovery_delay(dp_info->aux,
dp_info->dpcd);
if (drm_dp_dpcd_read_link_status(dp_info->aux,
dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index b197fdac2334..3a3c4cfb9ac6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -132,7 +132,8 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZ
}
EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
-void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
+void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 591ddc4b876c..198ddb3c173a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -513,7 +513,7 @@ static void
intel_dp_link_training_clock_recovery_delay(struct intel_dp *intel_d
enum drm_dp_phy dp_phy)
{
if (dp_phy == DP_PHY_DPRX)
- drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
+ drm_dp_link_train_clock_recovery_delay(&intel_dp->aux,
intel_dp->dpcd);
else
drm_dp_lttpr_link_train_clock_recovery_delay();
}
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 1390f3547fde..264a9eae87d3 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1103,7 +1103,7 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private
*ctrl,
tries = 0;
old_v_level = ctrl->link->phy_params.v_level;
for (tries = 0; tries < maximum_retries; tries++) {
- drm_dp_link_train_clock_recovery_delay(ctrl->panel->dpcd);
+ drm_dp_link_train_clock_recovery_delay(ctrl->aux,
ctrl->panel->dpcd);
ret = dp_ctrl_read_link_status(ctrl, link_status);
if (ret)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 57af3d8b6699..6501598448b4 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -608,7 +608,7 @@ static int edp_start_link_train_1(struct edp_ctrl *ctrl)
tries = 0;
old_v_level = ctrl->v_level;
while (1) {
- drm_dp_link_train_clock_recovery_delay(ctrl->dpcd);
+ drm_dp_link_train_clock_recovery_delay(ctrl->drm_aux,
ctrl->dpcd);
rlen = drm_dp_dpcd_read_link_status(ctrl->drm_aux, link_status);
if (rlen < DP_LINK_STATUS_SIZE) {
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index c50c504bad50..299b9d8da376 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -680,7 +680,7 @@ static int radeon_dp_link_train_cr(struct
radeon_dp_link_train_info *dp_info)
dp_info->tries = 0;
voltage = 0xff;
while (1) {
- drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
+ drm_dp_link_train_clock_recovery_delay(dp_info->aux,
dp_info->dpcd);
if (drm_dp_dpcd_read_link_status(dp_info->aux,
dp_
[PATCH v3 09/20] drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay()
So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c| 14 +-
.../gpu/drm/i915/display/intel_dp_link_training.c | 4 ++--
drivers/gpu/drm/msm/dp/dp_ctrl.c | 4 ++--
drivers/gpu/drm/msm/edp/edp_ctrl.c | 4 ++--
drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
include/drm/drm_dp_helper.h| 6 --
8 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index b0eaeb6afd29..9f0acee0a271 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -682,7 +682,7 @@ amdgpu_atombios_dp_link_train_ce(struct
amdgpu_atombios_dp_link_train_info *dp_i
dp_info->tries = 0;
channel_eq = false;
while (1) {
- drm_dp_link_train_channel_eq_delay(dp_info->dpcd);
+ drm_dp_link_train_channel_eq_delay(dp_info->aux, dp_info->dpcd);
if (drm_dp_dpcd_read_link_status(dp_info->aux,
dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3a3c4cfb9ac6..eaafc676aa0c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -151,7 +151,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct
drm_dp_aux *aux,
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
-static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
+static void __drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+unsigned long rd_interval)
{
if (rd_interval > 4)
DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
@@ -165,9 +166,11 @@ static void __drm_dp_link_train_channel_eq_delay(unsigned
long rd_interval)
usleep_range(rd_interval, rd_interval * 2);
}
-void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+void drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
- __drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ __drm_dp_link_train_channel_eq_delay(aux,
+dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK);
}
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
@@ -183,13 +186,14 @@ static u8 dp_lttpr_phy_cap(const u8
phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
}
-void drm_dp_lttpr_link_train_channel_eq_delay(const u8
phy_cap[DP_LTTPR_PHY_CAP_SIZE])
+void drm_dp_lttpr_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+ const u8
phy_cap[DP_LTTPR_PHY_CAP_SIZE])
{
u8 interval = dp_lttpr_phy_cap(phy_cap,
DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1) &
DP_TRAINING_AUX_RD_MASK;
- __drm_dp_link_train_channel_eq_delay(interval);
+ __drm_dp_link_train_channel_eq_delay(aux, interval);
}
EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 198ddb3c173a..6bf6f1ec13ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -665,11 +665,11 @@ intel_dp_link_training_channel_equalization_delay(struct
intel_dp *intel_dp,
enum drm_dp_phy dp_phy)
{
if (dp_phy == DP_PHY_DPRX) {
- drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
+ drm_dp_link_train_channel_eq_delay(&intel_dp->aux,
intel_dp->dpcd);
} else {
const u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
- drm_dp_lttpr_link_train_channel_eq_delay(phy_caps);
+ drm_dp_lttpr_link_train_channel_eq_delay(&intel_dp->aux,
phy_caps);
}
}
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 264a9eae87d3..2cebd17a7289 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1184,7 +1184,7 @@ static int dp_ctrl_link_lane_down_shift(struct
dp_ctrl_private *ctrl)
static void dp_ctrl_clear_training_pattern(struc
[PATCH v3 10/20] drm/dp: Always print aux channel name in logs
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eaafc676aa0c..6dc1ccd4880b 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -139,8 +139,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct
drm_dp_aux *aux,
DP_TRAINING_AUX_RD_MASK;
if (rd_interval > 4)
- DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
- rd_interval);
+ DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
+ aux->name, rd_interval);
if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
rd_interval = 100;
@@ -155,8 +155,8 @@ static void __drm_dp_link_train_channel_eq_delay(const
struct drm_dp_aux *aux,
unsigned long rd_interval)
{
if (rd_interval > 4)
- DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
- rd_interval);
+ DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
+ aux->name, rd_interval);
if (rd_interval == 0)
rd_interval = 400;
@@ -2819,7 +2819,7 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux)
if (ret < 0)
return ret;
if (!(buf & DP_PCON_ENABLE_SOURCE_CTL_MODE)) {
- DRM_DEBUG_KMS("PCON in Autonomous mode, can't enable FRL\n");
+ DRM_DEBUG_KMS("%s: PCON in Autonomous mode, can't enable
FRL\n", aux->name);
return -EINVAL;
}
buf |= DP_PCON_ENABLE_HDMI_LINK;
@@ -2914,7 +2914,8 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct
drm_dp_aux *aux,
num_error = 0;
}
- DRM_ERROR("More than %d errors since the last read for lane
%d", num_error, i);
+ DRM_ERROR("%s: More than %d errors since the last read for lane
%d",
+ aux->name, num_error, i);
}
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/20] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_set_tmds_output()
Another function that we'll need to pass a drm_device (and not drm_dp_aux)
down to so that we can move over to using drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
include/drm/drm_dp_dual_mode_helper.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 9ee75c568c37..a63d7de85309 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -336,6 +336,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_get_tmds_output);
/**
* drm_dp_dual_mode_set_tmds_output - Enable/disable TMDS output buffers in
the DP dual mode adaptor
+ * @dev: &drm_device to use
* @type: DP dual mode adaptor type
* @adapter: I2C adapter for the DDC bus
* @enable: enable (as opposed to disable) the TMDS output buffers
@@ -349,7 +350,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_get_tmds_output);
* Returns:
* 0 on success, negative error code on failure
*/
-int drm_dp_dual_mode_set_tmds_output(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_set_tmds_output(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter, bool enable)
{
uint8_t tmds_oen = enable ? 0 : DP_DUAL_MODE_TMDS_DISABLE;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 08fb98dac169..fc3e7a9396b5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1251,8 +1251,7 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi
*hdmi, bool enable)
drm_dbg_kms(&dev_priv->drm, "%s DP dual mode adaptor TMDS output\n",
enable ? "Enabling" : "Disabling");
- drm_dp_dual_mode_set_tmds_output(hdmi->dp_dual_mode.type,
-adapter, enable);
+ drm_dp_dual_mode_set_tmds_output(&dev_priv->drm,
hdmi->dp_dual_mode.type, adapter, enable);
}
static int intel_hdmi_hdcp_read(struct intel_digital_port *dig_port,
diff --git a/include/drm/drm_dp_dual_mode_helper.h
b/include/drm/drm_dp_dual_mode_helper.h
index 23ce849152f3..8cb0dcd98a99 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -110,7 +110,7 @@ int drm_dp_dual_mode_max_tmds_clock(enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter);
int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
struct i2c_adapter *adapter, bool
*enabled);
-int drm_dp_dual_mode_set_tmds_output(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_set_tmds_output(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter, bool enable);
const char *drm_dp_get_dual_mode_type_name(enum drm_dp_dual_mode_type type);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 13/20] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_max_tmds_clock()
Another function we need to pass drm_device down to in order to start using
drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
include/drm/drm_dp_dual_mode_helper.h | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index a63d7de85309..4a26b3e1f78f 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -252,6 +252,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_detect);
/**
* drm_dp_dual_mode_max_tmds_clock - Max TMDS clock for DP dual mode adaptor
+ * @dev: &drm_device to use
* @type: DP dual mode adaptor type
* @adapter: I2C adapter for the DDC bus
*
@@ -265,7 +266,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_detect);
* Returns:
* Maximum supported TMDS clock rate for the DP dual mode adaptor in kHz.
*/
-int drm_dp_dual_mode_max_tmds_clock(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_max_tmds_clock(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter)
{
uint8_t max_tmds_clock;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index fc3e7a9396b5..46de56af33db 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2256,7 +2256,7 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector
*connector, bool has_edid)
hdmi->dp_dual_mode.type = type;
hdmi->dp_dual_mode.max_tmds_clock =
- drm_dp_dual_mode_max_tmds_clock(type, adapter);
+ drm_dp_dual_mode_max_tmds_clock(&dev_priv->drm, type, adapter);
drm_dbg_kms(&dev_priv->drm,
"DP dual mode adaptor (%s) detected (max TMDS clock: %d
kHz)\n",
diff --git a/include/drm/drm_dp_dual_mode_helper.h
b/include/drm/drm_dp_dual_mode_helper.h
index 8cb0dcd98a99..aabf9c951380 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -106,7 +106,7 @@ enum drm_dp_dual_mode_type {
enum drm_dp_dual_mode_type
drm_dp_dual_mode_detect(const struct drm_device *dev, struct i2c_adapter
*adapter);
-int drm_dp_dual_mode_max_tmds_clock(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_max_tmds_clock(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter);
int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
struct i2c_adapter *adapter, bool
*enabled);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 14/20] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_get_tmds_output()
Another function to pass drm_device * down to so we can start using the
drm_dbg_*() in the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 4a26b3e1f78f..c9c2952bcad2 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -296,6 +296,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_max_tmds_clock);
/**
* drm_dp_dual_mode_get_tmds_output - Get the state of the TMDS output buffers
in the DP dual mode adaptor
+ * @dev: &drm_device to use
* @type: DP dual mode adaptor type
* @adapter: I2C adapter for the DDC bus
* @enabled: current state of the TMDS output buffers
@@ -310,8 +311,8 @@ EXPORT_SYMBOL(drm_dp_dual_mode_max_tmds_clock);
* Returns:
* 0 on success, negative error code on failure
*/
-int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
-struct i2c_adapter *adapter,
+int drm_dp_dual_mode_get_tmds_output(const struct drm_device *dev,
+enum drm_dp_dual_mode_type type, struct
i2c_adapter *adapter,
bool *enabled)
{
uint8_t tmds_oen;
diff --git a/include/drm/drm_dp_dual_mode_helper.h
b/include/drm/drm_dp_dual_mode_helper.h
index aabf9c951380..01eec9ff5962 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -108,7 +108,7 @@ enum drm_dp_dual_mode_type
drm_dp_dual_mode_detect(const struct drm_device *dev, struct i2c_adapter
*adapter);
int drm_dp_dual_mode_max_tmds_clock(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter);
-int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_get_tmds_output(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter, bool
*enabled);
int drm_dp_dual_mode_set_tmds_output(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter, bool enable);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 15/20] drm/dp_dual_mode: Pass drm_device to drm_lspcon_(get|set)_mode()
So that we can start using drm_dbg_*() throughout the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +---
drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++-
include/drm/drm_dp_dual_mode_helper.h | 4 ++--
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index c9c2952bcad2..dbf9b1fdec63 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -430,6 +430,7 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
/**
* drm_lspcon_get_mode: Get LSPCON's current mode of operation by
* reading offset (0x80, 0x41)
+ * @dev: &drm_device to use
* @adapter: I2C-over-aux adapter
* @mode: current lspcon mode of operation output variable
*
@@ -437,7 +438,7 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
* 0 on success, sets the current_mode value to appropriate mode
* -error on failure
*/
-int drm_lspcon_get_mode(struct i2c_adapter *adapter,
+int drm_lspcon_get_mode(const struct drm_device *dev, struct i2c_adapter
*adapter,
enum drm_lspcon_mode *mode)
{
u8 data;
@@ -477,13 +478,14 @@ EXPORT_SYMBOL(drm_lspcon_get_mode);
/**
* drm_lspcon_set_mode: Change LSPCON's mode of operation by
* writing offset (0x80, 0x40)
+ * @dev: &drm_device to use
* @adapter: I2C-over-aux adapter
* @mode: required mode of operation
*
* Returns:
* 0 on success, -error on failure/timeout
*/
-int drm_lspcon_set_mode(struct i2c_adapter *adapter,
+int drm_lspcon_set_mode(const struct drm_device *dev, struct i2c_adapter
*adapter,
enum drm_lspcon_mode mode)
{
u8 data = 0;
@@ -508,7 +510,7 @@ int drm_lspcon_set_mode(struct i2c_adapter *adapter,
* so wait and retry until time out or done.
*/
do {
- ret = drm_lspcon_get_mode(adapter, ¤t_mode);
+ ret = drm_lspcon_get_mode(dev, adapter, ¤t_mode);
if (ret) {
DRM_ERROR("can't confirm LSPCON mode change\n");
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index ca25044e7d1b..ec0048024746 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -139,10 +139,11 @@ void lspcon_detect_hdr_capability(struct intel_lspcon
*lspcon)
static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon
*lspcon)
{
+ struct intel_dp *intel_dp = lspcon_to_intel_dp(lspcon);
enum drm_lspcon_mode current_mode;
- struct i2c_adapter *adapter = &lspcon_to_intel_dp(lspcon)->aux.ddc;
+ struct i2c_adapter *adapter = &intel_dp->aux.ddc;
- if (drm_lspcon_get_mode(adapter, ¤t_mode)) {
+ if (drm_lspcon_get_mode(intel_dp->aux.drm_dev, adapter, ¤t_mode))
{
DRM_DEBUG_KMS("Error reading LSPCON mode\n");
return DRM_LSPCON_MODE_INVALID;
}
@@ -175,11 +176,12 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct
intel_lspcon *lspcon,
static int lspcon_change_mode(struct intel_lspcon *lspcon,
enum drm_lspcon_mode mode)
{
+ struct intel_dp *intel_dp = lspcon_to_intel_dp(lspcon);
int err;
enum drm_lspcon_mode current_mode;
- struct i2c_adapter *adapter = &lspcon_to_intel_dp(lspcon)->aux.ddc;
+ struct i2c_adapter *adapter = &intel_dp->aux.ddc;
- err = drm_lspcon_get_mode(adapter, ¤t_mode);
+ err = drm_lspcon_get_mode(intel_dp->aux.drm_dev, adapter,
¤t_mode);
if (err) {
DRM_ERROR("Error reading LSPCON mode\n");
return err;
@@ -190,7 +192,7 @@ static int lspcon_change_mode(struct intel_lspcon *lspcon,
return 0;
}
- err = drm_lspcon_set_mode(adapter, mode);
+ err = drm_lspcon_set_mode(intel_dp->aux.drm_dev, adapter, mode);
if (err < 0) {
DRM_ERROR("LSPCON mode change failed\n");
return err;
diff --git a/include/drm/drm_dp_dual_mode_helper.h
b/include/drm/drm_dp_dual_mode_helper.h
index 01eec9ff5962..7ee482265087 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -114,8 +114,8 @@ int drm_dp_dual_mode_set_tmds_output(const struct
drm_device *dev, enum drm_dp_d
struct i2c_adapter *adapter, bool enable);
const char *drm_dp_get_dual_mode_type_name(enum drm_dp_dual_mode_type type);
-int drm_lspcon_get_mode(struct i2c_adapter *adapter,
+int drm_lspcon_get_mode(const struct drm_device *dev, struct i2c_adapter
*adapter,
enum drm_lspcon_mode *current_mode);
-int drm_lspcon_set_mode(struct i2
[PATCH v3 11/20] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect()
Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll
need to be able to access the DRM device in the dual mode DP helpers as
well. Note however that since drm_dp_dual_mode_detect() can be called with
DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down
the drm_device to these functions instead of using drm_dp_aux.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 4 +++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
drivers/gpu/drm/i915/display/intel_lspcon.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h | 4 +++-
4 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 1c9ea9f7fdaf..9ee75c568c37 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -165,6 +165,7 @@ static bool is_lspcon_adaptor(const char
hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
/**
* drm_dp_dual_mode_detect - Identify the DP dual mode adaptor
+ * @dev: &drm_device to use
* @adapter: I2C adapter for the DDC bus
*
* Attempt to identify the type of the DP dual mode adaptor used.
@@ -178,7 +179,8 @@ static bool is_lspcon_adaptor(const char
hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
* Returns:
* The type of the DP dual mode adaptor used
*/
-enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct i2c_adapter *adapter)
+enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(const struct drm_device
*dev,
+ struct i2c_adapter *adapter)
{
char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN] = {};
uint8_t adaptor_id = 0x00;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 47a8f0a1c5e2..08fb98dac169 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2224,7 +2224,7 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector
*connector, bool has_edid)
enum port port = hdmi_to_dig_port(hdmi)->base.port;
struct i2c_adapter *adapter =
intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
- enum drm_dp_dual_mode_type type = drm_dp_dual_mode_detect(adapter);
+ enum drm_dp_dual_mode_type type =
drm_dp_dual_mode_detect(&dev_priv->drm, adapter);
/*
* Type 1 DVI adaptors are not required to implement any
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index e4ff533e3a69..ca25044e7d1b 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -221,7 +221,8 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
{
int retry;
enum drm_dp_dual_mode_type adaptor_type;
- struct i2c_adapter *adapter = &lspcon_to_intel_dp(lspcon)->aux.ddc;
+ struct intel_dp *intel_dp = lspcon_to_intel_dp(lspcon);
+ struct i2c_adapter *adapter = &intel_dp->aux.ddc;
enum drm_lspcon_mode expected_mode;
expected_mode = lspcon_wake_native_aux_ch(lspcon) ?
@@ -232,7 +233,7 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
if (retry)
usleep_range(500, 1000);
- adaptor_type = drm_dp_dual_mode_detect(adapter);
+ adaptor_type = drm_dp_dual_mode_detect(intel_dp->aux.drm_dev,
adapter);
if (adaptor_type == DRM_DP_DUAL_MODE_LSPCON)
break;
}
diff --git a/include/drm/drm_dp_dual_mode_helper.h
b/include/drm/drm_dp_dual_mode_helper.h
index 4c42db81fcb4..23ce849152f3 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -62,6 +62,7 @@
#define DP_DUAL_MODE_LSPCON_CURRENT_MODE 0x41
#define DP_DUAL_MODE_LSPCON_MODE_PCON 0x1
+struct drm_device;
struct i2c_adapter;
ssize_t drm_dp_dual_mode_read(struct i2c_adapter *adapter,
@@ -103,7 +104,8 @@ enum drm_dp_dual_mode_type {
DRM_DP_DUAL_MODE_LSPCON,
};
-enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct i2c_adapter
*adapter);
+enum drm_dp_dual_mode_type
+drm_dp_dual_mode_detect(const struct drm_device *dev, struct i2c_adapter
*adapter);
int drm_dp_dual_mode_max_tmds_clock(enum drm_dp_dual_mode_type type,
struct i2c_adapter *adapter);
int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 17/20] drm/print: Handle potentially NULL drm_devices in drm_dbg_*
While this shouldn't really be something that happens all that often, since we're going to be using the drm_dbg_* log helpers in DRM helpers it's technically possible that a driver could use an AUX adapter before it's been associated with it's respective drm_device. While drivers should take care to avoid this, there's likely going to be situations where it's difficult to workaround. And since other logging helpers in the kernel tend to be OK with NULL pointers (for instance, passing a NULL pointer to a "%s" argument for a printk-like function in the kernel doesn't break anything), we should do the same for ours. Signed-off-by: Lyude Paul --- include/drm/drm_print.h | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index a3c58c941bdc..9b66be54dd16 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -443,25 +443,25 @@ void drm_dev_dbg(const struct device *dev, enum drm_debug_category category, #define drm_dbg_core(drm, fmt, ...)\ - drm_dev_dbg((drm)->dev, DRM_UT_CORE, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__) #define drm_dbg(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_DRIVER, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, ##__VA_ARGS__) #define drm_dbg_kms(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__) #define drm_dbg_prime(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_PRIME, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_PRIME, fmt, ##__VA_ARGS__) #define drm_dbg_atomic(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_ATOMIC, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_ATOMIC, fmt, ##__VA_ARGS__) #define drm_dbg_vbl(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_VBL, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_VBL, fmt, ##__VA_ARGS__) #define drm_dbg_state(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_STATE, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_STATE, fmt, ##__VA_ARGS__) #define drm_dbg_lease(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_LEASE, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_LEASE, fmt, ##__VA_ARGS__) #define drm_dbg_dp(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_DP, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DP, fmt, ##__VA_ARGS__) #define drm_dbg_drmres(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_DRMRES, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt, ##__VA_ARGS__) /* -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 18/20] drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()
Now that we've added a back-pointer to drm_device to drm_dp_aux, made
drm_dp_aux available to any functions in drm_dp_helper.c which need to
print to the kernel log, and ensured all of our logging uses a consistent
format, let's do the final step of the conversion and actually move
everything over to using drm_err() and drm_dbg_*().
This was done by using the following cocci script:
@@
expression list expr;
@@
(
- DRM_DEBUG_KMS(expr);
+ drm_dbg_kms(aux->drm_dev, expr);
|
- DRM_DEBUG_DP(expr);
+ drm_dbg_dp(aux->drm_dev, expr);
|
- DRM_DEBUG_ATOMIC(expr);
+ drm_dbg_atomic(aux->drm_dev, expr);
|
- DRM_DEBUG_KMS_RATELIMITED(expr);
+ drm_dbg_kms_ratelimited(aux->drm_dev, expr);
|
- DRM_ERROR(expr);
+ drm_err(aux->drm_dev, expr);
)
Followed by correcting the resulting line-wrapping in the results by hand.
v2:
* Fix indenting in drm_dp_dump_access
Signed-off-by: Lyude Paul
Cc: Robert Foss
Reviewed-by: Robert Foss
---
drivers/gpu/drm/drm_dp_helper.c | 121
1 file changed, 59 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 6dc1ccd4880b..75563987ab8c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -139,8 +139,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct
drm_dp_aux *aux,
DP_TRAINING_AUX_RD_MASK;
if (rd_interval > 4)
- DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
- aux->name, rd_interval);
+ drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range
(max 4)\n",
+ aux->name, rd_interval);
if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
rd_interval = 100;
@@ -155,8 +155,8 @@ static void __drm_dp_link_train_channel_eq_delay(const
struct drm_dp_aux *aux,
unsigned long rd_interval)
{
if (rd_interval > 4)
- DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
- aux->name, rd_interval);
+ drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range
(max 4)\n",
+ aux->name, rd_interval);
if (rd_interval == 0)
rd_interval = 400;
@@ -220,11 +220,11 @@ drm_dp_dump_access(const struct drm_dp_aux *aux,
const char *arrow = request == DP_AUX_NATIVE_READ ? "->" : "<-";
if (ret > 0)
- DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
-aux->name, offset, arrow, ret, min(ret, 20),
buffer);
+ drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
+ aux->name, offset, arrow, ret, min(ret, 20), buffer);
else
- DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d)\n",
-aux->name, offset, arrow, ret);
+ drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d)\n",
+ aux->name, offset, arrow, ret);
}
/**
@@ -287,8 +287,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
err = ret;
}
- DRM_DEBUG_KMS("%s: Too many retries, giving up. First error: %d\n",
- aux->name, err);
+ drm_dbg_kms(aux->drm_dev, "%s: Too many retries, giving up. First
error: %d\n",
+ aux->name, err);
ret = err;
unlock:
@@ -524,44 +524,44 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux
*aux,
if (drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR,
&auto_test_req, 1) < 1) {
- DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
- aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
+ drm_err(aux->drm_dev, "%s: DPCD failed read at register 0x%x\n",
+ aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
return false;
}
auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
if (drm_dp_dpcd_read(aux, DP_TEST_REQUEST, &link_edid_read, 1) < 1) {
- DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
- aux->name, DP_TEST_REQUEST);
+ drm_err(aux->drm_dev, "%s: DPCD failed read at register 0x%x\n",
+ aux->name, DP_TEST_REQUEST);
return false;
}
link_edid_read &= DP_TEST_LINK_EDID_READ;
if (!auto_test_req || !link_edid_read) {
- DRM_DEBUG_KMS("%s: Source
[PATCH v3 16/20] drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw()
Since this is one of the few functions in drm_dp_mst_topology.c that
doesn't have any way of getting access to a drm_device, let's pass the
drm_dp_mst_topology_mgr down to this function so that it can use
drm_dbg_kms().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 +--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ++-
include/drm/drm_dp_mst_helper.h | 3 ++-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 276f7f054d62..9bac5bd050ab 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3638,6 +3638,7 @@ static int drm_dp_send_up_ack_reply(struct
drm_dp_mst_topology_mgr *mgr,
/**
* drm_dp_get_vc_payload_bw - get the VC payload BW for an MST link
+ * @mgr: The &drm_dp_mst_topology_mgr to use
* @link_rate: link rate in 10kbits/s units
* @link_lane_count: lane count
*
@@ -3646,7 +3647,8 @@ static int drm_dp_send_up_ack_reply(struct
drm_dp_mst_topology_mgr *mgr,
* convert the number of PBNs required for a given stream to the number of
* timeslots this stream requires in each MTP.
*/
-int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count)
+int drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr *mgr,
+int link_rate, int link_lane_count)
{
if (link_rate == 0 || link_lane_count == 0)
DRM_DEBUG_KMS("invalid link rate/lane count: (%d / %d)\n",
@@ -3711,7 +3713,8 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
goto out_unlock;
}
- mgr->pbn_div =
drm_dp_get_vc_payload_bw(drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
+ mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr,
+
drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
mgr->dpcd[2] &
DP_MAX_LANE_COUNT_MASK);
if (mgr->pbn_div == 0) {
ret = -EINVAL;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 180f97cd74cb..eb04b3cefda2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -70,7 +70,8 @@ static int intel_dp_mst_compute_link_config(struct
intel_encoder *encoder,
slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
connector->port,
crtc_state->pbn,
-
drm_dp_get_vc_payload_bw(crtc_state->port_clock,
+
drm_dp_get_vc_payload_bw(&intel_dp->mst_mgr,
+
crtc_state->port_clock,
crtc_state->lane_count));
if (slots == -EDEADLK)
return slots;
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index bd1c39907b92..20dc705642bd 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -783,7 +783,8 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
-int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count);
+int drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr *mgr,
+int link_rate, int link_lane_count);
int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 19/20] drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using drm_err/drm_dbg_kms()
Next step in the conversion, move everything in drm_dp_dual_mode_helper.c
over to using drm_err() and drm_dbg_kms(). This was done using the
following cocci script:
@@
expression list expr;
@@
(
- DRM_DEBUG_KMS(expr);
+ drm_dbg_kms(dev, expr);
|
- DRM_ERROR(expr);
+ drm_err(dev, expr);
)
And correcting the indentation of the resulting code by hand.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 45 +++
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index dbf9b1fdec63..9faf49354cab 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
#include
@@ -202,8 +203,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(const
struct drm_device *dev,
*/
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_HDMI_ID,
hdmi_id, sizeof(hdmi_id));
- DRM_DEBUG_KMS("DP dual mode HDMI ID: %*pE (err %zd)\n",
- ret ? 0 : (int)sizeof(hdmi_id), hdmi_id, ret);
+ drm_dbg_kms(dev, "DP dual mode HDMI ID: %*pE (err %zd)\n",
+ ret ? 0 : (int)sizeof(hdmi_id), hdmi_id, ret);
if (ret)
return DRM_DP_DUAL_MODE_UNKNOWN;
@@ -221,8 +222,7 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(const
struct drm_device *dev,
*/
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_ADAPTOR_ID,
&adaptor_id, sizeof(adaptor_id));
- DRM_DEBUG_KMS("DP dual mode adaptor ID: %02x (err %zd)\n",
- adaptor_id, ret);
+ drm_dbg_kms(dev, "DP dual mode adaptor ID: %02x (err %zd)\n",
adaptor_id, ret);
if (ret == 0) {
if (is_lspcon_adaptor(hdmi_id, adaptor_id))
return DRM_DP_DUAL_MODE_LSPCON;
@@ -238,8 +238,7 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(const
struct drm_device *dev,
* that we may have misdetected the type.
*/
if (!is_type1_adaptor(adaptor_id) && adaptor_id != hdmi_id[0])
- DRM_ERROR("Unexpected DP dual mode adaptor ID %02x\n",
- adaptor_id);
+ drm_err(dev, "Unexpected DP dual mode adaptor ID
%02x\n", adaptor_id);
}
@@ -286,7 +285,7 @@ int drm_dp_dual_mode_max_tmds_clock(const struct drm_device
*dev, enum drm_dp_du
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_MAX_TMDS_CLOCK,
&max_tmds_clock, sizeof(max_tmds_clock));
if (ret || max_tmds_clock == 0x00 || max_tmds_clock == 0xff) {
- DRM_DEBUG_KMS("Failed to query max TMDS clock\n");
+ drm_dbg_kms(dev, "Failed to query max TMDS clock\n");
return 165000;
}
@@ -326,7 +325,7 @@ int drm_dp_dual_mode_get_tmds_output(const struct
drm_device *dev,
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_TMDS_OEN,
&tmds_oen, sizeof(tmds_oen));
if (ret) {
- DRM_DEBUG_KMS("Failed to query state of TMDS output buffers\n");
+ drm_dbg_kms(dev, "Failed to query state of TMDS output
buffers\n");
return ret;
}
@@ -372,18 +371,17 @@ int drm_dp_dual_mode_set_tmds_output(const struct
drm_device *dev, enum drm_dp_d
ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,
&tmds_oen, sizeof(tmds_oen));
if (ret) {
- DRM_DEBUG_KMS("Failed to %s TMDS output buffers (%d
attempts)\n",
- enable ? "enable" : "disable",
- retry + 1);
+ drm_dbg_kms(dev, "Failed to %s TMDS output buffers (%d
attempts)\n",
+ enable ? "enable" : "disable", retry + 1);
return ret;
}
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_TMDS_OEN,
&tmp, sizeof(tmp));
if (ret) {
- DRM_DEBUG_KMS("I2C read failed during TMDS output
buffer %s (%d attempts)\n",
- enable ? "enabling" : "disabling",
- retry + 1);
+ drm_dbg_kms(dev,
+ "I2C read failed during TMDS output buffer
%s (%d attempts)\n",
+ enable ? &
[PATCH v3 20/20] drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()
And finally, convert all of the code in drm_dp_mst_topology.c over to using
drm_err() and drm_dbg*(). Note that this refactor would have been a lot
more complicated to have tried writing a coccinelle script for, so this
whole thing was done by hand.
v2:
* Fix line-wrapping in drm_dp_mst_atomic_check_mstb_bw_limit()
Signed-off-by: Lyude Paul
Cc: Robert Foss
Reviewed-by: Robert Foss
---
drivers/gpu/drm/drm_dp_mst_topology.c | 368 +-
1 file changed, 187 insertions(+), 181 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 9bac5bd050ab..5539a91b4031 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -286,7 +286,8 @@ static void drm_dp_encode_sideband_msg_hdr(struct
drm_dp_sideband_msg_hdr *hdr,
*len = idx;
}
-static bool drm_dp_decode_sideband_msg_hdr(struct drm_dp_sideband_msg_hdr *hdr,
+static bool drm_dp_decode_sideband_msg_hdr(const struct
drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_sideband_msg_hdr *hdr,
u8 *buf, int buflen, u8 *hdrlen)
{
u8 crc4;
@@ -303,7 +304,7 @@ static bool drm_dp_decode_sideband_msg_hdr(struct
drm_dp_sideband_msg_hdr *hdr,
crc4 = drm_dp_msg_header_crc4(buf, (len * 2) - 1);
if ((crc4 & 0xf) != (buf[len - 1] & 0xf)) {
- DRM_DEBUG_KMS("crc4 mismatch 0x%x 0x%x\n", crc4, buf[len - 1]);
+ drm_dbg_kms(mgr->dev, "crc4 mismatch 0x%x 0x%x\n", crc4,
buf[len - 1]);
return false;
}
@@ -789,7 +790,8 @@ static bool drm_dp_sideband_append_payload(struct
drm_dp_sideband_msg_rx *msg,
return true;
}
-static bool drm_dp_sideband_parse_link_address(struct drm_dp_sideband_msg_rx
*raw,
+static bool drm_dp_sideband_parse_link_address(const struct
drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_sideband_msg_rx
*raw,
struct
drm_dp_sideband_msg_reply_body *repmsg)
{
int idx = 1;
@@ -1014,7 +1016,8 @@ drm_dp_sideband_parse_query_stream_enc_status(
return true;
}
-static bool drm_dp_sideband_parse_reply(struct drm_dp_sideband_msg_rx *raw,
+static bool drm_dp_sideband_parse_reply(const struct drm_dp_mst_topology_mgr
*mgr,
+ struct drm_dp_sideband_msg_rx *raw,
struct drm_dp_sideband_msg_reply_body
*msg)
{
memset(msg, 0, sizeof(*msg));
@@ -1030,7 +1033,7 @@ static bool drm_dp_sideband_parse_reply(struct
drm_dp_sideband_msg_rx *raw,
switch (msg->req_type) {
case DP_LINK_ADDRESS:
- return drm_dp_sideband_parse_link_address(raw, msg);
+ return drm_dp_sideband_parse_link_address(mgr, raw, msg);
case DP_QUERY_PAYLOAD:
return drm_dp_sideband_parse_query_payload_ack(raw, msg);
case DP_REMOTE_DPCD_READ:
@@ -1053,14 +1056,16 @@ static bool drm_dp_sideband_parse_reply(struct
drm_dp_sideband_msg_rx *raw,
case DP_QUERY_STREAM_ENC_STATUS:
return drm_dp_sideband_parse_query_stream_enc_status(raw, msg);
default:
- DRM_ERROR("Got unknown reply 0x%02x (%s)\n", msg->req_type,
- drm_dp_mst_req_type_str(msg->req_type));
+ drm_err(mgr->dev, "Got unknown reply 0x%02x (%s)\n",
+ msg->req_type, drm_dp_mst_req_type_str(msg->req_type));
return false;
}
}
-static bool drm_dp_sideband_parse_connection_status_notify(struct
drm_dp_sideband_msg_rx *raw,
- struct
drm_dp_sideband_msg_req_body *msg)
+static bool
+drm_dp_sideband_parse_connection_status_notify(const struct
drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_sideband_msg_rx
*raw,
+ struct
drm_dp_sideband_msg_req_body *msg)
{
int idx = 1;
@@ -1082,12 +1087,14 @@ static bool
drm_dp_sideband_parse_connection_status_notify(struct drm_dp_sideban
idx++;
return true;
fail_len:
- DRM_DEBUG_KMS("connection status reply parse length fail %d %d\n", idx,
raw->curlen);
+ drm_dbg_kms(mgr->dev, "connection status reply parse length fail %d
%d\n",
+ idx, raw->curlen);
return false;
}
-static bool drm_dp_sideband_parse_resource_status_notify(struct
drm_dp_sideband_msg_rx *raw,
- struct
drm_dp_sideband_msg_req_body *msg)
+static bool drm_dp_sideband_parse_resource_status_notify(const struct
drm_dp_mst_topology_mgr *mgr,
+st
Re: [PATCH v3 03/20] drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini
On Tue, 2021-04-20 at 02:16 +0300, Ville Syrjälä wrote: > > The init vs. register split is intentional. Registering the thing > and allowing userspace access to it before the rest of the driver > is ready isn't particularly great. For a while now we've tried to > move towards an architecture where the driver is fully initialzied > before anything gets exposed to userspace. Yeah-thank you for pointing this out. Thierry - do you think there's an alternate solution we could go with in Tegra to fix the get_device() issue that wouldn't require us trying to expose the i2c adapter early? > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 03/20] drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini
OK - talked with Ville a bit on this and did some of my own research, I actually think that moving i2c to drm_dp_aux_init() is the right decision for the time being. The reasoning behind this being that as shown by my previous work of fixing drivers that call drm_dp_aux_register() too early - it seems like there's already been drivers that have been working just fine with setting up the i2c device before DRM registration. In the future, it'd probably be better if we can split up i2c_add_adapter() into an init and register function - but we'll have to talk with the i2c maintainers to see if this is acceptable w/ them On Thu, 2021-04-22 at 13:18 -0400, Lyude Paul wrote: > On Tue, 2021-04-20 at 02:16 +0300, Ville Syrjälä wrote: > > > > The init vs. register split is intentional. Registering the thing > > and allowing userspace access to it before the rest of the driver > > is ready isn't particularly great. For a while now we've tried to > > move towards an architecture where the driver is fully initialzied > > before anything gets exposed to userspace. > > Yeah-thank you for pointing this out. Thierry - do you think there's an > alternate solution we could go with in Tegra to fix the get_device() issue > that wouldn't require us trying to expose the i2c adapter early? > > > > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 03/20] drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini
On Thu, 2021-04-22 at 18:33 -0400, Lyude Paul wrote: > OK - talked with Ville a bit on this and did some of my own research, I > actually think that moving i2c to drm_dp_aux_init() is the right decision > for > the time being. The reasoning behind this being that as shown by my previous > work of fixing drivers that call drm_dp_aux_register() too early - it seems > like there's already been drivers that have been working just fine with > setting up the i2c device before DRM registration. > > In the future, it'd probably be better if we can split up i2c_add_adapter() > into an init and register function - but we'll have to talk with the i2c > maintainers to see if this is acceptable w/ them Actually - I think adding the ability to refcount dp aux adapters might be a better solution so I'm going to try that! > > On Thu, 2021-04-22 at 13:18 -0400, Lyude Paul wrote: > > On Tue, 2021-04-20 at 02:16 +0300, Ville Syrjälä wrote: > > > > > > The init vs. register split is intentional. Registering the thing > > > and allowing userspace access to it before the rest of the driver > > > is ready isn't particularly great. For a while now we've tried to > > > move towards an architecture where the driver is fully initialzied > > > before anything gets exposed to userspace. > > > > Yeah-thank you for pointing this out. Thierry - do you think there's an > > alternate solution we could go with in Tegra to fix the get_device() issue > > that wouldn't require us trying to expose the i2c adapter early? > > > > > > > > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 03/20] drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini
On Fri, 2021-04-23 at 14:39 +0200, Thierry Reding wrote: > > I'm curious: how is a DP AUX adapter reference count going to solve the > issue of potentially registering devices too early (i.e. before the DRM > is registered)? > > Is it because registering too early could cause a reference count > problem if somebody get a hold of the DP AUX adapter before the parent > DRM device is around? Well currently the problem is that we kind of want to avoid setting up the i2c adapter before the DRM driver is registered with userspace, but it's not really possible to do that if we need the core device struct for the ddc adapter initialized so that tegra can call get_device() on it in drivers/gpu/drm/tegra/sor.c. So my thought is instead of calling get_device() on the ddc adapter that the AUX channel provides, why not just call it on the actual platform device that implements the AUX channel instead? I think this should work pretty nicely while still preventing the platform device for the AUX channel from disappearing before the SOR has disappeared. > > Thierry -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/tegra: Fix device/module refs for DP
This patch series fixes a regression that was introduced by one of the changes I made to when Tegra registers its AUX adapters, along with fixing some reference leaks that I found along the way. !!!NOTE!!! There's one thing I'm not entirely sure about, which is the use of module references (e.g. try_module_get()) here. If I'm understanding how this code worked previously: since the get_device call in tegra_sor_probe() was previously the i2c adapter for the AUX channel - which itself is initialized in drm_dp_aux_register() - then I -think- that the module owner for the DDC adapter would likely have been drm_kms_helper. With these changes, if I'm understanding things correctly we're now just grabbing a module reference for ourselves - something which might not be the best idea? If anyone could confirm if I need to fix this or not that'd be appreciated, along with reviews of course :P Lyude Paul (2): drm/tegra: Get ref for DP AUX channel, not its ddc adapter drm/tegra: Fix DP AUX channel reference leaks drivers/gpu/drm/tegra/sor.c | 25 ++--- 1 file changed, 18 insertions(+), 7 deletions(-) -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/tegra: Get ref for DP AUX channel, not its ddc adapter
While we're taking a reference of the DDC adapter for a DP AUX channel in
tegra_sor_probe() because we're going to be using that adapter with the
SOR, now that we've moved where AUX registration happens the actual device
structure for the DDC adapter isn't initialized yet. Which means that we
can't really take a reference from it to try to keep it around anymore.
This should be fine though, because we can just take a reference of its
parent instead.
Signed-off-by: Lyude Paul
Fixes: 39c17ae60ea9 ("drm/tegra: Don't register DP AUX channels before
connectors")
Cc: Lyude Paul
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/sor.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 7b88261f57bb..4e0e3a63e586 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3739,11 +3739,11 @@ static int tegra_sor_probe(struct platform_device *pdev)
if (!sor->aux)
return -EPROBE_DEFER;
- if (get_device(&sor->aux->ddc.dev)) {
- if (try_module_get(sor->aux->ddc.owner))
+ if (get_device(sor->aux->dev)) {
+ if (try_module_get(sor->aux->dev->driver->owner))
sor->output.ddc = &sor->aux->ddc;
else
- put_device(&sor->aux->ddc.dev);
+ put_device(sor->aux->dev);
}
}
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/tegra: Fix DP AUX channel reference leaks
Noticed while fixing the regression I introduced in Tegra that Tegra seems
to actually never release the device or module references it's grabbing for
the DP AUX channel. So, let's fix that by dropping them when appropriate.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/tegra/sor.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 4e0e3a63e586..474586e18d06 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3772,12 +3772,13 @@ static int tegra_sor_probe(struct platform_device *pdev)
err = tegra_sor_parse_dt(sor);
if (err < 0)
- return err;
+ goto put_aux;
err = tegra_output_probe(&sor->output);
- if (err < 0)
- return dev_err_probe(&pdev->dev, err,
-"failed to probe output\n");
+ if (err < 0) {
+ err = dev_err_probe(&pdev->dev, err, "failed to probe
output\n");
+ goto put_aux;
+ }
if (sor->ops && sor->ops->probe) {
err = sor->ops->probe(sor);
@@ -3966,6 +3967,11 @@ static int tegra_sor_probe(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
remove:
tegra_output_remove(&sor->output);
+put_aux:
+ if (sor->aux && sor->output.ddc) {
+ module_put(sor->aux->dev->driver->owner);
+ put_device(sor->aux->dev);
+ }
return err;
}
@@ -3985,6 +3991,11 @@ static int tegra_sor_remove(struct platform_device *pdev)
tegra_output_remove(&sor->output);
+ if (sor->aux && sor->output.ddc) {
+ module_put(sor->aux->dev->driver->owner);
+ put_device(sor->aux->dev);
+ }
+
return 0;
}
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 00/17] drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers
Since it's been asked quite a few times on some of the various DP related patch series I've submitted to use the new DRM printk helpers, and it technically wasn't really trivial to do this before due to the lack of a consistent way to find a drm_device for an AUX channel, this patch series aims to address this. In this series we: * (NEW! starting from V3) Make sure drm_dbg_*() and friends can handle NULL drm device pointers * Clean-up potentially erroneous usages of drm_dp_aux_init() and drm_dp_aux_register() so that actual AUX registration doesn't happen until we have an associated DRM device * Clean-up any obvious errors in drivers we find along the way * Add a backpointer to the respective drm_device for an AUX channel in drm_dp_aux.drm_dev, and hook it up in every driver with an AUX channel across the tree * Add a new ratelimited print helper we'll need for converting the DP helpers over to using the new DRM printk helpers * Fix any inconsistencies with logging in drm_dp_helper.c so we always have the aux channel name printed * Prepare the various DP helpers so they can find the correct drm_device to use for logging * And finally, convert all of the DP helpers over to using drm_dbg_*() and drm_err(). Major changes in v4: * Don't move i2c aux init into drm_dp_aux_init(), since I think I've found a much better solution to tegra's issues: https://patchwork.freedesktop.org/series/89420/ Lyude Paul (17): drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister drm/dp: Add backpointer to drm_device in drm_dp_aux drm/dp: Clarify DP AUX registration time drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay() drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay() drm/dp: Always print aux channel name in logs drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect() drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_set_tmds_output() drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_max_tmds_clock() drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_get_tmds_output() drm/dp_dual_mode: Pass drm_device to drm_lspcon_(get|set)_mode() drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw() drm/print: Handle potentially NULL drm_devices in drm_dbg_* drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*() drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using drm_err/drm_dbg_kms() drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*() drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 6 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 + .../drm/bridge/analogix/analogix-anx6345.c| 1 + .../drm/bridge/analogix/analogix-anx78xx.c| 1 + .../drm/bridge/analogix/analogix_dp_core.c| 1 + .../drm/bridge/cadence/cdns-mhdp8546-core.c | 12 +- drivers/gpu/drm/bridge/tc358767.c | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 + drivers/gpu/drm/drm_dp_aux_dev.c | 6 + drivers/gpu/drm/drm_dp_dual_mode_helper.c | 68 ++-- drivers/gpu/drm/drm_dp_helper.c | 184 + drivers/gpu/drm/drm_dp_mst_topology.c | 376 +- drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 + .../drm/i915/display/intel_dp_link_training.c | 6 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 7 +- drivers/gpu/drm/i915/display/intel_lspcon.c | 17 +- drivers/gpu/drm/msm/dp/dp_ctrl.c | 6 +- drivers/gpu/drm/msm/edp/edp.h | 3 +- drivers/gpu/drm/msm/edp/edp_aux.c | 5 +- drivers/gpu/drm/msm/edp/edp_ctrl.c| 8 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 26 +- drivers/gpu/drm/radeon/atombios_dp.c | 5 +- drivers/gpu/drm/tegra/dpaux.c | 1 + drivers/gpu/drm/xlnx/zynqmp_dp.c | 5 +- include/drm/drm_dp_dual_mode_helper.h | 14 +- include/drm/drm_dp_helper.h | 19 +- include/drm/drm_dp_mst_helper.h | 3 +- include/drm/drm_print.h | 20 +- 29 files changed, 453 insertions(+), 354 deletions(-) -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 02/17] drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister
Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 61e6d7412505..c04044be3d32 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -401,7 +401,6 @@ nouveau_connector_destroy(struct drm_connector *connector)
drm_connector_cleanup(connector);
if (nv_connector->aux.transfer) {
drm_dp_cec_unregister_connector(&nv_connector->aux);
- drm_dp_aux_unregister(&nv_connector->aux);
kfree(nv_connector->aux.name);
}
kfree(connector);
@@ -905,13 +904,29 @@ nouveau_connector_late_register(struct drm_connector
*connector)
int ret;
ret = nouveau_backlight_init(connector);
+ if (ret)
+ return ret;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ ret = drm_dp_aux_register(&nouveau_connector(connector)->aux);
+ if (ret)
+ goto backlight_fini;
+ }
+
+ return 0;
+backlight_fini:
+ nouveau_backlight_fini(connector);
return ret;
}
static void
nouveau_connector_early_unregister(struct drm_connector *connector)
{
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+ drm_dp_aux_unregister(&nouveau_connector(connector)->aux);
+
nouveau_backlight_fini(connector);
}
@@ -1343,14 +1358,14 @@ nouveau_connector_create(struct drm_device *dev,
snprintf(aux_name, sizeof(aux_name), "sor-%04x-%04x",
dcbe->hasht, dcbe->hashm);
nv_connector->aux.name = kstrdup(aux_name, GFP_KERNEL);
- ret = drm_dp_aux_register(&nv_connector->aux);
+ drm_dp_aux_init(&nv_connector->aux);
if (ret) {
- NV_ERROR(drm, "failed to register aux channel\n");
+ NV_ERROR(drm, "Failed to init AUX adapter for
sor-%04x-%04x: %d\n",
+dcbe->hasht, dcbe->hashm, ret);
kfree(nv_connector);
return ERR_PTR(ret);
}
- funcs = &nouveau_connector_funcs;
- break;
+ fallthrough;
default:
funcs = &nouveau_connector_funcs;
break;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 01/17] drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace
Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 01e95466502a..49e4c340f1de 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -1719,10 +1719,14 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
dev_dbg(mhdp->dev, "%s\n", __func__);
+ ret = drm_dp_aux_register(&mhdp->aux);
+ if (ret < 0)
+ return ret;
+
if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
ret = cdns_mhdp_connector_init(mhdp);
if (ret)
- return ret;
+ goto aux_unregister;
}
spin_lock(&mhdp->start_lock);
@@ -1738,6 +1742,9 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
mhdp->regs + CDNS_APB_INT_MASK);
return 0;
+aux_unregister:
+ drm_dp_aux_unregister(&mhdp->aux);
+ return ret;
}
static void cdns_mhdp_configure_video(struct cdns_mhdp_device *mhdp,
@@ -2082,6 +2089,8 @@ static void cdns_mhdp_detach(struct drm_bridge *bridge)
dev_dbg(mhdp->dev, "%s\n", __func__);
+ drm_dp_aux_unregister(&mhdp->aux);
+
spin_lock(&mhdp->start_lock);
mhdp->bridge_attached = false;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/17] drm/dp: Clarify DP AUX registration time
The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly
correct, except for the fact that they made the assumption that all AUX
devices were grandchildren of their respective DRM devices. This is the
case for most normal GPUs, but is almost never the case with SoCs and
display bridges. So, let's fix this documentation to clarify when the right
time to use drm_dp_aux_init() or drm_dp_aux_register() is.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 45 +++--
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ad73d7264743..9f66153a3c55 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1728,10 +1728,18 @@ EXPORT_SYMBOL(drm_dp_remote_aux_init);
* drm_dp_aux_init() - minimally initialise an aux channel
* @aux: DisplayPort AUX channel
*
- * If you need to use the drm_dp_aux's i2c adapter prior to registering it
- * with the outside world, call drm_dp_aux_init() first. You must still
- * call drm_dp_aux_register() once the connector has been registered to
- * allow userspace access to the auxiliary DP channel.
+ * If you need to use the drm_dp_aux's i2c adapter prior to registering it with
+ * the outside world, call drm_dp_aux_init() first. For drivers which are
+ * grandparents to their AUX adapters (e.g. the AUX adapter is parented by a
+ * &drm_connector), you must still call drm_dp_aux_register() once the
connector
+ * has been registered to allow userspace access to the auxiliary DP channel.
+ * Likewise, for such drivers you should also assign &drm_dp_aux.drm_dev as
+ * early as possible so that the &drm_device that corresponds to the AUX
adapter
+ * may be mentioned in debugging output from the DRM DP helpers.
+ *
+ * For devices which use a separate platform device for their AUX adapters,
this
+ * may be called as early as required by the driver.
+ *
*/
void drm_dp_aux_init(struct drm_dp_aux *aux)
{
@@ -1751,15 +1759,26 @@ EXPORT_SYMBOL(drm_dp_aux_init);
* drm_dp_aux_register() - initialise and register aux channel
* @aux: DisplayPort AUX channel
*
- * Automatically calls drm_dp_aux_init() if this hasn't been done yet.
- * This should only be called when the underlying &struct drm_connector is
- * initialiazed already. Therefore the best place to call this is from
- * &drm_connector_funcs.late_register. Not that drivers which don't follow this
- * will Oops when CONFIG_DRM_DP_AUX_CHARDEV is enabled.
- *
- * Drivers which need to use the aux channel before that point (e.g. at driver
- * load time, before drm_dev_register() has been called) need to call
- * drm_dp_aux_init().
+ * Automatically calls drm_dp_aux_init() if this hasn't been done yet. This
+ * should only be called once the parent of @aux, &drm_dp_aux.dev, is
+ * initialized. For devices which are grandparents of their AUX channels,
+ * &drm_dp_aux.dev will typically be the &drm_connector &device which
+ * corresponds to @aux. For these devices, it's advised to call
+ * drm_dp_aux_register() in &drm_connector_funcs.late_register, and likewise to
+ * call drm_dp_aux_unregister() in &drm_connector_funcs.early_unregister.
+ * Functions which don't follow this will likely Oops when
+ * %CONFIG_DRM_DP_AUX_CHARDEV is enabled.
+ *
+ * For devices where the AUX channel is a device that exists independently of
+ * the &drm_device that uses it, such as SoCs and bridge devices, it is
+ * recommended to call drm_dp_aux_register() after a &drm_device has been
+ * assigned to &drm_dp_aux.drm_dev, and likewise to call
+ * drm_dp_aux_unregister() once the &drm_device should no longer be associated
+ * with the AUX channel (e.g. on bridge detach).
+ *
+ * Drivers which need to use the aux channel before either of the two points
+ * mentioned above need to call drm_dp_aux_init() in order to use the AUX
+ * channel before registration.
*
* Returns 0 on success or a negative error code on failure.
*/
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/17] drm/dp: Add backpointer to drm_device in drm_dp_aux
This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for doing so.
Note that there is one limitation with this - because some DP AUX adapters
exist as platform devices which are initialized independently of their
respective DRM devices, one cannot rely on drm_dp_aux->drm_dev to always be
non-NULL until drm_dp_aux_register() has been called. We make sure to point
this out in the documentation for struct drm_dp_aux.
v3:
* Add WARN_ON_ONCE() to drm_dp_aux_register() if drm_dev isn't filled out
Signed-off-by: Lyude Paul
Acked-by: Thierry Reding
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 ++
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 +
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 1 +
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 1 +
drivers/gpu/drm/bridge/tc358767.c| 1 +
drivers/gpu/drm/bridge/ti-sn65dsi86.c| 1 +
drivers/gpu/drm/drm_dp_aux_dev.c | 6 ++
drivers/gpu/drm/drm_dp_helper.c | 2 ++
drivers/gpu/drm/drm_dp_mst_topology.c| 1 +
drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 +
drivers/gpu/drm/msm/edp/edp.h| 3 +--
drivers/gpu/drm/msm/edp/edp_aux.c| 5 +++--
drivers/gpu/drm/msm/edp/edp_ctrl.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 1 +
drivers/gpu/drm/radeon/atombios_dp.c | 1 +
drivers/gpu/drm/tegra/dpaux.c| 1 +
drivers/gpu/drm/xlnx/zynqmp_dp.c | 1 +
include/drm/drm_dp_helper.h | 9 -
20 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index a3ba9ca11e98..062625a8a4ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -188,6 +188,8 @@ void amdgpu_atombios_dp_aux_init(struct amdgpu_connector
*amdgpu_connector)
{
amdgpu_connector->ddc_bus->rec.hpd = amdgpu_connector->hpd.hpd;
amdgpu_connector->ddc_bus->aux.transfer =
amdgpu_atombios_dp_aux_transfer;
+ amdgpu_connector->ddc_bus->aux.drm_dev = amdgpu_connector->base.dev;
+
drm_dp_aux_init(&amdgpu_connector->ddc_bus->aux);
amdgpu_connector->ddc_bus->has_aux = true;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 73cdb9fe981a..997567f6f0ba 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -433,6 +433,7 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
kasprintf(GFP_KERNEL, "AMDGPU DM aux hw bus %d",
link_index);
aconnector->dm_dp_aux.aux.transfer = dm_dp_aux_transfer;
+ aconnector->dm_dp_aux.aux.drm_dev = dm->ddev;
aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc;
drm_dp_aux_init(&aconnector->dm_dp_aux.aux);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index aa6cda458eb9..e33cd077595a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -537,6 +537,7 @@ static int anx6345_bridge_attach(struct drm_bridge *bridge,
/* Register aux channel */
anx6345->aux.name = "DP-AUX";
anx6345->aux.dev = &anx6345->client->dev;
+ anx6345->aux.drm_dev = bridge->dev;
anx6345->aux.transfer = anx6345_aux_transfer;
err = drm_dp_aux_register(&anx6345->aux);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index f20558618220..5e6a0ed39199 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -905,6 +905,7 @@ static int anx78xx_bridge_attach(struct drm_bridge *bridge,
/* Register aux channel */
anx78xx->aux.name = "DP-AUX";
anx78xx->aux.dev = &anx78xx->client->dev;
+ anx78xx->aux.drm_dev = bridge->dev;
anx78xx->aux.transfer = anx78xx_aux_transfer;
err = drm_dp_aux_register(&anx7
[PATCH v4 05/17] drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
drivers/gpu/drm/msm/edp/edp_ctrl.c| 2 +-
drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
include/drm/drm_dp_helper.h | 4 +++-
8 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 062625a8a4ec..92d76f4cfdfc 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -612,7 +612,7 @@ amdgpu_atombios_dp_link_train_cr(struct
amdgpu_atombios_dp_link_train_info *dp_i
dp_info->tries = 0;
voltage = 0xff;
while (1) {
- drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
+ drm_dp_link_train_clock_recovery_delay(dp_info->aux,
dp_info->dpcd);
if (drm_dp_dpcd_read_link_status(dp_info->aux,
dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 9f66153a3c55..f71b035a48b4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -132,7 +132,8 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZ
}
EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
-void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
+void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 591ddc4b876c..198ddb3c173a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -513,7 +513,7 @@ static void
intel_dp_link_training_clock_recovery_delay(struct intel_dp *intel_d
enum drm_dp_phy dp_phy)
{
if (dp_phy == DP_PHY_DPRX)
- drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
+ drm_dp_link_train_clock_recovery_delay(&intel_dp->aux,
intel_dp->dpcd);
else
drm_dp_lttpr_link_train_clock_recovery_delay();
}
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 1390f3547fde..264a9eae87d3 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1103,7 +1103,7 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private
*ctrl,
tries = 0;
old_v_level = ctrl->link->phy_params.v_level;
for (tries = 0; tries < maximum_retries; tries++) {
- drm_dp_link_train_clock_recovery_delay(ctrl->panel->dpcd);
+ drm_dp_link_train_clock_recovery_delay(ctrl->aux,
ctrl->panel->dpcd);
ret = dp_ctrl_read_link_status(ctrl, link_status);
if (ret)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 57af3d8b6699..6501598448b4 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -608,7 +608,7 @@ static int edp_start_link_train_1(struct edp_ctrl *ctrl)
tries = 0;
old_v_level = ctrl->v_level;
while (1) {
- drm_dp_link_train_clock_recovery_delay(ctrl->dpcd);
+ drm_dp_link_train_clock_recovery_delay(ctrl->drm_aux,
ctrl->dpcd);
rlen = drm_dp_dpcd_read_link_status(ctrl->drm_aux, link_status);
if (rlen < DP_LINK_STATUS_SIZE) {
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index c50c504bad50..299b9d8da376 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -680,7 +680,7 @@ static int radeon_dp_link_train_cr(struct
radeon_dp_link_train_info *dp_info)
dp_info->tries = 0;
voltage = 0xff;
while (1) {
- drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
+ drm_dp_link_train_clock_recovery_delay(dp_info->aux,
dp_info->dpcd);
if (drm_dp_dpcd_read_link_status(dp_info->aux,
dp_
[PATCH v4 07/17] drm/dp: Always print aux channel name in logs
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a2047dae3ab7..b50e572b544d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -139,8 +139,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct
drm_dp_aux *aux,
DP_TRAINING_AUX_RD_MASK;
if (rd_interval > 4)
- DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
- rd_interval);
+ DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
+ aux->name, rd_interval);
if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
rd_interval = 100;
@@ -155,8 +155,8 @@ static void __drm_dp_link_train_channel_eq_delay(const
struct drm_dp_aux *aux,
unsigned long rd_interval)
{
if (rd_interval > 4)
- DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
- rd_interval);
+ DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
+ aux->name, rd_interval);
if (rd_interval == 0)
rd_interval = 400;
@@ -2781,7 +2781,7 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux)
if (ret < 0)
return ret;
if (!(buf & DP_PCON_ENABLE_SOURCE_CTL_MODE)) {
- DRM_DEBUG_KMS("PCON in Autonomous mode, can't enable FRL\n");
+ DRM_DEBUG_KMS("%s: PCON in Autonomous mode, can't enable
FRL\n", aux->name);
return -EINVAL;
}
buf |= DP_PCON_ENABLE_HDMI_LINK;
@@ -2876,7 +2876,8 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct
drm_dp_aux *aux,
num_error = 0;
}
- DRM_ERROR("More than %d errors since the last read for lane
%d", num_error, i);
+ DRM_ERROR("%s: More than %d errors since the last read for lane
%d",
+ aux->name, num_error, i);
}
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 06/17] drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay()
So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c| 14 +-
.../gpu/drm/i915/display/intel_dp_link_training.c | 4 ++--
drivers/gpu/drm/msm/dp/dp_ctrl.c | 4 ++--
drivers/gpu/drm/msm/edp/edp_ctrl.c | 4 ++--
drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
include/drm/drm_dp_helper.h| 6 --
8 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 92d76f4cfdfc..f327becb022f 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -677,7 +677,7 @@ amdgpu_atombios_dp_link_train_ce(struct
amdgpu_atombios_dp_link_train_info *dp_i
dp_info->tries = 0;
channel_eq = false;
while (1) {
- drm_dp_link_train_channel_eq_delay(dp_info->dpcd);
+ drm_dp_link_train_channel_eq_delay(dp_info->aux, dp_info->dpcd);
if (drm_dp_dpcd_read_link_status(dp_info->aux,
dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f71b035a48b4..a2047dae3ab7 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -151,7 +151,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct
drm_dp_aux *aux,
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
-static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
+static void __drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+unsigned long rd_interval)
{
if (rd_interval > 4)
DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
@@ -165,9 +166,11 @@ static void __drm_dp_link_train_channel_eq_delay(unsigned
long rd_interval)
usleep_range(rd_interval, rd_interval * 2);
}
-void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+void drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
- __drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ __drm_dp_link_train_channel_eq_delay(aux,
+dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK);
}
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
@@ -183,13 +186,14 @@ static u8 dp_lttpr_phy_cap(const u8
phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
}
-void drm_dp_lttpr_link_train_channel_eq_delay(const u8
phy_cap[DP_LTTPR_PHY_CAP_SIZE])
+void drm_dp_lttpr_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+ const u8
phy_cap[DP_LTTPR_PHY_CAP_SIZE])
{
u8 interval = dp_lttpr_phy_cap(phy_cap,
DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1) &
DP_TRAINING_AUX_RD_MASK;
- __drm_dp_link_train_channel_eq_delay(interval);
+ __drm_dp_link_train_channel_eq_delay(aux, interval);
}
EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 198ddb3c173a..6bf6f1ec13ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -665,11 +665,11 @@ intel_dp_link_training_channel_equalization_delay(struct
intel_dp *intel_dp,
enum drm_dp_phy dp_phy)
{
if (dp_phy == DP_PHY_DPRX) {
- drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
+ drm_dp_link_train_channel_eq_delay(&intel_dp->aux,
intel_dp->dpcd);
} else {
const u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
- drm_dp_lttpr_link_train_channel_eq_delay(phy_caps);
+ drm_dp_lttpr_link_train_channel_eq_delay(&intel_dp->aux,
phy_caps);
}
}
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 264a9eae87d3..2cebd17a7289 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1184,7 +1184,7 @@ static int dp_ctrl_link_lane_down_shift(struct
dp_ctrl_private *ctrl)
static void dp_ctrl_clear_training_pattern(struc
[PATCH v4 08/17] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect()
Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll
need to be able to access the DRM device in the dual mode DP helpers as
well. Note however that since drm_dp_dual_mode_detect() can be called with
DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down
the drm_device to these functions instead of using drm_dp_aux.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 4 +++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
drivers/gpu/drm/i915/display/intel_lspcon.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h | 4 +++-
4 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 1c9ea9f7fdaf..9ee75c568c37 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -165,6 +165,7 @@ static bool is_lspcon_adaptor(const char
hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
/**
* drm_dp_dual_mode_detect - Identify the DP dual mode adaptor
+ * @dev: &drm_device to use
* @adapter: I2C adapter for the DDC bus
*
* Attempt to identify the type of the DP dual mode adaptor used.
@@ -178,7 +179,8 @@ static bool is_lspcon_adaptor(const char
hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
* Returns:
* The type of the DP dual mode adaptor used
*/
-enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct i2c_adapter *adapter)
+enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(const struct drm_device
*dev,
+ struct i2c_adapter *adapter)
{
char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN] = {};
uint8_t adaptor_id = 0x00;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 47a8f0a1c5e2..08fb98dac169 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2224,7 +2224,7 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector
*connector, bool has_edid)
enum port port = hdmi_to_dig_port(hdmi)->base.port;
struct i2c_adapter *adapter =
intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
- enum drm_dp_dual_mode_type type = drm_dp_dual_mode_detect(adapter);
+ enum drm_dp_dual_mode_type type =
drm_dp_dual_mode_detect(&dev_priv->drm, adapter);
/*
* Type 1 DVI adaptors are not required to implement any
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index e4ff533e3a69..ca25044e7d1b 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -221,7 +221,8 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
{
int retry;
enum drm_dp_dual_mode_type adaptor_type;
- struct i2c_adapter *adapter = &lspcon_to_intel_dp(lspcon)->aux.ddc;
+ struct intel_dp *intel_dp = lspcon_to_intel_dp(lspcon);
+ struct i2c_adapter *adapter = &intel_dp->aux.ddc;
enum drm_lspcon_mode expected_mode;
expected_mode = lspcon_wake_native_aux_ch(lspcon) ?
@@ -232,7 +233,7 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
if (retry)
usleep_range(500, 1000);
- adaptor_type = drm_dp_dual_mode_detect(adapter);
+ adaptor_type = drm_dp_dual_mode_detect(intel_dp->aux.drm_dev,
adapter);
if (adaptor_type == DRM_DP_DUAL_MODE_LSPCON)
break;
}
diff --git a/include/drm/drm_dp_dual_mode_helper.h
b/include/drm/drm_dp_dual_mode_helper.h
index 4c42db81fcb4..23ce849152f3 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -62,6 +62,7 @@
#define DP_DUAL_MODE_LSPCON_CURRENT_MODE 0x41
#define DP_DUAL_MODE_LSPCON_MODE_PCON 0x1
+struct drm_device;
struct i2c_adapter;
ssize_t drm_dp_dual_mode_read(struct i2c_adapter *adapter,
@@ -103,7 +104,8 @@ enum drm_dp_dual_mode_type {
DRM_DP_DUAL_MODE_LSPCON,
};
-enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct i2c_adapter
*adapter);
+enum drm_dp_dual_mode_type
+drm_dp_dual_mode_detect(const struct drm_device *dev, struct i2c_adapter
*adapter);
int drm_dp_dual_mode_max_tmds_clock(enum drm_dp_dual_mode_type type,
struct i2c_adapter *adapter);
int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/17] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_set_tmds_output()
Another function that we'll need to pass a drm_device (and not drm_dp_aux)
down to so that we can move over to using drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
include/drm/drm_dp_dual_mode_helper.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 9ee75c568c37..a63d7de85309 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -336,6 +336,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_get_tmds_output);
/**
* drm_dp_dual_mode_set_tmds_output - Enable/disable TMDS output buffers in
the DP dual mode adaptor
+ * @dev: &drm_device to use
* @type: DP dual mode adaptor type
* @adapter: I2C adapter for the DDC bus
* @enable: enable (as opposed to disable) the TMDS output buffers
@@ -349,7 +350,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_get_tmds_output);
* Returns:
* 0 on success, negative error code on failure
*/
-int drm_dp_dual_mode_set_tmds_output(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_set_tmds_output(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter, bool enable)
{
uint8_t tmds_oen = enable ? 0 : DP_DUAL_MODE_TMDS_DISABLE;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 08fb98dac169..fc3e7a9396b5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1251,8 +1251,7 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi
*hdmi, bool enable)
drm_dbg_kms(&dev_priv->drm, "%s DP dual mode adaptor TMDS output\n",
enable ? "Enabling" : "Disabling");
- drm_dp_dual_mode_set_tmds_output(hdmi->dp_dual_mode.type,
-adapter, enable);
+ drm_dp_dual_mode_set_tmds_output(&dev_priv->drm,
hdmi->dp_dual_mode.type, adapter, enable);
}
static int intel_hdmi_hdcp_read(struct intel_digital_port *dig_port,
diff --git a/include/drm/drm_dp_dual_mode_helper.h
b/include/drm/drm_dp_dual_mode_helper.h
index 23ce849152f3..8cb0dcd98a99 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -110,7 +110,7 @@ int drm_dp_dual_mode_max_tmds_clock(enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter);
int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
struct i2c_adapter *adapter, bool
*enabled);
-int drm_dp_dual_mode_set_tmds_output(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_set_tmds_output(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter, bool enable);
const char *drm_dp_get_dual_mode_type_name(enum drm_dp_dual_mode_type type);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 12/17] drm/dp_dual_mode: Pass drm_device to drm_lspcon_(get|set)_mode()
So that we can start using drm_dbg_*() throughout the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +---
drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++-
include/drm/drm_dp_dual_mode_helper.h | 4 ++--
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index c9c2952bcad2..dbf9b1fdec63 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -430,6 +430,7 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
/**
* drm_lspcon_get_mode: Get LSPCON's current mode of operation by
* reading offset (0x80, 0x41)
+ * @dev: &drm_device to use
* @adapter: I2C-over-aux adapter
* @mode: current lspcon mode of operation output variable
*
@@ -437,7 +438,7 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
* 0 on success, sets the current_mode value to appropriate mode
* -error on failure
*/
-int drm_lspcon_get_mode(struct i2c_adapter *adapter,
+int drm_lspcon_get_mode(const struct drm_device *dev, struct i2c_adapter
*adapter,
enum drm_lspcon_mode *mode)
{
u8 data;
@@ -477,13 +478,14 @@ EXPORT_SYMBOL(drm_lspcon_get_mode);
/**
* drm_lspcon_set_mode: Change LSPCON's mode of operation by
* writing offset (0x80, 0x40)
+ * @dev: &drm_device to use
* @adapter: I2C-over-aux adapter
* @mode: required mode of operation
*
* Returns:
* 0 on success, -error on failure/timeout
*/
-int drm_lspcon_set_mode(struct i2c_adapter *adapter,
+int drm_lspcon_set_mode(const struct drm_device *dev, struct i2c_adapter
*adapter,
enum drm_lspcon_mode mode)
{
u8 data = 0;
@@ -508,7 +510,7 @@ int drm_lspcon_set_mode(struct i2c_adapter *adapter,
* so wait and retry until time out or done.
*/
do {
- ret = drm_lspcon_get_mode(adapter, ¤t_mode);
+ ret = drm_lspcon_get_mode(dev, adapter, ¤t_mode);
if (ret) {
DRM_ERROR("can't confirm LSPCON mode change\n");
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index ca25044e7d1b..ec0048024746 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -139,10 +139,11 @@ void lspcon_detect_hdr_capability(struct intel_lspcon
*lspcon)
static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon
*lspcon)
{
+ struct intel_dp *intel_dp = lspcon_to_intel_dp(lspcon);
enum drm_lspcon_mode current_mode;
- struct i2c_adapter *adapter = &lspcon_to_intel_dp(lspcon)->aux.ddc;
+ struct i2c_adapter *adapter = &intel_dp->aux.ddc;
- if (drm_lspcon_get_mode(adapter, ¤t_mode)) {
+ if (drm_lspcon_get_mode(intel_dp->aux.drm_dev, adapter, ¤t_mode))
{
DRM_DEBUG_KMS("Error reading LSPCON mode\n");
return DRM_LSPCON_MODE_INVALID;
}
@@ -175,11 +176,12 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct
intel_lspcon *lspcon,
static int lspcon_change_mode(struct intel_lspcon *lspcon,
enum drm_lspcon_mode mode)
{
+ struct intel_dp *intel_dp = lspcon_to_intel_dp(lspcon);
int err;
enum drm_lspcon_mode current_mode;
- struct i2c_adapter *adapter = &lspcon_to_intel_dp(lspcon)->aux.ddc;
+ struct i2c_adapter *adapter = &intel_dp->aux.ddc;
- err = drm_lspcon_get_mode(adapter, ¤t_mode);
+ err = drm_lspcon_get_mode(intel_dp->aux.drm_dev, adapter,
¤t_mode);
if (err) {
DRM_ERROR("Error reading LSPCON mode\n");
return err;
@@ -190,7 +192,7 @@ static int lspcon_change_mode(struct intel_lspcon *lspcon,
return 0;
}
- err = drm_lspcon_set_mode(adapter, mode);
+ err = drm_lspcon_set_mode(intel_dp->aux.drm_dev, adapter, mode);
if (err < 0) {
DRM_ERROR("LSPCON mode change failed\n");
return err;
diff --git a/include/drm/drm_dp_dual_mode_helper.h
b/include/drm/drm_dp_dual_mode_helper.h
index 01eec9ff5962..7ee482265087 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -114,8 +114,8 @@ int drm_dp_dual_mode_set_tmds_output(const struct
drm_device *dev, enum drm_dp_d
struct i2c_adapter *adapter, bool enable);
const char *drm_dp_get_dual_mode_type_name(enum drm_dp_dual_mode_type type);
-int drm_lspcon_get_mode(struct i2c_adapter *adapter,
+int drm_lspcon_get_mode(const struct drm_device *dev, struct i2c_adapter
*adapter,
enum drm_lspcon_mode *current_mode);
-int drm_lspcon_set_mode(struct i2
[PATCH v4 11/17] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_get_tmds_output()
Another function to pass drm_device * down to so we can start using the
drm_dbg_*() in the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 4a26b3e1f78f..c9c2952bcad2 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -296,6 +296,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_max_tmds_clock);
/**
* drm_dp_dual_mode_get_tmds_output - Get the state of the TMDS output buffers
in the DP dual mode adaptor
+ * @dev: &drm_device to use
* @type: DP dual mode adaptor type
* @adapter: I2C adapter for the DDC bus
* @enabled: current state of the TMDS output buffers
@@ -310,8 +311,8 @@ EXPORT_SYMBOL(drm_dp_dual_mode_max_tmds_clock);
* Returns:
* 0 on success, negative error code on failure
*/
-int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
-struct i2c_adapter *adapter,
+int drm_dp_dual_mode_get_tmds_output(const struct drm_device *dev,
+enum drm_dp_dual_mode_type type, struct
i2c_adapter *adapter,
bool *enabled)
{
uint8_t tmds_oen;
diff --git a/include/drm/drm_dp_dual_mode_helper.h
b/include/drm/drm_dp_dual_mode_helper.h
index aabf9c951380..01eec9ff5962 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -108,7 +108,7 @@ enum drm_dp_dual_mode_type
drm_dp_dual_mode_detect(const struct drm_device *dev, struct i2c_adapter
*adapter);
int drm_dp_dual_mode_max_tmds_clock(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter);
-int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_get_tmds_output(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter, bool
*enabled);
int drm_dp_dual_mode_set_tmds_output(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter, bool enable);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/17] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_max_tmds_clock()
Another function we need to pass drm_device down to in order to start using
drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
include/drm/drm_dp_dual_mode_helper.h | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index a63d7de85309..4a26b3e1f78f 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -252,6 +252,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_detect);
/**
* drm_dp_dual_mode_max_tmds_clock - Max TMDS clock for DP dual mode adaptor
+ * @dev: &drm_device to use
* @type: DP dual mode adaptor type
* @adapter: I2C adapter for the DDC bus
*
@@ -265,7 +266,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_detect);
* Returns:
* Maximum supported TMDS clock rate for the DP dual mode adaptor in kHz.
*/
-int drm_dp_dual_mode_max_tmds_clock(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_max_tmds_clock(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter)
{
uint8_t max_tmds_clock;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index fc3e7a9396b5..46de56af33db 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2256,7 +2256,7 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector
*connector, bool has_edid)
hdmi->dp_dual_mode.type = type;
hdmi->dp_dual_mode.max_tmds_clock =
- drm_dp_dual_mode_max_tmds_clock(type, adapter);
+ drm_dp_dual_mode_max_tmds_clock(&dev_priv->drm, type, adapter);
drm_dbg_kms(&dev_priv->drm,
"DP dual mode adaptor (%s) detected (max TMDS clock: %d
kHz)\n",
diff --git a/include/drm/drm_dp_dual_mode_helper.h
b/include/drm/drm_dp_dual_mode_helper.h
index 8cb0dcd98a99..aabf9c951380 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -106,7 +106,7 @@ enum drm_dp_dual_mode_type {
enum drm_dp_dual_mode_type
drm_dp_dual_mode_detect(const struct drm_device *dev, struct i2c_adapter
*adapter);
-int drm_dp_dual_mode_max_tmds_clock(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_max_tmds_clock(const struct drm_device *dev, enum
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter);
int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
struct i2c_adapter *adapter, bool
*enabled);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 16/17] drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using drm_err/drm_dbg_kms()
Next step in the conversion, move everything in drm_dp_dual_mode_helper.c
over to using drm_err() and drm_dbg_kms(). This was done using the
following cocci script:
@@
expression list expr;
@@
(
- DRM_DEBUG_KMS(expr);
+ drm_dbg_kms(dev, expr);
|
- DRM_ERROR(expr);
+ drm_err(dev, expr);
)
And correcting the indentation of the resulting code by hand.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 45 +++
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index dbf9b1fdec63..9faf49354cab 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
#include
@@ -202,8 +203,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(const
struct drm_device *dev,
*/
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_HDMI_ID,
hdmi_id, sizeof(hdmi_id));
- DRM_DEBUG_KMS("DP dual mode HDMI ID: %*pE (err %zd)\n",
- ret ? 0 : (int)sizeof(hdmi_id), hdmi_id, ret);
+ drm_dbg_kms(dev, "DP dual mode HDMI ID: %*pE (err %zd)\n",
+ ret ? 0 : (int)sizeof(hdmi_id), hdmi_id, ret);
if (ret)
return DRM_DP_DUAL_MODE_UNKNOWN;
@@ -221,8 +222,7 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(const
struct drm_device *dev,
*/
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_ADAPTOR_ID,
&adaptor_id, sizeof(adaptor_id));
- DRM_DEBUG_KMS("DP dual mode adaptor ID: %02x (err %zd)\n",
- adaptor_id, ret);
+ drm_dbg_kms(dev, "DP dual mode adaptor ID: %02x (err %zd)\n",
adaptor_id, ret);
if (ret == 0) {
if (is_lspcon_adaptor(hdmi_id, adaptor_id))
return DRM_DP_DUAL_MODE_LSPCON;
@@ -238,8 +238,7 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(const
struct drm_device *dev,
* that we may have misdetected the type.
*/
if (!is_type1_adaptor(adaptor_id) && adaptor_id != hdmi_id[0])
- DRM_ERROR("Unexpected DP dual mode adaptor ID %02x\n",
- adaptor_id);
+ drm_err(dev, "Unexpected DP dual mode adaptor ID
%02x\n", adaptor_id);
}
@@ -286,7 +285,7 @@ int drm_dp_dual_mode_max_tmds_clock(const struct drm_device
*dev, enum drm_dp_du
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_MAX_TMDS_CLOCK,
&max_tmds_clock, sizeof(max_tmds_clock));
if (ret || max_tmds_clock == 0x00 || max_tmds_clock == 0xff) {
- DRM_DEBUG_KMS("Failed to query max TMDS clock\n");
+ drm_dbg_kms(dev, "Failed to query max TMDS clock\n");
return 165000;
}
@@ -326,7 +325,7 @@ int drm_dp_dual_mode_get_tmds_output(const struct
drm_device *dev,
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_TMDS_OEN,
&tmds_oen, sizeof(tmds_oen));
if (ret) {
- DRM_DEBUG_KMS("Failed to query state of TMDS output buffers\n");
+ drm_dbg_kms(dev, "Failed to query state of TMDS output
buffers\n");
return ret;
}
@@ -372,18 +371,17 @@ int drm_dp_dual_mode_set_tmds_output(const struct
drm_device *dev, enum drm_dp_d
ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,
&tmds_oen, sizeof(tmds_oen));
if (ret) {
- DRM_DEBUG_KMS("Failed to %s TMDS output buffers (%d
attempts)\n",
- enable ? "enable" : "disable",
- retry + 1);
+ drm_dbg_kms(dev, "Failed to %s TMDS output buffers (%d
attempts)\n",
+ enable ? "enable" : "disable", retry + 1);
return ret;
}
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_TMDS_OEN,
&tmp, sizeof(tmp));
if (ret) {
- DRM_DEBUG_KMS("I2C read failed during TMDS output
buffer %s (%d attempts)\n",
- enable ? "enabling" : "disabling",
- retry + 1);
+ drm_dbg_kms(dev,
+ "I2C read failed during TMDS output buffer
%s (%d attempts)\n",
+ enable ? &
[PATCH v4 15/17] drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()
Now that we've added a back-pointer to drm_device to drm_dp_aux, made
drm_dp_aux available to any functions in drm_dp_helper.c which need to
print to the kernel log, and ensured all of our logging uses a consistent
format, let's do the final step of the conversion and actually move
everything over to using drm_err() and drm_dbg_*().
This was done by using the following cocci script:
@@
expression list expr;
@@
(
- DRM_DEBUG_KMS(expr);
+ drm_dbg_kms(aux->drm_dev, expr);
|
- DRM_DEBUG_DP(expr);
+ drm_dbg_dp(aux->drm_dev, expr);
|
- DRM_DEBUG_ATOMIC(expr);
+ drm_dbg_atomic(aux->drm_dev, expr);
|
- DRM_DEBUG_KMS_RATELIMITED(expr);
+ drm_dbg_kms_ratelimited(aux->drm_dev, expr);
|
- DRM_ERROR(expr);
+ drm_err(aux->drm_dev, expr);
)
Followed by correcting the resulting line-wrapping in the results by hand.
v2:
* Fix indenting in drm_dp_dump_access
Signed-off-by: Lyude Paul
Cc: Robert Foss
Reviewed-by: Robert Foss
---
drivers/gpu/drm/drm_dp_helper.c | 121
1 file changed, 59 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index b50e572b544d..cb56d74e9d38 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -139,8 +139,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct
drm_dp_aux *aux,
DP_TRAINING_AUX_RD_MASK;
if (rd_interval > 4)
- DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
- aux->name, rd_interval);
+ drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range
(max 4)\n",
+ aux->name, rd_interval);
if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
rd_interval = 100;
@@ -155,8 +155,8 @@ static void __drm_dp_link_train_channel_eq_delay(const
struct drm_dp_aux *aux,
unsigned long rd_interval)
{
if (rd_interval > 4)
- DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
- aux->name, rd_interval);
+ drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range
(max 4)\n",
+ aux->name, rd_interval);
if (rd_interval == 0)
rd_interval = 400;
@@ -220,11 +220,11 @@ drm_dp_dump_access(const struct drm_dp_aux *aux,
const char *arrow = request == DP_AUX_NATIVE_READ ? "->" : "<-";
if (ret > 0)
- DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
-aux->name, offset, arrow, ret, min(ret, 20),
buffer);
+ drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
+ aux->name, offset, arrow, ret, min(ret, 20), buffer);
else
- DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d)\n",
-aux->name, offset, arrow, ret);
+ drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d)\n",
+ aux->name, offset, arrow, ret);
}
/**
@@ -287,8 +287,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
err = ret;
}
- DRM_DEBUG_KMS("%s: Too many retries, giving up. First error: %d\n",
- aux->name, err);
+ drm_dbg_kms(aux->drm_dev, "%s: Too many retries, giving up. First
error: %d\n",
+ aux->name, err);
ret = err;
unlock:
@@ -524,44 +524,44 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux
*aux,
if (drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR,
&auto_test_req, 1) < 1) {
- DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
- aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
+ drm_err(aux->drm_dev, "%s: DPCD failed read at register 0x%x\n",
+ aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
return false;
}
auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
if (drm_dp_dpcd_read(aux, DP_TEST_REQUEST, &link_edid_read, 1) < 1) {
- DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
- aux->name, DP_TEST_REQUEST);
+ drm_err(aux->drm_dev, "%s: DPCD failed read at register 0x%x\n",
+ aux->name, DP_TEST_REQUEST);
return false;
}
link_edid_read &= DP_TEST_LINK_EDID_READ;
if (!auto_test_req || !link_edid_read) {
- DRM_DEBUG_KMS("%s: Source
[PATCH v4 13/17] drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw()
Since this is one of the few functions in drm_dp_mst_topology.c that
doesn't have any way of getting access to a drm_device, let's pass the
drm_dp_mst_topology_mgr down to this function so that it can use
drm_dbg_kms().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 +--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ++-
include/drm/drm_dp_mst_helper.h | 3 ++-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 276f7f054d62..9bac5bd050ab 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3638,6 +3638,7 @@ static int drm_dp_send_up_ack_reply(struct
drm_dp_mst_topology_mgr *mgr,
/**
* drm_dp_get_vc_payload_bw - get the VC payload BW for an MST link
+ * @mgr: The &drm_dp_mst_topology_mgr to use
* @link_rate: link rate in 10kbits/s units
* @link_lane_count: lane count
*
@@ -3646,7 +3647,8 @@ static int drm_dp_send_up_ack_reply(struct
drm_dp_mst_topology_mgr *mgr,
* convert the number of PBNs required for a given stream to the number of
* timeslots this stream requires in each MTP.
*/
-int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count)
+int drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr *mgr,
+int link_rate, int link_lane_count)
{
if (link_rate == 0 || link_lane_count == 0)
DRM_DEBUG_KMS("invalid link rate/lane count: (%d / %d)\n",
@@ -3711,7 +3713,8 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
goto out_unlock;
}
- mgr->pbn_div =
drm_dp_get_vc_payload_bw(drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
+ mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr,
+
drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
mgr->dpcd[2] &
DP_MAX_LANE_COUNT_MASK);
if (mgr->pbn_div == 0) {
ret = -EINVAL;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 180f97cd74cb..eb04b3cefda2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -70,7 +70,8 @@ static int intel_dp_mst_compute_link_config(struct
intel_encoder *encoder,
slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
connector->port,
crtc_state->pbn,
-
drm_dp_get_vc_payload_bw(crtc_state->port_clock,
+
drm_dp_get_vc_payload_bw(&intel_dp->mst_mgr,
+
crtc_state->port_clock,
crtc_state->lane_count));
if (slots == -EDEADLK)
return slots;
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index bd1c39907b92..20dc705642bd 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -783,7 +783,8 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
-int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count);
+int drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr *mgr,
+int link_rate, int link_lane_count);
int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 14/17] drm/print: Handle potentially NULL drm_devices in drm_dbg_*
While this shouldn't really be something that happens all that often, since we're going to be using the drm_dbg_* log helpers in DRM helpers it's technically possible that a driver could use an AUX adapter before it's been associated with it's respective drm_device. While drivers should take care to avoid this, there's likely going to be situations where it's difficult to workaround. And since other logging helpers in the kernel tend to be OK with NULL pointers (for instance, passing a NULL pointer to a "%s" argument for a printk-like function in the kernel doesn't break anything), we should do the same for ours. Signed-off-by: Lyude Paul --- include/drm/drm_print.h | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index a3c58c941bdc..9b66be54dd16 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -443,25 +443,25 @@ void drm_dev_dbg(const struct device *dev, enum drm_debug_category category, #define drm_dbg_core(drm, fmt, ...)\ - drm_dev_dbg((drm)->dev, DRM_UT_CORE, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__) #define drm_dbg(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_DRIVER, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, ##__VA_ARGS__) #define drm_dbg_kms(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__) #define drm_dbg_prime(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_PRIME, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_PRIME, fmt, ##__VA_ARGS__) #define drm_dbg_atomic(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_ATOMIC, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_ATOMIC, fmt, ##__VA_ARGS__) #define drm_dbg_vbl(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_VBL, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_VBL, fmt, ##__VA_ARGS__) #define drm_dbg_state(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_STATE, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_STATE, fmt, ##__VA_ARGS__) #define drm_dbg_lease(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_LEASE, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_LEASE, fmt, ##__VA_ARGS__) #define drm_dbg_dp(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_DP, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DP, fmt, ##__VA_ARGS__) #define drm_dbg_drmres(drm, fmt, ...) \ - drm_dev_dbg((drm)->dev, DRM_UT_DRMRES, fmt, ##__VA_ARGS__) + drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt, ##__VA_ARGS__) /* -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 17/17] drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()
And finally, convert all of the code in drm_dp_mst_topology.c over to using
drm_err() and drm_dbg*(). Note that this refactor would have been a lot
more complicated to have tried writing a coccinelle script for, so this
whole thing was done by hand.
v2:
* Fix line-wrapping in drm_dp_mst_atomic_check_mstb_bw_limit()
Signed-off-by: Lyude Paul
Cc: Robert Foss
Reviewed-by: Robert Foss
---
drivers/gpu/drm/drm_dp_mst_topology.c | 368 +-
1 file changed, 187 insertions(+), 181 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 9bac5bd050ab..5539a91b4031 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -286,7 +286,8 @@ static void drm_dp_encode_sideband_msg_hdr(struct
drm_dp_sideband_msg_hdr *hdr,
*len = idx;
}
-static bool drm_dp_decode_sideband_msg_hdr(struct drm_dp_sideband_msg_hdr *hdr,
+static bool drm_dp_decode_sideband_msg_hdr(const struct
drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_sideband_msg_hdr *hdr,
u8 *buf, int buflen, u8 *hdrlen)
{
u8 crc4;
@@ -303,7 +304,7 @@ static bool drm_dp_decode_sideband_msg_hdr(struct
drm_dp_sideband_msg_hdr *hdr,
crc4 = drm_dp_msg_header_crc4(buf, (len * 2) - 1);
if ((crc4 & 0xf) != (buf[len - 1] & 0xf)) {
- DRM_DEBUG_KMS("crc4 mismatch 0x%x 0x%x\n", crc4, buf[len - 1]);
+ drm_dbg_kms(mgr->dev, "crc4 mismatch 0x%x 0x%x\n", crc4,
buf[len - 1]);
return false;
}
@@ -789,7 +790,8 @@ static bool drm_dp_sideband_append_payload(struct
drm_dp_sideband_msg_rx *msg,
return true;
}
-static bool drm_dp_sideband_parse_link_address(struct drm_dp_sideband_msg_rx
*raw,
+static bool drm_dp_sideband_parse_link_address(const struct
drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_sideband_msg_rx
*raw,
struct
drm_dp_sideband_msg_reply_body *repmsg)
{
int idx = 1;
@@ -1014,7 +1016,8 @@ drm_dp_sideband_parse_query_stream_enc_status(
return true;
}
-static bool drm_dp_sideband_parse_reply(struct drm_dp_sideband_msg_rx *raw,
+static bool drm_dp_sideband_parse_reply(const struct drm_dp_mst_topology_mgr
*mgr,
+ struct drm_dp_sideband_msg_rx *raw,
struct drm_dp_sideband_msg_reply_body
*msg)
{
memset(msg, 0, sizeof(*msg));
@@ -1030,7 +1033,7 @@ static bool drm_dp_sideband_parse_reply(struct
drm_dp_sideband_msg_rx *raw,
switch (msg->req_type) {
case DP_LINK_ADDRESS:
- return drm_dp_sideband_parse_link_address(raw, msg);
+ return drm_dp_sideband_parse_link_address(mgr, raw, msg);
case DP_QUERY_PAYLOAD:
return drm_dp_sideband_parse_query_payload_ack(raw, msg);
case DP_REMOTE_DPCD_READ:
@@ -1053,14 +1056,16 @@ static bool drm_dp_sideband_parse_reply(struct
drm_dp_sideband_msg_rx *raw,
case DP_QUERY_STREAM_ENC_STATUS:
return drm_dp_sideband_parse_query_stream_enc_status(raw, msg);
default:
- DRM_ERROR("Got unknown reply 0x%02x (%s)\n", msg->req_type,
- drm_dp_mst_req_type_str(msg->req_type));
+ drm_err(mgr->dev, "Got unknown reply 0x%02x (%s)\n",
+ msg->req_type, drm_dp_mst_req_type_str(msg->req_type));
return false;
}
}
-static bool drm_dp_sideband_parse_connection_status_notify(struct
drm_dp_sideband_msg_rx *raw,
- struct
drm_dp_sideband_msg_req_body *msg)
+static bool
+drm_dp_sideband_parse_connection_status_notify(const struct
drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_sideband_msg_rx
*raw,
+ struct
drm_dp_sideband_msg_req_body *msg)
{
int idx = 1;
@@ -1082,12 +1087,14 @@ static bool
drm_dp_sideband_parse_connection_status_notify(struct drm_dp_sideban
idx++;
return true;
fail_len:
- DRM_DEBUG_KMS("connection status reply parse length fail %d %d\n", idx,
raw->curlen);
+ drm_dbg_kms(mgr->dev, "connection status reply parse length fail %d
%d\n",
+ idx, raw->curlen);
return false;
}
-static bool drm_dp_sideband_parse_resource_status_notify(struct
drm_dp_sideband_msg_rx *raw,
- struct
drm_dp_sideband_msg_req_body *msg)
+static bool drm_dp_sideband_parse_resource_status_notify(const struct
drm_dp_mst_topology_mgr *mgr,
+st
Re: [PATCH 1/2] drm/tegra: Get ref for DP AUX channel, not its ddc adapter
On Mon, 2021-04-26 at 09:42 +0200, Thierry Reding wrote:
> On Fri, Apr 23, 2021 at 02:21:45PM -0400, Lyude Paul wrote:
> > While we're taking a reference of the DDC adapter for a DP AUX channel in
> > tegra_sor_probe() because we're going to be using that adapter with the
> > SOR, now that we've moved where AUX registration happens the actual device
> > structure for the DDC adapter isn't initialized yet. Which means that we
> > can't really take a reference from it to try to keep it around anymore.
> >
> > This should be fine though, because we can just take a reference of its
> > parent instead.
> >
> > Signed-off-by: Lyude Paul
> > Fixes: 39c17ae60ea9 ("drm/tegra: Don't register DP AUX channels before
> > connectors")
> > Cc: Lyude Paul
> > Cc: Thierry Reding
> > Cc: Jonathan Hunter
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-te...@vger.kernel.org
> > ---
> > drivers/gpu/drm/tegra/sor.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> > index 7b88261f57bb..4e0e3a63e586 100644
> > --- a/drivers/gpu/drm/tegra/sor.c
> > +++ b/drivers/gpu/drm/tegra/sor.c
> > @@ -3739,11 +3739,11 @@ static int tegra_sor_probe(struct platform_device
> > *pdev)
> > if (!sor->aux)
> > return -EPROBE_DEFER;
> >
> > - if (get_device(&sor->aux->ddc.dev)) {
> > - if (try_module_get(sor->aux->ddc.owner))
> > + if (get_device(sor->aux->dev)) {
> > + if (try_module_get(sor->aux->dev->driver->owner))
> > sor->output.ddc = &sor->aux->ddc;
> > else
> > - put_device(&sor->aux->ddc.dev);
> > + put_device(sor->aux->dev);
> > }
> > }
>
> Unfortunately, I think it's a bit more subtle than that. The reason for
> this get_device()/try_module_get() dance was to mirror the behaviour of
> of_get_i2c_adapter_by_node() so that when we call i2c_put_adapter() in
> tegra_output_remove() we correctly decrease the reference count.
>
> The above will increase the reference on the I2C adapter's parent while
> i2c_put_adapter() will then only decrease the reference on the I2C
> adapter, so I think effectively we'd be leaking a reference to the I2C
> adapter's parent.
>
> Also, since we didn't take a reference on the I2C adapter explicitly,
> releasing that reference in tegra_output_remove() might free the I2C
> adapter too early.
>
> I wonder if perhaps it'd be easier to get rid of the struct tegra_output
> abstraction altogether and push this down into the individual drivers,
> even if that means a bit more code duplication. That's not the kind of
> quick fix to resolve this current situation, so perhaps as a stop-gap we
> just need to sprinkle a few more conditionals throughout tegra_output
> code. We could, for example, avoid calling i2c_put_adapter() in
> tegra_output_remove() for the DisplayPort cases and instead manually
> release the reference to the I2C adapter's parent in tegra_sor_remove().
> On top of your patch above that /should/ fix things properly for now.
Alright - I will try to get to this tomorrow
>
> Thierry
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Heads up to maintainers] Re: [PATCH v8 1/1] drm/drm_mst: Use Extended Base Receiver Capability DPCD space
; + u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
>
> - if (drm_dp_dpcd_read(&port->aux, DP_DOWNSTREAMPORT_PRESENT,
> - &downstreamport, 1) < 0)
> + if (drm_dp_read_dpcd_caps(port->mgr->aux, dpcd_ext) < 0)
> return NULL;
>
> - if ((downstreamport & DP_DWN_STRM_PORT_PRESENT) &&
> - ((downstreamport & DP_DWN_STRM_PORT_TYPE_MASK)
> + if ((dpcd_ext[DP_DOWNSTREAMPORT_PRESENT] &
> DP_DWN_STRM_PORT_PRESENT) &&
> + ((dpcd_ext[DP_DOWNSTREAMPORT_PRESENT] &
> DP_DWN_STRM_PORT_TYPE_MASK)
> != DP_DWN_STRM_PORT_TYPE_ANALOG))
> return port->mgr->aux;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 860381d68d9d..a4245eb48ef4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -942,6 +942,7 @@ intel_dp_mst_encoder_init(struct intel_digital_port
> *dig_port, int conn_base_id)
> struct intel_dp *intel_dp = &dig_port->dp;
> enum port port = dig_port->base.port;
> int ret;
> + int bios_max_link_rate;
>
> if (!HAS_DP_MST(i915) || intel_dp_is_edp(intel_dp))
> return 0;
> @@ -956,8 +957,11 @@ intel_dp_mst_encoder_init(struct intel_digital_port
> *dig_port, int conn_base_id)
>
> /* create encoders */
> intel_dp_create_fake_mst_encoders(dig_port);
> + bios_max_link_rate = intel_bios_dp_max_link_rate(&dig_port->base);
> ret = drm_dp_mst_topology_mgr_init(&intel_dp->mst_mgr, &i915->drm,
> - &intel_dp->aux, 16, 3,
> conn_base_id);
> + &intel_dp->aux, 16, 3,
> + dig_port->max_lanes,
> + bios_max_link_rate / 27000,
> conn_base_id);
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 1c9c0cdf85db..e02f9d2d74eb 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1617,7 +1617,8 @@ nv50_mstm_new(struct nouveau_encoder *outp, struct
> drm_dp_aux *aux, int aux_max,
> mstm->mgr.cbs = &nv50_mstm;
>
> ret = drm_dp_mst_topology_mgr_init(&mstm->mgr, dev, aux, aux_max,
> - max_payloads, conn_base_id);
> + max_payloads, outp->dcb-
> >dpconf.link_nr,
> + outp->dcb->dpconf.link_bw,
> conn_base_id);
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
> b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> index 59cf1d288465..8f0b2dccd199 100644
> --- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
> +++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> @@ -629,13 +629,20 @@ int
> radeon_dp_mst_init(struct radeon_connector *radeon_connector)
> {
> struct drm_device *dev = radeon_connector->base.dev;
> + int max_link_rate;
>
> if (!radeon_connector->ddc_bus->has_aux)
> return 0;
>
> + if (radeon_connector_is_dp12_capable(&radeon_connector->base))
> + max_link_rate = 0x14;
> + else
> + max_link_rate = 0x0a;
> +
> radeon_connector->mst_mgr.cbs = &mst_cbs;
> return drm_dp_mst_topology_mgr_init(&radeon_connector->mst_mgr, dev,
> &radeon_connector->ddc_bus->aux,
> 16, 6,
> + 4, max_link_rate,
> radeon_connector->base.base.id);
> }
>
> diff --git a/include/drm/drm_dp_mst_helper.h
> b/include/drm/drm_dp_mst_helper.h
> index 20dc705642bd..b5b0bf37813b 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -593,6 +593,14 @@ struct drm_dp_mst_topology_mgr {
> * @max_payloads: maximum number of payloads the GPU can generate.
> */
> int max_payloads;
> + /**
> + * @max_lane_count: maximum number of lanes the GPU can drive.
> + */
> + int max_lane_count;
> + /**
> + * @max_link_rate: maximum link rate per lane GPU can output.
> + */
> + int max_link_rate;
> /**
> * @conn_base_id: DRM connector ID this mgr is connected to. Only
> used
> * to build the MST connector path value.
> @@ -765,7 +773,9 @@ struct drm_dp_mst_topology_mgr {
> int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr,
> struct drm_device *dev, struct drm_dp_aux
> *aux,
> int max_dpcd_transaction_bytes,
> - int max_payloads, int conn_base_id);
> + int max_payloads,
> + int max_lane_count, int max_link_rate,
> + int conn_base_id);
>
> void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr);
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v3 2/2] backlight: Add DisplayPort aux backlight driver
ode *np;
> > + struct i2c_adapter *ddc;
> > + int ret = 0;
> > + u32 val;
> > +
> > + aux_bl = devm_kzalloc(&pdev->dev, sizeof(*aux_bl), GFP_KERNEL);
> > + if (!aux_bl)
> > + return -ENOMEM;
> > +
> > + aux_bl->dev = &pdev->dev;
> > +
> > + np = of_parse_phandle(pdev->dev.of_node, "ddc-i2c-bus", 0);
> > + if (!np) {
> > + dev_err(&pdev->dev, "failed to get aux ddc I2C bus\n");
> > + return -ENODEV;
> > + }
> > +
> > + ddc = of_find_i2c_adapter_by_node(np);
> > + of_node_put(np);
> > + if (!ddc)
> > + return -EPROBE_DEFER;
> > +
> > + aux_bl->aux = i2c_to_aux(ddc);
> > + dev_dbg(&pdev->dev, "using dp aux %s\n", aux_bl->aux->name);
> > +
> > + aux_bl->enable_gpio = devm_gpiod_get_optional(&pdev->dev,
> > "enable",
> > + GPIOD_OUT_LOW);
> > + if (IS_ERR(aux_bl->enable_gpio)) {
> > + ret = PTR_ERR(aux_bl->enable_gpio);
> > + goto free_ddc;
> > + }
> > +
> > + val = DP_AUX_MAX_BRIGHTNESS;
> > + of_property_read_u32(pdev->dev.of_node, "max-brightness", &val);
> > + if (val > DP_AUX_MAX_BRIGHTNESS)
> > + val = DP_AUX_MAX_BRIGHTNESS;
> > +
> > + bl_props.max_brightness = val;
> > + bl_props.brightness = val;
> > + bl_props.type = BACKLIGHT_RAW;
> > + bd = devm_backlight_device_register(&pdev->dev, dev_name(&pdev-
> > >dev),
> > + &pdev->dev, aux_bl,
> > + &aux_bl_ops, &bl_props);
> > + if (IS_ERR(bd)) {
> > + ret = PTR_ERR(bd);
> > + dev_err(&pdev->dev,
> > + "failed to register backlight (%d)\n", ret);
> > + goto free_ddc;
> > + }
> > +
> > + platform_set_drvdata(pdev, bd);
> > +
> > + return 0;
> > +
> > +free_ddc:
> > + if (ddc)
> > + put_device(&ddc->dev);
> > +
> > + return ret;
> > +}
> > +
> > +static int dp_aux_backlight_remove(struct platform_device *pdev)
> > +{
> > + struct backlight_device *bd = platform_get_drvdata(pdev);
> > + struct dp_aux_backlight *aux_bl = bl_get_data(bd);
> > + struct i2c_adapter *ddc = &aux_bl->aux->ddc;
> > +
> > + if (ddc)
> > + put_device(&ddc->dev);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id dp_aux_bl_of_match_table[] = {
> > + { .compatible = "dp-aux-backlight"},
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, dp_aux_bl_of_match_table);
> > +
> > +static struct platform_driver dp_aux_backlight_driver = {
> > + .driver = {
> > + .name = "dp-aux-backlight",
> > + .of_match_table = dp_aux_bl_of_match_table,
> > + },
> > + .probe = dp_aux_backlight_probe,
> > + .remove = dp_aux_backlight_remove,
> > +
> > +};
> > +module_platform_driver(dp_aux_backlight_driver);
> > +
> > +MODULE_DESCRIPTION("DisplayPort aux backlight driver");
> > +MODULE_LICENSE("GPL v2");
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/1] drm/dp_mst: Use the correct max source link rate for i915
On Fri, 2021-04-30 at 17:22 -0400, Nikola Cornij wrote:
> [why]
> Previously used value was not safe to provide the correct value, i.e. it
> could be 0 if not not configured, leading to no MST on this platform.
>
> [how]
> Do not use the value from BIOS, but from the structure populated at
> encoder initialization time.
>
> Fixes: 98025a62cb00 ("drm/dp_mst: Use Extended Base Receiver Capability DPCD
> space")
> Signed-off-by: Nikola Cornij
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index bf7f8487945c..01a0ed99988f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -942,7 +942,6 @@ intel_dp_mst_encoder_init(struct intel_digital_port
> *dig_port, int conn_base_id)
> struct intel_dp *intel_dp = &dig_port->dp;
> enum port port = dig_port->base.port;
> int ret;
> - int bios_max_link_rate;
>
> if (!HAS_DP_MST(i915) || intel_dp_is_edp(intel_dp))
> return 0;
> @@ -957,11 +956,11 @@ intel_dp_mst_encoder_init(struct intel_digital_port
> *dig_port, int conn_base_id)
>
> /* create encoders */
> intel_dp_create_fake_mst_encoders(dig_port);
> - bios_max_link_rate = intel_bios_dp_max_link_rate(&dig_port->base);
> ret = drm_dp_mst_topology_mgr_init(&intel_dp->mst_mgr, &i915->drm,
> &intel_dp->aux, 16, 3,
> (u8)dig_port->max_lanes,
> - (u8)(bios_max_link_rate / 27000),
> conn_base_id);
> + (u8)(intel_dp-
> >source_rates[intel_dp->num_source_rates - 1] / 27000),
> + conn_base_id);
This line is kind of long, I'd say we should just store the max link rate in a
local variable like max_link_rate, then just pass that to
drm_dp_mst_topology_mgr_init()
Also, the commit message should probably be:
drm/i915: Use the correct max source link rate for MST
With those two things fixed:
Reviewed-by: Lyude Paul
> if (ret)
> return ret;
>
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/dp: Handle zeroed port counts in drm_dp_read_downstream_info()
While the DP specification isn't entirely clear on if this should be
allowed or not, some branch devices report having downstream ports present
while also reporting a downstream port count of 0. So to avoid breaking
those devices, we need to handle this in drm_dp_read_downstream_info().
So, to do this we assume there's no downstream port info when the
downstream port count is 0.
Signed-off-by: Lyude Paul
Tested-by: Jérôme de Bretagne
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3416
Fixes: 3d3721ccb18a ("drm/i915/dp: Extract drm_dp_read_downstream_info()")
Cc: # v5.10+
---
drivers/gpu/drm/drm_dp_helper.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index cb56d74e9d38..27c8c5bdf7d9 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -682,7 +682,14 @@ int drm_dp_read_downstream_info(struct drm_dp_aux *aux,
!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
return 0;
+ /* Some branches advertise having 0 downstream ports, despite also
advertising they have a
+* downstream port present. The DP spec isn't clear on if this is
allowed or not, but since
+* some branches do it we need to handle it regardless.
+*/
len = drm_dp_downstream_port_count(dpcd);
+ if (!len)
+ return 0;
+
if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE)
len *= 4;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/dp: Drop open-coded drm_dp_is_branch() in drm_dp_read_downstream_info()
Noticed this while fixing another issue in drm_dp_read_downstream_info(), the open coded DP_DOWNSTREAMPORT_PRESENT check here just duplicates what we already do in drm_dp_is_branch(), so just get rid of it. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_helper.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 27c8c5bdf7d9..0f84df8798ab 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -677,9 +677,7 @@ int drm_dp_read_downstream_info(struct drm_dp_aux *aux, memset(downstream_ports, 0, DP_MAX_DOWNSTREAM_PORTS); /* No downstream info to read */ - if (!drm_dp_is_branch(dpcd) || - dpcd[DP_DPCD_REV] < DP_DPCD_REV_10 || - !(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT)) + if (!drm_dp_is_branch(dpcd) || dpcd[DP_DPCD_REV] < DP_DPCD_REV_10) return 0; /* Some branches advertise having 0 downstream ports, despite also advertising they have a -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/1] drm/i915: Use the correct max source link rate for MST
Alright - I had Ville double check this and give their A-B on IRC (I just need
to fix the open coded link_rate_to_bw() here). Since this got broken on drm-
misc-next I'm going to go ahead and push the fix there, since I'm not going to
be around next Monday or Tuesday and I don't want to leave i915 broken in the
interim. Sorry about the noise with this Jani!
As well - I'll get to fixing the dpcd unit usage once I get back on Wednesday
(unless Nikola's already gotten to it by then) so we use KHz instead. Although
as ville has pointed out, I think we should teach the topology manager to allow
passing for the current link rate/lane count during state computation in the
long term.
On Fri, 2021-04-30 at 17:45 -0400, Nikola Cornij wrote:
> [why]
> Previously used value was not safe to provide the correct value, i.e. it
> could be 0 if not not configured, leading to no MST on this platform.
>
> [how]
> Do not use the value from BIOS, but from the structure populated at
> encoder initialization time.
>
> Fixes: 98025a62cb00 ("drm/dp_mst: Use Extended Base Receiver Capability DPCD
> space")
> Signed-off-by: Nikola Cornij
> Reviewed-by: Lyude Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index bf7f8487945c..3642d7578658 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -942,7 +942,7 @@ intel_dp_mst_encoder_init(struct intel_digital_port
> *dig_port, int conn_base_id)
> struct intel_dp *intel_dp = &dig_port->dp;
> enum port port = dig_port->base.port;
> int ret;
> - int bios_max_link_rate;
> + int max_source_rate = intel_dp->source_rates[intel_dp-
> >num_source_rates - 1];
>
> if (!HAS_DP_MST(i915) || intel_dp_is_edp(intel_dp))
> return 0;
> @@ -957,11 +957,11 @@ intel_dp_mst_encoder_init(struct intel_digital_port
> *dig_port, int conn_base_id)
>
> /* create encoders */
> intel_dp_create_fake_mst_encoders(dig_port);
> - bios_max_link_rate = intel_bios_dp_max_link_rate(&dig_port->base);
> ret = drm_dp_mst_topology_mgr_init(&intel_dp->mst_mgr, &i915->drm,
> &intel_dp->aux, 16, 3,
> (u8)dig_port->max_lanes,
> - (u8)(bios_max_link_rate / 27000),
> conn_base_id);
> + (u8)(max_source_rate / 27000),
> + conn_base_id);
> if (ret)
> return ret;
>
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device
On Wed, 2021-07-21 at 00:03 +0800, Wayne Lin wrote:
> [Why]
> Currently, we will create connectors for all output ports no matter
> it's connected or not. However, in MST, we can only determine
> whether an output port really stands for a "connector" till it is
> connected and check its peer device type as an end device.
What is this commit trying to solve exactly? e.g. is AMD currently running
into issues with there being too many DRM connectors or something like that?
Ideally this is behavior I'd very much like us to keep as-is unless there's
good reason to change it.
Some context here btw - there's a lot of subtleties with MST locking that
isn't immediately obvious. It's been a while since I wrote this code, but if I
recall correctly one of those subtleties is that trying to create/destroy
connectors on the fly when ports change types introduces a lot of potential
issues with locking and some very complicated state transitions. Note that
because we maintain the topology as much as possible across suspend/resumes
this means there's a lot of potential state transitions with drm_dp_mst_port
and drm_dp_mst_branch we need to handle that would typically be impossible to
run into otherwise.
An example of this, if we were to try to prune connectors based on PDT
on the fly: assume we have a simple topology like this
Root MSTB -> Port 1 -> MSTB 1.1 (Connected w/ display)
-> Port 2 -> MSTB 2.1
We suspend the system, unplug MSTB 1.1, and then resume. Once the
system starts reprobing, it will notice that MSTB 1.1 has been
disconnected. Since we no longer have a PDT, we decide to unregister our
connector. But there's a catch! We had a display connected to MSTB 1.1,
so even after unregistering the connector it's going to stay around
until userspace has committed a new mode with the connector disabled.
Now - assuming we're still in the same spot in the resume processs, let's assume
somehow MSTB 1.1 is suddenly plugged back in. Once we've finished
responding to the hotplug event, we will have created a connector for
it. Now we've hit a bug - userspace hasn't removed the previous zombie
connector which means we have references to the drm_dp_mst_port in our
atomic state and potentially also our payload tables (?? unsure about
this one).
So then how do we manage to add/remove connectors for input connectors
on the fly? Well, that's one of the fun normally-impossible state
transitions I mentioned before. According to the spec input ports are always
disconnected, so we'll never receive a CSN for them. This means in
theory the only possible way we could have a connector go from being an
input connector to an output connector connector would be if the entire
topology was swapped out during suspend/resume, and the input/output
ports in the two topologies topology happen to be in different places.
Since we only have to reprobe once during resume before we get
hotplugging enabled, we're guaranteed this state transition will only
happen once in this state - which means the second replug I described in
the previous paragraph can never happen.
Note that while I don't actually know if there's topologies with input
ports at indexes other than 0, since the specification isn't super clear
on this bit we play it safe and assume it is possible.
Anyway-this is -all- based off my memory, so please point out anything
here that I've explained that doesn't make sense or doesn't seem
correct :). It's totally possible I might have misremembered something.
>
> In current code, we have chance to create connectors for output ports
> connected with branch device and these are redundant connectors. e.g.
> StarTech 1-to-4 DP hub is constructed by internal 2 layer 1-to-2 branch
> devices. Creating connectors for such internal output ports are
> redundant.
>
> [How]
> Put constraint on creating connector for connected end device only.
>
> Fixes: 6f85f73821f6 ("drm/dp_mst: Add basic topology reprobing when
> resuming")
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Cc: Sean Paul
> Cc: Lyude Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Alex Deucher
> Cc: Nicholas Kazlauskas
> Cc: Rodrigo Siqueira
> Cc: Aurabindo Pillai
> Cc: Eryk Brol
> Cc: Bas Nieuwenhuizen
> Cc: Nikola Cornij
> Cc: Wayne Lin
> Cc: "Ville Syrjälä"
> Cc: Jani Nikula
> Cc: Manasi Navare
> Cc: Ankit Nautiyal
> Cc: "José Roberto de Souza"
> Cc: Sean Paul
> Cc: Ben Skeggs
> Cc: dri-devel@lists.freedesktop.org
> Cc: # v5.5+
> Signed-off-by: Wayne Lin
> ---
> drivers/gpu/drm/drm_dp_mst_topolo
Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device
On Tue, 2021-08-03 at 19:58 -0400, Lyude Paul wrote:
> On Wed, 2021-07-21 at 00:03 +0800, Wayne Lin wrote:
> > [Why]
> > Currently, we will create connectors for all output ports no matter
> > it's connected or not. However, in MST, we can only determine
> > whether an output port really stands for a "connector" till it is
> > connected and check its peer device type as an end device.
>
> What is this commit trying to solve exactly? e.g. is AMD currently running
> into issues with there being too many DRM connectors or something like that?
> Ideally this is behavior I'd very much like us to keep as-is unless there's
> good reason to change it.
>
> Some context here btw - there's a lot of subtleties with MST locking that
> isn't immediately obvious. It's been a while since I wrote this code, but if
> I
> recall correctly one of those subtleties is that trying to create/destroy
> connectors on the fly when ports change types introduces a lot of potential
> issues with locking and some very complicated state transitions. Note that
> because we maintain the topology as much as possible across suspend/resumes
> this means there's a lot of potential state transitions with drm_dp_mst_port
> and drm_dp_mst_branch we need to handle that would typically be impossible
> to
> run into otherwise.
>
> An example of this, if we were to try to prune connectors based on PDT
> on the fly: assume we have a simple topology like this
>
> Root MSTB -> Port 1 -> MSTB 1.1 (Connected w/ display)
> -> Port 2 -> MSTB 2.1
>
> We suspend the system, unplug MSTB 1.1, and then resume. Once the
> system starts reprobing, it will notice that MSTB 1.1 has been
> disconnected. Since we no longer have a PDT, we decide to unregister our
> connector. But there's a catch! We had a display connected to MSTB 1.1,
> so even after unregistering the connector it's going to stay around
> until userspace has committed a new mode with the connector disabled.
>
> Now - assuming we're still in the same spot in the resume processs, let's
> assume
> somehow MSTB 1.1 is suddenly plugged back in. Once we've finished
> responding to the hotplug event, we will have created a connector for
> it. Now we've hit a bug - userspace hasn't removed the previous zombie
> connector which means we have references to the drm_dp_mst_port in our
> atomic state and potentially also our payload tables (?? unsure about
> this one).
Whoops. One thing I totally forgot to mention here: the reason this is a
problem is because we'd now have two drm_connectors which both have the same
drm_dp_mst_port pointer.
>
> So then how do we manage to add/remove connectors for input connectors
> on the fly? Well, that's one of the fun normally-impossible state
> transitions I mentioned before. According to the spec input ports are always
> disconnected, so we'll never receive a CSN for them. This means in
> theory the only possible way we could have a connector go from being an
> input connector to an output connector connector would be if the entire
> topology was swapped out during suspend/resume, and the input/output
> ports in the two topologies topology happen to be in different places.
> Since we only have to reprobe once during resume before we get
> hotplugging enabled, we're guaranteed this state transition will only
> happen once in this state - which means the second replug I described in
> the previous paragraph can never happen.
>
> Note that while I don't actually know if there's topologies with input
> ports at indexes other than 0, since the specification isn't super clear
> on this bit we play it safe and assume it is possible.
>
> Anyway-this is -all- based off my memory, so please point out anything
> here that I've explained that doesn't make sense or doesn't seem
> correct :). It's totally possible I might have misremembered something.
>
> >
> > In current code, we have chance to create connectors for output ports
> > connected with branch device and these are redundant connectors. e.g.
> > StarTech 1-to-4 DP hub is constructed by internal 2 layer 1-to-2 branch
> > devices. Creating connectors for such internal output ports are
> > redundant.
> >
> > [How]
> > Put constraint on creating connector for connected end device only.
> >
> > Fixes: 6f85f73821f6 ("drm/dp_mst: Add basic topology reprobing when
> > resuming")
> > Cc: Juston Li
> > Cc: Imre Deak
> > Cc: Ville Syrjälä
> > Cc: Harry Wentland
> > Cc: Daniel Vetter
> > Cc: Sean Paul
> > Cc: Lyude Paul
> >
Re: Help needed for EVoC/GSoC/Outreachy
Hi everyone! I got some questions from someone that made me realize that there's a couple of things that I forgot to mention here that might be useful for folks to know regarding being a mentor: * "Who decides what project and what student?" It's up to the student to come up with ideas for what they want to work on, although we will occasionally have a list of potential project ideas that students are welcome to use or draw inspiration from. Since X.org participates as a foundation, pretty much any of the projects under the X.org umbrella are allowed to do this if they're willing to come up with mentors. As for who the mentors are, that's really all just up to who's volunteering for it on a given project. As for how we decide what students we accept, that decision is usually made based off the quality of their project proposal along with whether a student seems self-sufficient enough to accomplish said project. Most students who come to us with a project idea already typically fall into this category. The final decision for this is typically made by the student's proposed mentor and/or our volunteer GSoC/Outreachy/EVoC admin. * "I assume this is international?" X.org tries to make our student outreach programs as international as possible. GSoC covers most of the world, but there are definitely some areas it doesn't cover - which is why we've ran EVoC in the past, so that students in areas that wouldn't be eligible for GSoC would still have a chance at participating in a project. Outreachy also helps fill this gap, as I don't believe they have the same kind of international restrictions that GSoC does. * What is the expected result, a grading? Yes. On Wed, 2021-07-14 at 16:32 -0400, Lyude Paul wrote: > Hi! As some of you might already be aware, after helping out X.org > project the previous years with regards to student outreach, Trevor > decided to retire from this position in hopes that someone else will be > able to step up and take on these responsibilities. As such, we're > trying to find people who would be willing to volunteer their time to > help out with getting us involved once again in student outreach > programs. > > In the past, X.org has been active in the GSoC program, occasionally > Outreachy, and our own EVoC program. As of 2021 though, GSoC decided to > shorten the amount of time allocated for a student to work on their > project. This unfortunately posed some problems for > X.org/freedesktop.org as a lot of the potential work that would have > been good for us to have students working on wouldn't really fit within > the new GSoC timeframe. While it's certainly possible that there will be > projects that come up in the future which do fit into this new timeline, > we think it'd be a good idea to step up our involvement again with > Outreachy where the program is a good bit more flexible then GSoC. We've > also had pretty good experience working with the Outreachy candidates > we've had in the past. > > The other main topic of discussion is around the fact that our own > program, EVoC, hasn't really had anyone available to volunteer to help > run it for a while now. For those who aren't aware, EVoC is a program > similar to Google Summer of Code that X.org started running with much > more relaxed requirements then GSoC/Outreachy in order to help fill the > gaps for any exceptional cases with students who would otherwise be left > out by the requirements for GSoC/Outreachy. Typically though, EVoC is > usually considered the last resort after a student has tried getting > into GSoC/Outreachy. > > So, the two biggest things that we need are: > * Admin volunteer(s) > * Mentors, mentors, mentors! We really need these the most. > > So, what responsibilities would being an admin for this entail? > > * Fielding questions from potential GSoC/EVoC/Outreachy participants. > Most of these students are just looking for simple details of how > these programs work and are looking for project ideas. Responding to > these inquiries is mostly just a matter of pointing students to > various pages on our wiki or replying with form/stock replies. Most of > the students at this phase expect to be handed a project and a mentor, > and therefore end up learning that they will need to come up with > their own project and mentor. > * For the small handful of students that make it to the next phase and > figure out a project idea, they then need to find a mentor. Usually > the admin will help out by taking a look at who proposed the project > idea, and/or looking through commit messages and mailing list history > to try to find someone who would be a good fit and willing to mentor > the
Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device
On Wed, 2021-08-04 at 07:13 +, Lin, Wayne wrote: > [Public] > > > -Original Message- > > From: Lyude Paul > > Sent: Wednesday, August 4, 2021 8:09 AM > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org > > Cc: Kazlauskas, Nicholas ; Wentland, Harry < > > harry.wentl...@amd.com>; Zuo, Jerry > > ; Wu, Hersen ; Juston Li < > > juston...@intel.com>; Imre Deak ; > > Ville Syrjälä ; Wentland, Harry < > > harry.wentl...@amd.com>; Daniel Vetter ; > > Sean Paul ; Maarten Lankhorst < > > maarten.lankho...@linux.intel.com>; Maxime Ripard ; > > Thomas Zimmermann ; David Airlie ; > > Daniel Vetter ; Deucher, > > Alexander ; Siqueira, Rodrigo < > > rodrigo.sique...@amd.com>; Pillai, Aurabindo > > ; Eryk Brol ; Bas > > Nieuwenhuizen ; Cornij, Nikola > > ; Jani Nikula ; Manasi > > Navare ; Ankit Nautiyal > > ; José Roberto de Souza > > ; Sean Paul ; Ben Skeggs > > ; sta...@vger.kernel.org > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected > > end device > > > > On Tue, 2021-08-03 at 19:58 -0400, Lyude Paul wrote: > > > On Wed, 2021-07-21 at 00:03 +0800, Wayne Lin wrote: > > > > [Why] > > > > Currently, we will create connectors for all output ports no matter > > > > it's connected or not. However, in MST, we can only determine > > > > whether an output port really stands for a "connector" till it is > > > > connected and check its peer device type as an end device. > > > > > > What is this commit trying to solve exactly? e.g. is AMD currently > > > running into issues with there being too many DRM connectors or > > > something like that? > > > Ideally this is behavior I'd very much like us to keep as-is unless > > > there's good reason to change it. > Hi Lyude, > Really appreciate for your time to elaborate in such detail. Thanks! > > I come up with this commit because I observed something confusing when I was > analyzing > MST connectors' life cycle. Take the topology instance you mentioned below > > Root MSTB -> Output_Port 1 -> MSTB 1.1 ->Output_Port 1(Connected w/ display) > | - > >Output_Port 2 (Disconnected) > -> Output_Port 2 -> MSTB 2.1 ->Output_Port 1 > (Disconnected) > -> > Output_Port 2 (Disconnected) > Which is exactly the topology of Startech DP 1-to-4 hub. There are 3 1-to-2 > branch chips > within this hub. With our MST implementation today, we'll create drm > connectors for all > output ports. Hence, we totally create 6 drm connectors here. However, > Output ports of > Root MSTB are not connected to a stream sink. They are connected with branch > devices. > Thus, creating drm connector for such port looks a bit strange to me and > increases > complexity to tracking drm connectors. My thought is we only need to create > drm > connector for those connected end device. Once output port is connected then > we can > determine whether to add on a drm connector for this port based on the peer > device type. > Hence, this commit doesn't try to break the locking logic but add more > constraints when > We try to add drm connector. Please correct me if I misunderstand anything > here. Thanks! Sorry-I will respond to this soon, some more stuff came up at work so it might take me a day or two > > > > > > Some context here btw - there's a lot of subtleties with MST locking > > > that isn't immediately obvious. It's been a while since I wrote this > > > code, but if I recall correctly one of those subtleties is that trying > > > to create/destroy connectors on the fly when ports change types > > > introduces a lot of potential issues with locking and some very > > > complicated state transitions. Note that because we maintain the > > > topology as much as possible across suspend/resumes this means there's > > > a lot of potential state transitions with drm_dp_mst_port and > > > drm_dp_mst_branch we need to handle that would typically be impossible > > > to run into otherwise. > > > > > > An example of this, if we were to try to prune connectors based on PDT > > > on the fly: assume we have a simple topology like this > > > > > > Root MSTB -> Port 1 -> MSTB 1.1 (Connected w/ display) > > > -> Port 2 -> MSTB 2.1 > > >
Re: [PATCH v2 0/3] drm/nouveau: fix a use-after-free in postclose()
It may have been, we're in the process of trying to change around how we currently accept nouveau patches to stop this from happening in the future. Ben, whenever you get a moment can you take a look at this? On Mon, 2021-08-16 at 09:03 +0200, Salvatore Bonaccorso wrote: > Hi, > > On Fri, Mar 26, 2021 at 06:00:51PM -0400, Lyude Paul wrote: > > This patch series is: > > > > Reviewed-by: Lyude Paul > > > > Btw - in the future if you need to send a respin of multiple patches, you > > need > > to send it as it's own separate series instead of replying to the previous > > one > > (one-off respins can just be posted as replies though), otherwise > > patchwork > > won't pick it up > > Did this patch series somehow fall through the cracks or got lost? > > Regards, > Salvatore > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device
On Wed, 2021-08-11 at 09:49 +, Lin, Wayne wrote: > [Public] > > > -Original Message- > > From: Lyude Paul > > Sent: Wednesday, August 11, 2021 4:45 AM > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org > > Cc: Kazlauskas, Nicholas ; Wentland, Harry < > > harry.wentl...@amd.com>; Zuo, Jerry > > ; Wu, Hersen ; Juston Li < > > juston...@intel.com>; Imre Deak ; > > Ville Syrjälä ; Daniel Vetter < > > daniel.vet...@ffwll.ch>; Sean Paul ; Maarten Lankhorst > > ; Maxime Ripard ; > > Thomas Zimmermann ; > > David Airlie ; Daniel Vetter ; Deucher, > > Alexander ; Siqueira, > > Rodrigo ; Pillai, Aurabindo < > > aurabindo.pil...@amd.com>; Eryk Brol ; Bas > > Nieuwenhuizen ; Cornij, Nikola < > > nikola.cor...@amd.com>; Jani Nikula ; Manasi > > Navare ; Ankit Nautiyal < > > ankit.k.nauti...@intel.com>; José Roberto de Souza ; > > Sean Paul ; Ben Skeggs ; > > sta...@vger.kernel.org > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected > > end device > > > > On Wed, 2021-08-04 at 07:13 +, Lin, Wayne wrote: > > > [Public] > > > > > > > -Original Message- > > > > From: Lyude Paul > > > > Sent: Wednesday, August 4, 2021 8:09 AM > > > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org > > > > Cc: Kazlauskas, Nicholas ; Wentland, > > > > Harry < harry.wentl...@amd.com>; Zuo, Jerry ; Wu, > > > > Hersen ; Juston Li < juston...@intel.com>; Imre > > > > Deak ; Ville Syrjälä > > > > ; Wentland, Harry < > > > > harry.wentl...@amd.com>; Daniel Vetter ; > > > > Sean Paul ; Maarten Lankhorst < > > > > maarten.lankho...@linux.intel.com>; Maxime Ripard > > > > ; Thomas Zimmermann ; David > > > > Airlie ; Daniel Vetter ; Deucher, > > > > Alexander ; Siqueira, Rodrigo < > > > > rodrigo.sique...@amd.com>; Pillai, Aurabindo > > > > ; Eryk Brol ; Bas > > > > Nieuwenhuizen ; Cornij, Nikola > > > > ; Jani Nikula ; Manasi > > > > Navare ; Ankit Nautiyal > > > > ; José Roberto de Souza > > > > ; Sean Paul ; Ben > > > > Skeggs ; sta...@vger.kernel.org > > > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for > > > > connected end device > > > > > > > > On Tue, 2021-08-03 at 19:58 -0400, Lyude Paul wrote: > > > > > On Wed, 2021-07-21 at 00:03 +0800, Wayne Lin wrote: > > > > > > [Why] > > > > > > Currently, we will create connectors for all output ports no > > > > > > matter it's connected or not. However, in MST, we can only > > > > > > determine whether an output port really stands for a "connector" > > > > > > till it is connected and check its peer device type as an end > > > > > > device. > > > > > > > > > > What is this commit trying to solve exactly? e.g. is AMD currently > > > > > running into issues with there being too many DRM connectors or > > > > > something like that? > > > > > Ideally this is behavior I'd very much like us to keep as-is > > > > > unless there's good reason to change it. > > > Hi Lyude, > > > Really appreciate for your time to elaborate in such detail. Thanks! > > > > > > I come up with this commit because I observed something confusing when > > > I was analyzing MST connectors' life cycle. Take the topology instance > > > you mentioned below > > > > > > Root MSTB -> Output_Port 1 -> MSTB 1.1 ->Output_Port 1(Connected w/ > > > display) > > > | > > > - > > > > Output_Port 2 (Disconnected) > > > -> Output_Port 2 -> MSTB 2.1 ->Output_Port 1 > > > (Disconnected) > > > > > > -> Output_Port 2 (Disconnected) Which is exactly the topology of > > > Startech DP 1-to-4 hub. There are 3 1-to-2 branch chips within this > > > hub. With our MST implementation today, we'll create drm connectors > > > for all output ports. Hence, we totally create 6 drm connectors here. > > > However, Output ports of Root MSTB are not connected to a stream sink. > > > They are connected with branch devices. > > > Thus, creating drm connector for such port looks a bit strange to me > > > and increases complex
Re: [PATCH 1/8] drm/connector: Give connector sysfs devices there own device_type
On Tue, 2021-08-17 at 23:51 +0200, Hans de Goede wrote:
> Give connector sysfs devices there own device_type, this allows us to
> check if a device passed to functions dealing with generic devices is
> a drm_connector or not.
>
> A check like this is necessary in the drm_connector_acpi_bus_match()
> function added in the next patch in this series.
>
> Tested-by: Heikki Krogerus
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/drm_sysfs.c | 50 +++--
> 1 file changed, 37 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 968a9560b4aa..f9d92bbb1f98 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -50,6 +50,10 @@ static struct device_type drm_sysfs_device_minor = {
> .name = "drm_minor"
> };
>
> +static struct device_type drm_sysfs_device_connector = {
> + .name = "drm_connector",
> +};
> +
> struct class *drm_class;
>
> static char *drm_devnode(struct device *dev, umode_t *mode)
> @@ -102,6 +106,11 @@ void drm_sysfs_destroy(void)
> drm_class = NULL;
> }
>
> +static void drm_sysfs_release(struct device *dev)
> +{
> + kfree(dev);
> +}
> +
> /*
> * Connector properties
> */
> @@ -273,27 +282,47 @@ static const struct attribute_group
> *connector_dev_groups[] = {
> int drm_sysfs_connector_add(struct drm_connector *connector)
> {
> struct drm_device *dev = connector->dev;
> + struct device *kdev;
> + int r;
>
> if (connector->kdev)
> return 0;
>
> - connector->kdev =
> - device_create_with_groups(drm_class, dev->primary->kdev, 0,
> - connector, connector_dev_groups,
> - "card%d-%s", dev->primary->index,
> - connector->name);
> + kdev = kzalloc(sizeof(*kdev), GFP_KERNEL);
> + if (!kdev)
> + return -ENOMEM;
> +
> + device_initialize(kdev);
> + kdev->class = drm_class;
> + kdev->type = &drm_sysfs_device_connector;
> + kdev->parent = dev->primary->kdev;
> + kdev->groups = connector_dev_groups;
> + kdev->release = drm_sysfs_release;
> + dev_set_drvdata(kdev, connector);
> +
> + r = dev_set_name(kdev, "card%d-%s", dev->primary->index, connector-
> >name);
> + if (r)
> + goto err_free;
> +
> DRM_DEBUG("adding \"%s\" to sysfs\n",
> connector->name);
>
> - if (IS_ERR(connector->kdev)) {
> - DRM_ERROR("failed to register connector device: %ld\n",
> PTR_ERR(connector->kdev));
> - return PTR_ERR(connector->kdev);
> + r = device_add(kdev);
> + if (r) {
> + DRM_ERROR("failed to register connector device: %d\n", r);
> + goto err_free;
Should probably be using drm_err() here since we have access to struct
drm_device *
> }
>
> + connector->kdev = kdev;
> +
> if (connector->ddc)
> return sysfs_create_link(&connector->kdev->kobj,
> &connector->ddc->dev.kobj, "ddc");
> return 0;
> +
> +err_free:
> + put_device(kdev);
> + return r;
> }
>
> void drm_sysfs_connector_remove(struct drm_connector *connector)
> @@ -374,11 +403,6 @@ void drm_sysfs_connector_status_event(struct
> drm_connector *connector,
> }
> EXPORT_SYMBOL(drm_sysfs_connector_status_event);
>
> -static void drm_sysfs_release(struct device *dev)
> -{
> - kfree(dev);
> -}
> -
> struct device *drm_sysfs_minor_alloc(struct drm_minor *minor)
> {
> const char *minor_str;
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v4 resend)
This looks great to me! Wasn't much to comment on here as most of this looks fine to me. For the whole series: Reviewed-by: Lyude Paul This will be quite interesting to try getting working for nouveau On Tue, 2021-08-17 at 23:51 +0200, Hans de Goede wrote: > Hi all, > > Here is a rebased-resend of v4 of my patchset making DP over Type-C work on > devices where the Type-C controller does not drive the HPD pin on the GPU, > but instead we need to forward HPD events from the Type-C controller to > the DRM driver. > > Changes in v4 resend: > - Rebase on top of latest drm-tip > > Changes in v4: > - Rebase on top of latest drm-tip > - Add forward declaration for struct fwnode_handle to drm_crtc_internal.h > (fixes warning reported by kernel test robot ) > - Add Heikki's Reviewed-by to patch 7 & 8 > - Add Heikki's Tested-by to the series > > Changes in v3: > - Base on top of latest drm-tip, which should fix the CI being unable to > apply (and thus to test) the patches > - Make intel_acpi_assign_connector_fwnodes() take a ref on the fwnode > it stores in connector->fwnode and have drm_connector_cleanup() put > this reference > - Drop data argument from drm_connector_oob_hotplug_event() > - Make the Type-C DP altmode code only call > drm_connector_oob_hotplug_event() > when the HPD bit in the status vdo changes > - Drop the platform/x86/intel_cht_int33fe: Correct "displayport" fwnode > reference patch, this will be merged independently through the pdx86 tree > > Changes in v2: > - Replace the bogus "drm/connector: Make the drm_sysfs connector->kdev > device hold a reference to the connector" patch with: > "drm/connector: Give connector sysfs devices there own device_type" > the new patch is a dep for patch 2/9 see the patches > > - Stop using a class-dev-iter, instead at a global connector list > to drm_connector.c and use that to find the connector by the fwnode, > similar to how we already do this in drm_panel.c and drm_bridge.c > > - Make drm_connector_oob_hotplug_event() take a fwnode pointer as > argument, rather then a drm_connector pointer and let it do the > lookup itself. This allows making drm_connector_find_by_fwnode() a > drm-internal function and avoids code outside the drm subsystem > potentially holding on the a drm_connector reference for a longer > period. > > This series not only touches drm subsys files but it also touches > drivers/usb/typec/altmodes/typec_displayport.c, that file usually > does not see a whole lot of changes. So I believe it would be best > to just merge the entire series through drm-misc, Assuming we can > get an ack from Greg for merging the typec_displayport.c changes > this way. > > Regards, > > Hans > > Hans de Goede (7): > drm/connector: Give connector sysfs devices there own device_type > drm/connector: Add a fwnode pointer to drm_connector and register with > ACPI (v2) > drm/connector: Add drm_connector_find_by_fwnode() function (v3) > drm/connector: Add support for out-of-band hotplug notification (v3) > drm/i915/dp: Add support for out-of-bound hotplug events > usb: typec: altmodes/displayport: Make dp_altmode_notify() more > generic > usb: typec: altmodes/displayport: Notify drm subsys of hotplug events > > Heikki Krogerus (1): > drm/i915: Associate ACPI connector nodes with connector entries (v2) > > drivers/gpu/drm/drm_connector.c | 79 ++ > drivers/gpu/drm/drm_crtc_internal.h | 2 + > drivers/gpu/drm/drm_sysfs.c | 87 +--- > drivers/gpu/drm/i915/display/intel_acpi.c | 46 +++ > drivers/gpu/drm/i915/display/intel_acpi.h | 3 + > drivers/gpu/drm/i915/display/intel_display.c | 1 + > drivers/gpu/drm/i915/display/intel_dp.c | 12 +++ > drivers/usb/typec/altmodes/Kconfig | 1 + > drivers/usb/typec/altmodes/displayport.c | 58 - > include/drm/drm_connector.h | 25 ++ > 10 files changed, 279 insertions(+), 35 deletions(-) > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device
On Fri, 2021-08-20 at 11:20 +, Lin, Wayne wrote: > [Public] > > > -Original Message- > > From: Lyude Paul > > Sent: Thursday, August 19, 2021 2:59 AM > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org > > Cc: Kazlauskas, Nicholas ; Wentland, Harry < > > harry.wentl...@amd.com>; Zuo, Jerry > > ; Wu, Hersen ; Juston Li < > > juston...@intel.com>; Imre Deak ; > > Ville Syrjälä ; Daniel Vetter < > > daniel.vet...@ffwll.ch>; Sean Paul ; Maarten Lankhorst > > ; Maxime Ripard ; > > Thomas Zimmermann ; > > David Airlie ; Daniel Vetter ; Deucher, > > Alexander ; Siqueira, > > Rodrigo ; Pillai, Aurabindo < > > aurabindo.pil...@amd.com>; Eryk Brol ; Bas > > Nieuwenhuizen ; Cornij, Nikola < > > nikola.cor...@amd.com>; Jani Nikula ; Manasi > > Navare ; Ankit Nautiyal < > > ankit.k.nauti...@intel.com>; José Roberto de Souza ; > > Sean Paul ; Ben Skeggs ; > > sta...@vger.kernel.org > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected > > end device > > > > On Wed, 2021-08-11 at 09:49 +, Lin, Wayne wrote: > > > [Public] > > > > > > > -Original Message- > > > > From: Lyude Paul > > > > Sent: Wednesday, August 11, 2021 4:45 AM > > > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org > > > > Cc: Kazlauskas, Nicholas ; Wentland, > > > > Harry < harry.wentl...@amd.com>; Zuo, Jerry ; Wu, > > > > Hersen ; Juston Li < juston...@intel.com>; Imre > > > > Deak ; Ville Syrjälä > > > > ; Daniel Vetter < > > > > daniel.vet...@ffwll.ch>; Sean Paul ; Maarten > > > > Lankhorst ; Maxime Ripard > > > > ; Thomas Zimmermann ; David > > > > Airlie ; Daniel Vetter ; Deucher, > > > > Alexander ; Siqueira, Rodrigo > > > > ; Pillai, Aurabindo < > > > > aurabindo.pil...@amd.com>; Eryk Brol ; Bas > > > > Nieuwenhuizen ; Cornij, Nikola < > > > > nikola.cor...@amd.com>; Jani Nikula ; Manasi > > > > Navare ; Ankit Nautiyal < > > > > ankit.k.nauti...@intel.com>; José Roberto de Souza > > > > ; Sean Paul ; Ben > > > > Skeggs ; sta...@vger.kernel.org > > > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for > > > > connected end device > > > > > > > > On Wed, 2021-08-04 at 07:13 +, Lin, Wayne wrote: > > > > > [Public] > > > > > > > > > > > -Original Message- > > > > > > From: Lyude Paul > > > > > > Sent: Wednesday, August 4, 2021 8:09 AM > > > > > > To: Lin, Wayne ; > > > > > > dri-devel@lists.freedesktop.org > > > > > > Cc: Kazlauskas, Nicholas ; > > > > > > Wentland, Harry < harry.wentl...@amd.com>; Zuo, Jerry > > > > > > ; Wu, Hersen ; Juston Li > > > > > > < juston...@intel.com>; Imre Deak ; Ville > > > > > > Syrjälä ; Wentland, Harry < > > > > > > harry.wentl...@amd.com>; Daniel Vetter ; > > > > > > Sean Paul ; Maarten Lankhorst < > > > > > > maarten.lankho...@linux.intel.com>; Maxime Ripard > > > > > > ; Thomas Zimmermann ; > > > > > > David Airlie ; Daniel Vetter > > > > > > ; Deucher, Alexander > > > > > > ; Siqueira, Rodrigo < > > > > > > rodrigo.sique...@amd.com>; Pillai, Aurabindo > > > > > > ; Eryk Brol ; Bas > > > > > > Nieuwenhuizen ; Cornij, Nikola > > > > > > ; Jani Nikula ; > > > > > > Manasi Navare ; Ankit Nautiyal > > > > > > ; José Roberto de Souza > > > > > > ; Sean Paul ; Ben > > > > > > Skeggs ; sta...@vger.kernel.org > > > > > > Subject: Re: [PATCH 2/4] drm/dp_mst: Only create connector for > > > > > > connected end device > > > > > > > > > > > > On Tue, 2021-08-03 at 19:58 -0400, Lyude Paul wrote: > > > > > > > On Wed, 2021-07-21 at 00:03 +0800, Wayne Lin wrote: > > > > > > > > [Why] > > > > > > > > Currently, we will create connectors for all output ports no > > > > > > > > matter it's connected or not. However, in MST, we can only > > > > > > > > determine whether an output port really stands for
Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device
ally coming from. > > Thanks Lyude! > > Sorry to bother you, but I would like to clarify this again. So it sounds It's no problem! It's my job and I'm happy to help :). > like you also agree that we should destroy associated connector Not quite. I think a better way of explaining this might be to point out that the lifetime of an MST port and its connector isn't supposed to be determined by whether or not it has something plugged into it - its lifetime is supposed to depend on whether there's a valid path from us down the MST topology to the port we're trying to reach. So an MSTB with ports that is unplugged would destroy all of its ports - but an unplugged port should just be the same as a disconnected DRM connector - even if the port itself is just hosting a branching device. Additionally - we don't want to try "delaying" connector creation either. In the modern world hotplugging is almost always reliable in normal situations, but even so there's still use cases for wanting force probing for analog devices on DP converters and just in general as it's a feature commonly used by developers or users working around monitors with problematic HPD issues or EDID issues. > when we unplug sst monitor from a mst hub in the case that I described? In > the case I described (unplug sst monitor), we only receive > CSN from the hub that notifying us the connection status of one of its > downstream output ports is changed to disconnected. There is no > topology refcount needed to be decreased on this disconnected port but the > malloc refcount. Since the output port is still declared by Apologies - I misunderstood your original mail as implying that topology refcounts were being leaked - but it sounds like it's actually malloc refcounts being leaked instead? In any case - that means we're still tracing down a leak, just a malloc ref leak. But, this still doesn't totally make sense to me. Malloc refs only keep the actual drm_dp_mst_port/drm_dp_mst_branch struct alive in memory. Nothing else is kept around, meaning the DRM connector (and I assume by proxy, the dc_sink) should both be getting dropped still and the only thing that should be leaked is a memory allocation. These things should instead be dropped once there's no longer any topology references around. So, are we _sure_ that the problem here is a missing drm_dp_mst_port_put_malloc() or drm_dp_mst_mstb_put_malloc()? If we are unfortunately we don't have equivalent tools for malloc() tracing. I'm totally fine with trying to add some if we have trouble figuring out this issue, but I'm a bit suspicious of the commits you mentioned that introduced this problem. If the problem doesn't happen until those two commits, then it's something in the code changes there that are causing this problem. The main thing I'm suspicious of just from looking at changes in 09b974e8983a4b163d4a406b46d50bf869da3073 is that the call to amdgpu_dm_update_freesync_caps() that was previously in dm_dp_destroy_mst_connector() appears to be dropped and not re-added in (oh dear, this is a /very/ confusingly similar function name!!!) dm_dp_mst_connector_destroy(). I don't remember if this was intentional on my part, but does adding a call back to amdgpu_dm_update_freesync_caps() into dm_dp_destroy_mst_connector() right before the dc_link_remove_remote_sink() call fix anything? As well, I'm far less suspicious of this one but does re-adding this hunk: aconnector->dc_sink = NULL; aconnector->dc_link->cur_link_settings.lane_count = 0; After dc_sink_release() fix anything either? > the mst hub, I think we shouldn't destroy the port. Actually, no ports nor > mst branch devices should get destroyed in this case I think. > The result of LINK_ADDRESS is still the same before/after removing the sst > monitor except the > DisplayPort_Device_Plug_Status/ Legacy_Device_Plug_Status. > > Hence, if you agree that we should put refcount of the connector of the > disconnected port within the unplugging sst monitor case to > release the allocated resource, it means we don't want to create connectors > for those disconnected ports. Which conflicts current flow > to create connectors for all declared output ports. > > Thanks again for your time Lyude! -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH AUTOSEL 4.14 6/7] drm/nouveau: block a bunch of classes from userspace
This isn't at all intended to be a fix to be backported, so I don't think this
should be included. I don't know about 5/7, but I'll let Benjamin comment on
that one
On Mon, 2021-08-23 at 20:55 -0400, Sasha Levin wrote:
> From: Ben Skeggs
>
> [ Upstream commit 148a8653789c01f159764ffcc3f370008966b42f ]
>
> Long ago, there had been plans for making use of a bunch of these APIs
> from userspace and there's various checks in place to stop misbehaving.
>
> Countless other projects have occurred in the meantime, and the pieces
> didn't finish falling into place for that to happen.
>
> They will (hopefully) in the not-too-distant future, but it won't look
> quite as insane. The super checks are causing problems right now, and
> are going to be removed.
>
> Signed-off-by: Ben Skeggs
> Reviewed-by: Lyude Paul
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/nouveau/include/nvif/cl0080.h | 3 +-
> drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
> drivers/gpu/drm/nouveau/nouveau_usif.c | 57 ++-
> .../gpu/drm/nouveau/nvkm/engine/device/user.c | 2 +-
> 4 files changed, 48 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/include/nvif/cl0080.h
> b/drivers/gpu/drm/nouveau/include/nvif/cl0080.h
> index 2740278d226b..61c17acd507c 100644
> --- a/drivers/gpu/drm/nouveau/include/nvif/cl0080.h
> +++ b/drivers/gpu/drm/nouveau/include/nvif/cl0080.h
> @@ -4,7 +4,8 @@
>
> struct nv_device_v0 {
> __u8 version;
> - __u8 pad01[7];
> + __u8 priv;
> + __u8 pad02[6];
> __u64 device; /* device identifier, ~0 for client default */
> };
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index fb6b1d0f7fef..fc54a26598cc 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -151,6 +151,7 @@ nouveau_cli_init(struct nouveau_drm *drm, const char
> *sname,
> ret = nvif_device_init(&cli->base.object, 0, NV_DEVICE,
> &(struct nv_device_v0) {
> .device = ~0,
> + .priv = true,
> }, sizeof(struct nv_device_v0),
> &cli->device);
> if (ret) {
> diff --git a/drivers/gpu/drm/nouveau/nouveau_usif.c
> b/drivers/gpu/drm/nouveau/nouveau_usif.c
> index 9dc10b17ad34..5da1f4d223d7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_usif.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_usif.c
> @@ -32,6 +32,9 @@
> #include
> #include
>
> +#include
> +#include
> +
> struct usif_notify_p {
> struct drm_pending_event base;
> struct {
> @@ -261,7 +264,7 @@ usif_object_dtor(struct usif_object *object)
> }
>
> static int
> -usif_object_new(struct drm_file *f, void *data, u32 size, void *argv, u32
> argc)
> +usif_object_new(struct drm_file *f, void *data, u32 size, void *argv, u32
> argc, bool parent_abi16)
> {
> struct nouveau_cli *cli = nouveau_cli(f);
> struct nvif_client *client = &cli->base;
> @@ -271,23 +274,48 @@ usif_object_new(struct drm_file *f, void *data, u32
> size, void *argv, u32 argc)
> struct usif_object *object;
> int ret = -ENOSYS;
>
> + if ((ret = nvif_unpack(ret, &data, &size, args->v0, 0, 0, true)))
> + return ret;
> +
> + switch (args->v0.oclass) {
> + case NV_DMA_FROM_MEMORY:
> + case NV_DMA_TO_MEMORY:
> + case NV_DMA_IN_MEMORY:
> + return -EINVAL;
> + case NV_DEVICE: {
> + union {
> + struct nv_device_v0 v0;
> + } *args = data;
> +
> + if ((ret = nvif_unpack(ret, &data, &size, args->v0, 0, 0,
> false)))
> + return ret;
> +
> + args->v0.priv = false;
> + break;
> + }
> + default:
> + if (!parent_abi16)
> + return -EINVAL;
> + break;
> + }
> +
> if (!(object = kmalloc(sizeof(*object), GFP_KERNEL)))
> return -ENOMEM;
> list_add(&object->head, &cli->objects);
>
> - if (!(ret = nvif_unpack(ret, &data, &size, args->v0, 0, 0, true))) {
> - object->route = args->v0.route;
> - object->token = args->v0.token;
> - args->v0.route = NVDRM_OBJECT_USIF;
> - args->v0.token = (unsigned l
Re: [PATCH AUTOSEL 5.10 16/18] drm/nouveau/kms/nv50: workaround EFI GOP window channel format differences
Ben, do we even have Ampere support in 5.10?
On Mon, 2021-08-23 at 20:54 -0400, Sasha Levin wrote:
> From: Ben Skeggs
>
> [ Upstream commit e78b1b545c6cfe9f87fc577128e00026fff230ba ]
>
> Should fix some initial modeset failures on (at least) Ampere boards.
>
> Signed-off-by: Ben Skeggs
> Reviewed-by: Lyude Paul
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 27 +
> drivers/gpu/drm/nouveau/dispnv50/head.c | 13
> drivers/gpu/drm/nouveau/dispnv50/head.h | 1 +
> 3 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 5b8cabb099eb..c2d34c91e840 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -2202,6 +2202,33 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state
> *state)
> interlock[NV50_DISP_INTERLOCK_CORE] = 0;
> }
>
> + /* Finish updating head(s)...
> + *
> + * NVD is rather picky about both where window assignments can
> change,
> + * *and* about certain core and window channel states matching.
> + *
> + * The EFI GOP driver on newer GPUs configures window channels with
> a
> + * different output format to what we do, and the core channel
> update
> + * in the assign_windows case above would result in a state
> mismatch.
> + *
> + * Delay some of the head update until after that point to
> workaround
> + * the issue. This only affects the initial modeset.
> + *
> + * TODO: handle this better when adding flexible window mapping
> + */
> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> + struct nv50_head_atom *asyh =
> nv50_head_atom(new_crtc_state);
> + struct nv50_head *head = nv50_head(crtc);
> +
> + NV_ATOMIC(drm, "%s: set %04x (clr %04x)\n", crtc->name,
> + asyh->set.mask, asyh->clr.mask);
> +
> + if (asyh->set.mask) {
> + nv50_head_flush_set_wndw(head, asyh);
> + interlock[NV50_DISP_INTERLOCK_CORE] = 1;
> + }
> + }
> +
> /* Update plane(s). */
> for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> struct nv50_wndw_atom *asyw =
> nv50_wndw_atom(new_plane_state);
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c
> b/drivers/gpu/drm/nouveau/dispnv50/head.c
> index 841edfaf5b9d..61826cac3061 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/head.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
> @@ -49,11 +49,8 @@ nv50_head_flush_clr(struct nv50_head *head,
> }
>
> void
> -nv50_head_flush_set(struct nv50_head *head, struct nv50_head_atom *asyh)
> +nv50_head_flush_set_wndw(struct nv50_head *head, struct nv50_head_atom
> *asyh)
> {
> - if (asyh->set.view ) head->func->view (head, asyh);
> - if (asyh->set.mode ) head->func->mode (head, asyh);
> - if (asyh->set.core ) head->func->core_set(head, asyh);
> if (asyh->set.olut ) {
> asyh->olut.offset = nv50_lut_load(&head->olut,
> asyh->olut.buffer,
> @@ -61,6 +58,14 @@ nv50_head_flush_set(struct nv50_head *head, struct
> nv50_head_atom *asyh)
> asyh->olut.load);
> head->func->olut_set(head, asyh);
> }
> +}
> +
> +void
> +nv50_head_flush_set(struct nv50_head *head, struct nv50_head_atom *asyh)
> +{
> + if (asyh->set.view ) head->func->view (head, asyh);
> + if (asyh->set.mode ) head->func->mode (head, asyh);
> + if (asyh->set.core ) head->func->core_set(head, asyh);
> if (asyh->set.curs ) head->func->curs_set(head, asyh);
> if (asyh->set.base ) head->func->base (head, asyh);
> if (asyh->set.ovly ) head->func->ovly (head, asyh);
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.h
> b/drivers/gpu/drm/nouveau/dispnv50/head.h
> index dae841dc05fd..0bac6be9ba34 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/head.h
> +++ b/drivers/gpu/drm/nouveau/dispnv50/head.h
> @@ -21,6 +21,7 @@ struct nv50_head {
>
> struct nv50_head *nv50_head_create(struct drm_device *, int index);
> void nv50_head_flush_set(struct nv50_head *head, struct nv50_head_atom
> *asyh);
> +void nv50_head_flush_set_wndw(struct nv50_head *head, struct nv50_head_atom
> *asyh);
> void nv50_head_flush_clr(struct nv50_head *head,
> struct nv50_head_atom *asyh, bool flush);
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH AUTOSEL 5.13 20/26] drm/nouveau: recognise GA107
This is more hardware enablement, I'm not sure this should be going into
stable either. Ben?
On Mon, 2021-08-23 at 20:53 -0400, Sasha Levin wrote:
> From: Ben Skeggs
>
> [ Upstream commit fa25f28ef2cef19bc9ffeb827b8ecbf48af7f892 ]
>
> Still no GA106 as I don't have HW to verif.
>
> Signed-off-by: Ben Skeggs
> Reviewed-by: Lyude Paul
> Signed-off-by: Sasha Levin
> ---
> .../gpu/drm/nouveau/nvkm/engine/device/base.c | 21 +++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> index b930f539feec..93ddf63d1114 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> @@ -2624,6 +2624,26 @@ nv174_chipset = {
> .dma = { 0x0001, gv100_dma_new },
> };
>
> +static const struct nvkm_device_chip
> +nv177_chipset = {
> + .name = "GA107",
> + .bar = { 0x0001, tu102_bar_new },
> + .bios = { 0x0001, nvkm_bios_new },
> + .devinit = { 0x0001, ga100_devinit_new },
> + .fb = { 0x0001, ga102_fb_new },
> + .gpio = { 0x0001, ga102_gpio_new },
> + .i2c = { 0x0001, gm200_i2c_new },
> + .imem = { 0x0001, nv50_instmem_new },
> + .mc = { 0x0001, ga100_mc_new },
> + .mmu = { 0x0001, tu102_mmu_new },
> + .pci = { 0x0001, gp100_pci_new },
> + .privring = { 0x0001, gm200_privring_new },
> + .timer = { 0x0001, gk20a_timer_new },
> + .top = { 0x0001, ga100_top_new },
> + .disp = { 0x0001, ga102_disp_new },
> + .dma = { 0x0001, gv100_dma_new },
> +};
> +
> static int
> nvkm_device_event_ctor(struct nvkm_object *object, void *data, u32 size,
> struct nvkm_notify *notify)
> @@ -3049,6 +3069,7 @@ nvkm_device_ctor(const struct nvkm_device_func *func,
> case 0x168: device->chip = &nv168_chipset; break;
> case 0x172: device->chip = &nv172_chipset; break;
> case 0x174: device->chip = &nv174_chipset; break;
> + case 0x177: device->chip = &nv177_chipset; break;
> default:
> if (nvkm_boolopt(device->cfgopt,
> "NvEnableUnsupportedChipsets", false)) {
> switch (device->chipset) {
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH v3] drm/dp_mst: Fix return code on sideband message failure
The patch was pushed yes (was part of drm-misc-next-2021-07-29), seems like it just hasn't trickled down to linus's branch quite yet. On Wed, 2021-08-25 at 09:06 -0700, khs...@codeaurora.org wrote: > On 2021-07-27 15:44, Lyude Paul wrote: > > Nice timing, you literally got me as I was 2 minutes away from leaving > > work > > for the day :P. I will go ahead and push it now. > > > Hi Lyude, > > Had you pushed this patch yet? > We still did not see this patch at msm-nex and v5.10 branch. > Thanks, > > > > BTW - in the future I recommend using dim to add Fixes: tags as it'll > > add Cc: > > to stable as appropriate (this patch in particular should be Cc: > > sta...@vger.kernel.org # v5.3+). will add these tags when I push it > > > > On Tue, 2021-07-27 at 15:41 -0700, khs...@codeaurora.org wrote: > > > On 2021-07-27 12:21, Lyude Paul wrote: > > > > On Thu, 2021-07-22 at 15:28 -0700, khs...@codeaurora.org wrote: > > > > > > > > > > It looks like this patch is good to go (mainlined). > > > > > Anything needed from me to do? > > > > > Thanks, > > > > > > > > Do you have access for pushing this patch? If not let me know and I > > > > can > > > > go > > > > ahead and push it to drm-misc-next for you. > > > no, I do not have access to drm-misc-next. > > > Please push it for me. > > > Thanks a lots. > > > > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [Intel-gfx] [PATCH 2/4] drm/dp: use more of the extended receiver cap
On Thu, 2021-08-26 at 14:11 +0300, Jani Nikula wrote:
> On Wed, 25 Aug 2021, Jani Nikula wrote:
> > On Thu, 19 Aug 2021, Ville Syrjälä wrote:
> > > On Fri, Aug 13, 2021 at 01:43:20PM +0300, Jani Nikula wrote:
> > > > Extend the use of extended receiver cap at 0x2200 to cover
> > > > MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation
> > > > hides
> > > > the DP 2.0 128b/132b channel encoding cap.
> > > >
> > > > Cc: Manasi Navare
> > > > Signed-off-by: Jani Nikula
> > > > ---
> > > > drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > index 9b2a2961fca8..9389f92cb944 100644
> > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > @@ -608,7 +608,7 @@ static u8 drm_dp_downstream_port_count(const u8
> > > > dpcd[DP_RECEIVER_CAP_SIZE])
> > > > static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
> > > > u8
> > > > dpcd[DP_RECEIVER_CAP_SIZE])
> > > > {
> > > > - u8 dpcd_ext[6];
> > > > + u8 dpcd_ext[DP_MAIN_LINK_CHANNEL_CODING + 1];
> > >
> > > Why are we even reading less of this than the normal receiver caps?
> >
> > Good question. I forget my reasoning to only extend to what might affect
> > this use case. Should we extend to the size of the usual receiver caps?
>
> Ah, there was a previous discussion [1] with Lyude (Cc'd).
Yeah - basically the problem is that we just need to make sure we take care to
avoid clearing info from the non-extended DPCD by accident. Extending this to
7 bits should be fine.
JFYI reading back at your comments it sounds like we might actually be safe to
read the entire DPCD, but we need to make sure we take care to avoid
accidentally replacing the main DPCD with a zeroed-out DPCD which could happen
on systems that have no support for extended DPCDs.
(Also - super bonus points if you can write a unit test to confirm we're not
overwriting the original DPCD! I don't know how much effort this would be
though so don't worry about it too much)
>
> BR,
> Jani.
>
>
> [1]
> https://patchwork.freedesktop.org/patch/msgid/20200901123226.4177-1-jani.nik...@intel.com
>
>
> >
> > BR,
> > Jani.
> >
> >
> > >
> > > > int ret;
> > > >
> > > > /*
> > > > --
> > > > 2.20.1
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
[PATCH 1/2] drm/nouveau/kms/nv50-: Use NV_ATOMIC() in nv50_head_atomic_check_lut()
Since this is used in the atomic check, we should use the right debug macro
for it.
Signed-off-by: Lyude Paul
Cc: Martin Peres
Cc: Jeremy Cline
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index ec361d17e900..fb821dcf6bd2 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -221,7 +221,10 @@ static int
nv50_head_atomic_check_lut(struct nv50_head *head,
struct nv50_head_atom *asyh)
{
- struct nv50_disp *disp = nv50_disp(head->base.base.dev);
+ struct drm_device *dev = head->base.base.dev;
+ struct drm_crtc *crtc = &head->base.base;
+ struct nv50_disp *disp = nv50_disp(dev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
struct drm_property_blob *olut = asyh->state.gamma_lut;
int size;
@@ -251,7 +254,8 @@ nv50_head_atomic_check_lut(struct nv50_head *head,
}
if (!head->func->olut(head, asyh, size)) {
- DRM_DEBUG_KMS("Invalid olut\n");
+ NV_ATOMIC(drm, "Invalid size %d for gamma on [CRTC:%d:%s]\n",
+ size, crtc->base.id, crtc->name);
return -EINVAL;
}
asyh->olut.handle = disp->core->chan.vram.handle;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/nouveau/kms/nv50-: Always validate LUTs in nv50_head_atomic_check_lut()
When it comes to gamma or degamma luts, nouveau will actually skip the
calculation of certain LUTs depending on the head and plane states. For
instance, when the head is disabled we don't perform any error checking on
the gamma LUT, and likewise if no planes are present and enabled in our
atomic state we will skip error checking the degamma LUT. This is a bit of
a problem though, since the per-head gamma and degamma props in DRM can be
changed even while a head is disabled - a situation which can be triggered
by the igt testcase mentioned down below.
Originally I thought this was a bit silly and was tempted to just fix the
igt test to only set gamma/degamma with the head enabled. After a bit of
thinking though I realized we should fix this in nouveau. This is because
if a program decides to set an invalid LUT for a head before enabling the
head, such a property change would succeed while also making it impossible
to turn the head back on until the LUT is removed or corrected - something
that could be painful for a user to figure out.
So, fix this checking both degamma and gamma LUTs unconditionally during
atomic checks. We start by calling nv50_head_atomic_check_lut() regardless
of whether the head is active or not in nv50_head_atomic_check(). Then we
move the ilut error checking into nv50_head_atomic_check_lut() and add a
per-head hook for it, primarily because as a per-CRTC property DRM we want
the LUT to be error checked by the head any time it's included in an atomic
state. Of course though, actual programming of the degamma lut to hardware
is still handled in each plane's atomic check and commit.
Signed-off-by: Lyude Paul
Testcase: igt/kms_color/pipe-invalid-*-lut-sizes
---
drivers/gpu/drm/nouveau/dispnv50/base907c.c | 6 +
drivers/gpu/drm/nouveau/dispnv50/head.c | 30 +++--
drivers/gpu/drm/nouveau/dispnv50/head.h | 2 ++
drivers/gpu/drm/nouveau/dispnv50/head907d.c | 6 +
drivers/gpu/drm/nouveau/dispnv50/head917d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 5 +---
drivers/gpu/drm/nouveau/dispnv50/wndw.h | 4 +--
drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 6 +
drivers/gpu/drm/nouveau/dispnv50/wndwc57e.c | 7 +++--
11 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/base907c.c
b/drivers/gpu/drm/nouveau/dispnv50/base907c.c
index 5396e3707cc4..e6b0417c325b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/base907c.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/base907c.c
@@ -103,12 +103,9 @@ base907c_xlut_set(struct nv50_wndw *wndw, struct
nv50_wndw_atom *asyw)
return 0;
}
-static bool
+static void
base907c_ilut(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw, int size)
{
- if (size != 256 && size != 1024)
- return false;
-
if (size == 1024)
asyw->xlut.i.mode =
NV907C_SET_BASE_LUT_LO_MODE_INTERPOLATE_1025_UNITY_RANGE;
else
@@ -116,7 +113,6 @@ base907c_ilut(struct nv50_wndw *wndw, struct nv50_wndw_atom
*asyw, int size)
asyw->xlut.i.enable = NV907C_SET_BASE_LUT_LO_ENABLE_ENABLE;
asyw->xlut.i.load = head907d_olut_load;
- return true;
}
static inline u32
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index fb821dcf6bd2..3b96eafb7bdd 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -225,9 +225,20 @@ nv50_head_atomic_check_lut(struct nv50_head *head,
struct drm_crtc *crtc = &head->base.base;
struct nv50_disp *disp = nv50_disp(dev);
struct nouveau_drm *drm = nouveau_drm(dev);
- struct drm_property_blob *olut = asyh->state.gamma_lut;
+ struct drm_property_blob *olut = asyh->state.gamma_lut,
+*ilut = asyh->state.degamma_lut;
int size;
+ /* Ensure that the ilut is valid */
+ if (ilut) {
+ size = drm_color_lut_size(ilut);
+ if (!head->func->ilut_check(size)) {
+ NV_ATOMIC(drm, "Invalid size %d for degamma on
[CRTC:%d:%s]\n",
+ size, crtc->base.id, crtc->name);
+ return -EINVAL;
+ }
+ }
+
/* Determine whether core output LUT should be enabled. */
if (olut) {
/* Check if any window(s) have stolen the core output LUT
@@ -329,8 +340,17 @@ nv50_head_atomic_check(struct drm_crtc *crtc, struct
drm_atomic_state *state)
struct drm_connector_state *conns;
struct drm_connector *conn;
int i, ret;
+ bool check_lut = asyh->state.color_mgmt_changed ||
+memcmp(&armh->wndw, &asyh->wndw, sizeof(asyh->wndw));
NV_AT
[PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
Looks like that there actually are another subset of laptops on the market
that don't support the Intel HDR backlight interface, but do advertise
support for the VESA DPCD backlight interface despite the fact it doesn't
seem to work.
Note though I'm not entirely clear on this - on one of the machines where
this issue was observed, I also noticed that we appeared to be rejecting
the VBT defined backlight frequency in
intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
/* Use highest possible value of Pn for more granularity of brightness
* adjustment while satifying the conditions below.
* ...
* - FxP is within 25% of desired value.
* Note: 25% is arbitrary value and may need some tweak.
*/
So it's possible that this value might just need to be tweaked, but for now
let's just disable the VESA backlight interface unless it's specified in
the VBT just to be safe. We might be able to try enabling this again by
default in the future.
Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight")
Cc: Jani Nikula
Cc: Rodrigo Vivi
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 651884390137..4f8337c7fd2e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *connector)
break;
case INTEL_BACKLIGHT_DISPLAY_DDI:
try_intel_interface = true;
- try_vesa_interface = true;
break;
default:
return -ENODEV;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
Actually-NAK this. I just realized I've been misreading the bug and that this
doesn't actually seem to be fixed. Will resend once I figure out what's going on
On Thu, 2021-03-18 at 13:02 -0400, Lyude Paul wrote:
> Looks like that there actually are another subset of laptops on the market
> that don't support the Intel HDR backlight interface, but do advertise
> support for the VESA DPCD backlight interface despite the fact it doesn't
> seem to work.
>
> Note though I'm not entirely clear on this - on one of the machines where
> this issue was observed, I also noticed that we appeared to be rejecting
> the VBT defined backlight frequency in
> intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
>
> /* Use highest possible value of Pn for more granularity of brightness
> * adjustment while satifying the conditions below.
> * ...
> * - FxP is within 25% of desired value.
> * Note: 25% is arbitrary value and may need some tweak.
> */
>
> So it's possible that this value might just need to be tweaked, but for now
> let's just disable the VESA backlight interface unless it's specified in
> the VBT just to be safe. We might be able to try enabling this again by
> default in the future.
>
> Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces through
> enable_dpcd_backlight")
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 651884390137..4f8337c7fd2e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *connector)
> break;
> case INTEL_BACKLIGHT_DISPLAY_DDI:
> try_intel_interface = true;
> - try_vesa_interface = true;
> break;
> default:
> return -ENODEV;
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/kms/nv50-: Check plane size for cursors, not fb size
Found this while trying to make some changes to the kms_cursor_crc test.
curs507a_acquire checks that the width and height of the cursor framebuffer
are equal (asyw->image.{w,h}). This is actually wrong though, as we only
want to be concerned that the actual width/height of the plane are the
same. It's fine if we scan out from an fb that's slightly larger than the
cursor plane (in fact, some igt tests actually do this).
Note that I'm not entirely sure why this wasn't previously breaking
kms_cursor_crc tests - they all set up cursors with the height being one
pixel larger than the actual size of the cursor. But this seems to fix
things, and the code before was definitely incorrect - so it's not really
worth looking into further imho.
Signed-off-by: Lyude Paul
Cc: Martin Peres
Cc: Jeremy Cline
---
drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/head507d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/head917d.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
index 54fbd6fe751d..7a7f80e51ec0 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
@@ -109,7 +109,7 @@ curs507a_acquire(struct nv50_wndw *wndw, struct
nv50_wndw_atom *asyw,
if (ret || !asyh->curs.visible)
return ret;
- if (asyw->image.w != asyw->image.h)
+ if (asyw->state.crtc_w != asyw->state.crtc_h)
return -EINVAL;
ret = head->func->curs_layout(head, asyw, asyh);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head507d.c
b/drivers/gpu/drm/nouveau/dispnv50/head507d.c
index 09b89983864b..3d230ca488c9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head507d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head507d.c
@@ -176,7 +176,7 @@ int
head507d_curs_layout(struct nv50_head *head, struct nv50_wndw_atom *asyw,
struct nv50_head_atom *asyh)
{
- switch (asyw->image.w) {
+ switch (asyw->state.crtc_w) {
case 32: asyh->curs.layout =
NV507D_HEAD_SET_CONTROL_CURSOR_SIZE_W32_H32; break;
case 64: asyh->curs.layout =
NV507D_HEAD_SET_CONTROL_CURSOR_SIZE_W64_H64; break;
default:
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head917d.c
b/drivers/gpu/drm/nouveau/dispnv50/head917d.c
index 4ce47b55f72c..caa7d633691b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head917d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head917d.c
@@ -103,7 +103,7 @@ int
head917d_curs_layout(struct nv50_head *head, struct nv50_wndw_atom *asyw,
struct nv50_head_atom *asyh)
{
- switch (asyw->state.fb->width) {
+ switch (asyw->state.crtc_w) {
case 32: asyh->curs.layout =
NV917D_HEAD_SET_CONTROL_CURSOR_SIZE_W32_H32; break;
case 64: asyh->curs.layout =
NV917D_HEAD_SET_CONTROL_CURSOR_SIZE_W64_H64; break;
case 128: asyh->curs.layout =
NV917D_HEAD_SET_CONTROL_CURSOR_SIZE_W128_H128; break;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: Check plane size for cursors, not fb size
On Thu, 2021-03-18 at 18:13 -0400, Ilia Mirkin wrote:
> On Thu, Mar 18, 2021 at 5:56 PM Lyude Paul wrote:
> >
> > Found this while trying to make some changes to the kms_cursor_crc test.
> > curs507a_acquire checks that the width and height of the cursor framebuffer
> > are equal (asyw->image.{w,h}). This is actually wrong though, as we only
> > want to be concerned that the actual width/height of the plane are the
> > same. It's fine if we scan out from an fb that's slightly larger than the
> > cursor plane (in fact, some igt tests actually do this).
>
> How so? The scanout engine expects the data to be packed. Height can
> be larger, but width has to match.
Huh - wasn't expecting that, nice catch. I'll fix this up in a moment
>
> -ilia
>
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/nouveau/kms/nv50-: Correct size checks for cursors
Found this while trying to make some changes to the kms_cursor_crc test.
curs507a_acquire checks that the width and height of the cursor framebuffer
are equal (asyw->image.{w,h}). This isn't entirely correct though, as the
height of the cursor can be larger than the size of the cursor, as long as
the width is the same as the cursor size and there's no framebuffer offset.
Note that I'm not entirely sure why this wasn't previously breaking
kms_cursor_crc tests - they all set up cursors with the height being one
pixel larger than the actual size of the cursor. But this seems to fix
things, and the code before was definitely incorrect - so it's not really
worth looking into further imho.
Changes since v1:
* Don't use crtc_w everywhere for determining cursor layout, just use fb
size again
* Change check so that we only check that the w/h of the cursor plane is
the same, the width of the scanout surface is the same as the framebuffer
width, and that there's no offset being used for the cursor surface.
Signed-off-by: Lyude Paul
Cc: Martin Peres
Cc: Jeremy Cline
---
drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
index 54fbd6fe751d..00e19fd959ea 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
@@ -98,6 +98,7 @@ static int
curs507a_acquire(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw,
struct nv50_head_atom *asyh)
{
+ struct nouveau_drm *drm = nouveau_drm(wndw->plane.dev);
struct nv50_head *head = nv50_head(asyw->state.crtc);
int ret;
@@ -109,8 +110,20 @@ curs507a_acquire(struct nv50_wndw *wndw, struct
nv50_wndw_atom *asyw,
if (ret || !asyh->curs.visible)
return ret;
- if (asyw->image.w != asyw->image.h)
+ if (asyw->state.crtc_w != asyw->state.crtc_h) {
+ NV_ATOMIC(drm, "Plane width/height must be equal for
cursors\n");
return -EINVAL;
+ }
+
+ if (asyw->image.w != asyw->state.crtc_w) {
+ NV_ATOMIC(drm, "Plane width must be equal to fb width for
cursors (height can be larger though)\n");
+ return -EINVAL;
+ }
+
+ if (asyw->state.src_x || asyw->state.src_y) {
+ NV_ATOMIC(drm, "Cursor planes do not support framebuffer
offsets\n");
+ return -EINVAL;
+ }
ret = head->func->curs_layout(head, asyw, asyh);
if (ret)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: Enhance DP MST topology logging
(*name != 0) ? name : "Unknown");
> + seq_printf(m, "%10d%10d%10d%10d%20s\n",
> + i,
> + port->port_num,
> + port->vcpi.vcpi,
> + port->vcpi.num_slots,
> + (*name != 0) ? name : "Unknown");
> } else
> - seq_printf(m, "vcpi %d:unused\n", i);
> + seq_printf(m, "%6d - Unused\n", i);
> }
> + seq_printf(m, "\n *** Payload Info ***\n");
> + seq_printf(m, "| idx | state | start slot | # slots |\n");
> for (i = 0; i < mgr->max_payloads; i++) {
> - seq_printf(m, "payload %d: %d, %d, %d\n",
> - i,
> - mgr->payloads[i].payload_state,
> - mgr->payloads[i].start_slot,
> - mgr->payloads[i].num_slots);
> -
> -
> + seq_printf(m, "%10d%10d%15d%10d\n",
> + i,
> + mgr->payloads[i].payload_state,
> + mgr->payloads[i].start_slot,
> + mgr->payloads[i].num_slots);
> }
> mutex_unlock(&mgr->payload_lock);
>
> + seq_printf(m, "\n *** DPCD Info ***\n");
> mutex_lock(&mgr->lock);
> if (mgr->mst_primary) {
> u8 buf[DP_PAYLOAD_TABLE_SIZE];
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/19] drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static
Reviewed-by: Lyude Paul
On Fri, 2021-03-19 at 08:24 +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
> prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
>
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Lyude Paul
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> index fd51527b56b83..bdcfd240d61c8 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> @@ -169,7 +169,7 @@ headc57d_olut_load(struct drm_color_lut *in, int size,
> void __iomem *mem)
> writew(readw(mem - 4), mem + 4);
> }
>
> -bool
> +static bool
> headc57d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size)
> {
> if (size != 0 && size != 256 && size != 1024)
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
On Tue, 2021-03-23 at 16:06 +0200, Jani Nikula wrote:
> On Thu, 18 Mar 2021, Lyude Paul wrote:
> > Actually-NAK this. I just realized I've been misreading the bug and that
> > this
> > doesn't actually seem to be fixed. Will resend once I figure out what's
> > going on
>
> Well, I think there are actually multiple issues on multiple
> machines. This fixes the issue on ThinkPad X1 Titanium Gen1 [1].
>
> I suspect reverting 98e497e203a5 ("drm/i915/dpcd_bl: uncheck PWM_PIN_CAP
> when detect eDP backlight capabilities") would too. But then that would
> break *other* machines that claim support for *both* eDP PWM pin and
> DPCD backlight control, I think.
>
> I think there are issues with how we try setup DPCD backlight if the GOP
> has set up PWM backlight. For example, we don't set the backlight
> control mode correctly until the next disable/enable sequence. However,
> I tried to fix this, and I think I was doing all the right things, and
> DPCD reads seemed to confirm this, yet I was not able to control
> brightness using DPCD. I don't know what gives, but I do know eDP PWM
> pin control works.
Should we go ahead and push the VESA fix for this then? If you're willing to
test future patches on that machine, we could give another shot at enabling this
in the future if we find reason to.
>
>
> BR,
> Jani.
>
>
> [1] https://gitlab.freedesktop.org/drm/intel/-/issues/3158
>
>
> >
> > On Thu, 2021-03-18 at 13:02 -0400, Lyude Paul wrote:
> > > Looks like that there actually are another subset of laptops on the market
> > > that don't support the Intel HDR backlight interface, but do advertise
> > > support for the VESA DPCD backlight interface despite the fact it doesn't
> > > seem to work.
> > >
> > > Note though I'm not entirely clear on this - on one of the machines where
> > > this issue was observed, I also noticed that we appeared to be rejecting
> > > the VBT defined backlight frequency in
> > > intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
> > >
> > > /* Use highest possible value of Pn for more granularity of brightness
> > > * adjustment while satifying the conditions below.
> > > * ...
> > > * - FxP is within 25% of desired value.
> > > * Note: 25% is arbitrary value and may need some tweak.
> > > */
> > >
> > > So it's possible that this value might just need to be tweaked, but for
> > > now
> > > let's just disable the VESA backlight interface unless it's specified in
> > > the VBT just to be safe. We might be able to try enabling this again by
> > > default in the future.
> > >
> > > Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces
> > > through
> > > enable_dpcd_backlight")
> > > Cc: Jani Nikula
> > > Cc: Rodrigo Vivi
> > > Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
> > > Signed-off-by: Lyude Paul
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > index 651884390137..4f8337c7fd2e 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
> > > intel_connector *connector)
> > > break;
> > > case INTEL_BACKLIGHT_DISPLAY_DDI:
> > > try_intel_interface = true;
> > > - try_vesa_interface = true;
> > > break;
> > > default:
> > > return -ENODEV;
>
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers: gpu: priv.h is included twice
Reviewed-by: Lyude Paul On Mon, 2021-03-22 at 20:45 +0800, Wan Jiabing wrote: > priv.h has been included at line 22, so remove > the duplicate include at line 24. > > Signed-off-by: Wan Jiabing > --- > drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c > b/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c > index c39e797dc7c9..09524168431c 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c > @@ -20,8 +20,6 @@ > * OTHER DEALINGS IN THE SOFTWARE. > */ > #include "priv.h" > - > -#include "priv.h" > #include > > static void * -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've asked me a question, are waiting for a review/merge on a patch, etc. and I haven't responded in a while, please feel free to send me another email to check on my status. I don't bite! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: Enhance DP MST topology logging
>max_payloads; i++) {
> if (mgr->proposed_vcpis[i]) {
> char name[14];
>
> port = container_of(mgr->proposed_vcpis[i], struct
> drm_dp_mst_port, vcpi);
> fetch_monitor_name(mgr, port, name, sizeof(name));
> - seq_printf(m, "vcpi %d: %d %d %d sink name: %s\n", i,
> - port->port_num, port->vcpi.vcpi,
> - port->vcpi.num_slots,
> - (*name != 0) ? name : "Unknown");
> + seq_printf(m, "%10d%10d%10d%10d%20s\n",
> + i,
> + port->port_num,
> + port->vcpi.vcpi,
> + port->vcpi.num_slots,
> + (*name != 0) ? name : "Unknown");
Maybe cleanup the second space after the : here while you're at it. Also, the
indenting is wrong here too
> } else
> - seq_printf(m, "vcpi %d:unused\n", i);
> + seq_printf(m, "%6d - Unused\n", i);
> }
> + seq_printf(m, "\n *** Payload Info ***\n");
^
another accidental space
> + seq_printf(m, "| idx | state | start slot | # slots |\n");
> for (i = 0; i < mgr->max_payloads; i++) {
> - seq_printf(m, "payload %d: %d, %d, %d\n",
> - i,
> - mgr->payloads[i].payload_state,
> - mgr->payloads[i].start_slot,
> - mgr->payloads[i].num_slots);
> -
> -
> + seq_printf(m, "%10d%10d%15d%10d\n",
> + i,
> + mgr->payloads[i].payload_state,
> + mgr->payloads[i].start_slot,
> + mgr->payloads[i].num_slots);
Need to correct the indenting here as well
> }
> mutex_unlock(&mgr->payload_lock);
>
> + seq_printf(m, "\n *** DPCD Info ***\n");
^ another extra space
> mutex_lock(&mgr->lock);
> if (mgr->mst_primary) {
> u8 buf[DP_PAYLOAD_TABLE_SIZE];
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/mst: Enhance MST topology logging
Reviewed-by: Lyude Paul
Let me know if you need me to push this to drm-misc-next for you
On Thu, 2021-03-25 at 14:06 -0400, Eryk Brol wrote:
> [why]
> MST topology print was missing fec logging and pdt printed
> as an int wasn't clear. vcpi and payload info was printed as an
> arbitrary series of ints which requires user to know the ordering
> of the prints, making the logs difficult to use.
>
> [how]
> -add fec logging
> -add pdt parsing into strings
> -format vcpi and payload info into tables with headings
> -clean up topology prints
>
> ---
>
> v2: Addressed Lyude's comments
> -made helper function return const
> -fixed indentation and spacing issues
>
> Signed-off-by: Eryk Brol
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 59 ++-
> 1 file changed, 48 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 932c4641ec3e..de5124ce42cb 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4720,6 +4720,28 @@ static void drm_dp_mst_kick_tx(struct
> drm_dp_mst_topology_mgr *mgr)
> queue_work(system_long_wq, &mgr->tx_work);
> }
>
> +/*
> + * Helper function for parsing DP device types into convenient strings
> + * for use with dp_mst_topology
> + */
> +static const char *pdt_to_string(u8 pdt)
> +{
> + switch (pdt) {
> + case DP_PEER_DEVICE_NONE:
> + return "NONE";
> + case DP_PEER_DEVICE_SOURCE_OR_SST:
> + return "SOURCE OR SST";
> + case DP_PEER_DEVICE_MST_BRANCHING:
> + return "MST BRANCHING";
> + case DP_PEER_DEVICE_SST_SINK:
> + return "SST SINK";
> + case DP_PEER_DEVICE_DP_LEGACY_CONV:
> + return "DP LEGACY CONV";
> + default:
> + return "ERR";
> + }
> +}
> +
> static void drm_dp_mst_dump_mstb(struct seq_file *m,
> struct drm_dp_mst_branch *mstb)
> {
> @@ -4732,9 +4754,20 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
> prefix[i] = '\t';
> prefix[i] = '\0';
>
> - seq_printf(m, "%smst: %p, %d\n", prefix, mstb, mstb->num_ports);
> + seq_printf(m, "%smstb - [%p]: num_ports: %d\n", prefix, mstb, mstb-
> >num_ports);
> list_for_each_entry(port, &mstb->ports, next) {
> - seq_printf(m, "%sport: %d: input: %d: pdt: %d, ddps: %d ldps:
> %d, sdp: %d/%d, %p, conn: %p\n", prefix, port->port_num, port->input, port-
> >pdt, port->ddps, port->ldps, port->num_sdp_streams, port-
> >num_sdp_stream_sinks, port, port->connector);
> + seq_printf(m, "%sport %d - [%p] (%s - %s): ddps: %d, ldps: %d,
> sdp: %d/%d, fec: %s, conn: %p\n",
> + prefix,
> + port->port_num,
> + port,
> + port->input ? "input" : "output",
> + pdt_to_string(port->pdt),
> + port->ddps,
> + port->ldps,
> + port->num_sdp_streams,
> + port->num_sdp_stream_sinks,
> + port->fec_capable ? "true" : "false",
> + port->connector);
> if (port->mstb)
> drm_dp_mst_dump_mstb(m, port->mstb);
> }
> @@ -4787,33 +4820,37 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
> mutex_unlock(&mgr->lock);
>
> mutex_lock(&mgr->payload_lock);
> - seq_printf(m, "vcpi: %lx %lx %d\n", mgr->payload_mask, mgr->vcpi_mask,
> - mgr->max_payloads);
> + seq_printf(m, "\n*** VCPI Info ***\n");
> + seq_printf(m, "payload_mask: %lx, vcpi_mask: %lx, max_payloads: %d\n",
> mgr->payload_mask, mgr->vcpi_mask, mgr->max_payloads);
>
> + seq_printf(m, "\n| idx | port # | vcp_id | # slots | sink
> name |\n");
> for (i = 0; i < mgr->max_payloads; i++) {
> if (mgr->proposed_vcpis[i]) {
> char name[14];
>
> port = container_of(mgr->proposed_vcpis[i], struct
> drm_dp_mst_port, vcpi);
> fetch_monitor_name(mgr, port, name, sizeof(name));
>
Re: [PATCH] drm: Update MST First Link Slot Information Based on Encoding Format
rst_link_slot_info);
> +
> /**
> * drm_dp_mst_allocate_vcpi() - Allocate a virtual channel
> * @mgr: manager for this port
> @@ -4518,8 +4546,8 @@ bool drm_dp_mst_allocate_vcpi(struct
> drm_dp_mst_topology_mgr *mgr,
>
> ret = drm_dp_init_vcpi(mgr, &port->vcpi, pbn, slots);
> if (ret) {
> - DRM_DEBUG_KMS("failed to init vcpi slots=%d max=63 ret=%d\n",
> - DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
> + DRM_DEBUG_KMS("failed to init vcpi slots=%d max=%d ret=%d\n",
> + DIV_ROUND_UP(pbn, mgr->pbn_div), mgr-
> >first_link_total_avail_slots, ret);
> drm_dp_mst_topology_put_port(port);
> goto out;
> }
> @@ -5162,7 +5190,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct
> drm_dp_mst_topology_mgr *mgr,
> struct drm_dp_mst_topology_state
> *mst_state)
> {
> struct drm_dp_vcpi_allocation *vcpi;
> - int avail_slots = 63, payload_count = 0;
> + int avail_slots = mgr->first_link_total_avail_slots, payload_count =
> 0;
>
> list_for_each_entry(vcpi, &mst_state->vcpis, next) {
> /* Releasing VCPI is always OK-even if the port is gone */
> @@ -5191,7 +5219,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct
> drm_dp_mst_topology_mgr *mgr,
> }
> DRM_DEBUG_ATOMIC("[MST MGR:%p] mst state %p VCPI avail=%d used=%d\n",
> mgr, mst_state, avail_slots,
> - 63 - avail_slots);
> + mgr->first_link_total_avail_slots - avail_slots);
>
> return 0;
> }
> @@ -5455,6 +5483,8 @@ int drm_dp_mst_topology_mgr_init(struct
> drm_dp_mst_topology_mgr *mgr,
> if (!mgr->proposed_vcpis)
> return -ENOMEM;
> set_bit(0, &mgr->payload_mask);
> + mgr->first_link_total_avail_slots = 63;
> + mgr->first_link_start_slot = 1;
>
> mst_state = kzalloc(sizeof(*mst_state), GFP_KERNEL);
> if (mst_state == NULL)
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index bd1c39907b92..f4310b3705e7 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -653,6 +653,13 @@ struct drm_dp_mst_topology_mgr {
> */
> int pbn_div;
>
> + /**
> + * @first_link_total_avail_slots: frist link total slots available.
> + * @first_link_start_slot: start slot index for real data
> transmission.
> + */
These kernel docs are also broken, you can't define two variables in the same
kernel doc comment if it's embedded in the struct, there has to be one kernel
doc comment per-member. Attempting to generate documentation with make htmldocs
even mentions this:
./include/drm/drm_dp_mst_helper.h:770: warning: Function parameter or member
'first_link_start_slot' not described in 'drm_dp_mst_topology_mgr'
> + u8 first_link_total_avail_slots;
> + u8 first_link_start_slot;
> +
> /**
> * @funcs: Atomic helper callbacks
> */
> @@ -795,6 +802,7 @@ int drm_dp_mst_get_vcpi_slots(struct
> drm_dp_mst_topology_mgr *mgr, struct drm_dp
>
> void drm_dp_mst_reset_vcpi_slots(struct drm_dp_mst_topology_mgr *mgr, struct
> drm_dp_mst_port *port);
>
> +void drm_dp_mst_update_first_link_slot_info(struct drm_dp_mst_topology_mgr
> *mgr, uint8_t encoding_format);
>
> void drm_dp_mst_deallocate_vcpi(struct drm_dp_mst_topology_mgr *mgr,
> struct drm_dp_mst_port *port);
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/20] drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers
Since it's been asked quite a few times on some of the various DP
related patch series I've submitted to use the new DRM printk helpers,
and it technically wasn't really trivial to do this before due to the
lack of a consistent way to find a drm_device for an AUX channel, this
patch series aims to address this. In this series we:
* Clean-up potentially erroneous usages of drm_dp_aux_init() and
drm_dp_aux_register() so that actual AUX registration doesn't happen
until we have an associated DRM device
* Clean-up any obvious errors in drivers we find along the way
* Add a backpointer to the respective drm_device for an AUX channel in
drm_dp_aux.drm_dev, and hook it up in every driver with an AUX channel
across the tree
* Add a new ratelimited print helper we'll need for converting the DP
helpers over to using the new DRM printk helpers
* Fix any inconsistencies with logging in drm_dp_helper.c so we always
have the aux channel name printed
* Prepare the various DP helpers so they can find the correct drm_device
to use for logging
* And finally, convert all of the DP helpers over to using drm_dbg_*()
and drm_err().
Series-wide changes in v2:
* Address most checkpatch issues ('most' as in all except for one line
going two chars over 100 in "drm/dp_mst: Pass drm_dp_mst_topology_mgr
to drm_dp_get_vc_payload_bw()" as this was the style in use
previously, and 2 chars over the limit looks nicer then trying to
line-wrap this
* Don't rewrap comments
Lyude Paul (20):
drm/dp: Fixup kernel docs for struct drm_dp_aux
drm/tegra: Don't register DP AUX channels before connectors
drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace
drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late
register/early unregister
drm/dp: Add backpointer to drm_device in drm_dp_aux
drm/dp: Clarify DP AUX registration time
drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED()
drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()
drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay()
drm/dp: Always print aux channel name in logs
drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect()
drm/dp_dual_mode: Pass drm_device to
drm_dp_dual_mode_set_tmds_output()
drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_max_tmds_clock()
drm/dp_dual_mode: Pass drm_device to
drm_dp_dual_mode_get_tmds_output()
drm/dp_dual_mode: Pass drm_device to drm_lspcon_(get|set)_mode()
drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw()
drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()
drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using
drm_err/drm_dbg_kms()
drm/dp_mst: Drop DRM_ERROR() on kzalloc() fail in
drm_dp_mst_handle_up_req()
drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 5 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 +
.../drm/bridge/analogix/analogix-anx6345.c| 1 +
.../drm/bridge/analogix/analogix-anx78xx.c| 1 +
.../drm/bridge/analogix/analogix_dp_core.c| 1 +
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 12 +-
drivers/gpu/drm/bridge/tc358767.c | 1 +
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 +
drivers/gpu/drm/drm_dp_aux_dev.c | 6 +
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 68 ++--
drivers/gpu/drm/drm_dp_helper.c | 181 +
drivers/gpu/drm/drm_dp_mst_topology.c | 381 +-
drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 +
.../drm/i915/display/intel_dp_link_training.c | 6 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 7 +-
drivers/gpu/drm/i915/display/intel_lspcon.c | 17 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c | 6 +-
drivers/gpu/drm/msm/edp/edp.h | 3 +-
drivers/gpu/drm/msm/edp/edp_aux.c | 5 +-
drivers/gpu/drm/msm/edp/edp_ctrl.c| 8 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 27 +-
drivers/gpu/drm/radeon/atombios_dp.c | 5 +-
drivers/gpu/drm/tegra/dpaux.c | 12 +-
drivers/gpu/drm/xlnx/zynqmp_dp.c | 5 +-
include/drm/drm_dp_dual_mode_helper.h | 14 +-
include/drm/drm_dp_helper.h | 61 +--
include/drm/drm_dp_mst_helper.h | 3 +-
include/drm/drm_print.h | 20 +-
29 files changed, 478 insertions(+), 384 deletions(-)
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/20] drm/dp: Fixup kernel docs for struct drm_dp_aux
* Make sure that struct members are referred to using @, otherwise they
won't be formatted as such
* Make sure to refer to other struct types using & so they link back to
each struct's definition
* Make sure to precede constant values with % so they're formatted
correctly
Signed-off-by: Lyude Paul
Acked-by: Randy Dunlap
---
include/drm/drm_dp_helper.h | 44 ++---
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 632ad7faa006..5efa0d329b67 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1844,34 +1844,34 @@ struct drm_dp_aux_cec {
* @crc_count: counter of captured frame CRCs
* @transfer: transfers a message representing a single AUX transaction
*
- * The .dev field should be set to a pointer to the device that implements
- * the AUX channel.
+ * The @dev field should be set to a pointer to the device that implements the
+ * AUX channel.
*
- * The .name field may be used to specify the name of the I2C adapter. If set
to
- * NULL, dev_name() of .dev will be used.
+ * The @name field may be used to specify the name of the I2C adapter. If set
to
+ * %NULL, dev_name() of @dev will be used.
*
- * Drivers provide a hardware-specific implementation of how transactions
- * are executed via the .transfer() function. A pointer to a drm_dp_aux_msg
+ * Drivers provide a hardware-specific implementation of how transactions are
+ * executed via the @transfer() function. A pointer to a &drm_dp_aux_msg
* structure describing the transaction is passed into this function. Upon
- * success, the implementation should return the number of payload bytes
- * that were transferred, or a negative error-code on failure. Helpers
- * propagate errors from the .transfer() function, with the exception of
- * the -EBUSY error, which causes a transaction to be retried. On a short,
- * helpers will return -EPROTO to make it simpler to check for failure.
+ * success, the implementation should return the number of payload bytes that
+ * were transferred, or a negative error-code on failure. Helpers propagate
+ * errors from the @transfer() function, with the exception of the %-EBUSY
+ * error, which causes a transaction to be retried. On a short, helpers will
+ * return %-EPROTO to make it simpler to check for failure.
*
* An AUX channel can also be used to transport I2C messages to a sink. A
- * typical application of that is to access an EDID that's present in the
- * sink device. The .transfer() function can also be used to execute such
- * transactions. The drm_dp_aux_register() function registers an I2C
- * adapter that can be passed to drm_probe_ddc(). Upon removal, drivers
- * should call drm_dp_aux_unregister() to remove the I2C adapter.
- * The I2C adapter uses long transfers by default; if a partial response is
- * received, the adapter will drop down to the size given by the partial
- * response for this transaction only.
+ * typical application of that is to access an EDID that's present in the sink
+ * device. The @transfer() function can also be used to execute such
+ * transactions. The drm_dp_aux_register() function registers an I2C adapter
+ * that can be passed to drm_probe_ddc(). Upon removal, drivers should call
+ * drm_dp_aux_unregister() to remove the I2C adapter. The I2C adapter uses long
+ * transfers by default; if a partial response is received, the adapter will
+ * drop down to the size given by the partial response for this transaction
+ * only.
*
- * Note that the aux helper code assumes that the .transfer() function
- * only modifies the reply field of the drm_dp_aux_msg structure. The
- * retry logic and i2c helpers assume this is the case.
+ * Note that the aux helper code assumes that the @transfer() function only
+ * modifies the reply field of the &drm_dp_aux_msg structure. The retry logic
+ * and i2c helpers assume this is the case.
*/
struct drm_dp_aux {
const char *name;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/20] drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace
Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 989a05bc8197..d966a33743b5 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -1674,10 +1674,14 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
dev_dbg(mhdp->dev, "%s\n", __func__);
+ ret = drm_dp_aux_register(&mhdp->aux);
+ if (ret < 0)
+ return ret;
+
if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
ret = cdns_mhdp_connector_init(mhdp);
if (ret)
- return ret;
+ goto aux_unregister;
}
spin_lock(&mhdp->start_lock);
@@ -1693,6 +1697,9 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
mhdp->regs + CDNS_APB_INT_MASK);
return 0;
+aux_unregister:
+ drm_dp_aux_unregister(&mhdp->aux);
+ return ret;
}
static void cdns_mhdp_configure_video(struct cdns_mhdp_device *mhdp,
@@ -2025,6 +2032,8 @@ static void cdns_mhdp_detach(struct drm_bridge *bridge)
dev_dbg(mhdp->dev, "%s\n", __func__);
+ drm_dp_aux_unregister(&mhdp->aux);
+
spin_lock(&mhdp->start_lock);
mhdp->bridge_attached = false;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/20] drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister
Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 26 ++---
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 61e6d7412505..bfce762adcf0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -905,13 +905,29 @@ nouveau_connector_late_register(struct drm_connector
*connector)
int ret;
ret = nouveau_backlight_init(connector);
+ if (ret)
+ return ret;
+
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ ret = drm_dp_aux_register(&nouveau_connector(connector)->aux);
+ if (ret)
+ goto backlight_fini;
+ }
+ return 0;
+backlight_fini:
+ nouveau_backlight_fini(connector);
return ret;
}
static void
nouveau_connector_early_unregister(struct drm_connector *connector)
{
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+ drm_dp_aux_unregister(&nouveau_connector(connector)->aux);
+
nouveau_backlight_fini(connector);
}
@@ -1343,14 +1359,8 @@ nouveau_connector_create(struct drm_device *dev,
snprintf(aux_name, sizeof(aux_name), "sor-%04x-%04x",
dcbe->hasht, dcbe->hashm);
nv_connector->aux.name = kstrdup(aux_name, GFP_KERNEL);
- ret = drm_dp_aux_register(&nv_connector->aux);
- if (ret) {
- NV_ERROR(drm, "failed to register aux channel\n");
- kfree(nv_connector);
- return ERR_PTR(ret);
- }
- funcs = &nouveau_connector_funcs;
- break;
+ drm_dp_aux_init(&nv_connector->aux);
+ fallthrough;
default:
funcs = &nouveau_connector_funcs;
break;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/20] drm/tegra: Don't register DP AUX channels before connectors
As pointed out by the documentation for drm_dp_aux_register(),
drm_dp_aux_init() should be used in situations where the AUX channel for a
display driver can potentially be registered before it's respective DRM
driver. This is the case with Tegra, since the DP aux channel exists as a
platform device instead of being a grandchild of the DRM device.
Since we're about to add a backpointer to a DP AUX channel's respective DRM
device, let's fix this so that we don't potentially allow userspace to use
the AUX channel before we've associated it with it's DRM connector.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/tegra/dpaux.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 105fb9cdbb3b..ea56c6ec25e4 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -534,9 +534,7 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
dpaux->aux.transfer = tegra_dpaux_transfer;
dpaux->aux.dev = &pdev->dev;
- err = drm_dp_aux_register(&dpaux->aux);
- if (err < 0)
- return err;
+ drm_dp_aux_init(&dpaux->aux);
/*
* Assume that by default the DPAUX/I2C pads will be used for HDMI,
@@ -589,8 +587,6 @@ static int tegra_dpaux_remove(struct platform_device *pdev)
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
- drm_dp_aux_unregister(&dpaux->aux);
-
mutex_lock(&dpaux_lock);
list_del(&dpaux->list);
mutex_unlock(&dpaux_lock);
@@ -723,6 +719,10 @@ int drm_dp_aux_attach(struct drm_dp_aux *aux, struct
tegra_output *output)
unsigned long timeout;
int err;
+ err = drm_dp_aux_register(aux);
+ if (err < 0)
+ return err;
+
output->connector.polled = DRM_CONNECTOR_POLL_HPD;
dpaux->output = output;
@@ -760,6 +760,7 @@ int drm_dp_aux_detach(struct drm_dp_aux *aux)
unsigned long timeout;
int err;
+ drm_dp_aux_unregister(aux);
disable_irq(dpaux->irq);
if (dpaux->output->panel) {
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/20] drm/dp: Add backpointer to drm_device in drm_dp_aux
This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for doing so.
Note that there is one limitation with this - because some DP AUX adapters
exist as platform devices which are initialized independently of their
respective DRM devices, one cannot rely on drm_dp_aux->drm_dev to always be
non-NULL until drm_dp_aux_register() has been called. We make sure to point
this out in the documentation for struct drm_dp_aux.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 1 +
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 +
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 1 +
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 1 +
drivers/gpu/drm/bridge/tc358767.c| 1 +
drivers/gpu/drm/bridge/ti-sn65dsi86.c| 1 +
drivers/gpu/drm/drm_dp_aux_dev.c | 6 ++
drivers/gpu/drm/drm_dp_mst_topology.c| 1 +
drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 +
drivers/gpu/drm/msm/edp/edp.h| 3 +--
drivers/gpu/drm/msm/edp/edp_aux.c| 5 +++--
drivers/gpu/drm/msm/edp/edp_ctrl.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 1 +
drivers/gpu/drm/radeon/atombios_dp.c | 1 +
drivers/gpu/drm/tegra/dpaux.c| 1 +
drivers/gpu/drm/xlnx/zynqmp_dp.c | 1 +
include/drm/drm_dp_helper.h | 9 -
19 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index a3ba9ca11e98..6d35da65e09f 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -188,6 +188,7 @@ void amdgpu_atombios_dp_aux_init(struct amdgpu_connector
*amdgpu_connector)
{
amdgpu_connector->ddc_bus->rec.hpd = amdgpu_connector->hpd.hpd;
amdgpu_connector->ddc_bus->aux.transfer =
amdgpu_atombios_dp_aux_transfer;
+ amdgpu_connector->ddc_bus->aux.drm_dev = amdgpu_connector->base.dev;
drm_dp_aux_init(&amdgpu_connector->ddc_bus->aux);
amdgpu_connector->ddc_bus->has_aux = true;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 73cdb9fe981a..b8b69c33fb2b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -434,6 +434,7 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
link_index);
aconnector->dm_dp_aux.aux.transfer = dm_dp_aux_transfer;
aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc;
+ aconnector->dm_dp_aux.aux.drm_dev = dm->ddev;
drm_dp_aux_init(&aconnector->dm_dp_aux.aux);
drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index aa6cda458eb9..e33cd077595a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -537,6 +537,7 @@ static int anx6345_bridge_attach(struct drm_bridge *bridge,
/* Register aux channel */
anx6345->aux.name = "DP-AUX";
anx6345->aux.dev = &anx6345->client->dev;
+ anx6345->aux.drm_dev = bridge->dev;
anx6345->aux.transfer = anx6345_aux_transfer;
err = drm_dp_aux_register(&anx6345->aux);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index f20558618220..5e6a0ed39199 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -905,6 +905,7 @@ static int anx78xx_bridge_attach(struct drm_bridge *bridge,
/* Register aux channel */
anx78xx->aux.name = "DP-AUX";
anx78xx->aux.dev = &anx78xx->client->dev;
+ anx78xx->aux.drm_dev = bridge->dev;
anx78xx->aux.transfer = anx78xx_aux_transfer;
err = drm_dp_aux_register(&anx78xx->aux);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f115233b1cb9..550814ca2139 1
[PATCH v2 08/20] drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
drivers/gpu/drm/msm/edp/edp_ctrl.c| 2 +-
drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
include/drm/drm_dp_helper.h | 4 +++-
8 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 6d35da65e09f..4468f9d6b4dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -611,7 +611,7 @@ amdgpu_atombios_dp_link_train_cr(struct
amdgpu_atombios_dp_link_train_info *dp_i
dp_info->tries = 0;
voltage = 0xff;
while (1) {
- drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
+ drm_dp_link_train_clock_recovery_delay(dp_info->aux,
dp_info->dpcd);
if (drm_dp_dpcd_read_link_status(dp_info->aux,
dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3fa858b9691c..4462624daefc 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -132,7 +132,8 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZ
}
EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
-void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
+void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 5e9c3c74310c..f543b494f052 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -513,7 +513,7 @@ static void
intel_dp_link_training_clock_recovery_delay(struct intel_dp *intel_d
enum drm_dp_phy dp_phy)
{
if (dp_phy == DP_PHY_DPRX)
- drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
+ drm_dp_link_train_clock_recovery_delay(&intel_dp->aux,
intel_dp->dpcd);
else
drm_dp_lttpr_link_train_clock_recovery_delay();
}
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 1390f3547fde..264a9eae87d3 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1103,7 +1103,7 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private
*ctrl,
tries = 0;
old_v_level = ctrl->link->phy_params.v_level;
for (tries = 0; tries < maximum_retries; tries++) {
- drm_dp_link_train_clock_recovery_delay(ctrl->panel->dpcd);
+ drm_dp_link_train_clock_recovery_delay(ctrl->aux,
ctrl->panel->dpcd);
ret = dp_ctrl_read_link_status(ctrl, link_status);
if (ret)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 57af3d8b6699..6501598448b4 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -608,7 +608,7 @@ static int edp_start_link_train_1(struct edp_ctrl *ctrl)
tries = 0;
old_v_level = ctrl->v_level;
while (1) {
- drm_dp_link_train_clock_recovery_delay(ctrl->dpcd);
+ drm_dp_link_train_clock_recovery_delay(ctrl->drm_aux,
ctrl->dpcd);
rlen = drm_dp_dpcd_read_link_status(ctrl->drm_aux, link_status);
if (rlen < DP_LINK_STATUS_SIZE) {
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index c50c504bad50..299b9d8da376 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -680,7 +680,7 @@ static int radeon_dp_link_train_cr(struct
radeon_dp_link_train_info *dp_info)
dp_info->tries = 0;
voltage = 0xff;
while (1) {
- drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
+ drm_dp_link_train_clock_recovery_delay(dp_info->aux,
dp_info->dpcd);
if (drm_dp_dpcd_read_link_status(dp_info->aux,
dp_
[PATCH v2 06/20] drm/dp: Clarify DP AUX registration time
The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly
correct, except for the fact that they made the assumption that all AUX
devices were grandchildren of their respective DRM devices. This is the
case for most normal GPUs, but is almost never the case with SoCs and
display bridges. So, let's fix this documentation to clarify when the right
time to use drm_dp_aux_init() or drm_dp_aux_register() is.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 44 +++--
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eedbb48815b7..3fa858b9691c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1728,10 +1728,17 @@ EXPORT_SYMBOL(drm_dp_remote_aux_init);
* drm_dp_aux_init() - minimally initialise an aux channel
* @aux: DisplayPort AUX channel
*
- * If you need to use the drm_dp_aux's i2c adapter prior to registering it
- * with the outside world, call drm_dp_aux_init() first. You must still
- * call drm_dp_aux_register() once the connector has been registered to
- * allow userspace access to the auxiliary DP channel.
+ * If you need to use the drm_dp_aux's i2c adapter prior to registering it with
+ * the outside world, call drm_dp_aux_init() first. For drivers which are
+ * grandparents to their AUX adapters (e.g. the AUX adapter is parented by a
+ * &drm_connector), you must still call drm_dp_aux_register() once the
connector
+ * has been registered to allow userspace access to the auxiliary DP channel.
+ * Likewise, for such drivers you should also assign &drm_dp_aux.drm_dev as
+ * early as possible so that the &drm_device that corresponds to the AUX
adapter
+ * may be mentioned in debugging output from the DRM DP helpers.
+ *
+ * For devices which use a separate platform device for their AUX adapters,
this
+ * may be called as early as required by the driver.
*/
void drm_dp_aux_init(struct drm_dp_aux *aux)
{
@@ -1751,15 +1758,26 @@ EXPORT_SYMBOL(drm_dp_aux_init);
* drm_dp_aux_register() - initialise and register aux channel
* @aux: DisplayPort AUX channel
*
- * Automatically calls drm_dp_aux_init() if this hasn't been done yet.
- * This should only be called when the underlying &struct drm_connector is
- * initialiazed already. Therefore the best place to call this is from
- * &drm_connector_funcs.late_register. Not that drivers which don't follow this
- * will Oops when CONFIG_DRM_DP_AUX_CHARDEV is enabled.
- *
- * Drivers which need to use the aux channel before that point (e.g. at driver
- * load time, before drm_dev_register() has been called) need to call
- * drm_dp_aux_init().
+ * Automatically calls drm_dp_aux_init() if this hasn't been done yet. This
+ * should only be called once the parent of @aux, &drm_dp_aux.dev, is
+ * initialized. For devices which are grandparents of their AUX channels,
+ * &drm_dp_aux.dev will typically be the &drm_connector &device which
+ * corresponds to @aux. For these devices, it's advised to call
+ * drm_dp_aux_register() in &drm_connector_funcs.late_register, and likewise to
+ * call drm_dp_aux_unregister() in &drm_connector_funcs.early_unregister.
+ * Functions which don't follow this will likely Oops when
+ * %CONFIG_DRM_DP_AUX_CHARDEV is enabled.
+ *
+ * For devices where the AUX channel is a device that exists independently of
+ * the &drm_device that uses it, such as SoCs and bridge devices, it is
+ * recommended to call drm_dp_aux_register() after a &drm_device has been
+ * assigned to &drm_dp_aux.drm_dev, and likewise to call
drm_dp_aux_unregister()
+ * once the &drm_device should no longer be associated with the AUX channel
+ * (e.g. on bridge detach).
+ *
+ * Drivers which need to use the aux channel before either of the two points
+ * mentioned above need to call drm_dp_aux_init() in order to use the AUX
+ * channel before registration.
*
* Returns 0 on success or a negative error code on failure.
*/
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/20] drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED()
Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want
to make sure that we can also add ratelimited versions of these macros in
order to retain some of the previous debugging output behavior we had.
However, as I was preparing to do this I noticed that the current
rate limited macros we have are kind of bogus. It looks like when I wrote
these, I didn't notice that we'd always be calling __ratelimit() even if
the debugging message we'd be printing would normally be filtered out due
to the relevant DRM debugging category being disabled.
So, let's fix this by making sure to check drm_debug_enabled() in our
ratelimited macros before calling __ratelimit(), and start using
drm_dev_printk() in order to print debugging messages since that will save
us from doing a redundant drm_debug_enabled() check. And while we're at it,
let's move the code for this into another macro that we can reuse for
defining new ratelimited DRM debug macros more easily.
v2:
* Make sure to use tabs where possible in __DRM_DEFINE_DBG_RATELIMITED()
Signed-off-by: Lyude Paul
Cc: Robert Foss
---
include/drm/drm_print.h | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index f32d179e139d..a3c58c941bdc 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -524,16 +524,20 @@ void __drm_err(const char *format, ...);
#define DRM_DEBUG_DP(fmt, ...) \
__drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
-
-#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...)\
-({ \
- static DEFINE_RATELIMIT_STATE(_rs, \
- DEFAULT_RATELIMIT_INTERVAL, \
- DEFAULT_RATELIMIT_BURST); \
- if (__ratelimit(&_rs)) \
- drm_dev_dbg(NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__); \
+#define __DRM_DEFINE_DBG_RATELIMITED(category, drm, fmt, ...)
\
+({
\
+ static DEFINE_RATELIMIT_STATE(rs_, DEFAULT_RATELIMIT_INTERVAL,
DEFAULT_RATELIMIT_BURST);\
+ const struct drm_device *drm_ = (drm);
\
+
\
+ if (drm_debug_enabled(DRM_UT_ ## category) && __ratelimit(&rs_))
\
+ drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ##
__VA_ARGS__); \
})
+#define drm_dbg_kms_ratelimited(drm, fmt, ...) \
+ __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__)
+
+#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) drm_dbg_kms_ratelimited(NULL, fmt,
## __VA_ARGS__)
+
/*
* struct drm_device based WARNs
*
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/20] drm/dp: Always print aux channel name in logs
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f0029b8cb558..54e19d7b9c51 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -139,8 +139,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct
drm_dp_aux *aux,
DP_TRAINING_AUX_RD_MASK;
if (rd_interval > 4)
- DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
- rd_interval);
+ DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
+ aux->name, rd_interval);
if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
rd_interval = 100;
@@ -155,8 +155,8 @@ static void __drm_dp_link_train_channel_eq_delay(const
struct drm_dp_aux *aux,
unsigned long rd_interval)
{
if (rd_interval > 4)
- DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
- rd_interval);
+ DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
+ aux->name, rd_interval);
if (rd_interval == 0)
rd_interval = 400;
@@ -2774,7 +2774,7 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux)
if (ret < 0)
return ret;
if (!(buf & DP_PCON_ENABLE_SOURCE_CTL_MODE)) {
- DRM_DEBUG_KMS("PCON in Autonomous mode, can't enable FRL\n");
+ DRM_DEBUG_KMS("%s: PCON in Autonomous mode, can't enable
FRL\n", aux->name);
return -EINVAL;
}
buf |= DP_PCON_ENABLE_HDMI_LINK;
@@ -2869,7 +2869,8 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct
drm_dp_aux *aux,
num_error = 0;
}
- DRM_ERROR("More than %d errors since the last read for lane
%d", num_error, i);
+ DRM_ERROR("%s: More than %d errors since the last read for lane
%d",
+ aux->name, num_error, i);
}
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/20] drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay()
So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c| 14 +-
.../gpu/drm/i915/display/intel_dp_link_training.c | 4 ++--
drivers/gpu/drm/msm/dp/dp_ctrl.c | 4 ++--
drivers/gpu/drm/msm/edp/edp_ctrl.c | 4 ++--
drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
include/drm/drm_dp_helper.h| 6 --
8 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 4468f9d6b4dd..59ce6f620fdc 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -676,7 +676,7 @@ amdgpu_atombios_dp_link_train_ce(struct
amdgpu_atombios_dp_link_train_info *dp_i
dp_info->tries = 0;
channel_eq = false;
while (1) {
- drm_dp_link_train_channel_eq_delay(dp_info->dpcd);
+ drm_dp_link_train_channel_eq_delay(dp_info->aux, dp_info->dpcd);
if (drm_dp_dpcd_read_link_status(dp_info->aux,
dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4462624daefc..f0029b8cb558 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -151,7 +151,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct
drm_dp_aux *aux,
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
-static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
+static void __drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+unsigned long rd_interval)
{
if (rd_interval > 4)
DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
@@ -165,9 +166,11 @@ static void __drm_dp_link_train_channel_eq_delay(unsigned
long rd_interval)
usleep_range(rd_interval, rd_interval * 2);
}
-void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+void drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
- __drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ __drm_dp_link_train_channel_eq_delay(aux,
+dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK);
}
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
@@ -183,13 +186,14 @@ static u8 dp_lttpr_phy_cap(const u8
phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
}
-void drm_dp_lttpr_link_train_channel_eq_delay(const u8
phy_cap[DP_LTTPR_PHY_CAP_SIZE])
+void drm_dp_lttpr_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+ const u8
phy_cap[DP_LTTPR_PHY_CAP_SIZE])
{
u8 interval = dp_lttpr_phy_cap(phy_cap,
DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1) &
DP_TRAINING_AUX_RD_MASK;
- __drm_dp_link_train_channel_eq_delay(interval);
+ __drm_dp_link_train_channel_eq_delay(aux, interval);
}
EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index f543b494f052..dd7423d3c562 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -665,11 +665,11 @@ intel_dp_link_training_channel_equalization_delay(struct
intel_dp *intel_dp,
enum drm_dp_phy dp_phy)
{
if (dp_phy == DP_PHY_DPRX) {
- drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
+ drm_dp_link_train_channel_eq_delay(&intel_dp->aux,
intel_dp->dpcd);
} else {
const u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
- drm_dp_lttpr_link_train_channel_eq_delay(phy_caps);
+ drm_dp_lttpr_link_train_channel_eq_delay(&intel_dp->aux,
phy_caps);
}
}
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 264a9eae87d3..2cebd17a7289 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1184,7 +1184,7 @@ static int dp_ctrl_link_lane_down_shift(struct
dp_ctrl_private *ctrl)
static void dp_ctrl_clear_training_pattern(struc
