On Mon, 22 Aug 2011 12:19:25 +0200, Philippe Houdoin wrote:
I'm not too fond of the name, but I don't really have a better suggestion either.Yeah, I asked in IRC and no one could come up with anything better.Hey, stop bringing down with you... innocents! VideoCardStuffs.h was suggested, after all ! ;-) BTW, that bring me another less crazy (I hope) suggestion: could you explain in your commits message, on first occasion only, the acronyms like MC and co used in your driver code. That way, us lazy lurkers (and any future commit log readers) could better follow what's done and what do such part of the code.
Sure!Here is a glossary of stuff thus far and a high-level overview of the display
management. Memory Areas: FB == Frame Buffer MC == Memory Controller Encoders: CRTC == CRT Controller PLL == Phase locked loop (DAC)TMDS == Transition Minimized Differential Signaling (HDMI, DVI, etc) LVDS == Low-voltage differential signaling (think lcd in a laptop)
DAC == Digital Analog converter Other:AtomBIOS == AMD's bios parser, give it a VGA bios and get a series of binary calls and tables that will manipulate registers I used the original AMD kgrids parser and backported the bug fixes made by the linux kernel DRM team at AMD. Turboencabulator == A fictional machine used for things I don't understand
R500-R700 == AMD's naming scheme for cards up to Radeon HD 4xxxR1000-R3000 == A made up naming scheme as AMD transitioned to named chipsets for Radeon HD 5000+ (i may change this to work off DCE version in the future)
The accelerant will keep two global arrays:gConnector[i] == physical connectors on the cards, and their encoder (DAC, TMDS, LVDS, etc) (i == 1-127 with only a few valid ones)
gDisplay[i] == logical displays, mapped to gConnector index.detect_connectors will populate gConnector[i] and is run once at driver startup. detect_displays will populate gDisplay[i] with active monitors (and can be run multiple times)
Let me know if I missed anything. Thanks! -- Alex