linux_dsm_epyc7002/drivers/gpu/drm/i915/display/intel_bw.h

/* SPDX-License-Identifier: MIT */
/*
 * Copyright © 2019 Intel Corporation
 */

#ifndef __INTEL_BW_H__
#define __INTEL_BW_H__

#include <drm/drm_atomic.h>

#include "intel_display.h"

struct drm_i915_private;
struct intel_atomic_state;
struct intel_crtc_state;

struct intel_bw_state {
	struct drm_private_state base;

	unsigned int data_rate[I915_MAX_PIPES];
	u8 num_active_planes[I915_MAX_PIPES];
};

#define to_intel_bw_state(x) container_of((x), struct intel_bw_state, base)

void intel_bw_init_hw(struct drm_i915_private *dev_priv);
int intel_bw_init(struct drm_i915_private *dev_priv);
void intel_bw_cleanup(struct drm_i915_private *dev_priv);
int intel_bw_atomic_check(struct intel_atomic_state *state);
void intel_bw_crtc_update(struct intel_bw_state *bw_state,
			  const struct intel_crtc_state *crtc_state);

#endif /* __INTEL_BW_H__ */
drm/i915: Make sure we have enough memory bandwidth on ICL ICL has so many planes that it can easily exceed the maximum effective memory bandwidth of the system. We must therefore check that we don't exceed that limit. The algorithm is very magic number heavy and lacks sufficient explanation for now. We also have no sane way to query the memory clock and timings, so we must rely on a combination of raw readout from the memory controller and hardcoded assumptions. The memory controller values obviously change as the system jumps between the different SAGV points, so we try to stabilize it first by disabling SAGV for the duration of the readout. The utilized bandwidth is tracked via a device wide atomic private object. That is actually not robust because we can't afford to enforce strict global ordering between the pipes. Thus I think I'll need to change this to simply chop up the available bandwidth between all the active pipes. Each pipe can then do whatever it wants as long as it doesn't exceed its budget. That scheme will also require that we assume that any number of planes could be active at any time. TODO: make it robust and deal with all the open questions v2: Sleep longer after disabling SAGV v3: Poll for the dclk to get raised (seen it take 250ms!) If the system has 2133MT/s memory then we pointlessly wait one full second :( v4: Use the new pcode interface to get the qgv points rather that using hardcoded numbers v5: Move the pcode stuff into intel_bw.c (Matt) s/intel_sagv_info/intel_qgv_info/ Do the NV12/P010 as per spec for now (Matt) s/IS_ICELAKE/IS_GEN11/ v6: Ignore bandwidth limits if the pcode query fails Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190524153614.32410-1-ville.syrjala@linux.intel.com 2019-05-24 22:36:14 +07:00			`/* SPDX-License-Identifier: MIT */`
			`/*`
			`* Copyright © 2019 Intel Corporation`
			`*/`

			`#ifndef __INTEL_BW_H__`
			`#define __INTEL_BW_H__`

			`#include <drm/drm_atomic.h>`

			`#include "intel_display.h"`

			`struct drm_i915_private;`
			`struct intel_atomic_state;`
			`struct intel_crtc_state;`

			`struct intel_bw_state {`
			`struct drm_private_state base;`

			`unsigned int data_rate[I915_MAX_PIPES];`
			`u8 num_active_planes[I915_MAX_PIPES];`
			`};`

			`#define to_intel_bw_state(x) container_of((x), struct intel_bw_state, base)`

			`void intel_bw_init_hw(struct drm_i915_private *dev_priv);`
			`int intel_bw_init(struct drm_i915_private *dev_priv);`
drm/i915/display: cleanup intel_bw_state on i915 module removal intel_bw_state allocated memory is not getting freed even after module removal. kmemleak reported backtrace: [<0000000079019739>] kmemdup+0x17/0x40 [<00000000d58c1b9d>] intel_bw_duplicate_state+0x1b/0x40 [i915] [<000000007423ed0c>] drm_atomic_get_private_obj_state+0xca/0x140 [<00000000100e3533>] intel_bw_atomic_check+0x133/0x350 [i915] [<00000000126d0e0c>] intel_atomic_check+0x1ab7/0x20d0 [i915] [<00000000d5dfc004>] drm_atomic_check_only+0x563/0x810 [<00000000c9379611>] drm_atomic_commit+0xe/0x50 [<00000000ec82b765>] drm_atomic_helper_disable_all+0x133/0x160 [<000000003c44760c>] drm_atomic_helper_shutdown+0x65/0xc0 [<00000000414e3e5c>] i915_driver_remove+0xcb/0x130 [i915] [<00000000f8544c2a>] i915_pci_remove+0x19/0x40 [i915] [<000000002dcbd148>] pci_device_remove+0x36/0xb0 [<000000003c8c6b0a>] device_release_driver_internal+0xe0/0x1c0 [<00000000580e9566>] unbind_store+0xc3/0x120 [<00000000869d0df5>] kernfs_fop_write+0x104/0x190 [<000000004dc1a355>] vfs_write+0xb9/0x1d0 Call the drm_atomic_private_obj_fini(), which inturn calls the intel_bw_destroy_state() to make sure the intel_bw_state memory is freed properly. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191209143921.9240-1-pankaj.laxminarayan.bharadiya@intel.com 2019-12-09 21:39:02 +07:00			`void intel_bw_cleanup(struct drm_i915_private *dev_priv);`
drm/i915: Make sure we have enough memory bandwidth on ICL ICL has so many planes that it can easily exceed the maximum effective memory bandwidth of the system. We must therefore check that we don't exceed that limit. The algorithm is very magic number heavy and lacks sufficient explanation for now. We also have no sane way to query the memory clock and timings, so we must rely on a combination of raw readout from the memory controller and hardcoded assumptions. The memory controller values obviously change as the system jumps between the different SAGV points, so we try to stabilize it first by disabling SAGV for the duration of the readout. The utilized bandwidth is tracked via a device wide atomic private object. That is actually not robust because we can't afford to enforce strict global ordering between the pipes. Thus I think I'll need to change this to simply chop up the available bandwidth between all the active pipes. Each pipe can then do whatever it wants as long as it doesn't exceed its budget. That scheme will also require that we assume that any number of planes could be active at any time. TODO: make it robust and deal with all the open questions v2: Sleep longer after disabling SAGV v3: Poll for the dclk to get raised (seen it take 250ms!) If the system has 2133MT/s memory then we pointlessly wait one full second :( v4: Use the new pcode interface to get the qgv points rather that using hardcoded numbers v5: Move the pcode stuff into intel_bw.c (Matt) s/intel_sagv_info/intel_qgv_info/ Do the NV12/P010 as per spec for now (Matt) s/IS_ICELAKE/IS_GEN11/ v6: Ignore bandwidth limits if the pcode query fails Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190524153614.32410-1-ville.syrjala@linux.intel.com 2019-05-24 22:36:14 +07:00			`int intel_bw_atomic_check(struct intel_atomic_state *state);`
			`void intel_bw_crtc_update(struct intel_bw_state *bw_state,`
			`const struct intel_crtc_state *crtc_state);`

			`#endif /* __INTEL_BW_H__ */`