Skip to content
Snippets Groups Projects
Select Git revision
  • 54c6fd566bb887e2c01d0db00ac83a1f1e8fd0d8
  • vme-testing default
  • ci-test
  • master
  • remoteproc
  • am625-sk-ov5640
  • pcal6534-upstreaming
  • lps22df-upstreaming
  • msc-upstreaming
  • imx8mp
  • iio/noa1305
  • vme-next
  • vme-next-4.14-rc4
  • v4.14-rc4
  • v4.14-rc3
  • v4.14-rc2
  • v4.14-rc1
  • v4.13
  • vme-next-4.13-rc7
  • v4.13-rc7
  • v4.13-rc6
  • v4.13-rc5
  • v4.13-rc4
  • v4.13-rc3
  • v4.13-rc2
  • v4.13-rc1
  • v4.12
  • v4.12-rc7
  • v4.12-rc6
  • v4.12-rc5
  • v4.12-rc4
  • v4.12-rc3
32 results

cppc_cpufreq.c

Blame
    • Prashanth Prakash's avatar
      d4f3388a
      cpufreq / CPPC: Set platform specific transition_delay_us · d4f3388a
      Prashanth Prakash authored
      
      Add support to specify platform specific transition_delay_us instead
      of using the transition delay derived from PCC.
      
      With commit 3d41386d (cpufreq: CPPC: Use transition_delay_us
      depending transition_latency) we are setting transition_delay_us
      directly and not applying the LATENCY_MULTIPLIER. Because of that,
      on Qualcomm Centriq we can end up with a very high rate of frequency
      change requests when using the schedutil governor (default
      rate_limit_us=10 compared to an earlier value of 10000).
      
      The PCC subspace describes the rate at which the platform can accept
      commands on the CPPC's PCC channel. This includes read and write
      command on the PCC channel that can be used for reasons other than
      frequency transitions. Moreover the same PCC subspace can be used by
      multiple freq domains and deriving transition_delay_us from it as we
      do now can be sub-optimal.
      
      Moreover if a platform does not use PCC for desired_perf register then
      there is no way to compute the transition latency or the delay_us.
      
      CPPC does not have a standard defined mechanism to get the transition
      rate or the latency at the moment.
      
      Given the above limitations, it is simpler to have a platform specific
      transition_delay_us and rely on PCC derived value only if a platform
      specific value is not available.
      
      Signed-off-by: default avatarPrashanth Prakash <pprakash@codeaurora.org>
      Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
      Fixes: 3d41386d (cpufreq: CPPC: Use transition_delay_us depending transition_latency)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d4f3388a
      History
      cpufreq / CPPC: Set platform specific transition_delay_us
      Prashanth Prakash authored
      
      Add support to specify platform specific transition_delay_us instead
      of using the transition delay derived from PCC.
      
      With commit 3d41386d (cpufreq: CPPC: Use transition_delay_us
      depending transition_latency) we are setting transition_delay_us
      directly and not applying the LATENCY_MULTIPLIER. Because of that,
      on Qualcomm Centriq we can end up with a very high rate of frequency
      change requests when using the schedutil governor (default
      rate_limit_us=10 compared to an earlier value of 10000).
      
      The PCC subspace describes the rate at which the platform can accept
      commands on the CPPC's PCC channel. This includes read and write
      command on the PCC channel that can be used for reasons other than
      frequency transitions. Moreover the same PCC subspace can be used by
      multiple freq domains and deriving transition_delay_us from it as we
      do now can be sub-optimal.
      
      Moreover if a platform does not use PCC for desired_perf register then
      there is no way to compute the transition latency or the delay_us.
      
      CPPC does not have a standard defined mechanism to get the transition
      rate or the latency at the moment.
      
      Given the above limitations, it is simpler to have a platform specific
      transition_delay_us and rely on PCC derived value only if a platform
      specific value is not available.
      
      Signed-off-by: default avatarPrashanth Prakash <pprakash@codeaurora.org>
      Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
      Fixes: 3d41386d (cpufreq: CPPC: Use transition_delay_us depending transition_latency)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
    pvr_debugfs.c 1.29 KiB
    // SPDX-License-Identifier: GPL-2.0-only OR MIT
    /* Copyright (c) 2023 Imagination Technologies Ltd. */
    
    #include "pvr_debugfs.h"
    
    #include "pvr_device.h"
    #include "pvr_fw_trace.h"
    #include "pvr_params.h"
    
    #include <linux/dcache.h>
    #include <linux/debugfs.h>
    #include <linux/err.h>
    #include <linux/kernel.h>
    #include <linux/types.h>
    
    #include <drm/drm_device.h>
    #include <drm/drm_file.h>
    #include <drm/drm_print.h>
    
    static const struct pvr_debugfs_entry pvr_debugfs_entries[] = {
    	{"pvr_params", pvr_params_debugfs_init},
    	{"pvr_fw", pvr_fw_trace_debugfs_init},
    };
    
    void
    pvr_debugfs_init(struct drm_minor *minor)
    {
    	struct drm_device *drm_dev = minor->dev;
    	struct pvr_device *pvr_dev = to_pvr_device(drm_dev);
    	struct dentry *root = minor->debugfs_root;
    	size_t i;
    
    	for (i = 0; i < ARRAY_SIZE(pvr_debugfs_entries); ++i) {
    		const struct pvr_debugfs_entry *entry = &pvr_debugfs_entries[i];
    		struct dentry *dir;
    
    		dir = debugfs_create_dir(entry->name, root);
    		if (IS_ERR(dir)) {
    			drm_warn(drm_dev,
    				 "failed to create debugfs dir '%s' (err=%d)",
    				 entry->name, (int)PTR_ERR(dir));
    			continue;
    		}
    
    		entry->init(pvr_dev, dir);
    	}
    }
    
    /*
     * Since all entries are created under &drm_minor->debugfs_root, there's no
     * need for a pvr_debugfs_fini() as DRM will clean up everything under its root
     * automatically.
     */