On Thu, 2004-09-23 at 21:28, Michael Schmitz wrote:
> Hi,
>
> > > At least the feedback divider and post divider there (for the albook 5,3)
> > > are different from what I've got (1, and 56 vs. 4 and 80)
> >
> > What do you have at boot in in PPLL_DIV_0 ? It's the value set by OF,
> > Linux uses PPLL_DIV_3 to set it's own.
>
> Can I read that from user space? Or should I add some printk to
> radeon_probe_pll_params ?
You can probably mmap /dev/mem to the right address and read it from
userspace ;)
> Did I mention that radeon_probe_pll_params fails to detect the xtal clock
> properly? It gets 25.6 MHz on probe ... but even making it tolerate that
> as 27 MHz, it only gets sclk and mckl wrong, no improvement. Maybe I need
> to set the ref clock to 26.5 MHz - but keep the OF provided sclk and mclk?
In radeonfb or in X ? radeonfb should get everything from OF, as far as
X is concerned, I plan to write a library so it can get to the OF
provided values via /proc/device-tree
> > > With that patch, the console image is fine. Now the PLL fails to lock
> > > properly in X.
> >
> > Weird... well, X should be tweaked to use the same value as it had
> > upon entry as well, taht is something I should write a patch for, we
> > should basically avoid using a different PLL value than what the ROM
> > set on LVDS panels.
>
> I'll try UseBIOSDividers next.
>
> > > What other combinations of fb_div and post_div can I try? iBooks use 6,
> > > ad, is that safe to use?
> >
> > Read what OF sets. the 2 bits 0x00000300 of CLOCK_CNTL_INDEX define
> > which of the 4 PPLL_DIV_n register is to be used. Apple uses 0 and we
> > use 3. The nice side effect is that apple value isn't overriden by
> > linux so you can still read it without having to reboot :)
>
> The code in radeonfb_base.c gives me a headache. What's ppll_div_sel
> being used for? The PLL recalc code sets the clock index to use
> PPLL_DIV_0, and then reads at PPLL_DIV_0+ppll_div_sel - is that the fb_div
> value?
Just give me the values of PPLL_DIV_0 and PPLL_REF_DIV and I'll figure
it out.
> Based on what's there, the measured vclk gets scaled and we arrive at 26.5
> MHz instead of 27 - maybe that's why the PLL doesn't lock with 27 MHz?
>
> > Also, check the value you have and send me a proper patch for radeonfb :)
>
> --- drivers/video/aty/radeon_monitor.c.org 2004-09-23
> 13:24:49.567846088 +0200
> +++ drivers/video/aty/radeon_monitor.c 2004-09-23 13:24:13.241368552
> +0200
> @@ -652,6 +652,13 @@
> rinfo->panel_info.fbk_divider = 0x80;
> rinfo->panel_info.use_bios_dividers = 1;
> }
> + /* Aluminium PowerBook 17" */
> + if (machine_is_compatible("PowerBook5,5")) {
> + rinfo->panel_info.ref_divider = rinfo->pll.ref_div;
> + rinfo->panel_info.post_divider = 0x4;
> + rinfo->panel_info.fbk_divider = 0x80;
> + rinfo->panel_info.use_bios_dividers = 1;
> + }
> /* iBook G4 */
> if (machine_is_compatible("PowerBook6,3") |
> machine_is_compatible("PowerBook6,5")) {
>
>
> That works for console but not X. The iBook values totally messed up the
> console, BTW.
Well, the LVDS is quite sensitive ... Once you get radeonfb to work in console,
use UseFBDev in X until I have fixed X...
Ben.
