| Message ID | 20220125135406.1.I62322abf81dbc1a1b72392a093be0c767da9bf51@changeid (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/panel-edp: Allow querying the detected panel via sysfs | expand |
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 <dianders@chromium.org> > --- Patch looks good to me. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Should this new sysfs entry be documented in Documentation/ABI/ ? Best regards,
Hi, On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas <javierm@redhat.com> 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 <dianders@chromium.org> > > --- > > Patch looks good to me. > > Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> 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 > <javierm@redhat.com> 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,
Hi, On Wed, Jan 26, 2022 at 12:25 AM Javier Martinez Canillas <javierm@redhat.com> wrote: > > On 1/26/22 00:25, Doug Anderson wrote: > > On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas > > <javierm@redhat.com> 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
On Tue, Feb 1, 2022 at 5:42 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Wed, Jan 26, 2022 at 12:25 AM Javier Martinez Canillas > <javierm@redhat.com> wrote: > > > > On 1/26/22 00:25, Doug Anderson wrote: > > > On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas > > > <javierm@redhat.com> 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
Hi, On Tue, Feb 1, 2022 at 9:02 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Tue, Feb 1, 2022 at 5:42 PM Doug Anderson <dianders@chromium.org> wrote: > > > > Hi, > > > > On Wed, Jan 26, 2022 at 12:25 AM Javier Martinez Canillas > > <javierm@redhat.com> wrote: > > > > > > On 1/26/22 00:25, Doug Anderson wrote: > > > > On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas > > > > <javierm@redhat.com> 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
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:
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 <dianders@chromium.org> --- drivers/gpu/drm/panel/panel-edp.c | 39 +++++++++++++++++++++++++++---- 1 file changed, 34 insertions(+), 5 deletions(-)