A question about the gtf setting

[Huang, FrankR]

Alex,

Appreciate your sooner reply in detail. And you must have read my mail between xorg-devel guys and I. Thanks also for your care on geode thing. You show me a very good example of ATI *_mode_valid() to refer. See below for my question:

> For flat panels, you may want to use cvt rather than gtf as cvt is
> newer and supports reduced blanking which some panels prefer; e.g.,
> cvt -r 1024 600 60
Fine. Right now I user cvt tool to generate the parameter.
> 
> Why would you want to use a 100hz refresh rate?  Does the monitor
> actually require a 100 hz refresh?  Your best bet would be to use the
> actual modeline the panel requires.  Widescreen is no different than
> non-widescreen; it's just another modeline.  The hw should be able to
> handle it the same as a non-widescreen mode.
The reason why I want to use 100Hz refresh is that if I use 60Hz refresh parameter, I found that few modes(1024x600,640x480) are provided on gnome monitor Preferences. After my debug, I found why there is few modes displayed with 1024x600 at 60Hz. In X server function GuessRangeFromModes(&mon_rec, output_modes), monitor's vrefresh and hsync value will be calculated. Then the vrefresh and hsync's hi and lo will be used to prune mode to be supported. The output_modes parameter given to GuessRangeFromModes is just got from the geode driver function lx_output_get_modes(). If the display is a panel instead of VGA(VGA will use EDID), the return value of this function is just the parameter I set with 1024x600 at 60Hz. So when I use 1024x600 at 100Hz parameter, much modes will be showed in monitor preferences.
> 
> As for mode validation, you have to check the proposed mode against
> the hw's capabilities.  For example, if the pixel clock is larger or
> smaller than the supported range of your pixel pll, then you'd reject
> the mode.  Different encoders also have limitations.  For example,
> single link TMDS is limited to 165 Mhz pixel clocks.  If the TMDS
> encoder on the chip is single link only, you would reject modes with
> clocks > 165 Mhz.  For things like LVDS, the LVDS panel usually has a
> fixed mode, so the driver should reject any modes with different sizes
> than the fixed panel size unless you have a scaler that can scale the
> non-native mode to the native panel timing.
I ask for the HW engineer to understand more about your this part words. There is one point I want to ask more. What is the fixed mode? Is it to say the HW does not need an I2C port to read EDID info? And If the LVDS panel has a fixed mode, the VBIOS and driver should do what?  
> 
> Thing you need to validate:
> - max, min pixel clocks the pll is able to generate
> - max, min pixel clocks supported by various encoders (TMDS, DAC, etc.)
The difference of pixel clock between PLL and encoder?

> - fixed panel size
Is it the panel screen FIXED resolution width and height?

> - memory bandwidth
> 
> Lets look at some examples from the radeon code (radeon_mode_valid()):
> 
>     if (info->ChipFamily == CHIP_FAMILY_RV100 && !pRADEONEnt->HasCRTC2) {
>         if (xf86ModeBandwidth(pMode, pScrn->bitsPerPixel) > 300)
>             return MODE_BANDWIDTH;
>     }
> 
> RN50 has limited memory bandwidth so larger modes with higher refresh
> rates are not possible.
> 
>     if (radeon_output->active_device & (ATOM_DEVICE_TV_SUPPORT)) {
> 	if (IS_AVIVO_VARIANT)
>             return MODE_OK;
>         else {
>             /* FIXME: Update when more modes are added */
>             if (pMode->HDisplay == 800 && pMode->VDisplay == 600)
>                 return MODE_OK;
>             else
>                 return MODE_CLOCK_RANGE;
>         }
>     }
> 
> If the monitor is a TV, we scale the desktop size (what we expose as a
> mode) to the native timing of the TV (NTSC, PAL, etc.).  For newer
> radeons, we support arbitrary mode scaling, so we return MODE_OK; on
> older radeons, we currently only support a scaled 800x600 mode, so we
> reject modes that are not 800x600.
> 
>     /* clocks over 135 MHz have heat issues with DVI on RV100 */
>     if ((radeon_output->MonType == MT_DFP) &&
>         (info->ChipFamily == CHIP_FAMILY_RV100) &&
>         (pMode->Clock > 135000))
>             return MODE_CLOCK_HIGH;
> 
> RV100 based chips only support a maximum pixel clock of 135 Mhz on on
> the TMDS encoder (for digital DVI).  If the mode clock is > 135 Mhz,
> reject it.
> 
>     /* single link DVI check */
>     if (pMode->Clock > 165000 && radeon_output->MonType == MT_DFP) {
>         /* DP->DVI converter */
>         if (radeon_output->ConnectorType == CONNECTOR_DISPLAY_PORT)
>             return MODE_CLOCK_HIGH;
> 
>         if (radeon_output->ConnectorType == CONNECTOR_EDP)
>             return MODE_CLOCK_HIGH;
> 
>         /* XXX some HDMI can do better than 165MHz on a link */
>         if (radeon_output->ConnectorType == CONNECTOR_HDMI_TYPE_A)
>             return MODE_CLOCK_HIGH;
> 
>         /* XXX some R300 and R400 can actually do this */
> 	if (!IS_AVIVO_VARIANT)
>             return MODE_CLOCK_HIGH;
> 
>         /* XXX and some AVIVO can't */
>     }
> 
> Single link TMDS encoders support a max clock of 165 Mhz, so we reject
> any modes > 165 Mhz on those encoders.
> 
>     if (radeon_output->active_device & (ATOM_DEVICE_LCD_SUPPORT)) {
>         if (radeon_output->rmx_type == RMX_OFF) {
>             if (pMode->HDisplay != native_mode->PanelXRes ||
> 		pMode->VDisplay != native_mode->PanelYRes)
>                 return MODE_PANEL;
>         }
>         if (pMode->HDisplay > native_mode->PanelXRes ||
>             pMode->VDisplay > native_mode->PanelYRes)
>             return MODE_PANEL;
>     }
> 
> If the monitor is a local flat panel (LVDS or eDP), it only supports a
> fixed mode, however we can set modes smaller than the panel size by
> using the scaler to upscale the image to the native panel timing.  So
> here we compare the mode size to the panel's native mode and reject
> any modes how size is larger than the native panel's size.
RMX is the "scaler disabled"? How the native_mode is got? Is it set fixed in driver code to satisfy the display?

> 
>     return MODE_OK;
> 
> Finally if the mode has not been rejected by any of the afore
> mentioned checked, it's considered ok.
> 
> I hope this helps.
> 
> Alex
> 
> >
> > Thanks,
> > Frank
> >
> >