Technical notes on Radeon HD, straight from AMD engineers. I am mostly documenting this to avoid the bus factor...

ddx == xorg

Radeon HD mode setting:

There are two basic parts we generally work with when programming the display hardware, the crtc and the encoder.
The crtc is basically a display controller and covers the display fb offset, the timing, and the pll setup.
The encoder is the part that takes the bit stream from the crtc and formats it for the proper electrical signal for
the connected monitor (TMDS, LVDS, DAC, DP, etc.).  It's probably easiest to look at the ATOM tables using AtomDis
(more on this below) and follow the same pattern in your driver.  Follow atombios_crtc_mode_set() and radeon_atom_encoder_mode_set()
in the drm.  Basically the modeset sequence looks like:

Disable encoder (dpms off)
Disable crtc (dpms off)
Set up the crtc to encoder routing
Program the pll
Program spread spectrum if applicable
Program mode timing
Program the crtc base address
Program the overscan registers
Program the scaler
Program the encoder
Enable the crtc (dpms on)
Enable the encoder (dpms on)

Note that the pll provides the pixclock for the crtc and the link clocks for the encoders, so it needs to be programmed for all displays.
For displayport on evergreen and newer asics, multiple displays can be driven by the same pll due to the way DP clocking works.

Radeon HD chipset families:

All of these chips have different display hardware so ATOM is your best bet to minimize the changes required to support each generation.

The Display blocks families look like:

Radeon - r1xx-r4xx
AVIVO/DCE 1.0 - r5xx
DCE2.0 - R600, RV610, RV630, RV670, RS690, RS740
DCE3.0 - RV620, RV635, RV770, RS780, RS880
DCE3.2 - RV710, RV730, RV740
DCE4.0 - evergreen (HEMLOCK, JUNIPER, CYPRESS, REDWOOD, CEDAR)
DCE4.1 - fusion (SUMO, SUMO2, PALM)
DCE5.0 - northern islands (BARTS, TURKS, CAICOS,  CAYMAN)

Each family programs slightly or some cases, majorly differently than others.

A tale of two AtomBIOSes

You can pretty much ignore the atom parser in the ddxes at this point.
That's the internal one we use at AMD that we used for the original open source port.
It's only used for UMS (usermode modsetting).  The one in the kernel was rewritten
to be more portable and easier to follow.  With KMS (kernel modesetting), the ddx
does not touch the hw at all; you can pretty much ignore all the ddx modesetting code.
With KMS, all the ddx does is build command buffers for 2D acceleration, and call ioctls
into the drm to set modes.

AtomBios info

Atom is basically a byte code scripting language used to write little scripts to handle
basic card initialization tasks (asic init, setting engine/memory clocks, modesetting).
There are two sets of tables in ATOM: command tables (basically scripts that execute certain
functionality) and data tables (structs that store board/system specific information (type
and number of connectors/encoders used on the board, power states, ddc lines, panel info, etc.).
The command tables are versioned and there are specific structs defined for the inputs to the
command tables.  These are all defined in atombios.h and ObjectID.h.  Command tables can also
call other command tables and look up data in data tables.

The ATOM command scripting language is pretty simiple.  It's basically an OP, dst, src.
Srcs and dsts can be registers, parameter space, fb space, or workspace (which is basically
a set of special attributes used by the parser).  

I'd suggest dumping a few tables using AtomDis to understand the structure.  A good place to
start is a simple table like EnableCrtc.  Let me know if you have any questions.