On 3/9/07, bruno schwander <[EMAIL PROTECTED]> wrote:
I keep answering my own questions. I hopI am not spamming the mailing list
too much, but it's nice to get some degree of confirmation from those who
know before I dive into something.
so I gather now that actually I should leave the xf86SetCrtcForModes()
alone, and just add setting the clock with CCR6C, CCR6D (and enabling it
with CCR68). I'll see how that goes...
exactly. Sorry for not responding earlier. You can use the
SMI_CalcClock() function to calculate SR6C and SR6D, just like the
mclk is generated. Use mode->Clock. I have a similar patch in my xorg
smi tree.
Alex
bruno
On Thu, 8 Mar 2007, bruno schwander wrote:
> On Thu, 8 Mar 2007, Alex Deucher wrote:
>
>> The siliconmotion driver doesn't explicitly set the vclk pll. It uses
>> the bios (if UseBIOS is set or does nothing if not).
>
>
> that is what I was wondering...
> well, if I do not
>
> Options UseBIOS false
>
> all I get is a blank screen. So I have to disable it. I did not realize that
> it did not set the pixel clock since when using a default VGA 640x480
> resolution, it was working. So I guess it just happens to stay at whatever
> pixel clock the BIOS or console driver had set it to ? That seems very
> strange.
>
>> It's trivial to add however. SR6C, SR6D are programmed similarly to the
>> mclk.
>
> I saw that mclk/dac stuff, yes, and was wondering how the pixel clock was
> really set. All this makes more sense now.
>
> So what you are saying is that in smi_driver.c : SMI_PreInit(), I should
> replace the call to xf86SetCrtcForModes(pScrn, 0), with an alternative that
> programs vclk explicitely ?
>
> How can it set the crtc for several modes ? That is what
> xf86SetCrtcForModes() seems to do, right ?
>
> I still have a lot to learn.
>
> thanks for all the help guys, trudging along...
>
> bruno
>
>
>
>> Alex
>>
>>> Bruno
>>>
>>> On Wed, 7 Mar 2007, bruno schwander wrote:
>>>
>>> > ah actually now it is not choosing my modeline and I do not understand
>>> why:
>>> >
>>> > (II) Silicon Motionlg: Using hsync range of 14.00-80.00 kHz
>>> > (II) Silicon Motionlg: Using vrefresh range of 56.00-76.00 Hz
>>> > (II) Silicon MotionClock range: 14.00 to 135.00 MHz
>>> > (II) Silicon MotionMode: 640x480 16-bpp, 59.990181Hz
>>> > (II) Silicon MotionNot using mode "640x480i" (vrefresh out of range)
>>> > (II) Silicon MotionMode: 640x350 16-bpp, 85.079948Hz
>>> > (II) Silicon MotionNot using default mode "640x350" (vrefresh out of
>>> range)
>>> >
>>> >
>>> > vrefresh range is 56-76Hz, so why is my 640x480i modeline, at 59.99Hz
>>> > vrefresh, rejected ?
>>> >
>>> > the modeline is as follows:
>>> >
>>> > ModeLine "640x480i" 24.44 640 680 728 776 480 480 484 525 Interlace
>>> > Composite
>>> >
>>> >
>>> >
>>> > bruno
>>> >
>>> >
>>> > On Wed, 7 Mar 2007, bruno schwander wrote:
>>> >
>>> >> I think I figured it out, however it seems that although my modeline
>>> >> includes 'composite'
>>> >>
>>> >> DisplayModePtr mode->Flags & V_CSYNC
>>> >>
>>> >> does not evaluate to true. I assume as long as the 'composite' keyword
>>> is
>>> >> found on the modeline, the flag should be set, right ?
>>> >>
>>> >> I need to add some debug messages, but this seems a little strange. Is
>>> >> there something else that needs to be configured, like telling that the
>>> >> driver actually supports the composite keyword on the modeline ?
>>> >>
>>> >> On a different note, the latest X release does not seem to work on that
>>> >> chip. I just get a blank screen. So I started hacking on Xorg 6.8.2 to
>>> test
>>> >> this stuff. I figure XFree86 4.5 should work, but 4.6 does not.
>>> >>
>>> >> I'll provide patches to all and note on which version it was tested of
>>> >> course, once it works :-)
>>> >>
>>> >> bruno
>>> >>
>>> >> On Tue, 27 Feb 2007, Marc Aurele La France wrote:
>>> >>
>>> >>> On Sun, 25 Feb 2007, bruno schwander wrote:
>>> >>>> On Fri, 23 Feb 2007, Marc Aurele La France wrote:
>>> >>>>> On Thu, 22 Feb 2007, bruno schwander wrote:
>>> >>>>>> A little background: I have a single board PC with a SMI712
>>> (lynxEM+)
>>> >>>>>> graphic chipset. X works like a charm.
>>> >>>
>>> >>>>> The driver currently ignores the V_CSYNC mode flag, so you would
>>> need to
>>> >>>>> come up with a source patch to change that.
>>> >>>
>>> >>>> I'd be happy to provide a patch, if I can figure where to put that.
>>> Since
>>> >>>> it is only a matter of setting one register it should be simple
>>> enough. I
>>> >>>> have (had?) no idea where to start, I'll grep for V_CSYNC and see...
>>> >>>
>>> >>> An appropriate spot for such changes would be after calls to
>>> vgaHWInit(),
>>> >>> which, in this case, is in SMI_ModeInit().
>>> >>>
>>> >>> Marc.
>>> >>>
>>> >>>
>>> +----------------------------------+----------------------------------+
>>> >>> | Marc Aurele La France | work: 1-780-492-9310
>>> |
>>> >>> | Academic Information and | fax: 1-780-492-1729
>>> |
>>> >>> | Communications Technologies | email: [EMAIL PROTECTED]
>>> |
>>> >>> | 352 General Services Building
>>> +----------------------------------+
>>> >>> | University of Alberta |
>>> |
>>> >>> | Edmonton, Alberta | Standard disclaimers apply
>>> |
>>> >>> | T6G 2H1 |
>>> |
>>> >>> | CANADA |
>>> |
>>> >>>
>>> +----------------------------------+----------------------------------+
>>> >>> XFree86 developer and VP. ATI driver and X server internals.
>> _______________________________________________
>> Devel mailing list
>> Devel@XFree86.Org
>> http://XFree86.Org/mailman/listinfo/devel
>>
>>
> _______________________________________________
> Devel mailing list
> Devel@XFree86.Org
> http://XFree86.Org/mailman/listinfo/devel
>
>
_______________________________________________
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
