DFP support for kernel radeonfb.c added

[Kevin B. Hendricks]

Hi Ben,

Okay here it is as a patch against your latest rsync versions.  I tried
not to touch any of Daniel's changes that should become redundant if the
EDID stuff works for everyone, they are still in there.

(see attached dfp_radeon.patch.gz)

FYI:

There are a few things I did change with how some fp registers are
intiialized that may impact others.   Especially how timings are
calculated for MT_LCD and MT_DFP.

Previously the code had the following in radeon_load_video_mode()
which just does  not look right at all.

       if ((primary_mon == MT_DFP) || (primary_mon == MT_LCD)) {

...snip...
                hTotal = mode->xres + rinfo->hblank + mode->left_margin;
                hSyncStart = mode->xres + rinfo->hOver_plus +
mode->right_margin;
                hSyncEnd = hSyncStart + rinfo->hOver_plus +
mode->hsync_len;

                vTotal = mode->yres + rinfo->vblank + mode->upper_margin;
                vSyncStart = mode->yres + rinfo->vOver_plus +
mode->lower_margin;
                vSyncEnd = vSyncStart + rinfo->vSync_width +
mode->vsync_len;
        }


But

HTotal = x active area +  hblank

hSyncStart  = x active area + offset to the sync (which is hOver_plus)

(I have no idea why mode->right margin is added  - we are then adding the
same thing twice!)

There are similar confusions over vTotal, vSyncStart, and vSyncEnd.  We
seem to be adding the same thing twice in many cases.   The latest XF86
CVS HEAD radeon_driver, calculates things the way I do and not the way it
seems to be done here previously.

I just don't understand how this could have worked for LCD and it did not
work for DFP at all.

So my patch fixes this which might make a difference but should actually
make things better.

Anyway, please give it a try.  I will send followup patches with other
fixes and additions I make to improve things but this should be enough to
get people working until the i2c stuff gets going.

So Daniel, if you get a chance, please try this.  If it works, then we
have broken nothing for you and we can then decide if you want to move to
the more general case of using EDID info.  If it does not work, please let
me know asap so I can back out my changes in groups until we identify what
is going wrong here.

Thanks,

Kevin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: dfp_radeon.patch.gz
Type: application/x-gzip
Size: 4639 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20011114/c0aeaeb9/attachment.bin>