[PATCH] drm/radeon/kms: remove useless radeon_ddc_dump()
Thomas Reim
reimth at googlemail.com
Tue Nov 1 04:23:16 PDT 2011
Dear Alex,
I think we've got the point. The users with improperly terminated i2c
busses suffered a long time from flooded logs and terminals. We solved
the problem by introducing the extended DDC probe check, which will be
according to your other patch the default for all implementations. We
reduced the log entry flood to one entry that shows that the connector
cannot be used (due to invalid EDID) plus four EDID dumps. Now the patch
here will also remove this one log entry. And we come to the point,
where there's no such information at all, as for most other users
(except of those that still use monitors with wrong EDIDs).
Believe me, we still need to get used to this "normal" driver
behaviour.
Nevertheless, I checked drm_fb_helper_initial_config() in more detail.
Whereas drm_get_edid() logs on kernel error level in case of (EDID)
problems, the to be removed function radeon_ddc_dump() adds information
on info level, the functions called by drm_fb_helper_initial_config()
stay on debug level. I switched on drm.debug and checked the logs.
You're right, most of the required information is there, but requires
drm.debug to be enabled.
The question that you also asked in your previous mail and that remains
is, how important is it to inform the users about the connector status
during driver load?
In the following you find a proposal how the (new) log could look like
after adding and modifying some logic in the
drm_fb_helper_initial_config() function:
> [ 14.912386] [drm] Radeon Display Connectors
> [ 14.912389] [drm] Connector 0:
> [ 14.912391] [drm] VGA
> [ 14.912394] [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c
> [ 14.912397] [drm] Encoders:
> [ 14.912398] [drm] CRT1: INTERNAL_KLDSCP_DAC1
> [ 14.912401] [drm] Connector 1:
> [ 14.912402] [drm] S-video
> [ 14.912404] [drm] Encoders:
> [ 14.912405] [drm] TV1: INTERNAL_KLDSCP_DAC1
> [ 14.912407] [drm] Connector 2:
> [ 14.912409] [drm] HDMI-A
> [ 14.912410] [drm] HPD2
> [ 14.912413] [drm] DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68 0x7e4c 0x7e6c
> [ 14.912415] [drm] Encoders:
> [ 14.912417] [drm] DFP2: INTERNAL_DDI
> [ 14.912419] [drm] Connector 3:
> [ 14.912421] [drm] DVI-D
> [ 14.912423] [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c
> [ 14.912425] [drm] Encoders:
> [ 14.912427] [drm] DFP3: INTERNAL_LVTM1
>
> ...
// Information that is already on debug log level changed to kernel info level
> [ 15.088976] [drm] Probing connector VGA-1 ...
> [ 15.100040] [drm] VGA-1 is disconnected
> [ 15.200048] [drm] Probing connector SVIDEO-1 ...
> [ 15.390040] [drm] SVIDEO-1 is disconnected
> [ 15.390048] [drm] Probing connector HDMI-A-1 ...
// NEW: drm_get_edid output in case of EDID problems:
> [ 15.470734] Raw EDID:
> [ 15.470745] <3>00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 ................
> [ 15.470748] <3>00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 ................
> [ 15.470751] <3>00 00 00 00 00 00 00 00 00 00 7f 00 00 00 00 00 ................
> [ 15.470754] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 15.470757] <3>00 00 00 00 1f 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 15.470760] <3>00 00 00 00 00 07 00 00 00 00 00 7f 00 00 00 00 ................
> [ 15.470762] <3>00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 ................
> [ 15.470765] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ................
> [ 15.470767]
> [ 15.779568] Raw EDID:
> [ 15.779578] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 15.779581] <3>00 00 00 00 00 7f 00 00 00 00 03 00 00 00 00 00 ................
> [ 15.779584] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 15.779587] <3>00 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 15.779590] <3>00 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00 ................
> [ 15.779593] <3>00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 ................
> [ 15.779596] <3>00 00 00 7f 00 00 00 00 00 03 07 00 00 00 00 00 ................
> [ 15.779598] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 15.779600]
> [ 16.151817] Raw EDID:
> [ 16.151827] <3>00 00 00 00 00 00 1f 00 00 00 00 00 00 00 00 00 ................
> [ 16.151830] <3>00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 ................
> [ 16.151833] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 16.151836] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 16.151839] <3>00 00 1f 00 00 00 00 00 00 00 00 00 00 00 0f 00 ................
> [ 16.151842] <3>01 00 00 00 00 00 00 00 01 00 00 00 00 07 00 ff ................
> [ 16.151844] <3>00 00 00 00 00 00 ff 00 00 00 00 00 00 00 7f 00 ................
> [ 16.151847] <3>00 0f 00 00 00 00 00 00 00 3f 00 00 00 00 00 00 .........?......
> [ 16.151849]
> [ 16.444209] Raw EDID:
> [ 16.444220] <3>00 07 00 00 00 00 00 00 ff 00 00 00 00 ff 00 00 ................
> [ 16.444223] <3>00 00 3f 00 00 00 00 00 00 00 00 00 00 ff 00 00 ..?.............
> [ 16.444226] <3>00 00 00 00 00 00 00 00 00 07 00 00 00 01 0f 00 ................
> [ 16.444229] <3>00 07 00 00 00 00 00 00 00 00 01 07 00 00 00 00 ................
> [ 16.444231] <3>00 00 00 00 00 00 00 00 7f 00 00 00 00 1f 00 00 ................
> [ 16.444234] <3>00 00 03 00 00 00 00 3f 00 03 00 00 00 00 00 00 .......?........
> [ 16.444237] <3>7f 00 00 1f 00 00 00 00 00 00 00 00 0f 07 00 00 ................
> [ 16.444240] <3>00 00 00 00 00 00 00 00 00 00 03 00 00 00 00 00 ................
> [ 16.444248] radeon 0000:01:05.0: HDMI-A-1: EDID block 0 invalid.
// Existing information on debug level, shifted to info level
> [ 16.694378] [drm] HDMI-A-1 is disconnected
> [ 16.694382] [drm] Probing connector DVI-D-1 ...
> [ 16.750763] [drm] Probed modes for DVI-D-1
// If drm.debug is enabled, mode information would follow here
> [ 16.750769] [drm:drm_mode_debug_printmodeline], Modeline 17:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48 0x5
> [ 16.750776] [drm:drm_mode_debug_printmodeline], Modeline 26:"1280x1024" 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
>
> ...
>
> [ 17.570156] [drm] fb mappable at 0xF0040000
>
Continuing from here we would have nothing in the logs, except for the
case, that we retrieve a wrong EDID with correct EDID header (0x00 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0x00).
Would this work also for other users, especially the users with eDP, DP,
or DP bridge chips?
Best regards
Thomas
Am Montag, den 31.10.2011, 11:46 -0400 schrieb Alex Deucher:
> On Mon, Oct 31, 2011 at 11:15 AM, Thomas Reim <reimth at googlemail.com> wrote:
> > Dear Alex,
> >
> > your reply confuses me:
> >
> >> On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim <reimth at googlemail.com> wrote:
> >> > Dear Alex,
> >> >
> >> > but we use DDC probing e. g. to identify connectors with improperly
> >> > terminated i2c bus. Instead of flooding logs and terminals with EDID dumps,
> >> > we decided some months ago to use this function during module loading to
> >> > inform the user once (and only once!), which connector has a monitor
> >> > connected with valid EDID and which connector has not.
> >>
> >> There's nothing in that function that actually prevents the printing
> >> of bad EDIDs.
> >
> > That's true.
> >
> >> All it does is call drm_get_edid() and report whether
> >> it found an EDID or not. radeon_dvi_detect() already takes into
> >> account the requires_extended_probe flag.
> >
> > The extended probe flag will prevent the radeon driver from further
> > useless printing of bad EDIDs every ten seconds:
>
> Yes, the extended probe check will prevent the spewing of probe
> failures, so why do we need to fetch all the edids again at load? It
> just adds latency.
>
> >
> > in radeon_connectors.c:
> > if (radeon_connector->ddc_bus)
> > dret = radeon_ddc_probe(radeon_connector,
> > radeon_connector->requires_extended_probe);
> > if (dret) {
> > if (radeon_connector->edid) {
> > kfree(radeon_connector->edid);
> > radeon_connector->edid = NULL;
> > }
> > radeon_connector->edid = drm_get_edid(&radeon_connector->base, &radeon_connector->ddc_bus->adapter);
> >
> >
> >
> >
> > But the now to be removed function radeon_ddc_dump() took care during
> > connector setup that at least one (!) dump was in the logs, accompagnied
> > by the info, that no monitor is connected, or there is a wrong/buggy
> > EDID.
>
> Ok, I see what you are saying. I'm not sure how important it is that
> we print that out. If we have an improperly terminated i2c line,
> you'll either get an edid or garbage and we already cover that with
> the extended edid probe check.
>
> >
> > in radeon_display.c:
> > radeon_print_display_setup(dev);
> > list_for_each_entry(drm_connector, &dev->mode_config.connector_list, head)
> > radeon_ddc_dump(drm_connector);
> >
> >
> > I cannot imagine why this should confuse users. Having retrieved and
> > configured connectors plus info plus EDID dump in case of problems
> > logged next to each other was perfect.
>
> It's confusing because on systems with eDP, DP, or DP bridge chips
> (VGA and LVDS bridges) users get messages saying that the connectors
> are disconnected or have a bad edid and then they file bugs that the
> driver can''t detect their monitor when the monitor is detected just
> fine, it's just on aux rather than i2c. It also adds latency to boot
> since you now have two rounds of connector probing; once for the
> ddc_dump, and once for the fb code. If we only dump information for
> certain connectors it is also confusing since users will not see some
> of the connectors checked at boot while others will be. We could add
> additional logic for the DP cases, but you'd need to drag in most of
> the logic from the dp detect functions in order to determine whether
> the DP port is in DP or legacy mode and then decide whether or not to
> use aux or i2c; all of which just adds more boot latency considering
> we already have to do this for the fb setup.
>
> >
> >> The connectors are probed by
> >> the fb code for the console as well so it just adds to the module load
> >> time. If we want to print what connectors are connected, it should be
> >> done from the fb code so we only have to do it once.
> >>
> >
> > I briefly checked the code, but couldn't find a promising connector
> > probing function in the fb code. Did you mean function
> > drm_fb_helper_probe_connector_modes?
>
> yes, via drm_fb_helper_initial_config()
>
> >
> >
> >> > Graphic solutions in general have several connectors integrated, and it's
> >> > sometimes really difficult to identify, which one of the does not work as
> >> > expected, based on the logs. From above log we see, that a monitor is
> >> > connected to DVI connector, nothing is connected to the VGA connector, and
> >> > we have a problem with the HDMI connector. Without this fuinction, nothing
> >> > helpful from radeon module would be in the logs.
> >>
> >> We should print the connector name in the generic drm error code then
> >> if we want to print this info at boot time.
> >
> > Is there a place that is not called every ten seconds?
>
> You could add logic to the fb probe code.
>
> >
> >>
> >> >
> >> > Maybe we can keep this function, but call it only for connectors, for which
> >> > it works, i. e. not for DP, eDP and DP bridge connectors.
> >>
> >> That's just as bad. Users won't understand why only certain
> >> connectors are probed.
> >>
> >> >
> >> > Best regards
> >> >
> >> > Thomas Reim
> >> >
> >> > Am Dienstag, den 25.10.2011, 19:24 -0400 schrieb alexdeucher at gmail.com:
> >> >
> >> > From: Alex Deucher <alexander.deucher at amd.com>
> >> >
> >> > The function didn't work with DP, eDP, or DP bridge
> >> > connectors and thus confused users as it lead them to
> >> > believe nothing was connected or the EDID was invalid
> >> > when in fact is was, just on the aux bus rather an i2c.
> >> >
> >> > It should also speed up module loading as it avoids a
> >> > bunch of extra DDC probing.
> >> >
> >> > Signed-off-by: Alex Deucher <alexander.deucher at amd.com>
> >> > ---
> >> > drivers/gpu/drm/radeon/radeon_display.c | 33
> >> > -------------------------------
> >> > 1 files changed, 0 insertions(+), 33 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> >> > b/drivers/gpu/drm/radeon/radeon_display.c
> >> > index 6adb3e5..4998736 100644
> >> > --- a/drivers/gpu/drm/radeon/radeon_display.c
> >> > +++ b/drivers/gpu/drm/radeon/radeon_display.c
> >> > @@ -33,8 +33,6 @@
> >> > #include "drm_crtc_helper.h"
> >> > #include "drm_edid.h"
> >> >
> >> > -static int radeon_ddc_dump(struct drm_connector *connector);
> >> > -
> >> > static void avivo_crtc_load_lut(struct drm_crtc *crtc)
> >> > {
> >> > struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> >> > @@ -669,7 +667,6 @@ static void radeon_print_display_setup(struct drm_device
> >> > *dev)
> >> > static bool radeon_setup_enc_conn(struct drm_device *dev)
> >> > {
> >> > struct radeon_device *rdev = dev->dev_private;
> >> > - struct drm_connector *drm_connector;
> >> > bool ret = false;
> >> >
> >> > if (rdev->bios) {
> >> > @@ -689,8 +686,6 @@ static bool radeon_setup_enc_conn(struct drm_device
> >> > *dev)
> >> > if (ret) {
> >> > radeon_setup_encoder_clones(dev);
> >> > radeon_print_display_setup(dev);
> >> > - list_for_each_entry(drm_connector, &dev->mode_config.connector_list,
> >> > head)
> >> > - radeon_ddc_dump(drm_connector);
> >> > }
> >> >
> >> > return ret;
> >> > @@ -743,34 +738,6 @@ int radeon_ddc_get_modes(struct radeon_connector
> >> > *radeon_connector)
> >> > return 0;
> >> > }
> >> >
> >> > -static int radeon_ddc_dump(struct drm_connector *connector)
> >> > -{
> >> > - struct edid *edid;
> >> > - struct radeon_connector *radeon_connector =
> >> > to_radeon_connector(connector);
> >> > - int ret = 0;
> >> > -
> >> > - /* on hw with routers, select right port */
> >> > - if (radeon_connector->router.ddc_valid)
> >> > - radeon_router_select_ddc_port(radeon_connector);
> >> > -
> >> > - if (!radeon_connector->ddc_bus)
> >> > - return -1;
> >> > - edid = drm_get_edid(connector, &radeon_connector->ddc_bus->adapter);
> >> > - /* Log EDID retrieval status here. In particular with regard to
> >> > - * connectors with requires_extended_probe flag set, that will prevent
> >> > - * function radeon_dvi_detect() to fetch EDID on this connector,
> >> > - * as long as there is no valid EDID header found */
> >> > - if (edid) {
> >> > - DRM_INFO("Radeon display connector %s: Found valid EDID",
> >> > - drm_get_connector_name(connector));
> >> > - kfree(edid);
> >> > - } else {
> >> > - DRM_INFO("Radeon display connector %s: No monitor connected or invalid
> >> > EDID",
> >> > - drm_get_connector_name(connector));
> >> > - }
> >> > - return ret;
> >> > -}
> >> > -
> >> > /* avivo */
> >> > static void avivo_get_fb_div(struct radeon_pll *pll,
> >> > u32 target_clock,
> >> >
> >> >
> >
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111101/9592735c/attachment.pgp>
More information about the dri-devel
mailing list