public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Dave Airlie <airlied@gmail.com>
Cc: Andreas Schwab <schwab@suse.de>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
Date: Fri, 08 Apr 2005 08:59:55 +1000	[thread overview]
Message-ID: <1112914795.9568.320.camel@gaston> (raw)
In-Reply-To: <21d7e9970504071422349426eb@mail.gmail.com>

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.




  reply	other threads:[~2005-04-07 23:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-11  5:42 [PATCH] radeonfb: Implement proper workarounds for PLL accesses Benjamin Herrenschmidt
2005-03-13  0:12 ` [PATCH] radeonfb: (#2) " Benjamin Herrenschmidt
2005-04-05 21:44   ` Andreas Schwab
2005-04-05 23:31     ` Benjamin Herrenschmidt
2005-04-06 22:35       ` Andreas Schwab
2005-04-06 22:47         ` Benjamin Herrenschmidt
2005-04-07 20:21           ` Andreas Schwab
2005-04-07 21:22             ` Dave Airlie
2005-04-07 22:59               ` Benjamin Herrenschmidt [this message]
2005-04-07 23:58                 ` Andreas Schwab
2005-04-08  0:03                   ` Benjamin Herrenschmidt
2005-04-08  1:19                   ` Benjamin Herrenschmidt
2005-04-08 21:11                     ` Andreas Schwab
2005-04-09  0:03                       ` Benjamin Herrenschmidt
2005-04-09 16:24                         ` Andreas Schwab
2005-04-09 23:33                           ` Benjamin Herrenschmidt
2005-04-10 10:05                             ` Moritz Muehlenhoff
2005-04-10 22:45                               ` Benjamin Herrenschmidt
2005-04-10 23:10                                 ` Brice Goglin
2005-04-07 22:47             ` Benjamin Herrenschmidt
2005-04-07 23:13               ` Andreas Schwab
2005-04-07 23:19                 ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1112914795.9568.320.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=airlied@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox