I was the one who determined the modedb.c entry for the C1MV, using my
laptop's hardware, and the existing (original) radeonfb driver.
I don't have the equipment to open the laptop and scope the DFP's sync
line, so I opened up the XFree86 4.2.0 source and looked at their
Radeon driver instead:
xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c, line 3774:
save->crtc_v_sync_strt_wid = (((mode->CrtcVSyncStart - 1) & 0xfff)
| (vsync_wid << 16)
| ((mode->Flags & V_NVSYNC)
? RADEON_CRTC_V_SYNC_POL
: 0));
RADEON_CRTC_V_SYNC_POL is defined as (1 << 23) in radeon_reg.h.
I think when vertical sync is low (the V_NVSYNC flag is set), the
register bit is set to 1. When vertical sync is high, the V_NVSYNC
flag is false, and the register bit is zero.
Looking at Ani's radeonfb code, we have two spots to consider:
drivers/video/radeonfb.c, line 2421:
sync = mode->sync;
h_sync_pol = sync & FB_SYNC_HOR_HIGH_ACT ? 0 : 1;
v_sync_pol = sync & FB_SYNC_VERT_HIGH_ACT ? 0 : 1;
and drivers/video/radeonfb.c, line 2472:
newmode.crtc_v_sync_strt_wid = (((vSyncStart - 1) & 0xfff) |
(vsync_wid << 16) | (v_sync_pol << 23));
Looking at this, I think if vertical sync is low, v_sync_pol is 1, and
v_sync_pol << 23 sets the register bit to 1. If vertical sync is
high, v_sync_pol is 0, and the register bit is cleared.
The XFree86 4.2.0 code seems to agree with the existing radeonfb
driver, with the sense of the tests being inverted.
I couldn't find a programming manual for the card on ATI's site (might
not know where to look). XFree86 4.2.0 worked for me before I tried
the framebuffer, and it configured itself just fine.
Hopefully Ani will have an answer...
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/