Re: intel_gpu_top missing clocks

[Ben Widawsky <ben@bwidawsk.net>]

On Thu, Jun 19, 2014 at 09:33:44PM +0100, Bragg, Robert wrote:
>    On Thu, Jun 19, 2014 at 3:10 PM, Chris Healy <[1]cphealy@gmail.com>
>    wrote:
> 
>    Hi Robert,
>    This information is helpful.  I am able to query the frequencies as
>    you mentioned.  My primary interest though is in getting support added
>    to intel_gpu_top.  It seems to me that intel_gpu_top has been coded to
>    support providing clock frequency data for a subset of Intel GPUs and
>    that the mobile Ivy Bridge GT2 chipset is not supported.  Would you
>    agree with this?
> 
>    That looks right, yep.

intel_gpu_top was designed and developed before we had variable GPU
frequencies and before we had either the sysfs or debugfs interace.

>    Â
> 
>    If so, I'd like to fix this but don't know where to look for the bit
>    descriptions for the necessary registers.  Can you point me to the
>    appropriate document?
> 
>    I'm afraid it looks like that the i915_debugfs.c code may be the best
>    reference a.t.m; though maybe someone who's worked on that code (not
>    me) can give you a better answer.
>    That said though; it could make sense to update intel_gpu_top to query
>    debugfs for this information anyway; considering that it's more up to
>    date and that way the logic doesn't need to be duplicated. For example
>    if you take a look at overlay/gpu-freq.c in the intel_gpu_tools repo it
>    looks like there's already some precedent for doing just that. It also
>    looks like the utility code in overlay/debugfs.c can be used to make
>    sure debugfs is mounted.
>    Sorry I couldn't point you at good documentation for this; but
>    hopefully that's still of some help to you.

Please do not use debugfs. Generally this is not the interface to write
a tool against. The sysfs interface is a stable interface, and that
should always be used. tests/pm_rps.c already loads and reads/writes
this interface.  Copy that code to print_clock_info () with the
appropriate if (have_sysfs(...)) or whatever you want.

BTW pm_rps has gotten very complex in the last few months. I would
recommend using the git history to find the initial commit for this
task.

>    --
>    Regards,
>    Robert
> 
>    Regards,
>    Chris
> 
>    On Tue, Jun 17, 2014 at 7:43 PM, Bragg, Robert
>    <[2]robert.bragg@intel.com> wrote:
> 
>    Hi Chris,
>    You can query the nominal and maximum frequency of your GPU via
>    debugfs, in case that is good enough for your needs. Depending on what
>    kernel version you have you can try to cat
>    /sys/kernel/debug/dri/0/i915_cur_delayinfo or with more recent
>    versions, /sys/kernel/debug/dri/0/i915_frequency_info
>    If you are curious about more details then it may be best to look at
>    the drm driver code in
>    drivers/gpu/drm/i915/i915_debugfs.c:i915_frequency_info().
>    --
>    Regards,
>    Robert
>    On Wed, Jun 18, 2014 at 1:55 AM, He, Shuang <[3]shuang.he@intel.com>
>    wrote:
> 
>    Hi, Chris
> 
>    Â Â Â Â Â Â Â Â  Letâs put you to the correct Mailing list for this
>    topic first
> 
>    Â
> 
>    Thanks
> 
>    Â Â Â Â Â Â Â Â  --Shuang
> 
>    From: Chris Healy [mailto:[4]cphealy@gmail.com]
>    Sent: Wednesday, June 18, 2014 1:15 AM
>    To: Eric Anholt; He, Shuang
>    Subject: intel_gpu_top missing clocks
> 
>    Â
> 
>    Eric, Shuang,
> 
>    I couldn't find an appropriate mailing list to report this on, so I'm
>    mailing the two of you as you've both touched the clock code in
>    intel_gpu_top.
> 
>    I'm running an Ivy Bridge Mobile chipset and trying to use
>    intel_gpu_top and intel_stepping to see the GPU clock frequencies.  In
>    both cases, the clocks are "unknown".
>    When I look at the code, it seems that there's just no code path to
>    handle this devid, though I'm not sure as I'm not very good at
>    understanding code.  I see in intel_chipset.h that device id 0x0166 =
>    PCI_CHIP_IVYBRIDGE_M_GT2 and that none of the "if's" in
>    print_clock_info ultimately point to this device type.
> 
>    Do either of you know why this would be?  Is it just a case of coding
>    for the majority of chipset configurations?
> 
>    If it's just the case of it not yet being handled, I'd be open to
>    trying to add support for it if you could point me to the necessary
>    chip documentation.
> 
>    Regards,
>    Chris
> 
>      _______________________________________________
>      Intel-gfx mailing list
>      [5]Intel-gfx@lists.freedesktop.org
>      [6]http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> References
> 
>    1. mailto:cphealy@gmail.com
>    2. mailto:robert.bragg@intel.com
>    3. mailto:shuang.he@intel.com
>    4. mailto:cphealy@gmail.com
>    5. mailto:Intel-gfx@lists.freedesktop.org
>    6. http://lists.freedesktop.org/mailman/listinfo/intel-gfx

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx


-- 
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx