Messages in this thread | | | Subject | Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses | From | Benjamin Herrenschmidt <> | Date | Fri, 08 Apr 2005 08:59:55 +1000 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |