Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLLaccesses

[Benjamin Herrenschmidt]

On Fri, 2005-04-08 at 07:22 +1000, Dave Airlie wrote:
> > There are 1694 calls to radeon_pll_errata_after_data during a switch from
> > X to the console and 393 calls the other way.
> 
> Wow... Ben that seems a bit extreme... there's not even close to 393 plls :-)

Yes, that's very extreme, I suspect somebody is banging on set_par or
something like that. Let me count a normal set_par operation:

 - blank. That can do INPLL, OUTPLLP and OUTPLL on MT_LCD, that is 4
calls to the errata (OUTPLLP has two). 

 - write_pll_regs which does
    * on mobility chips: 2x INPLL to test the PLL value, and if it
matches, just writes the PLL selector with a call to the errata, that
is only 3 calls to the errata. Can you check we actually get in that
case ? Normally, on the internal LCD, we should never change the PLL
registers, or only one (they should stay the same all the time after
that) and thus we should get into this case. If not (CRT), indeed, we
end up doing more accesses:

    * OUTPLLP (2), OUTPLLP (2), manual errata (1), OUTPLLP (2),
OUTPLLP (2), OUTPLLP (2), an INPLL loop (hrm...), OUTPLLP (2), another
INPLL loop, OUTPLL (1), OUTPLLP (2), OUTPLLP (2). That is 18 calls to
the errata plus the 2 INPLL loops. It would be useful to instrument
those loops and see what happens there, but I don't see why they would
have any impact unless something wrong is going on there with the PLL
locking...

   * One last call to OUTPLLP (2).

 - reset the engine, that is 3 calls to the errata

So that means that one call to raeonfb_set_par() should be in the normal
internal flat panel case about 12 calls to the errata, and in the case
where we actually write the PLL registers, about 29, plus the ones
called by the INPLL loops waiting for the PLL to lock.

As you can see, we are far below the measured counts. So I would need
more instrumentation of the driver to figure out what's going on there.

Ben.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/