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
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
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 entry instead
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 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
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
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
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: OUTPLL
> > 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
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.
>
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.
Ok, what about
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 makes 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
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
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:
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:
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
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
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
> 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
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.
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 a
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_data during
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
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 774
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: radeonfb_set_par
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:
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 around that
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 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
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
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 sleep,
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 radeonfb.h,
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
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
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 sure we
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 sleeping in PLL
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
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
42 matches
Mail list logo
