Benjamin Herrenschmidt a écrit :
But it's not specific to X11; I've applied the patch you posted and the
same symptoms occur for pure tty switching as well, the delay has decreased
a bit (it's hard to measure, but around a second), but it's still rather
annoying to work with.
Is it distinguishable
> But it's not specific to X11; I've applied the patch you posted and the
> same symptoms occur for pure tty switching as well, the delay has decreased
> a bit (it's hard to measure, but around a second), but it's still rather
> annoying to work with.
>
> Is it distinguishable which M6 models are
Benjamin Herrenschmidt wrote:
>> radeonfb_setcolreg: INPLL
>> radeonfb_setcolreg: OUTPLL
>> radeonfb_setcolreg: OUTPLL
>> ... last three lines repeated 63 times
>
> Hrm... the last (serie of 64 setcolreg) are probably X beeing extremely
> dumb, and calling the ioctl 64 times to set each palette ent
On Sat, 2005-04-09 at 18:24 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > Can you redo the counting of the workarounds with the patch ?
>
> Switching from X to console:
>
> radeon_write_pll_regs: INPLL
> radeon_write_pll_regs: INPLL
> radeon_write_mode:
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> Can you redo the counting of the workarounds with the patch ?
Switching from X to console:
radeon_write_pll_regs: INPLL
radeon_write_pll_regs: INPLL
radeon_write_mode: OUTPLL
radeonfb_engine_reset: INPLL
radeonfb_engine_reset: OUTPLL
radeonfb_
> > This patch adds to the fbdev interface a set_cmap callback that allow
> > the driver to "batch" palette changes. This is useful for drivers like
> > radeonfb which might require lenghtly workarounds on palette accesses,
> > thus allowing to factor out those workarounds efficiently.
>
> This m
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> On Fri, 2005-04-08 at 01:58 +0200, Andreas Schwab wrote:
>> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>>
>> > Yes, that's very extreme, I suspect somebody is banging on set_par or
>> > something like that.
>>
>> fb_setcolreg is it.
>
On Fri, 2005-04-08 at 01:58 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > Yes, that's very extreme, I suspect somebody is banging on set_par or
> > something like that.
>
> fb_setcolreg is it.
Ok, what about that patch:
---
This patch adds to the fbdev
On Fri, 2005-04-08 at 01:58 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > Yes, that's very extreme, I suspect somebody is banging on set_par or
> > something like that.
>
> fb_setcolreg is it.
Ahhh... interesting. I'll see if I can find a way to work aro
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> Yes, that's very extreme, I suspect somebody is banging on set_par or
> something like that.
fb_setcolreg is it.
kernel: radeonfb_set_par
kernel: radeon_write_pll_regs: radeon_pll_errata_after_data
kernel: radeon_write_pll_regs: radeon_pll_err
On Fri, 2005-04-08 at 01:13 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > Can you cound how many times radeonfb_set_par is called and dump your
> > "counter" at the beginning and end of each of these calls ?
>
> Switch from X to console:
>
> kernel: rade
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> Can you cound how many times radeonfb_set_par is called and dump your
> "counter" at the beginning and end of each of these calls ?
Switch from X to console:
kernel: radeonfb_set_par
kernel: radeon_pll_errata_after_data
last message repeated 7
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 suspe
On Thu, 2005-04-07 at 22:21 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > It is weird tho. Could you try adding a printk or something to figure
> > out how much this is called during a typical swich ?
>
> There are 1694 calls to radeon_pll_errata_after_da
> 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 :-)
Dave.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> It is weird tho. Could you try adding a printk or something to figure
> out how much this is called during a typical swich ?
There are 1694 calls to radeon_pll_errata_after_data during a switch from
X to the console and 393 calls the other way.
On Thu, 2005-04-07 at 00:35 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > Hrm... it should only add a few ms, maybe about 20 ms to the mode
> > switching... If you remove the radeon_msleep(5) call from the
> > radeon_pll_errata_after_data() routine in rade
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> Hrm... it should only add a few ms, maybe about 20 ms to the mode
> switching... If you remove the radeon_msleep(5) call from the
> radeon_pll_errata_after_data() routine in radeonfb.h, does it make a
> difference ?
Yes, it does. Without the s
On Tue, 2005-04-05 at 23:44 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > After discussion with ATIs, it seems that the workarounds they initially
> > gave me were not completely correct.
> >
> > This patch implements the proper ones, which includes sleepi
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> After discussion with ATIs, it seems that the workarounds they initially
> gave me were not completely correct.
>
> This patch implements the proper ones, which includes sleeping in PLL
> accesses, and thus requires the previous patch to make su
On Fri, 2005-03-11 at 16:42 +1100, Benjamin Herrenschmidt wrote:
> Hi !
>
> After discussion with ATIs, it seems that the workarounds they initially
> gave me were not completely correct.
>
> This patch implements the proper ones, which includes sleeping in PLL
> accesses, and thus requires the p
21 matches
Mail list logo
