Recently we added generic "edp-panel"s probed by EDID. To support
panels in this way we look at the panel ID in the EDID and look up the
panel in a table that has power sequence timings. If we find a panel
that's not in the table we will still attempt to use it but we'll use
conservative timings. While it's likely that these conservative
timings will work for most nearly all panels, the performance of
turning the panel off and on suffers.
We'd like to be able to reliably detect the case that we're using the
hardcoded timings without relying on parsing dmesg. This allows us to
implement tests that ensure that no devices get shipped that are
relying on the conservative timings.
Let's add a new sysfs entry to panel devices. It will have one of:
* UNKNOWN - We tried to detect a panel but it wasn't in our table.
* HARDCODED - We're not using generic "edp-panel" probed by EDID.
* A panel name - This is the name of the panel from our table.
Signed-off-by: Douglas Anderson <[email protected]>
---
drivers/gpu/drm/panel/panel-edp.c | 39 +++++++++++++++++++++++++++----
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
index 99ca1bd0091c..719c1bb6c45c 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -222,6 +222,8 @@ struct panel_edp {
struct gpio_desc *enable_gpio;
struct gpio_desc *hpd_gpio;
+ const struct edp_panel_entry *detected_panel;
+
struct edid *edid;
struct drm_display_mode override_mode;
@@ -666,7 +668,6 @@ static const struct edp_panel_entry *find_edp_panel(u32 panel_id);
static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel)
{
- const struct edp_panel_entry *edp_panel;
struct panel_desc *desc;
u32 panel_id;
char vend[4];
@@ -705,14 +706,14 @@ static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel)
}
drm_edid_decode_panel_id(panel_id, vend, &product_id);
- edp_panel = find_edp_panel(panel_id);
+ panel->detected_panel = find_edp_panel(panel_id);
/*
* We're using non-optimized timings and want it really obvious that
* someone needs to add an entry to the table, so we'll do a WARN_ON
* splat.
*/
- if (WARN_ON(!edp_panel)) {
+ if (WARN_ON(!panel->detected_panel)) {
dev_warn(dev,
"Unknown panel %s %#06x, using conservative timings\n",
vend, product_id);
@@ -734,12 +735,14 @@ static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel)
*/
desc->delay.unprepare = 2000;
desc->delay.enable = 200;
+
+ panel->detected_panel = ERR_PTR(-EINVAL);
} else {
dev_info(dev, "Detected %s %s (%#06x)\n",
- vend, edp_panel->name, product_id);
+ vend, panel->detected_panel->name, product_id);
/* Update the delay; everything else comes from EDID */
- desc->delay = *edp_panel->delay;
+ desc->delay = *panel->detected_panel->delay;
}
ret = 0;
@@ -750,6 +753,28 @@ static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel)
return ret;
}
+static ssize_t detected_panel_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct panel_edp *p = dev_get_drvdata(dev);
+
+ if (IS_ERR(p->detected_panel))
+ return sysfs_emit(buf, "UNKNOWN\n");
+ else if (!p->detected_panel)
+ return sysfs_emit(buf, "HARDCODED\n");
+ else
+ return sysfs_emit(buf, "%s\n", p->detected_panel->name);
+}
+
+static const DEVICE_ATTR_RO(detected_panel);
+
+static void edp_panel_remove_detected_panel(void *data)
+{
+ struct panel_edp *p = data;
+
+ device_remove_file(p->base.dev, &dev_attr_detected_panel);
+}
+
static int panel_edp_probe(struct device *dev, const struct panel_desc *desc,
struct drm_dp_aux *aux)
{
@@ -849,6 +874,10 @@ static int panel_edp_probe(struct device *dev, const struct panel_desc *desc,
drm_panel_add(&panel->base);
+ err = device_create_file(dev, &dev_attr_detected_panel);
+ if (!err)
+ devm_add_action_or_reset(dev, edp_panel_remove_detected_panel, panel);
+
return 0;
err_finished_pm_runtime:
--
2.35.0.rc0.227.g00780c9af4-goog
Hello Doug,
On 1/25/22 22:54, Douglas Anderson wrote:
> Recently we added generic "edp-panel"s probed by EDID. To support
> panels in this way we look at the panel ID in the EDID and look up the
> panel in a table that has power sequence timings. If we find a panel
> that's not in the table we will still attempt to use it but we'll use
> conservative timings. While it's likely that these conservative
> timings will work for most nearly all panels, the performance of
> turning the panel off and on suffers.
>
> We'd like to be able to reliably detect the case that we're using the
> hardcoded timings without relying on parsing dmesg. This allows us to
> implement tests that ensure that no devices get shipped that are
> relying on the conservative timings.
>
> Let's add a new sysfs entry to panel devices. It will have one of:
> * UNKNOWN - We tried to detect a panel but it wasn't in our table.
> * HARDCODED - We're not using generic "edp-panel" probed by EDID.
> * A panel name - This is the name of the panel from our table.
>
> Signed-off-by: Douglas Anderson <[email protected]>
> ---
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas <[email protected]>
Should this new sysfs entry be documented in Documentation/ABI/ ?
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hi,
On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas
<[email protected]> wrote:
>
> Hello Doug,
>
> On 1/25/22 22:54, Douglas Anderson wrote:
> > Recently we added generic "edp-panel"s probed by EDID. To support
> > panels in this way we look at the panel ID in the EDID and look up the
> > panel in a table that has power sequence timings. If we find a panel
> > that's not in the table we will still attempt to use it but we'll use
> > conservative timings. While it's likely that these conservative
> > timings will work for most nearly all panels, the performance of
> > turning the panel off and on suffers.
> >
> > We'd like to be able to reliably detect the case that we're using the
> > hardcoded timings without relying on parsing dmesg. This allows us to
> > implement tests that ensure that no devices get shipped that are
> > relying on the conservative timings.
> >
> > Let's add a new sysfs entry to panel devices. It will have one of:
> > * UNKNOWN - We tried to detect a panel but it wasn't in our table.
> > * HARDCODED - We're not using generic "edp-panel" probed by EDID.
> > * A panel name - This is the name of the panel from our table.
> >
> > Signed-off-by: Douglas Anderson <[email protected]>
> > ---
>
> Patch looks good to me.
>
> Reviewed-by: Javier Martinez Canillas <[email protected]>
Thanks!
> Should this new sysfs entry be documented in Documentation/ABI/ ?
I'm not sure what the policy is here. I actually don't know that I'm
too worried about this being an ABI. For the purposes of our tests
then if something about this file changed (path changed or something
like that) it wouldn't be a huge deal. Presumably the test itself
would just "fail" in this case and that would clue us in that the ABI
changed and we could adapt to whatever new way was needed to discover
this.
That being said, if the policy is that everything in sysfs is supposed
to be ABI then I can add documentation for this...
-Doug
On 1/26/22 00:25, Doug Anderson wrote:
> On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas
> <[email protected]> wrote:
[snip]
>> Should this new sysfs entry be documented in Documentation/ABI/ ?
>
> I'm not sure what the policy is here. I actually don't know that I'm
> too worried about this being an ABI. For the purposes of our tests
> then if something about this file changed (path changed or something
> like that) it wouldn't be a huge deal. Presumably the test itself
> would just "fail" in this case and that would clue us in that the ABI
> changed and we could adapt to whatever new way was needed to discover
> this.
>
> That being said, if the policy is that everything in sysfs is supposed
> to be ABI then I can add documentation for this...
>
I also don't know the policy, hence the question. But in any case, I
think that it could even be done as a follow-up if is needed.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hi,
On Wed, Jan 26, 2022 at 12:25 AM Javier Martinez Canillas
<[email protected]> wrote:
>
> On 1/26/22 00:25, Doug Anderson wrote:
> > On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas
> > <[email protected]> wrote:
>
> [snip]
>
> >> Should this new sysfs entry be documented in Documentation/ABI/ ?
> >
> > I'm not sure what the policy is here. I actually don't know that I'm
> > too worried about this being an ABI. For the purposes of our tests
> > then if something about this file changed (path changed or something
> > like that) it wouldn't be a huge deal. Presumably the test itself
> > would just "fail" in this case and that would clue us in that the ABI
> > changed and we could adapt to whatever new way was needed to discover
> > this.
> >
> > That being said, if the policy is that everything in sysfs is supposed
> > to be ABI then I can add documentation for this...
> >
>
> I also don't know the policy, hence the question. But in any case, I
> think that it could even be done as a follow-up if is needed.
Sounds good. Since it's been pretty silent and I had your review I
pushed this to drm-misc-next. If there are comments or someone has an
opinion documenting this as a stable ABI then please yell.
363c4c3811db drm/panel-edp: Allow querying the detected panel via sysfs
Hi,
On Tue, Feb 1, 2022 at 9:02 AM Daniel Vetter <[email protected]> wrote:
>
> On Tue, Feb 1, 2022 at 5:42 PM Doug Anderson <[email protected]> wrote:
> >
> > Hi,
> >
> > On Wed, Jan 26, 2022 at 12:25 AM Javier Martinez Canillas
> > <[email protected]> wrote:
> > >
> > > On 1/26/22 00:25, Doug Anderson wrote:
> > > > On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas
> > > > <[email protected]> wrote:
> > >
> > > [snip]
> > >
> > > >> Should this new sysfs entry be documented in Documentation/ABI/ ?
> > > >
> > > > I'm not sure what the policy is here. I actually don't know that I'm
> > > > too worried about this being an ABI. For the purposes of our tests
> > > > then if something about this file changed (path changed or something
> > > > like that) it wouldn't be a huge deal. Presumably the test itself
> > > > would just "fail" in this case and that would clue us in that the ABI
> > > > changed and we could adapt to whatever new way was needed to discover
> > > > this.
> > > >
> > > > That being said, if the policy is that everything in sysfs is supposed
> > > > to be ABI then I can add documentation for this...
> > > >
> > >
> > > I also don't know the policy, hence the question. But in any case, I
> > > think that it could even be done as a follow-up if is needed.
> >
> > Sounds good. Since it's been pretty silent and I had your review I
> > pushed this to drm-misc-next. If there are comments or someone has an
> > opinion documenting this as a stable ABI then please yell.
> >
> > 363c4c3811db drm/panel-edp: Allow querying the detected panel via sysfs
>
> Generally stuff for tests should be put into debugfs. We print
> everything there in various files.
>
> sysfs is uapi, and so come with the full baggage of you need open
> userspace (which for some sysfs stuff might just be a script), and
> explicitly not for tests (because that just opens the door to merge
> anything binary blobs might want and just slide it all in). So please
> retcon at least some plausible deniability here :-)
OK, fair enough. It really is just for a test. Let me post a revert
then while we discuss more. If someone can add a Reviewed-by to the
revert then I'll push that just so we're not in an awkward situation.
https://lore.kernel.org/r/20220201092152.1.Ibc65ec6fa05017e9856ba9ef557310268429c3ce@changeid
> But if it's really only for a test then maybe dumping this into a
> debugfs file (we do have connector directories already) would be much
> better. That doable?
I did spend a little time looking at how to do this in debugfs and it
wasn't at all obvious to me without plumbing in a lot of extra code,
but I can spend more time on it if it's a requirement. If you think
this is something that should just be easy, I certainly wouldn't say
no to a pointer to what I should look at! ;-)
-Doug
On Tue, Feb 1, 2022 at 5:42 PM Doug Anderson <[email protected]> wrote:
>
> Hi,
>
> On Wed, Jan 26, 2022 at 12:25 AM Javier Martinez Canillas
> <[email protected]> wrote:
> >
> > On 1/26/22 00:25, Doug Anderson wrote:
> > > On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas
> > > <[email protected]> wrote:
> >
> > [snip]
> >
> > >> Should this new sysfs entry be documented in Documentation/ABI/ ?
> > >
> > > I'm not sure what the policy is here. I actually don't know that I'm
> > > too worried about this being an ABI. For the purposes of our tests
> > > then if something about this file changed (path changed or something
> > > like that) it wouldn't be a huge deal. Presumably the test itself
> > > would just "fail" in this case and that would clue us in that the ABI
> > > changed and we could adapt to whatever new way was needed to discover
> > > this.
> > >
> > > That being said, if the policy is that everything in sysfs is supposed
> > > to be ABI then I can add documentation for this...
> > >
> >
> > I also don't know the policy, hence the question. But in any case, I
> > think that it could even be done as a follow-up if is needed.
>
> Sounds good. Since it's been pretty silent and I had your review I
> pushed this to drm-misc-next. If there are comments or someone has an
> opinion documenting this as a stable ABI then please yell.
>
> 363c4c3811db drm/panel-edp: Allow querying the detected panel via sysfs
Generally stuff for tests should be put into debugfs. We print
everything there in various files.
sysfs is uapi, and so come with the full baggage of you need open
userspace (which for some sysfs stuff might just be a script), and
explicitly not for tests (because that just opens the door to merge
anything binary blobs might want and just slide it all in). So please
retcon at least some plausible deniability here :-)
But if it's really only for a test then maybe dumping this into a
debugfs file (we do have connector directories already) would be much
better. That doable?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch