Re: [RFC] amdgpu MST questions, and future plans
On Wed, 2022-01-19 at 17:56 -0500, Lyude Paul wrote: > Hi! I'm writing this email because I'm currently finishing up removing > pretty > much all of the non-atomic MST code in drm_dp_mst_topology_mgr.c as it's > really made it difficult to maintain MST over time. As well, once that's > complete it's likely I'm going to start on the (extremely overdue) task of > moving as much of amdgpu's MST code for DSC out of amdgpu and into the DRM > code where it's supposed to live. > > This brings me to two questions. The first major one being: is anyone > capable > of testing the MST support in radeon.ko to figure out whether it works or > not? > I've already talked with hwentlan and ag5df about this and they haven't been > able to find anyone to help with testing this. The reason I ask is because > radeon isn't an atomic driver, and is basically the only user of any of the > non-atomic parts of the MST helpers. If anyone want to prevent this from > breaking in the future, I would definitely recommend they step up to try and > help with testing it - otherwise I'm probably going to be pushing for us > just > to drop the code entirely. > > The second question is: is anyone willing to help me figure out how much of > the code in amdgpu related to DSC is definitely not amdgpu specific and can > be > moved out? I'm honestly having a lot of trouble wrapping my head around how > some of this works, and how much of this code is even needed. As well, with > the amount of issues I've already found in it (there's numerous spots where > we're storing MST state outside of atomic state for instance, lots of > duplicates of DP helper functions that should not be here, etc.) it's quite > likely I'm going to be rewriting rather large chunks of it. If anyone would mhhh - on second thought I think I'm starting to wrap my head around this and it's not actually too bad :), still could use some help with the radeon testing though! > like to volunteer please let me know, it'd be super appreciated and likely > will make reviewing the patches that will come out of this easier. -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
[Important!] 2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding instructions on the nomination process to membership in the near future. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is March 17th 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ You can find the current election schedule here: https://www.x.org/wiki/BoardOfDirectors/Elections/2022/ Lyude Paul, On behalf of the X.Org elections committee
Help needed for EVoC/GSoC/Outreachy
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 student. Sometimes this happens quickly, and sometimes it requires poking a lot of people - and occasionally, there might not always be a mentor to be found. * If we have a student, project, and mentor then the next step is having the student write up a proposal. Many students start out with over-simplified proposals, so a lot of this work is just gently nudging students and getting them to refine their work items into a week-by-week synopsis. There's usually a good bit of back and forth with the student's proposal, and occasionally the mentor may be involved with this step. * The admin then works with the student to come up with a timeline for their work, taking into account any vacation time the student may have, along with coordinating the frequency/type of meetings that will happen between the student and the mentor. If the mentor is unable to attend all of these meetings, it's usually up to the admin to check in with the student to see how they are progressing and potentially provide them tips if they get stuck. As for being a mentor, it's pretty much as simple as it sounds: you work with students who have projects to help familiarize them with the project at hand, help them out wherever needed, check in on their progress, and guide them along the way towards reaching their project goal along with grading their work. Please help spread the word on this, and contact anyone you know who might be involved with this! We'll be happy to provide more information on how you can get started. Remember, folks like myself wouldn't be in this community without projects like GSoC :). -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/dp_mst: Don't return error code when crtc is null
Reviewed-by: Lyude Paul I will go ahead and push this to drm-misc-fixes, thanks! On Fri, 2020-08-14 at 13:01 -0400, Bhawanpreet Lakha wrote: > [Why] > In certain cases the crtc can be NULL and returning -EINVAL causes > atomic check to fail when it shouln't. This leads to valid > configurations failing because atomic check fails. > > [How] > Don't early return if crtc is null > > Signed-off-by: Bhawanpreet Lakha > --- > drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > b/drivers/gpu/drm/drm_dp_mst_topology.c > index 70c4b7afed12..bc90a1485699 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -5037,8 +5037,8 @@ int drm_dp_mst_add_affected_dsc_crtcs(struct > drm_atomic_state *state, struct drm > > crtc = conn_state->crtc; > > - if (WARN_ON(!crtc)) > - return -EINVAL; > + if (!crtc) > + continue; > > if (!drm_dp_mst_dsc_aux_for_port(pos->port)) > continue; -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/dp_mst: Don't return error code when crtc is null
Oh-just noticed this is also missing a CC for sta...@vger.kernel.org. I'll add it before pushing but please make sure to follow the guidelines here when submitting fixes, since otherwise they might not get backported automatically to older kernels: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html (you can ignore the "It cannot be bigger than 100 lines, with context." part, as long as you're not trying to backport new functionality to stable and you're actually fixing something they're pretty leniant about that rule) On Mon, 2020-08-17 at 11:21 -0400, Lyude Paul wrote: > Reviewed-by: Lyude Paul > > I will go ahead and push this to drm-misc-fixes, thanks! > > On Fri, 2020-08-14 at 13:01 -0400, Bhawanpreet Lakha wrote: > > [Why] > > In certain cases the crtc can be NULL and returning -EINVAL causes > > atomic check to fail when it shouln't. This leads to valid > > configurations failing because atomic check fails. > > > > [How] > > Don't early return if crtc is null > > > > Signed-off-by: Bhawanpreet Lakha > > --- > > drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > > b/drivers/gpu/drm/drm_dp_mst_topology.c > > index 70c4b7afed12..bc90a1485699 100644 > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > > @@ -5037,8 +5037,8 @@ int drm_dp_mst_add_affected_dsc_crtcs(struct > > drm_atomic_state *state, struct drm > > > > crtc = conn_state->crtc; > > > > - if (WARN_ON(!crtc)) > > - return -EINVAL; > > + if (!crtc) > > + continue; > > > > if (!drm_dp_mst_dsc_aux_for_port(pos->port)) > > continue; -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 4/5] drm_dp_cec: add plumbing in preparation for MST support
Super minor nitpicks:
On Tue, 2020-09-01 at 16:22 +1000, Sam McNally wrote:
> From: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> [sa...@chromium.org:
> - rebased
> - removed polling-related changes
> - moved the calls to drm_dp_cec_(un)set_edid() into the next patch
> ]
> Signed-off-by: Sam McNally
> ---
>
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
> drivers/gpu/drm/drm_dp_cec.c | 22 ++-
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
> include/drm/drm_dp_helper.h | 6 +++--
> 5 files changed, 19 insertions(+), 15 deletions(-)
>
> 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 461fa4da0a34..6e7075893ec9 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
> @@ -419,7 +419,7 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
>
> drm_dp_aux_init(&aconnector->dm_dp_aux.aux);
> drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
> - &aconnector->base);
> + &aconnector->base, false);
>
> if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
> return;
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index 3ab2609f9ec7..04ab7b88055c 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Unfortunately it turns out that we have a chicken-and-egg situation
> @@ -338,8 +339,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
> if (aux->cec.adap) {
> if (aux->cec.adap->capabilities == cec_caps &&
> aux->cec.adap->available_log_addrs == num_las) {
> - /* Unchanged, so just set the phys addr */
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> goto unlock;
> }
May as well drop the braces here
> /*
> @@ -364,15 +363,16 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
> if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
> cec_delete_adapter(aux->cec.adap);
> aux->cec.adap = NULL;
> - } else {
> - /*
> - * Update the phys addr for the new CEC adapter. When called
> - * from drm_dp_cec_register_connector() edid == NULL, so in
> - * that case the phys addr is just invalidated.
> - */
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> }
> unlock:
> + /*
> + * Update the phys addr for the new CEC adapter. When called
> + * from drm_dp_cec_register_connector() edid == NULL, so in
> + * that case the phys addr is just invalidated.
> + */
> + if (aux->cec.adap && edid) {
> + cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> + }
And here
> mutex_unlock(&aux->cec.lock);
> }
> EXPORT_SYMBOL(drm_dp_cec_set_edid);
> @@ -418,6 +418,7 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
> * drm_dp_cec_register_connector() - register a new connector
> * @aux: DisplayPort AUX channel
> * @connector: drm connector
> + * @is_mst: set to true if this is an MST branch
> *
> * A new connector was registered with associated CEC adapter name and
> * CEC adapter parent device. After registering the name and parent
> @@ -425,12 +426,13 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
> * CEC and to register a CEC adapter if that is the case.
> */
> void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> -struct drm_connector *connector)
> + struct drm_connector *connector, bool is_mst)
> {
> WARN_ON(aux->cec.adap);
> if (WARN_ON(!aux->transfer))
> return;
> aux->cec.connector = connector;
> + aux->cec.is_mst = is_mst;
Also JFYI, you can also check aux->is_remote, but maybe you've got another
reason for copying this here
Either way:
Reviewed-by: Lyude Paul
...Also, maybe this is just a coincidence - but do I know your name from
somewhere? Perhaps an IRC community from long ago?
> INIT_DELAYED_WORK(&aux->cec.unregister_work,
&
[RESEND] Requests For Proposals for hosting XDC2021 are now open
(Including a bunch more emails in the To: that got missed the first time) Hello everyone! The X.org board is soliciting proposals to host XDC in 2021. Since XDC2020 is being held virtually this year, we've decided to host in either North America or Europe. However, the board is open to other locations, especially if there's an interesting co-location with another conference. Of course though, due to the ongoing COVID-19 pandemic it's not yet clear whether or not it will be possible to host XDC2021 in person. Because of this, we would like to make it clear that sponsors should prepare for both the possibility of an in person conference, and the possibility of a virtual conference. We will work with organizers on coming up with a deadline for deciding whether or not we'll be going virtual, likely sometime around July. If you're considering hosting XDC, we've assembled a wiki page with what's generally expected and needed: https://www.x.org/wiki/Events/RFP/ When submitting your proposal, please make sure to include at least the key information about the potential location in question, possible dates along with estimated costs. Proposals can be submitted to board at foundation.x.org until the deadline of November 1st. Additionally, an quirk early heads-up to the board if you're considering hosting would be appreciated, in case we need to adjust the schedule a bit. Also, earlier is better since there generally will be a bit of Q&A with organizers. And if you just have some questions about what organizing XDC entails, please feel free to chat with previous organizers, or someone from the board. -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 01/30] drm/dp: Rewrap kdocs for struct drm_dp_aux
Since we're about to be adding some more fields and update this
documentation, let's rewrap it to the new column limit of 100 beforehand.
No actual doc or functional changes are made here.
Signed-off-by: Lyude Paul
---
include/drm/drm_dp_helper.h | 42 -
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index edffd1dcca3e..2891a98eebc8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1839,34 +1839,28 @@ 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
- * 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.
+ * 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.
*
- * 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.
+ * 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.
*
- * 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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 02/30] 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
---
include/drm/drm_dp_helper.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 2891a98eebc8..b35a1c1339e8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1839,28 +1839,28 @@ 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 structure describing
the transaction is
+ * @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.
+ * 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
+ * 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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 05/30] 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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 04/30] drm/bridge/tc358767: Don't register DP AUX channel until bridge is attached
Since this is a bridge, we don't start out with a respective DRM device.
Likewise this means we don't have a connector, which also means that we
should be following drm_dp_aux_register()'s documentation advice and not
call drm_dp_aux_register() until we have a matching connector. Instead,
call drm_dp_aux_init() in tc_probe() and wait until tc_bridge_attach() to
register our AUX channel. We also add tc_bridge_detach() to handle
unregistering the AUX adapter once the bridge has been disconnected.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/tc358767.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 34a3e4e9f717..da89922721ed 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1414,11 +1414,15 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
return 0;
+ ret = drm_dp_aux_register(&tc->aux);
+ if (ret < 0)
+ return ret;
+
/* Create DP/eDP connector */
drm_connector_helper_add(&tc->connector, &tc_connector_helper_funcs);
ret = drm_connector_init(drm, &tc->connector, &tc_connector_funcs,
tc->bridge.type);
if (ret)
- return ret;
+ goto aux_unregister;
/* Don't poll if don't have HPD connected */
if (tc->hpd_pin >= 0) {
@@ -1438,10 +1442,19 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
drm_connector_attach_encoder(&tc->connector, tc->bridge.encoder);
return 0;
+aux_unregister:
+ drm_dp_aux_unregister(&tc->aux);
+ return ret;
+}
+
+static void tc_bridge_detach(struct drm_bridge *bridge)
+{
+ drm_dp_aux_unregister(&bridge_to_tc(bridge)->aux);
}
static const struct drm_bridge_funcs tc_bridge_funcs = {
.attach = tc_bridge_attach,
+ .detach = tc_bridge_detach,
.mode_valid = tc_mode_valid,
.mode_set = tc_bridge_mode_set,
.enable = tc_bridge_enable,
@@ -1680,9 +1693,7 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
tc->aux.name = "TC358767 AUX i2c adapter";
tc->aux.dev = tc->dev;
tc->aux.transfer = tc_aux_transfer;
- ret = drm_dp_aux_register(&tc->aux);
- if (ret)
- return ret;
+ drm_dp_aux_init(&tc->aux);
tc->bridge.funcs = &tc_bridge_funcs;
if (tc->hpd_pin >= 0)
@@ -1702,7 +1713,6 @@ static int tc_remove(struct i2c_client *client)
struct tc_data *tc = i2c_get_clientdata(client);
drm_bridge_remove(&tc->bridge);
- drm_dp_aux_unregister(&tc->aux);
return 0;
}
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 07/30] drm/bridge/analogix/anx78xx: Add missing drm_dp_aux_unregister() call
Surprisingly, this bridge actually registers it's AUX adapter at the
correct time already. Nice job! However, it does forget to actually
unregister the AUX adapter, so let's add a bridge function to handle that.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index 81debd02c169..ec4607dc01eb 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -942,6 +942,11 @@ static int anx78xx_bridge_attach(struct drm_bridge *bridge,
return 0;
}
+static void anx78xx_bridge_detach(struct drm_bridge *bridge)
+{
+ drm_dp_aux_unregister(&bridge_to_anx78xx(bridge)->aux);
+}
+
static enum drm_mode_status
anx78xx_bridge_mode_valid(struct drm_bridge *bridge,
const struct drm_display_info *info,
@@ -1013,6 +1018,7 @@ static void anx78xx_bridge_enable(struct drm_bridge
*bridge)
static const struct drm_bridge_funcs anx78xx_bridge_funcs = {
.attach = anx78xx_bridge_attach,
+ .detach = anx78xx_bridge_detach,
.mode_valid = anx78xx_bridge_mode_valid,
.disable = anx78xx_bridge_disable,
.mode_set = anx78xx_bridge_mode_set,
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 06/30] drm/bridge/ti-sn65dsi86: (Un)register aux device on bridge attach/detach
Since we're about to add a back-pointer to drm_dev in drm_dp_aux, let's
move the AUX adapter registration to the first point where we know which
DRM device we'll be working with - when the drm_bridge is attached.
Likewise, we unregister the AUX adapter on bridge detachment by adding a
ti_sn_bridge_detach() callback.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index f27306c51e4d..88df4dd0f39d 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -362,12 +362,18 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
return -EINVAL;
}
+ ret = drm_dp_aux_register(&pdata->aux);
+ if (ret < 0) {
+ drm_err(bridge->dev, "Failed to register DP AUX channel: %d\n",
ret);
+ return ret;
+ }
+
ret = drm_connector_init(bridge->dev, &pdata->connector,
&ti_sn_bridge_connector_funcs,
DRM_MODE_CONNECTOR_eDP);
if (ret) {
DRM_ERROR("Failed to initialize connector with drm\n");
- return ret;
+ goto err_conn_init;
}
drm_connector_helper_add(&pdata->connector,
@@ -424,9 +430,16 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
mipi_dsi_device_unregister(dsi);
err_dsi_host:
drm_connector_cleanup(&pdata->connector);
+err_conn_init:
+ drm_dp_aux_unregister(&pdata->aux);
return ret;
}
+static void ti_sn_bridge_detach(struct drm_bridge *bridge)
+{
+ drm_dp_aux_unregister(&bridge_to_ti_sn_bridge(bridge)->aux);
+}
+
static void ti_sn_bridge_disable(struct drm_bridge *bridge)
{
struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
@@ -863,6 +876,7 @@ static void ti_sn_bridge_post_disable(struct drm_bridge
*bridge)
static const struct drm_bridge_funcs ti_sn_bridge_funcs = {
.attach = ti_sn_bridge_attach,
+ .detach = ti_sn_bridge_detach,
.pre_enable = ti_sn_bridge_pre_enable,
.enable = ti_sn_bridge_enable,
.disable = ti_sn_bridge_disable,
@@ -1287,7 +1301,7 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
pdata->aux.name = "ti-sn65dsi86-aux";
pdata->aux.dev = pdata->dev;
pdata->aux.transfer = ti_sn_aux_transfer;
- drm_dp_aux_register(&pdata->aux);
+ drm_dp_aux_init(&pdata->aux);
pdata->bridge.funcs = &ti_sn_bridge_funcs;
pdata->bridge.of_node = client->dev.of_node;
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 03/30] 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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 08/30] drm/bridge/analogix/anx78xx: Setup encoder before registering connector
Since encoder mappings for connectors are exposed to userspace, we should
be attaching the encoder before exposing the connector to userspace. Just a
drive-by fix for an issue I noticed while fixing up usages of
drm_dp_aux_init()/drm_dp_aux_register() across the tree.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index ec4607dc01eb..338dd8531d4b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -924,12 +924,6 @@ static int anx78xx_bridge_attach(struct drm_bridge *bridge,
drm_connector_helper_add(&anx78xx->connector,
&anx78xx_connector_helper_funcs);
- err = drm_connector_register(&anx78xx->connector);
- if (err) {
- DRM_ERROR("Failed to register connector: %d\n", err);
- return err;
- }
-
anx78xx->connector.polled = DRM_CONNECTOR_POLL_HPD;
err = drm_connector_attach_encoder(&anx78xx->connector,
@@ -939,6 +933,12 @@ static int anx78xx_bridge_attach(struct drm_bridge *bridge,
return err;
}
+ err = drm_connector_register(&anx78xx->connector);
+ if (err) {
+ DRM_ERROR("Failed to register connector: %d\n", err);
+ return err;
+ }
+
return 0;
}
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 10/30] drm/bridge/analogix/anx6345: Add missing drm_dp_aux_unregister() call
Another driver I found that seems to forget to unregister it's DP AUX
device. Let's fix this by adding anx6345_bridge_detach().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index d9164fab044d..8e016ba7c54a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -574,6 +574,11 @@ static int anx6345_bridge_attach(struct drm_bridge *bridge,
return 0;
}
+static void anx6345_bridge_detach(struct drm_bridge *bridge)
+{
+ drm_dp_aux_unregister(&bridge_to_anx6345(bridge)->aux);
+}
+
static enum drm_mode_status
anx6345_bridge_mode_valid(struct drm_bridge *bridge,
const struct drm_display_info *info,
@@ -624,6 +629,7 @@ static void anx6345_bridge_enable(struct drm_bridge *bridge)
static const struct drm_bridge_funcs anx6345_bridge_funcs = {
.attach = anx6345_bridge_attach,
+ .detach = anx6345_bridge_detach,
.mode_valid = anx6345_bridge_mode_valid,
.disable = anx6345_bridge_disable,
.enable = anx6345_bridge_enable,
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 11/30] drm/bridge/analogix/anx6345: Don't link encoder until after connector registration
Another case of linking an encoder to a connector after the connector's
been registered. The proper place to do this is before connector
registration, so let's fix that.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index 8e016ba7c54a..6258f16da0e8 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -556,12 +556,6 @@ static int anx6345_bridge_attach(struct drm_bridge *bridge,
drm_connector_helper_add(&anx6345->connector,
&anx6345_connector_helper_funcs);
- err = drm_connector_register(&anx6345->connector);
- if (err) {
- DRM_ERROR("Failed to register connector: %d\n", err);
- return err;
- }
-
anx6345->connector.polled = DRM_CONNECTOR_POLL_HPD;
err = drm_connector_attach_encoder(&anx6345->connector,
@@ -571,6 +565,12 @@ static int anx6345_bridge_attach(struct drm_bridge *bridge,
return err;
}
+ err = drm_connector_register(&anx6345->connector);
+ if (err) {
+ DRM_ERROR("Failed to register connector: %d\n", err);
+ return err;
+ }
+
return 0;
}
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 14/30] 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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 12/30] drm/bridge/analogix/anx6345: Cleanup on errors in anx6345_bridge_attach()
Another drive-by fix I found when fixing DP AUX adapter across the kernel
tree - make sure we don't leak resources (and by proxy-AUX adapters) on
failures in anx6345_bridge_attach() by unrolling on errors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index 6258f16da0e8..aa6cda458eb9 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -550,7 +550,7 @@ static int anx6345_bridge_attach(struct drm_bridge *bridge,
DRM_MODE_CONNECTOR_eDP);
if (err) {
DRM_ERROR("Failed to initialize connector: %d\n", err);
- return err;
+ goto aux_unregister;
}
drm_connector_helper_add(&anx6345->connector,
@@ -562,16 +562,21 @@ static int anx6345_bridge_attach(struct drm_bridge
*bridge,
bridge->encoder);
if (err) {
DRM_ERROR("Failed to link up connector to encoder: %d\n", err);
- return err;
+ goto connector_cleanup;
}
err = drm_connector_register(&anx6345->connector);
if (err) {
DRM_ERROR("Failed to register connector: %d\n", err);
- return err;
+ goto connector_cleanup;
}
return 0;
+connector_cleanup:
+ drm_connector_cleanup(&anx6345->connector);
+aux_unregister:
+ drm_dp_aux_unregister(&anx6345->aux);
+ return err;
}
static void anx6345_bridge_detach(struct drm_bridge *bridge)
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 13/30] drm/bridge/analogix/dp_core: Unregister DP AUX channel on error in analogix_dp_probe()
Just another drive-by fix I noticed while going through the tree to cleanup DP aux adapter registration - make sure we unregister the DP AUX dev if analogix_dp_probe() fails. Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index aa1bb86293fd..f115233b1cb9 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -1782,6 +1782,7 @@ int analogix_dp_bind(struct analogix_dp_device *dp, struct drm_device *drm_dev) err_disable_pm_runtime: pm_runtime_disable(dp->dev); + drm_dp_aux_unregister(&dp->aux); return ret; } -- 2.29.2 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 16/30] drm/dp: Rewrap drm_dp_aux_register()/drm_dp_aux_init() kdocs
We're about to make a correction to these, so let's rewrap the kernel docs
for these while we're at it.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eedbb48815b7..17f5d1296ff1 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1728,10 +1728,9 @@ 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. You must still call drm_dp_aux_register()
once the connector has
+ * been registered to allow userspace access to the auxiliary DP channel.
*/
void drm_dp_aux_init(struct drm_dp_aux *aux)
{
@@ -1751,15 +1750,13 @@ 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
+ * 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().
+ * 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().
*
* Returns 0 on success or a negative error code on failure.
*/
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 17/30] 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 | 32
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 17f5d1296ff1..194e0c273809 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1729,8 +1729,15 @@ EXPORT_SYMBOL(drm_dp_remote_aux_init);
* @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.
+ * 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,12 +1758,21 @@ EXPORT_SYMBOL(drm_dp_aux_init);
* @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().
+ * 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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 00/30] 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(). Lyude Paul (30): drm/dp: Rewrap kdocs for struct drm_dp_aux drm/dp: Fixup kernel docs for struct drm_dp_aux drm/tegra: Don't register DP AUX channels before connectors drm/bridge/tc358767: Don't register DP AUX channel until bridge is attached drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace drm/bridge/ti-sn65dsi86: (Un)register aux device on bridge attach/detach drm/bridge/analogix/anx78xx: Add missing drm_dp_aux_unregister() call drm/bridge/analogix/anx78xx: Setup encoder before registering connector drm/bridge/analogix/anx78xx: Cleanup on error in anx78xx_bridge_attach() drm/bridge/analogix/anx6345: Add missing drm_dp_aux_unregister() call drm/bridge/analogix/anx6345: Don't link encoder until after connector registration drm/bridge/analogix/anx6345: Cleanup on errors in anx6345_bridge_attach() drm/bridge/analogix/dp_core: Unregister DP AUX channel on error in analogix_dp_probe() 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: Rewrap drm_dp_aux_register()/drm_dp_aux_init() kdocs 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: 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| 28 +- .../drm/bridge/analogix/analogix-anx78xx.c| 28 +- .../drm/bridge/analogix/analogix_dp_core.c| 2 + .../drm/bridge/cadence/cdns-mhdp8546-core.c | 12 +- drivers/gpu/drm/bridge/tc358767.c | 21 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 19 +- 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 | 175 drivers/gpu/drm/drm_dp_mst_topology.c | 377 +- 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 | 59 +-- include/drm/drm_dp_mst_helper.h | 3 +- include/drm/drm_print.h | 20 +- 29 files changed, 537 ins
[PATCH 19/30] 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
---
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 194e0c273809..ce08eb3bface 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 892d7db7d94f..222073d46bdb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -441,7 +441,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 36b39c381b3f..2501a6b326a3 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_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/xlnx
[PATCH 15/30] 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 41b09ab22233..163641b44339 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
@@ -431,6 +431,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 18/30] 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.
Signed-off-by: Lyude Paul
---
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..3a0c3fe4d292 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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 20/30] 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
---
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 ce08eb3bface..a9316c1ecb52 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 222073d46bdb..fe8b5a5d9d1a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -593,11 +593,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 2501a6b326a3..33df288dd4eb 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(struct dp_ctrl_private *ctrl)
{
[PATCH 21/30] 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 a9316c1ecb52..b5e2671baf22 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;
@@ -2769,7 +2769,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;
@@ -2864,7 +2864,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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 23/30] 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 52d99fec2435..b2442148b7f1 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1270,8 +1270,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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 22/30] 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 7f384f259fc8..52d99fec2435 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2606,7 +2606,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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 09/30] drm/bridge/analogix/anx78xx: Cleanup on error in anx78xx_bridge_attach()
Just another issue I noticed while correcting usages of
drm_dp_aux_init()/drm_dp_aux_register() around the tree. If any of the
steps in anx78xx_bridge_attach() fail, we end up leaking resources. So,
let's fix that (and fix leaking a DP AUX adapter in the process) by
unrolling on errors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index 338dd8531d4b..f20558618220 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -918,7 +918,7 @@ static int anx78xx_bridge_attach(struct drm_bridge *bridge,
DRM_MODE_CONNECTOR_DisplayPort);
if (err) {
DRM_ERROR("Failed to initialize connector: %d\n", err);
- return err;
+ goto aux_unregister;
}
drm_connector_helper_add(&anx78xx->connector,
@@ -930,16 +930,21 @@ static int anx78xx_bridge_attach(struct drm_bridge
*bridge,
bridge->encoder);
if (err) {
DRM_ERROR("Failed to link up connector to encoder: %d\n", err);
- return err;
+ goto connector_cleanup;
}
err = drm_connector_register(&anx78xx->connector);
if (err) {
DRM_ERROR("Failed to register connector: %d\n", err);
- return err;
+ goto connector_cleanup;
}
return 0;
+connector_cleanup:
+ drm_connector_cleanup(&anx78xx->connector);
+aux_unregister:
+ drm_dp_aux_unregister(&anx78xx->aux);
+ return err;
}
static void anx78xx_bridge_detach(struct drm_bridge *bridge)
--
2.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 25/30] 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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 24/30] 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 b2442148b7f1..ef875fc48646 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2638,7 +2638,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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 26/30] 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 27/30] 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 cf4f2f85711e..fb66df39e0bb 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3631,6 +3631,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
*
@@ -3639,7 +3640,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",
@@ -3704,7 +3706,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 8e316146b6d1..60ca0fa32d15 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.29.2
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 29/30] 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 30/30] 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.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 369 +-
1 file changed, 187 insertions(+), 182 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index fb66df39e0bb..f66232954689 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,
+struct
drm_dp_sideband_msg_rx *raw,
+struct
[PATCH 28/30] 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.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 122
1 file changed, 60 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index b5e2671baf22..0a787ddf39fd 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,12 @@ 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 +288,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 +525,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 DUT does not support
TEST_EDID_READ\n",
- aux->
Re: [PATCH 01/30] drm/dp: Rewrap kdocs for struct drm_dp_aux
On Fri, 2021-02-19 at 15:42 -0800, Randy Dunlap wrote:
> On 2/19/21 1:52 PM, Lyude Paul wrote:
> > Since we're about to be adding some more fields and update this
> > documentation, let's rewrap it to the new column limit of 100 beforehand.
> > No actual doc or functional changes are made here.
> >
>
> The preferred column limit is still 80.
> For some (exceptional) cases, going up to 100 is OK,
> but I don't see any reason here to go beyond 80.
Found some posts online that discussed this in detail:
https://linux.slashdot.org/story/20/05/31/211211/linus-torvalds-argues-against-80-column-line-length-coding-style-as-linux-kernel-deprecates-it
so I guess I'm fine with rewrapping these to 80 cols (although honestly, it'd be
really nice to just have a single col limit to make things easier on text
editors :) in the next respin.
> Signed-off-by: Lyude Paul
> ---
> include/drm/drm_dp_helper.h | 42 -
> 1 file changed, 18 insertions(+), 24 deletions(-)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index edffd1dcca3e..2891a98eebc8 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1839,34 +1839,28 @@ 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
> - * 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.
> + * 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.
> *
> - * 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.
> + * 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.
> *
> - * 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 th
Re: [PATCH 15/30] drm/dp: Add backpointer to drm_device in drm_dp_aux
On Sun, 2021-02-21 at 20:21 +0200, Laurent Pinchart wrote:
> Hi Lyude,
>
> Thank you for the patch.
>
> On Fri, Feb 19, 2021 at 04:53:11PM -0500, Lyude Paul wrote:
> > 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.
>
> Isn't it better to use the existing dev field ? If you have multiple DP
> outputs for one DRM device, using the DRM device name in debug messages
> won't tell which output the message corresponds to.
Well the thing is dev won't tell you that either - on most SoCs the DP AUX
adapter is it's own platform device that isn't a child of the DRM device. Also,
that's what the ability to name AUX channels is supposed to be there for.
> > 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 41b09ab22233..163641b44339 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
> > @@ -431,6 +431,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/dr
Re: [PATCH] drm/amdkfd: Fix UBSAN shift-out-of-bounds warning
Tested-by: Lyude Paul
That just leaves the KASAN error from read_indirect_azalia_reg, thanks for the
fix!
On Thu, 2021-03-04 at 15:08 -0500, Anson Jacob wrote:
> If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up
> doing a shift operation where the number of bits shifted equals
> number of bits in the operand. This behaviour is undefined.
>
> Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the
> count is >= number of bits in the operand.
>
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472
> Reported-by: Lyude Paul
> Signed-off-by: Anson Jacob
> Reviewed-by: Alex Deucher
> Reviewed-by: Felix Kuehling
> ---
> .../drm/amd/amdkfd/kfd_device_queue_manager.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index c37e9c4b1fb4..e7a3c496237f 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -1128,6 +1128,9 @@ static int set_sched_resources(struct
> device_queue_manager *dqm)
>
> static int initialize_cpsch(struct device_queue_manager *dqm)
> {
> + uint64_t num_sdma_queues;
> + uint64_t num_xgmi_sdma_queues;
> +
> pr_debug("num of pipes: %d\n", get_pipes_per_mec(dqm));
>
> mutex_init(&dqm->lock_hidden);
> @@ -1136,8 +1139,18 @@ static int initialize_cpsch(struct device_queue_manager
> *dqm)
> dqm->active_cp_queue_count = 0;
> dqm->gws_queue_count = 0;
> dqm->active_runlist = false;
> - dqm->sdma_bitmap = ~0ULL >> (64 - get_num_sdma_queues(dqm));
> - dqm->xgmi_sdma_bitmap = ~0ULL >> (64 - get_num_xgmi_sdma_queues(dqm));
> +
> + num_sdma_queues = get_num_sdma_queues(dqm);
> + if (num_sdma_queues >= BITS_PER_TYPE(dqm->sdma_bitmap))
> + dqm->sdma_bitmap = ULLONG_MAX;
> + else
> + dqm->sdma_bitmap = (BIT_ULL(num_sdma_queues) - 1);
> +
> + num_xgmi_sdma_queues = get_num_xgmi_sdma_queues(dqm);
> + if (num_xgmi_sdma_queues >= BITS_PER_TYPE(dqm->xgmi_sdma_bitmap))
> + dqm->xgmi_sdma_bitmap = ULLONG_MAX;
> + else
> + dqm->xgmi_sdma_bitmap = (BIT_ULL(num_xgmi_sdma_queues) - 1);
>
> INIT_WORK(&dqm->hw_exception_work, kfd_process_hw_exception);
>
--
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!
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdkfd: Fix UBSAN shift-out-of-bounds warning
On Sat, 2021-03-06 at 03:55 +, Jacob, Anson wrote:
> [AMD Public Use]
>
> Thanks Lyude for testing the patch.
>
> Are you referring to this issue [1] ?
>
> Is it reproducible after applying this patch as well ?
Yes I am - and yeah, if you're talking about the patch you originally asked me
to try then yes- I'm still able to reproduce it with that patch applied
>
> [1] https://gitlab.freedesktop.org/drm/amd/-/issues/1473
>
> -- Anson
> From: Lyude Paul
> Sent: Friday, March 5, 2021 6:08 PM
> To: Jacob, Anson ; amd-gfx@lists.freedesktop.org g...@lists.freedesktop.org>
> Cc: Deucher, Alexander ; Kuehling, Felix
>
> Subject: Re: [PATCH] drm/amdkfd: Fix UBSAN shift-out-of-bounds warning
> Tested-by: Lyude Paul
>
> That just leaves the KASAN error from read_indirect_azalia_reg, thanks for the
> fix!
>
> On Thu, 2021-03-04 at 15:08 -0500, Anson Jacob wrote:
> > If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up
> > doing a shift operation where the number of bits shifted equals
> > number of bits in the operand. This behaviour is undefined.
> >
> > Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the
> > count is >= number of bits in the operand.
> >
> > Bug:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F1472&data=04%7C01%7Canson.jacob%40amd.com%7Ce9ea7130bcd945a194aa08d8e02ba9f8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637505826204096667%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GEyObPt%2FnEeU9Y7K2I30RS1TBMGbbUneQ6hWkR7pJLM%3D&reserved=0
> > Reported-by: Lyude Paul
> > Signed-off-by: Anson Jacob
> > Reviewed-by: Alex Deucher
> > Reviewed-by: Felix Kuehling
> > ---
> > .../drm/amd/amdkfd/kfd_device_queue_manager.c | 17 +++--
> > 1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> > b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> > index c37e9c4b1fb4..e7a3c496237f 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> > @@ -1128,6 +1128,9 @@ static int set_sched_resources(struct
> > device_queue_manager *dqm)
> >
> > static int initialize_cpsch(struct device_queue_manager *dqm)
> > {
> > + uint64_t num_sdma_queues;
> > + uint64_t num_xgmi_sdma_queues;
> > +
> > pr_debug("num of pipes: %d\n", get_pipes_per_mec(dqm));
> >
> > mutex_init(&dqm->lock_hidden);
> > @@ -1136,8 +1139,18 @@ static int initialize_cpsch(struct
> device_queue_manager
> > *dqm)
> > dqm->active_cp_queue_count = 0;
> > dqm->gws_queue_count = 0;
> > dqm->active_runlist = false;
> > - dqm->sdma_bitmap = ~0ULL >> (64 - get_num_sdma_queues(dqm));
> > - dqm->xgmi_sdma_bitmap = ~0ULL >> (64 -
> get_num_xgmi_sdma_queues(dqm));
> > +
> > + num_sdma_queues = get_num_sdma_queues(dqm);
> > + if (num_sdma_queues >= BITS_PER_TYPE(dqm->sdma_bitmap))
> > + dqm->sdma_bitmap = ULLONG_MAX;
> > + else
> > + dqm->sdma_bitmap = (BIT_ULL(num_sdma_queues) - 1);
> > +
> > + num_xgmi_sdma_queues = get_num_xgmi_sdma_queues(dqm);
> > + if (num_xgmi_sdma_queues >= BITS_PER_TYPE(dqm->xgmi_sdma_bitmap))
> > + dqm->xgmi_sdma_bitmap = ULLONG_MAX;
> > + else
> > + dqm->xgmi_sdma_bitmap = (BIT_ULL(num_xgmi_sdma_queues) - 1);
> >
> > INIT_WORK(&dqm->hw_exception_work, kfd_process_hw_exception);
> >
>
--
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!
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
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!
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload allocation/removement
On Thu, 2023-08-24 at 04:12 +, Lin, Wayne wrote: > [Public] > > Hi Lyude, > > I'm afraid that I don't have the permissions to push and would like to have > your help. Thanks! Whoops, sorry I only just noticed this message. I set a reminder on my phone to bug me to push it tomorrow :), sorry about the delay > > > -Original Message- > > From: Lyude Paul > > Sent: Thursday, August 24, 2023 5:00 AM > > To: Lin, Wayne ; dri-de...@lists.freedesktop.org; > > amd-gfx@lists.freedesktop.org > > Cc: jani.nik...@intel.com; ville.syrj...@linux.intel.com; > > imre.d...@intel.com; > > Wentland, Harry ; Zuo, Jerry > > > > Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload > > allocation/removement > > > > Sure - you're also welcome to push the first two patches after fixing the > > indentation if you'd like > > > > On Wed, 2023-08-23 at 03:19 +, Lin, Wayne wrote: > > > [Public] > > > > > > Thanks, Lyude! > > > Should I push another version to fix the indention? > > > > > > > -Original Message- > > > > From: Lyude Paul > > > > Sent: Friday, August 18, 2023 6:17 AM > > > > To: Lin, Wayne ; dri-de...@lists.freedesktop.org; > > > > amd-gfx@lists.freedesktop.org > > > > Cc: jani.nik...@intel.com; ville.syrj...@linux.intel.com; > > > > imre.d...@intel.com; Wentland, Harry ; Zuo, > > > > Jerry > > > > Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload > > > > allocation/removement > > > > > > > > Two small comments: > > > > > > > > On Mon, 2023-08-07 at 10:56 +0800, Wayne Lin wrote: > > > > > [Why] > > > > > Today, the allocation/deallocation steps and status is a bit unclear. > > > > > > > > > > For instance, payload->vc_start_slot = -1 stands for "the failure > > > > > of updating DPCD payload ID table" and can also represent as > > > > > "payload is not allocated yet". These two cases should be handled > > > > > differently and hence better to distinguish them for better > > > > > understanding. > > > > > > > > > > [How] > > > > > Define enumeration - ALLOCATION_LOCAL, ALLOCATION_DFP and > > > > > ALLOCATION_REMOTE to distinguish different allocation status. > > > > > Adjust the code to handle different status accordingly for better > > > > > understanding the sequence of payload allocation and payload > > > > removement. > > > > > > > > > > For payload creation, the procedure should look like this: > > > > > DRM part 1: > > > > > * step 1 - update sw mst mgr variables to add a new payload > > > > > * step 2 - add payload at immediate DFP DPCD payload table > > > > > > > > > > Driver: > > > > > * Add new payload in HW and sync up with DFP by sending ACT > > > > > > > > > > DRM Part 2: > > > > > * Send ALLOCATE_PAYLOAD sideband message to allocate bandwidth > > > > > along > > > > the > > > > > virtual channel. > > > > > > > > > > And as for payload removement, the procedure should look like this: > > > > > DRM part 1: > > > > > * step 1 - Send ALLOCATE_PAYLOAD sideband message to release > > bandwidth > > > > >along the virtual channel > > > > > * step 2 - Clear payload allocation at immediate DFP DPCD payload > > > > > table > > > > > > > > > > Driver: > > > > > * Remove the payload in HW and sync up with DFP by sending ACT > > > > > > > > > > DRM part 2: > > > > > * update sw mst mgr variables to remove the payload > > > > > > > > > > Note that it's fine to fail when communicate with the branch > > > > > device connected at immediate downstrean-facing port, but updating > > > > > variables of SW mst mgr and HW configuration should be conducted > > > > > anyway. That's because it's under commit_tail and we need to > > > > > complete the HW > > > > programming. > > > > > > > > > > Changes since v1: > > > > > * Remove the set but not use variable 'old_payload' in function > &
Re: [PATCH 5/9] drm/nouveau/pm: Annotate struct nvkm_perfdom with __counted_by
Reviewed-by: Lyude Paul
Thanks!
On Fri, 2023-09-22 at 10:32 -0700, Kees Cook wrote:
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
> (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> functions).
>
> As found with Coccinelle[1], add __counted_by for struct nvkm_perfdom.
>
> [1]
> https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
>
> Cc: Ben Skeggs
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Kees Cook
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/pm/priv.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/pm/priv.h
> b/drivers/gpu/drm/nouveau/nvkm/engine/pm/priv.h
> index 6ae25d3e7f45..c011227f7052 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/pm/priv.h
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/pm/priv.h
> @@ -82,7 +82,7 @@ struct nvkm_perfdom {
> u8 mode;
> u32 clk;
> u16 signal_nr;
> - struct nvkm_perfsig signal[];
> + struct nvkm_perfsig signal[] __counted_by(signal_nr);
> };
>
> struct nvkm_funcdom {
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH] drm/dp: Avoid Reading DPCD_REV Before Native Aux Read
Reviewed-by: Lyude Paul
On Wed, 2022-08-31 at 18:13 -0400, Fangzhi Zuo wrote:
> The attempt to read DPCD_REV before any native aux read breaks
> majority of DP2 compliance.
>
> The spec. requires DP_SINK_STATUS to be polled for the reset status
> DP_INTRA_HOP_AUX_REPLY_INDICATION during the clear training stage.
>
> Polling DP_SINK_STATUS each time gets DPCD_REV read first
> that makes non link training regsiter DPCD_REV get read
> during UHBR link training. It violates DP2 compliance.
>
> Cc: Ville Syrjala
> Cc: Lyude Paul
> Signed-off-by: Fangzhi Zuo
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index e7c22c2ca90c..c7aa5bafa667 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -571,24 +571,6 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux,
> unsigned int offset,
> {
> int ret;
>
> - /*
> - * HP ZR24w corrupts the first DPCD access after entering power save
> - * mode. Eg. on a read, the entire buffer will be filled with the same
> - * byte. Do a throw away read to avoid corrupting anything we care
> - * about. Afterwards things will work correctly until the monitor
> - * gets woken up and subsequently re-enters power save mode.
> - *
> - * The user pressing any button on the monitor is enough to wake it
> - * up, so there is no particularly good place to do the workaround.
> - * We just have to do it before any DPCD access and hope that the
> - * monitor doesn't power down exactly after the throw away read.
> - */
> - if (!aux->is_remote) {
> - ret = drm_dp_dpcd_probe(aux, DP_DPCD_REV);
> - if (ret < 0)
> - return ret;
> - }
> -
> if (aux->is_remote)
> ret = drm_dp_mst_dpcd_read(aux, offset, buffer, size);
> else
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH 5/7] nouveau/dmem: Refactor nouveau_dmem_fault_copy_one()
On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
> nouveau_dmem_fault_copy_one() is used during handling of CPU faults via
> the migrate_to_ram() callback and is used to copy data from GPU to CPU
> memory. It is currently specific to fault handling, however a future
> patch implementing eviction of data during teardown needs similar
> functionality.
>
> Refactor out the core functionality so that it is not specific to fault
> handling.
>
> Signed-off-by: Alistair Popple
> ---
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 59 +--
> 1 file changed, 29 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> index f9234ed..66ebbd4 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> @@ -139,44 +139,25 @@ static void nouveau_dmem_fence_done(struct
> nouveau_fence **fence)
> }
> }
>
> -static vm_fault_t nouveau_dmem_fault_copy_one(struct nouveau_drm *drm,
> - struct vm_fault *vmf, struct migrate_vma *args,
> - dma_addr_t *dma_addr)
> +static int nouveau_dmem_copy_one(struct nouveau_drm *drm, struct page *spage,
> + struct page *dpage, dma_addr_t *dma_addr)
> {
> struct device *dev = drm->dev->dev;
> - struct page *dpage, *spage;
> - struct nouveau_svmm *svmm;
> -
> - spage = migrate_pfn_to_page(args->src[0]);
> - if (!spage || !(args->src[0] & MIGRATE_PFN_MIGRATE))
> - return 0;
>
> - dpage = alloc_page_vma(GFP_HIGHUSER, vmf->vma, vmf->address);
> - if (!dpage)
> - return VM_FAULT_SIGBUS;
> lock_page(dpage);
>
> *dma_addr = dma_map_page(dev, dpage, 0, PAGE_SIZE, DMA_BIDIRECTIONAL);
> if (dma_mapping_error(dev, *dma_addr))
> - goto error_free_page;
> + return -EIO;
>
> - svmm = spage->zone_device_data;
> - mutex_lock(&svmm->mutex);
> - nouveau_svmm_invalidate(svmm, args->start, args->end);
> if (drm->dmem->migrate.copy_func(drm, 1, NOUVEAU_APER_HOST, *dma_addr,
> - NOUVEAU_APER_VRAM, nouveau_dmem_page_addr(spage)))
> - goto error_dma_unmap;
> - mutex_unlock(&svmm->mutex);
> + NOUVEAU_APER_VRAM,
> + nouveau_dmem_page_addr(spage))) {
> + dma_unmap_page(dev, *dma_addr, PAGE_SIZE, DMA_BIDIRECTIONAL);
> + return -EIO;
> + }
Feel free to just align this with the starting (, as long as it doesn't go
above 100 characters it doesn't really matter imho and would look nicer that
way.
Otherwise:
Reviewed-by: Lyude Paul
Will look at the other patch in a moment
>
> - args->dst[0] = migrate_pfn(page_to_pfn(dpage));
> return 0;
> -
> -error_dma_unmap:
> - mutex_unlock(&svmm->mutex);
> - dma_unmap_page(dev, *dma_addr, PAGE_SIZE, DMA_BIDIRECTIONAL);
> -error_free_page:
> - __free_page(dpage);
> - return VM_FAULT_SIGBUS;
> }
>
> static vm_fault_t nouveau_dmem_migrate_to_ram(struct vm_fault *vmf)
> @@ -184,9 +165,11 @@ static vm_fault_t nouveau_dmem_migrate_to_ram(struct
> vm_fault *vmf)
> struct nouveau_drm *drm = page_to_drm(vmf->page);
> struct nouveau_dmem *dmem = drm->dmem;
> struct nouveau_fence *fence;
> + struct nouveau_svmm *svmm;
> + struct page *spage, *dpage;
> unsigned long src = 0, dst = 0;
> dma_addr_t dma_addr = 0;
> - vm_fault_t ret;
> + vm_fault_t ret = 0;
> struct migrate_vma args = {
> .vma= vmf->vma,
> .start = vmf->address,
> @@ -207,9 +190,25 @@ static vm_fault_t nouveau_dmem_migrate_to_ram(struct
> vm_fault *vmf)
> if (!args.cpages)
> return 0;
>
> - ret = nouveau_dmem_fault_copy_one(drm, vmf, &args, &dma_addr);
> - if (ret || dst == 0)
> + spage = migrate_pfn_to_page(src);
> + if (!spage || !(src & MIGRATE_PFN_MIGRATE))
> + goto done;
> +
> + dpage = alloc_page_vma(GFP_HIGHUSER, vmf->vma, vmf->address);
> + if (!dpage)
> + goto done;
> +
> + dst = migrate_pfn(page_to_pfn(dpage));
> +
> + svmm = spage->zone_device_data;
> + mutex_lock(&svmm->mutex);
> + nouveau_svmm_invalidate(svmm, args.start, args.end);
> + ret = nouveau_dmem_copy_one(drm, spage, dpage, &dma_addr);
> + mutex_unlock(&svmm->mutex);
> + if (ret) {
> + ret = VM_FAULT_SIGBUS;
> goto done;
> + }
>
> nouveau_fence_new(dmem->migrate.chan, false, &fence);
> migrate_vma_pages(&args);
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH 6/7] nouveau/dmem: Evict device private memory during release
On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
> When the module is unloaded or a GPU is unbound from the module it is
> possible for device private pages to be left mapped in currently running
> processes. This leads to a kernel crash when the pages are either freed
> or accessed from the CPU because the GPU and associated data structures
> and callbacks have all been freed.
>
> Fix this by migrating any mappings back to normal CPU memory prior to
> freeing the GPU memory chunks and associated device private pages.
>
> Signed-off-by: Alistair Popple
>
> ---
>
> I assume the AMD driver might have a similar issue. However I can't see
> where device private (or coherent) pages actually get unmapped/freed
> during teardown as I couldn't find any relevant calls to
> devm_memunmap(), memunmap(), devm_release_mem_region() or
> release_mem_region(). So it appears that ZONE_DEVICE pages are not being
> properly freed during module unload, unless I'm missing something?
I've got no idea, will poke Ben to see if they know the answer to this
> ---
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 48 +++-
> 1 file changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> index 66ebbd4..3b247b8 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> @@ -369,6 +369,52 @@ nouveau_dmem_suspend(struct nouveau_drm *drm)
> mutex_unlock(&drm->dmem->mutex);
> }
>
> +/*
> + * Evict all pages mapping a chunk.
> + */
> +void
> +nouveau_dmem_evict_chunk(struct nouveau_dmem_chunk *chunk)
> +{
> + unsigned long i, npages = range_len(&chunk->pagemap.range) >>
> PAGE_SHIFT;
> + unsigned long *src_pfns, *dst_pfns;
> + dma_addr_t *dma_addrs;
> + struct nouveau_fence *fence;
> +
> + src_pfns = kcalloc(npages, sizeof(*src_pfns), GFP_KERNEL);
> + dst_pfns = kcalloc(npages, sizeof(*dst_pfns), GFP_KERNEL);
> + dma_addrs = kcalloc(npages, sizeof(*dma_addrs), GFP_KERNEL);
> +
> + migrate_device_range(src_pfns, chunk->pagemap.range.start >> PAGE_SHIFT,
> + npages);
> +
> + for (i = 0; i < npages; i++) {
> + if (src_pfns[i] & MIGRATE_PFN_MIGRATE) {
> + struct page *dpage;
> +
> + /*
> + * _GFP_NOFAIL because the GPU is going away and there
> + * is nothing sensible we can do if we can't copy the
> + * data back.
> + */
You'll have to excuse me for a moment since this area of nouveau isn't one of
my strongpoints, but are we sure about this? IIRC __GFP_NOFAIL means infinite
retry, in the case of a GPU hotplug event I would assume we would rather just
stop trying to migrate things to the GPU and just drop the data instead of
hanging on infinite retries.
> + dpage = alloc_page(GFP_HIGHUSER | __GFP_NOFAIL);
> + dst_pfns[i] = migrate_pfn(page_to_pfn(dpage));
> + nouveau_dmem_copy_one(chunk->drm,
> + migrate_pfn_to_page(src_pfns[i]), dpage,
> + &dma_addrs[i]);
> + }
> + }
> +
> + nouveau_fence_new(chunk->drm->dmem->migrate.chan, false, &fence);
> + migrate_device_pages(src_pfns, dst_pfns, npages);
> + nouveau_dmem_fence_done(&fence);
> + migrate_device_finalize(src_pfns, dst_pfns, npages);
> + kfree(src_pfns);
> + kfree(dst_pfns);
> + for (i = 0; i < npages; i++)
> + dma_unmap_page(chunk->drm->dev->dev, dma_addrs[i], PAGE_SIZE,
> DMA_BIDIRECTIONAL);
> + kfree(dma_addrs);
> +}
> +
> void
> nouveau_dmem_fini(struct nouveau_drm *drm)
> {
> @@ -380,8 +426,10 @@ nouveau_dmem_fini(struct nouveau_drm *drm)
> mutex_lock(&drm->dmem->mutex);
>
> list_for_each_entry_safe(chunk, tmp, &drm->dmem->chunks, list) {
> + nouveau_dmem_evict_chunk(chunk);
> nouveau_bo_unpin(chunk->bo);
> nouveau_bo_ref(NULL, &chunk->bo);
> + WARN_ON(chunk->callocated);
> list_del(&chunk->list);
> memunmap_pages(&chunk->pagemap);
> release_mem_region(chunk->pagemap.range.start,
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH 6/7] nouveau/dmem: Evict device private memory during release
On Tue, 2022-09-27 at 11:39 +1000, Alistair Popple wrote: > Felix Kuehling writes: > > > On 2022-09-26 17:35, Lyude Paul wrote: > > > On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote: > > > > When the module is unloaded or a GPU is unbound from the module it is > > > > possible for device private pages to be left mapped in currently running > > > > processes. This leads to a kernel crash when the pages are either freed > > > > or accessed from the CPU because the GPU and associated data structures > > > > and callbacks have all been freed. > > > > > > > > Fix this by migrating any mappings back to normal CPU memory prior to > > > > freeing the GPU memory chunks and associated device private pages. > > > > > > > > Signed-off-by: Alistair Popple > > > > > > > > --- > > > > > > > > I assume the AMD driver might have a similar issue. However I can't see > > > > where device private (or coherent) pages actually get unmapped/freed > > > > during teardown as I couldn't find any relevant calls to > > > > devm_memunmap(), memunmap(), devm_release_mem_region() or > > > > release_mem_region(). So it appears that ZONE_DEVICE pages are not being > > > > properly freed during module unload, unless I'm missing something? > > > I've got no idea, will poke Ben to see if they know the answer to this > > > > I guess we're relying on devm to release the region. Isn't the whole point > > of > > using devm_request_free_mem_region that we don't have to remember to > > explicitly > > release it when the device gets destroyed? I believe we had an explicit free > > call at some point by mistake, and that caused a double-free during module > > unload. See this commit for reference: > > Argh, thanks for that pointer. I was not so familiar with > devm_request_free_mem_region()/devm_memremap_pages() as currently > Nouveau explicitly manages that itself. Mhm, TBH I feel like this was going to happen eventually anyway but there's another reason for nouveau to start using the managed versions of these functions at some point > > > commit 22f4f4faf337d5fb2d2750aff13215726814273e > > Author: Philip Yang > > Date: Mon Sep 20 17:25:52 2021 -0400 > > > > drm/amdkfd: fix svm_migrate_fini warning > > Device manager releases device-specific resources when a driver > > disconnects from a device, devm_memunmap_pages and > > devm_release_mem_region calls in svm_migrate_fini are redundant. > > It causes below warning trace after patch "drm/amdgpu: Split > > amdgpu_device_fini into early and late", so remove function > > svm_migrate_fini. > > BUG: https://gitlab.freedesktop.org/drm/amd/-/issues/1718 > > WARNING: CPU: 1 PID: 3646 at drivers/base/devres.c:795 > > devm_release_action+0x51/0x60 > > Call Trace: > > ? memunmap_pages+0x360/0x360 > > svm_migrate_fini+0x2d/0x60 [amdgpu] > > kgd2kfd_device_exit+0x23/0xa0 [amdgpu] > > amdgpu_amdkfd_device_fini_sw+0x1d/0x30 [amdgpu] > > amdgpu_device_fini_sw+0x45/0x290 [amdgpu] > > amdgpu_driver_release_kms+0x12/0x30 [amdgpu] > > drm_dev_release+0x20/0x40 [drm] > > release_nodes+0x196/0x1e0 > > device_release_driver_internal+0x104/0x1d0 > > driver_detach+0x47/0x90 > > bus_remove_driver+0x7a/0xd0 > > pci_unregister_driver+0x3d/0x90 > > amdgpu_exit+0x11/0x20 [amdgpu] > > Signed-off-by: Philip Yang > > Reviewed-by: Felix Kuehling > > Signed-off-by: Alex Deucher > > > > Furthermore, I guess we are assuming that nobody is using the GPU when the > > module is unloaded. As long as any processes have /dev/kfd open, you won't > > be > > able to unload the module (except by force-unload). I suppose with > > ZONE_DEVICE > > memory, we can have references to device memory pages even when user mode > > has > > closed /dev/kfd. We do have a cleanup handler that runs in an > > MMU-free-notifier. > > In theory that should run after all the pages in the mm_struct have been > > freed. > > It releases all sorts of other device resources and needs the driver to > > still be > > there. I'm not sure if there is anything preventing a module unload before > > the > > free-notifier runs. I'll look into that. > > Right - module unload (or device u
Re: [PATCH v2 7/8] nouveau/dmem: Evict device private memory during release
Reviewed-by: Lyude Paul
On Wed, 2022-09-28 at 22:01 +1000, Alistair Popple wrote:
> When the module is unloaded or a GPU is unbound from the module it is
> possible for device private pages to still be mapped in currently
> running processes. This can lead to a hangs and RCU stall warnings when
> unbinding the device as memunmap_pages() will wait in an uninterruptible
> state until all device pages have been freed which may never happen.
>
> Fix this by migrating device mappings back to normal CPU memory prior to
> freeing the GPU memory chunks and associated device private pages.
>
> Signed-off-by: Alistair Popple
> Cc: Lyude Paul
> Cc: Ben Skeggs
> Cc: Ralph Campbell
> Cc: John Hubbard
> ---
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 48 +++-
> 1 file changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> index 65f51fb..5fe2091 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> @@ -367,6 +367,52 @@ nouveau_dmem_suspend(struct nouveau_drm *drm)
> mutex_unlock(&drm->dmem->mutex);
> }
>
> +/*
> + * Evict all pages mapping a chunk.
> + */
> +static void
> +nouveau_dmem_evict_chunk(struct nouveau_dmem_chunk *chunk)
> +{
> + unsigned long i, npages = range_len(&chunk->pagemap.range) >>
> PAGE_SHIFT;
> + unsigned long *src_pfns, *dst_pfns;
> + dma_addr_t *dma_addrs;
> + struct nouveau_fence *fence;
> +
> + src_pfns = kcalloc(npages, sizeof(*src_pfns), GFP_KERNEL);
> + dst_pfns = kcalloc(npages, sizeof(*dst_pfns), GFP_KERNEL);
> + dma_addrs = kcalloc(npages, sizeof(*dma_addrs), GFP_KERNEL);
> +
> + migrate_device_range(src_pfns, chunk->pagemap.range.start >> PAGE_SHIFT,
> + npages);
> +
> + for (i = 0; i < npages; i++) {
> + if (src_pfns[i] & MIGRATE_PFN_MIGRATE) {
> + struct page *dpage;
> +
> + /*
> + * _GFP_NOFAIL because the GPU is going away and there
> + * is nothing sensible we can do if we can't copy the
> + * data back.
> + */
> + dpage = alloc_page(GFP_HIGHUSER | __GFP_NOFAIL);
> + dst_pfns[i] = migrate_pfn(page_to_pfn(dpage));
> + nouveau_dmem_copy_one(chunk->drm,
> + migrate_pfn_to_page(src_pfns[i]), dpage,
> + &dma_addrs[i]);
> + }
> + }
> +
> + nouveau_fence_new(chunk->drm->dmem->migrate.chan, false, &fence);
> + migrate_device_pages(src_pfns, dst_pfns, npages);
> + nouveau_dmem_fence_done(&fence);
> + migrate_device_finalize(src_pfns, dst_pfns, npages);
> + kfree(src_pfns);
> + kfree(dst_pfns);
> + for (i = 0; i < npages; i++)
> + dma_unmap_page(chunk->drm->dev->dev, dma_addrs[i], PAGE_SIZE,
> DMA_BIDIRECTIONAL);
> + kfree(dma_addrs);
> +}
> +
> void
> nouveau_dmem_fini(struct nouveau_drm *drm)
> {
> @@ -378,8 +424,10 @@ nouveau_dmem_fini(struct nouveau_drm *drm)
> mutex_lock(&drm->dmem->mutex);
>
> list_for_each_entry_safe(chunk, tmp, &drm->dmem->chunks, list) {
> + nouveau_dmem_evict_chunk(chunk);
> nouveau_bo_unpin(chunk->bo);
> nouveau_bo_ref(NULL, &chunk->bo);
> + WARN_ON(chunk->callocated);
> list_del(&chunk->list);
> memunmap_pages(&chunk->pagemap);
> release_mem_region(chunk->pagemap.range.start,
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH 6/7] nouveau/dmem: Evict device private memory during release
Re comments about infinite retry: gotcha, makes sense to me.
On Tue, 2022-09-27 at 09:45 +1000, Alistair Popple wrote:
> John Hubbard writes:
>
> > On 9/26/22 14:35, Lyude Paul wrote:
> > > > + for (i = 0; i < npages; i++) {
> > > > + if (src_pfns[i] & MIGRATE_PFN_MIGRATE) {
> > > > + struct page *dpage;
> > > > +
> > > > + /*
> > > > +* _GFP_NOFAIL because the GPU is going away
> > > > and there
> > > > +* is nothing sensible we can do if we can't
> > > > copy the
> > > > +* data back.
> > > > +*/
> > >
> > > You'll have to excuse me for a moment since this area of nouveau isn't
> > > one of
> > > my strongpoints, but are we sure about this? IIRC __GFP_NOFAIL means
> > > infinite
> > > retry, in the case of a GPU hotplug event I would assume we would rather
> > > just
> > > stop trying to migrate things to the GPU and just drop the data instead of
> > > hanging on infinite retries.
> > >
>
> No problem, thanks for taking a look!
>
> > Hi Lyude!
> >
> > Actually, I really think it's better in this case to keep trying
> > (presumably not necessarily infinitely, but only until memory becomes
> > available), rather than failing out and corrupting data.
> >
> > That's because I'm not sure it's completely clear that this memory is
> > discardable. And at some point, we're going to make this all work with
> > file-backed memory, which will *definitely* not be discardable--I
> > realize that we're not there yet, of course.
> >
> > But here, it's reasonable to commit to just retrying indefinitely,
> > really. Memory should eventually show up. And if it doesn't, then
> > restarting the machine is better than corrupting data, generally.
>
> The memory is definitely not discardable here if the migration failed
> because that implies it is still mapped into some userspace process.
>
> We could avoid restarting the machine by doing something similar to what
> happens during memory failure and killing every process that maps the
> page(s). But overall I think it's better to retry until memory is
> available, because that allows things like reclaim to work and in the
> worst case allows the OOM killer to select an appropriate task to kill.
> It also won't cause data corruption if/when we have file-backed memory.
>
> > thanks,
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
[PATCH] drm/amdgpu/dm/mst: Fix incorrect usage of drm_dp_add_payload_part2()
Yikes, it appears somehow I totally made a mistake here. We're currently
checking to see if drm_dp_add_payload_part2() returns a non-zero value to
indicate success. That's totally wrong though, as this function only
returns a zero value on success - not the other way around.
So, fix that.
Signed-off-by: Lyude Paul
Issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic
state")
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index b8077fcd4651..00598def5b39 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -297,7 +297,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
clr_flag = MST_ALLOCATE_NEW_PAYLOAD;
}
- if (enable && drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
payload)) {
+ if (enable && drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
payload) == 0) {
amdgpu_dm_set_mst_status(&aconnector->mst_status,
set_flag, false);
} else {
--
2.37.3
Re: [PATCH] drm/amdgpu/dm/mst: Fix incorrect usage of drm_dp_add_payload_part2()
On Tue, 2022-10-04 at 16:46 -0400, Rodrigo Siqueira Jordao wrote:
>
> On 2022-10-04 16:24, Lyude Paul wrote:
> > Yikes, it appears somehow I totally made a mistake here. We're currently
> > checking to see if drm_dp_add_payload_part2() returns a non-zero value to
> > indicate success. That's totally wrong though, as this function only
> > returns a zero value on success - not the other way around.
> >
> > So, fix that.
> >
> > Signed-off-by: Lyude Paul
> > Issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
> > Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the
> > atomic state")
> > ---
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > index b8077fcd4651..00598def5b39 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > @@ -297,7 +297,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
> > clr_flag = MST_ALLOCATE_NEW_PAYLOAD;
> > }
> >
> > - if (enable && drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
> > payload)) {
> > + if (enable && drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
> > payload) == 0) {
> > amdgpu_dm_set_mst_status(&aconnector->mst_status,
> > set_flag, false);
> > } else {
>
> Hi Lyude,
>
> Maybe I'm missing something, but I can't find the
> drm_dp_add_payload_part2() function on amd-staging-drm-next. Which repo
> are you using?
If it's not on amd-staging-drm-next then it likely hasn't gotten backported to
amd's branch yet and is in drm-misc-next
>
> Thanks
> Siqueira
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH] drm/amdgpu/dm/mst: Fix incorrect usage of drm_dp_add_payload_part2()
Gotcha, I'll take another look at this tomorrow
On Mon, 2022-10-17 at 03:09 +, Lin, Wayne wrote:
> [Public]
>
>
>
> > -Original Message-----
> > From: Lyude Paul
> > Sent: Thursday, October 6, 2022 3:37 AM
> > To: Siqueira, Rodrigo ; dri-
> > de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
> > Cc: Wentland, Harry ; Li, Sun peng (Leo)
> > ; Deucher, Alexander
> > ; Koenig, Christian
> > ; Pan, Xinhui ; David
> > Airlie ; Daniel Vetter ; Zuo, Jerry
> > ; Lin, Wayne ; Chen, Ian
> > ; Mikita Lipski ; Mahfooz,
> > Hamza ; Claudio Suarez ; Colin
> > Ian King ; Jani Nikula ; open
> > list
> > Subject: Re: [PATCH] drm/amdgpu/dm/mst: Fix incorrect usage of
> > drm_dp_add_payload_part2()
> >
> > On Tue, 2022-10-04 at 16:46 -0400, Rodrigo Siqueira Jordao wrote:
> > >
> > > On 2022-10-04 16:24, Lyude Paul wrote:
> > > > Yikes, it appears somehow I totally made a mistake here. We're
> > > > currently checking to see if drm_dp_add_payload_part2() returns a
> > > > non-zero value to indicate success. That's totally wrong though, as
> > > > this function only returns a zero value on success - not the other way
> > around.
> > > >
> > > > So, fix that.
> > > >
> > > > Signed-off-by: Lyude Paul
> > > > Issue:
> > > >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > > tlab.freedesktop.org%2Fdrm%2Famd%2F-
> > %2Fissues%2F2171&data=05%7C0
> > > >
> > 1%7Cwayne.lin%40amd.com%7Ccd5a63120e064f4bb6aa08daa7090baf%7C3d
> > d8961
> > > >
> > fe4884e608e11a82d994e183d%7C0%7C0%7C638005954559719396%7CUnkno
> > wn%7CT
> > > >
> > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > JXV
> > > >
> > CI6Mn0%3D%7C3000%7C%7C%7C&sdata=nMIGnUKS6EDrdKJ0rR%2BAh
> > FRa4ST0%2
> > > > BYr9bILmXv40yv0%3D&reserved=0
> > > > Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into
> > > > the atomic state")
> > > > ---
> > > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2
> > +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git
> > > > a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > index b8077fcd4651..00598def5b39 100644
> > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > +++
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > @@ -297,7 +297,7 @@ bool
> > dm_helpers_dp_mst_send_payload_allocation(
> > > > clr_flag = MST_ALLOCATE_NEW_PAYLOAD;
> > > > }
> > > >
> > > > - if (enable && drm_dp_add_payload_part2(mst_mgr, mst_state-
> > > base.state, payload)) {
> > > > + if (enable && drm_dp_add_payload_part2(mst_mgr,
> > > > +mst_state->base.state, payload) == 0) {
>
> Hi Lyude,
>
> This line changes the original logic a bit. The 'if' case was trying to catch
> failure
> while sending ALLOCATE_PAYLOAD. If the msg fails, set the set_flag to false.
> If succeed, set the set_flag to true and clear the clr_flag.
>
> Sorry if the code wording misleading. Thanks!
>
> > > > amdgpu_dm_set_mst_status(&aconnector->mst_status,
> > > > set_flag, false);
> > > > } else {
> > >
> > > Hi Lyude,
> > >
> > > Maybe I'm missing something, but I can't find the
> > > drm_dp_add_payload_part2() function on amd-staging-drm-next. Which
> > > repo are you using?
> >
> > If it's not on amd-staging-drm-next then it likely hasn't gotten backported
> > to
> > amd's branch yet and is in drm-misc-next
> >
> > >
> > > Thanks
> > > Siqueira
> > >
> >
> > --
> > Cheers,
> > Lyude Paul (she/her)
> > Software Engineer at Red Hat
> --
> Regards,
> Wayne Lin
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
[Important!] 2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding instructions on the nomination process to membership in the near future. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is March 17th 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ You can find the current election schedule here: https://www.x.org/wiki/BoardOfDirectors/Elections/2022/ Lyude Paul, On behalf of the X.Org elections committee
2022 X.Org Board of Directors Elections Nomination period is NOW
We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2022 election are now open and will remain open until 23:59 UTC on 06 March 2022. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2021 were Lyude Paul, Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will continue to serve until their term ends in 2023. Current directors whose term expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark Filion. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the member's account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23:59 UTC on 6th March 2022. The slate of candidates will be published 14 March 2022 and candidate Q&A will begin then. The deadline for Xorg membership applications and renewals is 17 March 2022. Cheers, Lyude Paul, on behalf of the X.Org BoD
2022 X.Org Board of Directors Elections timeline extended, Request for nominations
We are seeking nominations for candidates for election to the X.org Foundation Board of Directors. However, as we presently do not have enough nominations to start the election - the decision has been made to extend the timeline by 2 weeks. Note this is a fairly regular part of the elections process. The new deadline for nominations to the X.org Board of Directors is 23:59 UTC on 20th March 2022. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2021 were Lyude Paul, Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will continue to serve until their term ends in 2023. Current directors whose term expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark Filion. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the member's account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23:59 UTC on 20th March 2022. The slate of candidates will be published 28th March 2022 and candidate Q&A will begin then. The deadline for Xorg membership applications and renewals is 31st March 2022. Cheers, Lyude Paul, on behalf of the X.Org BoD
Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref histories from debugfs
e them keep the stale dc_sinks. > 3. plug in the mst monitor to arbitrary ports. Since the new connected mst > monitor will > have us add new mst port to the topology and attach a new aconnector for > that mst port, > we'll try to create a new dc_sink to that new aconnector and break the > sink_count > limitation. As you can see in the log the error message : "*ERROR* Unable to > add a > remote sink" > > (Note that different hub might influence the result. Some hubs will pull > down the HPD > when there is no monitor connected to its downstream ports which will run > into different > code flow) by "pull down" I assume you mean doing a long HPD instead of short (or vice versa?). > > I also attach the dmesg log under different debug level (0x104 & 0x116) for > your reference. > > Please let me know if you can reproduce then : ) > > Sorry about that Lyude and hope this time I send to the right thread.. > Really appreciate for your help!!! > > Regards, > Wayne > > -Original Message- > > From: Lyude Paul > > Sent: Wednesday, March 2, 2022 9:10 AM > > To: Lin, Wayne > > Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref > > histories from debugfs > > > > Ran into some issues with my system yesterday (hooray being the first to > > find > > a rather annoying zsh bug that broke my scripts!), but I've finally got > > things > > setup. I'm not able to reproduce this issue though (I've tried hotplugging > > the > > way you mentioned here, but nothing seems to leak), which makes me think > > there's something special in your setup we might not have noticed. > > > > Do you think you could get some drm logs with drm.debug=0x116 > > log_buf_len=50M > > from when this happens so I can get a better idea of the drm events > > leading up > > to this? Also, if you've been testing this in a GUI could you confirm > > whether > > this happens when you're just in a plain old VT? > > > > On Mon, 2022-02-28 at 16:43 -0500, Lyude Paul wrote: > > > Alright - starting to look into this now and setting up a system to try > > > reproducing this, will let you know as soon as I've got results. Sorry > > > again > > > about all of the delays > > > > > > On Fri, 2022-02-25 at 15:47 -0500, Lyude Paul wrote: > > > > I didn't get a chance yet, but I've gotten through most of my backlog > > > > now. > > > > Sorry about the delay - I've been catching up since I had to take two > > > > weeks > > > > off work very unexpectedly. I'll put aside time to look at this first > > > > thing > > > > monday. > > > > > > > > On Fri, 2022-02-25 at 01:33 +, Lin, Wayne wrote: > > > > > [AMD Official Use Only] > > > > > > > > > > Hi Lyude, > > > > > > > > > > Good day! > > > > > Sorry to bother you, but would like to know if you can reproduce the > > > > > issue? > > > > > > > > > > Thanks! > > > > > > > > > > Regards, > > > > > Wayne > > > > > > > > > > > -Original Message- > > > > > > From: Lyude Paul > > > > > > Sent: Thursday, February 3, 2022 4:12 AM > > > > > > To: Lin, Wayne > > > > > > Cc: dri-de...@lists.freedesktop.org > > > > > > Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping > > > > > > topology > > > > > > ref > > > > > > histories from debugfs > > > > > > > > > > > > JFYI I should be able to respond to this soon, I think I'm > > > > > > following > > > > > > your > > > > > > issue a bit more (haven't gotten to go through the patches too so > > > > > > I'm > > > > > > probably > > > > > > going to see if I can reproduce it locally as well. Sorry for the > > > > > > delay > > > > > > - > > > > > > dealing with some X.org stuff and work issues at the moment > > > > > > > > > > > > On Tue, 2022-01-25 at 08:32 +, Lin, Wayne wrote: > > > > > > > [Public] > > > > > > > > > > > > > > Hey Lyude, > > > > > > > > > > &g
2022 X.Org Board of Directors Elections Nomination period is NOW
The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2021 were Lyude Paul, Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will continue to serve until their term ends in 2023. Current directors whose term expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark Filion. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the member's account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23:59 UTC on 20th March 2022. The slate of candidates will be published 28th March 2022 and candidate Q&A will begin then. The deadline for Xorg membership applications and renewals is 31st March 2022. Cheers, Lyude Paul, on behalf of the X.Org BoD
2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding the election schedule and nominating process to the membership shortly. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is 31 March 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ Lyude Paul, on behalf of the X.Org elections committee
2022 X.org Foundation Election Candidates
To all X.Org Foundation Members: The election for the X.Org Foundation Board of Directors will begin on 04 April 2022. We have 6 candidates who are running for 4 seats. They are: Emma Anholt Shashank Sharma Ricardo Garcia Mark Filion Lucas Stach Alyssa Rosenzweig To be found in the link below below are the Personal Statements each candidate submitted for your consideration along with their Statements of Contribution that they submitted with the membership application. Please review each of the candidates' statements to help you decide whom to vote for during the upcoming election. https://www.x.org/wiki/BoardOfDirectors/Elections/2022/ If you have questions of the candidates, you should feel free to ask them here on the mailing list. The election committee will provide detailed instructions on how the voting system will work when the voting period begins. Lyude Paul, on behalf of the X.Org elections committee
2022 X.Org Foundation Election vote results
The Board of Directors election and the vote on the By-laws concluded at 23:59 UTC on 18 April 2022. There are 80 current Members of the X.Org Foundation, and 52 Members cast votes. This is a 65.0% turn out. In the election of the Directors to the Board of the X.Org Foundation, the results were that Emma Anholt, Alyssa Rosenzweig, Mark Filion and Ricardo Garcia were elected for two year terms. The old full board is: Emma Anholt, Samuel Iglesias Gonsálvez, Mark Filion, Manasi D Navare, Keith Packard, Lyude Paul, Daniel Vetter, Harry Wentland The new full board is: Emma Anholt, Samuel Iglesias Gonsálvez, Mark Filion, Manasi D Navare, Alyssa Rosenzweig, Lyude Paul, Daniel Vetter, and Ricardo Garcia The full election results were as follows: Option | Rank 1 | Rank 2 | Rank 3 | Rank 4 | Rank 5 | Rank 6 | Final Score Emma Anholt | 21 | 16 | 4 | 1 | 5 | 5 | 240 Alyssa Rosenzweig | 4 | 10 | 17 | 7 | 11 | 3 | 188 Mark Filion | 8 | 12 | 7 | 10 | 5 | 10 | 186 Ricardo Garcia | 9 | 4 | 5 | 17 | 10 | 7 | 172 Lucas Stach | 4 | 5 | 14 | 9 | 11 | 9 | 163 Shashank Sharma | 6 | 5 | 5 | 8 | 10 | 18 | 143 Lyude Paul, on behalf of the X.Org elections committee
Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref histories from debugfs
Hey! Figured I'd check if there's been any status updates here since it's been a while, just to make sure I haven't dropped this issue from my radar. No problem if you're busy :) On Wed, 2022-03-16 at 10:46 +, Lin, Wayne wrote: > [Public] > > > -Original Message- > > From: Lyude Paul > > Sent: Wednesday, March 16, 2022 8:48 AM > > To: Lin, Wayne > > Cc: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org > > Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref > > histories from debugfs > > > > (Adding this back to the dri-devel mailing list since I didn't notice it > > got > > dropped from there) > > > > Hm, some comments on this issue down below. Sorry for the delayed > > response, I > > was going to try this right after I finished the MST legacy removal but > > that's > > ending up taking longer than I hoped. > > > > On Tue, 2022-03-08 at 01:46 +, Lin, Wayne wrote: > > > [AMD Official Use Only] > > > > > > Oops... > > > I didn't notice that I replied to wrong mail previously : P > > > Sorry for the confusion and reply to the correct thread. > > > > > > Good day! > > > I probably know why you can't reproduce the issue there. Please refer to > > > the > > > attached > > > patch file which makes me easier to explain this. > > > > > > In dm_dp_mst_get_modes(), we will create a new dc_sink by calling > > > dc_link_add_remote_sink() and add that dc_sink into the array dc_link- > > > > remote_sinks[]. > > > However, if we find that aconnector->dc_sink is not null, then we won't > > > create a new > > > dc_sink for that aconnector and won't add the sink to the array dc_link- > > > > remote_sinks[]. > > > > > > When the issue that I mentioned before occurs, we won't be able to > > > release > > > the dc_sink > > > for the aconnector when we unplug the sst monitor. Hence, we can't > > > create > > > new dc_sink > > > for the latter on connected new stream sink of that port. Which leads to > > > two > > > issues > > > 1. Unplug monitor and plug in another monitor "to the same port" > > > => Since we use the same dc_sink to reflect the capability of the new > > > connected stream > > > sink, we might send out inappropriate stream to the new connected sink. > > > 2. Because we can't release dc_sink in the array dc_link- > > > >remote_sinks[], > > > when we > > > plug/unplug sst monitor to more than 4 different mst port, we will break > > > the > > > criteria > > > "dc_link->sink_count >= MAX_SINKS_PER_LINK" in > > > link_add_remote_sink_helper(). > > > > Ok, a lot of this seems to be happening in amdgpu which certainly explains > > why > > I had so much trouble following along with this originally (also, having > > learned a bit more about how DC works definitely has helped a bit). I > > already > > see a bunch of issues though with how this code is structured that would > > definitely break things, though note I haven't sat down and tried this on > > a > > real machine yet - will try tomorrow. > > > > So - it seems like dc_sink == a bunch of hotplugging state for a dm > > connector, > > which actually tells me for one that this is definitely the wrong spot for > > this code. get_modes() really should just handle filling out DRM modes and > > pretty much nothing else, because callers from DRM aren't going to expect > > side-effects like this when get_modes() is called - which could > > potentially > > lead to all sorts of weirdness down the line if the DRM call paths that > > use > > this ever change. i915 and nouveau have good examples of what these > > functions > > should typically look like, and amdgpu actually seems to mostly follow > > this > > advice for it's other get_modes() callback. > > > > Note there's also another problem here: the assumption "no EDID == > > disconnected" isn't correct. It's totally possible to run into EDID-less > > displays if the display is some ancient pre-historic relic, or if the ROM > > (or > > EEPROM? can't remember what type of chip computer displays tend to use...) > > chip > > in the monitor containing the EDID has died. Note that the second > > situation is > > suprisingly
XDC 2022: Registration & Call for Proposals now open!
Hello! The 2022 X.Org Developers Conference is being held in conjunction with the 2022 Wine Developers Conference. This is a meeting to bring together developers working on all things open graphics (Linux kernel, Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine Project, a key consumer of open graphics. Registration & Call for Proposals are now open for both XDC 2022 and WineConf 2022, which will take place on October 4-6, 2022 in Minneapolis, Minnesota, USA. https://xdc2022.x.org As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to do it via the XDC website: https://indico.freedesktop.org/event/2/registrations/2/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2022. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/2/abstracts/ The deadline for submissions is Monday July 4th, 2022. Check out our Reimbursement Policy to accept speaker expenses for X.Org events like XDC 2022: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to x...@codeweavers.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best regards, Lyude Paul, on behalf of X.org
Requests For Proposals for hosting XDC 2023 are now open
Hello everyone! The X.org board is soliciting proposals to host XDC in 2023. Since XDC 2022 is being held in North America this year, XDC 2023 is expected to be in Europe. However, the board is open to other locations, especially if there's an interesting co-location with another conference. If you're considering hosting XDC, we've assembled a wiki page with what's generally expected and needed: https://www.x.org/wiki/Events/RFP/ When submitting your proposal, please make sure to include at least the key information about the potential location in question, possible dates along with estimated costs. Proposals can be submitted to board at foundation.x.org until the deadline of *September 1st, 2022*. Additionally, an quirk early heads-up to the board if you're considering hosting would be appreciated, in case we need to adjust the schedule a bit. Also, earlier is better since there generally will be a bit of Q&A with organizers. And if you just have some questions about what organizing XDC entails, please feel free to chat with previous organizers, or someone from the board. Best regards, Lyude Paul On behalf of X.org
Re: [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
i.c | 66 --- > drivers/platform/x86/apple-gmux.c | 3 - > drivers/platform/x86/asus-nb-wmi.c | 21 - > drivers/platform/x86/asus-wmi.c | 13 - > drivers/platform/x86/asus-wmi.h | 2 - > drivers/platform/x86/eeepc-wmi.c | 25 +- > drivers/platform/x86/samsung-laptop.c | 87 > drivers/platform/x86/toshiba_acpi.c | 16 - > include/acpi/video.h | 9 +- > 26 files changed, 468 insertions(+), 415 deletions(-) > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH v2 05/29] drm/nouveau: Don't register backlight when another backlight should be used
Reviewed-by: Lyude Paul
You also have permission to push this to drm-misc-whatever
On Tue, 2022-07-12 at 21:38 +0200, Hans de Goede wrote:
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight device and acpi_video's
> firmware acpi_video# backlight device. This relies on userspace preferring
> firmware type backlight devices over native ones.
>
> Registering 2 backlight devices for a single display really is
> undesirable, don't register the GPU's native backlight device when
> another backlight device should be used.
>
> Reviewed-by: Lyude Paul
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index a2141d3d9b1d..91c504c7b82c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -34,6 +34,8 @@
> #include
> #include
>
> +#include
> +
> #include "nouveau_drv.h"
> #include "nouveau_reg.h"
> #include "nouveau_encoder.h"
> @@ -405,6 +407,11 @@ nouveau_backlight_init(struct drm_connector *connector)
> goto fail_alloc;
> }
>
> + if (!acpi_video_backlight_use_native()) {
> + NV_INFO(drm, "Skipping nv_backlight registration\n");
> + goto fail_alloc;
> + }
> +
> if (!nouveau_get_backlight_name(backlight_name, bl)) {
> NV_ERROR(drm, "Failed to retrieve a unique name for the
> backlight interface\n");
> goto fail_alloc;
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [RESEND RFC 00/18] drm/display/dp_mst: Drop Radeon MST support, make MST atomic-only
Sorry for taking a while on respinning this! I've been busy with trying to review as much nouveau patches as possible before we passed the deadline for getting pulled into the kernel, since we've got quite a lot of pending patches coming up. The pull deadline we had from Dave has passed at this point though, so I should have a chance to respin this in the next few business days. On Tue, 2022-06-07 at 15:29 -0400, Lyude Paul wrote: > Ugh, thanks ./scripts/get_maintainers.pl for confusing and breaking > git-send email <<. Sorry for the resend everyone. > > For quite a while we've been carrying around a lot of legacy modesetting > code in the MST helpers that has been rather annoying to keep around, > and very often gets in the way of trying to implement additional > functionality in MST such as fallback link rate retraining, dynamic BPC > management and DSC support, etc. because of the fact that we can't rely > on atomic for everything. > > Luckily, we only actually have one user of the legacy MST code in the > kernel - radeon. Originally I was thinking of trying to maintain this > code and keep it around in some form, but I'm pretty unconvinced anyone > is actually using this. My reasoning for that is because I've seen > nearly no issues regarding MST on radeon for quite a while now - despite > the fact my local testing seems to indicate it's quite broken. This > isn't too surprising either, as MST support in radeon.ko is gated behind > a module parameter that isn't enabled by default. This isn't to say I > wouldn't be open to alternative suggestions, but I'd rather not be the > one to have to spend time on that if at all possible! Plus, I already > floated the idea of dropping this code by AMD folks a few times and > didn't get much resistance. > > As well, this series has some basic refactoring that I did along the way > and some bugs I had to fix in order to get my atomic-only MST code > working. Most of this is pretty straight forward and simply renaming > things to more closely match the DisplayPort specification, as I think > this will also make maintaining this code a lot easier in the long run > (I've gotten myself confused way too many times because of this). > > So far I've tested this on all three MST drivers: amdgpu, i915 and > nouveau, along with making sure that removing the radeon MST code > doesn't break anything else. The one thing I very much could use help > with regarding testing though is making sure that this works with > amdgpu's DSC support on MST. > > So, with this we should be using the atomic state as much as possible > with MST modesetting, hooray! > > Cc: Wayne Lin > Cc: Ville Syrjälä > Cc: Fangzhi Zuo > Cc: Jani Nikula > Cc: Imre Deak > Cc: Daniel Vetter > Cc: Sean Paul > > Lyude Paul (18): > drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table) > drm/amdgpu/dm/mst: Rename get_payload_table() > drm/display/dp_mst: Rename drm_dp_mst_vcpi_allocation > drm/display/dp_mst: Call them time slots, not VCPI slots > drm/display/dp_mst: Fix confusing docs for > drm_dp_atomic_release_time_slots() > drm/display/dp_mst: Add some missing kdocs for atomic MST structs > drm/display/dp_mst: Add helper for finding payloads in atomic MST > state > drm/display/dp_mst: Add nonblocking helpers for DP MST > drm/display/dp_mst: Don't open code modeset checks for releasing time > slots > drm/display/dp_mst: Fix modeset tracking in > drm_dp_atomic_release_vcpi_slots() > drm/nouveau/kms: Cache DP encoders in nouveau_connector > drm/nouveau/kms: Pull mst state in for all modesets > drm/display/dp_mst: Add helpers for serializing SST <-> MST > transitions > drm/display/dp_mst: Drop all ports from topology on CSNs before > queueing link address work > drm/display/dp_mst: Skip releasing payloads if last connected port > isn't connected > drm/display/dp_mst: Maintain time slot allocations when deleting > payloads > drm/radeon: Drop legacy MST support > drm/display/dp_mst: Move all payload info into the atomic state > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 72 +- > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 111 +- > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 126 +- > drivers/gpu/drm/amd/display/dc/core/dc_link.c | 10 +- > drivers/gpu/drm/amd/display/dc/dm_helpers.h | 4 +- > .../amd/display/include/link_service_types.h | 18 +- > drivers/gpu/drm/display/drm_dp_mst_topology.c | 1160 - > drivers/gpu/drm/i915/display/intel_display.c | 11 + > drivers/gpu/drm/i915/display/intel_dp.c | 9 + > driver
Re: [RESEND RFC 04/18] drm/display/dp_mst: Call them time slots, not VCPI slots
On Wed, 2022-06-15 at 04:28 +, Lin, Wayne wrote:
> [Public]
>
> Thank you Lyude for addressing this!
>
> VCPI is also a confusing naming to me at first glance since it stands for
> Virtual Channel Payload Identification which is just an ID number ( we can
> look up these payload IDs In DPCD 0x2C1 ~0x2FF).
>
> I also look up left VCPI terms in rest of the code. Seems like we still can
> modify
> some parts here? Like:
>
> /**
> * struct drm_dp_vcpi - Virtual Channel Payload Identifier
> * @vcpi: Virtual channel ID.
> * @pbn: Payload Bandwidth Number for this channel
> * @aligned_pbn: PBN aligned with slot size
> * @num_slots: number of slots for this PBN
> */
> struct drm_dp_vcpi {
> int vcpi;
> int pbn;
> int aligned_pbn;
> int num_slots;
> };
>
> Would like to change the structure name to "struct drm_dp_mst_vcp {}" to
> represent
> the virtual channel payload. Not specific to the ID.
> Would like to know your thoughts : )
JFYI - I didn't rename this structure because we actually remove it entirely
in later patches
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Wednesday, June 8, 2022 3:29 AM
> > To: dri-de...@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd-
> > g...@lists.freedesktop.org
> > Cc: Lin, Wayne ; Ville Syrjälä
> > ; Zuo, Jerry ; Jani
> > Nikula
> > ; Imre Deak ; Daniel Vetter
> > ; Sean Paul ; Wentland, Harry
> > ; Li, Sun peng (Leo) ;
> > Siqueira, Rodrigo ; Deucher, Alexander
> > ; Koenig, Christian
> > ; Pan, Xinhui ; David
> > Airlie ; Daniel Vetter ; Jani Nikula
> > ; Joonas Lahtinen
> > ; Rodrigo Vivi ;
> > Tvrtko Ursulin ; Ben Skeggs
> > ; Karol Herbst ; Kazlauskas,
> > Nicholas ; Li, Roman
> > ; Shih, Jude ; Simon Ser
> > ; Wu, Hersen ; Thomas
> > Zimmermann ; Lakha, Bhawanpreet
> > ; José Roberto de Souza
> > ; He Ying ; Matt Roper
> > ; Sean Paul ; Hans
> > Verkuil ; Fernando Ramos ;
> > Javier Martinez Canillas ; open list > ker...@vger.kernel.org>; open list:INTEL DRM DRIVERS > g...@lists.freedesktop.org>
> > Subject: [RESEND RFC 04/18] drm/display/dp_mst: Call them time slots, not
> > VCPI slots
> >
> > VCPI is only sort of the correct term here, originally the majority of
> > this code
> > simply referred to timeslots vaguely as "slots" - and since I started
> > working
> > on it and adding atomic functionality, the name "VCPI slots" has been used
> > to
> > represent time slots.
> >
> > Now that we actually have consistent access to the DisplayPort spec thanks
> > to
> > VESA, I now know this isn't actually the proper term - as the
> > specification
> > refers to these as time slots.
> >
> > Since we're trying to make this code as easy to figure out as possible,
> > let's
> > take this opportunity to correct this nomenclature and call them by their
> > proper name - timeslots. Likewise, we rename various functions
> > appropriately, along with replacing references in the kernel documentation
> > and various debugging messages.
> >
> > It's important to note that this patch series leaves the legacy MST code
> > untouched for the most part, which is fine since we'll be removing it soon
> > anyhow. There should be no functional changes in this series.
> >
> > Signed-off-by: Lyude Paul
> > Cc: Wayne Lin
> > Cc: Ville Syrjälä
> > Cc: Fangzhi Zuo
> > Cc: Jani Nikula
> > Cc: Imre Deak
> > Cc: Daniel Vetter
> > Cc: Sean Paul
> > ---
> > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 28 ++---
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 106 +-
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +-
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +-
> > include/drm/display/drm_dp_mst_helper.h | 6 +-
> > 6 files changed, 75 insertions(+), 76 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 ad4571190a90..f84a4ad736d8 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -7393,7 +7393,7 @@ static int dm_encoder_helper_atomic_check(struct
> > drm_encoder *encoder,
> > clock = adjusted_mode->clock;
> > dm_new_connector_state-&g
Re: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing payloads if last connected port isn't connected
On Tue, 2022-07-05 at 08:45 +, Lin, Wayne wrote:
> [Public]
>
>
>
> > -Original Message-----
> > From: Lyude Paul
> > Sent: Wednesday, June 8, 2022 3:30 AM
> > To: dri-de...@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd-
> > g...@lists.freedesktop.org
> > Cc: Lin, Wayne ; Ville Syrjälä
> > ; Zuo, Jerry ; Jani
> > Nikula
> > ; Imre Deak ; Daniel Vetter
> > ; Sean Paul ; David Airlie
> > ; Daniel Vetter ; Thomas Zimmermann
> > ; Lakha, Bhawanpreet
> > ; open list
> > Subject: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing payloads if
> > last connected port isn't connected
> >
> > In the past, we've ran into strange issues regarding errors in response to
> > trying to destroy payloads after a port has been unplugged. We fixed this
> > back in:
> >
> > This is intended to replace the workaround that was added here:
> >
> > commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
> > ports in stale topology")
> >
> > which was intended fix to some of the payload leaks that were observed
> > before, where we would attempt to determine if the port was still
> > connected to the topology before updating payloads using
> > drm_dp_mst_port_downstream_of_branch. This wasn't a particularly good
> > solution, since one of the points of still having port and mstb validation
> > is to
> > avoid sending messages to newly disconnected branches wherever possible
> > - thus the required use of drm_dp_mst_port_downstream_of_branch
> > would indicate something may be wrong with said validation.
> >
> > It seems like it may have just been races and luck that made
> > drm_dp_mst_port_downstream_of_branch work however, as while I was
> > trying to figure out the true cause of this issue when removing the legacy
> > MST code - I discovered an important excerpt in section 2.14.2.3.3.6 of
> > the DP
> > 2.0
> > specs:
> >
> > "BAD_PARAM - This reply is transmitted when a Message Transaction
> > parameter is in error; for example, the next port number is invalid or /no
> > device is connected/ to the port associated with the port number."
> >
> > Sure enough - removing the calls to
> > drm_dp_mst_port_downstream_of_branch()
> > and instead checking the ->ddps field of the parent port to see whether we
> > should release a given payload or not seems to totally fix the issue. This
> > does
> > actually make sense to me, as it seems the implication is that given a
> > topology where an MSTB is removed, the payload for the MST parent's port
> > will be released automatically if that port is also marked as
> > disconnected.
> > However, if there's another parent in the chain after that which is
> > connected
> > - payloads must be released there with an ALLOCATE_PAYLOAD message.
> >
> > So, let's do that!
> >
> > Signed-off-by: Lyude Paul
> > Cc: Wayne Lin
> > Cc: Ville Syrjälä
> > Cc: Fangzhi Zuo
> > Cc: Jani Nikula
> > Cc: Imre Deak
> > Cc: Daniel Vetter
> > Cc: Sean Paul
> > ---
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 51 +++
> > 1 file changed, 17 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index dd314586bac3..70adb8db4335 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -3137,7 +3137,7 @@ static struct drm_dp_mst_port
> > *drm_dp_get_last_connected_port_to_mstb(struct drm static struct
> > drm_dp_mst_branch * drm_dp_get_last_connected_port_and_mstb(struct
> > drm_dp_mst_topology_mgr *mgr,
> > struct drm_dp_mst_branch *mstb,
> > - int *port_num)
> > + struct drm_dp_mst_port
> > **last_port)
> > {
> > struct drm_dp_mst_branch *rmstb = NULL;
> > struct drm_dp_mst_port *found_port;
> > @@ -3153,7 +3153,8 @@
> > drm_dp_get_last_connected_port_and_mstb(struct
> > drm_dp_mst_topology_mgr *mgr,
> >
> > if (drm_dp_mst_topology_try_get_mstb(found_port-
> > > parent)) {
> > rmstb = found_port->parent;
> > - *port_num = found_port->port_num;
> > + *last_port = found_port;
> > +
Re: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info into the atomic state
On Tue, 2022-07-05 at 09:10 +, Lin, Wayne wrote:
> > +struct drm_dp_mst_port;
> > +
> > /* DP MST stream allocation (payload bandwidth number) */
> > struct dc_dp_mst_stream_allocation {
> > uint8_t vcp_id;
> > /* number of slots required for the DP stream in
> > * transport packet */
> > uint8_t slot_count;
> > + /* The MST port this is on, this is used to associate DC MST payloads
> > with their
> > + * respective DRM payloads allocations, and can be ignored on non-
> > Linux.
> > + */
>
> Is it necessary for adding this new member? Since this is for setting the DC
> HW and not relating to drm.
I don't entirely know, honestly. The reasons I did it:
* Mapping things from DRM to DC and from DC to DRM is really confusing for
outside contributors like myself, so it wasn't even really clear to me if
there was another way to reconstruct the DRM context from the spots where
we call from DC up to DM (not a typo, see next point).
* These DC structs for MST are already layer mixing as far as I can tell,
just not in an immediately obvious way. While this struct itself is for DC,
there's multiple spots where we pass the DC payload structs down from DM to
DC, then pass them back up from DC to DM and have to figure out how to
reconstruct the DRM context that we actually need to use the MST helpers
from that. So, that kind of further complicates the confusion of where
layers should be separated.
* As far as I'm aware with C there shouldn't be any issue with adding a
pointer to a struct whose contents are undefined. IMHO, this is also
preferable to just using void* because then at least you get some hint as
to the actual type of the data and avoid the possibility of casting it to
the wrong type. So tl;dr, on any platform even outside of Linux with a
reasonably compliant compiler this should still build just fine. It'll even
give you the added bonus of warning people if they try to access the
contents of this member in DC on non-Linux platforms. If void* is preferred
though I'm fine with switching it to that.
--
Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH v2 1/3] drm/dp_mst: add passthrough_aux to struct drm_dp_mst_port
lgtm!
Reviewed-by: Lyude Paul
On Fri, 2022-08-05 at 17:13 -0400, Hamza Mahfooz wrote:
> Currently, there is no way to identify if DSC pass-through can be
> enabled and what aux DSC pass-through requests ought to be sent to. So,
> add a variable to struct drm_dp_mst_port that keeps track of the
> aforementioned information.
>
> Signed-off-by: Hamza Mahfooz
> ---
> v2: define DP_DSC_PASSTHROUGH_IS_SUPPORTED
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +++-
> include/drm/display/drm_dp.h | 1 +
> include/drm/display/drm_dp_mst_helper.h | 3 +++
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 67b3b9697da7..71915afd9892 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -5921,8 +5921,10 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
> drm_dp_mst_port *port)
> /* Enpoint decompression with DP-to-DP peer device */
> if ((endpoint_dsc & DP_DSC_DECOMPRESSION_IS_SUPPORTED) &&
> (endpoint_fec & DP_FEC_CAPABLE) &&
> - (upstream_dsc & 0x2) /* DSC passthrough */)
> + (upstream_dsc & DP_DSC_PASSTHROUGH_IS_SUPPORTED)) {
> + port->passthrough_aux = &immediate_upstream_port->aux;
> return &port->aux;
> + }
>
> /* Virtual DPCD decompression with DP-to-DP peer device */
> return &immediate_upstream_port->aux;
> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
> index 9e3aff7e68bb..4d0abe4c7ea9 100644
> --- a/include/drm/display/drm_dp.h
> +++ b/include/drm/display/drm_dp.h
> @@ -239,6 +239,7 @@
>
> #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */
> # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0)
> +# define DP_DSC_PASSTHROUGH_IS_SUPPORTED(1 << 1)
>
> #define DP_DSC_REV 0x061
> # define DP_DSC_MAJOR_MASK (0xf << 0)
> diff --git a/include/drm/display/drm_dp_mst_helper.h
> b/include/drm/display/drm_dp_mst_helper.h
> index 10adec068b7f..4a39c95f8afd 100644
> --- a/include/drm/display/drm_dp_mst_helper.h
> +++ b/include/drm/display/drm_dp_mst_helper.h
> @@ -86,6 +86,8 @@ struct drm_dp_vcpi {
> * @next: link to next port on this branch device
> * @aux: i2c aux transport to talk to device connected to this port,
> protected
> * by &drm_dp_mst_topology_mgr.base.lock.
> + * @passthrough_aux: parent aux to which DSC pass-through requests should be
> + * sent, only set if DSC pass-through is possible.
> * @parent: branch device parent of this port
> * @vcpi: Virtual Channel Payload info for this port.
> * @connector: DRM connector this port is connected to. Protected by
> @@ -140,6 +142,7 @@ struct drm_dp_mst_port {
>*/
> struct drm_dp_mst_branch *mstb;
> struct drm_dp_aux aux; /* i2c bus for this port? */
> + struct drm_dp_aux *passthrough_aux;
> struct drm_dp_mst_branch *parent;
>
> struct drm_dp_vcpi vcpi;
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info into the atomic state
On Mon, 2022-08-08 at 10:02 +, Lin, Wayne wrote:
> [Public]
>
>
>
> > -Original Message-----
> > From: Lyude Paul
> > Sent: Thursday, August 4, 2022 4:28 AM
> > To: Lin, Wayne ; dri-de...@lists.freedesktop.org;
> > nouv...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
> > Cc: Ville Syrjälä ; Zuo, Jerry
> > ; Jani Nikula ; Imre Deak
> > ; Daniel Vetter ; Sean Paul
> > ; Wentland, Harry ; Li, Sun
> > peng (Leo) ; Siqueira, Rodrigo
> > ; Deucher, Alexander
> > ; Koenig, Christian
> > ; Pan, Xinhui ; David
> > Airlie ; Daniel Vetter ; Jani Nikula
> > ; Joonas Lahtinen
> > ; Rodrigo Vivi ;
> > Tvrtko Ursulin ; Ben Skeggs
> > ; Karol Herbst ; Kazlauskas,
> > Nicholas ; Li, Roman
> > ; Shih, Jude ; Simon Ser
> > ; Lakha, Bhawanpreet
> > ; Mikita Lipski ;
> > Claudio Suarez ; Chen, Ian ; Colin Ian
> > King ; Wu, Hersen ; Liu,
> > Wenjing ; Lei, Jun ; Strauss,
> > Michael ; Ma, Leo ;
> > Thomas Zimmermann ; José Roberto de Souza
> > ; He Ying ; Anshuman
> > Gupta ; Andi Shyti
> > ; Ashutosh Dixit ;
> > Juston Li ; Sean Paul ;
> > Fernando Ramos ; Luo Jiaxing
> > ; Javier Martinez Canillas ;
> > open list ; open list:INTEL DRM DRIVERS
> >
> > Subject: Re: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info
> > into the atomic state
> >
> > On Tue, 2022-07-05 at 09:10 +, Lin, Wayne wrote:
> > > > +struct drm_dp_mst_port;
> > > > +
> > > > /* DP MST stream allocation (payload bandwidth number) */
> > > > struct dc_dp_mst_stream_allocation {
> > > > uint8_t vcp_id;
> > > > /* number of slots required for the DP stream in
> > > > * transport packet */
> > > > uint8_t slot_count;
> > > > + /* The MST port this is on, this is used to associate DC MST
> > > > + payloads
> > > > with their
> > > > + * respective DRM payloads allocations, and can be ignored on non-
> > > > Linux.
> > > > + */
> > >
> > > Is it necessary for adding this new member? Since this is for setting
> > > the DC HW and not relating to drm.
> >
> > I don't entirely know, honestly. The reasons I did it:
> >
> > * Mapping things from DRM to DC and from DC to DRM is really confusing for
> >outside contributors like myself, so it wasn't even really clear to me if
> >there was another way to reconstruct the DRM context from the spots
> > where
> >we call from DC up to DM (not a typo, see next point).
> > * These DC structs for MST are already layer mixing as far as I can tell,
> >just not in an immediately obvious way. While this struct itself is for
> > DC,
> >there's multiple spots where we pass the DC payload structs down from
> > DM to
> >DC, then pass them back up from DC to DM and have to figure out how to
> >reconstruct the DRM context that we actually need to use the MST helpers
> >from that. So, that kind of further complicates the confusion of where
> >layers should be separated.
> > * As far as I'm aware with C there shouldn't be any issue with adding a
> >pointer to a struct whose contents are undefined. IMHO, this is also
> >preferable to just using void* because then at least you get some hint as
> >to the actual type of the data and avoid the possibility of casting it to
> >the wrong type. So tl;dr, on any platform even outside of Linux with a
> >reasonably compliant compiler this should still build just fine. It'll
> > even
> >give you the added bonus of warning people if they try to access the
> >contents of this member in DC on non-Linux platforms. If void* is
> > preferred
> >though I'm fine with switching it to that.
> >
> > --
> > Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
>
> Hi Lyude,
>
> Thanks for your time!
> I was thinking that our DC just mainly takes care of HW related programming.
> Struct dc_dp_mst_stream_allocation is only used to construct a copy of the
> virtual
> channel payload ID and slots count of payload allocation table determined by
> dm/drm. ID and slots are only things required for programming HW registers.
> I think there shouldn't be any spots to try to construct the DRM context from
> this dc struct since there is no such concept in HW level. Our HW should only
> take care of local DP link and it doesn't have overall topology info.
Looking at the code I wrote again and realizing I slightly misspoke, looking
at the code again I think I probably can drop this. It's likely I just got
totally lost with the DC codebase and thought this was necessary when it
wasn't. Will drop in the respin
>
> Thanks!
>
> Regards,
> Wayne
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [RESEND RFC 06/18] drm/display/dp_mst: Add some missing kdocs for atomic MST structs
Also JFYI - I did see this comment but didn't address it in my respin, but only because I figured this might be better for a followup patch considering how much work is already in here On Wed, 2022-06-15 at 04:43 +, Lin, Wayne wrote: > I would prefer not using the term "available" which is a bit conflicting with > the idea in the reply of ENUM_PATH_RESOURCES - full PBN & available PBN. > Maybe better to change to use "full_slots"? > > Not yet finish all the patches. Will try to go through all the patches > recently : ) -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
[RFC v2 02/18] drm/amdgpu/dm/mst: Rename get_payload_table()
This function isn't too confusing if you see the comment around the
call-site for it, but if you don't then it's not at all obvious this is
meant to copy DRM's payload table over to DC's internal state structs.
Seeing this function before finding that comment definitely threw me into a
loop a few times.
So, let's rename this to make it's purpose more obvious regardless of where
in the code you are.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 3aa385860eea..77c545e670d5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -153,8 +153,9 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
return result;
}
-static void get_payload_table(struct amdgpu_dm_connector *aconnector,
- struct dc_dp_mst_stream_allocation_table
*proposed_table)
+static void
+fill_dc_mst_payload_table_from_drm(struct amdgpu_dm_connector *aconnector,
+ struct dc_dp_mst_stream_allocation_table
*proposed_table)
{
int i;
struct drm_dp_mst_topology_mgr *mst_mgr =
@@ -252,7 +253,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
* stream. AMD ASIC stream slot allocation should follow the same
* sequence. copy DRM MST allocation to dc */
- get_payload_table(aconnector, proposed_table);
+ fill_dc_mst_payload_table_from_drm(aconnector, proposed_table);
return true;
}
--
2.37.1
[RFC v2 01/18] drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table)
Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 9 -
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 10 +-
drivers/gpu/drm/amd/display/dc/dm_helpers.h | 4 ++--
.../gpu/drm/amd/display/include/link_service_types.h | 11 ---
4 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index a0154a5f7183..3aa385860eea 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -153,9 +153,8 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
return result;
}
-static void get_payload_table(
- struct amdgpu_dm_connector *aconnector,
- struct dp_mst_stream_allocation_table *proposed_table)
+static void get_payload_table(struct amdgpu_dm_connector *aconnector,
+ struct dc_dp_mst_stream_allocation_table
*proposed_table)
{
int i;
struct drm_dp_mst_topology_mgr *mst_mgr =
@@ -177,7 +176,7 @@ static void get_payload_table(
mst_mgr->payloads[i].payload_state ==
DP_PAYLOAD_REMOTE) {
- struct dp_mst_stream_allocation *sa =
+ struct dc_dp_mst_stream_allocation *sa =
&proposed_table->stream_allocations[
proposed_table->stream_count];
@@ -201,7 +200,7 @@ void dm_helpers_dp_update_branch_info(
bool dm_helpers_dp_mst_write_payload_allocation_table(
struct dc_context *ctx,
const struct dc_stream_state *stream,
- struct dp_mst_stream_allocation_table *proposed_table,
+ struct dc_dp_mst_stream_allocation_table *proposed_table,
bool enable)
{
struct amdgpu_dm_connector *aconnector;
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 9e51338441d0..e01424fb02ba 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3516,7 +3516,7 @@ static void update_mst_stream_alloc_table(
struct dc_link *link,
struct stream_encoder *stream_enc,
struct hpo_dp_stream_encoder *hpo_dp_stream_enc, // TODO: Rename
stream_enc to dio_stream_enc?
- const struct dp_mst_stream_allocation_table *proposed_table)
+ const struct dc_dp_mst_stream_allocation_table *proposed_table)
{
struct link_mst_stream_allocation work_table[MAX_CONTROLLER_NUM] = { 0
};
struct link_mst_stream_allocation *dc_alloc;
@@ -3679,7 +3679,7 @@ enum dc_status dc_link_allocate_mst_payload(struct
pipe_ctx *pipe_ctx)
{
struct dc_stream_state *stream = pipe_ctx->stream;
struct dc_link *link = stream->link;
- struct dp_mst_stream_allocation_table proposed_table = {0};
+ struct dc_dp_mst_stream_allocation_table proposed_table = {0};
struct fixed31_32 avg_time_slots_per_mtp;
struct fixed31_32 pbn;
struct fixed31_32 pbn_per_slot;
@@ -3784,7 +3784,7 @@ enum dc_status dc_link_reduce_mst_payload(struct pipe_ctx
*pipe_ctx, uint32_t bw
struct fixed31_32 avg_time_slots_per_mtp;
struct fixed31_32 pbn;
struct fixed31_32 pbn_per_slot;
- struct dp_mst_stream_allocation_table proposed_table = {0};
+ struct dc_dp_mst_stream_allocation_table proposed_table = {0};
uint8_t i;
const struct link_hwss *link_hwss = get_link_hwss(link,
&pipe_ctx->link_res);
DC_LOGGER_INIT(link->ctx->logger);
@@ -3873,7 +3873,7 @@ enum dc_status dc_link_increase_mst_payload(struct
pipe_ctx *pipe_ctx, uint32_t
struct fixed31_32 avg_time_slots_per_mtp;
struct fixed31_32 pbn;
struct fixed31_32 pbn_per_slot;
- struct dp_mst_stream_allocation_table proposed_table = {0};
+ struct dc_dp_mst_stream_allocation_table proposed_table = {0};
uint8_t i;
enum act_return_status ret;
const struct link_hwss *link_hwss = get_link_hwss(link,
&pipe_ctx->link_res);
@@ -3957,7 +3957,7 @@ static enum dc_status deallocate_mst_payload(struct
pipe_ctx *pipe_ctx)
{
struct dc_stream_state *stream = pipe_ctx->stream;
struct dc_link *link = stream->link;
- struct dp_mst_stream_allocation_table proposed_table = {0};
+ struct dc_dp_mst_stream_allocation_table proposed_table = {0};
struct fixed31_32 avg_time_slots_per_mtp = dc_fixpt_from_int(0);
[RFC v2 03/18] drm/display/dp_mst: Rename drm_dp_mst_vcpi_allocation
In retrospect, the name I chose for this originally is confusing, as
there's a lot more info in here then just the VCPI. This really should be
called a payload. Let's make it more obvious that this is meant to be
related to the atomic state and is about payloads by renaming it to
drm_dp_mst_atomic_payload. Also, rename various variables throughout the
code that use atomic payloads.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 96 +--
include/drm/display/drm_dp_mst_helper.h | 4 +-
2 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 7a94a5288e8d..f448e3e5ec6e 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4370,7 +4370,7 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state
*state,
int pbn_div)
{
struct drm_dp_mst_topology_state *topology_state;
- struct drm_dp_vcpi_allocation *pos, *vcpi = NULL;
+ struct drm_dp_mst_atomic_payload *pos, *payload = NULL;
int prev_slots, prev_bw, req_slots;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
@@ -4378,11 +4378,11 @@ int drm_dp_atomic_find_vcpi_slots(struct
drm_atomic_state *state,
return PTR_ERR(topology_state);
/* Find the current allocation for this port, if any */
- list_for_each_entry(pos, &topology_state->vcpis, next) {
+ list_for_each_entry(pos, &topology_state->payloads, next) {
if (pos->port == port) {
- vcpi = pos;
- prev_slots = vcpi->vcpi;
- prev_bw = vcpi->pbn;
+ payload = pos;
+ prev_slots = payload->vcpi;
+ prev_bw = payload->pbn;
/*
* This should never happen, unless the driver tries
@@ -4399,7 +4399,7 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state
*state,
break;
}
}
- if (!vcpi) {
+ if (!payload) {
prev_slots = 0;
prev_bw = 0;
}
@@ -4417,17 +4417,17 @@ int drm_dp_atomic_find_vcpi_slots(struct
drm_atomic_state *state,
port, prev_bw, pbn);
/* Add the new allocation to the state */
- if (!vcpi) {
- vcpi = kzalloc(sizeof(*vcpi), GFP_KERNEL);
- if (!vcpi)
+ if (!payload) {
+ payload = kzalloc(sizeof(*payload), GFP_KERNEL);
+ if (!payload)
return -ENOMEM;
drm_dp_mst_get_port_malloc(port);
- vcpi->port = port;
- list_add(&vcpi->next, &topology_state->vcpis);
+ payload->port = port;
+ list_add(&payload->next, &topology_state->payloads);
}
- vcpi->vcpi = req_slots;
- vcpi->pbn = pbn;
+ payload->vcpi = req_slots;
+ payload->pbn = pbn;
return req_slots;
}
@@ -4464,21 +4464,21 @@ int drm_dp_atomic_release_vcpi_slots(struct
drm_atomic_state *state,
struct drm_dp_mst_port *port)
{
struct drm_dp_mst_topology_state *topology_state;
- struct drm_dp_vcpi_allocation *pos;
+ struct drm_dp_mst_atomic_payload *pos;
bool found = false;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
- list_for_each_entry(pos, &topology_state->vcpis, next) {
+ list_for_each_entry(pos, &topology_state->payloads, next) {
if (pos->port == port) {
found = true;
break;
}
}
if (WARN_ON(!found)) {
- drm_err(mgr->dev, "no VCPI for [MST PORT:%p] found in mst state
%p\n",
+ drm_err(mgr->dev, "No payload for [MST PORT:%p] found in mst
state %p\n",
port, &topology_state->base);
return -EINVAL;
}
@@ -5060,7 +5060,7 @@ drm_dp_mst_duplicate_state(struct drm_private_obj *obj)
{
struct drm_dp_mst_topology_state *state, *old_state =
to_dp_mst_topology_state(obj->state);
- struct drm_dp_vcpi_allocation *pos, *vcpi;
+ struct drm_dp_mst_atomic_payload *pos, *payload;
state = kmemdup(old_state, sizeof(*state), GFP_KERNEL);
if (!state)
@@ -5068,25 +5068,25 @@ drm_dp_mst_duplicate_state(struct
[RFC v2 00/18] drm/display/dp_mst: Drop Radeon MST support, make MST atomic-only
For quite a while we've been carrying around a lot of legacy modesetting code in the MST helpers that has been rather annoying to keep around, and very often gets in the way of trying to implement additional functionality in MST such as fallback link rate retraining, dynamic BPC management and DSC support, etc. because of the fact that we can't rely on atomic for everything. Luckily, we only actually have one user of the legacy MST code in the kernel - radeon. Originally I was thinking of trying to maintain this code and keep it around in some form, but I'm pretty unconvinced anyone is actually using this. My reasoning for that is because I've seen nearly no issues regarding MST on radeon for quite a while now - despite the fact my local testing seems to indicate it's quite broken. This isn't too surprising either, as MST support in radeon.ko is gated behind a module parameter that isn't enabled by default. This isn't to say I wouldn't be open to alternative suggestions, but I'd rather not be the one to have to spend time on that if at all possible! Plus, I already floated the idea of dropping this code by AMD folks a few times and didn't get much resistance. As well, this series has some basic refactoring that I did along the way and some bugs I had to fix in order to get my atomic-only MST code working. Most of this is pretty straight forward and simply renaming things to more closely match the DisplayPort specification, as I think this will also make maintaining this code a lot easier in the long run (I've gotten myself confused way too many times because of this). So far I've tested this on all three MST drivers: amdgpu, i915 and nouveau, along with making sure that removing the radeon MST code doesn't break anything else. The one thing I very much could use help with regarding testing though is making sure that this works with amdgpu's DSC support on MST. So, with this we should be using the atomic state as much as possible with MST modesetting, hooray! Cc: Wayne Lin Cc: Ville Syrjälä Cc: Fangzhi Zuo Cc: Jani Nikula Cc: Imre Deak Cc: Daniel Vetter Cc: Sean Paul Lyude Paul (18): drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table) drm/amdgpu/dm/mst: Rename get_payload_table() drm/display/dp_mst: Rename drm_dp_mst_vcpi_allocation drm/display/dp_mst: Call them time slots, not VCPI slots drm/display/dp_mst: Fix confusing docs for drm_dp_atomic_release_time_slots() drm/display/dp_mst: Add some missing kdocs for atomic MST structs drm/display/dp_mst: Add helper for finding payloads in atomic MST state drm/display/dp_mst: Add nonblocking helpers for DP MST drm/display/dp_mst: Don't open code modeset checks for releasing time slots drm/display/dp_mst: Fix modeset tracking in drm_dp_atomic_release_vcpi_slots() drm/nouveau/kms: Cache DP encoders in nouveau_connector drm/nouveau/kms: Pull mst state in for all modesets drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions drm/display/dp_mst: Drop all ports from topology on CSNs before queueing link address work drm/display/dp_mst: Skip releasing payloads if last connected port isn't connected drm/display/dp_mst: Maintain time slot allocations when deleting payloads drm/radeon: Drop legacy MST support drm/display/dp_mst: Move all payload info into the atomic state .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 68 +- .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 108 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 125 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 10 +- drivers/gpu/drm/amd/display/dc/dm_helpers.h |4 +- .../amd/display/include/link_service_types.h | 14 +- drivers/gpu/drm/display/drm_dp_mst_topology.c | 1154 - drivers/gpu/drm/i915/display/intel_display.c |6 + drivers/gpu/drm/i915/display/intel_dp.c |9 + drivers/gpu/drm/i915/display/intel_dp_mst.c | 91 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 24 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 197 ++- drivers/gpu/drm/nouveau/dispnv50/disp.h |2 + drivers/gpu/drm/nouveau/nouveau_connector.c | 18 +- drivers/gpu/drm/nouveau/nouveau_connector.h |3 + drivers/gpu/drm/radeon/Makefile |2 +- drivers/gpu/drm/radeon/atombios_crtc.c| 11 +- drivers/gpu/drm/radeon/atombios_encoders.c| 59 - drivers/gpu/drm/radeon/radeon_atombios.c |2 - drivers/gpu/drm/radeon/radeon_connectors.c| 61 +- drivers/gpu/drm/radeon/radeon_device.c|1 - drivers/gpu/drm/radeon/radeon_dp_mst.c| 778 --- drivers/gpu/drm/radeon/radeon_drv.c |4 - drivers/gpu/drm/radeon/radeon_encoders.c | 14 +- drivers/gpu/drm/radeon/radeon_irq_kms.c | 10 +- drivers/gpu/drm/radeon/radeon_mode.h | 40 - include/drm/display/drm_dp_mst_help
[RFC v2 04/18] drm/display/dp_mst: Call them time slots, not VCPI slots
VCPI is only sort of the correct term here, originally the majority of this
code simply referred to timeslots vaguely as "slots" - and since I started
working on it and adding atomic functionality, the name "VCPI slots" has
been used to represent time slots.
Now that we actually have consistent access to the DisplayPort spec thanks
to VESA, I now know this isn't actually the proper term - as the
specification refers to these as time slots.
Since we're trying to make this code as easy to figure out as possible,
let's take this opportunity to correct this nomenclature and call them by
their proper name - timeslots. Likewise, we rename various functions
appropriately, along with replacing references in the kernel documentation
and various debugging messages.
It's important to note that this patch series leaves the legacy MST code
untouched for the most part, which is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.
v2:
* Add note that Wayne Lin from AMD suggested regarding slots being between
the source DP Tx and the immediate downstream DP Rx
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 28 ++---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 106 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +-
include/drm/display/drm_dp_mst_helper.h | 12 +-
6 files changed, 81 insertions(+), 76 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 8a3e25d35099..34f0d2f056bb 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6428,7 +6428,7 @@ static int dm_encoder_helper_atomic_check(struct
drm_encoder *encoder,
clock = adjusted_mode->clock;
dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp,
false);
}
- dm_new_connector_state->vcpi_slots =
drm_dp_atomic_find_vcpi_slots(state,
+ dm_new_connector_state->vcpi_slots =
drm_dp_atomic_find_time_slots(state,
mst_mgr,
mst_port,
dm_new_connector_state->pbn,
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 2e74ccf7df5b..655d63b20b33 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
@@ -472,7 +472,7 @@ static int dm_dp_mst_atomic_check(struct drm_connector
*connector,
return 0;
}
- return drm_dp_atomic_release_vcpi_slots(state,
+ return drm_dp_atomic_release_time_slots(state,
mst_mgr,
mst_port);
}
@@ -785,7 +785,7 @@ static bool increase_dsc_bpp(struct drm_atomic_state *state,
if (initial_slack[next_index] > fair_pbn_alloc) {
vars[next_index].pbn += fair_pbn_alloc;
- if (drm_dp_atomic_find_vcpi_slots(state,
+ if (drm_dp_atomic_find_time_slots(state,
params[next_index].port->mgr,
params[next_index].port,
vars[next_index].pbn,
@@ -795,7 +795,7 @@ static bool increase_dsc_bpp(struct drm_atomic_state *state,
vars[next_index].bpp_x16 =
bpp_x16_from_pbn(params[next_index], vars[next_index].pbn);
} else {
vars[next_index].pbn -= fair_pbn_alloc;
- if (drm_dp_atomic_find_vcpi_slots(state,
+ if (drm_dp_atomic_find_time_slots(state,
params[next_index].port->mgr,
params[next_index].port,
vars[next_index].pbn,
@@ -804,7 +804,7 @@ static bool increase_dsc_bpp(struct drm_atomic_state *state,
}
} else {
vars[next_index].pbn += initial_slack[next_index];
- if (drm_dp_atomic_find_vcpi_slots(s
[RFC v2 07/18] drm/display/dp_mst: Add helper for finding payloads in atomic MST state
We already open-code this quite often, and will be iterating through
payloads even more once we've moved all of the payload tracking into the
atomic state. So, let's add a helper for doing this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 109 --
1 file changed, 45 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 8a2ddfde594a..1c054a5e2e77 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -1738,6 +1738,19 @@ drm_dp_mst_dump_port_topology_history(struct
drm_dp_mst_port *port) {}
#define save_port_topology_ref(port, type)
#endif
+static struct drm_dp_mst_atomic_payload *
+drm_atomic_get_mst_payload_state(struct drm_dp_mst_topology_state *state,
+struct drm_dp_mst_port *port)
+{
+ struct drm_dp_mst_atomic_payload *payload;
+
+ list_for_each_entry(payload, &state->payloads, next)
+ if (payload->port == port)
+ return payload;
+
+ return NULL;
+}
+
static void drm_dp_destroy_mst_branch_device(struct kref *kref)
{
struct drm_dp_mst_branch *mstb =
@@ -4370,39 +4383,31 @@ int drm_dp_atomic_find_time_slots(struct
drm_atomic_state *state,
int pbn_div)
{
struct drm_dp_mst_topology_state *topology_state;
- struct drm_dp_mst_atomic_payload *pos, *payload = NULL;
- int prev_slots, prev_bw, req_slots;
+ struct drm_dp_mst_atomic_payload *payload = NULL;
+ int prev_slots = 0, prev_bw = 0, req_slots;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
/* Find the current allocation for this port, if any */
- list_for_each_entry(pos, &topology_state->payloads, next) {
- if (pos->port == port) {
- payload = pos;
- prev_slots = payload->time_slots;
- prev_bw = payload->pbn;
-
- /*
-* This should never happen, unless the driver tries
-* releasing and allocating the same timeslot
allocation,
-* which is an error
-*/
- if (WARN_ON(!prev_slots)) {
- drm_err(mgr->dev,
- "cannot allocate and release time slots
on [MST PORT:%p] in the same state\n",
- port);
- return -EINVAL;
- }
+ payload = drm_atomic_get_mst_payload_state(topology_state, port);
+ if (payload) {
+ prev_slots = payload->time_slots;
+ prev_bw = payload->pbn;
- break;
+ /*
+* This should never happen, unless the driver tries
+* releasing and allocating the same timeslot allocation,
+* which is an error
+*/
+ if (WARN_ON(!prev_slots)) {
+ drm_err(mgr->dev,
+ "cannot allocate and release time slots on [MST
PORT:%p] in the same state\n",
+ port);
+ return -EINVAL;
}
}
- if (!payload) {
- prev_slots = 0;
- prev_bw = 0;
- }
if (pbn_div <= 0)
pbn_div = mgr->pbn_div;
@@ -4463,30 +4468,24 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
struct drm_dp_mst_port *port)
{
struct drm_dp_mst_topology_state *topology_state;
- struct drm_dp_mst_atomic_payload *pos;
- bool found = false;
+ struct drm_dp_mst_atomic_payload *payload;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
- list_for_each_entry(pos, &topology_state->payloads, next) {
- if (pos->port == port) {
- found = true;
- break;
- }
- }
- if (WARN_ON(!found)) {
+ payload = drm_atomic_get_mst_payload_state(topology_state, port);
+ if (WARN_ON(!payload)) {
drm_err(mgr->dev, "No payload for [MST PORT:%p] found in mst
state %p\n",
port, &topology_state->base);
return -EINVAL;
}
- drm
[RFC v2 05/18] drm/display/dp_mst: Fix confusing docs for drm_dp_atomic_release_time_slots()
For some reason we mention returning 0 if "slots have been added back to drm_dp_mst_topology_state->avail_slots". This is totally misleading, avail_slots is simply for figuring out the total number of slots available in total on the topology and has no relation to the current payload allocations. So, let's get rid of that comment. Signed-off-by: Lyude Paul Cc: Wayne Lin Cc: Ville Syrjälä Cc: Fangzhi Zuo Cc: Jani Nikula Cc: Imre Deak Cc: Daniel Vetter Cc: Sean Paul Acked-by: Jani Nikula --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c index fad80ab2b9db..8a2ddfde594a 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c @@ -4456,8 +4456,7 @@ EXPORT_SYMBOL(drm_dp_atomic_find_time_slots); * drm_dp_mst_atomic_check() * * Returns: - * 0 if all slots for this port were added back to - * &drm_dp_mst_topology_state.avail_slots or negative error code + * 0 on success, negative error code otherwise */ int drm_dp_atomic_release_time_slots(struct drm_atomic_state *state, struct drm_dp_mst_topology_mgr *mgr, -- 2.37.1
[RFC v2 06/18] drm/display/dp_mst: Add some missing kdocs for atomic MST structs
Since we're about to start adding some stuff here, we may as well fill in
any missing documentation that we forgot to write.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
include/drm/display/drm_dp_mst_helper.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index 9cdd2def56a1..3b155ad3eee4 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -542,7 +542,14 @@ struct drm_dp_payload {
#define to_dp_mst_topology_state(x) container_of(x, struct
drm_dp_mst_topology_state, base)
+/**
+ * struct drm_dp_mst_atomic_payload - Atomic state struct for an MST payload
+ *
+ * The primary atomic state structure for a given MST payload. Stores
information like current
+ * bandwidth allocation, intended action for this payload, etc.
+ */
struct drm_dp_mst_atomic_payload {
+ /** @port: The MST port assigned to this payload */
struct drm_dp_mst_port *port;
/**
@@ -551,16 +558,32 @@ struct drm_dp_mst_atomic_payload {
* the immediate downstream DP Rx
*/
int time_slots;
+ /** @pbn: The payload bandwidth for this payload */
int pbn;
+ /** @dsc_enabled: Whether or not this payload has DSC enabled */
bool dsc_enabled;
+
+ /** @next: The list node for this payload */
struct list_head next;
};
+/**
+ * struct drm_dp_mst_topology_state - DisplayPort MST topology atomic state
+ *
+ * This struct represents the atomic state of the toplevel DisplayPort MST
manager
+ */
struct drm_dp_mst_topology_state {
+ /** @base: Base private state for atomic */
struct drm_private_state base;
+
+ /** @payloads: The list of payloads being created/destroyed in this
state */
struct list_head payloads;
+ /** @mgr: The topology manager */
struct drm_dp_mst_topology_mgr *mgr;
+
+ /** @total_avail_slots: The total number of slots this topology can
handle (63 or 64) */
u8 total_avail_slots;
+ /** @start_slot: The first usable time slot in this topology (1 or 0) */
u8 start_slot;
};
--
2.37.1
[RFC v2 08/18] drm/display/dp_mst: Add nonblocking helpers for DP MST
As Daniel Vetter pointed out, if we only use the atomic modesetting locks
with MST it's technically possible for a driver with non-blocking modesets
to race when it comes to MST displays - as we make the mistake of not doing
our own CRTC commit tracking in the topology_state object.
This could potentially cause problems if something like this happens:
* User starts non-blocking commit to disable CRTC-1 on MST topology 1
* User starts non-blocking commit to enable CRTC-2 on MST topology 1
There's no guarantee here that the commit for disabling CRTC-2 will only
occur after CRTC-1 has finished, since neither commit shares a CRTC - only
the private modesetting object for MST. Keep in mind this likely isn't a
problem for blocking modesets, only non-blocking.
So, begin fixing this by keeping track of which CRTCs on a topology have
changed by keeping track of which CRTCs we release or allocate timeslots
on. As well, add some helpers for:
* Setting up the drm_crtc_commit structs in the ->commit_setup hook
* Waiting for any CRTC dependencies from the previous topology state
v2:
* Use drm_dp_mst_atomic_setup_commit() directly - Jani
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +-
drivers/gpu/drm/display/drm_dp_mst_topology.c | 93 +++
drivers/gpu/drm/i915/display/intel_display.c | 6 ++
drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 ++
include/drm/display/drm_dp_mst_helper.h | 15 +++
5 files changed, 124 insertions(+), 2 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 34f0d2f056bb..1739710003a4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2808,7 +2808,8 @@ static const struct drm_mode_config_funcs
amdgpu_dm_mode_funcs = {
};
static struct drm_mode_config_helper_funcs amdgpu_dm_mode_config_helperfuncs =
{
- .atomic_commit_tail = amdgpu_dm_atomic_commit_tail
+ .atomic_commit_tail = amdgpu_dm_atomic_commit_tail,
+ .atomic_commit_setup = drm_dp_mst_atomic_setup_commit,
};
static void update_connector_ext_caps(struct amdgpu_dm_connector *aconnector)
@@ -7986,6 +7987,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
DRM_ERROR("Waiting for fences timed out!");
drm_atomic_helper_update_legacy_modeset_state(dev, state);
+ drm_dp_mst_atomic_wait_for_dependencies(state);
dm_state = dm_atomic_get_new_state(state);
if (dm_state && dm_state->context) {
@@ -8384,7 +8386,6 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
dc_release_state(dc_state_temp);
}
-
static int dm_force_atomic_commit(struct drm_connector *connector)
{
int ret = 0;
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 1c054a5e2e77..d701e5b819b8 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4384,12 +4384,16 @@ int drm_dp_atomic_find_time_slots(struct
drm_atomic_state *state,
{
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_mst_atomic_payload *payload = NULL;
+ struct drm_connector_state *conn_state;
int prev_slots = 0, prev_bw = 0, req_slots;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
+ conn_state = drm_atomic_get_new_connector_state(state, port->connector);
+ topology_state->pending_crtc_mask |= drm_crtc_mask(conn_state->crtc);
+
/* Find the current allocation for this port, if any */
payload = drm_atomic_get_mst_payload_state(topology_state, port);
if (payload) {
@@ -4469,11 +4473,15 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
{
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_mst_atomic_payload *payload;
+ struct drm_connector_state *conn_state;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
+ conn_state = drm_atomic_get_old_connector_state(state, port->connector);
+ topology_state->pending_crtc_mask |= drm_crtc_mask(conn_state->crtc);
+
payload = drm_atomic_get_mst_payload_state(topology_state, port);
if (WARN_ON(!payload)) {
drm_err(mgr->dev, "No payload for [MST PORT:%p] found in mst
state %p\n",
@@ -4492,6 +4500,83 @@ int drm_dp_atomic_release_time_slots(struct
drm_a
[RFC v2 11/18] drm/nouveau/kms: Cache DP encoders in nouveau_connector
Post-NV50, the only kind of encoder you'll find for DP connectors on Nvidia
GPUs are SORs (serial output resources). Because SORs have fixed
associations with their connectors, we can correctly assume that any DP
connector on a nvidia GPU will have exactly one SOR encoder routed to it
for DisplayPort.
Since we're going to need to be able to retrieve this fixed SOR DP encoder
much more often as a result of hooking up MST helpers for tracking
SST<->MST transitions in atomic states, let's simply cache this encoder in
nouveau_connector for any DP connectors on the system to avoid looking it
up each time. This isn't safe for NV50 since PIORs then come into play,
however there's no code pre-NV50 that would need to look this up anyhow -
so it's not really an issue.
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 4 +++-
drivers/gpu/drm/nouveau/nouveau_connector.h | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 43a9d1e1cf71..bdaec3427f14 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1367,7 +1367,7 @@ nouveau_connector_create(struct drm_device *dev,
return ERR_PTR(-ENOMEM);
}
drm_dp_aux_init(&nv_connector->aux);
- fallthrough;
+ break;
default:
funcs = &nouveau_connector_funcs;
break;
@@ -1430,6 +1430,8 @@ nouveau_connector_create(struct drm_device *dev,
switch (type) {
case DRM_MODE_CONNECTOR_DisplayPort:
+ nv_connector->dp_encoder = find_encoder(&nv_connector->base,
DCB_OUTPUT_DP);
+ fallthrough;
case DRM_MODE_CONNECTOR_eDP:
drm_dp_cec_register_connector(&nv_connector->aux, connector);
break;
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index 4bf0c703eee7..f4e17ff68bf9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -128,6 +128,9 @@ struct nouveau_connector {
struct drm_dp_aux aux;
+ /* The fixed DP encoder for this connector, if there is one */
+ struct nouveau_encoder *dp_encoder;
+
int dithering_mode;
int scaling_mode;
--
2.37.1
[RFC v2 10/18] drm/display/dp_mst: Fix modeset tracking in drm_dp_atomic_release_vcpi_slots()
Currently with the MST helpers we avoid releasing payloads _and_ avoid
pulling in the MST state if there aren't any actual payload changes. While
we want to keep the first step, we need to now make sure that we're always
pulling in the MST state on all modesets that can modify payloads - even if
the resulting payloads in the atomic state are identical to the previous
ones.
This is mainly to make it so that if a CRTC is still assigned to a
connector but is set to DPMS off, the CRTC still holds it's payload
allocation in the atomic state and still appropriately pulls in the MST
state for commit tracking. Otherwise, we'll occasionally forget to update
MST payloads from changes caused by non-atomic DPMS changes. Doing this
also allows us to track bandwidth limitations in a state correctly even
between DPMS changes, so that there's no chance of a simple ->active change
being rejected by the atomic check.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index aa6dcd9ff6a5..2f7c43f88d74 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4474,6 +4474,7 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_mst_atomic_payload *payload;
struct drm_connector_state *old_conn_state, *new_conn_state;
+ bool update_payload = true;
old_conn_state = drm_atomic_get_old_connector_state(state,
port->connector);
if (!old_conn_state->crtc)
@@ -4485,10 +4486,12 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
struct drm_crtc_state *crtc_state =
drm_atomic_get_new_crtc_state(state,
new_conn_state->crtc);
- if (!crtc_state ||
- !drm_atomic_crtc_needs_modeset(crtc_state) ||
- crtc_state->enable)
+ /* No modeset means no payload changes, so it's safe to not
pull in the MST state */
+ if (!crtc_state || !drm_atomic_crtc_needs_modeset(crtc_state))
return 0;
+
+ if (!crtc_state->mode_changed &&
!crtc_state->connectors_changed)
+ update_payload = false;
}
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
@@ -4496,6 +4499,8 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
return PTR_ERR(topology_state);
topology_state->pending_crtc_mask |=
drm_crtc_mask(old_conn_state->crtc);
+ if (!update_payload)
+ return 0;
payload = drm_atomic_get_mst_payload_state(topology_state, port);
if (WARN_ON(!payload)) {
--
2.37.1
[RFC v2 09/18] drm/display/dp_mst: Don't open code modeset checks for releasing time slots
I'm not sure why, but at the time I originally wrote the find/release time
slot helpers I thought we should avoid keeping modeset tracking out of the
MST helpers. In retrospect though there's no actual good reason to do
this, and the logic has ended up being identical across all the drivers
using the helpers. Also, it needs to be fixed anyway so we don't break
things when going atomic-only with MST.
So, let's just move this code into drm_dp_atomic_release_time_slots() and
stop open coding it.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 29 +++
drivers/gpu/drm/display/drm_dp_mst_topology.c | 21 --
drivers/gpu/drm/i915/display/intel_dp_mst.c | 24 +--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 21 --
4 files changed, 23 insertions(+), 72 deletions(-)
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 655d63b20b33..7a0d6cfa77f5 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
@@ -447,34 +447,13 @@ dm_dp_mst_detect(struct drm_connector *connector,
}
static int dm_dp_mst_atomic_check(struct drm_connector *connector,
- struct drm_atomic_state *state)
+ struct drm_atomic_state *state)
{
- struct drm_connector_state *new_conn_state =
- drm_atomic_get_new_connector_state(state, connector);
- struct drm_connector_state *old_conn_state =
- drm_atomic_get_old_connector_state(state, connector);
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
- struct drm_crtc_state *new_crtc_state;
- struct drm_dp_mst_topology_mgr *mst_mgr;
- struct drm_dp_mst_port *mst_port;
+ struct drm_dp_mst_topology_mgr *mst_mgr =
&aconnector->mst_port->mst_mgr;
+ struct drm_dp_mst_port *mst_port = aconnector->port;
- mst_port = aconnector->port;
- mst_mgr = &aconnector->mst_port->mst_mgr;
-
- if (!old_conn_state->crtc)
- return 0;
-
- if (new_conn_state->crtc) {
- new_crtc_state = drm_atomic_get_new_crtc_state(state,
new_conn_state->crtc);
- if (!new_crtc_state ||
- !drm_atomic_crtc_needs_modeset(new_crtc_state) ||
- new_crtc_state->enable)
- return 0;
- }
-
- return drm_dp_atomic_release_time_slots(state,
- mst_mgr,
- mst_port);
+ return drm_dp_atomic_release_time_slots(state, mst_mgr, mst_port);
}
static const struct drm_connector_helper_funcs
dm_dp_mst_connector_helper_funcs = {
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index d701e5b819b8..aa6dcd9ff6a5 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4473,14 +4473,29 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
{
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_mst_atomic_payload *payload;
- struct drm_connector_state *conn_state;
+ struct drm_connector_state *old_conn_state, *new_conn_state;
+
+ old_conn_state = drm_atomic_get_old_connector_state(state,
port->connector);
+ if (!old_conn_state->crtc)
+ return 0;
+
+ /* If the CRTC isn't disabled by this state, don't release it's payload
*/
+ new_conn_state = drm_atomic_get_new_connector_state(state,
port->connector);
+ if (new_conn_state->crtc) {
+ struct drm_crtc_state *crtc_state =
+ drm_atomic_get_new_crtc_state(state,
new_conn_state->crtc);
+
+ if (!crtc_state ||
+ !drm_atomic_crtc_needs_modeset(crtc_state) ||
+ crtc_state->enable)
+ return 0;
+ }
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
- conn_state = drm_atomic_get_old_connector_state(state, port->connector);
- topology_state->pending_crtc_mask |= drm_crtc_mask(conn_state->crtc);
+ topology_state->pending_crtc_mask |=
drm_crtc_mask(old_conn_state->crtc);
payload = drm_atomic_get_mst_payload_state(topology_state, port);
if (WARN_ON(!payload)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/
[RFC v2 12/18] drm/nouveau/kms: Pull mst state in for all modesets
Since we're going to be relying on atomic locking for payloads now (and the MST mgr needs to track CRTCs), pull in the topology state for all modesets in nv50_msto_atomic_check(). Signed-off-by: Lyude Paul Acked-by: Jani Nikula --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index 5669c8d747d7..24807aa9da5f 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -1049,7 +1049,7 @@ nv50_msto_atomic_check(struct drm_encoder *encoder, if (ret) return ret; - if (!crtc_state->mode_changed && !crtc_state->connectors_changed) + if (!drm_atomic_crtc_needs_modeset(crtc_state)) return 0; /* -- 2.37.1
[RFC v2 13/18] drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions
There's another kind of situation where we could potentially race with
nonblocking modesets and MST, especially if we were to only use the locking
provided by atomic modesetting:
* Display 1 begins as enabled on DP-1 in SST mode
* Display 1 switches to MST mode, exposes one sink in MST mode
* Userspace does non-blocking modeset to disable the SST display
* Userspace does non-blocking modeset to enable the MST display with a
different CRTC, but the SST display hasn't been fully taken down yet
* Execution order between the last two commits isn't guaranteed since they
share no drm resources
We can fix this however, by ensuring that we always pull in the atomic
topology state whenever a connector capable of driving an MST display
performs its atomic check - and then tracking CRTC commits happening on the
SST connector in the MST topology state. So, let's add some simple helpers
for doing that and hook them up in various drivers.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
drivers/gpu/drm/display/drm_dp_mst_topology.c | 59 +++
drivers/gpu/drm/i915/display/intel_dp.c | 9 +++
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 14 +
include/drm/display/drm_dp_mst_helper.h | 2 +
7 files changed, 94 insertions(+), 1 deletion(-)
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 1739710003a4..51732bd603a9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6318,10 +6318,17 @@ amdgpu_dm_connector_atomic_check(struct drm_connector
*conn,
drm_atomic_get_old_connector_state(state, conn);
struct drm_crtc *crtc = new_con_state->crtc;
struct drm_crtc_state *new_crtc_state;
+ struct amdgpu_dm_connector *aconn = to_amdgpu_dm_connector(conn);
int ret;
trace_amdgpu_dm_connector_atomic_check(new_con_state);
+ if (conn->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ ret = drm_dp_mst_root_conn_atomic_check(new_con_state,
&aconn->mst_mgr);
+ if (ret < 0)
+ return ret;
+ }
+
if (!crtc)
return 0;
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 2f7c43f88d74..97e8f8a83ed4 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4597,6 +4597,65 @@ void drm_dp_mst_atomic_wait_for_dependencies(struct
drm_atomic_state *state)
}
EXPORT_SYMBOL(drm_dp_mst_atomic_wait_for_dependencies);
+/**
+ * drm_dp_mst_root_conn_atomic_check() - Serialize CRTC commits on MST-capable
connectors operating
+ * in SST mode
+ * @new_conn_state: The new connector state of the &drm_connector
+ * @mgr: The MST topology manager for the &drm_connector
+ *
+ * Since MST uses fake &drm_encoder structs, the generic atomic modesetting
code isn't able to
+ * serialize non-blocking commits happening on the real DP connector of an MST
topology switching
+ * into/away from MST mode - as the CRTC on the real DP connector and the
CRTCs on the connector's
+ * MST topology will never share the same &drm_encoder.
+ *
+ * This function takes care of this serialization issue, by checking a root
MST connector's atomic
+ * state to determine if it is about to have a modeset - and then pulling in
the MST topology state
+ * if so, along with adding any relevant CRTCs to
&drm_dp_mst_topology_state.pending_crtc_mask.
+ *
+ * Drivers implementing MST must call this function from the
+ * &drm_connector_helper_funcs.atomic_check hook of any physical DP
&drm_connector capable of
+ * driving MST sinks.
+ *
+ * Returns:
+ * 0 on success, negative error code otherwise
+ */
+int drm_dp_mst_root_conn_atomic_check(struct drm_connector_state
*new_conn_state,
+ struct drm_dp_mst_topology_mgr *mgr)
+{
+ struct drm_atomic_state *state = new_conn_state->state;
+ struct drm_connector_state *old_conn_state =
+ drm_atomic_get_old_connector_state(state,
new_conn_state->connector);
+ struct drm_crtc_state *crtc_state;
+ struct drm_dp_mst_topology_state *mst_state = NULL;
+
+ if (new_conn_state->crtc) {
+ crtc_state = drm_atomic_get_new_crtc_state(state,
new_conn_state->crtc);
+ if (crtc_state && drm_atomic_crtc_needs_modeset(crtc_state)) {
+ mst_state = drm_atomic_get_mst_topology_state(state,
mgr);
+
[RFC v2 14/18] drm/display/dp_mst: Drop all ports from topology on CSNs before queueing link address work
We want to start cutting down on all of the places that we use port
validation, so that ports may be removed from the topology as quickly as
possible to minimize the number of errors we run into as a result of being
out of sync with the current topology status. This isn't a very typical
scenario and I don't think I've ever even run into it - but since the next
commit is going to make some changes to payload updates depending on their
hotplug status I think it's a probably good idea to take precautions.
Let's do this with CSNs by moving some code around so that we only queue
link address probing work at the end of handling all CSNs - allowing us to
make sure we drop as many topology references as we can beforehand.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 97e8f8a83ed4..a5460cadf2c8 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -2509,7 +2509,7 @@ drm_dp_mst_handle_link_address_port(struct
drm_dp_mst_branch *mstb,
return ret;
}
-static void
+static int
drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch *mstb,
struct drm_dp_connection_status_notify *conn_stat)
{
@@ -2522,7 +2522,7 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch
*mstb,
port = drm_dp_get_port(mstb, conn_stat->port_number);
if (!port)
- return;
+ return 0;
if (port->connector) {
if (!port->input && conn_stat->input_port) {
@@ -2575,8 +2575,7 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch
*mstb,
out:
drm_dp_mst_topology_put_port(port);
- if (dowork)
- queue_work(system_long_wq, &mstb->mgr->work);
+ return dowork;
}
static struct drm_dp_mst_branch *drm_dp_get_mst_branch_device(struct
drm_dp_mst_topology_mgr *mgr,
@@ -4060,7 +4059,7 @@ drm_dp_mst_process_up_req(struct drm_dp_mst_topology_mgr
*mgr,
struct drm_dp_mst_branch *mstb = NULL;
struct drm_dp_sideband_msg_req_body *msg = &up_req->msg;
struct drm_dp_sideband_msg_hdr *hdr = &up_req->hdr;
- bool hotplug = false;
+ bool hotplug = false, dowork = false;
if (hdr->broadcast) {
const u8 *guid = NULL;
@@ -4083,11 +4082,14 @@ drm_dp_mst_process_up_req(struct
drm_dp_mst_topology_mgr *mgr,
/* TODO: Add missing handler for DP_RESOURCE_STATUS_NOTIFY events */
if (msg->req_type == DP_CONNECTION_STATUS_NOTIFY) {
- drm_dp_mst_handle_conn_stat(mstb, &msg->u.conn_stat);
+ dowork = drm_dp_mst_handle_conn_stat(mstb, &msg->u.conn_stat);
hotplug = true;
}
drm_dp_mst_topology_put_mstb(mstb);
+
+ if (dowork)
+ queue_work(system_long_wq, &mgr->work);
return hotplug;
}
--
2.37.1
[RFC v2 15/18] drm/display/dp_mst: Skip releasing payloads if last connected port isn't connected
In the past, we've ran into strange issues regarding errors in response to
trying to destroy payloads after a port has been unplugged. We fixed this
back in:
This is intended to replace the workaround that was added here:
commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports in
stale topology")
which was intended fix to some of the payload leaks that were observed
before, where we would attempt to determine if the port was still connected
to the topology before updating payloads using
drm_dp_mst_port_downstream_of_branch. This wasn't a particularly good
solution, since one of the points of still having port and mstb validation
is to avoid sending messages to newly disconnected branches wherever
possible - thus the required use of drm_dp_mst_port_downstream_of_branch
would indicate something may be wrong with said validation.
It seems like it may have just been races and luck that made
drm_dp_mst_port_downstream_of_branch work however, as while I was trying to
figure out the true cause of this issue when removing the legacy MST code -
I discovered an important excerpt in section 2.14.2.3.3.6 of the DP 2.0
specs:
"BAD_PARAM - This reply is transmitted when a Message Transaction parameter
is in error; for example, the next port number is invalid or /no device is
connected/ to the port associated with the port number."
Sure enough - removing the calls to drm_dp_mst_port_downstream_of_branch()
and instead checking the ->ddps field of the parent port to see whether we
should release a given payload or not seems to totally fix the issue. This
does actually make sense to me, as it seems the implication is that given a
topology where an MSTB is removed, the payload for the MST parent's port
will be released automatically if that port is also marked as disconnected.
However, if there's another parent in the chain after that which is
connected - payloads must be released there with an ALLOCATE_PAYLOAD
message.
So, let's do that!
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 51 +++
1 file changed, 17 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index a5460cadf2c8..e9cf09a4b2a4 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3128,7 +3128,7 @@ static struct drm_dp_mst_port
*drm_dp_get_last_connected_port_to_mstb(struct drm
static struct drm_dp_mst_branch *
drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_branch *mstb,
- int *port_num)
+ struct drm_dp_mst_port **last_port)
{
struct drm_dp_mst_branch *rmstb = NULL;
struct drm_dp_mst_port *found_port;
@@ -3144,7 +3144,8 @@ drm_dp_get_last_connected_port_and_mstb(struct
drm_dp_mst_topology_mgr *mgr,
if (drm_dp_mst_topology_try_get_mstb(found_port->parent)) {
rmstb = found_port->parent;
- *port_num = found_port->port_num;
+ *last_port = found_port;
+ drm_dp_mst_get_port_malloc(found_port);
} else {
/* Search again, starting from this parent */
mstb = found_port->parent;
@@ -3161,7 +3162,7 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
int pbn)
{
struct drm_dp_sideband_msg_tx *txmsg;
- struct drm_dp_mst_branch *mstb;
+ struct drm_dp_mst_branch *mstb = NULL;
int ret, port_num;
u8 sinks[DRM_DP_MAX_SDP_STREAMS];
int i;
@@ -3169,12 +3170,22 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
port_num = port->port_num;
mstb = drm_dp_mst_topology_get_mstb_validated(mgr, port->parent);
if (!mstb) {
- mstb = drm_dp_get_last_connected_port_and_mstb(mgr,
- port->parent,
- &port_num);
+ struct drm_dp_mst_port *rport = NULL;
+ bool ddps;
+ mstb = drm_dp_get_last_connected_port_and_mstb(mgr,
port->parent, &rport);
if (!mstb)
return -EINVAL;
+
+ ddps = rport->ddps;
+ port_num = rport->port_num;
+ drm_dp_mst_put_port_malloc(rport);
+
+ /* If the port is currently marked as disconnected, don't send
a payload message */
+
[RFC v2 16/18] drm/display/dp_mst: Maintain time slot allocations when deleting payloads
Currently, we set drm_dp_atomic_payload->time_slots to 0 in order to
indicate that we're about to delete a payload in the current atomic state.
Since we're going to be dropping all of the legacy code for handling the
payload table however, we need to be able to ensure that we still keep
track of the current time slot allocations for each payload so we can reuse
this info when asking the root MST hub to delete payloads. We'll also be
using it to recalculate the start slots of each VC.
So, let's keep track of the intent of a payload in drm_dp_atomic_payload by
adding ->delete, which we set whenever we're planning on deleting a payload
during the current atomic commit.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 14 +++---
include/drm/display/drm_dp_mst_helper.h | 5 -
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index e9cf09a4b2a4..3fce1ed8d5e8 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4399,7 +4399,7 @@ int drm_dp_atomic_find_time_slots(struct drm_atomic_state
*state,
* releasing and allocating the same timeslot allocation,
* which is an error
*/
- if (WARN_ON(!prev_slots)) {
+ if (drm_WARN_ON(mgr->dev, payload->delete)) {
drm_err(mgr->dev,
"cannot allocate and release time slots on [MST
PORT:%p] in the same state\n",
port);
@@ -4504,10 +4504,10 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
}
drm_dbg_atomic(mgr->dev, "[MST PORT:%p] TU %d -> 0\n", port,
payload->time_slots);
- if (payload->time_slots) {
+ if (!payload->delete) {
drm_dp_mst_put_port_malloc(port);
- payload->time_slots = 0;
payload->pbn = 0;
+ payload->delete = true;
}
return 0;
@@ -5222,7 +5222,7 @@ drm_dp_mst_duplicate_state(struct drm_private_obj *obj)
list_for_each_entry(pos, &old_state->payloads, next) {
/* Prune leftover freed timeslot allocations */
- if (!pos->time_slots)
+ if (pos->delete)
continue;
payload = kmemdup(pos, sizeof(*payload), GFP_KERNEL);
@@ -5254,8 +5254,8 @@ static void drm_dp_mst_destroy_state(struct
drm_private_obj *obj,
int i;
list_for_each_entry_safe(pos, tmp, &mst_state->payloads, next) {
- /* We only keep references to ports with non-zero VCPIs */
- if (pos->time_slots)
+ /* We only keep references to ports with active payloads */
+ if (!pos->delete)
drm_dp_mst_put_port_malloc(pos->port);
kfree(pos);
}
@@ -5383,7 +5383,7 @@ drm_dp_mst_atomic_check_payload_alloc_limits(struct
drm_dp_mst_topology_mgr *mgr
list_for_each_entry(payload, &mst_state->payloads, next) {
/* Releasing payloads is always OK-even if the port is gone */
- if (!payload->time_slots) {
+ if (payload->delete) {
drm_dbg_atomic(mgr->dev, "[MST PORT:%p] releases all
time slots\n",
payload->port);
continue;
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index b9c361b242ea..8b847836a0b4 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -560,8 +560,11 @@ struct drm_dp_mst_atomic_payload {
int time_slots;
/** @pbn: The payload bandwidth for this payload */
int pbn;
+
+ /** @delete: Whether or not we intend to delete this payload during
this atomic commit */
+ bool delete : 1;
/** @dsc_enabled: Whether or not this payload has DSC enabled */
- bool dsc_enabled;
+ bool dsc_enabled : 1;
/** @next: The list node for this payload */
struct list_head next;
--
2.37.1
[RFC v2 17/18] drm/radeon: Drop legacy MST support
Right now, radeon is technically the only non-atomic driver still making
use of the MST helpers - and thus the final user of all of the legacy MST
helpers. Originally I was going to look into seeing if we could move legacy
MST into the radeon driver itself, however:
* SI and CIK both can use amdgpu, which still supports MST
* It currently doesn't work according to my own testing. I'm sure with some
troubleshooting we could likely fix it, but that brings me to point #2:
* It was never actually enabled by default, and is still marked as
experimental in the module parameter description
* If people were using it, someone probably would have probably seen a bug
report about how it is currently not functional by now. That certainly
doesn't appear to be the case, since before getting access to my own
hardware I had to go out of my way to try finding someone to help test
whether this legacy MST code even works - even amongst AMD employees.
* Getting rid of this code and only having atomic versions of the MST
helpers to maintain is likely going to be a lot easier in the long run,
and will make it a lot easier for others contributing to this code to
follow along with what's happening.
FWIW - if anyone still wants this code to be in the tree and has a good
idea of how to support this without needing to maintain the legacy MST
helpers (trying to move them would probably be acceptable), I'm happy to
suggestions. But my hope is that we can just drop this code and forget
about it. I've already run this idea by Harry Wentland and Alex Deucher a
few times as well.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Alex Deucher
Acked-by: Jani Nikula
---
drivers/gpu/drm/radeon/Makefile| 2 +-
drivers/gpu/drm/radeon/atombios_crtc.c | 11 +-
drivers/gpu/drm/radeon/atombios_encoders.c | 59 --
drivers/gpu/drm/radeon/radeon_atombios.c | 2 -
drivers/gpu/drm/radeon/radeon_connectors.c | 61 +-
drivers/gpu/drm/radeon/radeon_device.c | 1 -
drivers/gpu/drm/radeon/radeon_dp_mst.c | 778 -
drivers/gpu/drm/radeon/radeon_drv.c| 4 -
drivers/gpu/drm/radeon/radeon_encoders.c | 14 +-
drivers/gpu/drm/radeon/radeon_irq_kms.c| 10 +-
drivers/gpu/drm/radeon/radeon_mode.h | 40 --
11 files changed, 7 insertions(+), 975 deletions(-)
delete mode 100644 drivers/gpu/drm/radeon/radeon_dp_mst.c
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index e3ab3aca1396..bb4e56f2f170 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -49,7 +49,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o \
- radeon_sync.o radeon_audio.o radeon_dp_auxch.o radeon_dp_mst.o
+ radeon_sync.o radeon_audio.o radeon_dp_auxch.o
radeon-$(CONFIG_MMU_NOTIFIER) += radeon_mn.o
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 69f1bc073902..d28d3acb3ba1 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -617,13 +617,6 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
}
}
- if (radeon_encoder->is_mst_encoder) {
- struct radeon_encoder_mst *mst_enc = radeon_encoder->enc_priv;
- struct radeon_connector_atom_dig *dig_connector =
mst_enc->connector->con_priv;
-
- dp_clock = dig_connector->dp_clock;
- }
-
/* use recommended ref_div for ss */
if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
if (radeon_crtc->ss_enabled) {
@@ -972,9 +965,7 @@ static bool atombios_crtc_prepare_pll(struct drm_crtc
*crtc, struct drm_display_
radeon_crtc->bpc = 8;
radeon_crtc->ss_enabled = false;
- if (radeon_encoder->is_mst_encoder) {
- radeon_dp_mst_prepare_pll(crtc, mode);
- } else if ((radeon_encoder->active_device & (ATOM_DEVICE_LCD_SUPPORT |
ATOM_DEVICE_DFP_SUPPORT)) ||
+ if ((radeon_encoder->active_device & (ATOM_DEVICE_LCD_SUPPORT |
ATOM_DEVICE_DFP_SUPPORT)) ||
(radeon_encoder_get_dp_bridge_encoder_id(radeon_crtc->encoder) !=
ENCODER_OBJECT_ID_NONE)) {
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
struct drm_connector *connector =
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index c93040e60d04..0eae05dfb385 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_e
[RFC v2 18/18] drm/display/dp_mst: Move all payload info into the atomic state
Now that we've finally gotten rid of the non-atomic MST users leftover in the kernel, we can finally get rid of all of the legacy payload code we have and move as much as possible into the MST atomic state structs. The main purpose of this is to make the MST code a lot less confusing to work on, as there's a lot of duplicated logic that doesn't really need to be here. As well, this should make introducing features like fallback link retraining and DSC support far easier. Since the old payload code was pretty gnarly and there's a Lot of changes here, I expect this might be a bit difficult to review. So to make things as easy as possible for reviewers, I'll sum up how both the old and new code worked here (it took me a while to figure this out too!). The old MST code basically worked by maintaining two different payload tables - proposed_vcpis, and payloads. proposed_vcpis would hold the modified payload we wanted to push to the topology, while payloads held the payload table that was currently programmed in hardware. Modifications to proposed_vcpis would be handled through drm_dp_allocate_vcpi(), drm_dp_mst_deallocate_vcpi(), and drm_dp_mst_reset_vcpi_slots(). Then, they would be pushed via drm_dp_mst_update_payload_step1() and drm_dp_mst_update_payload_step2(). Furthermore, it's important to note how adding and removing VC payloads actually worked with drm_dp_mst_update_payload_step1(). When a VC payload is removed from the VC table, all VC payloads which come after the removed VC payload's slots must have their time slots shifted towards the start of the table. The old code handles this by looping through the entire payload table and recomputing the start slot for every payload in the topology from scratch. While very much overkill, this ends up doing the right thing because we always order the VCPIs for payloads from first to last starting timeslot. It's important to also note that drm_dp_mst_update_payload_step2() isn't actually limited to updating a single payload - the driver can use it to queue up multiple payload changes so that as many of them can be sent as possible before waiting for the ACT. This is -technically- not against spec, but as Wayne Lin has pointed out it's not consistently implemented correctly in hubs - so it might as well be. drm_dp_mst_update_payload_step2() is pretty self explanatory and basically the same between the old and new code, save for the fact we don't have a second step for deleting payloads anymore -and thus rename it to drm_dp_mst_add_payload_step2(). The new payload code stores all of the current payload info within the MST atomic state and computes as much of the state as possible ahead of time. This has the one exception of the starting timeslots for payloads, which can't be determined at atomic check time since the starting time slots will vary depending on what order CRTCs are enabled in the atomic state - which varies from driver to driver. These are still stored in the atomic MST state, but are only copied from the old MST state during atomic commit time. Likewise, this is when new start slots are determined. Adding/removing payloads now works much more closely to how things are described in the spec. When we delete a payload, we loop through the current list of payloads and update the start slots for any payloads whose time slots came after the payload we just deleted. Determining the starting time slots for new payloads being added is done by simply keeping track of where the end of the VC table is in drm_dp_mst_topology_mgr->next_start_slot. Additionally, it's worth noting that we no longer have a single update_payload() function. Instead, we now have drm_dp_mst_add_payload_step1|2() and drm_dp_mst_remove_payload(). As such, it's now left it up to the driver to figure out when to add or remove payloads. The driver already knows when it's disabling/enabling CRTCs, so it also already knows when payloads should be added or removed. Changes since v1: * Refactor around all of the completely dead code changes that are happening in amdgpu for some reason when they really shouldn't even be there in the first place… :\ * Remove mention of sending one ACT per series of payload updates. As Wayne Lin pointed out, there are apparently hubs on the market that don't work correctly with this scheme and require a separate ACT per payload update. * Fix accidental drop of mst_mgr.lock - Wayne Lin * Remove mentions of allowing multiple ACT updates per payload change, mention that this is a result of vendors not consistently supporting this part of the spec and requiring a unique ACT for each payload change. * Get rid of reference to drm_dp_mst_port in DC - turns out I just got myself confused by DC and we don't actually need this. Signed-off-by: Lyude Paul Cc: Wayne Lin Cc: Ville Syrjälä Cc: Fangzhi Zuo Cc: Jani Nikula Cc: Imre Deak Cc: Daniel Vetter C
Re: [PATCH v2 1/3] drm/dp_mst: add passthrough_aux to struct drm_dp_mst_port
Ah yes of course! Probably should have asked when I gave the r-b :). Also,
just so patchwork actually catches it I will say the magic incantation:
Reviewed-by: Lyude Paul
Do we want to merge just this patch to drm-misc-next, or do you want to merge
the whole series through there? If you'd rather just merge this through amd's
branch I'm fine with that as well
On Tue, 2022-08-09 at 11:15 -0400, Hamza Mahfooz wrote:
> Hey Lyude,
>
> On 2022-08-05 17:17, Lyude Paul wrote:
> > lgtm!
> >
>
> Any chance you can apply this to drm-misc-next?
>
> > Reviewed-by: Lyude Paul
> >
> > On Fri, 2022-08-05 at 17:13 -0400, Hamza Mahfooz wrote:
> > > Currently, there is no way to identify if DSC pass-through can be
> > > enabled and what aux DSC pass-through requests ought to be sent to. So,
> > > add a variable to struct drm_dp_mst_port that keeps track of the
> > > aforementioned information.
> > >
> > > Signed-off-by: Hamza Mahfooz
> > > ---
> > > v2: define DP_DSC_PASSTHROUGH_IS_SUPPORTED
> > > ---
> > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +++-
> > > include/drm/display/drm_dp.h | 1 +
> > > include/drm/display/drm_dp_mst_helper.h | 3 +++
> > > 3 files changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > index 67b3b9697da7..71915afd9892 100644
> > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > @@ -5921,8 +5921,10 @@ struct drm_dp_aux
> > > *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port *port)
> > > /* Enpoint decompression with DP-to-DP peer device */
> > > if ((endpoint_dsc & DP_DSC_DECOMPRESSION_IS_SUPPORTED)
> > > &&
> > > (endpoint_fec & DP_FEC_CAPABLE) &&
> > > - (upstream_dsc & 0x2) /* DSC passthrough */)
> > > + (upstream_dsc & DP_DSC_PASSTHROUGH_IS_SUPPORTED)) {
> > > + port->passthrough_aux = &immediate_upstream_port->aux;
> > > return &port->aux;
> > > + }
> > >
> > > /* Virtual DPCD decompression with DP-to-DP peer device
> > > */
> > > return &immediate_upstream_port->aux;
> > > diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
> > > index 9e3aff7e68bb..4d0abe4c7ea9 100644
> > > --- a/include/drm/display/drm_dp.h
> > > +++ b/include/drm/display/drm_dp.h
> > > @@ -239,6 +239,7 @@
> > >
> > > #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */
> > > # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0)
> > > +# define DP_DSC_PASSTHROUGH_IS_SUPPORTED(1 << 1)
> > >
> > > #define DP_DSC_REV 0x061
> > > # define DP_DSC_MAJOR_MASK (0xf << 0)
> > > diff --git a/include/drm/display/drm_dp_mst_helper.h
> > > b/include/drm/display/drm_dp_mst_helper.h
> > > index 10adec068b7f..4a39c95f8afd 100644
> > > --- a/include/drm/display/drm_dp_mst_helper.h
> > > +++ b/include/drm/display/drm_dp_mst_helper.h
> > > @@ -86,6 +86,8 @@ struct drm_dp_vcpi {
> > >* @next: link to next port on this branch device
> > >* @aux: i2c aux transport to talk to device connected to this port,
> > > protected
> > >* by &drm_dp_mst_topology_mgr.base.lock.
> > > + * @passthrough_aux: parent aux to which DSC pass-through requests
> > > should be
> > > + * sent, only set if DSC pass-through is possible.
> > >* @parent: branch device parent of this port
> > >* @vcpi: Virtual Channel Payload info for this port.
> > >* @connector: DRM connector this port is connected to. Protected by
> > > @@ -140,6 +142,7 @@ struct drm_dp_mst_port {
> > >*/
> > > struct drm_dp_mst_branch *mstb;
> > > struct drm_dp_aux aux; /* i2c bus for this port? */
> > > + struct drm_dp_aux *passthrough_aux;
> > > struct drm_dp_mst_branch *parent;
> > >
> > > struct drm_dp_vcpi vcpi;
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
[RFC v3] drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions
There's another kind of situation where we could potentially race with
nonblocking modesets and MST, especially if we were to only use the locking
provided by atomic modesetting:
* Display 1 begins as enabled on DP-1 in SST mode
* Display 1 switches to MST mode, exposes one sink in MST mode
* Userspace does non-blocking modeset to disable the SST display
* Userspace does non-blocking modeset to enable the MST display with a
different CRTC, but the SST display hasn't been fully taken down yet
* Execution order between the last two commits isn't guaranteed since they
share no drm resources
We can fix this however, by ensuring that we always pull in the atomic
topology state whenever a connector capable of driving an MST display
performs its atomic check - and then tracking CRTC commits happening on the
SST connector in the MST topology state. So, let's add some simple helpers
for doing that and hook them up in various drivers.
v2:
* Use intel_dp_mst_source_support() to check for MST support in i915, fixes
CI failures
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
drivers/gpu/drm/display/drm_dp_mst_topology.c | 59 +++
drivers/gpu/drm/i915/display/intel_dp.c | 9 +++
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 14 +
include/drm/display/drm_dp_mst_helper.h | 2 +
7 files changed, 94 insertions(+), 1 deletion(-)
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 1739710003a4..51732bd603a9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6318,10 +6318,17 @@ amdgpu_dm_connector_atomic_check(struct drm_connector
*conn,
drm_atomic_get_old_connector_state(state, conn);
struct drm_crtc *crtc = new_con_state->crtc;
struct drm_crtc_state *new_crtc_state;
+ struct amdgpu_dm_connector *aconn = to_amdgpu_dm_connector(conn);
int ret;
trace_amdgpu_dm_connector_atomic_check(new_con_state);
+ if (conn->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ ret = drm_dp_mst_root_conn_atomic_check(new_con_state,
&aconn->mst_mgr);
+ if (ret < 0)
+ return ret;
+ }
+
if (!crtc)
return 0;
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 2f7c43f88d74..97e8f8a83ed4 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4597,6 +4597,65 @@ void drm_dp_mst_atomic_wait_for_dependencies(struct
drm_atomic_state *state)
}
EXPORT_SYMBOL(drm_dp_mst_atomic_wait_for_dependencies);
+/**
+ * drm_dp_mst_root_conn_atomic_check() - Serialize CRTC commits on MST-capable
connectors operating
+ * in SST mode
+ * @new_conn_state: The new connector state of the &drm_connector
+ * @mgr: The MST topology manager for the &drm_connector
+ *
+ * Since MST uses fake &drm_encoder structs, the generic atomic modesetting
code isn't able to
+ * serialize non-blocking commits happening on the real DP connector of an MST
topology switching
+ * into/away from MST mode - as the CRTC on the real DP connector and the
CRTCs on the connector's
+ * MST topology will never share the same &drm_encoder.
+ *
+ * This function takes care of this serialization issue, by checking a root
MST connector's atomic
+ * state to determine if it is about to have a modeset - and then pulling in
the MST topology state
+ * if so, along with adding any relevant CRTCs to
&drm_dp_mst_topology_state.pending_crtc_mask.
+ *
+ * Drivers implementing MST must call this function from the
+ * &drm_connector_helper_funcs.atomic_check hook of any physical DP
&drm_connector capable of
+ * driving MST sinks.
+ *
+ * Returns:
+ * 0 on success, negative error code otherwise
+ */
+int drm_dp_mst_root_conn_atomic_check(struct drm_connector_state
*new_conn_state,
+ struct drm_dp_mst_topology_mgr *mgr)
+{
+ struct drm_atomic_state *state = new_conn_state->state;
+ struct drm_connector_state *old_conn_state =
+ drm_atomic_get_old_connector_state(state,
new_conn_state->connector);
+ struct drm_crtc_state *crtc_state;
+ struct drm_dp_mst_topology_state *mst_state = NULL;
+
+ if (new_conn_state->crtc) {
+ crtc_state = drm_atomic_get_new_crtc_state(state,
new_conn_state->crtc);
+ if (crtc_state && drm_atomic_crtc_needs_modeset(crtc_state)) {
+
Re: [PATCH v2 1/3] drm/dp_mst: add passthrough_aux to struct drm_dp_mst_port
On Wed, 2022-08-10 at 09:23 -0400, Hamza Mahfooz wrote:
> On 2022-08-09 18:01, Lyude Paul wrote:
> > Ah yes of course! Probably should have asked when I gave the r-b :). Also,
> > just so patchwork actually catches it I will say the magic incantation:
> >
> > Reviewed-by: Lyude Paul
> >
> > Do we want to merge just this patch to drm-misc-next, or do you want to
> > merge
> > the whole series through there? If you'd rather just merge this through
> > amd's
> > branch I'm fine with that as well
>
> In that case, it is preferable to have all of the patches in this series
> to get merged through amd's branch.\
Sounds totally fine to me! Just make sure to run it by Harry or another amdgpu
maintainer first, and then you should be good to go.
>
> >
> > On Tue, 2022-08-09 at 11:15 -0400, Hamza Mahfooz wrote:
> > > Hey Lyude,
> > >
> > > On 2022-08-05 17:17, Lyude Paul wrote:
> > > > lgtm!
> > > >
> > >
> > > Any chance you can apply this to drm-misc-next?
> > >
> > > > Reviewed-by: Lyude Paul
> > > >
> > > > On Fri, 2022-08-05 at 17:13 -0400, Hamza Mahfooz wrote:
> > > > > Currently, there is no way to identify if DSC pass-through can be
> > > > > enabled and what aux DSC pass-through requests ought to be sent to.
> > > > > So,
> > > > > add a variable to struct drm_dp_mst_port that keeps track of the
> > > > > aforementioned information.
> > > > >
> > > > > Signed-off-by: Hamza Mahfooz
> > > > > ---
> > > > > v2: define DP_DSC_PASSTHROUGH_IS_SUPPORTED
> > > > > ---
> > > > >drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +++-
> > > > >include/drm/display/drm_dp.h | 1 +
> > > > >include/drm/display/drm_dp_mst_helper.h | 3 +++
> > > > >3 files changed, 7 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > index 67b3b9697da7..71915afd9892 100644
> > > > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > @@ -5921,8 +5921,10 @@ struct drm_dp_aux
> > > > > *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port *port)
> > > > > /* Enpoint decompression with DP-to-DP peer device */
> > > > > if ((endpoint_dsc & DP_DSC_DECOMPRESSION_IS_SUPPORTED)
> > > > > &&
> > > > > (endpoint_fec & DP_FEC_CAPABLE) &&
> > > > > - (upstream_dsc & 0x2) /* DSC passthrough */)
> > > > > + (upstream_dsc & DP_DSC_PASSTHROUGH_IS_SUPPORTED)) {
> > > > > + port->passthrough_aux =
> > > > > &immediate_upstream_port->aux;
> > > > > return &port->aux;
> > > > > + }
> > > > >
> > > > > /* Virtual DPCD decompression with DP-to-DP peer device
> > > > > */
> > > > > return &immediate_upstream_port->aux;
> > > > > diff --git a/include/drm/display/drm_dp.h
> > > > > b/include/drm/display/drm_dp.h
> > > > > index 9e3aff7e68bb..4d0abe4c7ea9 100644
> > > > > --- a/include/drm/display/drm_dp.h
> > > > > +++ b/include/drm/display/drm_dp.h
> > > > > @@ -239,6 +239,7 @@
> > > > >
> > > > >#define DP_DSC_SUPPORT 0x060 /* DP 1.4 */
> > > > ># define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0)
> > > > > +# define DP_DSC_PASSTHROUGH_IS_SUPPORTED(1 << 1)
> > > > >
> > > > >#define DP_DSC_REV 0x061
> > > > ># define DP_DSC_MAJOR_MASK (0xf << 0)
> > > > > diff --git a/include/drm/display/drm_dp_mst_helper.h
> > > > > b/include/drm/display/drm_dp_mst_helper.h
> > > > > index 10adec068b7f..4a39c95f8afd 100644
> > > > > --- a/include/drm/display/drm_dp_mst_helper.h
> > > > > +++ b/include/drm/display/drm_dp_mst_helper.h
> > > > > @@ -86,6 +86,8 @@ struct drm_dp_vcpi {
> > > > > * @next: link to next port on this branch device
> > > > > * @aux: i2c aux transport to talk to device connected to this
> > > > > port, protected
> > > > > * by &drm_dp_mst_topology_mgr.base.lock.
> > > > > + * @passthrough_aux: parent aux to which DSC pass-through requests
> > > > > should be
> > > > > + * sent, only set if DSC pass-through is possible.
> > > > > * @parent: branch device parent of this port
> > > > > * @vcpi: Virtual Channel Payload info for this port.
> > > > > * @connector: DRM connector this port is connected to. Protected
> > > > > by
> > > > > @@ -140,6 +142,7 @@ struct drm_dp_mst_port {
> > > > >*/
> > > > > struct drm_dp_mst_branch *mstb;
> > > > > struct drm_dp_aux aux; /* i2c bus for this port? */
> > > > > + struct drm_dp_aux *passthrough_aux;
> > > > > struct drm_dp_mst_branch *parent;
> > > > >
> > > > > struct drm_dp_vcpi vcpi;
> > > >
> > >
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing payloads if last connected port isn't connected
and the in-memory topology still can be referred for stale > connection status before payload deallocation completes, i.e. which will put > malloc krefcount to eventually destroy disconnected devices in topology > in-memory. > I mean, ideally, sounds like the topology in-memory should be reliable when > we send ALLOCATE_PAYLOAD as PBN=0. But I understand it definitely is not the > case if we have krefcount leak. mhm, I think you made me realize I'm overthinking this a bit now that I've seen the excerpt you mentioned above, along with the other excerpt about only the end devices being involved. The main reason I originally foresaw an issue with this is because the delay with updating the in-memory topology structure might put us slightly out of sync with the state of the hub on the other end - causing the hub to spit out an error. However - based on the excerpts you mentioned I think what I was seeing was mainly just the 2 second timeout causing things to be released properly - not specific behavior based on the location in the topology of the branch that was just unplugged like I originally assumed. I think in that case it probably does make more sense to go with your fix, so I'll likely drop this and rework the topology checks you had into this. > > Appreciate for your time and help Lyude! > no, thank you for your help! :) There aren't a whole ton of people who are this involved with MST so it's very useful to finally have another pair of eyes looking at all of this. > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
[RFC v4 02/17] drm/amdgpu/dm/mst: Rename get_payload_table()
This function isn't too confusing if you see the comment around the
call-site for it, but if you don't then it's not at all obvious this is
meant to copy DRM's payload table over to DC's internal state structs.
Seeing this function before finding that comment definitely threw me into a
loop a few times.
So, let's rename this to make it's purpose more obvious regardless of where
in the code you are.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 3aa385860eea..77c545e670d5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -153,8 +153,9 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
return result;
}
-static void get_payload_table(struct amdgpu_dm_connector *aconnector,
- struct dc_dp_mst_stream_allocation_table
*proposed_table)
+static void
+fill_dc_mst_payload_table_from_drm(struct amdgpu_dm_connector *aconnector,
+ struct dc_dp_mst_stream_allocation_table
*proposed_table)
{
int i;
struct drm_dp_mst_topology_mgr *mst_mgr =
@@ -252,7 +253,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
* stream. AMD ASIC stream slot allocation should follow the same
* sequence. copy DRM MST allocation to dc */
- get_payload_table(aconnector, proposed_table);
+ fill_dc_mst_payload_table_from_drm(aconnector, proposed_table);
return true;
}
--
2.37.1
[RFC v4 00/17] drm/display/dp_mst: Drop Radeon MST support, make MST atomic-only
For quite a while we've been carrying around a lot of legacy modesetting code in the MST helpers that has been rather annoying to keep around, and very often gets in the way of trying to implement additional functionality in MST such as fallback link rate retraining, dynamic BPC management and DSC support, etc. because of the fact that we can't rely on atomic for everything. Luckily, we only actually have one user of the legacy MST code in the kernel - radeon. Originally I was thinking of trying to maintain this code and keep it around in some form, but I'm pretty unconvinced anyone is actually using this. My reasoning for that is because I've seen nearly no issues regarding MST on radeon for quite a while now - despite the fact my local testing seems to indicate it's quite broken. This isn't too surprising either, as MST support in radeon.ko is gated behind a module parameter that isn't enabled by default. This isn't to say I wouldn't be open to alternative suggestions, but I'd rather not be the one to have to spend time on that if at all possible! Plus, I already floated the idea of dropping this code by AMD folks a few times and didn't get much resistance. As well, this series has some basic refactoring that I did along the way and some bugs I had to fix in order to get my atomic-only MST code working. Most of this is pretty straight forward and simply renaming things to more closely match the DisplayPort specification, as I think this will also make maintaining this code a lot easier in the long run (I've gotten myself confused way too many times because of this). So far I've tested this on all three MST drivers: amdgpu, i915 and nouveau, along with making sure that removing the radeon MST code doesn't break anything else. The one thing I very much could use help with regarding testing though is making sure that this works with amdgpu's DSC support on MST. So, with this we should be using the atomic state as much as possible with MST modesetting, hooray! V4: * Get rid of fix that Wayne pointed out isn't needed Cc: Wayne Lin Cc: Ville Syrjälä Cc: Fangzhi Zuo Cc: Jani Nikula Cc: Imre Deak Cc: Daniel Vetter Cc: Sean Paul Lyude Paul (17): drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table) drm/amdgpu/dm/mst: Rename get_payload_table() drm/display/dp_mst: Rename drm_dp_mst_vcpi_allocation drm/display/dp_mst: Call them time slots, not VCPI slots drm/display/dp_mst: Fix confusing docs for drm_dp_atomic_release_time_slots() drm/display/dp_mst: Add some missing kdocs for atomic MST structs drm/display/dp_mst: Add helper for finding payloads in atomic MST state drm/display/dp_mst: Add nonblocking helpers for DP MST drm/display/dp_mst: Don't open code modeset checks for releasing time slots drm/display/dp_mst: Fix modeset tracking in drm_dp_atomic_release_vcpi_slots() drm/nouveau/kms: Cache DP encoders in nouveau_connector drm/nouveau/kms: Pull mst state in for all modesets drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions drm/display/dp_mst: Drop all ports from topology on CSNs before queueing link address work drm/display/dp_mst: Maintain time slot allocations when deleting payloads drm/radeon: Drop legacy MST support drm/display/dp_mst: Move all payload info into the atomic state .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 68 +- .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 108 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 125 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 10 +- drivers/gpu/drm/amd/display/dc/dm_helpers.h |4 +- .../amd/display/include/link_service_types.h | 14 +- drivers/gpu/drm/display/drm_dp_mst_topology.c | 1137 - drivers/gpu/drm/i915/display/intel_display.c |6 + drivers/gpu/drm/i915/display/intel_dp.c |9 + drivers/gpu/drm/i915/display/intel_dp_mst.c | 91 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 24 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 197 ++- drivers/gpu/drm/nouveau/dispnv50/disp.h |2 + drivers/gpu/drm/nouveau/nouveau_connector.c | 18 +- drivers/gpu/drm/nouveau/nouveau_connector.h |3 + drivers/gpu/drm/radeon/Makefile |2 +- drivers/gpu/drm/radeon/atombios_crtc.c| 11 +- drivers/gpu/drm/radeon/atombios_encoders.c| 59 - drivers/gpu/drm/radeon/radeon_atombios.c |2 - drivers/gpu/drm/radeon/radeon_connectors.c| 61 +- drivers/gpu/drm/radeon/radeon_device.c|1 - drivers/gpu/drm/radeon/radeon_dp_mst.c| 778 --- drivers/gpu/drm/radeon/radeon_drv.c |4 - drivers/gpu/drm/radeon/radeon_encoders.c | 14 +- drivers/gpu/drm/radeon/radeon_irq_kms.c | 10 +- drivers/gpu/drm/radeon/radeon_mode.h | 40 - include/drm/display/drm_dp_mst_helper.h | 234 ++-- 27 fil
[RFC v4 01/17] drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table)
Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 9 -
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 10 +-
drivers/gpu/drm/amd/display/dc/dm_helpers.h | 4 ++--
.../gpu/drm/amd/display/include/link_service_types.h | 11 ---
4 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index a0154a5f7183..3aa385860eea 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -153,9 +153,8 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
return result;
}
-static void get_payload_table(
- struct amdgpu_dm_connector *aconnector,
- struct dp_mst_stream_allocation_table *proposed_table)
+static void get_payload_table(struct amdgpu_dm_connector *aconnector,
+ struct dc_dp_mst_stream_allocation_table
*proposed_table)
{
int i;
struct drm_dp_mst_topology_mgr *mst_mgr =
@@ -177,7 +176,7 @@ static void get_payload_table(
mst_mgr->payloads[i].payload_state ==
DP_PAYLOAD_REMOTE) {
- struct dp_mst_stream_allocation *sa =
+ struct dc_dp_mst_stream_allocation *sa =
&proposed_table->stream_allocations[
proposed_table->stream_count];
@@ -201,7 +200,7 @@ void dm_helpers_dp_update_branch_info(
bool dm_helpers_dp_mst_write_payload_allocation_table(
struct dc_context *ctx,
const struct dc_stream_state *stream,
- struct dp_mst_stream_allocation_table *proposed_table,
+ struct dc_dp_mst_stream_allocation_table *proposed_table,
bool enable)
{
struct amdgpu_dm_connector *aconnector;
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 9e51338441d0..e01424fb02ba 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3516,7 +3516,7 @@ static void update_mst_stream_alloc_table(
struct dc_link *link,
struct stream_encoder *stream_enc,
struct hpo_dp_stream_encoder *hpo_dp_stream_enc, // TODO: Rename
stream_enc to dio_stream_enc?
- const struct dp_mst_stream_allocation_table *proposed_table)
+ const struct dc_dp_mst_stream_allocation_table *proposed_table)
{
struct link_mst_stream_allocation work_table[MAX_CONTROLLER_NUM] = { 0
};
struct link_mst_stream_allocation *dc_alloc;
@@ -3679,7 +3679,7 @@ enum dc_status dc_link_allocate_mst_payload(struct
pipe_ctx *pipe_ctx)
{
struct dc_stream_state *stream = pipe_ctx->stream;
struct dc_link *link = stream->link;
- struct dp_mst_stream_allocation_table proposed_table = {0};
+ struct dc_dp_mst_stream_allocation_table proposed_table = {0};
struct fixed31_32 avg_time_slots_per_mtp;
struct fixed31_32 pbn;
struct fixed31_32 pbn_per_slot;
@@ -3784,7 +3784,7 @@ enum dc_status dc_link_reduce_mst_payload(struct pipe_ctx
*pipe_ctx, uint32_t bw
struct fixed31_32 avg_time_slots_per_mtp;
struct fixed31_32 pbn;
struct fixed31_32 pbn_per_slot;
- struct dp_mst_stream_allocation_table proposed_table = {0};
+ struct dc_dp_mst_stream_allocation_table proposed_table = {0};
uint8_t i;
const struct link_hwss *link_hwss = get_link_hwss(link,
&pipe_ctx->link_res);
DC_LOGGER_INIT(link->ctx->logger);
@@ -3873,7 +3873,7 @@ enum dc_status dc_link_increase_mst_payload(struct
pipe_ctx *pipe_ctx, uint32_t
struct fixed31_32 avg_time_slots_per_mtp;
struct fixed31_32 pbn;
struct fixed31_32 pbn_per_slot;
- struct dp_mst_stream_allocation_table proposed_table = {0};
+ struct dc_dp_mst_stream_allocation_table proposed_table = {0};
uint8_t i;
enum act_return_status ret;
const struct link_hwss *link_hwss = get_link_hwss(link,
&pipe_ctx->link_res);
@@ -3957,7 +3957,7 @@ static enum dc_status deallocate_mst_payload(struct
pipe_ctx *pipe_ctx)
{
struct dc_stream_state *stream = pipe_ctx->stream;
struct dc_link *link = stream->link;
- struct dp_mst_stream_allocation_table proposed_table = {0};
+ struct dc_dp_mst_stream_allocation_table proposed_table = {0};
struct fixed31_32 avg_time_slots_per_mtp = dc_fixpt_from_int(0);
