Re: [PATCH] drm/radeon/kms: remove useless radeon_ddc_dump()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Alex,

see
http://lists.freedesktop.org/archives/dri-devel/2011-November/016934.html for a proposal.

I went back to the DVI detect function in radeon_connectors.c. The
reason for this is that during initial configuration of the framebuffer,
where we would like to put the log message output, function
drm_helper_probe_single_connector_modes() is called. Log output to the
user is performed already there: e. g. 'CONNECTOR HDMI-A-1' followed by
'HDMI-A-1 is disconnected' in case the (extended) DDC probe fails. The
DDC probe itself is triggered by calling the connector type specific
detect function, e. g. radeon_dvi_detect().

Therefore, I decided to leave the general DRM framebuffer initial
configuration functions untouched and adapt the Radeon connector
specific detect function(s) instead.

Hope you like it.

Best regards

Thomas

> On Tue, Nov 1, 2011 at 7:23 AM, Thomas Reim <reimth@xxxxxxxxxxxxxx> wrote:
> > 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.
> 
> User's will still realize they can't use the monitor since it will
> listed as disconnected.  Is there really a lot of value in printing a
> garbage EDID dump due to an improperly terminated i2c line?  Now that
> you fixed the probe function, it becomes a moot point I think.
> Monitors with bad EDID checksums, etc. will still get logged.  I'd
> argue that we should still use those too as in most cases the EDID is
> still valid, but that is another discussion.
> 
> >
> > 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?
> 
> Most users never look at their kernel log unless there is a problem in
> which case they'll file a bug report and we can request debug output.
> 
> >
> > 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).
> >
> 
> If you want to add better debugging output, that'd be great.  While
> you are at it, it would be nice to print which modes are rejected by
> the driver's mode_valid functions.
> 
> > Would this work also for other users, especially the users with eDP, DP,
> > or DP bridge chips?
> 
> Yes, it should.
> 
> Alex


_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux