Re: 16bpp @ 1024x768 with ct65554?
Hi.
In <[🔎] 3A10003D.CF757E78@hecke.dartmouth.edu>,
on "Mon, 13 Nov 2000 09:52:45 -0500",
with "Re: 16bpp @ 1024x768 with ct65554?",
"Thomas R. Shemanske" <trs@hecke.dartmouth.edu> wrote:
trs> The FPClock options and SetMclk options are overridden by the server as
trs> you can see from the excerpt from the XFree86.0.log file:
trs>
trs> (--) CHIPS(0): Using programmable clocks
trs> (--) CHIPS(0): Dot clock 0: 25.172 MHz
trs> (--) CHIPS(0): Dot clock 1: 28.325 MHz CRTclk
trs> (--) CHIPS(0): Dot clock 2: 65.082 MHz FPclk
trs> (--) CHIPS(0): Memory clock of 77.099 MHz exceeds limit of 55.000 MHz
trs> (==) CHIPS(0): Min pixel clock is 11.000 MHz
trs> (--) CHIPS(0): Max pixel clock is 56.125 MHz
trs> (**) CHIPS(0): FP clock 65.082 MHz requested
trs> (II) CHIPS(0): FP clock set to 50.512 MHz
trs>
trs> This suggests to me that I cannot create the illusion of a faster dot
trs> clock. Right?
Ah, sorry. I have misunderstood the meaning of the option.
FPClock option does not have effect on the DotClock. It is to be used
in order to change the LCD panel clock. The LCD (flat panel) does have
its own clock. So you don't need this, I think.
FWIW, the chips driver set the FP clock to the value specified by this
option when that value is within the range from Min pixel clock to Max
pixel clock. If the specified value exceeds the Max pixel clock, then
the driver uses 90% of the maximum allowable clock as the target FP clock
value. You see, 50.512 = 56.125 * 0.9.
The code is in ct_driver.c:
val = (int) (real * 1000.);
if (val && val >= cPtr->MinClock && val <= cPtr->MaxClock)
cPtr->FPclock = val;
else if (cPtr->FPclock > cPtr->MaxClock)
cPtr->FPclock = (int)((float)cPtr->MaxClock * 0.9);
else
cPtr->FPclock = 0; /* special value */
cPtr->FPClkModified = FALSE;
if (cPtr->FPclock)
xf86DrvMsg(pScrn->scrnIndex, X_INFO,
"FP clock set to %7.3f MHz\n",
(float)(cPtr->FPclock / 1000.));
The document says
Normally the chips BIOS set the flat panel clock correctly and so
the default behaviour with HiQV chipset is to leave the flat panel
clock alone, or force it to be 90% of the maximum allowable clock
if the current panel clock exceeds the dotclock limitation due to
a depth change.
Perhaps you don't have to use this FPClock(depth) option. Just disable it.
The correct option to force the Dot Clock, is the common option, DacSpeed.
>From the document:
DacSpeed 80.000
The server will limit the maximum dotclock to a value as speci-
fied by the manufacturer. This might make certain modes impossi-
ble to obtain with a reasonable refresh rate. Using this option
the user can override the maximum dot-clock and specify any value
they prefer. Use caution with this option, as driving the video
processor beyond its specifications might cause damage.
And I was wrong another point. SetMclck option is valid option with 4.0.1e
chips driver. You can use it in order to set memory clock.
Option "SetMClk" "38.000MHz"
Option "SetMClk" "38000kHz"" This option sets the internal memory
clock (MCLK) registers of HiQV chipsets to 38MHz or some other
value. Use caution as excess heat generated by the video proces-
sor if its specifications are exceeded might cause damage. How-
ever careful use of this option might boost performance. This
option might also be used to reduce the speed of the memory clock
to preserve power in modes that don't need the full speed of the
memory to work correctly. This option might also be needed to
reduce the speed of the memory clock with the "Overlay" option.
Excuse me about confusing, and please take care when you use this option.
The codes in ct_driver are:
if (xf86GetOptValFreq(cPtr->Options, OPTION_SET_MCLK, OPTUNITS_MHZ, &real))
{
int mclk = (int)(real * 1000.0);
if (mclk <= MemClk->Max) {
xf86DrvMsg(pScrn->scrnIndex, X_CONFIG,
"Using memory clock of %7.3f MHz\n",
(float)(mclk/1000.));
/* Only alter the memory clock if the desired memory clock differs
* by 50kHz from the one currently being used.
*/
if (abs(mclk - MemClk->ProbedClk) > 50) {
unsigned char vclk[3];
MemClk->Clk = mclk;
chipsCalcClock(pScrn, MemClk->Clk, vclk);
MemClk->M = vclk[1] + 2;
MemClk->N = vclk[2] + 2;
MemClk->P = (vclk[0] & 0x70) >> 4;
MemClk->PSN = (vclk[0] & 0x1) ? 1 : 4;
MemClk->xrCC = vclk[1];
MemClk->xrCD = vclk[2];
MemClk->xrCE = 0x80 || vclk[0];
}
} else
xf86DrvMsg(pScrn->scrnIndex, X_PROBED,
"Memory clock of %7.3f MHz exceeds limit of %7.3f MHz\n",
(float)(mclk/1000.),
(float)(MemClk->Max/1000.));
} else
xf86DrvMsg(pScrn->scrnIndex, X_PROBED,
"Probed memory clock of %7.3f MHz\n",
(float)(MemClk->ProbedClk/1000.));
cPtr->ClockMulFactor = 1;
And
/* Check if maxClock is limited by the MemClk. Only 70% to allow for */
/* RAS/CAS. Extra byte per memory clock needed if framebuffer used */
/* Extra byte if the overlay plane is avtivated */
if (cPtr->FrameBufferSize && (cPtr->PanelType & ChipsLCD))
if (cPtr->Flags & ChipsOverlay8plus16 )
cPtr->MaxClock = min(cPtr->MaxClock, MemClk->Clk * 4 * 0.7 / 4);
else
cPtr->MaxClock = min(cPtr->MaxClock,
MemClk->Clk * 4 * 0.7 / (bytesPerPixel + 1));
else
if (cPtr->Flags & ChipsOverlay8plus16)
cPtr->MaxClock = min(cPtr->MaxClock, MemClk->Clk * 4 * 0.7 / 3);
else
cPtr->MaxClock = min(cPtr->MaxClock,
MemClk->Clk * 4 * 0.7 / bytesPerPixel);
if (cPtr->pEnt->device->dacSpeeds[0]) {
int speed = 0;
switch (pScrn->bitsPerPixel) {
case 1:
case 4:
case 8:
speed = cPtr->pEnt->device->dacSpeeds[DAC_BPP8];
break;
case 16:
speed = cPtr->pEnt->device->dacSpeeds[DAC_BPP16];
break;
case 24:
speed = cPtr->pEnt->device->dacSpeeds[DAC_BPP24];
break;
case 32:
speed = cPtr->pEnt->device->dacSpeeds[DAC_BPP32];
break;
}
if (speed == 0)
speed = cPtr->pEnt->device->dacSpeeds[0];
from = X_CONFIG;
xf86DrvMsg(pScrn->scrnIndex, X_CONFIG,
"User max pixel clock of %7.3f MHz overrides %7.3f MHz limit\n",
(float)(speed / 1000.), (float)(cPtr->MaxClock / 1000.));
cPtr->MaxClock = speed;
} else {
xf86DrvMsg(pScrn->scrnIndex, X_PROBED,
"Max pixel clock is %7.3f MHz\n",
(float)(cPtr->MaxClock / 1000.));
}
trs> I have tried changing the horizontal and vertical refresh limits.
trs> Either modelines tell me certain values are out of range, or when I
trs> change the range to include them, it tells me they are invalid, e.g.,
trs>
trs>
trs> (WW) CHIPS(0): Mode "1024x768@16bpp" deleted (hsync out of range)
trs>
trs> (WW) CHIPS(0): Mode "1024x768@16bpp" deleted (bad mode
trs> clock/interlace/doublescan)
These messages are written in common/xf86Mode.c:
const char *
xf86ModeStatusToString(ModeStatus status)
{
switch (status) {
(snip)
case MODE_HSYNC:
return "hsync out of range";
(snip)
case MODE_CLOCK_RANGE:
return "bad mode clock/interlace/doublescan";
You can read the MODE_CLOCK_RANGE in common/xf86str.h:
/* These are possible return values for xf86CheckMode() and ValidMode() */
typedef enum {
(snip)
MODE_CLOCK_RANGE, /* clock/mode isn't in a ClockRange */
(snip)
} ModeStatus;
So the reason "bad mode clock" may be that clock exceeds the limit.
trs> I have tried varying the following modelines (changing the dotclock?)
trs> entry 55.6, 56.125. The first has entries suggested by the current
trs> xserver in 8bit mode (as you suggest above). The latter is the exact
trs> modeline that worked in 3.3.6
trs>
trs> ModeLine "1024x768@16bpp" 55.6 1024 1072 1168 1376 768 769 772 808
trs> ModeLine "1024x768@16bpp" 56.125 1024 1048 1208 1264 768 776 784 817
You wrote in your first mail:
| I have tried to tweak SetMClk and DacSpeed, but so far no luck.
So you did correct way. Sorry to confuse.
Your X log in 8bpp said:
| (--) CHIPS(0): Using programmable clocks
| (--) CHIPS(0): Dot clock 0: 25.172 MHz
| (--) CHIPS(0): Dot clock 1: 28.325 MHz CRTclk
| (--) CHIPS(0): Dot clock 2: 65.082 MHz FPclk
| (--) CHIPS(0): Probed memory clock of 40.090 MHz
| (==) CHIPS(0): Min pixel clock is 11.000 MHz
| (--) CHIPS(0): Max pixel clock is 95.000 MHz
| (**) CHIPS(0): Default mode "1024x768": 94.5 MHz, 68.7 kHz, 85.0 Hz
| (**) CHIPS(0): Default mode "800x600": 56.3 MHz, 53.7 kHz, 85.1 Hz
And your X log in 16bpp said:
| (--) CHIPS(0): Using programmable clocks
| (--) CHIPS(0): Dot clock 0: 25.172 MHz
| (--) CHIPS(0): Dot clock 1: 28.325 MHz CRTclk
| (--) CHIPS(0): Dot clock 2: 65.082 MHz FPclk
| (--) CHIPS(0): Probed memory clock of 40.090 MHz
| (==) CHIPS(0): Min pixel clock is 11.000 MHz
| (--) CHIPS(0): Max pixel clock is 56.125 MHz
| (II) CHIPS(0): FP clock set to 50.512 MHz
Well, chips document said:
==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
For the HiQV series of chips, the memory clock can be successfully probed.
Hence you will see a line like
(--) CHIPS(0): Probed memory clock of 40.090 MHz
in your startx log file. Note that many chips are capable of higher
memory clocks than actually set by BIOS. You can use the "<tt>SetMClk</tt>"
option in your XF86Config file to get a higher MClk. However some
video ram, particularly EDO, might not be fast enough to handle this,
resulting in drawing errors on the screen. The formula to determine the
maximum usable dotclock on the HiQV series of chips is
Max dotclock = min(MaxDClk, 0.70 * 4 * MemoryClk / (BytesPerPixel +
(isDSTN == TRUE ? 1 : 0)))
which says that there are two limits on the dotclock. One the overall
maximum, and another due to the available memory bandwidth of the chip.
==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
So, using the "Probed memory clock of 40.090 MHz" in the log above,
we get 0.70*4*40.090/1 = 112.25 for depth 8, and 56.126 for depth 16.
Hence Max pixel clock 95.000 MHz in depth 8 comes from the MaxDClk,
and 56.125 MHz in depth 16 comes from the memory clock.
Have you try to use "SetMClk 42.0" ? May be you can try 44.0 or 46.0 also.
Make sure to disable FPClock option next time.
trs> One other interesting bit of information. If I use only the option
trs> UseModeLine, I get a screen with a black vertical band on the left
trs> (about 4cm wide), and the rest white. If I also use the FixPanelSize
trs> option, the black vertical band eventually locks in as my normal
trs> background color. It's just that I have a 150 x 768 panel.
Just forget UseModeLine. You have to tune the modeline for each depth
when you use it.
trs> Since the xserver won't allow me to adjust the dot clock, can you
trs> suggest a systematic way of testing modelines? Right now my efforts are
trs> fairly random.
Let's try to use DacSpeed and SetMClk again, and show us the log with them.
Regards.
--
Taketoshi Sano: <sano@debian.org>,<sano@debian.or.jp>,<kgh12351@nifty.ne.jp>
Reply to: