| | 50 | |
| | 51 | '''A tale of two AtomBIOSes''' |
| | 52 | {{{ |
| | 53 | You can pretty much ignore the atom parser in the ddxes at this point. |
| | 54 | That's the internal one we use at AMD that we used for the original open source port. |
| | 55 | It's only used for UMS (usermode modsetting). The one in the kernel was rewritten |
| | 56 | to be more portable and easier to follow. With KMS (kernel modesetting), the ddx |
| | 57 | does not touch the hw at all; you can pretty much ignore all the ddx modesetting code. |
| | 58 | With KMS, all the ddx does is build command buffers for 2D acceleration, and call ioctls |
| | 59 | into the drm to set modes. |
| | 60 | }}} |
| | 61 | |
| | 62 | |
| | 63 | '''AtomBios info''' |
| | 64 | {{{ |
| | 65 | Atom is basically a byte code scripting language used to write little scripts to handle |
| | 66 | basic card initialization tasks (asic init, setting engine/memory clocks, modesetting). |
| | 67 | There are two sets of tables in ATOM: command tables (basically scripts that execute certain |
| | 68 | functionality) and data tables (structs that store board/system specific information (type |
| | 69 | and number of connectors/encoders used on the board, power states, ddc lines, panel info, etc.). |
| | 70 | The command tables are versioned and there are specific structs defined for the inputs to the |
| | 71 | command tables. These are all defined in atombios.h and ObjectID.h. Command tables can also |
| | 72 | call other command tables and look up data in data tables. |
| | 73 | |
| | 74 | The ATOM command scripting language is pretty simiple. It's basically an OP, dst, src. |
| | 75 | Srcs and dsts can be registers, parameter space, fb space, or workspace (which is basically |
| | 76 | a set of special attributes used by the parser). |
| | 77 | |
| | 78 | I'd suggest dumping a few tables using AtomDis to understand the structure. A good place to |
| | 79 | start is a simple table like EnableCrtc. Let me know if you have any questions. |
| | 80 | }}} |
