I used your vclk setting code as in smi_driver.c, and changed the shift
in SMI_CommonCalcClock() but it seems to still have some
issue.
12220 clock gives me values of
SR6C: 63, SR6D: 1D
bruno
On Sun, 11 Mar 2007, Alex Deucher wrote:
On 3/10/07, bruno schwander [EMAIL PROTECTED] wrote:
I
On 3/12/07, bruno schwander [EMAIL PROTECTED] wrote:
I used your vclk setting code as in smi_driver.c, and changed the shift
in SMI_CommonCalcClock() but it seems to still have some
issue.
12220 clock gives me values of
SR6C: 63, SR6D: 1D
That's going to give you a vclk of ~48.88 Mhz
On Mon, 12 Mar 2007, Alex Deucher wrote:
On 3/12/07, bruno schwander [EMAIL PROTECTED] wrote:
I used your vclk setting code as in smi_driver.c, and changed the shift
in SMI_CommonCalcClock() but it seems to still have some
issue.
12220 clock gives me values of
SR6C: 63, SR6D: 1D
That's
On 3/13/07, bruno schwander [EMAIL PROTECTED] wrote:
On Mon, 12 Mar 2007, Alex Deucher wrote:
On 3/12/07, bruno schwander [EMAIL PROTECTED] wrote:
I used your vclk setting code as in smi_driver.c, and changed the shift
in SMI_CommonCalcClock() but it seems to still have some
issue.
12220
On 3/10/07, bruno schwander [EMAIL PROTECTED] wrote:
I looked at that diff and it looks like what I added, except that I also
set bits 7:6 of CCR68 to 01 because the doc I have says that will select
VCLK from the programmable VCLK regs, CCR6C and CCR6D.
I fixed the vclk problem. The
in SMI_Save(), SR6C and SR6D (and SR68) are saved only if pSmi-Dualhead,
why ? seems it should always be done ?
in SMI_WriteMode, those 2 are written twice, once everytime + once if
pSmi-Dualhead
What's your take about CCR68 (SR68), also written only in dualhead
mode... seems if SR6C/SR6D
On 3/10/07, bruno schwander [EMAIL PROTECTED] wrote:
I looked at that diff and it looks like what I added, except that I also
set bits 7:6 of CCR68 to 01 because the doc I have says that will select
VCLK from the programmable VCLK regs, CCR6C and CCR6D.
Right, I should probably do that
On 3/10/07, bruno schwander [EMAIL PROTECTED] wrote:
in SMI_Save(), SR6C and SR6D (and SR68) are saved only if pSmi-Dualhead,
why ? seems it should always be done ?
It should. Like I said this is still my untested local working tree.
I'm aiming to add xrandr 1.2 support as well.
in
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
On Fri, 9 Mar 2007, Alex Deucher wrote:
On 3/9/07, bruno schwander [EMAIL PROTECTED] wrote:
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
On 3/9/07, bruno schwander [EMAIL PROTECTED] wrote:
On Fri, 9 Mar 2007, Alex Deucher wrote:
On 3/9/07, bruno schwander [EMAIL PROTECTED] wrote:
so I gather now that actually I should leave the xf86SetCrtcForModes()
alone, and just add setting the clock with CCR6C, CCR6D (and enabling it
On Fri, 9 Mar 2007, Alex Deucher wrote:
The latest version of the siliconmotion driver in xorg git head should
have the lockup fix you need. The problem is the engine doesn't need
to be synced until it has been started. I've also added dualhead
support. I haven't yet pushed the pll fix,
On 3/9/07, bruno schwander [EMAIL PROTECTED] wrote:
On Fri, 9 Mar 2007, Alex Deucher wrote:
The latest version of the siliconmotion driver in xorg git head should
have the lockup fix you need. The problem is the engine doesn't need
to be synced until it has been started. I've also added
I looked at that diff and it looks like what I added, except that I also
set bits 7:6 of CCR68 to 01 because the doc I have says that will select
VCLK from the programmable VCLK regs, CCR6C and CCR6D.
I'll get git and give your tree a try, thanks
bruno
On Fri, 9 Mar 2007, Alex Deucher wrote:
On 3/8/07, bruno schwander [EMAIL PROTECTED] wrote:
ah never mind. since this is interlaced, the pixel clock needs to be half
that to get the right frame refresh rate (60Hz) with a pixel clock of
12.22MHz, it passes.
Now, I am not sure if the pixel clock is effectively set to that, and my
lcd
On Thu, 8 Mar 2007, Tim Roberts wrote:
bruno schwander wrote:
ah never mind. since this is interlaced, the pixel clock needs to be
half that to get the right frame refresh rate (60Hz) with a pixel
clock of 12.22MHz, it passes.
Now, I am not sure if the pixel clock is effectively set to that,
On Thu, 8 Mar 2007, Tim Roberts wrote:
bruno schwander wrote:
ah never mind. since this is interlaced, the pixel clock needs to be
half that to get the right frame refresh rate (60Hz) with a pixel
clock of 12.22MHz, it passes.
Now, I am not sure if the pixel clock is effectively set to that,
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 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
19 matches
Mail list logo
