[Xorg-driver-geode] A question about the gtf setting

[Alex Deucher]

On Thu, Oct 14, 2010 at 4:14 AM, Huang, FrankR <FrankR.Huang at amd.com> wrote:
> 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.

If the panel only supports 1024x600 at 60hz, just add that mode in the
probe() function for your LVDS output and reject the other modes in
the mode_valid() function unless your panel hw has a scaler in which
case you should be able to support the additional modes.  See
RADEONProbeOutputModes() in radeon_modes.c for how we add modes for
different output types.

>>
>> 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?

When I say panel, I'm generally talking about integrated flat panels
(e.g., the panels on laptops).  LCD monitors connected via DVI or VGA
have an EDID and generally support other non-native modes due to
having a built in scaler in the monitor.  As for the LVDS panel
timing, on radeon, we have potentially two places where that
information is stored: 1. there is an LVDS info table in the vbios
that includes the panel size and timing, and 2. some laptops have a
panel EDID.  There should be some method to get that information on
geode.

>>
>> 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?

PLL is the clock generator for the crtc; it takes a reference
frequency and through a set of dividers, generates the requested pixel
clock for the mode.  The encoder is the part of the display pipeline
that takes the bit stream from the crtc and encodes it in the proper
format for the selected connector (LVDS, TMDS, etc.).  See this blog
post I wrote for more information in the display pipeline on radeon:
http://www.botchco.com/agd5f/?p=51


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

Yes.  LCD panels generally have a fixed size and timing;  this timing
is considered the native mode of the panel.  In order to support
non-native modes, you need a scaler which will scale up (or down in
some cases) the in coming data to the native panel size.  The panel
always gets native timing.  For LVDS, the GPU usually has a scaler to
handle non-native modes.  For VGA/DVI LCD monitors, the monitor
generally has a scaler that scales the incoming mode to the native
mode.

>
>> - 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?
>

RMX (RadioMetric eXpansion) is the name of the scaler on older radeon
hw.  The LVDS panel's native mode is pulled from either the vbios LVDS
info table or from the panel's EDID if it has one.  In the
mode_valid() function, we reject modes that are larger than the panel
(MODE_PANEL), but we allow modes smaller than the panel since the RMX
unit can scale those modes up to the native mode size.  When setting
the mode, we always program the native mode.  If requested mode is
smaller than the native mode, we also set up the RMX unit.  You give
the RMX unit the requested size and the native size and a few other
parameters and it scales the image up.

Alex

>>
>>     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
>> >
>> >
>
>
>